阶段 10 讲义 — 如何证明一个 Agent 可靠
阶段 10 讲义 — 如何证明一个 Agent 可靠
本阶段的核心命题 从"感觉效果不错"升级为"能够量化证明"。这是 Agent 产品经理与传统产品经理能力差距最大的一段——传统产品的效果可以靠 A/B 和转化率说话，Agent 的行为是路径级的、非确定的，需要一整套新的度量方法。
一、评测的四个目的，四套做法
先分清目的，否则会做出"测了一堆但什么决策也支撑不了"的评测集。
| 目的 | 问题 | 做法 | 频率 |
|---|---|---|---|
| 能力评估 | 它能不能做这件事 | 覆盖面广的任务集 | 立项时 |
| 回归测试 | 改动有没有弄坏原来能做的 | 固定集 + 阈值 | 每次改动 |
| 方案比较 | A 和 B 哪个好 | 同集 + 统计显著性 | 选型时 |
| 上线门槛 | 能不能发 | 准入指标 + 硬性红线 | 发版前 |
最常见的失败：只做了"能力评估" 做了一次评测、拿到 82% 的成功率、然后就没有了。没有回归集的 Agent 产品，改一次提示词就可能悄悄退化，而没有人知道。 回归集才是评测体系里价值最高、最应该先建的部分。
二、测什么：三个层次
只测最终答案是不够的。一个实用的课程框架是三层同时评：
| 层次 | 评什么 | 典型判据 |
|---|---|---|
| 最终结果（Final Response） | 输出对不对 | 精确匹配 / 规则校验 / 评分标准 / 模型判官 |
| 执行轨迹（Trajectory） | 走的路对不对：选了哪些工具、顺序、参数 | 与参考轨迹匹配 / 关键步骤是否出现 / 有无多余调用 |
| 状态变化（State Changes） | 世界被改成什么样了 | 期望的产物是否生成 / 数据库最终状态是否正确 |
第三层是最硬的判据 τ-bench 这类工具-用户交互基准的核心做法就是：对话结束后比对数据库最终状态与标注的目标状态。这个思路极其适合有副作用的业务 Agent——"用户说他改签成功了"不算数，订单表里的状态才算数。
对国际机票 Agent 来说，这意味着评测集里应当包含"跑完之后订单/占座/支付记录应当是什么样"的期望状态。
为什么轨迹必须评
只看最终答案，会漏掉三类严重问题：
- 蒙对了：走了错误的路径但碰巧结果对，换个输入就崩
- 绕远路：结果对但用了 3 倍步数和成本
- 副作用：结果对但顺手做了不该做的事（多查了不该查的数据、多发了一次请求）
三、怎么测：五种判据
| 判据 | 适用 | 优点 | 陷阱 |
|---|---|---|---|
| 精确匹配 | 结构化输出、抽取 | 客观、便宜 | 只适用于唯一答案 |
| 规则校验 | 格式、约束、业务规则 | 客观、可解释 | 写规则要花时间 |
| 评分标准（Rubric） | 主观输出 | 可细化维度 | 一致性依赖标注质量 |
| LLM-as-a-Judge | 大批量主观评价 | 可规模化 | 判官本身要被评测 |
| 人工评审 | 高风险、判据难写 | 最准 | 贵、慢、不可规模化 |
LLM 判官必须先与人工对齐 用模型打分之前，先做一件事：在 30～50 条样本上同时跑判官和人工标注，算一致率。一致率低于可接受阈值时，判官的分数没有意义——它只是给出了一个稳定的、错误的数字。
另外：判官容易有位置偏好（偏好先出现的）、长度偏好（偏好长的）。做 A/B 比较时要交换顺序各跑一次。
四、指标：别只报一个成功率
| 指标 | 含义 | 注意 |
|---|---|---|
| 任务成功率 | 完成且正确的比例 | 要定义清楚"成功"，尤其是部分成功怎么算 |
| 轨迹合规率 | 关键步骤都走了、没有多余危险调用 | 需要参考轨迹或规则 |
| 工具选择准确率 | 选对工具的比例 | 定位问题最有用的单项指标 |
| 参数正确率 | 参数拼对的比例 | 常常是失败的真正原因 |
| 恢复率 | 遇到错误后自行恢复的比例 | 体现 Harness 的鲁棒性 |
| 人工接管率 | 需要人介入的比例 | 商业模型的核心变量 |
| 平均成本 / 时延 | 每完成一次任务 | 与成功率一起看才有意义 |
| pass@k | 采样 k 次至少一次成功 | 不能作为线上准入指标 |
pass@k 的误用 pass@1 = 60%、pass@5 = 92% 这组数据经常被简化成"我们的 Agent 有 92% 的成功率"。但线上用户通常只有一次机会——除非产品真的会自动重试 5 次并且能自己判断哪次对。
报告口径必须与产品实际行为一致。 如果产品会重试 3 次并用校验器挑选，那就报 pass@3 + 校验器准确率；否则报 pass@1。
非确定性系统怎么测
三条硬规则：
- 固定环境：工具返回、时间、随机源都要可控。用真实线上接口做评测，结果不可比。
- 重复采样：每条用例至少跑 3～5 次，报分布而不是单点。
- 统计判断：比较两个版本时，差异要大到超过噪声才算改进。样本量小的时候，5% 的差异很可能只是抖动。
五、评测集怎么建
四类用例，缺一不可
| 类型 | 占比建议 | 来源 |
|---|---|---|
| 真实任务 | 40% | 线上日志、用户反馈 |
| 合成任务 | 20% | 覆盖组合空间 |
| 边界任务 | 25% | 信息不全、超范围、多意图、极端值 |
| 对抗任务 | 15% | 提示词注入、诱导越权、矛盾指令 |
从"失败"开始建集，不要从"功能"开始 最有效的评测集来源是已经出过的问题。每修一个线上问题，就往回归集里加一条用例——半年后你会有一个别人抄不走的资产。
Anthropic 在 Skills 的创作指南里给的建议是同一个道理：从评测出发，先跑代表性任务、观察在哪卡住，再针对性补能力，而不是先把手册搬进去。
一条用例应当包含什么
六、验证 Agent：证据合同与抽查闭环
独立 Reviewer 仍然是一个 LLM；只写“请仔细检查”很容易得到一段看似认真、实际没有验证的文本。要把验证变成问责结构，需要一份明确合同：
- 命名失败模式：例如审核回避、被前 80% 的正确实现迷惑、只复述实现者结论。
- 堵住常见托词：“代码看起来对”“实现者说测过了”“改动很小”等都不能作为 PASS 依据。
- 规定证据格式：PASS 必须包含实际命令、输入、关键输出和观察结论。
- 限制 PARTIAL：只能用于环境或权限阻塞，不能表示“我不确定”。
- PASS 前做对抗式探测：至少主动寻找一个边界、反例或破坏路径。
- FAIL 前排除误报：确认不是有意设计、环境差异或不可行动限制。
- 调用方随机抽查：重跑 2～3 条验证命令，形成自律 + 他律闭环。
不要把实现者的“已经测过”传给 Reviewer 当锚点 实现者测试可作为背景线索，但不能自动成为独立证据。Reviewer 应优先从验收标准出发选择验证方法。
完整案例见 Claude Code：验证 Agent。
七、可观测性：线上要看什么
三层数据
| 层 | 内容 | 用途 |
|---|---|---|
| Trace / Span | 一次运行的完整树：模型调用、工具调用、子 Agent | 定位问题 |
| 事件流 | 状态变化、审批、错误、停止原因 | 理解行为 |
| 用量与成本 | token、调用次数、按用户/功能归因 | 成本管理与定价 |
标准化现状：OpenTelemetry 的 GenAI 语义约定截至 2026 年年中仍处于 Development / experimental 状态——字段名还会变。产品含义：现在就可以按 OTel 的思路埋点，但不要把字段名硬编码进太多下游依赖；预留一层映射。
工具生态目前分两类：评测优先（Braintrust 一类，强在离线评测与 CI 门禁）与观测优先（Langfuse、Arize Phoenix、LangSmith 一类，强在生产 trace 与在线评估）。选型时的关键问题不是功能表，而是：能不能自托管、trace 里的业务数据是否出域、能不能对轨迹（而不只是单次调用）做评估。
线上必须能回答的五个问题
- 这次任务走了哪几步？
- 每一步为什么这么走（当时上下文里有什么）？
- 在哪一步出的问题？属于四类故障中的哪一类（模型/上下文/工具/Harness）？
- 这次任务花了多少钱、时延分布在哪？
- 同类任务最近一周的成功率趋势如何？
答不出第 3 条，就没有可观测性 只有日志、没有轨迹结构的系统，第 3 条只能靠研发人工翻。"产品经理能不能自己看懂一次失败"是可观测性的验收标准。
八、可靠性：从自愈到人工兜底
五层防线，从便宜到贵（与阶段 4 的错误恢复五层次对应，这里补充系统层）：
| 层 | 机制 | 适用 |
|---|---|---|
| 1 | 重试 / 退避 | 瞬时故障 |
| 2 | 改参重试（把校验错误回喂） | 参数问题 |
| 3 | Fallback（换工具 / 换模型） | 单点不可用 |
| 4 | Circuit Breaker（熔断） | 依赖持续故障，快速失败而不是拖死 |
| 5 | 降级与人工兜底 | 以上都不行 |
自愈的前提是能判断"坏了"。 没有校验器和指标，所谓自愈只是盲目重试。这也是本阶段与阶段 4 的连接点：Agent 的鲁棒性来自可判定性，不来自模型的"聪明"。
准入门槛与回归流程模板
"危险动作零越权"必须是硬红线 其他指标可以是百分比，涉及资金、不可撤销动作、越权访问的项必须是 0 容忍。把它写成 99.9% 通过率，等于允许千分之一的越权发生——在支付和出票场景里这是不可接受的。
九、常见误区清单
| 误区 | 纠正 |
|---|---|
| "跑几个 case 感觉不错就行" | 非确定系统需要重复采样与统计 |
| "只看最终答案" | 会漏掉蒙对、绕远路、副作用三类问题 |
| "用线上接口做评测更真实" | 环境不固定，结果不可比 |
| "LLM 判官很方便" | 判官要先与人工对齐，还要防位置/长度偏好 |
| "pass@5 是我们的成功率" | 口径必须与产品实际重试行为一致 |
| "先做功能，评测以后补" | 回归集越晚建成本越高，且早期问题会被永久遗忘 |
| "可观测性是研发的事" | 产品经理能不能自己看懂失败，是验收标准 |
| "成功率高就能上线" | 危险动作越权必须是 0，不是百分比 |
| "Reviewer 说 PASS 就算验证过" | PASS 必须有原始证据，并由调用方随机抽查 |
十、外部一手资料（阶段 10 精读，约 5 小时）
| 资料 | 出处 | 读它拿什么 |
|---|---|---|
| Evaluate agent workflows（trace grading） | OpenAI 文档 | 用 trace 打分回答"选对工具了吗、该 handoff 时 handoff 了吗" |
| How to evaluate your agent with trajectory evaluations | LangChain 文档 | 轨迹评测的具体做法与评估器 |
| Evaluating AI Agents at the Run, Trace, and Thread Level | LangChain | 三层评测（最终结果 / 轨迹 / 状态变化）的完整表述 |
| τ-bench（arXiv:2406.12045） | 论文 | "比对最终数据库状态"这一评测思路 |
| Testing Agent Skills Systematically with Evals | OpenAI 博客，2026-01-22 | 把评测做成轻量端到端测试的工程做法 |
本仓已有资料：
- Pi：怎么测一个不确定的系统
- Agent 评测就绪清单
- Deep Agents 评测方法
- 生产 Agent 自愈
- Claude Code：证据合同与对抗式验证
Related Documents
- 阶段 10 实践：30 条最小评测集
- 阶段 4 讲义：故障归因四类
- 阶段 11 讲义：安全
- 学习路线