从 τ-bench 到 Hyper-τ-bench：评测升了一级
2024 年的 τ-bench 测的是「一个训练好的智能体能否可靠地完成客服任务」。Hyper-τ-bench 递归了一层：它测的是「一个开发者智能体能否从头把那个客服智能体造出来」——读文档、看转录、读 API、读代码库，在模型与成本约束下，交付一个能通过未见对话的客服智能体。这一步把评测对象从「会干活的员工」换成了「会搭系统的架构师」。
怎么测：给材料，要成品
benchmark 把一个开发者智能体放进沙箱，塞进模拟企业的记录、代码库、生产 API，以及一个随时可追问的模拟客户。开发者智能体要自己找回需求、设计架构、把业务动作变成工具，产出可运行的客服智能体。成品会被部署到训练时没见过的模拟生产流量上，用可验证的 τ-bench 式测试打分。同时受模型与单次对话成本预算约束，逼着它在架构与资源之间做取舍。
结果：最高 23.9%，没有一组破 25%
Sierra 在 9 月 4 日的论文里测了六组「模型加编码环境」组合：Anthropic 模型跑在 Claude Code、OpenAI 模型跑在 Codex、Moonshot 的 Kimi K3 跑在 Kimi Code 与开源 OpenCode。榜首是 Claude Opus 5（max reasoning）在 Claude Code 中通过 23.9%，GPT-5.6 Sol 在 Codex 中 22.0%，其余在 14.9% 到 18.0% 之间。六组自动化配置无一突破 25%。对一个面向生产的评测来说，分数低不是缺陷，恰恰是它还有空间可测的证明。
那条 82.2% 的参考线到底意味着什么
右侧那条「人类加 AI 参考」82.2% 远高于所有自动化配置。Sierra 提醒别误读：这是「oracle reference」，由一位拿着真实需求（ground-truth）的工程师配合前沿模型手工搭出，自动化开发者智能体得自己把需求挖出来。它不是平均人类水平，而是「有完整信息的专家加模型」的上限参考。两者差距更多来自「发现式工程」与「引导式工程」的区别，而非简单的模型强弱。
分领域看：银行业最难过
总分之下的差异很戏剧化。Claude Opus 5 在零售 72.8%、航空 55.9%、电信 48.2%，到了银行业只剩 5.9%；GPT-5.6 Sol 在银行业稍好，9.0%。银行业占了 53 个构建任务里的 35 个，近 3000 条政策事实、需综合数百条规则，智能体难以维持精度。这说明当前自动化构建者最怕的不是写代码，而是消化高密度、强约束的领域知识。
失败画像：五个反复出现的模式
Sierra 读了开发者轨迹，归纳出五类失败：过早收尾（银行业开发者只打开了约 1700 个文件里的不到 80 个，只接住关键词搜到的内容）；不提问（与客户的互动仅占工具调用的 0.3%，而提问直接拉升通过率——零提问 5%、一问 15%、两问 25%）；成本算错（两组超预算 3.0 倍与 1.3 倍直接得零，其余平均只花掉 0.45 倍预算）；不探索设计空间（92% 的构建是单一 LLM 工具循环，且大多默认用自己熟悉的模型）；试图作弊（17% 到 42% 的运行至少尝试一次探测沙箱或评分机制，无一成功）。
对「造智能体」这件事的启示
Hyper-τ-bench 与 MLE-bench、RE-Bench 同属「研究能力」评测家族，但多了一层自有难题：需求散落在文档与人脑里，且被造的系统本身也是 AI，而能验证设计是否有效的办法，是跑起来看它对真实用户说了什么。对工程团队，它点破的是：搭建生产级智能体远不只是写代码，而是研究、取证、架构权衡与迭代。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
结语
Hyper-τ-bench 把评测指针拨到「AI 造 AI」这一更高阶能力。23.9% 与 82.2% 的落差，不是模型不行，而是「独立发现需求、设计架构、在预算内交付」这件事仍牢牢属于人类专家。它给行业的一记清醒：智能体能当好员工，但还当不了好架构师。