ToolBottleneckBench 工具菜单与预算研究

ToolBottleneckBench：工具菜单、完成上限与评测偏差

作者
DeepSeekAgent.io 编辑部
发布
更新

同一个模型执行同一个任务，为什么换一套 Agent Harness 就会出现明显分差？ToolBottleneckBench 把这个问题拆成可控实验：保持任务、答案、证据规则与工具不变，只改变 Harness 向模型展示的工具菜单、工作流、返回格式和预算限制。

论文的核心结论很直接：Agent 的成功率不只衡量模型，也同时衡量运行它的 Harness。大量失败发生在 Harness 上限，而不是模型已经作出完整但错误的决策之后。如果评测只报告最终得分，不报告 Token、调用次数、Turn 和截断规则，就可能把基础设施限制误写成模型能力差异。

四种压力分别是什么

ToolBottleneckBench 为同一任务生成匹配变体，每次只改变一种压力：

  • Registered Tool Catalog（R）：系统中注册了多少工具；
  • Visible Tool Menu（V）：这一轮真正展示给模型多少工具；
  • Certified Workflow（W）：任务要求遵守的依赖与执行流程；
  • Data Encoding（D）：工具返回记录采用怎样的编码与关联格式。

主实验固定 Episode Budget、Call Limit、Turn Limit 与其他 Harness Contract，并用确定性 Grader 检查九项义务，包括工具可用性、选择、工作流、答案、证据、安全、治理、预算和完整性。失败记录同时保留“第一项未满足义务”和“最终由哪个上限终止”。

这个设计避免了一个常见误判：如果模型的第一条回复因为 Completion Cap 被截断，评测表面上可能记录成“没有选对工具”；真正终止轨迹的却是输出上限。

工具很多不是问题，全部展示才是问题

论文评估 21 组模型与 Harness 配置。在三种直接作用于模型的压力中，Visible Tool Menu 是唯一出现大幅负面影响的一项。

当可见菜单扩展到 128 个工具时，3,024 个匹配对中有 472 个从成功变为失败；其中 343 个失败变体发生了截断。这部分截断关联了 15.6 个百分点总损失中的 11.3 个百分点。

论文随后把部分截断严重配置的 Completion Cap 提高 16 倍至 16,384 Token，主要菜单损失随之消失。这个结果并不意味着“永远给更多 Token”是最佳方案，而是说明原先测到的工具菜单效应，很大一部分其实是菜单长度与输出上限共同造成的 Harness 瓶颈。

注册 2,048 个工具时，检索层决定工具是否存在

大工具目录还引入另一类失败：需要的工具根本没有进入模型可见菜单。

论文报告，当 Registered Catalog 达到 2,048 个工具时：

  • 扁平词法检索的必要工具召回率只有 19.4%；
  • Connector-First Router 达到 77.8%；
  • 24.5% 的 Discovery Episode 在第一次模型调用前就已经失败。

这时失败不能归因于模型“不会选工具”，因为正确工具从未进入模型的选择集合。评测应把 Tool Discovery、Tool Routing 和 Tool Selection 分开记录。

哪些修复真正有效

论文比较了 Prompt Repair、菜单路由与其他配置切换。结果显示，真正跨配置起效的修复改变了“哪些工具能到达模型”或“由谁发出调用”，而不是单纯要求模型更加认真。

Routed Menu 的压力增益为 4.9 个百分点，重复实验中为 7.1 个百分点；Connector-First Router 则通过提高工具可用性起效。两种 Prompt Repair 都没有产生可检出的稳定改善。

这不代表 Prompt 永远没有价值。它说明当根因是工具不可见、输出被截断或调用层失败时，继续添加文字指令并没有修复基础设施。

对 DeepSeek Harness 的直接启示

DSH 的插件化架构可以注册大量工具，但不应默认把完整工具 Schema 无差别塞进每一轮上下文。更合理的链路是：

  1. 按 Profile、任务与权限先过滤工具；
  2. 按 Connector 或能力域做第一层路由；
  3. 只向模型展示当前步骤需要的候选；
  4. 记录工具是否注册、是否召回、是否可见、是否被选择；
  5. 把 Completion、Episode、Call 和 Turn 上限一起写入轨迹。

这样才能区分四类问题：工具不存在、路由没召回、模型选错、Harness 在调用或预算处截断。

Agent Benchmark 应该怎样报告

只给一个成功率不够。一个可比较的评测至少应同时公布：

  • 模型、Provider Route 与推理设置；
  • Prompt Template 与 Tool Protocol；
  • Registered 和 Visible Tool 数量；
  • Completion、Episode、Call 与 Turn 上限；
  • 上下文裁剪、Compaction 与重试策略；
  • 每类终止原因与截断比例；
  • 工具从注册到召回、展示、选择、执行的漏斗。

这也解释了为什么不同产品的“同模型成绩”不能直接横向比较。模型只是一个组件；Harness 决定它实际看见什么、能调用什么，以及在第几步被终止。

与 DSH 长会话和动态工具的关系

DSH 长会话压缩处理历史增长，动态工具与 KV Cache处理工具定义的装载成本。ToolBottleneckBench 补上评测视角：工具菜单和预算不仅影响费用，也会系统性改变成功率与失败归因。

对于拥有插件市场的 Agent Runtime，优化目标不应是“支持最多工具”，而应是“在正确步骤稳定展示正确工具，并保留完整的预算证据”。

研究边界

论文使用合成企业任务和固定 Harness Contract，主实验只对 Completion Cap 做了 16 倍 Sweep，其他预算保持不变。结论说明特定评测压力如何与 Harness 上限共同作用，不等于所有真实任务都应使用 16,384 Token 输出上限。

参考资料

常见问题

工具越多，Agent 就一定越差吗？

不是。论文发现明显损失来自模型实际看见的菜单、检索召回和固定预算之间的组合。大目录经过可靠路由后，不必全部进入每一轮上下文。

提高 Completion Cap 就能解决问题吗？

只能解决截断主导的部分配置。工具没有召回、调用失败、错误工作流和 Episode 上限仍需要分别处理。

为什么 Prompt Repair 没有明显作用？

因为实验中的关键瓶颈位于菜单、路由和预算层。Prompt 无法让一个没有展示给模型的工具重新出现，也无法恢复已经被截断的输出。