工具不是越多越好：每加一个工具，模型就多一个要考虑的选项，工具定义本身还要占上下文。工具集膨胀到几十个之后，最先出现的问题不是成本，而是选错——模型会挑一个名字看起来最像的工具，然后带着错误的假设一路走下去。解法是按需加载，而不是全量铺开。
先看代价：工具集的三个隐性成本
- 选择成本：工具越多，选对的难度非线性上升，尤其在名字相近、职责重叠时。
- 上下文成本：每个工具的定义都要进提示词，二十个工具可能就吃掉几千 token，而这些 token 在多数轮次里完全是浪费。
- 权限成本：工具越多，攻击面越大。一个本轮用不到的工具只要存在，就等于多了一个可被调用的入口。
一个可量化的警戒线：当常驻工具超过 20 个，就该开始做分层；超过 50 个而没有任何按需加载机制，几乎必然出现选错和上下文浪费。 Anthropic 自己给 Claude Code 加新工具的门槛也很高，理由正是”多一个工具就多一个模型要思考的选项”。
四层方案，从轻到重
第一层：渐进式发现
不一次性把所有工具定义塞进上下文，而是先暴露一个”搜索工具”的接口，让模型按需检索、取回需要的定义，再发起调用。 MCP 客户端的最佳实践里明确推荐这一模式，它同时压低了工具定义和工具结果两部分的 token 消耗，让上下文留给推理而不是数据搬运。
第二层：技能式按需加载
把能力写成可加载的知识包：模型先看到简短的能力清单，需要时再读取详细指令，指令里还能引用更深层的文件，逐层展开。这样”加了功能”不等于”加了工具”——这是目前性价比最高的扩展方式。
第三层：子智能体隔离
某一类工具的检索和使用过程放进子智能体的上下文里，它只在自己的上下文内翻找，把最终结论交回主智能体。主上下文因此保持干净。适合文档检索、大型代码库搜索这类”过程很脏、结论很短”的任务。
第四层：代码化编排
让模型写一段代码，在一个执行过程里调用多个工具，中间结果留在代码里流转而不回流进上下文。这是压缩率最高的一层，代价是需要沙箱：网络隔离、资源上限、输出过滤，缺一不可。
怎么收敛现有的工具集
| 动作 | 判断标准 |
|---|---|
| 合并职责重叠的工具 | 两个工具名字不同但实现接近，模型经常选错 |
| 把低频工具移到按需加载 | 十次会话里用不到一次 |
| 删除从未被调用的工具 | 调用日志里出现次数为零 |
| 把多步操作合并成一个 | 模型每次都要按固定顺序连调三个工具 |
| 重命名含糊的工具 | 名字无法体现职责边界，说明里要写大段解释 |
- 导出近一个月的工具调用日志，统计每个工具的调用次数与失败率。
- 删掉零调用工具，合并失败率高且职责重叠的工具。
- 把剩余工具按使用频率分三档：常驻、按需加载、仅子智能体可用。
- 为常驻工具重写描述，确保名字能体现职责边界，边界写不清的重新拆分。
- 上线后对比两个指标：单轮平均 token 消耗、工具选错导致的重试次数。
安全底线不能让位于便利
- 跨服务端数据流：一个服务端的工具输出对另一个服务端而言是不可信输入，必须按同样的输入审查策略处理，仅做输出截断无法阻止信息外泄。
- 网络隔离：代码化执行的沙箱不应有直接网络访问，所有外部通信经宿主代理并做授权校验。
- 凭证不外露：API 密钥由宿主持有，生成的代码调用类型化函数，认证在转发时注入。
- 资源上限：设置超时和内存上限，防止失控脚本拖垮宿主。
相关阅读
工具本身的命名、参数与返回结构设计见智能体工具设计实践；把某一类工具整体下沉到子智能体的做法见子智能体拆分与上下文隔离；如果工具是通过 MCP 暴露的，资源与提示模板的按需取回方式见MCP Resources 与 Prompts 用法。
渐进式发现和直接全量暴露，差别有多大？
差别主要在上下文占用和选择准确率。全量暴露时，模型每轮都要在几十个选项里做一次判断；渐进式发现把这一步变成显式的检索动作，同时省下大量工具定义的 token 。任务越复杂，差距越明显。
技能式加载和子智能体该选哪个？
看产出形态。产出是”一段可执行的知识或规范”，用技能；产出是”一个需要多轮检索才能得到的小结论”，用子智能体。前者加载的是指令，后者隔离的是过程。
代码化编排值得引入吗？
当你发现大量 token 花在”把工具结果搬进上下文再传给下一个工具”时，就值得。它的压缩效果最显著，但必须配套沙箱：网络隔离、资源上限、输出过滤，三样缺一样就先别上。
工具调用失败变多，是工具太多导致的吗？
可能是，但要先排除其他原因：工具描述含糊、参数 schema 不清晰、错误信息没有可执行反馈。这三项修好之后如果选错率仍然高，再做分层收敛。
评论 (0)