Anthropic《Demystifying evals for AI agents》结构译述

本文基于 Anthropic 于 2026-01-09 发布的文章《Demystifying evals for AI agents》进行结构化译述。正文以中文解读为主，适当嵌入少量关键英文原句，帮助保留原文判断的力度，但不做整段英文转载。

原文信息

原文标题：Demystifying evals for AI agents
发布方：Anthropic Engineering
发布日期：2026-01-09
原文链接：anthropic.com/engineering/demystifying-evals-for-ai-agents

为什么值得读

这篇文章的价值，在于它先把概念边界讲清楚，再谈方法。很多团队一说到 evals，容易把样例集、自动化测试、grader、线上监控、甚至 agent scaffold 混成一团。Anthropic 这篇文章最有用的地方，就是先把这些词一一拆开。

如果没有这一层术语澄清，团队后面做的很多事情其实很难对齐。产品会以为自己在补测试，研究会以为自己在调模型，工程会以为自己在搭基础设施，但三边说的并不一定是同一件事。

一句话结论

对 agent 来说，评估不是单次问答打分，而是一整套围绕任务、trial、grader、transcript、outcome 和 harness 组织起来的系统。只有把这些组件分别定义清楚，团队才能真正进入可持续优化。

文章结构译述

标题与引言（对应原文：Introduction）

Anthropic 开头先说明，agent 之所以有价值，恰恰也是它难评估的原因。原文有一句很值得保留："the capabilities that make agents useful"。意思是，agent 的自主性、灵活性、多轮工具调用能力，本来就是它相比普通聊天模型更有生产力的地方，但也正因为如此，它不再适合只靠单轮题目来衡量。

这篇文章的起点不是“我们怎样做一个更复杂的 benchmark”，而是“当系统已经会调用工具、修改环境、跨多轮推进任务时，评估本身也必须升级”。它想解决的，是从原型走向生产时最容易被忽视的一层能力建设。

一个 eval 到底由什么组成（对应原文：The structure of an evaluation）

这一节是全文最重要的概念框架。Anthropic 先把 eval 定义成：给 AI 输入，再用 grading logic 去衡量结果是否达标。这个定义本身并不新，但关键在于它随后把 agent 评估拆成了多个独立组件，而不是只说“跑一遍看结果”。

文章明确区分了 task、trial、grader、transcript、outcome、evaluation harness、agent harness、evaluation suite 这几层。这里最值得特别记住的是 evaluation harness 和 agent harness 不一样。前者是运行评估、记录步骤、聚合结果的基础设施；后者是让模型能够作为 agent 行动起来的系统本身。

原文里一句定义很关键："A task is a single test." 这句话虽然短，但很有用。它提醒团队不要把一整类能力混成一个笼统指标，而要把真实任务拆成一个个有输入、有成功标准的测试单元。

为什么团队越往后越离不开 evals（对应原文：Why build evaluations?）

这一节的核心不是鼓励“从第一天就把评估平台一次性建好”，而是解释为什么没有 evals 的团队最终一定会进入被动状态。早期原型阶段，团队经常靠手工测试、内部试用和直觉也能快速推进，但一旦产品上线并开始频繁调整，问题就会变得越来越难看清。

Anthropic 描述的典型症状很准确：用户开始反馈体验变差，但团队只能靠猜。修了一个问题，又引出另一个问题；有人觉得是模型退化，有人觉得是 Prompt 改坏了，有人怀疑是工具链或路由问题。没有 evals 时，所有这些都只能靠人工复现和反复试错。

文章特别强调 eval 的“复利”价值。原文里有个短句："their value compounds"。前期成本看起来很具体，但后期收益会不断叠加，包括更快的模型切换、更清楚的回归验证、更高带宽的产品与研究协作。

Anthropic 眼里的 agent eval 方法论（对应原文：How to evaluate AI agents）

这部分开始把方法落到不同 agent 类型上。文章并不建议每种 agent 都从零发明一套新体系，而是提出一些跨场景可复用的 grader 组合思路。编码 agent 更适合 deterministic checks 起步；对话 agent 则更依赖 outcome 与 rubric 的结合；研究 agent 需要 groundedness、coverage 和 source quality 这类多维检查。

这部分一个重要判断是：没有哪一种 grader 足够覆盖所有问题。代码型 grader 快、便宜、可复现，但常常很脆；模型型 grader 更灵活，能处理开放式输出，但成本更高，也需要人工校准；人工评估仍然是校准标准，而不是可以彻底被省掉的环节。

文章还区分了 capability evals 和 regression evals。前者回答“这个 agent 已经能做好什么”，适合找上限；后者回答“它原来会做的东西现在还会不会做”，适合守住底线。这个区分很适合放进站内文章，因为它直接对应了研发节奏中的“爬坡”和“防回退”两类任务。

非确定性不是噪声，而是设计维度（对应原文：How to think about non-determinism in evaluations for agents）

Anthropic 在这一节提醒，不要把 agent 的波动性只当成统计噪声。对于 agent 来说，同一个 task 在不同 trial 中能否稳定成功，本身就是产品质量的一部分。也因此，单看一次是否通过，远远不够。

文章拿 pass@k 和 pass^k 说明两种截然不同的关注点。前者适合“多试几次，成功一次就有价值”的场景；后者适合“每次都得稳定成功”的场景。这个区分很有现实意义，因为很多团队嘴上说想提高成功率，实际上没有先定义自己追求的是“偶尔能成”还是“每次都稳”。

对用户侧强依赖稳定性的系统，pass^k 的意义往往更大。反过来，如果是探索式 agent 或创意类工作流，pass@k 可能更贴近真实价值。这个判断不应交给评估框架默认决定，而应由产品目标来驱动。

从零到一搭建 agent evals（对应原文：Going from zero to one: a roadmap to great evals for agents）

这部分最实用。Anthropic 并没有要求团队一开始就准备几百条任务，而是建议从少量真实任务起步，尤其是从手工测试、用户失败案例、Bug 反馈中提炼最有价值的初始样本。对很多团队来说，20 到 50 条高信号任务，往往比 500 条泛泛样本更有用。

它的建议顺序也很工程化：先把当前已经在人工检查的行为显式化，再写成无歧义的任务和成功标准，然后选择最合适的 grader 组合，再逐步扩展。换句话说，eval 不是先搭平台再找题，而是先把“什么叫做好”说清楚，再把它机制化。

这部分真正的底层观点是：evals 不是末端验收工具，而是需求澄清工具。很多团队直到写 task 时，才第一次被迫说清楚边界情况怎么处理、什么算成功、哪些 tradeoff 不能接受。

关键观点提炼

evaluation harness、agent harness、grader、suite 这些概念需要先分清，再谈体系建设。
eval 的价值不只在于发现退化，更在于加速模型替换、促进产品与研究对齐。
不同 agent 类型可共享设计原则，但 grader 组合必须按任务特征来选。
非确定性不是附带问题，而是必须被显式建模和度量的对象。
真正有用的 eval 往往从少量高信号真实任务起步，而不是从大而全的数据集开始。

对工程团队的启发

如果你的团队现在已经在做 agent，但仍然主要靠手工试用和上线观察来判断质量，这篇文章最值得借鉴的不是某个具体框架，而是它的拆解方式。先把 task、trial、grader、transcript、outcome、harness 分开，你们内部关于“评估到底缺什么”的讨论会立刻清晰很多。

另一个直接启发是：不要急着追求一套统一总分。对 agent 来说，往往先建立明确的任务单元、grader 组合与回归样本库，比做一个漂亮的 Dashboard 更重要。真正能让团队跑起来的，是一个能持续使用的小体系，而不是一个概念上完整但迟迟无法落地的大体系。

原文链接与出处说明

原文由 Anthropic Engineering 发布：

Demystifying evals for AI agents | Anthropic

本文为结构化译述与观点整理。如需查看原文术语定义和完整上下文，请直接阅读原始页面。