Agent 评测怎么做
Agent 评测怎么做
原文:Demystifying evals for AI agents | Anthropic Engineering Blog | 2026.1.9
导语
没有评测的 Agent 开发,就是盲人骑瞎马。
你修复了一个 Bug,不知道有没有引入新的;你优化了一个提示,不确定其他场景有没有退化。团队陷入被动循环——只能在生产环境中发现问题。
这篇文章是 Anthropic 写的最全面的 Agent 评测指南,覆盖了从概念到实操的完整链条。
一、核心概念

| 术语 | 定义 |
|---|---|
| 任务(Task) | 具有明确输入和成功标准的单个测试 |
| 试验(Trial) | 对任务的一次尝试(模型有随机性,需多次) |
| 评分器(Scorer) | 评估 Agent 性能某方面的逻辑 |
| 记录(Transcript) | 试验的完整记录(输出、工具调用、推理过程) |
| 结果(Outcome) | 试验结束时环境的最终状态 |
二、三种评分器

| 类型 | 方法 | 优点 | 缺点 |
|---|---|---|---|
| 基于代码 | 字符串匹配、单元测试、静态分析 | 快速、客观、可重现 | 脆弱、缺乏细微差别 |
| 基于模型 | LLM 规则评分、成对比较 | 灵活、可扩展 | 不确定性、需校准 |
| 人工评分 | 专家审查、A/B 测试 | 黄金标准 | 昂贵、缓慢 |
三、能力评估 vs 回归评估
能力评估
问:"Agent 能做什么?" 针对 Agent 目前还做不好的任务,设定改进目标。
回归评估
问:"Agent 是否还能做它以前能做的?" 通过率应接近 100%。
关键机制: 当能力评估达到高通过率后,将其"毕业"为回归评估。
四、不同类型 Agent 的评估策略
编程 Agent
- 使用确定性测试(单元测试)验证正确性
- 结合 LLM 规则评估代码质量
- 参考基准:SWE-bench Verified、Terminal-Bench
对话 Agent
- 检查可验证的最终状态(退款是否处理)
- 评估交互质量(同理心、解释清晰度)
- 需要第二个 LLM 模拟用户
研究 Agent
- 事实核查 + 覆盖范围检查 + 来源质量检查
- LLM 规则需频繁校准
计算机使用 Agent
- 在真实或沙盒环境中运行
- 检查是否达到预期结果
- 平衡 Token 效率和延迟
五、处理非确定性

Agent 行为在运行之间存在差异,需要专门的度量指标:
| 指标 | 含义 | 适用场景 |
|---|---|---|
| pass@k | k 次中至少一次成功 | "只要有一个成功就行"的开发工具 |
| pass^k | k 次全部成功 | 需要每次都可靠的面向客户系统 |
六、从零开始的 8 步指南

- 尽早开始:20-50 个真实失败案例就是很好的起点
- 从手动测试开始:利用开发中的手动检查和生产 Bug
- 编写明确的任务:两个专家应独立得出相同的通过/失败结论
- 平衡问题集:测试应该发生和不应该发生的情况
- 构建强大的框架:每次试验从干净状态开始
- 精心设计评分器:优先确定性评分器,LLM 评分器需校准
- 检查记录:定期阅读记录确认评分是否公平
- 监控饱和度:100% 通过率意味着需要更难的任务
七、评估不是万能的
最有效的团队结合多种方法:
- 自动化评估:快速迭代
- 生产监控:真实用户行为
- A/B 测试:衡量实际用户结果
- 用户反馈:发现未预料的问题
- 人工记录审查:建立失败模式直觉
读后感
这篇文章最重要的观点是:评估不是锦上添花,而是 Agent 开发的基础设施。
没有评估,你就无法衡量进步。投入到评估中的每一分钟,都会在后续迭代中产生复利效应。
本文是 Anthropic AI Agent 系列 第 12 篇,共 15 篇。下一篇:Agent 安全:从权限提示到沙箱隔离
关注公众号 coft 获取系列更新。

浙公网安备 33010602011771号