SA 空间预约 - 时间处理逻辑 (Time Pipeline)

职责: 负责接收 LLM 提取的初始槽位，通过归一化与漏斗过滤算法，输出准确的 DateTime 候选或指引 Agent 进行 澄清/报错。

---

1. 逻辑架构 (Pipeline Architecture)

为解决复杂场景下分支嵌套过深、维护困难的问题，时间处理逻辑采用 “三步法 (归一化 -> 漏斗过滤 -> 决策建议)”。

1.1 核心流程图

---

2. 三步法详细说明

2.1 槽位归一化与一致性匹配 (Normalization)

在此阶段将不稳定的语义槽位转换为确定的时间区间，并利用区间交集算法 (Range Intersection) 拦截所有逻辑矛盾。

• 1.1 槽位提取与默认补全 (Pre-processing)：
  • Date 补全：若 start_date 为空，补全为 Today。
  • Duration 补全：若 duration_hours 为空，默认补全为 1.0 (1 小时)。
• 1.2 候选窗口流生成 (Generation)：
  • 将用户的意图转换为 1 或 2 个 [Start, End] 时间窗口：
    • NOW $\to$ [CurrentTime, CurrentTime + Duration]
    • ASAP $\to$ [CurrentTime, 23:59]
    • 数字时间 $\to$ 结合上下午生成对应窗口（无 Period 则生成双候选）。
• 1.3 结束时间跨天截断 (Cross-day Truncation)：
  • 若 Start + Duration 越过当日 00:00，则将结束时间截断为当日 23:59，不报错、不顺延至次日。
  • 截断优先于「时长超限」校验：跨天窗口按截断后的区间放行，不再因原始时长超限而拦截。
  • 背景：前端候选卡片形如 精选3间 2026-09-16 17:00~18:00，不支持跨天展示；且跨天会议本身为伪需求。
• 1.4 候选流生成 (Generation)：
  • 经过匹配与消歧后，输出最终的 “有效候选窗口流 (Candidate Window Stream)”。
  • 后续流向：无论是单窗口（OK）、多窗口（AMBI）还是搜索窗口（ASAP），均统一进入 Phase 2 的漏斗过滤（如营业时间过滤），并最终由 Resource Pipeline 执行物理检索。

2.2 漏斗过滤 (Funnel Filtering)

此阶段将生成的候选池进行逐个规则过滤。

• 过滤器配置化 (软约束)：由 Dify 的流程节点在调用时传入配置。逻辑层读取该配置对候选池进行硬过滤。
• 工作时间范围（已收敛）：AI 空间侧不再单独定义工作时间范围，后续统一从自有会议系统同步；当前暂固定为 00:00 - 23:59，等价于不做营业时间过滤（凌晨时段同样放行）。该规则节点保留，待会议系统同步能力就绪后由上游配置驱动。
• 执行方式：像筛子一样，层层剔除不符合要求的候选。一旦某个候选触发了拦截，记录被拦截的原因（用于后续友好提示）。

2.3 决策与建议 (Resolution)

读取漏斗过滤后的候选池情况：

• 唯一 (Count = 1)：直接 OK，结束。
• 歧义 (Count > 1)：返回 AMBI，交给 Agent 追问。
• 空窗 (Count = 0)：直接报错 ERROR，告知用户该时间段不可用（已过期）。不再执行跨天自动顺延逻辑（跨天场景已在归一化阶段截断至 23:59，不会顺延到次日）。

---

3. 异常场景穷举 (Edge Case Matrix)

为确保系统稳定性，研发需针对以下场景进行逻辑覆盖：

3.1 AMBI (歧义确认)

场景	触发条件	预期 Reason	Agent 预期话术
缺少具体时间	用户仅说“订明天的会议室”，未提供 start_time	缺少具体时间	"好的，请问您想订几点的呢？"
上下午歧义	“订9点的”，且 09:00 和 21:00 均在未来	上下午歧义	"请确认是上午9点还是晚上9点？"

3.2 ERROR (逻辑拦截)

场景	拦截规则	预期 Reason	示例输入
日期已过期	Date 规则	日期已过期	“帮我订昨天的会议室”
时空逻辑矛盾	语义一致性规则	逻辑冲突	“预定明天现在”、“上午 16:00”
时间已过期	历史时间规则	时间已过期	当前 14:00，预定“今天上午 10:00”
非营业时间	营业时间规则（预留，当前默认 00:00-23:59 不拦截）	非营业时间	“帮我订凌晨 3 点的会议室”（当前放行，待会议系统同步后生效）
时长超限	Config 规则（跨天截断优先，仅校验未跨天的超长会议）	时长超限	明天上午 9 点开 5 小时会（Max: 4）

---

4. 接口契约规范 (Time Logic Contract)

4.1 输入参数 (Input)

增加了 config 字段用于企业实施阶段的轻量级软约束配置。

参数名	数据类型	必填	默认值	说明
start_date	String	否	null	日期 "yyyy-MM-dd"
start_time	String	否	null	时间 "HH:mm" 或语义标签 "NOW" / "ASAP"
period	String	否	null	上午/下午标识 ("AM"/"PM")
duration_hours	Float	否	1.0	会议时长
current_time	Long	是	-	当前时间戳
config	Object	否	见下文	实施期预设的业务软规则 (由 Dify 传入)

config 示例:

{
  "work_hours": {
    "start": "00:00",
    "end": "23:59"
  },
  "max_duration_hours": 4.0
}

备注：work_hours 不再由 AI 空间侧单独定义，后续统一从自有会议系统同步；当前暂固定为 00:00-23:59，等价于不做营业时间过滤。

4.2 输出参数 (Output)

字段名	数据类型	说明	示例
status	Enum	处理状态: OK / AMBI / ERROR	"AMBI"
candidates	Array	有效候选项 (标准 DateTime)	["2026-03-23T14:30:00+08:00"]
reason	String	若为 ERROR/AMBI，返回具体诱因	"逻辑冲突 (AM/PM 矛盾)"、"候选数超限"、"时间已过期" 或 "缺少具体时间"

---

5. 落地建议

按照此架构改造后，代码复杂度将大幅度降低：

1. 避免深层 If-Else：新增业务规则只需编写一个新的 Filter 函数加入 Pipe。
2. 将业务权交还给实施与客户：由实施同学在 Dify 后台配置软约束 config，开发层面不再硬编码“上下班时间”（工作时间范围改由会议系统同步，AI 侧不再单独维护）。