评测对象的转移：从「答得对」到「造得出」
2026 年 9 月 4 日提交的论文 ττ-Bench（读作 hyper-tau-bench，arXiv 2609.04611，作者 Quan Shi、Keshav Dhandhania、Karthik Narasimhan、Victor Barres，来自 Sierra 与普林斯顿），做了一件评测上很不一样的事：它把「构造一个智能体」本身变成任务。过去的基准大多考智能体在给定环境里答得对不对；ττ-Bench 给一个开发智能体真实的业务素材——企业实际留存的业务记录、提出需求的客户、必须跑通的生产 API、要继承的代码库，以及模型与服务成本的硬约束——然后要求它交付一个完整的客户服务智能体，并用留出的模拟用户去实测这个交付物。换句话说，考的是「你能不能造出一个能用的智能体」。
任务设计：照着真实客户交付的起点来
这恰恰戳中当下最现实的痛点：构建智能体越来越多地交给了 coding agent，但现有基准几乎不回答「一个 AI 系统能否在真实客户交付的条件下交付一个智能体」。ττ-Bench 刻意还原真实 Engagement 的起点——业务知识以企业实际留存的方式到来（标准作业流程、客服录音转写、电子表格里的费率表），最关键的部分往往只活在人脑里、要在追问中才浮现并随业务变化而漂移；构建本身也很少从空白开始，开发者可能继承一个必须保留行为的旧代码库，还要满足成本、延迟与可用模型的硬约束。设计决策无处不在：是单一策略模型，还是编排子智能体的层级？动作空间怎么切成工具？固定预算与有限模型菜单怎么分配才能交付最好的智能体？哪些事必须去问人？
成绩：23.9% 对 82.2% 的落差
在横跨航空、零售、电信、银行四个领域、共 53 个任务上，论文报告的得分最高配置——Claude Opus 5 经 Claude Code——只通过了 23.9% 的评估模拟；而由专家撰写的参考上限达到 82.2%。其他模型配置落在 14.9% 到 22.0% 之间。这个落差之所以有信息量，不是因为它「低」，而是因为它把 coding 能力与「理解业务、沟通客户、做架构取舍、管理成本」之间的差距量化了出来。Sierra 于 9 月 8 日前后以 MIT 许可开源了该基准（GitHub sierra-research/hyper-tau-bench）并开放公开排行榜。前述分数由论文报告，尚待独立复现与更细的统计不确定性披露。
失败模式：像极了人类开发者的坑
论文归纳的失败模式，几乎是人类智能体开发者也常踩的坑：模型发出浅层查询，而非深度吃透业务记录；几乎不与客户沟通；对智能体架构与服务投入的实验太少，跑通一个能跑的设计就交付。这一点把讨论从「代码生成」拉到「交付物质量与用户交互」——被测试的系统常常产出了能跑的东西，却没满足交付更深层的约束。ττ-Bench 因此把「协作式智能体构建」变成一个可度量目标，而不是一句愿景。
为什么它重要：coding agent 不能只考 coding
对正在用 coding agent 搭智能体的团队，ττ-Bench 是一面镜子。它提示：编码能力本身不等于理解业务数据、翻译客户需求、做架构选择、平衡质量与成本的能力。许多评测把模型生成代码或完成窄定义任务孤立出来；ττ-Bench 考的是决定一个智能体能否在运行环境中成立的整条决策链——解读不完美的组织数据、把客户需求转成行为、与既有系统整合、选模型、在质量与成本间取舍。它也让「coding agent 能否替代围绕 AI 系统的软件开发」这类断言有了更具体的检验方式：被测试系统常常产出了能跑的，却没满足更深要求。
局限与待观察
也必须点明边界。论文 landing page 未给出任务构造、模拟器设计、打分流程、基线选择与统计不确定性的细节，也未证明 23.9% 能预测生产结果。它是否与其他基准可比、模拟用户能否预测真实客户行为、结果能否泛化到那 53 个任务与四个领域之外，都有待后续。基准本身是否公开、实现要求与复现条件也需作者进一步明确。对研究团队，下一步应测更多模型、更多 coding-agent 系统、更多领域与任务类型，并澄清模拟用户如何代表真实客户行为。
结语
ττ-Bench 把评测指针从「智能体答得对」拨到「智能体能造出一个可用的智能体吗」。23.9% 与 82.2% 之间的鸿沟，不是用来唱衰某个模型，而是用来提醒行业：把构建智能体交给 coding agent，缺的往往不是写代码的能力，而是读懂业务、敢做架构实验、会算成本账的判断力。这恰恰是人机协作最该补的短板。