这篇很接近真实产品问题
很多 Agent benchmark 测的是：给模型一个完整指令和一组 API，看它能不能调用正确工具。这当然重要，但离真实业务还差很远。
真实 Agent 往往不知道全部信息，要问用户；要遵守业务 policy；要处理多轮确认；要更新数据库；最后还要给用户说清楚结果。
Tau-bench 就是围绕这个问题设计的。
它测的是什么
Tau-bench 全称是 Tool Agent User Interaction Benchmark。它构造了 Retail 和 Airline 两个领域，有数据库、API、领域 policy、用户模拟器和任务 ground truth。
一个任务不只是“调用某个函数”。Agent 要和模拟用户对话，收集缺失信息，理解规则，必要时调用工具，最后让数据库状态和目标 outcome 一致。
这个设定更像真实客服、订单、航班修改，而不是玩具 tool calling。
Reward 设计很有意思
Tau-bench 的 reward 是二元的，主要检查两个东西：
- 数据库最终状态是否和 ground truth 一致；
- 用户最终回复是否包含必要信息。
这个设计允许中间对话路径不一样，读 API 顺序也不一样。只要最终状态正确、输出信息完整，就算成功。
但论文也提醒，R = 1 不一定充分。比如 Agent 没有获得用户确认就退款，数据库状态可能对了，但流程违规。这说明真实业务的评价比状态比对更复杂。
Pass^k 很扎心
Tau-bench 里有一个指标很有意思：Pass^k。它不是代码生成里的 Pass@k。
Pass@k 是多试几次，只要有一次成功就行。Pass^k 是同一任务独立运行 k 次，必须每次都成功。这个指标更像真实产品，因为用户不会接受“多试几次总有一次对”。
实验里 k 增大后成功率下降很快。这说明很多 function calling Agent 缺的是一致性，不是偶尔能做对。
失败类型很真实
论文的失败分析里，最大一类是 wrong argument / wrong info：工具选对了，但参数错了，漏了价格、金额、用户要求等信息。
这比“不会选工具”更危险。表面上 Agent 像是在正常工作，实际上细节错了。另一些失败来自 policy 理解错误、复合请求只处理一部分、长上下文跟踪不稳。
这也解释了为什么业务 Agent 难上线。不是 demo 不能跑，而是稳定性和规则遵守达不到可托付程度。
工程启发
我觉得 Tau-bench 对产品最有用的提醒是：评测要贴近最终状态。
如果只看模型是否调用某个 API，很容易高估能力。更好的评测应该检查数据库状态、用户授权、必要回复、policy 约束、异常处理和多轮一致性。
对于真实系统，还要加入审计日志、人工确认、只读预演、幂等操作和回滚策略。工具调用只是入口，可靠执行才是重点。
小结
Tau-bench 告诉我：Agent 能不能用，不是看它能不能生成一个漂亮的 tool call，而是看它能不能在多轮用户交互中稳定完成业务结果。
这篇论文也把问题说得更朴素了：现在的 function calling Agent 还不够一致，尤其是在规则复杂、信息缺失和状态更新场景里。