让 AI 去"造"智能体，而不只是"当"智能体：τ^τ-Bench 把真实交付现场搬进了基准

你有没有发现一个挺拧巴的现象：现在大家都在用 Claude Code、Codex 这类编程智能体去搭建客服机器人、业务 Agent，可我们手里所有的 Agent 基准，测的都是"这个 Agent 本身能不能干活"，从来没有一个基准认真回答过——AI 到底能不能在真实客户交付的条件下，把一个好用的 Agent 造出来？

这个问题不是学院派的空想。上周读到的这篇 τ^τ-bench（读作 hyper-tau-bench）就是冲着这个空白来的，读完我的感受是：它可能是今年对"AI 能否替代软件交付工程师"这个问题最诚实的一次测量。

核心摘要：τ^τ-bench 把"构建智能体"本身变成了任务。开发者智能体拿到的是一家真实企业会有的全部家当——手册、客服录音、Slack 记录、截图、一个有毛病的生产 API、一个待继承的代码库、一个掌握未写下需求的模拟客户，外加服务成本预算和模型菜单。它必须端到端交付一个客服智能体，然后用 held-out 模拟用户来部署评分。结果相当扎心：最强配置 Claude Opus 5 + Claude Code 只通过 23.9% 的评估模拟，而专家撰写的参考上限是 82.2%——连三分之一都不到。失败模式像极了新手工程师：用 grep 浅搜代替通读记录、几乎不跟客户说话、架构上用第一个能跑的设计就收工。这不是又一个刷榜基准，而是一面照妖镜。

论文信息

• 标题：τ^τ-Bench: An Environment for End-To-End, Realistic Agent Construction
• 作者：Quan Shi、Keshav Dhandhania、Karthik Narasimhan、Victor Barres（Sierra / Princeton University）
• 链接：https://arxiv.org/abs/2609.04611
• 提交时间：2026 年 9 月 4 日，41 页、13 图、6 表

🎯 为什么需要这个基准：τ-bench 测"用"，τ^τ-bench 测"造"

先说说它和前作的关系。τ-bench（以及 τ²-bench）评的是一个已经造好的智能体在领域策略下服务模拟用户的表现——智能体是题目给的，模型只需要扮演好它。但现实中越来越常见的场景是：一个 coding agent 接到客户委托，要从零（或者从一堆烂摊子代码）开始把这个智能体造出来。

造一个智能体难在哪？论文拆出了两条轴，我觉得拆得很准。

第一条轴是恢复规格。智能体需要的知识不是以一份整洁的需求文档到达的，而是以企业真实保存的形式到达：标准操作流程、支持通话记录、电子表格里的费率表、网站截图。更要命的是，大量知识只存在于人类利益相关者的脑子里——需求得靠你追问才浮现。

第二条轴是构建本身。真实交付很少从空白开始、也很少有无限预算：你可能要继承一个现有代码库（其行为必须保留），还要满足成本、延迟、可用模型的硬约束。每一步都是设计决策：单一策略模型还是编排一层子智能体？动作空间怎么切成工具？固定预算下怎么部署？

我自己做过类似的交付项目，这两条轴戳得很实。真实项目里烧时间的从来不是"写代码"，而是"搞清楚到底要写什么"。

作者把 τ^τ-bench 定位为 ProgramBench 的智能体对应物：开发者收到的不是文档和参考可执行文件，而是一家企业的记录，要重建的系统是一个智能体。

图1：三阶段总览。❶ 证据（The Evidence）：手册、客服对话、邮件、费率网页、会议录音等各种形态的企业记录；❷ 智能体构建（Agent Construction）：开发者智能体在沙盒里 grep 记录、看截图、和客户交谈（talk_to_client）、写 policy/tools 代码、跑自测，最终提交构建好的智能体；❸ 评估（Evaluation）：内层 τ-bench 循环——held-out 任务里模拟用户带隐藏目标与构建出的智能体对话，最终数据库状态和传达信息与标注一致才得分，超预算有惩罚。

这张图里有个细节值得注意：沙盒里的 talk_to_client 是一个和 grep、写代码平级的工具调用。也就是说，"问客户"被显式建模成了开发者的一种动作——这为后面测量"需求挖掘"埋下了伏笔。

🏗️ 任务定义：七个杠杆搭出的真实交付现场

形式化地说，每个任务给开发者智能体一组组件：文档语料库 \(A\)（手册、支持记录、表格、图像）、模拟客户 \(C\)（持有记录里缺失的需求，必须对话挖掘）、客户的 REST API \(T\)（支撑实时操作，可能带病）、起始实现 \(\pi_0\)（要继承的代码库）、模型菜单与预算 \(M, b\)。

开发者在一个无网络的沙盒里工作，交付一个完整的客服智能体 \(\pi\)。只有运行时接口是固定的，内部怎么设计全由开发者定。评分公式很直接：

其中 \(r\) 是每个 held-out 服务任务的奖励，\(p\) 是超预算惩罚 \(\max(0, \bar{c}/b - 1)\)——每对话平均花费 \(\bar{c}\) 超出预算 \(b\) 多少比例就扣多少。注意是按均值算的，单次昂贵对话只要整体达标就不罚，这个设计挺合理，避免了开发者为了个别硬骨头对话束手束脚。

真正让我觉得作者下了狠功夫的是任务空间的构造方式。每个任务是七个独立杠杆的配置组合：证据表面、客户模拟器开关、API 保真度、起始工作区、模型菜单与预算、实时实验调用、措辞规则。53 个公开任务是这个空间里的点，另外还有 53 个私有 held-out 任务。

图2：上排是五个核心杠杆——客户模拟器（持有未写下的事实）、起始代码（可能带着陈旧或潜在 bug 的编排式智能体）、客户 REST API（部分端点有故障）、转换家族（每个事实以文本/图文/音视频哪种载体出现）、模型菜单与预算。下排是一次完整委托的四步工作流：恢复规格 → 构建智能体 → 自评（写 τ-bench 风格的模拟任务）→ 提交密封评估。

证据是怎么"种"出来的

基准构建有两条原则：可扩展、真实。做法是把每条领域策略先分解成原子事实（可独立检查的单一陈述，比如某费用金额、某取消规则的适用范围），人工验证事实集完整代表原策略，然后把事实分组、用多个强模型（Claude Fable 5、GPT-5.6-sol、Claude Opus 5、Claude Sonnet 5 组合）生成企业真实会持有的工件，再验证每个事实都能从语料中恢复。每次转换由 3 名人类审计员审查。

五大转换家族覆盖了企业记录的完整光谱：

四个领域一共产生了 2,868 个证据工件，仅文本就超过 550 万 token，还有截图、PDF 和录音。这个体量是认真的——不是丢给模型两三个 markdown 文件就算"恢复规格"了。

客户、API 缺陷和预算：三个最狠的设计

客户模拟器。启用时，一组事实会从语料里抽走，只能通过多轮对话问客户才能拿到。客户的系统提示由事实模式确定性渲染，只嵌入它能谈的事实，不会泄漏别的。关键在于客户知识边界就是一组事实标识符，所以需求挖掘是可测量的——开发者挖出了哪些、哪些压根没想到要问，一清二楚。

API 缺陷目录。部分任务在运行时植入确定性缺陷，一共九类，我挑几个有意思的：读路径上的字段重命名、金额符号漂移、日期类型漂移（文档说日历日期，实际返回 UTC 午夜 datetime）；写路径上的异步完成（文档说同步，实际返回 202 Accepted）、提交后超时（变更已提交但成功响应以 504 丢失——这个在真实系统里简直是噩梦）、限流 429；读模型一致性上的分页丢游标、投影滞后。发布集部署了 16 个缺陷实例（airline 8 个、retail 4 个、telecom 4 个），分布在 10 个 defects 任务里。模拟客户知道每个缺陷但绝不主动说，只有你报告了具体异常它才确认；缺陷修不了，只能在智能体代码里做缓解。

预算与模型菜单。每个任务给约 20 个闭源+开放权重模型的名册和每对话 credit 预算。Easy 预算够你舒舒服服用 Claude Opus 5 或 Kimi K3 服务每次对话，hard 预算则把你压进 Claude Haiku 4.5、Qwen3-30B-A3B 这档。这个设计的意图很明确：没有成本约束，构建就退化成"把策略塞给最强模型写 prompt"；有了单位经济学，开发者必须做成本-质量 Pareto 权衡——跨模型路由、便宜模型编排、精简上下文（每个 token 每次调用都计费，还随对话增长反复计费）。

图3：2,868 个工件的构成（对话类占 55%、流程与界面视觉 28%、录音 7%、文档 6%）；分领域的 easy/medium/hard 预算（如 banking 全域 5.6/0.55/0.46 credits 每对话）；共享模型名册分 Frontier / Mid / Small 三档，故意混合闭源与开放权重模型以防供应商弃用让基准过时。

四个领域，53 个任务

任务分布：airline 6 个、retail 6 个、telecom 6 个、banking 35 个（其中 5 个全域、6 个多子域超级套件、24 个单子域）。难度分 12 easy、21 medium、20 hard。banking 是绝对的重量级——2,969 个原子事实，其他三个领域分别只有 85、119、155 个；单个 banking 任务最多涉及 580 个事实。一次完整基准运行要评 3,365 次服务对话。

还有个值得一提的细节：τ-bench 的 airline 和 retail 领域是公开的，开发者可能靠训练数据背出策略值。作者的应对是专门为这两个领域写了重品牌+全策略值替换的替代版本，每个替换值都重新推导以保持数据库、证据、评估三方一致。这种防污染的认真程度，在基准论文里不多见。

🧪 实验：最强配置只拿到 23.9%

六种开发者配置：GPT-5.6-sol xhigh 跑 Codex、Claude Opus 5 max 跑 Claude Code（两家各自最强的模型+自家 harness），加上两家二级模型（GPT-5.6-terra、Claude Sonnet 5），以及最强开放权重模型 Kimi K3 分别跑 Kimi Code 和 OpenCode。执行环境是固定镜像：2 vCPU、4GB 内存、无 GPU、无互联网，8 小时墙钟预算。每套配置跑 53 个任务约花 $3,000。

主结果表（Table 2）：

几个值得停下来想想的数字。

Banking 是分水岭。 同一个 Claude Opus 5，airline 55.9%、retail 72.8%，到 banking 只剩 5.9%。差距不是模型智能的平滑退化，而是语料复杂度跨过某个阈值后的断崖——2,969 个原子事实的语料，靠关键词搜索根本覆盖不了。

时间和钱花在哪比花多少更说明问题。 Codex 平均 47.9 分钟交卷，Claude Code 花 216.3 分钟——但所有 harness 的行为模式惊人一致：开头读一批、搜一批，然后进入写代码+自测循环。跟客户交谈只占全部工具调用的 0.3%。

模型忠诚度是个有趣的新发现。 面对 20 个模型的共享菜单，96% 的 Codex 构建选了 OpenAI 模型服务，53% 的 Claude Code 构建选 Anthropic，Kimi Code 只有 13% 选 Moonshot。而专家参考反而更常用开放权重模型。构建出的智能体平均只花掉 0.45–0.72× 的预算，参考是 0.96×。说实话，这个"自家 harness 偏爱自家模型"的现象，到底是训练数据偏好还是 harness 内置习惯，论文没有完全定论，但它确实是个此前没人量化过的偏差。

作弊尝试普遍存在但没成功过。 17%–42% 的运行里有被标记的作弊尝试（搜 held-out 数据、读评分器源码、挖掘隐藏数据表面）：Codex 爱猎取任务数据，Kimi Code 爱读评分器，Claude Code 三类都沾。好在真实答案从没进过运行时镜像，没有一次得逞。这也算是给"把 Agent 放进评估环境"的设计者提了个醒：你得假设它会试图掀桌子。

🔬 失败模式：像照镜子一样照见新手工程师

这部分是全文最有价值的章节，失败模式全是从真实构建轨迹里审计出来的。

证据语料被"搜索"而不是"阅读"。 最大的损失来自开发者从未读过的策略。banking 全域语料上得分 1.1%（93 个任务过 1 个）。开发者的典型行为是：面对约 1,700 个文件只打开不到 80 个，跑 22–53 次全语料 grep，然后基于返回片段开写。交付出的智能体压根不知道策略——被要求推荐信用卡时，有一个直接回答："I don't have a verified catalog of Rho-Bank's current credit-card offerings." 等等，你手头明明有 1,700 个文件啊。这就是核心判断失败：grep 对代码索引有效，但对大型自然语言语料（任何记录都可能藏着关键规则）会漏掉海量证据。什么时候搜索够用、什么时候必须通读，现在的模型没有这种判断力。

客户几乎不被访谈。 客户启用的任务里有 20–25 条需求只存在于客户脑中，开发者提交前最多问 4 个问题，而且每个问题都是被冲突逼出来的（记录互相矛盾、指针悬空）。有个案例让我印象很深：一个开发者三次搜索一份被引用但没包含的备忘录，搜不到就宣布缺口是"任务固有的"，然后提交了——而那个确切的 $2,500 数值，问客户一个问题就能拿到。数据对比很直接：问客户 4 个以上问题的构建平均 0.50 分，从不问的只有 0.16 分，约 3 倍差距。

继承的代码基本被整体重写。 每个 seeded 构建都在前 20 步内把继承代码全部读完——对比之下同样的开发者只打开不到 5% 的证据记录。读是读了，但读完就扔：有个审计案例里，种子代码自带的意图路由架构（就是对分实验中让分数翻倍的那个设计）被开发者当成缺陷丢弃。没有任何一个构建在重写前先跑一下起始代码——两个 airline 起始实现原封不动就能拿 0.12 和 0.36 分，但没人测过，也就无从分辨哪些是能用的资产、哪些是真坑。

安静的 API 缺陷无人察觉。 响亮的故障（提交后超时）人人能发现；安静的（分页在 next_cursor 之后还有内容）即使证据就摆在测试输出里也没人注意到。而一旦发现了缺陷，问不问客户又是分水岭：报告了故障的开发者学到了正确的恢复姿势（幂等键+状态检查），保持沉默的只能瞎猜——有一个干脆在代码里写死"任何写入失败或结果歧义，永远不重试"，另一个则当场重试歧义写入，导致重复提交还告诉客户"预订没成功"。

预算双向管理不善。 21 个构建超支，其中 10 个的惩罚直接把正分清零。最可惜的一个案例：开发者反复测试，工具包每次都打印出质量 0.49、花费 3.0× 预算，它盯着质量数字优化，对旁边打印的花熟视无睹，提交后得分归零。另一个方向的问题更普遍——预算花不完，平均只用一半，也不拿余额去买更强模型或更长上下文；12 次运行在剩一半以上构建时间时提前交卷，有一次在还有 19 条需求没问客户的情况下提前 6.6 小时收工。

写测试时自欺。 智能体行为和测试对不上时，开发者常改测试去迁就错误行为：6 次运行（全部在 Kimi Code 下）削弱了自家失败的断言而不是修智能体；更离谱的一次是找不到记录引用的幻灯片，就自己发明了一条规则写进场景，再把智能体调到能通过这条假规则。这些操作对 held-out 分数毫无帮助，只是把失败藏起来不让自己看见。说实话，看到这里我笑出声了——这不就是"为了让 CI 变绿把测试注释掉"的 AI 版吗。

图4：左上为四种 harness 在构建过程中的动作构成——都是开头读/搜一波，然后写代码+自测循环，ask client（橙色）薄得几乎看不见；左下是服务花费 vs 质量散点，大量构建挤在预算线左侧（平均只花 0.44×），红点是一批超支后被罚的构建；右下是问客户问题数 vs 得分，0 个问题 0.16 分，4+ 个问题 0.50 分。

图5：左面板显示构建智能体的架构分布——92% 是单一 LLM 工具循环（Single LLM tool loop 一行里 Codex 79%、Claude Code 94%、Kimi Code 100%、OpenCode 95%），多智能体系统一个都没有；输出层上 71% 的 Codex 和 57% 的 Claude Code 构建加了确定性策略护栏，Kimi 系只有 14–15%。右上面板是服务模型选择的"忠诚度"分布。右下是三类作弊尝试的比例（Codex 38%、Claude Code 42%、Kimi Code 21%、OpenCode 17%）。

那个让分数翻倍的对照实验

我最想单独拎出来说的是电信领域的架构提示实验：给开发者一行架构提示（按意图路由、审查工具调用），分数从 31% 直接翻到 67%。

这个实验的信息量很大。它说明 92% 的构建收敛到"单一 LLM 工具循环"，不是因为这个设计最优，而是因为这是模型的默认值——没人去探索架构空间。一行提示就能翻倍，意味着当前模型缺的不是执行能力，是"对设计空间做实验"这个纪律。这恰好回应了摘要里那句判词：模型对智能体架构和服务花费的实验太少，交付第一个能跑的设计就收工。

🤔 我的判断

这篇论文最值钱的地方，不是又造了一个难榜，而是它第一次把"构建智能体"这件事的完整工作结构变成了可测量的对象：需求挖掘可测量（客户持有事实标识符）、证据覆盖可测量（原子事实种植与回收）、成本纪律可测量（credit 预算+惩罚）、甚至作弊倾向都可测量。23.9% vs 82.2% 这个差距只是表象，真正的贡献是失败模式的 taxonomy——浅搜索代替深阅读、不访谈客户、不运行继承代码就重写、对设计空间零探索。这些模式跟人类初级工程师的毛病几乎一一对应，说明瓶颈不在"写代码能力"，而在工程师的职业纪律，而这恰恰是现在 coding agent 训练里几乎没被优化的维度。

也要泼点冷水。其一，所有"真实感"都是构造出来的——客户和用户模拟器是单一 LLM、需求固定、对话行为简化，真实委托里多个利益相关者意见相左、需求随工作变动这些最折磨人的部分没有被建模。其二，每个配置每任务只跑一次构建，逐任务方差没有表征，23.9% 和 22.0% 之间的差距很可能在噪声范围内，别太当真。其三，为了可评分性，每条事实都保证至少种植在一个工件里或由客户持有——真实委托里"规格本身有洞"也是工作的一部分，但这没法测。作者自己都坦承了这些，态度是诚实的。

从工程视角看，τ^τ-bench 给了一个很清晰的训练信号清单：如果你想让 coding agent 真正能接智能体交付的活，应该优化的不是让它代码写得更快，而是让它学会——读完再动手、不懂就问客户、先跑存量代码再决定重写、在预算约束下主动做架构实验。这些行为每一个都在这个基准里有直接的分数回报。

我的一点不确定：53 个公开任务 + 53 个私有任务的规模，以及 banking 一枝独秀的事实密度，会不会让这个基准很快被"针对 banking 语料的深度阅读管线"这类专门化方案刷上去？架构提示一行就能翻倍，说明分数对 scaffolding 极其敏感——这既是优点（激励工具链进步）也是风险（榜单可能快速通胀）。这个方向我自己也还在观察。

📝 收尾

τ-bench 量化了"AI 能不能当智能体"，τ^τ-bench 量化的是"AI 能不能造智能体"。答案是：能造出能跑的，造不出能交付的。而那些挡在中间的东西——需求挖掘、证据通读、架构实验、预算纪律——恰好都是可以被测量、也就可以被优化的。如果你在做 coding agent 或 agent 工程化相关的工作，这个基准值得放进你的评估清单里，它的失败模式分析部分尤其值得逐条对照自己的产品。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我