Agent 上生产后判断不出对错：缺的不是日志，是评估链路

某电商客服智能体上线第三周，运营报的自助解决率是 78%，质检抽样只有 41%。两批数据取自同一段会话，差别只在口径：前者数"会话是否正常结束"，后者数"用户的问题是否真的被解决"。团队为对齐这个口径花了四天，四天里问题单还在涨。

日志、指标、调用链都齐了，为什么还是答不出"它做对了吗"

传统可观测三件套建立在一个隐含假设上：失败会报错。接口超时、返回 5xx、进程崩掉，都能被捕获。

智能体的失败大多是静默的。工具调用返回 200，参数结构合法，token 消耗正常，链路完整无断点，但答案是错的——查了订单表却引用了另一个账号的记录，或者把"退款申请"理解成"取消订单"。这类事故不产生任何 error 日志，监控面板全绿。

这也是为什么大量试点停在验收这一步，而不是停在模型能力上——95% 的 AI 试点进不了生产，卡点常在验收，而验收最依赖的就是这条平时看不见的链路。

蚂蚁集团可观测技术架构师刘杨在 QCon 上海 2026 的分享里把问题说得很直接：随着智能体进入真实业务，传统日志、指标和链路追踪已经难以完整回答三件事——任务是否正确完成、问题出在哪个环节、质量如何持续衡量。他给的解法是建一套企业级的可观测与评估体系，而不是继续往看板上堆面板。

第一步不是买工具，是统一埋点语义

评估链路的上游是采集。蚂蚁在采集层的做法是遵循 OpenTelemetry GenAI 语义约定，把模型调用、工具调用和智能体执行过程用统一字段埋下来。需要注意的是，这份规范在 2026 年 9 月已标注迁移（Moved），当前语义约定版本 1.44.0 中仍能看到 agent spans、MCP、Anthropic、OpenAI 等分组，接入前建议先确认版本与字段的对应关系。

落地时不必一上来对齐全套字段。我们给客户交付时先钉住三样：

1. 任务 ID。一次用户意图从入口到结束的全部模型调用、工具调用、重试都挂在同一个 ID 下。缺了它，跨服务的调用链根本拼不起来。
2. 工具调用的输入摘要与结果状态。只记"调用了 search_orders"没有意义，要能回答：传了哪些参数、命中几条、结果是否为空。
3. 用户原始意图。评估环节做关键信息提取时，必须能回到用户最初那句话。只能对着模型自己的复述做判断，等于让被告当证人。

这里有个我们踩过的坑。最早一个项目先花两周做看板，把 P95 延迟、token 成本、工具失败率都拉了出来，等到要接评估任务才发现 span 里没有原始意图字段，只能回头改埋点、重放历史流量，等于付了两遍成本。字段设计必须排在评估设计之前。

重试与副作用属于同一层的问题，我们之前在 超时、重试与副作用 那篇里单独拆过，这里不重复。

把调用链从"出事才查的数据"变成"持续运行的评估对象"

蚂蚁方案里第二个转变更重要：调用链不再只是排障时的日志，而是评估任务的输入源。整条链路分五段——span 聚合、评估任务筛选、关键信息提取、评估执行、结果沉淀。

其中"配置化"是省人力的关键。用声明式表达式描述"哪些链路需要评估、从哪些字段提取、交给哪个评估器"，新增评估场景不必修改智能体埋点，接入新智能体也只是写一套表达式去适配它的链路结构。对同时维护三五个业务智能体的团队来说，这决定了评估能不能规模化。

两阶段评估：让全量覆盖的账单降下来

全量评估的直觉做法是把每条链路都丢给大模型裁决。日调用几千次的业务，这条路的账单很快会超过项目本身的开发预算。

更实际的做法是两阶段：先用轻量小模型做全量、低成本的粗筛保证召回，再把候选链路按需加载完整执行上下文，交给大模型做精准语义裁决。按分享中的口径，这套机制能把 token 成本降低约 90%，使安全、合规这类底线指标的评估得以覆盖全量生产流量。

代价同样要说清楚。两阶段强依赖一个有效的小模型，而小模型需要针对业务场景训练才能做好过滤，训练与调优成本不低；要做到从业务链路深入到推理引擎内部的跨层分析，还得在推理引擎侧额外埋点，接入成本是实打实的。

评估策略	覆盖范围	单条成本	主要问题
人工抽样	千分之几	高（人力）	覆盖低，回归周期以周计
大模型全量裁决	100%	高（算力）	底线类指标跑不起全量
小模型粗筛 + 大模型精筛	底线类可全量	约为全量裁决的十分之一	依赖业务域小模型，需持续训练与校准

顺带一提，同一周 KubeCon 中国场的讨论指向了更下面一层的变化：调用基础设施的主体正从人扩展到智能体，Kubernetes 正在通过 DRA 等插件机制适配异构算力。等智能体开始自己申请资源、改实例数，可观测的对象就不只是业务链路，还包括它对外部系统做了什么。

评估自己也会骗人：同一个系统，26% 和 86% 两个结论

把评估当成工程制品之后，还剩一个坑：评估本身会失真。

2026 年 9 月 15 日，安全研究团队 Trail of Bits 发文批评 1Password 在 8 月 6 日发布的 FLAWED 报告（原文与其复核数据）。那份报告的标题结论是：模型只在 26% 的情况下给出"干净修复"。该团队复核代码与数据后，指出四个设计选择让这个数字严重偏离常规修复场景：

1. 样本是按"修复复杂"挑出来的六个漏洞，样本内干净修复率从 3% 到 60%，均值高度依赖选了哪几个漏洞。
2. 两组提示词直接要求智能体套用错误修复，这部分占全部数据的 22%。
3. 超过三分之一的试验禁止编译或运行代码，占 36%，却被合并进同一个头条数字。
4. 两个模型跑在不同推理档位（GPT-5.5 用 medium、Opus 4.8 用 high，都是工具默认值），且没有测最高档的影响。

按"允许运行代码、且没有被喂错方向"这批试验重算，3067 个补丁里有 2634 个（86%）挡住了给定的漏洞利用代码。该团队也明确说明，挡住给定 exploit 不等于完整修复——但 26% 与 86% 的落差说明，评估口径对结论的影响，远大于被测对象之间的能力差异。

判定层的问题更值得记下来：报告里自动评分与人工复核在五类完整结论上的一致率是 65.9%；两个评审模型对同一批补丁有 36.8% 给出了不同结论；作为参考的 Linux 修复本身带一个 off-by-one 错误，248 个补丁重复了它，自动评分只抓到其中 24 个。

翻译成工程要求就三句话：口径（哪些试验算数）、评审人（人或哪个模型、什么推理档位）、一致率（自动评估与人工复核的实测吻合度），这三样必须写进评估卡。缺了它们，任何百分比都不适合拿去做上线决策。

LinkedIn 把多智能体代码审查搬进产线时也绕不开同一件事：模型判断要进流程，就得先把一致率量化出来。

我们交付时按这个顺序走

1. 先写出"做对了"的判定句。一句话讲清某个场景下什么算完成。写不出来的场景，先别开评估——这类判断力目前比模型更稀缺，能判断 AI 答案对不对的工程师，缺口比算法岗位更大。
2. 再补字段。按语义约定把任务 ID、工具调用摘要、原始意图三类字段埋齐，用历史流量重放验证一遍能否拼出完整链路。
3. 从 100 条人工标注起步。最容易出错和最容易做对的两端各挑 50 条，人工打标作为基线。不要等评估器上线了再回头补标注。
4. 先上粗筛，再扩覆盖。用规则或小模型把明显正常的链路过滤掉，只让可疑链路进精筛，成本可控之后再把覆盖面拉满。
5. 把评估结果接回研发流程。按链路维度做灰度门禁：改动前后跑同一批评估集，不通过不全量。
6. 每月校准一次评审一致性。抽 50 条人工复核，测出自动评估与人工的一致率。一致率下滑时先查评估器，别急着查业务。

常见问题

团队没有专职可观测工程师，最小可行方案是什么？

先用现成 SDK 把任务 ID 打通，挑 3 个业务指标做人工标注基线，评估任务跑在离线脚本里也够用。真正的门槛不是工具，而是那句"什么算完成"的定义。

链路采样率怎么定？

按犯错成本分。安全、合规、资金相关建议全量，其余按需采样。筛掉一条违规链路和筛掉一条慢链路，代价完全不对称。

小模型粗筛准确率不够怎么办？

先接受它会漏判，把它当召回工具而不是裁判：阈值宁松勿紧，宁可多送一些给大模型，也不要把问题链路筛掉。等到标注数据积累起来，再针对性微调。

直接让大模型当评审可靠吗？

可以，但必须测一致率。上面那份复核里，两个评审模型对同一批补丁有 36.8% 的结论分歧——评审模型本身就是变量。模型名、推理档位、提示词版本要跟评估结果一起存档。

参考

• 从 Trace 到规模化实时评估：面向生产流量的 Agent 可观测实践（QCon 上海 2026）
• OpenTelemetry Generative AI semantic conventions
• 1Password's AI patching benchmark is misleading — Trail of Bits, 2026-09-15
• Agent 开始调用基础设施，Kubernetes 准备好了吗（KubeCon 中国 2026）

我们在 蓝曜炬辉（www.lanyaoai.com）做企业智能体交付时，把这套顺序写进了项目验收：埋点字段和评估集不齐，工程不进灰度。如果你的团队正卡在"上线后不知道它做得对不对"，可以把一段脱敏的调用链样例发给我们做一次口径评审，或者先翻我们已交付的智能体项目记录。