Agent 的评估
不能度量就不能改进。但 Agent 评估比传统软件测试难得多：非确定性、长轨迹、开放环境。本章先建立框架，下一节盘点基准与方法。
为什么 Agent 评估难
传统单元测试是确定性的：固定输入，断言输出。Agent 至少打破了三件事：
- 输出非确定。同样的输入，两次运行走不同的路径、给出不同的答案。断言从“等于什么”变成“满足什么性质”。
- 正确性依赖轨迹。最终答案对，不代表过程对——可能碰巧对、可能修改了不该改的文件、可能烧了十倍预算。只看结果会漏掉一半问题。
- 环境有状态。Agent 修改的文件、调用的 API 是有状态的真实世界，测试之间会互相污染。
因此 Agent 评估的核心思路是：从断言输出，转向评估过程与性质的组合。
评估的三层对象
| 层次 | 评估什么 | 典型手段 |
|---|---|---|
| 组件层 | 单次调用的质量 | prompt 回归测试、工具选择正确率 |
| 轨迹层 | 整个执行过程 | 轨迹回放、步骤数/成本/转折点分析 |
| 结果层 | 最终交付物 | 端到端基准、验收标准通过率 |
轨迹评估是 Agent 特有且最值得投入的一层：把一次运行的完整记录（每轮 prompt、响应、工具调用与结果）当作数据。典型检查点：
- 该用工具时用了吗？选对工具了吗？参数对吗？
- 从错误中恢复了几轮？有没有空转（连续重复动作）？
- 上下文被压缩后还保有任务关键信息吗？
LLM-as-judge 是轨迹评估的主力：用一个强模型按评分标准（rubric）给轨迹打分。它把不可枚举的“过程好坏”变成可批量执行的检查，但要警惕 judge 本身的偏差（偏长答案、偏自信表述），对关键场景要用人工校准。
评估进开发循环
Agent 开发把评估变成日常工具，而不是发布前的大考：
text
改 prompt / 换模型 / 调 Harness 参数
│
▼
跑评测集（几十个代表性任务 + 断言 + 轨迹检查）
│
▼
对比指标：通过率 / 平均步数 / 平均成本 / 注入拦截率
│
└──▶ 回归则定位（轨迹回放）→ 修复 → 再跑这要求评测集本身被精心维护：覆盖典型与边界场景、每次失败案例转化为新用例、版本化以对比历史。
下一节：基准与方法
基准与评估方法盘点可拿来就用的公开基准（SWE-bench、GAIA 等）、自建评测的设计要点，以及在线评估（A/B 与监控）如何补齐离线评测的盲区。