τ-bench：在真实领域中评测工具—智能体—用户交互

一句话结论

τ-bench 的关键贡献不是再测一次“模型会不会调用函数”，而是把多轮用户信息收集、复杂领域规则、带副作用的工具调用和重复运行的一致性放进同一评测。ICLR 2025 正式稿显示，GPT-4o 函数调用智能体在零售与航空领域的 pass^1 分别只有 61.2% 和 35.2%；即使零售单次平均成功率超过 60%，连续 8 次都成功的 pass^8 仍降到 25% 以下。

版本说明

arXiv 页面只保留 2024 年 6 月 17 日提交的 2406.12045v1。本文依据的是更晚的 ICLR 2025 官方正式稿：官方 proceedings PDF 共 53 页，包含主文、完整零售/航空政策、数据生成代码、三条零售失败轨迹和一条航空成功轨迹。元数据保留 arXiv ID 与 DOI 方便检索，但实验数字、页码和附录位置均以 ICLR 正式稿为准。

官方代码仓库采用 MIT 许可证；论文采用 CC BY 4.0。仓库当前 README 已提示原始零售与航空任务属于旧版本，并引导读者使用后续 τ³-bench。这个维护状态不反向改变 2025 正式论文的实验结果，因此本文不会把当前 leaderboard 与论文 Table 2 混合。

摘要译文

现有基准通常不测试语言智能体与人类用户的交互，也不测试其遵循领域专用规则的能力，而这两点对安全、现实地部署智能体都至关重要。作者提出 τ-bench：一个包含零售和航空两个领域的基准，通过语言模型模拟用户，让客服智能体在领域 API 工具与政策指引下进行动态对话。

作者采用高效且相对忠实的评估方式，将对话结束后的数据库状态与人工标注的目标状态进行比较，并提出 pass^k 指标来衡量智能体跨多次试验的行为可靠性。实验表明，即使是当时最先进的函数调用智能体 GPT-4o，也只能完成不到 50% 的总体任务；其行为很不一致，在零售领域的 pass^8 低于 25%。这些结果指出，智能体仍需要显著提高一致性与规则遵循能力。

论文地图

问题	论文如何回答	主要证据
如何同时评测对话、工具与规则	把数据库、API、领域政策、模拟用户和唯一目标终态组合成动态任务	§3、Figures 1–2
如何避免只看一次成功	用 `pass^k` 衡量同一任务的 $k$ 次随机对话是否全部成功	§3、Figure 4
基准如何构造	人工设计 schema/API/政策，GPT-4 辅助生成数据，再用智能体轨迹人工迭代任务	§4、Appendix B
当前模型做到什么程度	比较 12 个模型的函数调用或 ReAct 基线	§5、Table 2、Figure 3
智能体具体错在哪里	人工检查零售失败轨迹，拆为参数、信息、决策和复合请求四类	§5.2、Figure 5
用户模拟是否主导失败	对四种用户模拟策略抽样标注失败责任	§5.3、Table 4
主结果之外还有哪些限定	给出完整政策、数据、失败/成功轨迹与任务难度分布	Appendices A–D

1. 研究问题：真实工具智能体不是单轮函数分类器

许多工具调用基准把所有信息一次性放进用户指令，让模型选择函数和参数。真实客服任务却是部分可观测的：用户不会一开始就提供身份、订单号、支付方式、替代偏好和授权；智能体必须在多轮对话中逐步获取信息，同时读取领域政策、查询数据库，并决定何时执行会改变状态的操作。

τ-bench 因而要求智能体同时满足三类能力（§1）：

在长交互中与用户和 API 往返，补齐意图所需信息；
从复杂、甚至并未由 API 自动强制的政策中找出当前约束；
面对语言模型用户带来的随机表达，在重复运行中保持同样正确的结果。

这使评测对象从“有没有生成合法 JSON”转为“对话、推理与副作用最终是否共同满足用户意图和政策”。

2. τ-bench 的任务结构

2.1 两个相互作用的状态空间

论文把单个任务写成部分可观测马尔可夫决策过程 $(S, A, O, T, R, U)$ 。状态由数据库与用户两部分组成：

S = S_{d b} \otimes S_{u s e r}, A = A_{d b} \cup A_{u s e r}, O = O_{d b} \cup O_{u s e r} .

数据库只能通过工具读取或修改，工具转换由 Python 函数确定性执行；用户由 gpt-4-0613 模拟，根据隐藏的任务指令和已经发生的对话随机生成下一句。智能体可在同一决策空间中选择调用工具或回复用户，但看不到隐藏任务标注（§3、Figure 2）。

领域政策作为系统提示提供给智能体。部分规则由 API 检查，例如支付方式是否存在；另一些规则只存在于政策文本中，例如执行数据库写操作前必须列出细节并获得明确确认，或一张已交付订单只能执行一次退换操作。这种区分使“工具调用成功”不自动等于“决策符合政策”。

2.2 奖励：终态正确，但并非覆盖所有过程规则

每个任务包含隐藏的用户身份、意图与偏好，以及唯一目标数据库写操作和可选的必答信息。一次 episode 的二元奖励为：

r = r_{a c t i o n} \times r_{o u t p u t} \in {0, 1} .

r_action 要求最终数据库与目标终态一致，r_output 要求面向用户的回复包含指定信息。对话措辞和只读查询路径可以变化，只要最终写入和必要输出一致即可（§3）。

作者同时明确承认，这个奖励可能只是成功的必要条件。例如智能体即使没有先获得用户确认，也可能执行正确写操作并得到 $r = 1$ 。因此 τ-bench 的规则评测比只检查函数名更强，但仍没有把全部对话过程政策编码成自动判定器（§3, p.5）。

2.3 `pass^k`：把“偶尔成功”与“稳定成功”分开

代码生成常用 pass@k，只要求 $k$ 次里至少一次成功；客服智能体的要求恰好相反。若同一任务运行 $n$ 次、成功 $c$ 次，τ-bench 定义 pass^k 为随机取 $k$ 次且全部成功的概率，再对任务取平均：

{p a s s}^{k} = 𝔼_{t a s k} [\frac{(\frac{c}{k})}{(\frac{n}{k})}] .

对话语义保持不变，随机性来自用户与智能体生成的不同措辞和路径。pass^1 就是平均单次奖励；随着 $k$ 增加，曲线直接暴露“一次能做对、重复就不可靠”的任务（§3, Figure 4）。

3. 基准构造：规模不大，但任务终态经过反复校验

3.1 数据与任务规模

领域	数据库	工具	任务
τ-retail	500 个用户、50 类产品、1,000 张订单	7 个写工具、8 个只读工具	115
τ-airline	500 个用户、300 个航班、2,000 个预订	6 个写工具、7 个只读工具	50

零售覆盖取消或修改待处理订单、退换已交付商品、地址修改和信息查询。航空覆盖订票、改签、取消、行李、乘客和补偿；其会员等级、舱位、保险、支付组合和航段状态产生更长的规则链（§4.1、Table 1）。

3.2 三阶段构造

人工设计 schema、API 与政策：作者以真实业务为灵感做简化，优先保证各组件逻辑一致且可标注。
语言模型辅助生成数据：先人工给示例，再让 GPT-4 生成可扩展采样代码与文本候选，经过执行反馈和少量人工修订生成用户、产品、航班等数据。
人工编写并迭代任务：作者先写用户模拟指令，用 GPT-4-Turbo 函数调用智能体试跑，再检查轨迹并消除会导致多种合法终态的歧义。Appendix A 说明，每个零售任务至少用 40 次 GPT-4-Turbo 运行估计难度，并针对零成功或低成功任务复查标注。

这种流程用较高的单任务标注成本换取可自动比较的唯一终态，但也带来一个重要偏差：任务指令是借助 GPT-4-Turbo 基线调出来的，可能更贴合或更针对这一类智能体（§4、§6）。

4. 实验设计与可比性

主实验使用函数调用构建智能体；Llama-3-70B 不支持相同接口，改用文本 ReAct，因此该行不是严格相同方法。作者另在 GPT 系列上比较文本 ReAct 与不输出思考轨迹的 Act。每项任务最多允许 30 次智能体动作（工具调用或用户回复），Table 2 每个任务至少运行 3 次；智能体 temperature 为 0.0，用户模拟器为 1.0（§5）。

论文测试的是当时 API 中的 GPT-4、Claude 3、Gemini 1.5、Mistral 等模型，以及 Mixtral-8x22B 和 Llama-3-70B 两个开放权重模型。论文没有报告置信区间或显著性检验，且 API 模型会随时间变化，因此结果应理解为 ICLR 2025 稿件对应配置的能力快照。

5. 主结果：航空规则链比零售更难

下表重述正式稿 Table 2 的 pass^1（%）。avg 是两个领域分数的等权平均，不按 165 个任务加权。

模型	τ-retail	τ-airline	avg
GPT-4o	61.2	35.2	48.2
GPT-4-Turbo	57.7	32.4	45.1
GPT-4-32K	56.5	33.0	44.8
Claude-3-Opus	44.2	34.7	39.5
Claude-3-Sonnet	26.3	27.6	27.0
Mistral-Large	30.7	22.4	26.6
Mixtral-8x22B	17.7	31.6	24.7
Gemini-1.5-Flash	17.4	26.0	21.7
Gemini-1.5-Pro	21.7	14.0	17.9
Claude-3-Haiku	19.0	14.4	16.7
GPT-3.5-Turbo	20.0	10.8	15.4
Llama-3-70B（文本 ReAct）	14.8	14.4	14.6

GPT-4o 是总体最佳基线，但航空仍只有 35.2%。Figure 3 还显示，在所测 GPT 模型上，原生函数调用一致优于文本 ReAct，ReAct 又优于只有动作的 Act；作者为函数调用增加额外 think 工具也没有得到提升。这支持“接口训练与模型—工具协议匹配很重要”，但不支持“函数调用永远优于所有显式推理方法”的普遍结论。

5.1 一致性比平均分下降得更快

在 τ-retail，GPT-4o 的单次成功率超过 60%，但 Figure 4 中连续 8 次全部成功的 pass^8 已低于 25%。这不是简单地把 61.2% 做八次方：论文按每个任务的重复成功数估计后再跨任务平均，保留了任务难度差异。结果说明产品若只报告一次运行的平均成功率，会掩盖同一用户意图换一种说法就失败的风险。

5.2 成本主要花在长系统提示

在 τ-retail 上用 GPT-4o 作为智能体、GPT-4 作为用户模拟器时，每任务的智能体与用户模拟平均成本分别为 0.38 美元和 0.23 美元，完整跑一轮约 200 美元。智能体成本的 95.9% 来自输入、4.1% 来自输出，主因是领域政策和函数定义组成的长系统提示（§5.1）。这些是历史价格与提示下的估计，不应当作当前 API 成本。

6. 失败分析：错误发生在调用前，也发生在调用序列之间

作者人工检查 τ-retail 的 115 条 GPT-4o 函数调用轨迹，其中 40 条失败。4 条来自任务指令歧义或笔误并随后修复；剩余 36 条智能体失败分布如下（§5.2、Figure 5）：

失败类别	比例	典型含义
参数错误	33.3%	工具类型正确，但从复杂库存或订单中选错 ID/参数
信息错误	22.2%	漏报用户要求的信息、算错价格，或用错误信息改变用户决策
决策错误	25.0%	忽略政策，调用了错误类型或错误顺序的写工具
复合请求只完成一部分	19.4%	忘记较早的显式请求，或只处理多个隐含动作中的一个

GPT-4o 每个零售任务平均产生 0.46 次不存在的用户、产品、订单或商品 ID；GPT-3.5-Turbo 的函数调用与 Act 分别为 2.08 和 6.34 次。这说明较强模型的失败已经从明显幻觉转向更难发现的选择、规则与完整性问题。

6.1 移除政策的消融

模型	τ-retail	τ-airline
GPT-4o	61.2 → 56.8	33.2 → 10.8
GPT-3.5-Turbo	20.0 → 14.5	10.8 → 9.6

零售规则较接近常识，移除政策后 GPT-4o 只下降 4.4 点；航空含舱位、会员、保险、行李和支付的专用规则，下降 22.4 点。GPT-3.5-Turbo 在航空只降 1.2 点不能被解释为更鲁棒，更可能说明它在有政策时也没有充分利用复杂规则（§5.2、Table 3）。

6.2 附录轨迹让四类错误变得具体

错误决策（Appendix C.2.1）：用户要在同一订单交换键盘和恒温器。智能体先单独交换键盘，使订单状态从 delivered 变为 exchange requested；第二次交换因此被 API 拒绝。每个局部动作看似合理，序列整体却不可恢复。
错误参数（Appendix C.2.2）：用户要“更暗且优先 AC 供电”的台灯，库存中存在低亮度 AC 型号 1569765161，智能体却选择中亮度 AC 型号 5320792178。它成功调用了工具，却没有完成偏好排序。
复合请求漏项（Appendix C.2.3）：用户要求修正所有订单地址、默认地址并更换拼图。智能体更新了默认地址和拼图订单，却遗漏另一张待处理订单的地址。
成功轨迹（Appendix D.2）：航空案例中，智能体先排除早于 11 点的直飞，选择最低价的晚间中转组合，再按“最多一张旅行凭证”政策使用 250 美元凭证加 5 美元信用卡，并正确计算金卡经济舱三件免费行李。

这些案例说明，终态任务的难点不是单一长上下文记忆：它同时要求集合完整性、偏好排序、不可逆动作规划、数值计算和政策约束。

7. 用户模拟器不是主要失败来源，但外部效度仍有限

作者在航空领域对每种用户策略的 50 条随机失败轨迹做责任标注（GPT-4o 函数调用、3 次试验）：

用户策略	3 次平均准确率	失败中归因智能体	失败中归因用户	其他
LLM 直接生成	0.367	0.980	0.020	0.000
ReAct	0.300	0.880	0.020	0.100
Verify	0.393	0.960	0.040	0.000
Reflection	0.406	0.920	0.040	0.040

四种策略中，归因于用户模拟器的失败都不超过 4%，reflection 准确率最高，但没有消除主要问题（§5.3、Table 4）。需要注意，比例是在“已失败轨迹”中抽样得到，不是所有 episode 的总体发生率；责任分类也来自人工判断。

8. 论文结论与证据边界

论文直接支持以下结论：

在两个合成客服领域、165 个任务和论文所测模型快照上，函数调用智能体的单次任务成功率仍低，航空复杂规则尤其困难（Table 2）。
同一任务的随机对话重复运行会导致 pass^k 快速下降，平均 pass^1 不能代表部署所需的一致性（Figure 4）。
失败不仅来自模型生成非法工具参数，还来自库存推理、政策理解、不可逆动作顺序和复合意图遗漏（§5.2、Appendix C）。
复杂政策确实提供有效信息：移除航空政策会让 GPT-4o 大幅退化；但仅把政策塞进上下文仍不足以保证遵循（Table 3）。

这些证据不能支持以下更强外推：

不能把分数等同于真实客服可靠性。 用户、数据库、规则与任务都由人工和 GPT-4 系列模型合成，只有零售与航空两个简化领域，没有真实用户分布、组织流程或生产副作用。
不能认为自动奖励覆盖全部合规性。 数据库终态与必答字符串可能都正确，但智能体仍可能未获得明确确认、给出错误过程信息或违反未编码规则。
不能把具体模型排名用于今天的同名 API。 论文没有固定可下载权重或完整 API 快照，也没有报告置信区间；Llama-3 还使用不同的文本 ReAct 接口。
不能断言用户模拟完全无偏。 用户指令可能有歧义、知识缺口或推理错误，任务又借助 GPT-4-Turbo 轨迹迭代，可能对基线行为形成隐式选择偏差（§6）。
不能忽略基准自身已经演进。 当前官方仓库明确将原始任务标为过时并指向 τ³-bench；复核新系统时应使用与目标版本绑定的任务和代码，而不是把旧论文数字当永久 leaderboard。

9. AI 解读：可靠工具智能体需要“事务级”而非“调用级”评测

以下是 AI 基于论文证据作出的延伸分析，不是作者原文结论。

9.1 单个工具调用正确，仍可能让整个事务失败

键盘/恒温器案例揭示了一个工程上容易漏掉的层次：工具 schema 能检查参数类型，API 能检查当前状态，但只有智能体负责把多个用户目标排成合法事务。第一次调用一旦改变订单状态，第二个目标就不可达。由此可以推断，生产评测至少需要区分调用正确性、序列可达性和最终目标完整性，不能只统计 function-call accuracy。

9.2 `pass^k` 更接近服务承诺，但还需要风险分层

客户服务不会因为智能体“平均六成正确”而接受同类请求随机失败。pass^k 把这种直觉变成指标：同一意图多次变化措辞仍要成功。不过不同工具副作用的失败成本不同，查询漏答、错误退款和违反授权不应等权。更完整的生产指标可能要在 pass^k 之外按只读、可回滚写入、不可逆写入和合规违规分层。

9.3 政策文本需要可执行的决策支撑

航空消融说明模型能从政策中获益，失败轨迹又说明“给了政策”不等于“在正确时刻提取并执行了规则”。一个合理的系统推论是，把政策全文放进 system prompt 只是最低配：高风险操作还应在工具层加入显式前置条件、授权凭证、事务规划或运行时 policy checker。论文没有比较这些架构，因此这是由错误模式启发的工程方向，而非作者已验证的方案。

9.4 用户模拟应当和真实流量形成双层验收

LM 用户让同一隐藏意图产生不同说法，适合做可重复压力测试；真实用户则会带来论文未覆盖的身份表达、反悔、并发修改、欺诈、无障碍需求和组织政策冲突。因此 τ-bench 更适合作为“动态单元测试层”，生产上线仍需匿名真实流量回放、人工红队与严格的无副作用沙箱。

10. 相关工作坐标

ReAct：把推理轨迹与行动交错；τ-bench 将它作为文本代理基线，并显示在所测 GPT 模型上 ReAct 优于 Act、但低于原生函数调用（Figure 3）。
BFCL、ToolBench、MetaTool：主要评测工具选择或函数参数；τ-bench 增加多轮用户信息收集、领域政策和数据库终态。
ToolEmu：用语言模型模拟工具以寻找安全风险；τ-bench 使用实际 Python 工具和确定性数据库转换，但用户仍由语言模型模拟。
WebArena、SWE-bench、AgentBench：强调网页、代码或多环境中的自主任务；τ-bench 的独特坐标是用户持续参与、政策限制和重复会话一致性。
任务型对话基准：传统数据集多为静态对话或符号用户；τ-bench 用开放式 LM 用户生成随机对话，同时以唯一数据库终态保留自动判定能力。