模型对话是否每一次都有必要带上工具定义？

[pisce188]

根据我的观察，DSH的插件市场非常活跃，而装的插件越多，根据集成的功能，可使用的工具也越多，每轮对话需要带上的工具定义占用的tokens就越多。

如图所示，我这里的工具定义占用的就是7.4k的tokens，而这一部分的占用在每一次模型调用里都存在。我这轮对话让模型看下这个代码文件干了什么，任务总体输入花费27Ktokens，其中15K是两次模型调用中工具定义占用的。

而这个任务，一共有533次模型调用，单次的工具定义占用tokens是9.1K，整体这部分占用为533x9.1K约等于4850K tokens。

我想请教一下，是否可以间隔固定轮次模型调用才发送一次工具定义？或者这部分占用有没有什么能够优化的社区插件？

[goatliamia]

我觉得这个问题可能不只是「工具定义占了太多 token」，而是 Tool Surface 到底应该由谁管理。

先说一个小点：533 × 9.1K ≈ 4.85M 可以理解成累计的逻辑 prompt volume，但不一定等于 4.85M 的 cache-miss input。DSH 会区分 inputTokens 和 cacheReadTokens，而工具定义只要长期保持相同顺序和内容，前缀是有机会复用 KV cache 的。

所以如果方便的话，我觉得这个 session 最值得先看的是：

inputTokens
cacheReadTokens
outputTokens
reasoningTokens

特别是 533 次调用里，工具定义到底是在反复 cache hit，还是因为 tool set 经常变化而发生 cache miss。

不过我觉得更有意思的是你提出的「隔固定轮次才发送一次工具定义」。

我不太确定按轮次省略是不是合适，因为 native tool definition 本质上描述的是：

这一轮模型实际可以调用哪些能力

如果：

第 1 轮：有 tools
第 2～5 轮：不传 tools
第 6 轮：重新出现

这不仅是 token 优化，同时也在不断改变 Model-facing capability surface，而且可能破坏前缀稳定性。

我反而觉得这里可能缺的是一个独立的 Tool Surface / Tool Disclosure capability。

大概是：

Tool Plugins
    ↓
完整 Tool Catalog
    ↓
Tool Surface Policy
    ↓
当前 Agent / Scene 的稳定 Working Set
    ↓
Model-visible Tool Definitions

也就是说，Tool Plugin 负责：

这个能力是什么
schema 是什么
怎么执行

而另一个 Plugin 负责：

当前这个 Agent / Scene
究竟应该看到哪些能力
什么时候值得改变这个集合

这和「每 N 轮发送一次」的区别在于，它不是按时间随机省掉 schema，而是尽量得到一个：

small but stable working set

例如 coding 场景可能长期保持：

fs
shell
git
lsp

真正需要另一类能力时才发生一次 Tool Surface transition。

DSH 其实已经有一个很接近的底层 primitive：ctx.tools.restrict()，它可以让 scoped visible tools 的 presentation / lookup / execution 保持一致；社区 #524 也正在讨论基于它做 ToolSearch / progressive disclosure。

所以我感觉这里未必缺一个「减少 tool token」的小优化，可能缺的是更明确的：

谁负责管理 Agent 当前的 capability working set？

另外 progressive disclosure 本身也需要小心：如果 visible tool set 经常变化，虽然单轮 schema 变小了，但前缀 cache 可能更不稳定，所以最后应该比较的可能不是单轮 tool tokens，而是：

Tool Surface Size
× Tool Surface Stability
× Trajectory Length
× Cache Behavior

尤其你这里有 533 次模型调用，我甚至有点怀疑 533 本身可能比 9.1K 更值得分析。

可以看一下这 533 个 turn 里：

有多少是真正推进任务
有多少是 tool-result follow-up
有多少是 verification / retry / polling
以及 tool surface 实际变化了多少次

可能最后会发现这是两个问题：

1. Tool Surface 太大；
2. Agent trajectory 本身太长。

这两个问题应该由不同的 Harness capability 处理。

[XiongHaoTrigger]

这个问题在anthropic的研究中有被提到 https://www.anthropic.com/engineering/advanced-tool-use?utm_source=chatgpt.com ，这篇文档提出了，如何去解决传统 function call 浪费大量 context以及Tokens