开源 AI Agent Runtime：客服知识怎样整理成问答卡片客服知识库真正难维护的地方，不是资料太少，而是同一个问

客服团队每天都在回答相似问题：功能怎么开启、某个限制适用于什么版本、遇到异常应该先检查哪一步。答案散落在帮助文档、更新说明和历史回复里，新人很难判断哪一段仍然有效。让 Agent 直接“整理所有常见问题”，容易把过期内容、内部讨论和正式说明混在一起。

更稳的做法是把资料加工成问答卡片。每张卡片都包含问题、简短答案、适用范围、来源名称、原文片段、版本日期和复核状态；无法从资料确认的内容进入待补充区，不用模型的常识补齐。这样，问答卡片既能帮助客服查找，也能作为后续知识维护的基础。

ZGI 可以承接这条流程：把允许使用的文件绑定到 Agent，用工作流安排抽取、分类、冲突检查和人工确认，再查看每次运行的步骤与结构化输出。这里的字段、分类和规则是示例方案，具体效果仍需使用团队自己的资料验收。

先定义什么是一张合格卡片

输入资料先分为正式帮助文档、版本说明、故障排查、产品公告和内部讨论。正式资料可以进入候选范围，内部讨论默认不直接生成对外答案；每份文件记录发布日期、适用版本、语言和来源负责人。没有日期或版本的资料先标记，不要因为文字写得完整就默认有效。

卡片字段可以这样设计：用户问题、答案、适用条件、排除条件、操作步骤、来源文件、原文片段、版本、审核人和状态。答案要解决一个具体问题，不能把五个相关问题拼成一张大卡片。问题相似但适用版本不同，应保留两张卡片，并明确区分条件。

提示词不应只要求“写得清楚”，还要规定证据边界：“只使用已绑定资料；答案后附来源和原文；不要补充资料外的功能；遇到版本冲突分别列出；无法确认时输出待补充。”模型先提取问题和依据，再生成短答案，出错时更容易回到原文。

工作流可以分成四个节点。第一步按主题和资料类型筛选候选段落；第二步生成问答卡片；第三步检查来源、版本和必要字段；第四步把通过的卡片送人工复核，把冲突、不完整和资料外问题分到不同清单。分支条件要写成团队能检查的规则，不能只留下“模型认为相似”。

相似问题合并要保持谨慎。“如何导出报表”和“为什么导出报表失败”虽然都包含导出，却需要不同答案；“在哪里打开功能”和“打开后需要什么权限”也不能仅按关键词合并。合并前让 Agent 给出共同意图、差异条件和被保留的原文，复核人再决定是否合并。

答案冲突时，卡片不应直接选择一段。可以同时展示来源日期、适用版本和冲突句子；如果范围清楚，就拆成带条件的两张卡片；如果范围不清，状态设为待确认。客服最终看到的不是模型的猜测，而是可以继续追问的证据。

复核人要检查三件事：答案是否覆盖问题、操作步骤是否来自原文、适用条件是否写完整。遇到“通常”“一般”“尽快”这类模糊词，要回到来源寻找边界；找不到边界就改成追问，而不是把模糊表达包装成确定答案。

通过复核的卡片可以输出为客服查阅版和维护版。查阅版保留问题、答案、条件和简短出处；维护版额外记录来源文件、版本、审核人和下一次复查时间。两种版本共享同一份来源信息，避免客服看到的文字和维护记录发生偏差。

运行记录能帮助维护流程。若一批卡片突然出现大量重复，检查主题切分和合并条件；若来源丢失，查看结构化输出校验；若旧版本重新出现，检查资料绑定范围和版本过滤。把错误定位到节点，才有机会稳定修正。

准备八类脱敏资料：同义问题、版本更新、部分答案、互相冲突、排查步骤、内部讨论、资料外问题和重复文档。逐项确认卡片是否有来源、是否写清适用条件、冲突是否进入人工环节、资料外问题是否承认没有依据。

不要把卡片数量当作质量指标。十张短而可追溯的卡片，可能比一百张没有版本和出处的卡片更有用。可以记录漏掉的关键问题、错误合并和来源缺失，但只有在样本、方法和结果都保留后，才适合讨论更稳定的质量趋势。

先从一个产品模块和一组正式文档开始，建立字段、状态和复核习惯。资料更新后，不要直接覆盖旧卡片，先生成差异清单，再让负责人确认哪些答案需要重审。这样，知识库会变成可维护的内容资产，而不是一次性生成的文本堆。