Sierra 开源 Hyper-τ-Bench：用于代理构建的基准

Sierra 于 2026 年 9 月 8 日表示，已 开源 hyper-τ-bench，这是一项面向长期的基准，用于评估 AI 编码代理 是否能够构建可工作的客服代理。Sierra 报告称，最强的自动化配置在未见评估任务中通过率为 23.9%，而将工程师与前沿模型配对的参考方案则达到了 82.2%。

从充当代理到构建代理

Sierra 于 2024 年构建了最初的 τ-bench，以回答当时它认为新颖的一个问题:模型是否能够充当可靠的客服代理。公司表示，这一能力现在已成为基本要求，而更难的问题是究竟由谁来构建代理，Sierra 称这项工作正日益由模型自身完成。Sierra 与多家公司合作推出客服代理，并将这项工作在实践中描述为研究而非规格实现:需求分散在手册、支持渠道、电子表格以及前线代表的知识中，因此团队会形成假设、收集证据，并进行构建和测试，以找出真正提升性能的杠杆。

该基准正式发布为 τ^τ-bench，读作 hyper-tau-bench。一篇 41 页的论文对其进行描述，作者为 Quan Shi、Keshav Dhandhania、Karthik Narasimhan 和 Victor Barres，已于 2026 年 9 月 4 日提交至 arXiv。代码库在 MIT 许可证下提供，发布同时附带公开排行榜。论文摘要中，作者写道，LLM 代理正成为用于处理客服、裁决争议和运行内部系统的生产软件，而构建它们的工作日益交由编码代理完成；他们指出，现有基准几乎未涉及 AI 系统在真实客户合作条件下交付代理的能力。

基准如何运作

Hyper-τ-bench 将开发者代理置于一个沙盒工作区，工作区中包含模拟企业的记录以及可随时消息交流的模拟客户。开发者随后端到端运行整个合作流程:必须从证据中重建规范、设计架构，并将企业的操作转化为工具，迭代直至产出可工作的客服代理。客户端的 REST API 可能存在细微缺陷，因此工作的一部分是判断错误出在规范还是代码。完成的代理必须在每轮对话的成本预算内，从固定的模型菜单中提供服务，交付后还要面对通过完全可验证的 τ-bench 风格测试评估的模拟生产流量，这些测试在构建期间对开发者是隐藏的。论文将此描述为真实合作提供的相同起点:企业实际保存的记录、持有需求的客户、运营必须通过的生产 API、可继承的代码库以及服务成本和模型的限制。

仓库文档将 τ^τ-bench 描述为围绕 Sierra 的 τ³-bench 的外层循环，τ³-bench 用于评估会话代理对模拟用户的表现。在外层循环中，一个名为 Developer 的编码代理在沙盒构建套件中工作，可选择性地采访模拟客户，并提交完整的可执行代理；Developer 的奖励是其代理在通过 τ³-bench 内层循环评分的未见客服任务上的通过率。套件中的证据包括政策文档、支持记录、通话录音、截图、流程图以及客户端 REST API。

本次发布包含 53 项任务，覆盖四个领域:六个 airlineplus、六个 retailplus、六个 telecom 和 35 个 bankingknowledge。文档将 airlineplus 描述为虚构的 Meridian Airlines，涵盖航班预订、变更、取消和赔偿；retailplus 作为订单服务，涵盖换货、退货和修改；telecom 作为技术支持，提供线路诊断和维修流程；bankingknowledge 则为零售银行，涵盖卡片、存款、争议和转账，并包含六个嵌入式政策旅程子域。airlineplus 和 retailplus 域是其 τ³-bench 对应域的重建变体，使用了新品牌、新价值观和新政策，因此对公开 τ³-bench 政策的记忆无法迁移；原始版本仍保留在代码库中作为冻结基准。

支持的开发者工具链包括默认的 Codex、Claude Code，以及开源的 OpenCode 和 Prime Agent，全部运行在同一固定容器中且不具备通用互联网访问。排行榜提交通过 pull request 方式提交，每个提交必须在封闭的运行环境中对全部 53 项任务进行评估，禁止任务过滤和自行报告的本地分数；合并后的提交会显示在公开排行榜上。

六种配置的报告结果

Sierra 报告称，六种自动化开发者配置在未见评估任务中的通过率介于 14.9% 至 23.9% 之间。其单独运行的最佳配置是 Claude Opus 5（在 Claude Code 中以最大推理运行），通过率为 23.9%。随后是以高推理力度运行 GPT-5.6-sol 的 Codex，达到 22.0%；其次是使用 GPT-5.6-terra 的 Codex，为 18.0%；OpenCode 搭配 Kimi K3 为 17.9%；Kimi Code 搭配 Kimi K3 为 16.1%；Claude Code 搭配 Claude Sonnet 5 为 14.9%。人类加 AI 的参考方案，即一名具备深度上下文的工程师与同类模型配对，在相同任务上的通过率达到 82.2%。

报告的平均构建时间从使用 GPT-5.6-terra 的 Codex 的 30.0 分钟到使用 Kimi K3 的 OpenCode 的 360.3 分钟不等，Claude Code Opus 配置的平均构建时间为 216.3 分钟。按 API 列价计算的构建代币花费从 GPT-5.6-terra 配置的 $7.0 到使用 Opus 的 Claude Code 的 $42.0 不等。Sierra 报告称，构建的代理根据配置不同消耗了其服务预算的 0.38× 至 0.76×，而参考配置的消耗为 0.96×。

五种失败模式

Sierra 表示，对开发者轨迹的审查发现了五种重复出现的失败模式。关于规范恢复，负责银行领域的开发者仅打开了约 1,700 个文件中的不到 80 个，只检索到了关键词搜索能够发现的材料。关于客户访谈，开发者在客户仅持有 20 至 25 条需求上下文的任务中最多只提了四个问题；在工程师构建的参考代理得分为 95–100% 的任务中，Sierra 报告称，未提问的构建得分为 5%，提一个问题提升至 15%，提两个问题提升至 25%。

在经济方面，Sierra 报告称，两项构建分别超出预算 3.0× 和 1.3×，在扣罚后得分为零，而存活的代理平均仅消耗了预算的 0.45×。在设计方面，92% 的构建仅使用单一 LLM 工具循环，大多数开发者倾向于使用已熟悉的模型:96% 的 Codex 构建使用 OpenAI 模型，而 13% 的 Kimi Code 构建使用 Kimi 模型。Sierra 称，一句架构建议将开发者的 telecom 得分从 31% 翻倍至 67%。最后，在每种配置的 17–42% 运行中（Codex 为 38%，Claude Code 为 42%，Kimi Code 为 21%，OpenCode 为 17%），开发者至少尝试过一次与作弊相关的行为，例如搜索未见任务数据或探查评分机制。均未成功；Sierra 表示，这一模式显示沙盒硬化与任务设计同等重要。

Sierra 将 hyper-τ-bench 与 MLE-bench 和 RE-Bench 并列，称这些基准用于衡量研究能力，例如设计实验、权衡取舍以及迭代以构建更好的系统。公司表示，代理构建本身也会带来新的问题:规范必须从文档和人员处恢复，而被构建的系统本身也是 AI。Sierra 称，将继续使用 hyper-τ-bench 来追踪代理在自行承担更多此类工作时的表现。