【中文精读】τ-bench:工具-Agent-用户三方交互的真实领域基准

一、动机:现有基准漏掉了部署中最要命的两件事

摘要开宗明义(翻译):「现有基准既不考察 agent 与人类用户交互的能力,也不测试它遵守特定领域规则的能力,而这两者对于把 agent 部署到真实应用中都至关重要。」

拆开说,2024 年中的 agent 基准(WebArena、AgentBench、SWE-bench 等)有三个共同盲区:

• 没有用户在场:任务指令一次性给全,agent 独自闷头执行。但真实客服场景里,信息藏在用户脑子里,用户表达含糊、会改主意、会提出政策不允许的要求,agent 必须通过对话逐步获取信息并向用户确认关键操作;
• 没有规则约束:真实业务 agent 必须遵守领域策略(domain policy)——例如「基础经济舱不可改签」「一个订单只能退换一次」。这些规则不在模型权重里,只在一份策略文档里,考验的是长系统提示下的规则遵循(rule following);
• 只测一次成功率:学术基准通行 pass@1 甚至 pass@k(k 次里对一次就算数),但企业要的是「每一次都对」。可靠性没有被度量,就不会被优化。

τ-bench 的回答:把 agent 放进一个「模拟用户(LLM 扮演)+ 领域 API 工具 + 策略文档」的动态对话环境,用数据库终态比对自动判分,并用 pass^k 度量一致性。

二、基准设计:三组件与判分机制

每个领域(domain)由三部分构成:

1. 数据库 + API 工具

每个领域有一套 mock 数据库(JSON 文件,如零售域的 users.json(用户/地址/支付方式)、products.json(商品,每个商品有多种变体如尺寸颜色)、orders.json(订单)),由 GPT 生成种子数据 + 程序化组合而成,规模达数百用户、上千级条目。agent 通过读写两类 API 工具访问它——数据库状态对 agent 和用户都不直接可见,agent 必须先调查询工具搞清事实,再调写工具执行操作。

2. 领域策略文档(domain policy)

一份几千词的自然语言规章,作为系统提示喂给 agent,规定什么能做、什么不能做、做之前要满足什么条件(如「代客修改订单前必须向用户复述并获得明确确认」「pending 状态订单才可取消」「基础经济舱机票不可修改」)。策略是「临时约定的(ad-hoc)」——刻意与模型预训练里的常识不完全一致,逼 agent 真的去读文档而不是靠直觉。

3. 任务场景 + 模拟用户(user simulator)

每个任务包含:一个用户画像、一条给模拟用户的自然语言指令(scenario,如「你是 Yusuf,想把送到的机械键盘换成另一种轴体,但你说话简短、不主动透露信息」)、一组标注好的金标动作序列(golden actions,含工具名与参数)和对应的目标数据库终态。模拟用户由 LLM(默认 gpt-4o)扮演,基于该指令和完整对话历史生成回复,可以表现出含糊、分次透露信息、提出越权要求等真实行为。任务都经过精心人工雕琢,保证在策略约束下只有唯一正确结局——这是终态比对能成立的前提。

判分:数据库终态比对 + 输出信息检查

对话结束后,把数据库的最终状态与标注的目标状态做比对(哈希比较)——因为唯一正确结局对应唯一正确终态,所以无论 agent 走了哪条对话路径、工具调用顺序如何,只要终态一致就算成功。此外,若任务要求 agent 向用户告知某些信息(如退款金额),还会检查 agent 的回复中是否包含这些必需输出。两者都满足才算任务成功。

这个设计的妙处:评测高效且可靠(fast and faithful)——不需要 LLM 判卷,不需要比对动作轨迹(合法轨迹可能有多条),一次状态哈希比较就搞定;金标动作序列只用于构造终态和辅助分析,不作为唯一路径强制。

三、两个领域:τ-retail 与 τ-airline

值得注意的两个「非业务」工具:think(让 agent 显式写推理草稿,不改变环境——CoT 工具化的早期实践)和 transfer_to_human_agents(策略不允许或超出能力时应转人工——「知道自己不该做」也是被测能力)。airline 域整体比 retail 难:策略更复杂(舱位/退改/行李规则的组合)、任务常含复合请求。

四、一段真实对话走读:一次换货是怎么被评测的

论文附录给了完整轨迹,这里走读一个 retail 域的真实片段,感受任务的「肌理」。模拟用户被指派的场景是:用户 yusuf_rossi_9620 想对已送达的订单 #W2378156 换货(机械键盘换成另一种规格,顺带问智能恒温器)。对话以 |user| / |assistant| / |tool| 三种角色交替推进:

• agent 先调 get_user_details / get_order_details 核实身份与订单状态(数据库对双方都不可见,一切事实必须靠查询工具确立);
• 再调 get_product_details 查目标商品变体是否存在、价格差多少;
• 按策略向用户复述换货内容并请求明确确认,确认后才调写工具 exchange_delivered_order_items;
• 轨迹中还出现了环境的硬约束反馈——对未送达订单调换货工具会直接报错 non-delivered order cannot be exchanged,策略不允许的路径被工具层挡住,agent 只能改道或调 transfer_to_human_agents 转人工。

对话结束后,评测器不看这几十轮谁说了什么,只把 orders.json 等数据库文件的终态和标注终态做哈希比对——换货是否落到了正确的变体、差价用哪种支付方式补、其余数据分毫未动,一次比较全部覆盖。这个例子也解释了为什么任务要人工雕琢到「唯一正确结局」:但凡场景里差价支付方式有两种合法选择,终态就不唯一,判分器就废了。

五、pass^k:把「可靠性」变成一个数字

论文提出的新指标 pass^k(读作 pass hat k)定义为:对同一任务独立试跑 k 次,k 次全部成功的概率,再对所有任务取平均。给定某任务 n 次试验中成功 c 次,其无偏估计量为组合数之比:

pass^k = E_task [ C(c, k) / C(n, k) ]

它与广泛使用的 pass@k 恰好是镜像:pass@k 问「k 次里至少成一次」(采样越多越沾光,度量能力上限),pass^k 问「k 次全部成功」(随 k 增大指数衰减,度量最差情况下的可靠性)。若单次成功率为 p 且各次独立,pass^k ≈ p^k:一个 pass^1 = 90% 的 agent,pass^8 只剩约 43%。企业视角下这才是要命的指标——「1000 个客户里 900 个被服务好」和「同一个客户来 8 次每次都被服务好」是两种完全不同的承诺。

六、实验:最强模型不及格,一致性更是灾难

设置:被测 agent 用三种策略——原生函数调用(function calling / tool-calling)、ReAct(推理+动作交替)、Act(只动作不推理);模拟用户默认用 gpt-4o、策略为 llm(官方实现还提供 react / verify / reflection 三种增强模拟策略,后两者用额外 LLM 步骤校验用户回复是否贴合场景、不满意则重新生成,用于压低模拟器自身的噪声)。每任务多次独立试跑以估计 pass^k。

论文头条结果(2024-06):最先进的函数调用 agent(gpt-4o)整体任务成功率(pass^1)不足 50%(retail 约 61%,airline 约 35%);而且极不稳定——retail 域 pass^8 < 25%,即连做 8 次全对的任务不到四分之一。官方仓库后续更新的 leaderboard(节选,策略均为 tool-calling):

可读出的规律:① 原生函数调用稳定优于 ReAct/Act 文本式 agent;② 从 pass^1 到 pass^4,所有模型都近乎腰斩,可靠性坍塌是普遍现象而非个别模型缺陷;③ airline 全面难于 retail。

失败模式分析

作者对失败轨迹的归因指向三类核心短板:

• 对数据库的复杂推理:需要跨多次工具调用聚合信息再计算(如多商品换货的差价)时容易出错;
• 理解并遵守 ad-hoc 策略:agent 会被用户带偏,执行策略明令禁止的操作,或忘记「先确认再执行」这类流程性规定——规则写在系统提示里不等于会被遵守;
• 复合请求(compound requests):用户一句话里包含多个子请求时,agent 常漏掉一部分或顺序处理出错。

官方仓库还提供 auto_error_identification.py 做自动错误归因:先判定责任方(user / agent / environment),再分类错误类型(目标部分完成、用错工具、工具参数错误、执行了非预期操作)。

七、局限与后续演化

• 规模有限、用户模拟较简单:165 个任务、两个领域;LLM 模拟用户偶有失真(答非所问、提前泄露信息),评测方差部分来自模拟器而非被测 agent;
• 指标粗粒度:只看终态成败,不惩罚过程中的策略违规(只要最后没写坏数据库)、不评对话体验;
• 后被发现的判分漏洞:对「不改数据库、也无必需输出」的任务,什么都不做也能判成功——后续研究测得「躺平 agent」在 airline/retail 上竟可拿到 38% / 6.0%,提醒我们基准的判分器本身也需要对抗性审计;
• 后继家族:τ²-bench(2025)新增电信域(114 个任务),让用户侧也持有工具、与 agent 在共享环境中双向操作,并加入可编程的组合式任务生成器;IntellAgent 则从数据库 schema 和策略文档自动合成测试场景,与 τ-bench 结果高度相关。官方仓库现已标注建议使用更新的 τ³-bench。