2026 年 1 月 9 日，Anthropic 工程博客发了一篇《Demystifying evals for AI agents》。四位作者，致谢名单里出现了 Cognition、Bolt、Sierra、Stripe、Shopify 这些一线 agent 团队的名字。它的价值不在于提出了什么新概念，而在于把一件被长期当成玄学的事情——怎么知道一个 agent 到底行不行——拆成了一套可以照着做的工程流程。这篇文章分两部分：前半是解读，后半是我自己的引申，以及社区补上的那几盆冷水。

01先把这篇长文的靶子说清楚

Anthropic 开篇就给了判断：让 agent 有用的那些能力——自主性、智能、灵活性——同时就是让 agent 难以评估的原因。单轮 LLM 评估很简单，一个 prompt、一个回答、一套评分逻辑就完了。agent 不是这样：它跨多轮调用工具、修改环境状态、根据中间结果调整策略。这意味着错误会传播和累积：前面某一步偏了一点，后面整条链路都可能跑歪。

真正让团队开始重视评估，是一个很具体的时刻。原文说得很直白：临界点通常出现在「用户反馈更新后体验反而变差，而团队除了猜和手动试，没有任何办法验证」的时候。这时候调试完全是被动的——等投诉、手动复现、改一版、祈祷没有引入新问题。你既没法从随机噪声里分辨出真正的性能回退，也没法在发版前自动跑几百个场景。

原文里有个例子值得单独记住。Anthropic 在 τ2-bench 的订机票任务里测 Opus 4.5，评估逻辑写死了必须遵守某条退改签政策。结果模型发现了政策本身的一个漏洞，绕过了原本的限制，给出的方案比标准答案更好——然后被评估系统判为「失败」。这不是段子，它说明一个结构性事实：模型越强，静态评估的边界就越容易失效。原文用的说法是，评估系统要从「批改作业」进化为「观察实验」。

02先把这八个词对齐

原文第二节几乎是一份术语表。八个词值得逐条过一遍，因为后面所有争论都建立在这套定义上。

• 任务（task）：一个独立的测试，有明确定义的输入和成功标准。
• 试验（trial）：对任务的单次尝试。模型输出有随机性，所以要跑多次。
• 评分器（grader）：给 agent 某个方面打分的逻辑。一个任务可以有多个评分器，每个评分器里可以有多条断言。
• 记录（transcript）：一次试验的完整过程记录，包含输出、工具调用、推理、中间结果。对应 Anthropic API 就是跑完一次评估后那个完整的 messages 数组。
• 结果（outcome）：试验结束时，环境的最终状态。
• 评估框架（evaluation harness）：端到端跑评估的基础设施，负责下发指令和工具、并发跑任务、记录每一步、评分、汇总。
• Agent 框架（agent harness / scaffold）：让模型能作为 agent 行动的那一层。原文特别点明：当我们评估「一个 agent」时，评估的是框架和模型协同工作的结果。
• 评估套件（evaluation suite）：围绕同一目标设计的一组任务集合。

八个词里最关键的一对是 transcript 和 outcome。原文举的例子非常好：订票 agent 在对话里信誓旦旦说「您的航班已预订」——那只是 transcript；只有去查环境里的 SQL 数据库、确实多出一条预订记录，那才叫 outcome。

这个区分解决的是一个很隐蔽的问题。绝大多数「看起来在进步」的迭代，改善的都是 transcript——语气更自然了、解释更清楚了、看起来更靠谱了。而 outcome 一动没动。只看 transcript 做产品决策，等于在给自己发安慰奖。

03你以为在评估模型，其实在评估「模型 + 脚手架」

这是全文最容易读漏、但对工程决策影响最大的一条。Anthropic 把 harness 分成两层：agent harness 是套在模型外面、让它能行动的那层（Claude Code 就是一个 agent harness）；evaluation harness 是跑测试的那层。评估一个 agent，实际评估的是这两层和模型的组合。

这条为什么重要？因为行业里绝大多数「模型对比」，都是在不同 harness 下做出来的。同一层级的能力，换个编排策略、换个工具接口、换个重试逻辑，跑分能差出很多。2026 年一篇叫 MASEval 的论文就是专门说这件事的：在同一个能力层级里，agent 框架选择对结果的影响和模型选择一样大。原文自己也承认，一个强模型配上一个工具解析写得很差的 scaffold，表现会很难看。

实践含义很直接：当你的 agent 表现不好时，先问一个问题——这是模型不够强，还是外面那层没套对？原文其实给了一半答案：在花钱换新模型之前，先确认瓶颈不在 harness 上，否则你买来的新能力会被自己那层吃掉。

顺带说一句，这也是为什么 2026 年「模型厂自己做工具、工具商被迫自建模型能力」变成了主旋律——护城河正在从权重挪到 loop 上。

04三类评分器是分层，不是三选一

原文把评分器分成三类，取舍标准写得很干脆。

基于代码的评分器：字符串匹配、单元测试、静态分析、状态校验、工具调用校验。快、便宜、客观、可复现、好调试。缺点是脆弱——对写法不同但同样正确的答案不宽容，对主观任务无能为力，而且容易误伤走了一条合理替代路径的 agent。

基于模型的评分器：按 rubric 打分、自然语言断言、成对比较、多裁判共识。灵活、能处理开放式任务。缺点是非确定性、比代码贵、必须和人类评分校准。它还有一组众所周知的偏差：位置偏差（倾向选先出现的那个）、自我偏好、长度偏差（更长的回答更容易得高分）。社区的缓解办法是给裁判留一条「Unknown」的退路、按维度隔离打分、别让它一次判断太多东西。

人工评分器：领域专家评审、抽样检查、A/B 测试。是金标准，主要作用是用来校准前两类。缺点是贵、慢、难以规模化。

原文的建议顺序很清楚：能用确定性评分器就用，必要时叠加模型评分器，人工评分器负责校准和验证。三者冲突时，用加权、二元（一票否决）或混合的方式组合。

这里有个数字值得单独拎出来。原文提到，Opus 4.5 在一个叫 CORE-Bench 的基准上最初只有 42%；在修掉了「过于死板的路径检查」和「任务描述歧义」之后，跳到了 95%。同一份模型权重，同一批任务，分数差了 53 分。

我认为这是全文最该被反复引用的一处。它说明在一个坏掉的评分器下面优化 agent，等于对着一面哈哈镜健身——你流的汗是真的，练出来的形状是假的。

所以正确的操作顺序是：先读 transcript 验证评分器本身，再优化 agent。原文把「检查 transcript」放在路线图的第 6 步，我觉得它在实践中应该更靠前。

一次 agent 评估的解剖：左边是任务，中间是 agent 在环境里的循环，右边分成两条线——它说了什么（transcript）和世界变成了什么样（outcome）

05进攻的能力评估，防守的回归评估

原文把评估按用途分成两种，定义得很干净。

能力评估（capability / quality evals）问的是「这个 agent 能做好什么」。它应该从低通过率开始，专门挑 agent 现在做不好的任务，给团队一个可以攀爬的目标。它衡量的是「我们到底能不能做」。

回归评估（regression evals）问的是「它还能做好以前能做的事吗」。通过率必须接近 100%，分数掉下来就说明改动引入了问题。它衡量的是「我们还能不能稳定地做」。

两者要同时跑。爬坡的时候靠回归评估兜底，等某项能力稳定下来，就把通过率高的能力评估「毕业」进回归套件，持续盯着有没有漂移。

这两种用途配上之前的三类评分器，落地下来就是一个很朴素的工程直觉：能力评估防止你自满，回归评估防止你手抖。多数团队只做了前者，因为它的数字好看、有故事可讲；后者不产生任何叙事，只在你半夜被叫起来的时候体现价值。

评分器设计上还有个坑，原文专门提了：不要检查 agent 是不是按固定顺序调用了某几个工具。Anthropic 试过，结论是这类检查「过于死板，导致测试极其脆弱」。正确的做法是评「产生了什么」和「环境变成了什么样」，而不是评「走的是哪条路」——除非那条路本身就是合规要求。

06pass@k 与 pass^k 的两个问题

Agent 的行为是概率性的，跑一次不算数。原文引了两个指标，只差一个字符，方向完全相反：

• pass@k：k 次尝试中至少成功一次的概率。k 越大越高，衡量的是能力——「它到底会不会」。
• pass^k：k 次尝试全部成功的概率。k 越大越低，衡量的是可靠性——「它每次会不会都成」。

原文给了一个很好用的例子：单次成功率 75%，跑 3 次全过的概率是 0.75³ ≈ 42%。我把这张表算全了：

k	pass@k（至少一次成功）	pass^k（全部成功）
1	75.0%	75.0%
3	98.4%	42.2%
5	99.9%	23.7%
10	≈100%	5.6%

同一个 agent、同一批任务，k=10 的时候一个指标告诉你「几乎什么都能做」，另一个告诉你「十次里能连着做对的可能不到六个百分点」。两个都是真的，因为它们问的压根不是同一个问题。

同一个 agent、单次成功率 75%：pass@k 一路爬到 100%，pass^k 一路掉到 5.6%。两条曲线之间的距离，就是可靠性还没解决的那部分

选哪个，取决于谁在消费这个结果。如果人会在中间复核、能重试——比如 Copilot 一次给你五个候选代码——那 pass@k 是诚实的。如果 agent 是无人值守、用户只有一次机会，pass@k 就是幻觉：那一部分用户拿到的是 25% 里的坏结果，而且他自己不知道。

我的引申是：pass@k 与 pass^k 之间的落差，就是你尚未解决的可靠性债务，而且它是一个可以直接拿去要预算的数字。

75% 对 42%，物理含义是「每三个任务里就有两个需要有人兜底」。把这句话翻译成人工复核的人力成本，比讲一百句「agent 还不够可靠」管用得多。

07社区泼来的四盆冷水

Anthropic 这篇是方法论里的上品，但它是一份「怎么做」，不是一份「做了就够」。原文发布后，社区补上了几个它没展开的角度，我觉得这些比原文本身更需要记住。

第一盆：数据污染。Hacker News 上有人引了一篇 arXiv 论文（2506.12286）指出，SWE-bench 这类基于公开源码构建的基准，很可能系统性地高估 agent 的真实能力——因为仓库和 issue 本来就躺在训练数据里。另有一些分析文章给出了更刺眼的对比：针对基准评分逻辑专门优化过的 agent 能拿到接近 68% 的通过率，换成动态轮换测试用例的变体就掉到 31%。这组数字来自二手分析、我没有独立复现，引用时请打折，但它指向的问题是真的。

第二盆：统计功效。有一条批评我认为比第一盆更重要。一份分析指出，在一个 500 题的基准上，50% 这个未配对分数携带的 95% 置信区间大约是 ±4.4 个百分点。也就是说，你准备发版时宣称的「提升了 3 个点」，落在误差棒里面——你分不出它和零的区别。而那篇分析的结论是，改成配对比对（同一批任务、同一组种子）能在同样的数据和同样的预算下，把可检测的效应压到 3 个点以内。这是 agent 评测里性价比最高、也最少人做的一个改动。

顺着说一个更反直觉的结论：分数方差里更大的一块，通常是任务之间的难度差异，而不是同一任务多次运行的抖动。多跑几次只能缩小后者，对前者完全没用。所以「再多跑几轮」往往不是正确的杠杆，「再多出几道题」才是。

第三盆：harness 自己会失控。有一篇叫 The Harness Handbook 的论文指出了一个二阶问题：评估基础设施本身会长到难以维护——它堆积 eval case、自定义 judge、按失败模式拆的 rubric、集成测试、可观测性钩子，半年之后它会比它包着的那个 agent 还复杂。原文其实提到了对应的实践（把模型、后端、judge 放在调用处，不要写死在 spec 里），但没有把「这套东西会长成一个需要自己维护的系统」这句话说出来。

第四盆：只做离线评估，不做线上监控。一份统计称，大约 52% 的团队会跑离线 eval，只有 37% 做生产环境的在线评估。这条缝隙正是静默退化的藏身处——你的离线题集和真实用户的输入分布，从来不会完全一致。

原文里还有几处经验值，也值得直接抄下来：跨越多次试验仍然是 0% 通过率（也就是 0% pass@100），最可能说明任务写坏了，而不是模型不行；评分器要防绕过，agent 会学着产出「看起来对」的东西；如果一个评估套件跑到 100% 通过率，它就不再产生信号了，这叫评估饱和，需要补新题或者把它毕业成回归集。

08把这套方法落到四类真实场景

原文按编码、对话、研究、计算机操作四类 agent 给了评分设计。下面我换成「你自己会遇到的四类业务场景」来说，这样更好用。

场景一：企业内部知识库 / 研究型 agent。难点是「好」很主观——什么算全面、什么算有据可查，在法务尽调和市场调研里是完全不同的标准。原文给的三层检查可以直接照搬：基础性（每个结论都有检索到的来源支持吗）、覆盖度（关键事实是否齐全）、来源质量（引用的是权威来源还是内容农场）。这三层里只有第一层适合确定性评分，后两层必须上 LLM rubric，而且必须和领域专家校准。

场景二：客服 / 对话 agent。原文的方案是引入第二个 LLM 扮演用户，做长轮次的对抗性对话——比如专门设定一个「挑剔、愤怒的用户模型」，看 agent 在需求反复横跳时还稳不稳。评分分三层：结果层（工单是否 resolved、退款是否 processed——查状态，不查对话）、效率层（硬约束，比如 10 轮以内）、体验层（rubric 里写清楚「是否对客户的挫败感表达了同情」「解释是否清晰」）。三层缺一不可：只评结果，会放出一堆又慢又难用的 agent。

场景三：编码 agent。原文的态度很明确：对代码来说，结果只是及格线，过程才是分水岭。一个「修复认证绕过漏洞」的任务，可以同时挂上五个评分器——必须通过的两个安全测试（功能）、安全日志里必须出现 auth_blocked（状态）、ruff / mypy / bandit 扫描（规范）、必须真的读过源码文件而不是瞎猜（行为）、LLM rubric 给代码质量打分（质量）。这套配置解决的是 Code Review 里那个老问题：代码能跑，但写成了屎山。

场景四：无人值守的自动化 agent。这是我加的一类，原文提到但没有展开。定时报告、批量处理、自动修复这类场景，用户只有一次机会，所以只有 pass^k 有意义。而且除了「做没做对」，还要加一类断言：它有没有越界——读了不该读的文件、把密钥写进了 transcript、把测试改了而不是把代码修了、在沙箱外留下了副作用。能力和护栏是两套断言，可以跑在同一次试验里。

09现在可以做的三件事

如果只记三条：

第一，别等「完整套件」。原文的说法是，20 到 50 个来自真实失败案例的简单任务就是一个很好的起点——不要等凑齐几百道题。而且早期每次改动的效果都很明显，小样本量就能测出来。评估拖得越久越难补，因为早期产品需求会自然地转化成测试用例。

第二，先把 grader 写对，再动 prompt。顺序反了，你会在一面哈哈镜前面优化很久。具体动作是：挑一次失败，把完整 transcript 读一遍，第一遍先只问一个问题——这次失败是 agent 的错，还是我的评分器的错。

第三，把 eval 当成产品测试来维护。原文的目标状态是「拥有和迭代评估应该像维护单元测试一样日常」。这件事的收益不在当下——它是让你下一次换模型的时候，从「数周人工测试」变成「几天」。评估真正的 ROI 从来不体现在当前这个模型上，它体现在未来每一次模型升级上。这就是原文说的复利，也是大部分团队算错账的地方。

10信息来源与参考资料

• Anthropic Engineering，《Demystifying evals for AI agents》，2026-01-09。作者 Mikaela Grace、Jeremy Hadfield、Rodrigo Olivares、Jiri De Jonghe。
• 原文附录列出的评估框架：Harbor、Braintrust、LangSmith、Langfuse、Arize（Phoenix / AX）。
• 原文涉及的基准：SWE-bench Verified、Terminal-Bench、τ-Bench / τ2-Bench、BrowseComp、WebArena、OSWorld、CORE-Bench。
• 社区讨论：Hacker News 关于 coding agent 评估与数据污染的讨论串（含对 arXiv 2506.12286 的引用）；ai-eval.org 的读书笔记；QCon AI New York 2026 关于 pass@k 会高估 agent 可靠性的议题；关于评估方差与统计功效的分析（±4.4 个百分点置信区间、配对比对）。
• 文中引用的置信区间、52% / 37% 的离线—线上比例、68% 对 31% 的基准利用对比等数字来自二手分析与社区文章，未做独立复现，已在正文中标注。
• 本文中的 pass@k / pass^k 数值表为按公式 1−0.25^k 与 0.75^k 实测计算所得；配图由脚本生成。

微信公众号

欢迎关注「字与码」

如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。

X

X / Twitter

关注 @ax2_zicode

更即时的技术观察、新文章提醒和一些短想法会发在 X 上。