ToolBench-X — 工具会坏时，agent 还能不能把事做完

已复核 · 稳定内容

是什么

ToolBench-X 是一个评测 tool-using agent 在不可靠工具环境下能否恢复 的 benchmark。它不满足于检查函数调用格式是否正确，而是故意让工具环境出现可恢复的坏情况，看 agent 是否能诊断、重试、fallback、验证或交叉检查。

类比：普通 tool benchmark 像在厨房里给你一套全新的刀具；ToolBench-X 像真实厨房，有的刀钝了、有的说明书变了、有的温度计读数飘了，但你仍然要把菜做熟。

论文设计了可执行的多步任务，覆盖 sequential、parallel 和 mixed workflows；每个任务都有 deterministic tools 和 canonical final answer，方便自动评测。

现有 tool-use benchmark 往往默认工具干净、稳定、可信。这个假设在真实 agent 系统里太乐观：API 会超时，schema 会变，返回值会漂，两个数据源会冲突，工具文档也可能过期。

ToolBench-X 问的是：当工具不是坏到完全不可用，而是坏到“需要恢复策略”时，agent 还能不能完成任务。

这个问题比 function calling 更接近生产环境。生产 agent 最大的风险不是不会调用工具，而是工具返回异常后继续相信旧计划，最后把错误包装成确定答案。

论文把不可靠性拆成五类结构化 hazard：

关键点是：每个注入后的 case 仍然至少存在一条 valid recovery path。这让 benchmark 不是单纯“折磨模型”，而是在测 agent 是否会恢复。

ToolBench-X 从 clean tool environments 出发，再注入可恢复 hazard。这样可以比较同一个 agent 在“工具可靠”和“工具不可靠”两种条件下的差异。

论文的结论方向也很有用：失败更多来自 hazard diagnosis 和 ineffective recovery，而不是单纯的工具调用次数或推理预算不足。也就是说，加更多 test-time scaling 不一定能解决问题，agent 需要更明确的故障识别和恢复策略。

这和 mcp-bench-2025 很互补：MCP benchmark 关心协议与工具生态，ToolBench-X 关心工具生态不稳定时的恢复能力。

任务：查一个城市今天的天气并给出穿衣建议。工具有：

get_weather(city) -> { temp_c, condition }
get_air_quality(city) -> { aqi }

ToolBench-X 式 hazard 可以这样注入：

情况	工具表现	好 agent 应该做什么
Specification Drift	`temp_c` 改名为 `temperature_celsius`	识别 schema drift，适配字段
Execution Failure	`get_weather` 第一次 timeout	重试或使用备用来源
Output Drift	AQI 返回字符串 `"good"` 而非数字	做类型校验，不直接算数
Cross-source Conflict	两个天气源温度差 15 度	交叉检查并说明不确定性

这个 toy 的重点是：正确答案不只取决于函数调用成功，还取决于 agent 是否检查工具结果是否可信。

ToolBench-X 给 tool agent 评测补了一层现实感：工具不是永远可信的外部 oracle，而是会漂移、失败和互相打架的环境。

对实际 harness 来说，这篇的启发是：工具调用层不只需要 schema，还需要错误分类、重试策略、fallback 策略、交叉验证和终态检查。