1. 为什么单次跑分骗过了所有人τ-bench 要解决的真实痛点如果你做过工具型 Agent 的评测大概率经历过这种落差本地跑一个函数调用测试模型十次里九次能选对 API参数也填得像模像样你会觉得“这东西能上线了”。可真接到客服场景里用户说“帮我把上周那个订单退了顺便看看能不能换个便宜点的颜色”Agent 立刻开始表演——要么只退了货忘了换色要么换色时选错了商品 ID要么干脆在第三轮对话里把用户最开始说的订单号记丢了。τ-benchTool-Agent-User Interaction Benchmark就是冲着这个落差来的。它是什么一句话一个把“模拟用户 真实风格数据库 API 领域政策文档”三者绑在一起的多轮交互评测基准专门测工具型 Agent 在真实业务域里能不能稳定把事办成。它能做什么能告诉你一个模型不只是“会不会调函数”而是“能不能在用户表达含糊、需求中途追加、政策处处设限的情况下把数据库最终状态改对”。适合谁做客服 Agent、任务型对话、工具调用链路的工程同学以及想给自家 Agent 选型、做回归测试的团队。它和传统函数调用基准最大的区别在于传统基准通常一次性把完整指令和全部参数喂给模型模型只要输出正确的 JSON 就算过。τ-bench 不这么玩。它让语言模型扮演用户用户一开始只给模糊目标缺的信息要 Agent 主动问用户还会中途加需求比如“对了我那张票能不能也一起改了”同时每个领域都有一份政策文档规定哪些操作允许、哪些必须先确认、哪些票种根本不能改签。Agent 要在“问用户”“查数据库”“读政策”“改状态”之间来回切换最后系统比对数据库最终状态和预先标注的目标状态一致才算成功。更狠的是 pass^k 这个指标。普通 passk 是“跑 k 次至少成功一次”而 pass^k 要求“跑 k 次每一次都成功”。为什么这个区别要命因为用户模拟器带随机性同一个任务换个措辞、换个追问顺序模型行为就可能漂移。GPT-4o 在 τ-retail 上单次成功率约 61%听起来还行但 pass^8 直接掉到 25% 以下——也就是说同一个任务连跑八次全部成功的概率不到四分之一。对真实业务来说这种“偶尔能行”的可靠性根本不敢上线。我实测下来最大的感受是τ-bench 暴露的不是“模型不会调工具”而是“模型不会在沟通、操作、规则三者之间做长期协调”。它把评测重点从“说得像不像”挪到了“最终状态对不对”这个转向非常工程化也更接近你真正关心的上线风险。2. 跑 τ-bench 之前要准备什么TaoToken 接入与模型选型τ-bench 官方实现依赖模型同时具备两样东西一是稳定的 function calling 能力二是能扮演用户模拟器的对话模型。原论文里 Agent 用 GPT-4o用户模拟器用 GPT-4-0613。你自己复现时最省事的路径是通过一个兼容 OpenAI 接口的网关来统一管理这些模型调用TaoToken 就是干这个的——它提供 OpenAI 兼容的 Base URL你原来的openaiSDK 几乎不用改代码只换 base_url 和 key 就能跑。先说清楚它在这里的角色τ-bench 的 Agent 每一步都要决定“是给用户发消息还是调工具”用户模拟器每一步都要根据对话历史生成下一条用户消息这两条链路都是高频 API 调用。用统一网关的好处是你可以在一个地方切换被测模型GPT-4o、Claude、Gemini 等和用户模拟模型不用为每个模型单独配环境。这对做对比实验特别重要因为 τ-bench 的价值就在于横向比较不同模型在同样任务上的 pass^k。模型选型上有几个坑要提前避开。第一用户模拟器不要用太弱的模型。论文用 GPT-4-0613 是有道理的弱模型扮演用户时会“太好说话”——Agent 推荐一个不符合用户偏好的商品弱模拟器可能就接受了导致任务被误判为成功。第二被测 Agent 必须支持原生 function calling文本格式的 ReAct 在 τ-bench 上普遍更差因为 JSON 解析错误会直接污染工具调用。第三注意上下文长度。τ-airline 的系统提示里塞了完整政策文档加所有 API 定义输入 token 消耗很大论文里 GPT-4o 每个任务光 Agent 侧就约 0.38 美元主要花在输入上。你需要准备的东西清单一个能访问的模型网关Base URL API Key、Python 3.10 环境、τ-bench 官方仓库、以及足够的 API 额度做多次运行。因为 pass^k 要求每个任务至少跑 3 次、通常跑 8 次任务数又是 115零售 50航空总调用量不小建议先用小任务子集验证链路再全量跑。这里有个经验别一上来就全量跑。先用 τ-retail 里挑 5 个任务每个跑 3 次确认 Agent 能正常调工具、用户模拟器能正常结束对话、评测脚本能正确比对数据库状态再放大规模。我见过太多人直接全量跑结果跑到一半发现用户模拟器没触发结束标记所有任务都超时白烧一堆额度。3. 可复制的评测配置settings 与 Agent 参数怎么填这一节给你能直接抄的配置。τ-bench 的核心配置分三块模型接入配置、Agent 运行参数、用户模拟器参数。先看模型接入如果你用 OpenAI 兼容方式接 TaoToken配置长这样{ base_url: https://taotoken.net/api, api_key: sk-你的key, agent_model: gpt-4o, user_model: gpt-4-0613, agent_temperature: 0, user_temperature: 1 }注意agent_temperature设 0、user_temperature设 1 是论文的设置别搞反。Agent 温度低是为了减少模型自身随机性让失败更多归因于任务难度而非采样噪声用户温度高是为了模拟真实用户表达的多样性这正是 pass^k 要测的东西。如果你把用户温度也设 0那 pass^k 会虚高因为用户每次说的话都一样测不出稳定性。Agent 运行参数里最关键的是最大行动步数。论文设的是 30 步一步 一次工具调用或一次给用户发消息。这个值太小会导致复杂任务被截断太大则浪费额度。零售任务一般 15 步内能完成航空任务因为要查航班、算行李、比价格经常逼近 30 步。建议先按 30 跑观察有多少任务是因为“步数耗尽”失败的再决定是否调整。用户模拟器的配置要单独说。它需要接收一个场景描述包含用户身份、初始目标、偏好、可能的追加请求。这部分在 τ-bench 里是隐藏指令不传给 Agent。配置结构大致是[user_simulator] model gpt-4-0613 temperature 1 max_turns 30 end_token ###STOP### scenario_file data/tau_retail/tasks.jsonend_token是用户模拟器表示“我的需求都表达完了”的标记Agent 看到这个标记后应该结束对话。如果这个标记没被正确触发任务会一直跑到 max_turns 然后判失败这是新手最常见的坑之一。还有一个容易忽略的配置政策文档的注入方式。τ-bench 把领域政策放在 Agent 的系统提示里而不是通过工具动态查询。这意味着政策文档的长度直接影响每次调用的输入 token。τ-airline 的政策比 τ-retail 长得多规则也更绕比如会员等级影响免费行李额、舱位影响改签费、某些支付方式组合有特殊限制。如果你要扩展新领域政策文档的写法很讲究规则要写成 Agent 能直接推理的形式别写成给人看的散文。最后提醒一个配置细节数据库和 API 是本地 Python 实现的不需要真的连数据库。τ-bench 用 JSON 文件存初始状态API 是纯函数执行后修改内存中的状态。评测时比对的是内存里的最终状态和 ground truth。所以你不需要配任何数据库连接克隆仓库、装依赖、填模型配置就能跑。4. 一次完整跑分验证从发请求到看结果配置填好后跑一次完整验证。以 τ-retail 为例流程是加载任务 → 初始化数据库状态 → 启动用户模拟器 → Agent 循环交互 → 比对最终状态 → 计算 pass^k。先跑单个任务看链路通不通。命令大致是这样python run_tau_bench.py \ --domain retail \ --task_id 0 \ --num_trials 3 \ --agent_model gpt-4o \ --user_model gpt-4-0613 \ --max_steps 30跑起来后你会看到对话轨迹被打印出来。一个正常的交互大概长这样用户说“我想退掉上周买的那个水壶”Agent 先调get_user_details拿用户 ID再调get_order_details查订单发现用户有多个订单于是问用户“您说的是哪个订单”用户补充订单号Agent 查商品、查政策、确认可退调return_delivered_order_items最后告诉用户退款金额。整个过程 Agent 在“问用户”和“调工具”之间切换了好几次。验证成功的标志是评测脚本输出reward: 1.0并且数据库最终状态和 ground truth 一致。如果输出reward: 0.0脚本通常会告诉你失败原因是数据库状态不对还是 Agent 没告诉用户必要信息比如退款金额。注意 τ-bench 的奖励是r_action × r_output两个都满足才是 1所以数据库改对了但没告知用户关键信息照样判失败。单任务通了之后跑一个小批量看 pass^kpython run_tau_bench.py \ --domain retail \ --task_ids 0,1,2,3,4 \ --num_trials 8 \ --agent_model gpt-4o \ --user_model gpt-4-0613num_trials 8就是每个任务跑 8 次用来算 pass^8。跑完后你会看到类似这样的结果pass^1 约 0.6pass^2 约 0.45pass^4 约 0.32pass^8 约 0.24。这个下降曲线就是 τ-bench 最想让你看到的东西——单次成功率看着还行但要求连续多次都成功时可靠性断崖式下跌。我实测时特别注意了失败任务的轨迹。有一类失败特别典型Agent 第一次跑成功了第二次用户换了个说法比如把“退掉水壶”说成“这个我不想要了能退吗”Agent 就多问了一轮结果在后续步骤里把之前查到的订单信息搞混了最后退错了商品。这不是模型“不会”而是它在长对话里对已确认信息的追踪不稳定。pass^k 就是专门抓这种问题的。跑分时建议把每次 trial 的完整轨迹存下来包括每步的 action、observation、用户消息。τ-bench 官方脚本支持 dump 轨迹你后面分析失败原因全靠它。光看一个 reward 数字没用得看轨迹才知道模型到底在哪一步走偏的。5. 常见报错与排查401、local proxy failed、reading choices 怎么解跑 τ-bench 时你会撞上几类典型报错这里逐个拆。401 Unauthorized最常见基本是 key 或 base_url 配错。检查你的api_key是不是完整复制了有没有多余空格检查base_url是不是https://taotoken.net/api注意末尾不要多加/v1或斜杠不同网关对路径的处理不一样。如果你用的是环境变量确认OPENAI_API_KEY和OPENAI_BASE_URL都被正确读取有时候 shell 里 export 了但 Python 进程没继承到。还有一种情况是 key 额度用尽返回也是 401 或 403去控制台看一眼余额。local proxy failed / connection error这类报错通常是网络层的问题不是模型层。先确认你的运行环境能正常访问配置的 base_url用curl直接打一下接口看通不通。如果是公司内网可能有出站限制需要走允许的出口。注意不要用任何非正规的网络工具正规网关的域名直接访问即可。另外检查是不是代理环境变量HTTP_PROXY/HTTPS_PROXY干扰了请求有时候本地设了代理但网关不需要反而导致连接失败unset 掉再试。Error reading choices / 返回结构解析失败这个报错说明你拿到的响应不是标准的 OpenAI chat completion 格式。常见原因有三个一是模型名写错了网关找不到对应模型返回了错误信息而不是正常响应二是你用的 SDK 版本和网关的响应格式不匹配建议用较新的openaiPython 包三是某些模型在 function calling 时返回的tool_calls字段结构有差异τ-bench 的解析代码可能没兼容。排查方法是把原始响应打印出来看别只看异常信息。OAuth / authentication 相关报错如果你在配置里混用了不同认证方式比如同时设了 API key 和 OAuth token可能冲突。τ-bench 走的是标准 API key 认证不需要 OAuth 流程。把多余的认证配置清掉只保留 base_url api_key。任务一直不结束 / 跑到 max_steps 判失败这不是报错但很常见。原因通常是用户模拟器没有正确触发结束标记或者 Agent 一直在问重复的问题。检查用户模拟器的end_token配置以及 Agent 是不是陷入了“问用户→用户回答→再问同样的问题”的死循环。后者往往是 Agent 没有正确解析用户回复里的信息属于模型能力问题换个更强的 Agent 模型能缓解。数据库状态比对失败但对话看起来没问题这是最隐蔽的一类。Agent 可能完成了主要操作但漏了复合请求的一部分比如用户要求退货换货Agent 只退了货。或者 Agent 操作顺序错了先换了第一个商品导致第二个无法换政策规定一个订单只能调一次换货工具。这类问题要看轨迹里的工具调用序列对照政策文档检查每一步是否合规。τ-bench 的失败分析里参数错误占约 55%规则违反占约 25%复合请求漏做占约 19%你可以按这个比例去定位。排查时有个通用技巧把agent_temperature临时设成 0 并且只跑一个任务把完整轨迹打出来逐步看。随机性去掉后失败原因会清晰很多。定位到问题后再恢复多 trial 跑 pass^k。6. 把 τ-bench 用起来从跑分到选型与回归跑通一次之后τ-bench 真正的价值在于把它变成你的 Agent 选型和回归测试工具。几个实用方向。第一用它做模型选型。别只看单次成功率重点看 pass^4 和 pass^8。一个模型 pass^1 高但 pass^8 掉得厉害说明它“偶尔行但不稳”这种模型上线风险大。反过来pass^1 稍低但 pass^k 下降平缓的模型可能更适合真实业务。论文里 GPT-4o 在零售上 pass^1 约 61%、pass^8 低于 25%这个衰减幅度就是你要警惕的信号。第二用它定位你的 Agent 架构短板。τ-bench 的失败分类很清晰参数错误、规则违反、复合请求漏做。如果你的 Agent 大量失败在参数错误说明数据库查询和组合推理能力不足可以考虑在 Agent 里加一个专门的“信息收集”阶段先把所有需要的 ID 和参数查清楚再动手。如果失败在规则违反说明政策文档没有被真正理解可以试试把政策拆成更细的检查步骤或者在系统提示里用更结构化的方式呈现规则。第三把它接进 CI 做回归。每次改 Agent 的提示词或工具定义跑一个小任务子集比如 10 个任务 × 3 trials看 pass^k 有没有下降。这比人工抽查对话高效得多也能防止“改了一个地方另一个地方悄悄退化”。第四扩展你自己的领域。τ-bench 的模块化设计允许你加新领域只要提供数据库结构、API 实现、政策文档、任务实例和 ground truth。如果你做的是保险、物流、酒店客服完全可以照着 τ-retail 的结构搭一个自己的评测集。关键是任务要设计成“唯一正确最终状态”否则评测会有歧义。最后说个实际经验τ-bench 跑起来成本不低全量跑一次零售加航空、每个任务 8 trialsAPI 费用可能上百美元。建议先用小规模验证确认你的 Agent 配置没问题再决定全量跑。另外用户模拟器的质量直接决定评测可信度如果预算允许用户模拟器用强模型别在这上面省钱。如果你要接自己的 Agent 做对比把 Agent 的模型换成你正在评估的Base URL 和 Key 走统一网关Model ID 填对然后跑同一批任务。这样你得到的 pass^k 曲线才有可比性。需要管理多个模型的 key 和额度可以去控制台建不同的 key 做隔离想先手动感受一下模型在工具调用上的表现差异模型对话页面可以直接试如果是长期做 Agent 开发和回归Coding Plan 那种按周期计费的方式会比按量付费更可控。接入细节看接入文档里面有各语言的示例代码。