Abstract：摘要想表达什么这篇论文提出了一个新的智能体评测基准，叫τ-bench，全名是Tool-Agent-User Interaction Benchmark。它要解决的问题是：现有的智能体测试，通常只检查模型会不会调用工具或完成一个简单指令，却很少测试它能否长期与用户沟通、遵守领域规则，并且稳定地完成真实任务。1. 现有评测不够贴近真实应用在真实世界中，一个客服或任务型智能体通常需要同时处理三件事：与用户进行多轮对话；调用数据库和 API 工具；遵守某个行业或业务领域的规则。例如，航空客服智能体可能需要：询问用户想改成哪个机场；查询用户的订单和航班；检查机票类型是否允许改签；根据航空公司政策决定能否操作；调用取消、改签或重新订票 API；把结果清楚地告诉用户。这不是单纯的“根据一条指令调用一个函数”，而是一个包含不完整信息、规则约束和多轮沟通的复杂过程。2. τ-bench 模拟真实的 Tool-Agent-User 交互τ-bench 让三个部分共同参与任务：Agent：被测试的语言模型智能体；Tools/API：智能体可以调用的数据库操作工具；User：由语言模型模拟的用户。智能体需要在整个对话中：向用户询问缺失信息；理解用户意图；处理用户追加的新请求；查询和修改数据库；遵守领域政策；最终把数据库状态变成正确的目标状态。论文首先构建了两个客服领域：τ-retail：零售或电商客服；τ-airline：航空客服。3. 评测重点不是“说得像不像”，而是最终状态对不对论文提出了一种相对客观的评测方式：对话结束后，直接比较数据库最终状态和预先标注的目标状态。例如：用户要求退货，订单是否真的变成“退货申请”；用户要求换货，商品和支付信息是否正确更新；用户要求改签，系统中的航班和订单状态是否符合预期；如果政策不允许操作，智能体是否保持数据库不变并提出合理替代方案。这种方式比只让人评价“回复是否合理”更加明确，因为最终是否完成任务可以通过数据库状态直接判断。4. 提出 pass^k 衡量智能体是否稳定一次成功并不代表智能体可靠。由于用户模拟器具有随机性，同一个任务在不同运行中可能用不同方式表达，或者在对话中加入不同的追问。因此，论文提出：passk \text{pass}^kpassk它表示：同一个任务独立运行kkk次时，智能体是否每一次都成功。例如：pass1^11：单次运行成功率；pass8^88：连续 8 次都完成任务的比例。这个指标可以衡量智能体的稳定性，而不仅仅是一次偶然成功。5. 实验结果显示，当前智能体仍然不可靠论文测试了包括 GPT-4o 在内的先进模型，发现即使是这些模型，在复杂客服任务上也表现不理想。主要结果是：τ-retail 的单次成功率约为 61%；τ-airline 的单次成功率约为 35%；当要求同一个任务连续多次都成功时，性能迅速下降；GPT-4o 在零售任务上的 pass8^88甚至低于 25%。这说明很多智能体虽然偶尔能正确完成任务，但还没有达到真实业务需要的可靠程度。6. 主要失败原因作者分析发现，当前智能体主要在以下方面出错：对复杂数据库状态推理不准确；无法正确理解或遵守临时的领域政策；不能处理一个用户消息中的多个复合请求；缺少关键信息时没有主动询问；在长对话中遗忘之前的信息；面对不同表达方式时行为不一致；错误地调用工具或修改数据库。因此，智能体的问题不只是“不会调用函数”，而是：不擅长在用户沟通、数据库操作和规则遵守之间进行长期协调。7. 论文的总体目标作者希望 τ-bench 能够成为一个更接近真实部署环境的测试平台，用来推动以下方面的研究：更强的多轮任务规划；更准确的工具调用；更可靠的规则遵守；更好的长期记忆和上下文管理；更稳定的多次执行行为；更适合实际业务的智能体架构。摘要一句话总结这篇论文提出 τ-bench，用模拟用户、真实风格的数据库 API 和领域政策共同构造多轮客服任务，并通过最终数据库状态和 passk^kk指标评估智能体的任务完成率与稳定性；实验表明，即使先进模型在这类真实交互任务上也远未达到可靠部署的要求。第 1 章：Introduction（引言）这一章主要是在说明：如果语言智能体要真正进入航空、零售、客服等现实业务，仅仅会回答问题或调用函数是不够的，它还必须能够长期和用户沟通、正确调用 API、遵守业务规则，并且在多次执行中保持一致。1. 真实世界中的智能体需要同时处理三类任务作者认为，一个可实际部署的语言智能体至少需要具备三种能力。与人和程序进行长期交互智能体不能假设用户一开始就提供了所有信息。它往往需要：主动询问缺失信息；理解用户逐步补充的需求；处理用户临时增加的新请求；在多轮对话中保持上下文；与数据库和 API 交替交互。例如，用户说想把航班改到另一个机场，智能体可能还需要继续询问：具体是哪一笔订单；想改到哪个机场；是否接受其他日期；是否愿意支付差价；是否还需要处理同行人的票。遵守领域规则和政策智能体不能只根据用户要求直接执行操作，还必须检查业务政策。例如，航空公司的基本经济舱可能不允许直接改签。此时智能体不能因为用户明确提出“请帮我改签”就直接调用修改 API，而应该：查阅政策；判断当前票种是否符合要求；拒绝不允许的操作；给出符合政策的替代方案，例如取消后重新订票。在大量交互中保持稳定真实系统每天可能处理数百万次请求，因此智能体不能只在某一次运行中表现正确。对于同样的用户需求，即使：用户表达方式略有不同；对话顺序略有变化；用户额外问了一句话；API 返回的信息顺序不同；智能体也应该得到一致、正确的最终结果。2. 航空客服例子说明了任务的复杂性作者用航班改签举例。用户可能只说：我想把航班改到另一个目的地机场。但智能体必须完成一整套工作：理解用户真正想修改的订单；询问缺少的航班和机场信息；查询用户的预订；检查票种和改签政策；查询可用航班；计算价格和差价；取得用户确认；调用取消、改签或重新订票 API；向用户解释最终结果。这个过程同时涉及：长上下文推理；工具选择；规则判断；多步规划；用户沟通；状态修改。3. 现有智能体基准过于简单作者指出，已有很多语言智能体基准，但通常采用简化设置：用户在一开始就给出完整指令；所有必要信息都已经提供；智能体独立操作网页、代码终端或 API；没有真正的人类参与；不需要阅读和遵守复杂的领域政策。这种测试可以衡量工具调用或指令执行能力，但不能充分反映现实客服中的困难。现实任务通常是：部分可观察的；信息逐渐出现的；用户目标可能模糊的；规则之间存在约束的；需要连续做出多步决策的。4. τ-bench 的设计目标为解决这些问题，作者提出 τ-bench，即 Tool-Agent-User Interaction Benchmark。它由三个核心部分组成：真实风格的数据库和 API数据库中保存用户、订单、航班、商品和支付等状态。智能体不能直接读取数据库，只能通过 API：查询；修改；取消；退货；换货；预订；改签。领域政策文件每个领域都有一份说明规则的政策文档，包含：业务流程；可执行操作；操作限制；不同用户状态下的规则；用户需要确认的事项；特殊例外情况。用户场景和目标状态每个任务都包含：一个具体用户情境；用户的初始目标；可能的追加请求；预期数据库最终状态；人工审核过的正确答案。作者首先构建了两个领域：τ-retail：零售客服；τ-airline：航空客服。5. 用户由语言模型模拟，但任务由人工设计和验证论文使用语言模型模拟用户，使用户行为更加灵活和自然。同一个场景重复运行时，模拟用户可能：使用不同措辞；不同顺序地提出信息；进行不同形式的追问；临时增加相关请求。但这些变化应该仍然围绕同一个目标。为了保证基准可信，作者采用了三阶段构建流程：人工设计数据库结构和 API；使用语言模型辅助生成数据；人工创建、检查和验证用户场景。因此，τ-bench 不是完全自动生成的随机测试，而是结合自动生成和人工审核的基准。6. 用最终数据库状态进行客观评测作者不只根据对话文字判断智能体是否成功，而是比较：实际最终数据库状态 \text{实际最终数据库状态}实际最终数据库状态和：预先标注的目标数据库状态 \text{预先标注的目标数据库状态}预先标注的目标数据库状态这样做有两个好处：评测更客观；对话过程允许存在随机变化。只要不同的对话最终都得到正确数据库状态，就应该判定为成功。例如，用户可以用不同方式提出退货请求，但只要：正确商品被退回；正确订单状态被修改；正确退款信息被记录；就可以认为任务完成。7. pass^k 用于测试可靠性作者提出 passk^kk指标，评价智能体在多个独立试验中是否始终成功。单次成功率 pass1^11只能回答：这次运行是否完成了任务？而 passk^kk更关心：同一个任务重复运行kkk次，是否每次都能完成？这更接近真实部署需求，因为实际用户交互本身具有随机性。8. 实验结果表明当前智能体很脆弱作者测试了函数调用、ReAct 等较简单的智能体结构。即使是 GPT-4o，也只达到大约：τ-retail：61% 的 pass1^11；τ-airline：35% 的 pass1^1
