读基准的最高阶读法：不是看分数，而是拆设计。τ-bench 的模拟用户与 policy 显式化、Terminal-Bench 的任务四件套与「229 投稿只收 89」的策展流水线，最后提炼成「好评测七基因」验收清单——你建评测集时逐条对照即可。
先修：a22、a23（读基准两讲）。准备自建评测集的人：先读这篇拿「好评测基因」清单，再动手写第一个任务。与 a22/a23（读基准）连读，构成完整的「读-拆-建」三步。
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
指令（含时限）+ Docker 初始化环境 + 确定性测试集 + oracle 参考解。测试只验最终容器状态，允许多条合理路径。
① 证明任务可解（别让 Agent 替无解的题背锅）；② 校验评分器——oracle 喂给评分器必须判满分，否则是评分器的 bug。
问一句：有没有一条不真正解决问题却能骗过判定的捷径（如判定只查「回复里有没有已退款三个字」）？发现就在任务设计阶段堵上——Terminal-Bench 甚至用对抗性 exploit agent 专门找这类洞。
上方为本站原创导读，下方为原文完整收录，便于对照阅读。
前两讲我们快速扫过了一堆基准。这一讲我们慢下来，挑两个特别有代表性的——τ-bench 和 Terminal-Bench——深拆。目的不是再多认识两个基准，而是透过它们，看清一件更值钱的事：一个好的评测，到底是怎么造出来的？我们要从这两个案例里，提炼出可迁移的设计模式——它们会直接喂给下一讲（你为自己业务建评测集时，照着用）。
它要啃的硬骨头。真实客服 Agent 最难评测的地方在于：它不是答一道题，而是和用户多轮周旋，同时还得守住业务规则。怎么把这么"活"的东西，变成一个能批量、可复现地自动跑的评测？τ-bench 给了一套漂亮的答案。
拆开看它的设计，四个关键零件：
它跑起来长这样（示意）：模拟用户被设定成"一个买了鞋、想退货的不耐烦顾客"，目标是"把鞋退了拿回钱"。用户是"活"的、会答非所问（"忘了订单号"），逼着 Agent 多轮周旋；而 Agent 每一步都被 policy 约束（必须查送达时间、必须确认未穿着）。评测结束后，τ-bench 既查数据库里退款到底发起没有（outcome），也查它有没有在该卡的地方守住 policy。把"和一个会乱来的真人聊天"变成一个能自动跑一万遍的评测——这就是模拟用户的威力。
你能借鉴的模式：
用 LLM 模拟用户很妙，但它带来一个"套娃"问题：这个模拟用户本身可信吗？如果它太配合（你一问就乖乖报订单号），就测不出 Agent 应对"难缠用户"的能力；如果它太混乱（前后矛盾、提了需求又自我否定），又会制造出根本无解的对话，反过来污染评测结果。
这其实是 Agent 评测里一个普遍现象——评测组件本身也需要被评测。你的模拟用户、你的 LLM 裁判，都是评测系统的一部分，它们的质量直接决定结论的质量。τ-bench 的应对是：给模拟用户清晰的人设、目标和约束，让它的行为可控、可复现。给你的启示也很直接：当你用一个 LLM 去驱动评测的某个环节时，别忘了也校准它——比如人工抽检几段模拟对话，确认"这个模拟用户像不像真实用户"。
τ-bench 的升级版 τ²-bench 引入了"电信客服"域（telecom，宽带、手机报障这类技术支持）这种双向控制场景——用户和 Agent 都能调工具、都能改环境（想象用户在自己手机上点设置、Agent 在后台改配置，两边协同排障）。这把评测难度又抬了一层：你不仅要评 Agent 自己做得对不对，还要评它和另一个会行动的主体怎么协作、怎么交接。如果你的产品里有"人和 Agent 共同操作"或"多个 Agent 协作"的场景，这正是要参考的设计。
它要啃的硬骨头。Agent 越来越强，评测就越需要够难、够真实的任务——而且这些任务还得可靠（Agent 失败必须是因为它真不行，而不是因为题目有毛病）。Terminal-Bench 选择"终端"作为考场（通用、可扩展），并围绕"怎么造出高质量任务"下了死功夫。
拆开看它的任务结构。它的每个任务由四件套组成，这套结构本身就值得你抄：
而且它是结果导向（outcome-driven）的——测试只验最终容器状态对不对，不管 Agent 用了什么命令、走了什么路。于是同一个任务，多种合理解法都被接受。
还有一层别忽略：它的 harness。Terminal-Bench 用一个叫 Harbor 的框架来跑评测——把"任务环境搭建、容器管理、Agent 调用、测试执行"这些事，用一套标准化的方式统一处理，让不同的 Agent、不同的环境都能套同一套流程跑。一个好基准，不只是好题目，还有一套好 harness 把题目可靠地跑起来。
最值得学的，是它近乎偏执的策展流程。任务进库前要过三道关，对应三条标准：
为保证这三条，它的质检流水线狠到什么程度？先自动检查几个幼稚失败模式（比如一个"什么都不干"的假 Agent 必须失败、oracle 必须能通过）→ 给出题人一份人工纠错清单 + 跑一套基于 LLM 的质量检查 → 资深评审和出题人一起人工核对 → 跑一个"对抗性 exploit agent"专门去找能作弊的设计漏洞 → 再两位人工复核才收录。最终：229 个投稿，只收了 89 个；平均每道入库的题，花了约三个评审小时。
它的题长这样。Terminal-Bench 的任务都源自真实工作流，且五花八门——有的让 Agent 在终端里训练一个机器学习模型，有的让它把一段 COBOL 老代码迁移成 Python，还有的让它从源码编译出整个 Linux。难度从"专家一小时"到"junior 一周以上"都有。
那个"对抗性 exploit agent"在抓什么？举个例子：假设有道题要求"写脚本算出日志里的错误总数"，测试是"检查输出文件里的数字等于 42"。一个偷懒解法是——Agent 根本不解析日志，直接 echo 42 > output，测试照样通过，但它什么都没真做。Terminal-Bench 的 exploit agent 就专门去找这种"能作弊蒙混过关"的题，把它们打回重做。这给你一个永远适用的提醒：写评测时先问一句——这题能不能被一行投机取巧的代码骗过去？
你能借鉴的模式：
把两个案例叠在一起，你会看到一组反复出现的特征。我把它们列成一张清单——这就是"好评测"的共同基因，也是你建自己评测集的验收标准：
| 基因 | τ-bench 怎么体现 | Terminal-Bench 怎么体现 |
|---|---|---|
| 判定标准清晰 | 明文 policy + 数据库状态 | specificity：指令穷举合格状态 |
| outcome 导向 | 查数据库最终状态 | 验容器最终状态 |
| 允许多路径 | 不规定对话怎么走 | 不管用了哪些命令 |
| 有参考解 oracle | —（强调可验证状态） | 每题配 oracle，验可解性+校验评分器 |
| 防作弊 | policy 约束 + 任务设计 | integrity + 对抗 exploit agent |
| 重视可靠性 | pass^k | 时限 + 多次审核 |
| 人工把关质量 | 领域建模 | 每题约 3 评审小时、229→89 |
你不需要、也做不到把这七条都拉满（你没有 Terminal-Bench 那种评审预算）。但它给了你一把尺子：当你建自己的评测集时，对照这张表问一句——我的任务有判定标准吗？验的是 outcome 吗？有参考解吗？能被作弊吗？命中得越多，你的评测越可信。
七条基因不必一次拉满，但有两样几乎对所有团队都立竿见影，建议你优先学：
第一样，给关键任务配 oracle 参考解。这是性价比最高的一步。不必给所有任务都写，但至少给那些最核心、最容易判错的任务，各写一条"已知正确的处理轨迹"。它一举两得：一是确认这题确实可解（别让 Agent 替一道根本无解的题背锅）；二是反过来校验你的评分器——把 oracle 喂给评分器，它理应判满分；如果没有，那是你评分器的毛病，不是 Agent 的。
第二样，给每个任务做一次"作弊体检"。学 Terminal-Bench 那个 exploit 思路，对每个任务问一句：有没有一条不真正解决问题、却能骗过判定的捷径？比如你的判定只查"回复里有没有'已退款'三个字"，那 Agent 不退款、光嘴上说就能过——这种洞，要在任务设计阶段就堵上。
这两样都不要大预算，却能立刻把你评测的可信度抬上一个台阶。剩下的（模拟用户、pass^k、全维覆盖……），随业务需要再逐步补。
最后泼盆冷水。即便策展到 Terminal-Bench 这种程度，它的作者依然承认——基准仍可能有缺陷。这不是谦虚，是事实：再严的流程，也挡不住"题目本身有隐藏歧义""测试覆盖不全""被新模型背过"这些问题。
最现成的例子就是 SWE-bench：它的原始全量里，本就混着一批描述含糊、测试太弱的题（弱到会放过错误的补丁），后来才靠专业开发者人工清洗出 Verified 版。连这么权威的基准都需要事后大修，说明一件事——质量不是"造出来"就完事的，是持续"养"出来的。
所以记住：对任何基准（包括你自己造的），都别把它的分数当圣旨。把评测集当成需要持续审视、持续修补的活东西。
这一讲我们深拆了两个基准，落点全在"可迁移的设计"：τ-bench（用 LLM 模拟用户让交互可复现、把 policy 显式化并纳入评分、用数据库状态验 outcome、用 pass^k 看可靠性）、Terminal-Bench（任务四件套、outcome-driven 允许多路径、以及一套近乎偏执的策展流程）。两者共有的"好评测基因"——判定清晰、outcome 导向、多路径、有 oracle、防作弊、重可靠、人工把关——构成你建评测集时的验收清单。