为什么重要
τ-bench（2024）问的是”模型能不能当好客服”，这个问题现在已经是入场券。Sierra 把问题抬了一层：谁来造那个干活的 Agent——而这件事正越来越多地交给编码 Agent 自己。
现有基准几乎不覆盖这个场景。真实客户交付的起点不是一份写清楚的 spec，而是一堆碎材料：政策文档、客服对话记录、通话录音、截图、流程图，以及一个可能藏着小 bug 的客户端 REST API。需求散在员工脑子里，团队得先提假设、找证据、做原型、再验证哪个杠杆真的有用。τ^τ-Bench 把这套流程整个搬进沙盒。
结果给这个方向泼了一盆冷水：最强的自动配置（Claude Opus 5 跑在 Claude Code 里）只通过 23.9% 的留出评估任务，专家撰写的参考线是 82.2%。差距接近 58 个百分点。
构建方式
- 外循环：编码 Agent（Developer）进入沙盒施工环境，可选地访谈模拟客户，提交一个完整可执行的客服 Agent
- 内循环：交付的 Agent 部署后面对模拟生产流量，用 τ³-bench 风格的完全可验证测试打分；这些测试在构建期对 Developer 保密
- 约束：必须从固定的模型菜单里选模型服务，且有每会话成本上限
- 陷阱：客户 REST API 可能有微妙缺陷，Developer 要判断 bug 在 spec 还是代码里
- 防记忆：airlineplus 与 retailplus 是 τ³-bench 对应域的重建版，换了品牌、数值和政策；原版作为冻结基线保留在代码库
- 支持的开发框架：Codex（默认）、Claude Code、开源的 OpenCode 与 Prime Agent，统一跑在同一个固定容器里，无公网出口
榜单靠 PR 提交，必须在封闭 runner 上跑完全部 53 个发布任务，禁止筛任务、禁止自报本地分数。代码 MIT 许可。
关键发现
- 失败方式和人类开发者一模一样：模型用浅层检索代替对业务记录的深读、几乎不跟客户沟通、对架构与服务成本几乎不做实验，跑通第一版设计就交付。
- 35/53 的任务压在 bankingknowledge：零售银行的卡片、存款、争议、转账，含 6 个内嵌策略的子域，是这个基准的难度主体。
- 它是第二周内第二个”抬高一层”的基准：同期 ByteDance 的 HarnessDev 问的是模型能不能给自己搭 harness。评测前沿正从”模型会不会做任务”移向”模型能不能造出做任务的系统”。
- 23.9% vs 82.2% 的缺口意味着：编码 Agent 在”有明确 issue 的既有代码库里改代码”上已经很强，在”没有 spec 的交付现场里造系统”上还很弱。
关联基准与展望
关联：TAU-bench、TAU2-bench、TAU3-bench（τ³-bench 是本基准的内循环）、SWE-bench Pro（同样是面向真实工程复杂度，但任务定义清晰得多）。
两个观察方向：一是 82.2% 这条专家参考线会不会像 τ-bench 当年一样，成为后续模型逐年逼近的目标——若 12 个月内自动配置爬到 50%，说明”Agent 交付”正在被自动化；二是这种外循环套内循环的评测结构（造出来的东西再被另一个基准打分）会不会成为 Agent 构建类任务的标准模板，它的成本比静态数据集高一个量级，但也是目前唯一能验证”交付物真的能用”的办法。