大家好，我是金全。

上一篇讲证据链。

我们讨论的是，企业怎样基于运行时事实，还原并核验一次判断为什么形成。

但判断依据说清楚以后，还有一个问题没有解决：

这次行为，到底做得好不好？

还是以“修复登录接口偶发超时”为例。

Coding Agent 接到任务，读取代码和运行日志，定位认证模块，调整重试配置，运行测试，最后提交代码。

整个过程都有 Trace。

文件读取成功。

命令执行成功。

测试通过。

代码也顺利合并。

从单个步骤看，似乎都没有问题。

但代码上线以后，登录超时仍然存在。

因为真正变慢的，是下游数据库连接。

这时企业面对的就不是“有没有记录”，而是另一个更现实的问题：

每一步都成功，为什么整件事还是失败了？

这正是质量评估要回答的问题。

Agent Trace 很擅长记录一次运行经过了哪里。

• 哪个 Agent 接到了任务。

• 调用了什么模型。

• 读取了哪些文件。

• 执行了什么工具。

• 哪一步耗时更长。

• 哪个接口返回失败。

这些事实，是分析 AI 运行现场的基础。

但 Trace 不会自动告诉企业：

• Agent 是否真正理解了任务。

• 工具是不是选对了。

• 中间判断是否合理。

• 规则和边界是否得到遵守。

• 最终有没有解决业务问题。

所以我越来越觉得：

Agent Trace 很完整，不等于行为质量已经清楚。

Agent Trace 记录运行事实。

行为链把这些运行事实组织成一次完整行为。

质量评估（Evaluation）再进一步判断：这次行为到底做得怎么样。

很多企业开始讨论 Evaluation（质量评估）。

但真正发生变化的，不只是多了一种评分能力。

AI 的质量，不属于某一个步骤，

而属于一次完整行为。

传统软件测试，经常可以围绕一个明确结果展开。

接口返回是否正确。

计算结果是否一致。

响应时间是否超过阈值。

Agent 不一样。

它完成一个任务，往往要经过任务理解、信息获取、判断、工具调用、人工介入和业务系统操作。

某一次模型回答可以是正确的。

某一次知识检索也可以命中正确资料。

每一个工具调用都可能返回成功。

但这些步骤连接起来以后，整件事仍然可能失败。

反过来也一样。

Agent 中间可能走过弯路，调用过一个不合适的工具，甚至第一次尝试失败。

但它及时修正，最终完成了任务，也没有突破业务边界。

如果只盯着某一个步骤，这次行为可能被判为失败。

如果看完整过程，它又可能是一次可以接受的成功。

企业最终要评估的，不是一次模型调用，也不是一个 Span。

而是一个任务从开始到产生业务结果的完整过程。

很多人一提 Evaluation，首先想到的是一个分数。

正确率 92%。

相关性 0.86。

任务完成度 80 分。

分数当然有价值。

但企业真正关心的，不只是分数高不高，而是这个分数代表什么。

一次完整 AI 行为的质量，至少要从四个方面看。

第一：结果质量。

最终答案是否正确？

生成的代码是否可用？

业务对象是否被正确处理？

第二：行为质量。

选择的工具是否合理？

执行顺序是否正确？

遇到失败以后，重试、调整和人工介入是否合适？

第三：边界质量。

它是否遵守权限、规则和审批要求？

有没有执行不该执行的动作？

应该人工确认的时候，是否真的停下来等待？

第四：业务质量。

任务是否真正完成？

客户问题是否得到解决？

业务状态是否按照预期发生变化？

有没有带来新的风险、返工或者额外成本？

这四个方面可能得出完全不同的结论。

一段回答可以很准确，但客户问题没有解决。

一段代码可以通过测试，但生产故障仍然存在。

一个工具调用可以成功，但业务动作本身不应该发生。

所以，质量不是一个结果，而是对一次完整行为的多维判断。

行为质量是多维的，因此企业也不可能依赖一种评估方式。

明确的格式、权限和数值边界，可以由规则直接检查。

有标准答案的任务，可以与参考结果比较。

代码能不能运行，可以交给编译、测试和安全扫描。

业务结果是否发生，要回到真实业务系统核验。

复杂场景是否符合业务常识，仍然需要人工复核。

LLM-as-a-Judge 可以帮助企业评估相关性、完整性、事实依据和表达质量，但它也不是最终裁判。

模型裁判可能受到提示词、模型版本和上下文影响。

规则可能已经过时。

人工判断也可能不一致。

因此，企业需要的不是寻找一个万能评估器，而是组合不同的评估信号。

企业最终相信的，不是某一个评估器给出的分数。

而是多个评估信号、运行事实和业务结果共同支持的质量判断。

这也意味着，评估器本身同样需要被校准。

它与人工判断是否一致？

对同类任务能否保持稳定？

有没有频繁误报或者漏报？

规则和参考答案是否仍然适用？

如果评估标准本身不可靠，再精确的分数也没有意义。

假设一个 Agent 的任务完成度从 90 分降到 75 分。

这个数字可以触发告警。

但它还不能帮助企业解决问题。

企业接下来需要知道：

• 是哪个任务类型开始下降？

• 哪个 Agent、模型或者工作流版本产生了变化？

• 问题出在任务理解、知识检索、工具选择，还是最终动作？

• 当时采用了哪些判断依据？

• 低分是否真的造成了客户投诉、业务失败或者人工返工？

如果质量分数不能回到具体 Trace、证据关系、版本和业务结果，它就只是另一个孤立指标。

企业真正关心的，从来不是一个低分，而是为什么得到这个分数。

这也是质量评估必须进入可观测性体系的原因。

它不能停留在一份测试报告里。

它需要和运行现场连接起来，让企业从分数继续追到任务、行为、依据和后果。

Agent 真正进入生产以后，面对的任务、用户表达、业务状态和异常组合，永远比测试集更复杂。

一个上线前表现很好的版本，在线上也可能因为知识更新、工具变化、上下文漂移或者任务分布变化而出现质量下降。

所以，线上质量评估首先要回答：

• 真实任务中的行为质量是否稳定？

• 哪些问题正在增加？

• 哪些低质量行为已经影响业务？

• 哪些现场应该进入人工复核？

行业也正在把评估结果与 Trace、延迟、成本、错误和用户行为放在一起，让低质量从一份离线报告变成可以查询、分析和告警的运行信号。

但线上评估不是为了替代上线前评估。

上线前仍然需要用固定数据集和明确标准，对比模型、Prompt、工具、工作流和 Agent 版本，发现回归，决定一个版本能不能发布。

两者不是替代关系，而是回答不同的问题。

上线前评估回答：

这个版本能不能进入生产？

线上评估回答：

它进入真实运行以后，是否仍然做得足够好？

回头看前面讨论的内容，我越来越觉得，企业要看清一次 AI 运行，至少要回答三个问题。

行为链回答：

发生了什么？

证据链回答：

为什么这样判断？

质量评估回答：

这次行为做得怎么样？

它们共同组成了 AI 运行现场的三个观察面：

三者必须围绕同一次 AI 行为关联起来。

只有这样，企业才可能进一步回答：

哪些 Agent 可以进入生产？

哪些任务可以继续交给它？

哪些行为需要人工接管？

下一篇，我想继续讨论：

到这里，我们讨论的仍然是如何看清、解释和评价 AI。

当 AI 的运行现场已经能够被还原、核验和评估以后，Agent 真正进入生产，还缺什么？

#AI系统 #AI可观测性 #因果AI #AgentOps #AI运行系统

行业参考：OpenAI Trace Grading、Datadog Trace-Level Evaluations、LangSmith Evaluation、Dynatrace dt-evals。