AI Agent 可观测性与评测：从链路追踪到回归闭环

先说结论：Agent 上线之后，可观测性和评测不是可选项

很多团队把 AI Agent 的监控做成「看接口是否 500、看 P95 延迟、看 token 花多少钱」，这套做法在传统服务上成立，在智能体上基本失效。原因很直接：一次模型调用返回 200，不代表任务做对了。智能体可能顺利调了五次模型、四次工具，然后在第五步把订单号写错了一位，用户看到的是一句语气正常的回复和一份错的业务数据。反过来，一次调用返回超时，也可能只是下游工具抖动，而任务其实已经完成了。

2026 年 10 月的几件事把这条线的重要性顶到了台面上。OpenAI 官方弃用页面显示，其 Evals 评测平台已于 2026 年 6 月 3 日宣布弃用，2026 年 10 月 31 日现有评测变为只读，11 月 30 日控制台与 API 计划关闭，官方给出的迁移方向是 Promptfoo。这意味着评测能力正在从「某个平台的功能」变成「团队自己必须持有的工程资产」。同期，开源评测工具 agentevals 在 v0.10.0 中做了一次破坏性重写，放弃 WebSocket 摄入、改为原生 OpenTelemetry（OTel）上报，并直接移除了 openai_eval 评估器，理由正是 OpenAI Evals API 的关闭安排。

本文按这个判断，把智能体的可观测性与评测拆成五层：链路追踪、成功定义、分层打分、告警指标、回归闭环，并说明每一层的落地顺序、常见误区与行业差异。

---

一、为什么传统监控在智能体上会失效

1.1 一次请求变成一棵树，不再是一个点

传统服务的可观测对象是「请求」：进来一个 HTTP 请求，出去一个响应，指标是 TPS、错误率、分位延迟。智能体的执行过程天然是树形的：一次用户请求会展开成多个模型调用、若干次工具执行、可能还有检索和子智能体委派。agentpatterns.ai 在其标准整理中给出了一个典型结构——根 span 是用户请求，下面挂 invoke_agent（编排器），编排器下面挂 chat（模型调用）、execute_tool（文件读取）、以及一次 invoke_agent（子智能体交接），交接下面又有 chat 和 execute_tool。

这意味着三件事：

1. 只看端到端指标无法定位问题。总耗时 20 秒，可能是生成慢、检索慢、工具慢，也可能是模型反复规划了三轮。只有 span 级别的耗时才能区分。
2. 扁平日志无法重建执行路径。智能体在运行时决定调用哪个工具、走哪条委派路径，行为是非确定性的，靠应用日志事后拼不回来。
3. 成本是复利的。一个任务循环五次，token 就是五倍。缺了调用链，成本异常永远查不到源头。

1.2 遥测本身就是一笔账，不是免费的

agentpatterns.ai 指出，AI 工作负载产生的遥测量是传统服务的 10 到 50 倍，因为每次模型调用都会产生 token 级指标、提示与响应事件，以及嵌套的工具 span。存储成本随追踪深度线性上升，如果连完整的提示与响应体一起抓取，还会显著放大。

更麻烦的是合规风险。提示里往往带着用户数据。把原始的工具入参和模型提示内容不做脱敏就转发给可观测后端，在 GDPR、HIPAA 一类规则下会直接构成违规。微软在其 Foundry 追踪实践中的表述很明确：GenAI 可观测性应当提升可见性，而不是制造一份缺乏治理的敏感数据副本；提示词、模型输入输出、工具入参与结果、token 用量、错误这些遥测都可能敏感，需要施加访问控制、保留期限、脱敏与最小化。

所以「先全量抓再说」是一个常见的、代价很高的错误。

---

二、第一层：把每次运行记成一棵可读的树

2.1 用 OpenTelemetry 而不是某个厂商的私有格式

目前工程上比较务实的选择是按 OpenTelemetry 的 GenAI 语义约定（semantic conventions）打点。原因不是它功能最强，而是它把「一次智能体运行长什么样」变成了一份公开约定，避免被单个后端锁定。

新加坡政府 AI 工程博客（blog.ai.gov.sg）在其「Agent Wars」系列第三篇中把这套机制讲得比较清楚：如果智能体发出的是标准 OTel 遥测，那么换后端或者新增一个目的地，只是采集器的配置变更，而不是全团队的重新埋点工程。该博客同时强调了一件容易被忽略的事——语义约定本身才是关键。如果一个框架把 token 用量记成 llm.tokens.prompt，另一个记成 input_token_count，第三个记成 usage.in，那么遥测在纸面上是标准的，实际却不可用：每套看板、每条评测、每个告警都得为每个框架重写一遍，而任何跨框架的系统（这在真实智能体系统里是多数）都会在边界处断掉。

2.2 需要记录的关键属性

按 agentpatterns.ai 与 blog.ai.gov.sg 梳理的约定，下面这些是值得优先落地的：

属性	作用	优先级
gen_ai.operation.name	标明这个 span 是什么操作：chat、embeddings、retrieval、execute_tool、invoke_agent、create_agent、invoke_workflow、plan，以及一组记忆操作（search_memory、create_memory、update_memory、delete_memory）	必填
gen_ai.provider.name	服务方标识；gen_ai.system 已被它取代	必填
gen_ai.agent.id / gen_ai.agent.name / gen_ai.agent.version	标识是哪个智能体、哪个版本做的	强烈建议
gen_ai.conversation.id	把一次会话的多个 span 串起来	多轮场景必填
gen_ai.request.model / gen_ai.response.model	记录请求的模型与实际应答的模型——两者不总是同一个	建议
gen_ai.usage.input_tokens / gen_ai.usage.output_tokens	成本核算的最小单元	必填
gen_ai.tool.name / gen_ai.tool.call.id	标识工具调用，用 call id 区分「同一次逻辑调用的重试」与「一次新调用」	建议
gen_ai.evaluation.result	评测结果事件，带名称、分数与说明，让评估器把判定写回它评判的那条 trace，且用同一套词汇	建议

注意最后一行。它是「评测」和「可观测」能咬合起来的关键接口——评测结果不是躺在另一个看板里的数字，而是直接挂在产生它的那次执行上。

另外，gen_ai.operation.name 里的记忆操作值得单独留意。blog.ai.gov.sg 提到这一组是新增的，记忆的读写正在成为一等追踪对象。这一点在企业场景里尤其重要：一次错误回答可能来自过期的记忆，而不是一次糟糕的检索。如果两者混在一起记，你永远分不清该改知识库还是该清记忆。微软在 Foundry 的实践里也专门提出，追踪应当揭示回答究竟是被一次记忆读取、一次检索查询，还是两者共同影响的。

2.3 约定还在演进，要主动锁定版本

这是必须写进技术方案的一条。swfte.com 在 2026 年 10 月 6 日核对的资料指出，GenAI 语义约定当时已从主语义约定仓库迁出到独立的 GenAI 仓库，agent spans 页面仍标注为 Development 状态，意味着属性名仍可能变化。blog.ai.gov.sg 的建议是：锁定你采用的那个约定版本，把它记进遥测设计里，把升级当成一次有意识的变更，而不是某天升级依赖时被顺带带进来的。

工程含义是：自定义属性统一加一个你自己控制的前缀（比如 app.），避免和规范里的名字撞车；约定升级时跑一遍回归，看看板和告警有没有因为改名而静默失效。

2.4 工具 span 要记错误，但不能吞掉错误

工具是智能体触碰外部世界的地方，值得拥有独立 span。约定里定义了 execute_tool 操作：gen_ai.operation.name 设为 execute_tool，gen_ai.tool.name 为必填，有 call id 时建议带上。

关键动作是：工具失败时把 span 状态设为 error 并记录异常，不要把失败吞掉、返回一句文本给模型了事。一个安静失败然后被重试五次的工具，是死循环和成本飙升最常见的成因之一，也是事后最难查的一类问题。

同时，入参只记摘要，不记原始值。参数里经常就是客户数据。

---

三、第二层：先把「成功」写下来，再谈测量

3.1 成功定义必须来自你自己的系统

这是整套方法里性价比最高、也最容易被跳过的一步。andrew.ooo 在 2026 年 10 月 11 日核验的实践指南里给出的判断很直接：监控一个智能体意味着观察结果而不是请求；并且每个智能体在开始测量之前，就应该把「什么算成功」写下来。

它给出的成功信号示例，全部来自企业自己的系统，而不是模型评分：

智能体类型	成功信号
客服类	工单在没有转人工的情况下解决；7 天内没有重开
编码类	PR 被合并；CI 通过；14 天内没有回滚
调研类	回答中的每条主张都有支撑它的来源
预订类	在业务系统里创建出字段正确的预订记录

这四行的共同点是：硬信号。工单解决了、PR 合了、预订建成了，这些都能从你自己的系统里查到，不需要相信任何模型的判断。指南里那句「硬信号胜过裁判模型」是这一节的核心。

3.2 为什么不能只看最终答案

对智能体来说，只评最终输出是最危险的一种做法。factualminds 在其 2026 年 10 月的生产级智能体「harness 工程」一文中把话说得很死：Agent 评测集能捕捉行为回归，但它替代不了那些确定性检查；单元测试、集成测试、类型检查、策略校验、schema 校验、迁移演练、业务规则（订单状态、金额、归属）以及高影响变更的人工确认，仍然要留在系统里。第二个模型只是另一个意见，当评分标准含糊时，它和第一个模型共享失败模式。

那么评测该看什么？分解执行轨迹本身。可观测平台应当能回答：这个智能体从上百个可用工具里是否选对了工具；如果它调用了错误的查询函数，评测指标应当记录一次「工具选择失败」，从而精确定位逻辑断点。这样工程侧才知道该改系统提示、该换模型路由，还是该改工具 schema，而不必整体重训。

---

四、第三层：分层打分，不要只用一种裁判

4.1 四类评分及其成本

Braintrust 的解决方案工程师 Doug Guthrie 在 2026 年 10 月的 AI Engineer 工作坊上展示了一套完整流程（据 Skala Blog 对该工作坊的记录）。他使用的四类评分，成本特征差异明显：

评分类型	做什么	成本特征
代码评分	用代码校验 schema、工具调用顺序、分支逻辑	快、便宜，不调用模型
LLM 裁判	对一条 trace 或 span 施加主观标准	每条被评 trace 消耗模型算力
人工复核的裁判	用人工标注校准 LLM 裁判	增加评审开销
代码包裹 LLM	先用代码表达分支逻辑，再调用模型	混合

还有一个操作细节值得记下来：界面里不支持评分链式依赖。如果评分 B 需要依赖评分 A 的结果，得写一个代码评分，由它条件性地调用模型并返回一组评分对象。

4.2 裁判模型不要用生成同一个模型

这是 andrew.ooo 那份指南列出的常见错误之一，也是最容易犯的一个：用产生答案的同一个模型来评判这个答案。正确做法是换用不同模型家族，或者干脆用代码检查。

Guthrie 的补充建议是，裁判用的模型通常应该比生成用的模型更强，但要注意在线评分会改变成本结构。他的另一条经验来自客户对话：从二元评分开始，并且要严。如果你在每一项评测上都拿到 100%，那基本说明测试用例太弱了。

4.3 用主题聚类覆盖「未知的未知」

评测只能覆盖你已经知道的失败模式。Guthie 在工作坊里演示的 Topics（主题聚类）机制是针对这一点的补充：它对 trace 做聚类，包含那些事实性和合规性评分都漏掉的静默失败。

据其记录，工作坊导入的 968 条 trace 暴露出一次订单记录检索失败，而当时没有任何内置评分标记出它。这条细节比任何抽象论述都有说服力——它直接证明了「评分体系覆盖不了什么」。

该机制的运作分几步：默认预处理器把 trace 压缩成对话来回，facet（分类提示词）对其做摘要，摘要被嵌入，嵌入向量构成主题地图，用于给 trace 打标签和分类；内置 facet 覆盖任务、情感、问题三类，自定义 facet（比如工作坊里的「客服流程问题」提示词）可以定向捕捉特定失败族，并用正则排除「没问题」的输出。

两个操作性约束要提前知道：摘要与嵌入两步只跑 Braintrust 托管的模型，厂商称换用其他模型产出的主题质量不佳，因此这一点是强制的；Topics 至少需要 100 条匹配 facet 才会生成聚类，工作坊里内置的 issues facet 在演示数据上从未跨过这个阈值，Doug Guthrie 把这当特性而非缺陷来讲。

关于成本，厂商公布的托管管线价格是每百万输入 token 0.06 美元、每百万输出 token 0.40 美元。Guthrie 提到 Dropbox 曾试验用 Topics 替换一部分 LLM 裁判的分类评分，以更低成本覆盖大得多的 trace 量——这是厂商转述的客户案例，不是独立研究。

还有一个访问控制上的做法值得借鉴（来自该工作坊问答）：把 trace 写进一个受严格限制的项目，让自动化流程用服务账号运行，只把产出的分析和 PR 分享出来，这样评审者看到的是结论，而不需要接触原始 trace。

---

五、第四层：告警要挂在用户能感知的指标上

5.1 一组够用的核心指标

andrew.ooo 那份指南给出的指标表，以及它对每一项「为什么重要」的说明，可以直接作为起点：

指标	为什么重要
任务成功率	用户真正感知的那个数
单个完成任务的成本	智能体会循环，token 是复利的
每任务的步数 / 工具调用数	循环或困惑的早期信号
工具错误率	接口挂了、参数错了
转人工率	隐形的失败模式
P95 延迟	上游超时

这六项里，任务成功率和单个完成任务的成本是唯二必须先做的。前者回答「这东西有没有用」，后者回答「这东西能不能持续跑」。步数与工具调用数是循环的早期信号，配合一个硬性上限使用效果最好——factualminds 的做法是在运行时设置里设迭代上限、截止时间、token 预算、并发数和取消机制；记录「触顶」这个事件本身就是后续循环告警的依据。

5.2 每条 trace 都要打版本标签

没有版本标签，就无法判断「这次改动是不是把成功率弄崩了」。andrew.ooo 把它列为常见错误之一：应该在每条 trace 上打上提示词版本、模型版本和代码版本，让一次回归能指向具体的原因。

这一条和第二节里的 gen_ai.agent.version 是同一件事，只是粒度不同——前者要求把提示词与代码的版本也纳入，而不只是智能体本身的版本号。

5.3 采样策略：新系统从高往低

采样率直接决定成本，这一点在多个来源里被重复强调。工作坊里三个 LLM 裁判（沟通质量、支持解决度、工具使用质量）以 100% 采样运行，Guthrie 明确提示采样率直接驱动模型成本，因为裁判跑在你自己配置的模型上。他的建议是：新智能体从高采样起步，等已知失败模式稳定后再往回降；对于分类型的 LLM 裁判，可以考虑用主题聚类作为更便宜的替代。

andrew.ooo 给了更具体的一档：常规流量采样 5% 到 20%，而高风险流程 100% 覆盖。并且有一条不能妥协的例外——所有转人工和用户投诉必须 100% 打分，只采happy path 是最常见的错误之一，因为它恰好漏掉了最该看的部分。

---

六、第五层：把生产失败变成回归用例

6.1 评测套件是「可执行的行为规格」

factualminds 把这件事讲得比较完整。传统软件团队保存的是：需求、代码、测试、文档。而 AI 团队应该越来越多地保存：行为需求、评测数据集、评分规则、阈值、失败用例、评测结果。

两者的转化链条是：

`` 业务需求 → 行为需求 → 评测用例 → 评估器 → 验收阈值 → CI/CD 门禁 ``

这条链的价值在于，它把「AI 的行为」变成了一件可以被评审、被治理的东西。这一点尤其重要，因为 AI 的行为很难只靠实现细节来完整描述。

6.2 一次生产故障的完整转化路径

给一个具体形态。假设有用户反馈「助手告诉我我的保单覆盖了某个除外责任」。正确动作不是直接改提示词，而是走完这条链：

`` 生产故障 → 根因分析 → 建成回归用例 → 加入评测数据集 → 修复系统 → 跑全量评测 → 部署 → 监控 ``

其价值随时间累积：评测套件会变成这套 AI 系统失败史的制度化记忆。这是相对于临时测试的根本优势——临时测试跑完就忘了，而回归用例每次发布都在守门。

6.3 分层检查，不要指望一个分数

factualminds 给出的护栏分层值得参考，因为它把「四层」和「谁强制执行」绑在了一起：

层	例子	由谁强制
行为	输出格式、拒答主题、任务上限	提示词加最终消息的 schema 检查
数据	PII 脱敏、保留期限、租户隔离、可展示范围	应用代码与 trace 接收端
工具与动作	白名单、参数约束、先起草后提交、审批	工具执行器、IAM、网关
运行	迭代上限、截止时间、token 预算、并发、取消	运行时设置或循环计数器

这张表里最反直觉也最重要的一行是第二行：提示词不做脱敏。脱敏是应用代码和 trace 接收端的职责，不能指望模型自觉。

还有一个容易被忽略的失败模式叫「上下文腐烂」（context rot）——长上下文窗口下，指令其实还在记录里，但模型已经不再按它行事。factualminds 提到 OpenAI 那个失败的百科全书文件是这个现象干净的公开例证。压缩与摘要（AgentCore 的 sliding_window 或 summarization、Strands 的 offload 与 compact 都会做这件事）可能把关键的一行丢掉，除非你在摘要之外把它固定住。

相应地，可观测的记录范围应该是：运行 id、任务 id、模型 id 与配置、工具名、脱敏后的参数、结果或错误、延迟、重试次数、上下文截断、记忆命中、验证器结果、人工决策、token 计数和最终结论。跳过原始提示、完整客户载荷和密钥——把所有东西都塞进 trace，等于凭空造出第二个需要你保护的数据存储。

6.4 失败分类才是改进的入口

factualminds 的做法是把失败分类，例如一百条失败里有多少属于检索、多少属于提示、多少属于模型、多少属于工具使用、多少属于数据质量、多少属于安全。有了这个分布，工程才知道该把力气花在哪。Techment 对评测驱动开发的整理也指出了同一件事：只优化单一分数会让严重失败被平均分掩盖，应当分维度跟踪，并给关键错误设独立的门禁。

6.5 别把评测当一次性基准

Techment 把「评测应贯穿生命周期」列为一类典型错误，理由值得展开：AI 应用在上线之后仍会持续变化——用户行为变了、检索数据变了、文档变了、模型升级了、提示词演进了、工具 API 变了、外部系统变了，新的失败模式会不断出现。因此上线前评测 + 生产监控 + 持续评测应当构成一个统一的质量闭环，而不是三件孤立的事。微软的当前指引同样把生命周期分成模型选型、上线前评测、上线后监控三个阶段，其中包含对生产行为的持续或定时评测。

---

七、分行业差异：同一套方法，不同的重心

方法论是通用的，但投入的优先级应该按行业风险调整。以下是按行业给出的侧重建议，属于工程判断而非既有结论：

行业	首要目标	需要额外覆盖的检查
政务监管	可复现的证据链	保留可回放的决策依据：契约版本、模型 id、工具目录版本、检索到哪几份文档；不需要保留完整提示正文（这一点与我们在政务监管系统的指标口径治理中的主张一致——口径要能追溯到来源）
医疗健康	隐私与召回	遥测脱敏强制在应用层；错误答案需区分来自记忆还是检索；转人工与投诉 100% 打分
零售电商	幂等与重复动作	重试前必须回答「上一次调用是否已经改变了远端状态」；工具 span 需要能证明写入的是正确的业务对象，而不是「工具返回了 200」
集团企业	多组织边界	trace 要带组织作用域；权限判定在模型外完成，与我们在企业后台权限模型设计中的主张一致
客服与内容	兜底与转人工	转人工率是一等指标；空态与拒答路径也要进评测集，而不是只测「能答对什么」

关于最后一行，可以参考我们在AI 客服的能力边界与兜底设计中的分析：难的不是答得像人，而是知道什么时候不该答。评测集必须包含「应该拒答」和「应该转人工」的用例，否则跑分再高也不代表能上线。

---

八、落地顺序：六步走完，不必一次到位

按收益与依赖排序，给出一条务实路径：

1. 打上追踪。 先按第二节的属性清单把 span 落下来，锁定 OTel 约定版本，自定义属性加 app. 前缀。这一步不依赖任何评测框架，做完之后排障能力就有质变。
2. 写成功定义。 每个智能体写 3 到 5 条来自自己系统的硬信号。这一步只需要一次会议，不需要写代码，但决定了后面所有工作的方向。
3. 上确定性检查。 先做代码评分：JSON 是否合法、必需工具是否调用了、禁用工具是否被碰了、成本是否超预算。这一层不花模型钱，而且能拦住最粗放的问题。
4. 接入 CI 回归。 收集 20 到 50 条真实用例作为黄金集（golden set），含边界、歧义与历史失败。每次提示词、模型、检索、工具变更都跑，用结果对比上一次运行，超过阈值就卡住发布。
5. 开在线评分。 常规流量采样 5% 到 20%，高风险流程和所有转人工、投诉 100%。裁判先用小模型试水，校准到人工标注一致再上比例。
6. 建立飞轮。 低分 trace 人工标注 → 转成回归用例 → 进数据集 → 定期重跑。这件事本身不难，难的是坚持。factualminds 在这一点上的提醒值得照抄：验证器失败时要存下失败与证据、指名原因、提一个窄改动、人工复核、加回归测试、在有代表性的集合上跑而不是只跑那一个case——这套流程叫 harness 维护，除非你真的训练权重，否则它不是微调。

关于预算，与我们在大模型调用成本怎么控制中的建议一致：评测本身也是模型调用，把它算进成本分档里，别当成「免费的质检」。在分层评分里用代码评分兜住格式与安全类检查，只把真正主观的判断交给模型裁判，这条路比「全部交给 LLM 裁判」省得多。

---

九、常见误区清单

汇总一份可对照检查的清单：

1. 只监控延迟和错误码。 智能体可以返回 200 加一个错误答案。
2. 用生成答案的同一个模型当裁判。 换模型家族，或改用代码检查。
3. 不打版本标签。 提示词、模型、代码版本缺一不可，否则回归无法定位原因。
4. 只采样 happy path。 转人工与用户投诉必须 100% 打分。
5. 只评最终答案，不看执行轨迹。 对智能体而言这是最危险的一种做法。
6. 原始提示与工具入参不做脱敏就上报。 提示词不做脱敏，脱敏是应用代码与 trace 接收端的职责。
7. 一开始就全量抓取。 遥测量是传统服务的 10 到 50 倍，先定采样、保留期限与最小必要字段。
8. 把评测当成一次性基准。 上线前评测、生产监控、持续评测应当是一个闭环。
9. 只优化单一分数。 平均分会掩盖严重失败，需要分维度跟踪加关键错误门禁。
10. 用通用基准代替任务评测。 模型在榜单上表现好，不代表它在你的业务流程里不出错。这也是我们在提升知识库问答准确率里强调分环节评测的同一个道理——通用指标回答不了「这个系统在你的场景里行不行」。
11. 不考虑评测资产的可迁移性。 OpenAI Evals 平台 10 月 31 日只读、11 月 30 日关闭就是一个提醒：把用例、参考答案、评分规则和历史结果放在自己掌控的版本控制里，迁移是重建而不是考古。
12. 把可观测平台的默认配置当成安全配置。 factualminds 特别提到，不同平台在「抓取多少内容」上的默认值并不一致，而这些默认值直接带来隐私、治理和证据连续性风险。

---

结语

智能体的可观测性与评测，和传统软件工程里的可观测性与测试，本质上是同一件事在新形态下的重演：你无法管理一个你看不见的过程，也无法守住一个你没有测过的边界。差别只在于被观测的对象从「请求」变成了「一棵树」，被测量的对象从「输出」变成了「结果加上产生它的过程」。

值得强调的是，这套东西不需要一次建完。第一层追踪和第三层的代码评分加起来，通常一两周就能落地，却已经能解决大部分排障问题。剩下的可以按上面第六节的顺序慢慢补。

对于希望先把基础能力建好的团队，我们的人工智能应用开发与软件研发服务会从链路设计与质量体系开始；关心评测体系如何与内容生成链路结合的，可以看AIGC 内容生产线的工程化实践；想了解评测指标中最容易出问题的那一环——检索召回——可以参考提升知识库问答准确率的工程手段；对模型选择与成本权衡有疑问，大模型调用成本怎么控制与大模型私有化部署的决策要点两篇讨论了不同前提下的取舍。

技术方案与实现细节，可参考我们的技术能力与工程交付说明；行业方案的适配差异，可查看行业方案或常见问题。