行为链把任务、动作、状态变化和业务结果关联起来，让企业能够还原 AI 做了什么。

但要解释它为什么这样判断，仅有行为链还不够。

Agent 进入生产以后，企业保存了越来越多的运行记录：

Prompt、上下文、知识检索、工具调用、Session、Trace 和接口返回。

这些记录进入了运行现场，却不一定构成判断证据。

从数据量看，现场似乎越来越完整。

但真正出了问题以后，企业经常发现：

记录越来越多，真正能够解释判断的证据，却没有增加多少。

原因并不复杂。

一条信息被放进上下文，只能说明 Agent 有机会看到它。

一次知识检索命中，只能说明系统找到了它。

一个文件被读取，只能说明它进入过工作过程。

这些都不能直接证明：

Agent 最终采用了这条信息，并据此形成了某个判断。

所以我越来越觉得，企业真正需要保留的，不只是 AI 获取了哪些信息，而是哪些运行时事实被采用，并影响了这次判断。

我们平时很容易把资料和证据混在一起。

一份制度文件。

一条业务规则。

一次接口返回。

一条生产日志。

它们都可能成为证据。

但脱离具体任务和判断，它们首先只是信息。

还是登录超时的例子。

第一条事实，是生产日志显示，请求在两次重试后仍然失败。

第二条事实，是当前配置将最大重试次数设为两次，而现行运行规范要求此类瞬时故障重试五次。

这两条事实都支持“重试次数不足”的判断。

但还有第三条事实：

Trace 显示，每次重试都卡在下游数据库连接，增加重试次数并不能解决问题。

这条事实反而在否定“重试次数不足”的判断。

如果企业只保存 Agent 引用了哪些资料，就可能看到一套很完整的支持理由。

但如果没有把反向证据一起放进现场，所谓解释，很可能只是把一个已经作出的判断讲圆。

因此，证据链不是资料清单。

证据链是运行事实与具体判断之间的关系。

它不仅要说明“有什么信息”，还要说明：

这条信息支持什么。

反对什么。

适用于什么条件。

有没有被实际采用。

最终影响了哪个判断和动作。

这里所说的证据，是能够被核验，并且能够与具体判断对应的运行时事实。

RAG、搜索和文件读取可以告诉企业，哪些信息进入过 Agent 的运行现场。

但“进入现场”和“形成依据”之间，还有很长一段距离。

一份资料可能被检索到，却因为优先级较低而没有被采用。

也可能被放进上下文，但被另一条规则覆盖。

还可能确实被采用了，却只支持判断的一部分。

因此，企业至少要区分三件事：

检索到了，不等于采用了。

采用了，不等于形成了充分依据。

依据充分，也不等于判断一定正确。

第一层解决信息有没有进入现场。

第二层解决信息有没有真正支撑判断。

第三层则要继续判断：在这些依据之上，Agent 得出的结论和采取的动作到底好不好。

这也是证据链与质量评估（Evaluation）的边界。

证据链解释判断怎样形成。

质量评估判断这次判断和行为的质量。

企业要核验一条证据，不能只看内容本身。

至少还要看几个条件。

第一：来源

它来自正式业务系统、当前知识库、工具真实返回，还是模型自己生成的内容？

来源不同，可信程度和使用边界完全不同。

第二：时间和版本

一条规则在去年可能有效，在今天已经失效。

一份接口文档可能是真的，却对应旧版本。

没有时间和版本，真实资料也可能成为错误依据。

第三：适用范围

它适用于哪个客户、产品、地区、环境和权限范围？

很多判断并不是资料本身错了，而是适用对象错了。

第四：是否被实际采用

Agent 看过十份资料，最后可能只使用了其中两份。

企业需要知道哪些内容进入了判断，哪些被忽略，哪些被其他规则覆盖。

第五：支持与反对

证据链不能只记录支持结论的材料。

它还要保留反向证据，以及这些证据为什么没有改变最终判断。

第六：缺失和验证

当时还有哪些关键事实没有进入现场？

重要规则是否真正执行？

工具返回是否经过交叉验证？

如果缺失信息没有被标出来，企业看到的就可能是一条逻辑通顺、事实却不完整的证据链。

企业调查一次生产问题时，不能只问：

有什么证据支持这个判断？

还要问：

有没有证据反对它？

例如，一个客服 Agent 决定为客户自动退款。

支持它的事实可能包括：

客户等级符合补偿规则。

订单确实发生了超时。

但现场还可能存在两条反向证据：

这笔订单当天已经退款一次。

退款金额超过了 Agent 的自动处理边界。

如果系统只记录前两条，企业会得到一个看起来很合理的解释。

但真正决定这次行为是否可信的，恰恰是后两条有没有进入判断，以及为什么没有发挥作用。

真正可信的证据链，不只记录支持理由，也必须保留反向证据。

它应该同时保留支持、冲突、排除和缺失关系。

只有这样，企业看到的才不是一套理由，而是当时真实的判断条件。

出了问题以后，最简单的办法，是让模型自己解释：

你当时为什么这样做？

它通常能够给出一套完整、连贯，甚至很有说服力的答案。

但能说得通，不等于当时就是这样发生的。

模型事后生成的解释，可以作为调查线索，不能直接成为证据。

企业真正需要保存的，是运行时留下、可以独立核验的事实：

• 当时接到什么任务。

• 看到哪些信息。

• 采用了哪些规则和数据。

• 工具实际返回了什么。

• 哪些事实支持或反对判断。

• 执行过哪些验证和边界检查。

• 最终形成了什么判断，又对应了什么动作。

这也是可观测性在 AI 时代需要继续向前走的一步。

传统 Trace 主要记录请求和调用之间的关系。

行为链继续追踪任务、动作、状态变化和业务结果。

证据链则进一步把可核验的运行事实，与具体判断关联起来。

质量评估继续回答：这次判断到底好不好。

第 14 篇讲行为链。

它回答：

AI 到底做了什么？

这一篇讲证据链。

它回答：

AI 依据什么形成了这次判断？

证据链解释了一次判断为什么形成。

但企业最终还要回答另一件事：

这次判断，到底做得好不好？

这就进入了下一篇要讨论的内容：

有了 Agent Trace，为什么还要做 Evaluation（质量评估）？