开源 AI Agent Runtime：制度版本问答

员工问"差旅住宿标准是多少"，知识库里可能同时有今年制度、去年制度和某个地区的补充通知。若 Agent 只按相似度取一段文字，回答看起来流畅，却可能引用了过期版本。更可靠的流程是先判断问题适用范围，再让检索结果带着版本和来源进入回答。

在 ZGI 中，可以把知识绑定、检索、条件分支、模型回答和人工追问串起来。公开资料说明 ZGI 支持知识与 Agent、工作流的绑定，并能查看运行步骤和结构化输出；本文重点放在业务团队可执行的配置和验收，不假设系统已经替你判断制度效力。

先整理资料元数据。每份制度补上生效日期、失效日期、适用地区、员工类型和发布部门；没有这些信息的文件先放到待补充区。文件正文保持原样，版本信息作为过滤条件，而不是写进模型提示词后任由模型自行取舍。

把员工问题拆成几个必要条件：制度主题、发生日期、地点、人员类型和费用类别。问题只说"住宿标准"时，Agent 不应马上报一个数字，而应追问出差地点和发生时间；条件齐全后，才检索处于有效期内且适用范围匹配的资料。

回答输出建议包含结论、适用条件、来源名称、版本日期和原文片段。若两份有效文件仍然冲突，就明确列出冲突位置，请制度负责人确认；不能用发布日期较新的文件自动覆盖专门针对某地区的补充通知。

在运行流中先做问题字段检查，缺少日期或地区就走用户问题节点；字段齐全后，再从已绑定知识范围中检索。模型提示词要求只使用返回的来源，引用原文，不把未找到的内容写成确定结论。回答后再加一个格式检查，确认版本日期和来源字段没有丢失。

如果检索返回多个可能答案，可以设置分支：只有一个来源且范围匹配时进入回答；多个来源冲突时进入人工确认；没有来源时返回需要补充的资料清单。分支条件应写成团队能复核的规则，不能只写"模型判断是否可信"。

运行记录对排错很有用。某次回答不合适时，查看输入条件、候选来源、分支结果和最终结构化输出，判断问题来自资料元数据、筛选条件还是回答提示词。修正后用原问题和一组相似问题重跑，确认没有把范围扩大到别的地区。

准备六组问题：明确日期和地区、缺日期、缺地区、旧制度命中、补充通知覆盖、资料完全没有答案。验收逐项检查：缺条件时是否追问，冲突时是否停下，回答是否带来源，资料外问题是否承认不知道。

不要用"答得像人"作为唯一标准。让制度负责人抽查原文对应关系，业务同事检查追问是否足够具体；发现同一问题在不同版本下得出相同答案，要进一步确认筛选是否失效。

先从报销制度的一类费用开始，保留版本元数据和运行样本，再扩展到更多制度。这样做的价值不是让 Agent 永远替人做决定，而是让每次回答都能说明依据、范围和下一步。