Agent 上线后怎么知道它坏了：可观测与评测的实操方案

Agent 的失败不报错，这才是麻烦

传统服务的失败是异常、500、超时——监控能看到。
Agent 的失败长得像成功：HTTP 200、返回了一段通顺的话，但答案是错的、绕了 7 步才做完本来 2 步的事、花了 20 倍 token。

所以 Agent 的可观测要回答三个问题：

它做了什么？（Trace）
做对了吗？（评测）
变贵/变慢了吗？（成本与延迟）

一、必须埋的 8 个指标

指标	为什么重要	报警阈值参考
任务成功率	最终目标达成率（需人工定义判定）	环比下降 >5%
平均步数 / P95 步数	突然变多说明在绕路或循环	P95 > 上限的 80%
工具调用成功率	单工具失败率定位到具体依赖	单工具 <95%
工具误调用率	调了不该调的工具（抽样人工标注）	>5%
每任务 token 消耗	成本核心指标	环比上涨 >20%
端到端延迟 P95	用户体验	> 业务容忍值
重试率	高重试意味着输出不稳定	>5%
循环拦截次数	触发 max_steps 的次数	>1%

最容易忽略的是「步数」和「循环拦截」——它们能在成本和延迟爆炸之前先报警。

二、Trace 的最小数据结构

一次任务 = 一个 trace，每一步 = 一个 span。

{
  "trace_id": "t-9f3a",
  "task": "查订单A1并告知物流",
  "started_at": "2026-10-27T09:00:00Z",
  "steps": [
    {
      "step": 1,
      "thought": "需要先查订单",
      "tool": "query_order",
      "args": {"order_id": "A1"},
      "result_ok": true,
      "result_size": 218,
      "latency_ms": 420,
      "tokens": {"in": 1180, "out": 46}
    }
  ],
  "outcome": "success",
  "total_steps": 3,
  "total_tokens": 3900,
  "user_feedback": null
}

四个必记字段容易被省掉，但排查时最有用：

result_size：结果多大→是否该截断
latency_ms 按工具拆：定位是模型慢还是依赖慢
thought：Agent 走偏时，从 thought 能看出它在想什么
outcome：人工/自动判定的最终结果，这是评测的原材料

三、三种离线评测方法

1. 结果断言（最可靠，适用于可判定任务）

CASES = [
    {"input": "查订单A1的物流", "expect": {"status": "shipped", "carrier": "SF"}},
    {"input": "帮我退款B2", "expect_error": "not_found"},
]

跑一遍，断言关键字段。能写成断言的任务一定要写——它比任何主观评分都可靠。

2. 轨迹评测（评过程，不只评结果）

不只问「答案对不对」，还问「路径是否合理」：

检查项	不合格示例
是否调用了必要工具	没查订单就回答物流
是否调用了多余工具	查了 4 次同一订单
步数是否超标	2 步的任务用了 7 步
是否越权	调用了写操作工具

轨迹评测能抓出「结果侥幸正确但过程有问题」的情况——这类问题下次就未必侥幸了。

3. LLM 评审（主观任务，需谨慎）

用另一个模型给输出打分。能用的前提：

给明确的评分细则（不要「1-10 分打一下」）
成对比较优于绝对打分（A/B 哪个更好，比单独打分稳定）
必须人工抽检校准，否则等于用一个模型的偏见替代另一个

四、20 条样本的起步评测集

不用一开始就做几百条。20 条精心设计的样本能抓住 80% 的问题：

类型	数量	设计要点
典型正常路径	6	覆盖主要功能的真实请求
边界值	4	空输入、超长输入、特殊字符
歧义输入	3	该追问而不是猜的情况
依赖失败	3	工具超时/报错时的行为
越权/注入	2	要求做禁止操作、输入里藏指令
知识边界	2	问它不知道的事，看是否编造

每次改 prompt、换模型、升级版本，都跑这 20 条。没有评测集的所有"优化"都是玄学。

五、上线后必做的三件事

抽样人工复盘：每周抽 20 条真实 trace 人工看，标出问题类型。这是唯一能发现「新型失败模式」的方法
失败样本回流：把线上失败案例加入评测集，让它不再复发
版本对比：模型版本、prompt 版本、工具版本都要记录在 trace 里，出问题才能归因

六、成本与延迟的联动监控

Agent 的成本异常往往是「行为异常」的副产品：

单任务 token = 步数 × 每步上下文
每步上下文 ≈ system + 历史消息（会累积） + 工具返回

历史消息累积是隐形炸弹：第 8 步时，前面的所有工具返回都还在上下文里。一次返回 5 万字符的工具，后面每一步都要重付一次这个成本。

对策：工具返回做截断；长历史做摘要压缩；超出阈值时开启新会话。

七、一张 checklist

[ ] 每个任务一个 trace_id，每步一个 span
[ ] 工具调用记录 args / result_size / latency / ok
[ ] 有 outcome 字段（自动断言 + 人工标注两条来源）
[ ] 20 条起步评测集，改动后必跑
[ ] 监控步数、循环拦截、单工具失败率
[ ] 工具返回体有大小上限
[ ] 每周抽 20 条 trace 人工复盘
[ ] 失败样本回流进评测集