# 2406.12045_τ-bench: A Benchmark for Tool-Agent-User

* [https://arxiv.org/abs/2406.12045](https://arxiv.org/abs/2406.12045)
* PDF: [https://arxiv.org/pdf/2406.12045](https://arxiv.org/pdf/2406.12045)
* 引用: 69(2025-07-20)
* 组织: Sierra
* GitHub: [https://github.com/sierra-research/tau-bench](https://github.com/sierra-research/tau-bench)

## 总结

* 方法
    * τ-bench
        * 模拟真实用户（通过大模型）和程序API交互
        * 要求代理遵循具体领域的政策规则（如航班政策）
        * 使用真实数据库、API、规则文件和用户请求模拟场景
    * 新指标 pass^k，用于衡量智能体在多次尝试中表现是否稳定可靠
* 数据集
    * τ-retail
    * τ-airline



## Abstract

目前的评测方法并没有考察语言智能体与人互动的能力，或者它们是否能遵守特定领域的规则，而这两点对于实际应用很重要。

为了解决这个问题，作者提出了一个新的评测方法 **τ-bench**，它模拟用户（由语言模型扮演）与语言智能体之间的动态对话，智能体有特定的 API 工具和规则可以用。

评估方式是看对话结束后数据库的状态，是否达到了预设的目标状态。他们还设计了一个新指标 **pass^k**，用于衡量智能体在多次尝试中表现是否稳定可靠。

实验发现，即使是像 GPT-4o 这样的最先进模型，成功率也不到 50%，在某些领域（如零售），稳定性更差（pass^8 低于 25%）。

因此，作者认为现在的智能体在“稳定执行”和“严格遵守规则”方面还有很大改进空间。


## 1.Introduction

### 🌟 语言代理（Language Agents）的潜力与挑战

**背景：**
语言代理被认为可以大幅提升各行各业的自动化水平，但要真正投入实际应用，需要满足几个关键条件，比如能长时间与人类和程序接口交互、遵守复杂规则、保持一致性和可靠性。

**问题：**
现有评测方法太简单，不能真实反映语言代理在现实环境中面对复杂对话、政策规则、API调用等情况的表现。


### 🧪 新提出的 τ-bench 评测框架

**τ-bench 介绍：**
这是一个用于评估语言代理真实交互能力的基准测试，特点包括：

1. 模拟真实用户（通过大模型）和程序API交互；
2. 要求代理遵循具体领域的政策规则（如航班政策）；
3. 使用真实数据库、API、规则文件和用户请求模拟场景。

![](https://img.zhaoweiguo.com/uPic/2025/07/nxNK04.jpg)

Figure 1: (a) In τ-bench, an agent interacts with database API tools and an LM-simulated user to complete tasks. The benchmark tests an agent’s ability to collate and convey all required information from/to users through multiple interactions, and solve complex issues on the fly while ensuring it follows guidelines laid out in a domain-specific policy document. (b) An example trajectory in τ-airline, where an agent needs to reject the user request (change a basic economy flight) following domain policies and propose a new solution (cancel and rebook). This challenges the agent in long-context zero-shot reasoning over complex databases, rules, and user intents.


**举例：**
用户想改签航班，但由于订的是“基本经济舱”，不能更改。但代理能识别出该票是在24小时内购买的，可以先取消再重新预订。这测试了代理对规则的理解和灵活处理能力。


### 📊 实验发现

* 目前的代理（包括使用 GPT-4o 的）在复杂任务中的成功率很低；
  * 例如，在 τ-airline 中，仅有 **35%** 成功率；
  * 多轮交互中成功率会进一步下降（例如 8 次尝试中成功一次的概率仅 ~25%）；
* 失败原因：
  * 无法处理复杂数据库查询、
  * 难以理解和遵守领域规则、
  * 无法应对多个复合请求。


### 🎯 目标与贡献

τ-bench 为构建更强大、更稳定、能适应真实环境的人机交互代理提供了评估和改进的基准平台。



## 2.Related Work


### τ-bench 做了什么：

τ-bench 是一个新的评测基准，目标是在**真实场景下**同时评估 **对话能力** 和 **工具使用能力**，并测试代理是否能持续地遵守领域特定规则。


### 与已有工作的区别：

1. **工具使用评测**（如 BFCL、ToolBench、ToolEmu 等）：
   * 主要评估大模型能否正确调用 API 函数。
   * 交互通常只有一步（一次指令、一次回应）。
   * 没有涉及多轮对话或人机信息交互。
   * ToolEmu 还模拟了工具执行过程，用于检测安全问题。

2. **任务型对话评测**（如 DSTC 系列）：
   * DSTC: Dialog System Technology Challenge
   * 多数基准是静态的，只评估已有的对话数据。
   * 有些使用规则或符号模拟用户，或用众包获取真人对话。
   * 最近也开始尝试用大模型模拟用户或评价对话。


### τ-bench 的特点：

* 使用大模型来**模拟用户**，生成更真实、动态的对话。
* 支持**多轮交互**，更贴近真实任务中的沟通与授权过程。
* 每次运行可以得到**有变化但可信的对话样本**，方便测试代理的稳定性。
* 用这些模拟对话来**系统评估 AI 代理的可靠性与稳健性**，为大规模实际部署提供依据。

---

## 3.τ-bench: A benchmark for T ool-A gent-U ser Interaction

### 🔁 **任务建模**

* 每个任务被建模为一个**部分可观测马尔可夫决策过程（POMDP）**，由状态S、动作A、观测O、转移T、奖励R、用户指令U组成。
* 智能体需要和两个对象交互完成任务：
  1. **数据库（db）**：通过API工具访问。
  2. **模拟用户（user）**：使用自然语言交互。


### 🔧 **数据库和API工具**

* 数据库存的是状态，智能体无法直接看到，只能通过API（如 Python 函数）来读写。
* 每个API调用是确定性的（输入确定输出）。


### 📜 **领域规则（Policy）**

* 每个任务域有一份规则文档，告诉智能体有哪些限制和操作流程。
* 有些限制在API中自动检查（如找不到付款ID时返回错误），有些需要智能体自己理解处理（如行李规定等）。


### 👤 **模拟用户**

* 使用语言模型（GPT-4）模拟人类用户。
* 用户只看到与智能体的对话，不知道API调用的内容。
* 用户行为是随机生成的（基于上下文），直到用户发出"###STOP###"结束对话。

### 🧩 **任务实例**

* 每个任务都有：
  * 一个用户模拟指令（设定用户身份、意图、偏好）。
  * 一个正确的数据库操作答案（作为评估依据）。
* 智能体必须完成这些操作，并向用户提供正确信息。


### 🏆 **奖励计算**

* 总分 `r = r_action × r_output ∈ {0,1}`，包括两个部分：
  1. 数据库操作是否正确（`r_action`）
  2. 对用户的回复是否包含必要信息（`r_output`）

### 📈 **评价指标（pass^k）**

* 类似代码任务的 pass@k（至少成功1次），**pass^k** 更严格：要求 **k次都成功**。
* 衡量的是智能体在同一任务、不同对话变化下的**稳定性与可靠性**。

$$
\operatorname{pass}^{\wedge} \mathrm{k}=\mathbb{E}_{\text {task }}\left[\binom{c}{k} /\binom{n}{k}\right], \quad \operatorname{pass} @ \mathrm{k}=1-\mathbb{E}_{\text {task }}\left[\binom{n-c}{k} /\binom{n}{k}\right] .
$$
* 参数
    * `n` 是某个任务被运行的总次数（即智能体尝试的次数）。
    * `c` 是这 `n` 次尝试中**成功的次数**（reward = 1）。
    * `k` 是我们关注的子集大小，比如“要求连续成功 3 次”就是 `k=3`。
    * `E_task[·]` 是对所有任务求平均。
    * 分子 $\binom{c}{k}$ 是：**在 `c` 个成功中，选 `k` 个成功组合**的数量。
    * 分母 $\binom{n}{k}$ 是：**在 `n` 个总尝试中，任意选 `k` 个组合**的数量。
    * $\binom{n-c}{k}$：从失败的尝试中选出 k 个组合数（即“全失败”的组合）。
    * $\binom{n}{k}$：总的所有组合数。
* 说明
    * pass^k 的定义
        * 所以这个比值就是**k次全成功的概率**。
        * 再对所有任务取平均，就是最终的 pass^k 值。
    * pass\@k 的定义
        * 所以 $\frac{\binom{n-c}{k}}{\binom{n}{k}}$ 是**k次都失败的概率**。
        * 所以 `1 - 这个值` 就是**至少有一次成功的概率**，即 pass\@k。


### 📊 **示例：两个任务领域**

| 任务域           | 用户数   | 数据条目   | API工具数      | 任务数 |
| ------------- | ----- | ------ | ----------- | --- |
| 零售（τ-retail）  | 500用户 | 1000订单 | 写操作7个，读操作8个 | 115 |
| 航空（τ-airline） | 500用户 | 2000预订 | 写操作6个，读操作7个 | 50  |



## 4. Benchmark Construction

### 基准构建流程（三个阶段）

1. **第一阶段：手动设计**
   * 设计数据库结构、API 和规则，尽量保持简单，便于标注和逻辑一致。
   * 每个领域需要几十个 schema、API 和规则，足够挑战现有智能体。

2. **第二阶段：用大模型生成数据**
   * 在已有 schema 基础上，用 GPT-4 自动生成批量数据（如产品或航班条目）
   * 再手动修复小问题。

3. **第三阶段：手动标注任务并用智能体验证**
   * 编写任务指令，运行 GPT-4 Turbo 代理测试其是否总能得到唯一正确的数据库结果。
   * 反复迭代修改指令，直到无歧义，并对任务进行标注。


### 4.1 Domains

1. **τ-retail（零售）**
   * 智能体需要处理订单取消、退换货、地址变更等。
   * 规则明确：一个订单只能取消一次，退换货也只能操作一次。

2. **τ-airline（航空）**
   * 涉及航班预订、改签、退款等。
   * 有更复杂的规则，如行李限额、支付方式组合、会员等级影响等。


### 4.2 Key Characteristics

* **真实感强**：用户模拟自然、任务开放、数据复杂，利用大模型生成真实语句。
* **任务多样**：虽然比真实世界简化，但仍支持高度开放和富有挑战的任务。
* **评估标准客观**：通过数据库结果比对，代替主观人工判断，确保评估准确可复现。
* **模块化易扩展**：支持轻松添加新领域、新规则、新任务，鼓励社区共同参与扩展。


## 5.Experiments

### 📌 **实验内容概述**

* 模型
    * **OpenAI**: gpt-4o, gpt-4-turbo, gpt-3.5 等
    * **Anthropic**: claude-3-opus 等
    * **Google**: gemini-1.5
    * **Mistral** 和 **Meta (LLaMA-3)**

> 只有 Mistral 和 Meta 模型开源。小模型（7B/13B）没测试，因为基准任务难度太高。


### 🧠 **方法对比**

* **主要方法**：Function Calling（FC），大部分模型原生支持，除了 LLaMA-3。
* **对比方法**：ReAct（思考 + 行动）和 Act-only（只行动）。
* 不适合使用的方法：如自反思和复杂计划，因为不适合实时用户交互。


### 📊 **主要结果**

* 模型表现（pass^1 得分，越高越好）：
    * 最好：**gpt-4o**
    * 闭源比开源模型表现明显更好（如 llama3、mistral 仍有差距）
    * 最难任务：航空类任务（gpt-4o 也只能完成 35.2%）

* 方法对比：
    * **Function Calling（FC）> ReAct > Act-only**
    * ReAct 添加“思考”内容能提高效果

* 可靠性问题（pass^k 趋势）：
    * 模型表现不稳定：即便 gpt-4o 平均能解决 60%，多试几次后（如 pass^8）成功率大降至 <25%。

* 成本：
    * 每个任务成本：约 **\$0.38（agent）+ \$0.23（user）**
    * 主要花费来自长系统提示词（如 policy、函数定义）


### 🧩 **失败原因分析（gpt-4o）**

在零售任务中，有约 36 个失败案例，主要分 3 类：

1. **提供了错误的信息或参数**（55%）
   * 例：给了用户不需要的商品，或价格计算错误。
   * 说明模型在理解数据库、用户意图上还需提升。

2. **做了错误决策（违反规则）**（25%）
   * 例：应一次性处理多个退货项，但模型只处理了一个。

3. **部分解决请求**（19%）
   * 例：用户要求修改所有订单地址，但模型只改了一个。


### 🧪 **规则作用的对比实验**

* 移除规则文档后：
  * 零售场景：影响不大（靠常识也能完成）
  * 航空场景：影响很大（需要理解复杂规则）


### 🔍 结论

* 闭源模型整体表现更好，但仍有改进空间
* τ-bench 是一个很好的测试平台，因为任务难、差异大
* **未来改进方向**：
  * 增强推理能力
  * 支持长对话记忆
  * 针对特定领域微调或提供程序模板（agent scaffolding）


## 6.Disscussion

好的，这段内容主要讲的是一个名为 **τ-bench** 的新评测基准，用来测试智能体（agent）在现实动态环境中与人类和工具互动时的可靠性。下面是简洁的总结：


### τ-bench 的作用：

* 用语言模型模拟用户，实现自动化测试；
* 测试智能体是否能持续地遵守特定领域的规则；
* 实验结果显示：即使是最先进的模型（SOTA）在真实场景中也不够可靠。

---

### 存在的改进空间：

1. **模拟用户的不足**：

   * 指令可能有错别字或含糊；
   * 用户通常不了解复杂规则，像现实生活中真实的用户；
   * 模拟用户的语言模型可能在推理、计算、记忆上能力不足。

2. **改进建议**：

   * 增加模拟器的系统性检查，确保结果唯一；
   * 让领域规则更复杂，更贴近现实；
   * 引入更多评估指标，比如是否遵守规则；
   * 数据标注很难，需要深入理解任务和智能体；
   * 当前的任务设计可能有偏见，未来可以探索更客观的方式。

---

### 智能体面临的挑战：

* 当前基于语言模型的 function calling 智能体**不够稳定**，经常**无法遵守规则**；
* 改进这些问题能极大促进现实任务的自动化；
* 还需要提升：长时间信息追踪能力、记忆能力、从上下文中提取关键信息的能力，尤其是在信息冲突的情况下。