Agent 评测正在经历一场从“说得对不对”到“世界有没有改变”的范式转移。本文拆解了任务成功率如何欺骗团队、Agent 评测为何比 Chatbot 难一个量级，并提供了从结果分到轨迹分的完整方法论，以及一套可直接使用的评测工具箱。

一个订票 Agent 在演示时对用户说：”您的航班已预订成功。”对话记录无懈可击：理解了需求，查了航班，确认了价格，礼貌收尾。但打开订单数据库——空的。预订从未发生。

这个场景来自 Anthropic 对 Agent 评测的拆解。它点中了一个最容易被忽略的事实：轨迹（transcript）里说了什么，和环境里真的发生了什么，是两回事。

Chatbot 时代，评测的对象是”它说得对不对”；Agent 时代，评测的对象变成了”世界有没有按它说的改变”。这个转变听起来只有一句话，落到工程上是三重范式转移：

1. 从答案到终态——判成败不能听 Agent 自己说，要查环境里的最终状态；
2. 从一次到 k 次——一次成功不算成功，k 次全成才算可靠；
3. 从分数到轨迹——分数只告诉你成没成，轨迹才告诉你为什么、能不能修、敢不敢上。

这篇文章回答三件事：Agent 评测为什么难一个量级（一至三章）、可靠性怎么量（四至六章）、你要拍板哪七个决定（第七章起，含一个订票 Agent 从”感觉不错”评到”敢上线”的完整推演）。文末附一套可以直接拿走用的评测工具箱；赶时间的读者可以先看第七章和文末工具箱，再回头补原理。

一、现象：任务成功率是最会骗人的指标

几乎每个做 Agent 的团队都经历过同一个剧本：内部演示惊艳全场，试运行阶段口碑崩塌。中间隔着的，往往就是一个被误读的数字——任务成功率。

它至少有三种骗法。

第一种骗法：嘴上的成功。开头那个订票 Agent 就是典型。如果你的”成功判定”是让一个模型读对话记录、判断”任务是否完成”，那 Agent 一句自信的”已为您办理成功”就能骗过裁判。判成败必须去查环境终态：数据库里有没有那条订单、文件系统里有没有那个文件、退款流水有没有真的发生。

第二种骗法：一次的成功。Sierra 团队在 τ-bench 论文里给出过一组著名数字：GPT-4o 级别的函数调用 Agent，在零售客服场景单次通过率约 61%——看起来及格了。但换一个问法：同一批任务独立跑 8 次、8 次全部成功的概率是多少？不到 25%。demo 演示的是前者，用户体验的是后者。一个十次里挂四次的客服 Agent，在用户眼里不是”61 分的助手”，是”不可信的系统”。

第三种骗法：平均的成功。二元判分会把”识别对了问题、核验了身份、只是最后一步退款失败”的 Agent，和”第一句话就跑偏”的 Agent 打成同一个 0 分。平均成功率抹掉了这种差异，而这种差异恰恰是迭代方向所在。

分数和体感的裂缝有多大？两个公开结果放在一起看就明白了。OSWorld 在 2024 年发布时，最强模型只能完成 12.24% 的任务，人类基线是 72.36%；短短两年，Agent 基准的分数已经大幅上升。可在真实工作里，METR 对 16 名资深开源开发者、246 个真实 issue 做随机对照试验，得到的却是另一个结果：使用 2025 年初的 AI 编程工具后，开发者平均慢了 19%。METR 后续也提醒，这个结论只代表当时的工具、参与者和任务；到 2026 年，更新实验已经出现小幅提速信号，但选择偏差仍让结论难以下死。

基准进步是真的，产品价值却不会自动到账。

这道裂缝，就是你的评测体系要去填的东西。

二、原理：Agent 评测为什么难一个量级

给 Chatbot 打分像批改作文：一份输入，一份输出，对着评分标准打分。给 Agent 打分像组织驾照路考：要有考场，有路线，有考官，还得考不止一次。难度的来源可以拆成五条，每一条都动摇了传统评测的一个默认假设。

1. 多步执行，误差会复合。Agent 会跨多轮使用工具、修改状态、根据中间结果调整路线，前一步的小错会被后面的动作继续放大。做个最简单的算术：假设每一步 95% 可靠，一个 20 步任务的端到端可靠性是 0.95 的 20 次方——约 36%。Chatbot 评测看的是”一步”，Agent 评测看的是整条链路。

2. 动作有副作用，判分对象从文本变成世界。Chatbot 说错话，重新生成一次就好；Agent 做错事，环境状态已经改变——订单已下、文件已删、邮件已发。因此 outcome（终态）必须独立于 transcript 被检查。评 Agent，本质上是评它对世界的改动是否符合预期。

3. 非确定性，单次结果不可信。同一个任务跑两次，模型可能给出不同的行动序列。这不是 bug，是概率模型的本性。应对办法只有一个：同一任务跑多个试次（trial），用统计而不是单点说话。

4. 条条大路通罗马，标准答案不存在。很多团队会把”正确步骤序列”写成答案：先调 A 工具、再调 B 工具、参数必须是 C。问题是，Agent 经常找到评测设计者没预料到、但同样合法的解法。默认情况下，更该评它产出了什么，而不是它是否走了指定路线。步骤比对不是不能用——合规红线场景必须用——但不适合当通用判分方式。

5. 你评的不是裸模型，而是模型与脚手架的组合。同一个模型，换一套系统提示词、工具定义或上下文管理策略，就是另一个 Agent。这带来一个很重要的推论：模型升级，不等于你的 Agent 一定变好；模型跑分，也不等于你的产品得分。

这五条合在一起，解释了为什么”抽几个 case 看看感觉”在 Agent 时代彻底失效——你抽到的是某一次、某一路径、某一环境状态下的切片，而你要保证的是全分布上的可靠性。

三、概念地基：先统一语言，再谈方法

Agent 评测的讨论经常鸡同鸭讲，因为连”跑一次评测”里的”一次”指什么都没对齐。Anthropic 在《Demystifying evals for AI agents》里给出了一套完整术语，值得原样引进——下表是最常用的七个：

这套语言里最重要的一对概念，是 transcript 与 outcome 的二分。Anthropic 原文：”每个评分器评的，要么是轨迹的某个部分，要么是终态。”这就是本文标题里”结果分”与”轨迹分”的确切含义：

• 结果分（outcome grading）：查环境终态。订单表里有没有那条记录？代码改完测试过没过？τ-bench 是这条路线的代表——成败主锚点就是”把对话结束时的数据库状态与标注好的目标状态做比对”（少数任务还会用子串匹配检查关键信息是否真的告知了用户，但主判据始终是数据库终态）。话术再漂亮，也改变不了错误的终态。
• 轨迹分（transcript grading）：读全程录像。工具调了几次、有没有多余动作、中间推理是否合规、语气是否得体、烧了多少 token。

两者不是二选一，是分工：成败判定锚定 outcome，质量评估与失败归因依赖 transcript。只看结果分，你知道挂了但不知道为什么挂；只看轨迹分，你会被”说得漂亮”骗过。

轨迹分具体怎么打？可核实的做法有三层，按颗粒度从粗到细（这个三分视角来自 Langfuse 的 Agent 评测指南，业内常用黑盒/玻璃盒/白盒来称呼）：

1. 黑盒（最终响应）：只看输入和最后的回答——退化为 Chatbot 评测，Agent 场景下只适合当辅助信号。
2. 玻璃盒（轨迹层）：检查行动序列。这一层有两种工具。第一种是规则匹配：业内已有现成的四种轨迹比对模式（严格顺序 / 无序全有 / 只许子集防越权 / 至少超集保底动作），按合规敏感度选用即可——完整定义放在文末工具箱①，”必须先查政策再执行退款”这类顺序敏感场景用它。第二种是 LLM 裁判：用评分细则（rubric）让模型判断轨迹是否合理、高效，不要求逐步一致。（注意：这类工具语境里的”轨迹”通常只指消息与工具调用序列，比 Anthropic 的 transcript 定义窄——后者还包含推理和中间结果。）
3. 白盒（单步层）：对某个关键决策点做”单元测试”级检查，比如在给定上下文下该不该调用某工具、参数是否正确。

介于终态与轨迹之间，还有一个折衷技巧值得单独记：里程碑法（milestone）。AgentQuest（NAACL 2024）的做法是把最终解拆成一串必经的中间环境状态，进度分 = 命中的里程碑数 ÷ 总数——既不逐句读录像，也不只认最后一帧。论文里有一句非常漂亮的话：当里程碑只剩 1 个时，这个指标就退化为成功率。换句话说，成功率只是里程碑数为 1 的特例，结果分和轨迹分之间其实是一条连续谱。里程碑法既保留了”部分得分”的诊断能力，又不掉进”逐步比对”的僵化陷阱，是二元判分和全轨迹裁判之间性价比最高的中间档。

这一章收束成一句话：判成败，查终态；找原因，读轨迹；卡红线，用步骤断言——三件事各用各的工具，别混。

四、可靠性：pass@k、pass^k，与”次次成功”的距离

这一章讲 Agent 评测里最重要、也最容易被混用的一对指标。先把定义钉死，因为两者一个上标之差，语义完全相反。

pass@k：k 次里至少成一次的概率。这个指标最早由 Kulal 等人在 2019 年的代码生成研究中使用，OpenAI 的 Codex 论文（2021）给出了无偏估计公式并让它成为行业标准：每题生成 n 个样本，数出通过的 c 个，按组合公式估算”随机抽 k 个至少一个通过”的概率。它衡量的是能力上限——采样够多的话，模型能不能碰到正确解。

pass^k：k 次全部成功的概率。这是 τ-bench 论文（Sierra，2024）明确提出的新指标，读作”pass hat k”，定义是”k 次独立同分布的任务试次全部成功的概率，在所有任务上取平均”。它衡量的是可靠性——用户反复用，它是不是次次都行。

两条曲线从同一个起点出发（k=1 时两者相等），方向却完全相反：k 越大，pass@k 单调上升，pass^k 单调下降。一句话总结这个数学事实：

多采样让 demo 更好看（pass@k），也让生产更露馅（pass^k）。

Anthropic 在评测指南里给了一个任何人都能心算的例子：单次成功率 75% 的 Agent，连续 3 次全对的概率是 0.75³ ≈ 42%。还记得第一章那组 τ-bench 数字吗？它的完整版更扎心：GPT-4o 函数调用 Agent 在零售域 pass^1 是 61.2%，换到航空域只有 35.2%，而零售域的 pass^8 跌破 25%（数字取自论文首发版；官方仓库后续复跑为 60.4%/42.0%，量级结论不变）。也就是说，一个”及格”的 Agent，只要用户用满 8 次，多数用户会至少撞上一次失败。

怎么选？Anthropic 的建议归结起来就是：成一次就有价值的工具，看 pass@k；一致性至关重要的 Agent，看 pass^k。代码补全给你 5 个候选，你挑一个能用的就行，pass@5 是合理指标；客服 Agent 替用户改签机票，没有”挑一个”的机会，pass^k 才反映真实体验。

k 定多少？没有权威魔法数字，这本质是一道风险×成本的产品题：面向内部工具，k=3 起步；面向付费用户的交易型场景，k=8 不过分。k 越大统计越可信，账单也越贵——具体的算账方法放在第七章。

最后记一条实用的诊断规则，来自 Anthropic 原文：如果一个任务跑了很多试次通过率是 0%（比如 0% pass@100），大概率不是 Agent 不行，是任务本身坏了——题目歧义、环境配错、或者裁判有 bug。别急着怪模型，先查自己的考题。

五、环境工程：评测的下半场是搭考场

Agent 评测最容易被低估的成本，不是出题和判分，而是搭环境、维护环境，再让它一次次回到相同起点。公开基准的工程实现已经把这件事说得很清楚。

每道题都要配一个世界。OSWorld 是最直观的例子：369 个任务，论文明确写着每个任务都带”一份详细的初始状态配置 + 一个定制的基于执行的评测脚本”。369 道题，369 套初始状态，369 个判分脚本。出一道”把这份 PPT 里的图表改成柱状图”的题，你得先造出那份 PPT、那个装好 LibreOffice 的虚拟机、以及一个能打开文件验证图表类型的检查脚本。

跑完一次，世界要能倒回去。Agent 会真的改动环境，所以环境必须可重置。OSWorld 的做法写在源码里：每次 reset，虚拟机回滚到名为 init_state 的快照，再注入本任务的初始状态。WebArena 的 README 更直白：跑完 812 个样例后，必须按指引把环境重置回初始状态——它甚至要求评测必须自建站点，官方演示站”仅供浏览”，因为被千百个 Agent 踩过的环境已经不是干净考场了。

试次之间必须隔离，否则分数会被污染。残留文件、缓存数据和资源耗尽会让不同试次彼此关联：你看到的波动可能来自基础设施，而不是 Agent。Anthropic 在内部评测中甚至观察到 Claude 翻看前几个试次留下的 git 历史，借用了”前人”的答案。Agent 不是故意作弊，它只是把环境里能用的信息都用了。

脏环境喂出高分，你还以为是能力。

环境自己也会出错，而且错得很隐蔽。OpenAI 当年为了修复原版 SWE-bench 的题面、测试和环境问题，组织 93 名有 Python 经验的开发者审查 1,699 个样本，筛出 500 道题组成 SWE-bench Verified。可到了 2026 年，OpenAI 又公开停止用它代表前沿编程能力：对 138 道模型经常失败的题做复核后，至少 59.4% 仍存在实质性的题面或测试问题。评测集不是一次建好就永远可信，它本身也要持续回归。

基础设施本身就是一个变量。Anthropic 在 2026 年 2 月的后续文章《Quantifying infrastructure noise in agentic coding evals》里量化了这件事：仅仅是评测机器资源配置的差异（最富配置 vs 最穷配置），就能在 Terminal-Bench 2.0 上造成 6 个百分点的分差（p < 0.01）——超过了榜单头部模型之间的差距。你以为在比模型，其实在比谁的 CPU 多。

环境里可能还有”人”。τ-bench 评的是客服场景，所以环境里除了 mock 数据库和 API，还有一个由 LLM 扮演的用户。于是，评测结果同时受”被测模型”和”用户模拟器”两重非确定性影响；用户模拟器一换版本，分数也可能跟着动。

落到你自己的产品上，环境保真度是一道三档选择题：

评测起步期用纯 mock 完全够——重要的不是环境多真，而是每个试次从同一个干净状态出发。保真度可以逐步加码，隔离纪律从第一天就不能破。

六、裁判：谁来打分，以及谁来评裁判

判分逻辑（grader）决定你的评测产出的是数据还是噪声。Anthropic 把裁判分成三类，这个分类可以直接套用：

Agent 场景的用法有明确的优先级：能用代码裁判的先用代码裁判，锚点放在终态校验上——查数据库、查文件系统、跑测试，这些判定客观且不可被话术欺骗。模型裁判留给代码判不了的维度：合规话术、方案质量、冗余程度。

模型裁判有三条纪律，出自 Anthropic 原文，每条都是踩过坑的人写的（这里只给结论，裁判校准本身值得另写一篇长文）：

1. 必须和人类专家校准——确认模型打分和人工打分没有系统性分歧之前，模型裁判打出的不是分数，是噪声；
2. 每个维度用一个独立裁判，好过让一个裁判打所有维度——维度混在一起，分数会互相污染；
3. 给裁判留退路——明确指示”信息不足时输出 Unknown”，否则裁判会像所有模型一样，硬着头皮编一个判断。

比”怎么选裁判”更重要的是一个多数团队从没想过的问题：裁判自己坏了怎么办？公开案例足够触目惊心：

• Anthropic 复核 CORE-Bench 时发现判分脚本在数值精度上有 bug——只认”96.12″、不认”96.124991″——错杀了大量正确答案，此外还有题面歧义和无法复现的随机任务。修复这些评测问题、并换用约束更少的脚手架后，Claude（Opus 4.5）的得分从 42% 跳到 95%。这 53 个百分点里，没有一个来自模型变强。
• 2025 年的一篇评测方法论文（Agentic Benchmark Checklist）直接点名：τ-bench 会把空响应判为成功，SWE-bench Verified 的部分单测不充分——这类缺陷对 Agent 表现的高估或低估，相对误差最高可达 100%。
• METR 的任务集里有一道题，题面要求”达到阈值”，判分脚本却要求”超过阈值”——精确听话的模型反而被判失败。

所以成熟团队会做”评测的评测”：每道任务配一个参考解（reference solution）——一个已知能通过所有裁判的标准输出。参考解过不了，说明裁判或环境坏了，这道题的所有历史分数都要打问号。Anthropic 还给了一条好任务的黄金标准：”两位领域专家独立判卷，结论应该一致。“达不到这条的任务，先修题，再谈分。

最后是防作弊。HAL 团队在大规模评测日志里观察到，有 Agent 直接去 HuggingFace 搜基准答案，也有 Agent 在订票任务里滥用信用卡。更微妙的是”评测意识”：Anthropic 在 2026 年披露，Claude Opus 4.6 曾自己推断出”我正在被评测”，随后定位并解密了答案。环境里只要留着答案、历史记录或能绕过判分的后门，能力足够强的 Agent 迟早会找到。

七、决策：产品经理真正要做的七个决定

前面六章是”是什么、为什么”，这一章是”你要拍板什么”。评测体系不是工程团队的自留地——下面七个决定，每一个都直接影响产品节奏、成本和上线风险，每一个都应该由产品经理牵头拍板。

决定一：评什么，题从哪来。不要憋大而全的题库。Anthropic 的量化建议非常解压：”从真实失败中提取 20-50 个简单任务，就是一个很好的开始”——早期 Agent 的问题效应量大，小样本就能测出显著差异。题的最好来源是真实翻车现场：客服工单、用户投诉、内部试用的失败记录。更进一步的姿势叫评测驱动开发（eval-driven development），Anthropic 原文：”在 Agent 具备某项能力之前，先建好定义这项能力的评测，然后迭代到通过为止。”先写考题，再教学生。

决定二：成败锚点定在哪。默认答案：outcome。写下你的产品里”世界被正确改变”的判据清单——订单状态、数据落库、文件产出。然后决定哪些质量维度值得进轨迹分（合规、效率、语气），以及部分得分怎么给（推荐里程碑法，见第三章）。

决定三：k 定多少，门槛画在哪。按场景风险分级：只读查询类 k=3、写操作类 k=5、资金交易类 k=8，门槛用 pass^k 而不是 pass^1（数字是我的判断，不是行业标准——行业还没有标准，这正是你要自己拍板的原因）。配套一条统计纪律：报分数时带上试次数和波动范围，”通过率 70%（30 任务 × 4 试次）”和光秃秃的”70%”是两种可信度。

决定四：环境保真度买哪一档。纯 mock / 容器沙箱 / 影子环境，三档的取舍见第五章。这是一笔真实的预算决策：环境每高一档，可信度上升，维护成本也上升。唯一不可谈判的是隔离纪律——试次之间共享状态的评测，跑得再多都是废数据。

决定五：裁判组合与校准预算。代码裁判打底、模型裁判补细腻维度、人工做金标和抽检。要预算化的是最后一项：模型裁判上岗前的人工校准、上岗后的定期抽检，都是持续成本，不是一次性投入。

决定六：门禁怎么设，题库怎么长大。Anthropic 的能力/回归二分法直接好用：能力评测（capability evals）问”它能做好什么新东西”，起步通过率应该很低——全绿的能力评测说明题太简单了；回归评测（regression evals）问”以前会的现在还会吗”，通过率应该接近 100%。两者之间有一条”毕业”通道：通过率爬高的能力评测，转入回归套件持续跑，防止能力回退。发布门禁挂在回归套件上（例：核心任务 pass^3 ≥ 90% 才能发版），每次改动跑核心子集，大版本前跑全量——Anthropic 的说法是，维护评测应该”像维护单元测试一样成为例行公事”。

决定七：线上对账与所有权。离线评测不是终点。Anthropic 用安全工程的瑞士奶酪模型来描述完整体系：自动化评测、生产监控、A/B、用户反馈、人工轨迹审阅——每层都有洞，叠起来才挡得住。落到执行：上线后按比例采样生产轨迹，定期人工审读，新的失败案例回流进能力题库（这就是决定一的题源循环）。最后明确所有权：评测归谁维护、分数异动谁响应——没有 owner 的评测体系，三个月后就是一堆没人信的旧数字。

这套体系要花多少钱？给一个可以套用的估算公式：

单轮评测成本 ≈ 任务数 T × 试次 k ×（单试次输入 token × 输入单价 + 单试次输出 token × 输出单价）+ 模型裁判同理另计

算一笔账。为了演示计算方法，下面用每百万 token 输入 3 美元、输出 15 美元这一档价格。真正立项时，只需要替换成你实际使用的模型价格：

• 规模假设：30 个任务 × 4 试次 = 120 个试次；每试次平均输入 4 万 token（系统提示词 + 工具定义 + 多轮上下文）、输出 6 千 token；用一档 $3/$15（每百万 token）的中档模型。
• 输入账：120 × 40k = 4.8M token ≈ $14.4；输出账：120 × 6k = 0.72M token ≈ $10.8。跑一轮约 $25。
• 模型裁判另计：每试次再读 1.5 万 token、写 800 token，约 +$7。全套一轮 ≈ $32，一天迭代三轮 ≈ $100。
• 降本开关一：提示词缓存。各家缓存读取价大约在标准输入价的一到三成（有的低到一成），而评测里系统提示词和工具定义天然是稳定前缀，命中率极高。
• 降本开关二：便宜模型跑高频回归，贵模型只跑大版本全量。
• 一个坑：不同模型的 tokenizer、缓存规则和工具调用开销并不一样。别只拿 token 单价横比，最好用同一批真实任务各跑一轮，再比较整单成本。

八、案例推演：把一个订票 Agent 从”感觉不错”评到”敢上线”

以下案例纯属虚构，但每一个坑都有第五、六章的公开案例做原型。

设定：差旅平台”途安”要上线订票 Agent，能力范围是机票查询、改签、退票、差标合规检查。团队试用两周，”感觉挺好”，准备上线。产品经理老周决定先把七个决定走一遍。

第 1 周：出题与搭环境。老周没有开脑暴会编题，而是从客服工单里挖了近三个月的真实差旅纠纷，提炼出 30 个任务——”改签到明天最早的航班，但不能超差标”、”退票并把款退回原支付方式”、”帮同行的两位同事一起改签”。每道题按黄金标准过筛：两位客服主管独立判卷，判定不一致的题当场修题面。环境用纯 mock 起步：假航司 API、可快照重置的订单库、一份差标政策文档，另用一个 LLM 按”着急出差的销售”人设扮演用户。判分锚定终态：改签是否落库、退款流水是否生成、差标是否被违反——Agent 说什么，一概不作为成败依据。轨迹层加三个 rubric 维度：改签前是否核验了差标、有没有多余的工具调用、话术是否合规。

第 2 周：第一轮数字，与第一盆冷水。30 任务 × 4 试次跑下来，pass^1 = 68%——团队觉得”及格了”。拆开看分布才见真相：12 个任务基本次次过（单次成功率在 95% 一档），18 个任务基本是掷硬币（单次约五成）。直接数”四次全过”的任务，占比约四成；再把两档按 0.95⁴ ≈ 81%、0.5⁴ ≈ 6% 折算，真实的 pass^4 只有约 36%——4 试次的小样本还会略微高估它。无论按哪个口径，都远低于 68% 给人的安全感。”感觉挺好”的两周试用，撞上的恰好多是那 12 个稳定任务。老周把上线时间往后推了三周，理由一句话：六成的高频场景在掷硬币，这不是调参能糊过去的。

第 3 周·翻车一：裁判错杀。归因时发现一批诡异失败：终态明明正确，任务却被判挂。查下来是一条辅助断言写死了字符串”改签成功”，而 Agent 的话术是”已为您完成改签”。修复方式照抄 CORE-Bench 的教训：删掉所有对话术的字符串断言，成败只认数据库字段；同时给 30 道题各配一个参考解，每周跑一遍——参考解过不了，先修题和裁判，再看模型分数。

第 3 周·翻车二：环境串味。又一批异常：某几个任务的通过率高得不合常理。查轨迹发现，前序试次残留的测试订单没被清掉，后续试次的 Agent 直接”发现”了一条现成订单，顺手就用了——和 Claude 翻 git 历史的公开案例如出一辙。修复：每个试次强制回滚快照，跑一致性抽查确认试次间零共享状态。清完这个泡沫，那几个任务的真实通过率掉了 15 个百分点——之前的高分是环境送的。

第 4-5 周：迭代与毕业。接下来的迭代全部对着 18 个”掷硬币任务”打：拆出失败模式（差标核验时机不稳定、多人改签时的状态管理混乱），改系统提示词、改工具返回结构，每次改动跑核心 10 题（约 20 分钟、几美元），每晚跑 30 题全量。三周后 pass^1 爬到 92%，pass^4 到 81%。其中 22 个任务连续两周稳定全过，”毕业”进回归套件；发布门禁定为：回归套件 pass^3 ≥ 90%；资金相关 6 题单独加跑到 8 试次，门禁 pass^8 = 100%——迭代期全员 4 试次是预算决定，放行标准按风险分级表升到 k=8，k 本身就是一个产品决策；任何一条不满足就不发版。

上线后。生产环境每天采样 5% 的真实轨迹，每周人工审读 20 条。第一个月就从线上抓到两类评测集里没有的失败（联程航班、儿童票），按”决定一”的循环回流成新的能力任务。老周在复盘里写了一句话，可以当这一章的结论：

上线前评测回答”敢不敢上”，上线后评测回答”下一步修什么”——它不是一次验收，是产品的例行体检。

九、边界：榜单能告诉你什么，以及评测替代不了什么

最后回答两个问题：公开榜单还能信几分？自建评测又有什么做不到？

榜单是模型的体检报告，不是你产品的体检报告。这句话有三层结构性的原因，每层都有硬证据。

第一层：污染与记忆。公开基准的题目、代码库和答案长期存在于互联网上，很难保证没有进入训练数据。2026 年，OpenAI 公开停止报告 SWE-bench Verified，原因之一正是污染：他们测试的前沿模型都能复现部分题目的原始补丁或高度具体的解法信息。此时高分里混进了多少能力、多少记忆，已经很难拆开。

第二层：饱和与测量噪声。当一套基准从三成一路涨到八成以上，剩下的失败越来越可能来自坏题、边界口径和环境噪声，而不只是模型能力。Anthropic 在 Terminal-Bench 2.0 上测到，仅资源配置差异就能带来 6 个百分点的分差。榜单头部只差两三分时，你看到的名次可能没有想象中精确。

第三层：与真实分布脱节。基准为了可重复，必然会缩小任务范围、固定环境和成功条件；真实用户却会带来长尾需求、脏数据、打断和跨系统依赖。METR 的随机对照试验之所以重要，不是因为”慢 19%”能代表所有 AI 编程工具，而是因为它测的不是一道公开题，而是真实开发者在熟悉代码库里完成真实 issue。它提醒我们：能力提升和生产价值之间，还隔着产品、流程和使用方式。

所以榜单最适合做两件事：选模型时做初筛，看能力演化时做温度计。它不能替你回答产品能不能发版。真正的放行依据，只能来自与你的用户、任务、工具和风险一致的自建评测。

自建评测也有边界，诚实列出三条：

1. 品味测不出来。rubric 能判合规判效率，判不了”这个回答让人舒服”。这也是人工轨迹审读永远不能省的原因——数字看健康度，人看灵魂。
2. 方向感测不出来。评测优化的是已定义的能力，”该不该做这个能力”是它回答不了的问题。评测集本身就是产品判断的凝结，题库出偏了，分数越高偏得越远。
3. 评测会腐坏。模型换代、用户分布漂移、题目老化，都会让一套曾经可信的评测变成自我安慰。评测过拟合是新型自欺：对着同一套题优化半年，分数上去了，产品未必。解法在第七章的循环里——线上失败持续回流，题库保持新陈代谢。

文末工具箱

① 评测视角选择画布

附：规则匹配的四种轨迹比对模式（LangChain agentevals）

② 轨迹标注 Schema（字段级，可直接建表；共两张表）

试次表（每次试跑一行）：

步骤表（每步一行，外键 trial_id）

③ pass^k 门禁参考模板（k 与门槛均为起步建议，按业务风险自调）

④ 上线前评测检查清单（四组 20 条，逐条打勾用）

环境组

• 每试次从干净快照启动
• 试次间零共享状态（抽查验证过）
• 环境故障与 Agent 失败在归因码中分开统计
• 用户模拟器版本已固定
• 基建资源配置已固定（防基建噪声）

裁判组

• 成败锚定终态而非话术
• 每题配参考解且每周复跑
• 无对自然语言话术的硬字符串断言
• 模型裁判已与人工校准
• 裁判有”Unknown”出口
• 已做防作弊检查（环境里无答案、无历史残留）

统计组

• 每任务试次数 ≥ 3
• 报告分数附任务数与试次数
• 核心场景用 pass^k 而非 pass^1
• 0% 通过率的任务已人工复核题目本身
• 两位专家独立判卷一致

流程组

• 能力/回归两套件已分开
• 发布门禁已挂在回归套件上
• 线上轨迹采样与回流机制已定
• 评测体系有明确 owner

⑤ 七个决定一页纸

现在就把这套工具带进下一次 Agent 评审：先把七个决定逐项写清，再让产品、算法和工程用同一套任务、指标和门禁说话。当 pass^k 不再只是一个公式，而成为共同的风险语言，评测才真正开始运转。