知识库越大，Agent 越容易遇到一个隐蔽问题：同一问题有两份甚至三份材料，各自都像是真的。旧版产品说明还在，新版客服话术已经改了，销售 FAQ 又写了另一种例外情况。模型检索到哪一份，回答口径就跟着变。
这类问题不适合只靠人工翻文档。AI Agent 可以先做引用冲突排查，把同一问题下互相冲突、时间不一致或适用范围不清的材料找出来，再交给负责人确认。它和 证据链、质量门禁、需求池去重 都能接上。
先从高频问题开始
不要一上来扫描全站知识库。更现实的做法，是从客服高频问题、低置信度问题、人工退回问题和客户投诉问题开始。它们更可能已经影响真实业务，也更容易看到治理效果。
Agent 可以把同一类问题下被引用过的文档列出来，标注标题、更新时间、适用产品、适用客户和关键结论。先把材料摆在一起，冲突才会显形。
冲突不只是不一致
知识库冲突有很多种。最明显的是结论相反，比如一个文档说支持退款，另一个文档说不支持。更常见的是范围不清：一个规则只适用于企业版，却被 Agent 用来回答个人版用户。
还有一种是时效冲突。旧文章没有删除，新规则已经发布，但旧文章权重更高。Agent 不知道谁是最新口径，就会把过期材料当成证据。
输出要带处理建议
排查结果不能只写“发现冲突”。更有用的输出是：冲突问题、冲突文档、相互矛盾的句子、建议保留口径、需要删除或降权的文档、待人工确认的问题。
如果冲突来自产品规则本身没有定清，就不要让 Agent 强行合并。应该进入产品或运营确认流程，等负责人给出口径后再更新知识库。
更新后要回到评估集
知识库修完不是结束。要把这次冲突问题放进评估样本，后续每次更新知识库、提示词或检索策略时都重新测试。否则同一个问题很可能过几周又回来。
这里可以接上 变更复盘 和 事故分级。如果冲突已经导致客户可见错误，就不只是资料维护，而是生产质量问题。
总结
用 AI Agent 做知识库引用冲突排查，重点不是让它替人决定最终口径，而是先把旧文档、新说明、客服话术和产品规则放到同一张桌面上。冲突看得见，团队才有机会把回答变稳定。
