25. τ-bench 与 τ²-bench：Tool-Agent-User Interaction 的典型方法
Benchmark 专题 · 4～6 小时
学习目标
- 理解数据库状态评测和用户模拟
- 理解 policy-following 与 conversational tool use
- 掌握 pass^k 的可靠性含义
前置知识
- 第 10、11、16 章
本章产物： 复刻一个最小 τ-bench 风格环境。
25.1 τ-bench 为什么重要
τ-bench 把真实企业 Tool Agent 的几个关键因素放在一起：
User Simulator
↕
Agent
↕
Domain Tools
↕
Database
+
Policy它不只问“工具调用对不对”，还测 Agent 是否：
- 和用户动态对话；
- 遵守领域规则；
- 修改正确数据库状态；
- 多次执行保持一致。
25.2 State-based Reward
τ-bench 的重要做法是：
对话结束后比较数据库状态和 annotated goal state。
这比仅检查最终文本更接近真实业务结果。
例如：
Goal:
refund order A
Final DB:
A refunded
B unchanged
refund amount correct25.3 User Simulator
真实客服任务往往需要澄清：
Agent: 请提供订单号
User: 我记得尾号是 32
Agent: 是 A-1032 吗？
...用户模拟器本身也会引入随机性，所以需要固定 protocol、重复运行并检查 simulator quality。
25.4 Policy
Tool Agent 的正确性包含：
Task Completion
+
Policy Compliance例如不能违反退货期限、不能跳过身份验证。
25.5 pass^k
τ-bench 特别强调多次运行可靠性。它指出单次能成功的 Agent，连续多次运行仍可能不稳定。
在生产设计中，可以把这个思想转成：
critical_case_all_runs_success或者直接报告不同 k 下的连续成功指标。
25.6 τ²-bench：Dual Control
τ²-bench 进一步关注一类现实问题：Agent 不总是能自己操作环境，有时必须指导用户完成动作。
例如：
Agent 能操作后台
+
用户必须在自己的设备完成某一步这要求 Agent 同时：
- 推理；
- 工具使用；
- 正确指导用户；
- 根据用户反馈调整。
25.7 版本意识
截至 2026 年，τ-bench 相关仓库已经继续演进。学习时要区分：
- 原始论文方法；
- 后续 τ²/τ³ 实现；
- 修复后的任务/环境。
Benchmark 必须版本化。
25.8 最小复刻
建立：
SQLite DB
3 tools
policy.md
20 tasks
user simulator
state scorer先验证方法，而不是马上做复杂客服系统。
25.9 验收问题
- τ-bench 为什么不只评 Tool Call？
- User Simulator 会引入哪些评测误差？
- τ²-bench 的 Dual Control 与普通 Agent 有何不同？