一句话定义：工具定义税（tool definition tax）指在使用支持工具调用的大模型 API 时，每次请求都要把全部工具的说明书——工具名、用途描述、参数结构（tool schema）——重新发送一遍，这部分 token 与用户当下问的问题无关，却必须付出，并且随工具数量大致线性增长。
为什么会这样：单次 API 调用是无状态的，服务端不记得上一轮你发过什么。所以每一轮对话，客户端都要把系统提示、历史消息、工具定义一起打包送上去，模型才知道“我手里有哪些工具、怎么调用”。这笔开销记在输入 token 里，跟你的问题长短无关。
打个比方：你每次打电话问物业一句“三号楼的电梯修好没”，都得先把整个小区所有楼栋、所有设施、所有报修流程的手册完整念一遍，念完才允许提问。问的话十个字，念手册三分钟。挂的工具越多，手册越厚，这“三分钟”就越长，而且每一轮都要重念。
一个带若干参数、还写了详细说明的工具，schema 占掉几百个 token 并不稀奇；挂上二三十个工具，固定开销就相当可观了。
和相邻概念的区别：
| 概念 | 计量方式 | 能否减少 |
|---|---|---|
| 工具定义税 | 每轮按输入 token 计，与问题长短无关 | 精简 schema、减少工具数、按需暴露 |
| 对话历史膨胀 | 每轮重发，随轮次累积增长 | 摘要、截断、滑动窗口 |
| prompt 缓存 | 重复前缀可能按更低的单价或更快的速度处理，具体规则以各家官方页面为准 | 保持前缀稳定，别每轮改工具顺序 |
| 工具检索（tool retrieval） | 先选出一小批候选工具，再暴露给模型 | 多发一次筛选，少发一大坨 schema |
要点是：缓存能让你少花钱、少等待，但“发送”这个动作还在；而工具检索是真正减少暴露面。两者不冲突。
对实际工作意味着什么：
- 做加法容易，做减法难。把内部几十个接口一股脑挂上去，看起来能力很强，实际每轮都在为从不调用的工具付费，还可能干扰模型选择。
- 描述要写“什么时候该用我”，而不是写成一篇产品文档；参数里的枚举值不要无限铺开。
- 分层暴露：先给少量粗粒度工具，选定方向后再加载细分 schema；或者按场景（客服、报表、运维）拆分工具集。
- 注意缓存前缀的稳定性：工具列表顺序、描述措辞每轮抖动，缓存就难以命中。
- 短对话场景受影响最大：用户只问一句，固定开销却照付，占比很难看。
一个粗略的自查方法：把全部 schema 拼起来估一下 token 量，把它当成每轮必付的“底噪成本”，再和你的真实业务收益比一比。很多时候，砍掉一半工具，效果反而更稳。