τ-bench 评测框架：把客服 Agent 放进带策略约束的模拟对话里
τ-Bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains
秒懂
- 它是什么？
- τ-bench 用「策略 + 工具 + 任务 + 用户模拟器」四件套，把客服场景的 Agent 评测做成可复现的仿真。本文说明它的数据流、CLI 入口、τ³ 版本带来的知识检索与语音全双工分支，以及版本间评分不可比这个容易被忽略的坑。
- 适合谁用？
- 如果你要评的是「Agent 能否在多轮对话里遵守书面策略并正确调用工具」，而不是单轮问答准确率，τ-bench 的结构是对口的：策略、工具、任务、用户模拟器四者分离，任务文件里写死了期望动作，评分不依赖模型自评。反过来，如果你的 Agent 不面向客服流程、没有可枚举的工具集，或者你只想测模型的知识边界，这个框架会带来大量与目标无关的工程量。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 4 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它评的不是模型会不会答题，而是 Agent 会不会照章办事
多数语言模型基准把问题压成一次输入一次输出，评的是答案对不对。客服场景不是这样：用户的需求分散在十几轮对话里，Agent 每轮都可能要查订单、改地址、办退订，而每一步都受一份书面策略约束。策略里会写明什么条件下可以退款、哪些操作需要先验证身份、哪些请求必须转人工。τ-bench 要测的正是这种能力，即在多轮交互中既满足用户诉求，又不越过策略边界。
它的目标读者是 Agent 开发者，不是模型训练者。README 里有一句区分很关键：如果你在评测 Agent 而不是训练，应该用 base 任务切分，它对应原始 τ-bench 的完整任务集，并且是默认值。这句话暗示了任务集存在多个切分，不同切分面向不同用途，选错切分会让你得到的分数无法与公开结果对照。
从仓库结构看，每个域包含四类东西：一份策略，一组 Agent 可调用的工具，一组待评测任务，以及可选的用户侧工具。用户侧工具这个设计容易被忽略，它意味着用户模拟器不只是会说话，还能执行动作，比如在对话中自己完成某步操作。这让评测能覆盖双方都在操作系统的场景，而不只是 Agent 单方面调用工具。
一次评测的参与者有三个，而不是两个
常规的 Agent 评测是 Agent 对任务。τ-bench 的编排里多了一个用户模拟器，它由另一个 LLM 驱动，通过 --user-llm 指定，与被测 Agent 的模型 --agent-llm 分开配置。这个分离是刻意的：用户模拟器的行为质量会直接影响 Agent 的得分，如果两者用同一个模型，你很难判断失败是 Agent 没理解还是模拟器没把需求说清楚。
编排层区分两种通信模式，README 用半双工和全双工来命名。文本模式是半双工，轮流发言，Agent 说完用户再说。语音模式是全双工，双方可以同时说话，走的是实时音频 API。仓库里 src/tau2/orchestrator/ 这个目录专门承载这两种编排方式，说明模式差异被收敛在编排层，而不是散落在各个域里。
评分侧的关键在任务文件。docs/evaluation.md 提到 evaluation_criteria.actions 和 reward_basis 两个概念：前者描述期望动作，后者决定奖励的计算范围。也就是说评分不是让模型给自己打分，而是拿 Agent 实际产生的动作去比对任务里预先写好的期望动作。这种设计的好处是可审计，坏处是任务文件的正确性直接决定评测的可信度，而后文会看到，任务文件确实出过错。
从 uv sync 到 tau2 run：跑通一次评测的实际路径
安装方式在 τ² 到 τ³ 之间变了。README 的升级说明写得很直接：现在用 uv 而不是 pip install -e .，Python 要求从 >=3.10 提到 >=3.12, <3.14。这个上界值得注意，它不是「至少 3.12」而是明确排除了 3.14 及以上，如果你的环境默认装了更新的解释器，uv sync 会失败。
基础安装只有一条命令：
uv sync
这条命令装的是核心部分，对应文本模式下的 airline、retail、telecom、mock 四个域。知识检索、语音、强化学习接口和开发依赖都是可选项，各自对应一个 extra：uv sync --extra knowledge 装 banking_knowledge 的检索管线，uv sync --extra voice 装语音与音频原生功能，uv sync --extra gym 装 gymnasium 的 RL 接口，uv sync --extra dev 装 pytest、ruff 和 pre-commit。语音功能还有系统级依赖，macOS 上文档给的是 brew install portaudio ffmpeg。
密钥配置走 .env 文件，先 cp .env.example .env 再填入。README 说明底层用 LiteLLM，所以任何 LiteLLM 支持的提供方都能接。这意味着模型名不是硬编码的枚举，而是按 LiteLLM 的命名约定传字符串。
跑一次评测的最小命令是这样的：
tau2 run --domain airline --agent-llm gpt-4.1 --user-llm gpt-4.1 --num-trials 1 --num-tasks 5
结果落在 data/simulations/，用 tau2 view 浏览。第一次接触这个项目的人可以先跑 tau2 intro，README 说它会列出可用域、命令和示例。这里有个实用建议：先用 --domain mock 加 --num-tasks 5 这种小规模组合验证环境，再换成 airline 或 retail，因为真实域的任务更长，失败时排查成本更高。
banking_knowledge 与语音分支：τ³ 把评测面拉宽了
v1.0.0 这一版把项目从 τ² 推到 τ³，新增了两条与原有文本客服差异较大的分支。
第一条是知识检索域 banking_knowledge。它不是纯工具调用，而是带文档检索的客服场景，仓库描述里提到可配置的 RAG 管线、文档搜索、嵌入向量，以及基于 shell 的 agentic 检索。也就是说 Agent 除了调用业务工具，还要自己去检索知识库。这条分支需要 --extra knowledge，src/tau2/knowledge/README.md 是它的专门文档。检索类评测的麻烦在于变量多：切分方式、嵌入模型、召回条数都会影响结果，所以跨实现比较分数时需要连同检索配置一起报告，否则数字没有意义。
第二条是语音全双工。它接的是实时音频提供方，README 点名了 OpenAI、Gemini、xAI 三家。这条分支的评测对象从「文本对话策略」扩展到「端到端音频交互」，涉及打断、抢话这类文本模式里不存在的情况。src/tau2/voice/README.md 是入口文档。需要注意它同时带来系统依赖和额外的 API 成本，如果你的产品是纯文本客服，这条分支的投入产出比不高。
v1.0.0 还包含 75 处以上的任务修正，覆盖 airline、retail、banking 三个域，README 说明这些修正来自 SABER 那篇论文的分析，具体是删除不正确的期望动作、澄清含糊指令、修掉不可能满足的约束、补上缺失的兜底行为。任务修正本身是好事，但它同时说明此前的任务集存在系统性瑕疵，用旧版本跑出来的分数需要打折扣看待。
版本不可比是这个项目最硬的约束
v1.0.1 的发布说明只有一句话的核心信息：修了几个 banking_knowledge 的任务错误，该域的分数因此变化，并且明确写了用 tau2-bench < 1.0.1 得到的结果与 >= 1.0.1 不可比，受影响的排行榜提交已被重新评分。
这条约束的严重性在于它不是 bug 修复那么简单。任务文件是评分基准，改任务等于改考卷，改完之后的分数自然不能和改之前放一起比。README 给了两条出路：老的结果文件可以用 tau2 evaluate-trajs --fresh-tasks 重新打分，因为轨迹本身还在，只是评分标准变了；如果要复现修复前的行为，就固定到 pre-v1.0.1 标签。这两条路对应两种需求，重新打分是为了让历史结果进入新口径，固定旧标签是为了复现旧结论。
对使用者的实际影响是：论文或内部报告里引用 τ-bench 分数时，必须写明版本号，尤其是涉及 banking_knowledge 的结果。只写「τ-bench 得分」而不写版本，在 2026 年 7 月之后就是一条不完整的信息。README 也补了一句其他域不受影响，这句话缩小了范围，但没有消除版本标注的必要性。
什么时候它是对的，什么时候是错的工具
τ-bench 的适用面比它的名字看起来窄。它假设你的场景有可枚举的工具集、有可写下来的策略、有可枚举的用户意图。客服、订单处理、账户管理这类流程符合这三条。反过来，如果你的 Agent 主要做开放式研究、代码生成或者创意写作，没有策略文档可写，也没有期望动作可以预先标注，硬套这个框架只会得到一堆无法解释的分数。
另一个不适用的情况是：你只想测模型的知识边界。那种需求用静态问答集更直接，τ-bench 会给你引入用户模拟器、编排层、任务文件三层额外变量，而这三层每一层都可能成为分数波动的来源。
与静态问答基准相比，差异在评测对象的粒度。静态基准评的是单次生成的质量，τ-bench 评的是一段轨迹的合规性：Agent 有没有在正确的轮次调用正确的工具、有没有在策略允许的范围内满足用户、有没有在需要时转人工。代价是评测成本高得多，一次运行要消耗 Agent 和用户模拟器两份模型调用，任务越长消耗越大。--num-trials 这个参数的存在也说明单次运行的结果有随机性，需要多次试验才能看出差异，而每次试验都是真金白银的 API 调用。
维护成本与许可证：MIT 之下的实际负担
许可证是 MIT，这是最宽松的一类，用于商业内部评测没有明显的许可障碍。但这里不做法律判断，涉及具体合规问题应当咨询法务。需要提醒的是依赖侧的许可：项目通过 LiteLLM 接入各家模型提供方，语音分支还依赖 portaudio 和 ffmpeg，这些组件的许可证与 MIT 不同，打包分发时要单独核对。
维护成本主要来自三处。第一是版本迁移，τ² 到 τ³ 改了安装工具、Python 版本下限，README 还提到部分内部 API 被重构，CHANGELOG.md 是唯一线索。如果你在 τ² 之上写过自定义 Agent 或自定义域，升级需要逐条对照变更记录。
第二是任务集的演进。任务修正会持续发生，而每次修正都可能让历史分数失效。这意味着把 τ-bench 接入 CI 时，不能只固定代码版本，还要固定任务集版本，否则某天上游修了一个任务，你的回归基线就悄悄变了。
第三是外部 API 依赖。评测本身要调用模型，模型提供方下线旧模型或调整行为都会影响结果。README 用 LiteLLM 做抽象层缓解了接口差异，但缓解不了模型本身的变化。想把 τ-bench 当作长期基线用，需要把模型名、版本号和任务集版本一起记录在结果文件旁边。
编辑结论
如果你要评的是「Agent 能否在多轮对话里遵守书面策略并正确调用工具」，而不是单轮问答准确率，τ-bench 的结构是对口的：策略、工具、任务、用户模拟器四者分离，任务文件里写死了期望动作，评分不依赖模型自评。反过来，如果你的 Agent 不面向客服流程、没有可枚举的工具集，或者你只想测模型的知识边界，这个框架会带来大量与目标无关的工程量。动手前先确认三件事：一是你用的版本，v1.0.1 修了 banking_knowledge 的任务错误，README 明确写了 1.0.1 之前的分数与之后不可比，老结果文件可以用 tau2 evaluate-trajs --fresh-tasks 重新打分，要复现旧行为就固定到 pre-v1.0.1 标签；二是 Python 版本必须落在 >=3.12, <3.14 区间，且安装走 uv sync 而不是 pip install -e .；三是先跑 tau2 run --domain mock 把链路走通，再换到 airline 或 retail 这种真实域。
社区笔记