粒度是工具设计的核心抉择：粗到足够安全，细到足够灵活。
每个工具都落在一条谱系上的某处——从一个无所不包的胖调用，到一百个原子原语；你把它放在哪里，决定了智能体推理得多好、一项任务要花多少个来回、每次调用能出多大的错，以及你的工具列表会膨胀得多严重。本文讲的是有意识地选择粒度：何时把多步收拢到一次调用背后、何时把一个工具拆开，以及如何识别那个正在 2025–2026 生态中悄悄拖垮智能体的工具爆炸故障。
粗工具与细工具朝相反的方向失败。
一个粗工具——一次调用就找到订单、退款、并通知客户——模型容易正确调用、来回成本低，但它隐藏了智能体可能需要做的决策，无法为你没预料到的情形重新组合，并且把爆炸半径集中了起来（一次错误调用做了三件事）。一个细工具——查找、退款、通知各自分开——灵活、可重组，但来回数翻倍、模型可能失步的地方翻倍、工具数膨胀。两者都不是「正确」的；问题永远是：对这项能力而言，哪种失败模式你最承受不起。
当多步是一份不可分割、模型不该编排的工作时，就合并。
如果模型在步骤 A 和步骤 B 之间没有任何有意义的决策可做——它总是会在 A 之后做 B，而做了 A 不做 B 就是个 bug——那么把它们分开暴露只会制造一种失败方式。把它们收拢。判据是决策性的，而非技术性的：不是「它们在数据库里是不是一个事务」，而是「智能体是否曾正当地想只做其一而不做其二?」退款后通知是一个工具，因为没人被告知的退款从来不是目标。先搜后读是两个工具，因为智能体确实会搜索、推理，再只读其中部分结果。
# No decision between the steps -> one coarse tool refund_order(order_id, reason) # find + refund + notify, atomic # Real decision between the steps -> keep them split search_issues(query) -> [ids] # model reasons over results... get_issue(id) # ...then reads only the ones it chose
当一个工具被模式或无界输出压垮时，就拆分。
相反的动作。一个根据 mode 或 action 参数做着微妙不同之事的工具，是两个工具披着一件外套：模型得先选工具、再选模式，把可能出错的地方翻倍，而模式也变成一个一半字段只在特定条件下相关的联合体。拆开它。同理，一个输出无界的单一工具——「返回这个客户的一切」——应当拆成一个便宜的发现调用和一个有针对性的取数调用，让模型只为它读的东西付费。
如果一个工具的描述里出现「或」来说明它做什么——「创建或更新」「搜索或取数」——这个「或」通常就是两个工具被焊在一起的接缝。沿着这个「或」拆分，几乎总能提高工具选择的准确率。
可组合性是你设计出来的属性，不是白送的。
细工具只有在智能体真能把它们串起来时才有价值，而串联只有在一个工具的输出被塑造成下一个工具的输入时才行得通。一个返回取数工具不接受的晦涩内部 ID 的搜索，就是两个无法组合的工具——模型只好凭空发明一个转换步骤，并且会做错。为可组合性设计，意味着在一个工具家族内就共享的标识符与形状达成一致，好让智能体能把它们接起来——正如 Unix 管道之所以能用，是因为每个工具都说着以行为单位的文本。
工具爆炸是一个可度量、遍及生态的故障。
过了某个点，工具更多并不等于能力更强——而是上下文膨胀与更差的选择。2025–2026 的数字很直白：一套标准 MCP 栈（Playwright + GitHub + 一个 IDE 服务器）能在智能体开始前就吃掉 20% 以上的上下文窗口；而正确工具选择的准确率，已被测出从聚焦工具集的约 95% 跌到加载完整 GitHub MCP 服务器后的约 71%——约 24 个百分点的损失，纯粹由工具数量造成。GitHub Copilot 把工具集从 40 个砍到 13 个、Block 把 Linear 工具从 30 多个减到 2 个，两者都带来了基准提升。Anthropic 在 2025 年末推出延迟工具加载，正是为了让智能体不再为它没用的工具付费。
你每加一个工具，都会对智能体此后的每一次调用征税，无论它是否用到那个工具，因为描述就摆在上下文里、参与选择竞争。边际工具很少是免费的；把工具列表当成预算，而不是自助餐。
何时细粒度值得它的代价。
对多数智能体而言，默认偏粗是对的偏向，但当智能体的价值本身就是开放式组合时它就错了——一个编码或数据分析智能体恰恰需要原始的读/写/运行工具，因为任务无法预料，而合并会把它们截肢。当你知道工作流时就合并；当工作流正是智能体该去发明的东西时就保留原语——并且绝不要仅仅因为每个原语看起来都很便宜，就让原语数量无界增长。