Chapter 12 · Agent Evaluation
Agent 评测不能只问“最后答对了吗”，还要问“过程是否合理、失败能否恢复、成本是否值得”
一个真正可迭代的 Agent 项目必须有固定 Eval Dataset 和可重复指标。否则你改了 Prompt、换了模型、加了 Memory 之后，只是在“凭感觉判断有没有变好”。
Result任务成功了吗
Final Outcome
Final Outcome
Process步骤合理吗
Tool / Trajectory
Tool / Trajectory
Robust出错能恢复吗
Recovery
Recovery
Cost代价值得吗
Latency / Token / Calls
Latency / Token / Calls
1. 为什么普通 Accuracy 不够？
两个 Agent 最终都答对，并不代表它们质量一样。
Agent A
search
→ calculator
→ answer
3 steps低成本路径清晰
Agent B
search × 8
→ calculator × 5
→ 2 errors
→ answer
15+ steps高成本路径冗余
Agent Quality = Correctness + Process + Robustness + Efficiency
2. 六类核心评测
✅
Final Answer
最终任务有没有完成。
🛠
Tool Calling
工具选对没有，参数对不对。
🧭
Trajectory
执行过程是否合理、高效。
🛡
Robustness
失败后能否恢复。
⏱
Cost / Latency
Token、调用数、时间、费用。
🔁
Regression
新版本有没有破坏旧能力。
3. Tool Calling Evaluation
Agent 特有的一类评测：模型到底会不会正确选择工具并构造参数。
| 错误类型 | 示例 |
|---|---|
| Wrong Tool | 天气问题却调用 search_web |
| Wrong Arguments | city="" 或参数字段错误 |
| Missing Tool | 应该调用工具却直接猜答案 |
| Unnecessary Tool | 简单计算却连续搜索网页 |
| Execution Failure | 调用格式正确，但工具真实执行失败 |
Tool Selection Accuracy
选对工具的比例。
Argument Accuracy
参数名、值和结构是否正确。
Execution Success Rate
真实工具是否执行成功。
选对工具 ≠ 工具执行成功 ≠ 最终任务成功
4. Trajectory Evaluation：评过程，而不只是评答案
τ = (a₁, o₁, a₂, o₂, …, aₜ)
Action：Agent 选择了什么操作。
Observation：环境返回了什么。
Loop：下一步是否合理利用了 Observation。
Finish：有没有及时停止，还是继续无意义调用。
好轨迹
read README
→ install
→ test
→ inspect error
→ fix
→ test pass
坏轨迹
search × 5
→ reread same file × 4
→ install random package
→ timeout
可以关注：重复动作率、无效工具调用率、平均步数、必要步骤覆盖率、提前结束率、超时率。
5. LLM-as-a-Judge：开放任务怎么办？
当答案没有唯一 Ground Truth 时，可以让模型按 Rubric 评分，但不能把它当作绝对真值。
Rubric:
1. 正确性：0-5
2. 完整性：0-5
3. 引用质量：0-5
4. 是否遵循任务约束：0-5
优点
适合长文本、研究报告、开放问答，扩展成本低。
风险
可能偏爱长答案、特定风格，存在随机性与模型偏差。
Rule-based + LLM Judge + Human Spot-check
更稳妥：能自动验证的先自动验证；只有开放维度再交给 LLM Judge。
6. Robustness：故意把环境弄坏
真正 Agent 必须面对工具失败、网络异常、文件缺失、权限错误等现实问题。
故障注入
API timeout、invalid JSON、missing file、permission denied。
观察行为
会不会崩、无限 retry、换方案或向用户求助。
核心指标
Recovery Rate、Retry Count、Escalation Rate。
Recovery Rate = 成功恢复的故障任务数 / 总故障任务数
特别关注无限循环：Agent 一旦把失败 Observation 理解错，可能不断重复同一 Tool Call。Runtime 必须有限步、超时与停止条件。
7. Cost / Latency：准确率提升 2%，成本涨 300% 值不值？
| 指标 | 意义 |
|---|---|
| Input Tokens | 上下文成本 |
| Output Tokens | 生成成本 |
| LLM Calls | 模型调用次数 |
| Tool Calls | 工具调用次数 |
| Wall Time | 真实完成时间 |
| Cost per Success | 每个成功任务的平均费用 |
Cost per Successful Task = Total Cost / Successful Tasks
工程判断：一个 Agent 不是“越聪明越好”，而是需要在质量、速度、成本之间达到合理平衡。
8. Regression Eval：新版本不能把旧能力搞坏
总体平均分最容易掩盖问题，所以必须按任务类型切片（slice）观察。
Agent v1:
code 80%
search 72%
tool_call 75%
Agent v2:
code 91%
search 74%
tool_call 52%
看起来平均分可能上涨，但 Tool Calling 已严重退化。所以评测必须分任务类型、难度、工具类别、故障场景。
Task Slice
代码、搜索、规划、总结。
Difficulty Slice
easy / normal / hard / edge-case。
Failure Slice
timeout / missing dep / invalid input。
9. 科研论文复现 Agent：Eval Dashboard 怎么设计？
| 指标 | 定义 |
|---|---|
| Environment Setup Rate | 能成功创建可运行环境的项目比例 |
| Run Success Rate | 能成功跑通 baseline 的项目比例 |
| Metric Recovery | 能否得到论文声明的关键实验指标 |
| Reproduction Gap | 复现实验与论文结果的差异 |
| Recovery Rate | 面对 dependency / CUDA / data 错误的恢复能力 |
| Average Steps | 完成任务平均需要多少动作 |
| Cost per Success | 每成功复现一个项目的平均成本 |
示例 Dashboard
Repos tested: 20
Setup success: 80%
Run success: 65%
Error recovery: 72%
Median steps: 14
Median runtime: 6.4 min
Median result gap: 1.3%
Avg cost / success: $0.21
这类数据比“做了一个 Agent Demo”更有项目价值。因为它直接说明系统在真实任务上的成功率、稳定性和成本。
10. 一页总结
1. Final Answer：任务做对了吗？
2. Tool Calling：工具选对了吗？
3. Trajectory：过程合理吗？
4. Robustness：出错能恢复吗？
5. Cost / Latency：代价值得吗？
6. Regression：新版本有没有破坏旧能力？
固定 Eval Dataset → 每次修改都重新跑 → 按 Slice 比较 Baseline
下一份：第 13～16 章综合项目收束——旅行 Agent、Deep Research、Cyber Town，以及如何把整套 Hello-Agents 映射成“科研论文代码复现 Agent”的完整项目蓝图。