τ^τ-Bench：评的不是当客服，而是能不能把客服 Agent 做出来

来源：Quan Shi、Keshav Dhandhania、Karthik Narasimhan、Victor Barres（Sierra、普林斯顿大学），arXiv:2609.04611v1，2026 年 9 月 4 日。许可证：CC BY 4.0。下文前半按摘要转写，后半按引言归纳。

摘要

大模型 Agent 正在变成生产软件，被部署去处理客服、裁定争议、操作内部系统。值得注意的是，构建它们的工作也越来越多地交给编程 Agent，但现有基准几乎不说明：一套 AI 系统能否在真实客户项目的条件下交付这样一个 Agent。

作者提出 τ^τ-bench（读作 hyper-tau-bench）。它把构建 Agent 当成任务本身。开发者 Agent 拿到的是企业真实会留存的记录、一位掌握需求的客户、运营必须走的生产 API、一份要继承的代码库，以及对服务成本和可用模型的限制。起点和真实项目相同。它必须交付一个完整的客服 Agent，评分方式是把这个 Agent 部署去对付留出的模拟用户。

53 道题、四个领域。最强配置是 Claude Code 下的 Claude Opus 5，只通过 23.9% 的评测仿真。专家撰写的参考上限是 82.2%。失败方式和人类 Agent 开发者看到的一样：模型用浅层查询代替对记录的深入理解，几乎不跟客户沟通，也很少试验 Agent 架构和服务花费，第一个能跑的设计就交出去。作者希望 τ^τ-bench 把协作式构建 Agent 变成编程 Agent 可测量的目标。

引言里的两个难度

构建这种 Agent 难在两条轴上。

第一条是把规格找回来。Agent 需要的知识，以企业实际存放的形式到来：标准作业程序、支持对话记录、电子表格里的费率。更重要的是，很多知识只在人身上，要问出来，而且会随业务变化。第二条是构建本身很少从空白或无限预算开始：可能继承必须保持行为的既有代码库，还要满足成本、时延和可服务模型的硬约束。

每一步都有设计问题。Agent 应是一个遵守政策的模型，还是一层编排好的子 Agent？业务数据上的动作空间怎么切成工具，每个工具暴露什么？固定预算和有限模型菜单怎么分配，才能交付更好的 Agent？当一部分事实只能从人那里问出来时，开发者必须问什么？

作者要回答的研究问题是：今天的 AI 系统在多大程度上能构建 Agent，而不只是充当 Agent？构建过程如何被忠实、可规模化地建模？构建 Agent 比常规软件工程多要求哪些能力，其中哪些正在卡住现有系统？

论文把「会做客服」和「会做一个客服系统」分开。前者是 τ-bench 一类基准已经在测的策略执行，后者才是这份工作的对象。23.9% 对 82.2% 的差距说明：最强编程 Agent 还远没有达到熟悉业务的人类开发者，在需求澄清、读原始记录和成本约束下的设计水平。

论文：https://arxiv.org/abs/2609.04611