论文档案

为什么静态工具调用不够

真实客服任务不是“根据一句话选一个函数”。Agent 需要边与用户沟通、边查数据库、边遵守长政策：缺少订单号要询问，退款前要确认，basic economy 机票不能直接改签，付款方式还可能受账户记录约束。

τ-bench 将交互明确为三个参与者：

User Simulator  <──自然语言──>  Agent  <──API call──>  Database/Tools
                                  │
                                  └── 必须遵守 Domain Policy

Agent 能看到政策与工具，不能直接看到用户模拟器隐藏意图和数据库；它必须逐轮收集信息并执行正确写操作。

两个领域

Retail 涵盖取消/修改待处理订单、退换已送达商品、修改地址和查询信息；Airline 涵盖预订、改签、取消、退款与行李规则。Airline 政策更复杂，涉及舱位、会员等级、付款组合和航线限制。

基准是怎样构造的

第一阶段：人工设计 schema、API 与政策

作者先定义数据库结构、工具函数和 Markdown 政策。一部分规则由 API 强制，例如不存在的 payment ID 会报错；另一些只写在政策中，例如特定舱位的行李额度，需要 Agent 自己遵守。

这一区分很重要：只靠工具 schema 无法表达所有业务约束，Harness 还需要 policy engine 或运行时验证。

第二阶段：模型辅助生成数据

团队给 GPT-4 一个示例，让它生成可扩展采样代码，再人工修正，用于构造用户、商品、订单、航班和预订。数据是合成的，但保持关系和约束，便于公开、重置与确定性检查。

第三阶段：人工任务与唯一终态

每条用户模拟器指令对应一个人工标注的目标数据库状态。作者反复用 GPT-4 Turbo 运行任务并修订指令；τ-retail 每题运行 40 次以上检查歧义，直到用户需求在政策下尽可能指向唯一终态。

这是昂贵但关键的工作：若用户可能合理选择两种付款方式，单一数据库 gold state 会把正确行为误判为失败。

终态判分为什么优于轨迹匹配

同一目标可以有多种合法对话和工具顺序。τ-bench 不要求 Agent 模仿参考轨迹，而是比较最终数据库状态与标注状态，并检查需要返回给用户的信息。

多条不同轨迹 ──► 相同正确数据库终态 ──► 都应成功

这样既允许语言与工具路径有随机性，又保持评分客观、快速。代价是必须确保目标终态唯一，而且纯读取/解释类目标还需额外输出检查。

pass^k：从“能成功”到“总能成功”

代码生成常用 pass@k：k 次里至少一次成功，衡量增加采样是否能找到解。真实客服更关心相反问题：同一任务重复 k 次，是否每次都正确。

τ-bench 定义 pass^k 为 k 次独立试验全部成功的概率，再对任务平均。它随 k 增大单调下降：

pass@k：至少一次成功，奖励搜索
pass^k：每一次都成功，衡量可靠性

如果一个任务运行 n 次，其中 c 次成功，论文给出无偏组合估计，而不是简单计算 (c/n)^k。默认 pass^1 = pass@1 = 平均任务成功率。

主要结果

论文比较 function calling、文本 ReAct 与 Act-only，Agent 温度 0，用户模拟器温度 1，每任务最多 30 个 Agent 动作，主结果至少运行 3 次。

即使最佳 GPT-4o，在更复杂 Airline 中也只有 35.2%。更关键的是它在 Retail 的 pass^1 超过 60%，但 pass^8 降到 25% 以下。一个平均看来“多数时候可用”的 Agent，连续服务多个用户时很快暴露不稳定。

失败分析

作者抽查 115 条 GPT-4o Retail 轨迹。初始 40 个失败中有 4 个源于任务 typo/歧义，修复后对其余 36 个 Agent 失败分类。主要问题包括：

• 工具参数或用户信息错误；
• 没有在复杂库存/订单数据库中找到唯一匹配；
• 未向用户收集必要信息就写数据库；
• 忽略政策或误解例外条件；
• compound request 只完成一部分；
• 向用户提供错误价格、追踪号等信息。

较弱模型还会 hallucinate 不存在的 ID。论文统计每个 Retail 任务中，GPT-4o FC 平均约 0.46 次不存在 ID 调用，GPT-3.5 FC 约 2.08 次，Act-only 约 6.34 次。

对 Harness 的直接要求

Policy 不能只作为一大段 system prompt

长政策放进上下文能工作，但稳定性有限。可机器化的约束应下沉到确定性层：写操作前验证订单状态、付款来源、退款额度和确认状态。模型负责解释和计划，policy gate 负责不可违反的不变量。

用户确认必须是显式状态

“用户已经确认退款”不应只靠模型记忆一段对话。Harness 应把关键确认解析为带作用域和过期时间的状态，并在写工具调用时校验。

工具写入需要幂等

重试可能重复取消、退款或创建预订。每个任务/动作应带 idempotency key，失败恢复时先读取真实状态，再决定是否补偿。

可靠性需要重复试验

同一配置至少多次运行，报告 per-task c/n 或 pass^k 曲线。只汇报最佳一次或 pass@k 会鼓励“多试总能撞对”，与生产可靠性方向相反。

复现实验建议

可以先复现 τ-retail 的 20 个任务：

1. 冻结数据库快照、政策版本、工具 schema 和用户模拟器；
2. 对每个任务运行 8 次，记录 pass^1、pass2、pass^4、pass8；
3. 保存对话、工具调用、前后数据库 diff 和政策校验；
4. 将错误分为信息收集、实体解析、政策、参数、部分完成、重复写；
5. 比较纯 prompt policy 与确定性 precondition；
6. 对写工具加入幂等键，再注入超时重试；
7. 将模型成本与用户模拟器成本分开报告。

论文估算 GPT-4o Agent + GPT-4 user simulator 在 Retail 每题约 $0.38 + $0.23，一轮完整实验约 200 美元。重复可靠性评测需要预先做成本预算。

局限

• 只有两个合成客服领域，不能代表医疗、税务或真实企业政策；
• 用户由 GPT-4-0613 模拟，行为与真实用户分布不同；
• 唯一数据库终态提高可判分性，也排除了部分现实歧义；
• 终态相同不保证过程中没有短暂泄露信息或不当动作；
• API 中硬编码的约束与 prompt 政策的比例会改变任务难度；
• 模型与价格均对应论文时期；
• pass^k 需要多次运行，统计和 API 成本较高。

τ-bench 最值得写进 Harness 规范的，是“终态正确”和“重复可靠”两条。Agent 的一次成功演示无法支撑上线判断；只有在相同语义的交互扰动下仍能稳定遵守政策，才接近真实服务要求。

延伸阅读

• 返回论文谱系与单篇索引
• AgentDojo：效用与安全的联合指标
• SWE-bench：测试驱动的环境终态验收
• 评测、复现与安全