Anthropic Engineering · 2026-01-09
讲解：Demystifying evals for AI agents
这篇文章的核心不是“多做几个 benchmark”，而是把 Agent 变成一个可度量、可回放、可比较、可长期维护的工程系统：任务定义清楚，环境可复现，评分器组合使用，轨迹被阅读，评测结果持续进入产品迭代。
Evaluation anatomy
一套 Agent eval 到底由什么组成？
Anthropic 先统一术语，因为大多数评测失败不是模型问题，而是任务、评分器、环境或成功标准没有定义好。
评的是 Agent harness + model，不只是模型
Claude Code 这样的 agent harness 会决定工具如何暴露、循环如何执行、状态如何写入。因此“Claude 通过/失败”往往其实是“Claude + scaffold + tools + environment”共同通过/失败。
不要只看 agent 说了什么
航班 agent 说“票已订好”不等于数据库里有 reservation；代码 agent 解释“我修复了”不等于测试通过。Agent eval 要尽量检查状态和产物。
Why it matters
为什么不靠手测和直觉？
早期 dogfooding 很有用，但一旦 agent 扩大到真实用户，纯手测会进入 Anthropic 所说的 reactive loop。
没有 eval：线上报错 → 手工复现 → 修一个坏另一个
团队无法判断“用户感觉变差”是真退化还是噪声，也无法在每次 prompt / tool / model 改动前跑几百个场景。
有 eval：失败样例变成回归测试
Claude Code 早期靠员工和外部用户反馈迭代，后来把 concision、file edits、over-engineering 等行为做成 eval，才更系统地支撑产品和研究协作。
新模型出来时可以几天内升级
没有 eval 的团队需要数周手测；有 eval 的团队能快速看新模型优势、调 prompt、测成本/延迟/错误率，并决定是否切换。
Graders
三类评分器：代码、模型、人
Anthropic 的建议是：能用确定性就用确定性；需要判断开放质量时用 LLM；用人类专家做校准和高价值抽检。
| 类型 | 适合评什么 | 优点 | 风险 |
|---|---|---|---|
| 代码型评分器 Code-based graders | exact/regex/fuzzy match、unit tests、static analysis、outcome verification、tool calls verification、transcript metrics。 | 快、便宜、客观、可复现、容易 debug，适合代码 agent 和有明确状态的任务。 | 容易脆：合法变体可能被误杀；对主观质量缺少 nuance。 |
| 模型型评分器 Model-based graders | rubric-based scoring、自然语言断言、pairwise comparison、reference-based evaluation、多 judge 共识。 | 灵活、可规模化、能评开放输出和“是否有帮助/是否完整/是否语气合适”。 | 非确定、成本更高，必须用人工标注校准；rubric 模糊会导致评分快速漂移。 |
| 人工评分器 Human graders | SME review、crowdsourcing、spot-check、A/B test、inter-annotator agreement。 | 最接近真实专家和用户判断，可作为 LLM judge 的 gold standard。 | 慢、贵、难规模化，复杂领域需要专家。 |
Capability vs Regression
能力评测和回归评测不是一回事
这是文章里对产品团队最重要的区分：一个给研究爬坡，一个守住线上质量。
问：这个 agent 能做到什么？
应该从低通过率开始，挑 agent 目前挣扎的任务，让团队有 hill to climb。若很快 100%，就不能再衡量能力进步，只能说明任务太简单或已经饱和。
问：它还会不会做以前会做的事？
应该接近 100% pass rate，用来保护不倒退。能力评测里已经稳定通过的任务，后续可以毕业进入回归套件，在 CI/CD 中持续跑。
Agent families
四类 Agent 的评测方法
Anthropic 把可落地的 agent 大致分成 coding、conversational、research、computer use。不同类型混合不同 grader。
代码型：用测试验证 outcome，再补质量 rubric
SWE-bench Verified 和 Terminal-Bench 都体现了这个思路：给真实代码任务，运行测试套件判定是否修复且不破坏旧功能。额外可加 static analysis、工具调用检查和 LLM 代码质量评分。
task: fix-auth-bypass 主要 grader: - deterministic_tests - static_analysis - state_check: security_logs - llm_rubric: code_quality metrics: n_turns, n_toolcalls, tokens, latency
对话型：目标完成 + 交互质量一起评
客服、销售、教练类 agent 不只要完成任务，还要语气、解释、上下文状态和工具调用正确。常需要另一个 LLM 模拟用户，比如 τ-Bench / τ2-Bench 的多轮场景。
refund support eval: - llm_rubric: empathy, clarity, groundedness - state_check: ticket resolved, refund processed - tool_calls: verify_identity, process_refund - transcript: max_turns <= 10
Research Agent：用 groundedness / coverage / source quality 组合
研究质量取决于任务语境：市场扫描、尽调、科学综述标准都不同。可用 claims 是否被来源支持、关键事实覆盖率、来源权威性、开放综合质量来评；LLM rubric 必须经常和专家判断校准。
这对 Auto Research 特别直接：不能只看报告“写得像不像”，还要看来源是否权威、是否覆盖必要事实、是否把不确定性说清楚、是否适合下一步工程决策。
电脑/浏览器使用型：检查真实 GUI 环境状态
WebArena 用 URL、页面状态和后端状态检查浏览器任务；OSWorld 检查文件系统、应用配置、数据库和 UI 元素。文章还提醒：DOM 工具快但 token 多，截图工具慢但可能更省 token，评测要检查 agent 是否选对工具。
Non-determinism
随机性：pass@k 和 pass^k 讲的是相反问题
Agent 同一任务多跑几次可能一次成功一次失败，所以不要只看单次结果。
k 次里至少成功一次的概率。适合“多给几次，只要找到一个有效解就行”的任务。
k 次都成功的概率。适合用户每次都期待稳定成功的客服、生产系统和高可靠 agent。
若单次成功率 75%，连续 3 次都成功是 0.75³ = 42.1875%；而 3 次至少一次成功是 98.4375%。同一 agent 在两个指标下叙事完全不同。
Roadmap
从 0 到 1：建立可信 Agent eval 的 8 步
这部分是文章最像 playbook 的地方，可以直接转成团队流程。
Start early：不要等到有几百个任务
Anthropic 建议 20–50 个来自真实失败的简单任务就能起步。早期系统改动 effect size 大，小样本也能发现方向。
从你已经手测的行为开始
把 release 前人工检查、bug tracker、support queue、用户投诉转成 eval tasks，并按用户影响排序。
写清晰任务和 reference solution
任务应让两个专家独立得出相同 pass/fail；评分器检查的内容必须在任务描述中明示。0% pass@100 常常是坏任务或坏 grader 信号。
构造 balanced problem sets
既测试“该发生时发生”，也测试“不该发生时不发生”。只测应该搜索，会训练出什么都搜索的 agent。
稳定 eval harness 和隔离环境
每个 trial 从干净环境开始，避免共享缓存、旧文件、git history、资源耗尽等让 trial 不独立或虚高。
精心设计 grader，允许 partial credit
优先确定性，必要时 LLM，人类校准；多组件任务要有部分分，否则无法区分“差一点成功”和“完全失败”。
读 transcripts
分数不涨时，必须读轨迹确认失败是否公平：是真错、有效解被误杀、任务含糊，还是 harness 限制了模型。
监控饱和并长期维护
100% 的 eval 只能做回归，不能测能力。eval suite 是活文档，应由 eval infra 团队拥有框架，产品/领域专家贡献任务。
Failure modes
文章中特别值得记的坑
很多“模型能力差”的结论，后来被证明是评测自己坏了。
把有效解法误判为失败
Opus 4.5 在 τ2-bench 航班预订题里找到 policy loophole，按静态 eval 算失败，但对用户可能是更好解法。
过于 rigid 的 grader
CORE-Bench 里曾出现把 96.12 因不等于 96.124991… 判错、任务含糊、随机任务不可复现等问题。修复后 Opus 4.5 分数从 42% 跳到 95%。
agent 能“hack”评测
任务和 grader 要让通过必须真的解决问题，而不是利用漏洞；同时也不要把 agent harness 约束得过死，压制模型真实能力。
Holistic evaluation
自动化 eval 只是多层防线之一
Anthropic 用类似 Swiss Cheese Model 的视角：每一层都有洞，多层组合才能覆盖真实质量。
| 方法 | 主要价值 | 主要限制 |
|---|---|---|
| 自动化 evals | 可复现、可在每次改动和模型升级前跑、不会影响真实用户。 | 前期投入高，若任务不贴近真实使用会制造虚假信心。 |
| Production monitoring | 看到真实用户行为和线上错误，发现 synthetic eval 漏掉的问题。 | 偏 reactive，问题先影响用户；缺少明确 ground truth。 |
| A/B testing | 衡量真实用户指标，如留存、任务完成、业务转化。 | 慢，需要足够流量；不一定解释“为什么”。 |
| User feedback | 暴露意料之外的问题，并提供真实样例。 | 稀疏、自选择偏差强，用户常不解释失败原因。 |
| Manual transcript review | 建立失败模式直觉，校准“好”的标准。 | 耗时、不可规模化、覆盖不稳定。 |
| Systematic human studies | 主观复杂任务的 gold standard，可校准 LLM grader。 | 贵、慢、专家难找，评分者分歧需要仲裁。 |
Auto Research implications
放到 FJ Auto Research 里，应该怎么落地？
这篇文章对“自动调研/自动报告系统”的启发非常直接：我们要评的是调研 agent 的全流程，而不是最终 HTML 是否好看。
为 Auto Research 建三层任务库
- 回归层：已知来源、固定答案、固定页面生成和链接解析，目标接近 100%。
- 能力层：开放研究问题，例如比较多个论文方向、从碎片源中形成投资/研究结论，目标一开始允许低通过率。
- 压力层：来源冲突、信息过时、网页不可访问、X/Twitter 噪声、用户临时改 scope。
不要只用一个 LLM judge
- 代码型：链接是否可访问、引用是否存在、页面是否生成、HTML 是否含设计 token、路径是否在 public 下。
- 模型型：claim 是否被 source 支持、coverage 是否满足 checklist、是否区分事实/推断/建议。
- 人工型：抽样阅读高价值报告，校准模型评分和产品口径。
保存和阅读轨迹，而非只保存报告
需要记录搜索 query、被排除来源、抽取内容、冲突证据、评分器输出和最终编辑决策。这样当报告出错时，能知道是检索错、抽取错、综合错，还是 HTML 发布错。
把质量、成本和稳定性一起看
除了 pass/fail，还跟踪来源数量、权威来源比例、unsupported claim rate、重复信息率、生成耗时、token 成本、人工修改量、用户后续采纳率。
Framework appendix
文章提到的实现工具
框架能省基础设施时间，但 Anthropic 的结论很明确：框架只和你放进去的任务一样好。
Harbor
面向容器化 agent eval，支持云上大规模 trials 和标准任务/评分器格式；Terminal-Bench 2.0 通过 Harbor registry 分发。
Braintrust / LangSmith / Langfuse
覆盖离线 eval、production observability、tracing、dataset management；Langfuse 偏自托管开源。
Phoenix / Arize AX
Phoenix 是开源 tracing/debug/eval 平台，AX 是面向规模化优化和监控的 SaaS。
Bottom line
最终 takeaway
Agent eval 的成熟标志不是“有一个分数”，而是：真实失败持续进入任务库；任务能被 reference solution 通过；grader 公平且可校准；环境隔离；每次改动都能跑；分数异常时有人读 transcript；能力题饱和后转为回归题，并继续补更难的新题。