# 工具过载税：当"多工具"成为智能体的税与病 当一台 IDE 助手接上 GitHub、Slack、Jira、Playwright、数据库再加几个 MCP server，工具定义常常在用户还没开口前就把 5 万到 13 万 token 灌进上下文。本期第 4 轮聚焦工具使用能力评测中最被低估的一个维度——**工具过载（Tool Overload）**。结论先行：工具数量超过一个阈值（约上下文的 10%、或几十个工具）后，智能体会同时遭受两重惩罚：上下文被 schema 挤占，以及"选择困难"导致的选错工具、填错参数。破局之道不是把每个工具描述写得更好（那是上一轮的主题），而是让工具**按需出场**——动态发现、延迟加载、子智能体隔离、代码编排。Anthropic 的 Tool Search Tool 把一个 50+ 工具的配置从约 72K token 压到 8.7K，Opus 4 在大工具库评测上的准确率从 49% 跳到 74%。本文用六种"减负"路线实测横评，给出不同规模的选型红线。 --- ## 一、核心发现：过载是"双面税" 大多数人谈工具使用，关注的是"调得对不对"。但 2025 年底起，工程界集体撞上的是另一个问题：**工具太多了，多到模型还没干活就被撑爆**。EclipseSource 团队在 2026 年 1 月的实测里给出一个直观比喻——一个装衣柜的工匠，理想状态下工具齐整、唾手可得；可一旦被上千件工具包围，正常人会先把不相关的全清走。LLM 做不到：它无状态，每次请求都带着完整工具清单入场，没有任何"先放一边、只看手头"的机制。 这造成了**两重同时发生的税**： - **上下文税**：每个 MCP 工具都带"做什么、接什么参数、怎么用"的完整描述。Anthropic 自己披露，5 个 server（GitHub 35 工具/26K、Slack 11/21K、Sentry 5/3K、Grafana 5/3K、Splunk 2/2K）合计 58 个工具就吃掉约 55K token，再加一个 Jira（单家约 17K）就逼近 100K。他们内部见过工具定义单独占到 134K token 的极端配置。按"工具应低于总上下文 40%"的经验线，工具独占 20% 已经危险。 - **准确率塌方税**：可见工具越多，选错和填错的概率越高。Anthropic 明确指出最常见的两类失败就是"选错工具"和"参数错误"，尤其是名称相近时——`notification-send-user` 与 `notification-send-channel` 这种孪生命名在几十个工具里几乎是必踩的坑。 关键洞察：这两重税是**相变式**的，不是线性的。工具少时几乎无感，越过阈值后陡然恶化。所以治理工具过载，本质是给智能体做"上下文预算管理 + 选择面收敛"。 --- ## 二、六栈对比：谁在原生动态加载，谁在裸奔 | 方案 / 栈 | 动态加载机制 | 隔离粒度 | 上下文节省 | 触发方式 | 上手难度 | 最适场景 | |---|---|---|---|---|---|---| | ① MCP 原生全量预加载（基线） | 无 | server 级 | 0（定义基线） | 连接即加载 | ★ | 工具≤15、单 server | | ② 手动精选 / 逐函数开关 | IDE 侧裁剪 | 函数级 | 中（30–60%） | 人工勾选 | ★★ | 已知固定工作流 | | ③ 子智能体隔离工具集 | 主智能体瘦身 | agent 级 | 中高 | 路由委派 | ★★★ | 多职能、可拆团队 | | ④ Tool Search Tool（Anthropic） | 延迟检索加载 | 工具级自动 | 高（85%） | `defer_loading:true` + 阈值 | ★★ | 50–135+ 工具、多 server | | ⑤ 程序化工具调用 | 代码内调用免推理 | 函数级 | 高（结果不入上下文） | code-execution | ★★★ | 批量、循环、大数据 | | ⑥ RAG-over-tools（自建检索） | 检索 + 路由 agent | 任意 | 高 | embedding 索引 | ★★★★ | 跨框架、自定义协议 | 注意两个反直觉点：其一，Claude Code 的子智能体**并不隔离**工具集——主 agent 装了什么，子 agent 仍共享，所谓"委派给专门 agent"在 Claude Code 里并不能真正给主 agent 减负（EclipseSource 专门提醒要核查这点）。其二，MCP 协议本身直到 2026 年仍把"工具级 lazy loading"当作 feature request（GitHub issue #7336），真正落地的延迟加载是**宿主侧**（Claude Code / API）做的，不是 MCP server 做的。 --- ## 三、阈值相变：10% 红线与 46.9% 削减 Claude Code 团队的 Thariq Shihipar 把 Tool Search 称作"被请求最多的功能之一"。落地的核心是一条**自动阈值**：当工具描述占用即将超过可用上下文的约 10% 时，系统停止预加载全部定义，转而对它们建一个轻量搜索索引。 实测数字很有冲击力： - **Anthropic 内部**：50+ MCP 工具全量加载约 72K token，开启 Tool Search 后总上下文消耗降到约 8.7K，**削减 85%，保留 95% 上下文窗口**；对比传统"全量"方案保留 122.8K，动态发现可保留 191.3K。 - **Claude Code 端实测**（Joe Njenga）：从约 51K token 降到约 8.5K，**削减 46.9%**（数字口径不同，因纳入了缓存与历史，但量级一致）。 - **极端样本**（Aakash Gupta）：单个 Docker MCP server 135 个工具独占约 125K token——这种配置不开动态发现几乎不可用。 工程含义：**10% 是一条设计红线**。如果你的工具定义 token 数 ÷ 上下文窗口 ≥ 10%，就该上动态加载；接近 40% 则是危险区。这条红线也可以反过来指导 MCP server 的拆分——单个 server 工具数最好控制在触发阈值之内。 --- ## 四、动态发现内核：defer_loading 与检索膨胀 Tool Search Tool 的架构很优雅，核心是"**把工具定义从 prompt 里抽出来，放进可检索的库**"： - 你把全部工具定义照常交给 API，但用 `defer_loading: true` 标记那些"可延迟"的。被标记的工具**初始不进入** Claude 的上下文，只有 Tool Search Tool 本身（约 500 token）和少数 `defer_loading: false` 的关键工具常驻。 - 当 Claude 需要某项能力时，它调用 Tool Search Tool 搜索（如 "github"），返回匹配工具的引用，再按需把完整定义**展开**进上下文。典型一次只加载 3–5 个相关工具（约 3K token）。 - 一个重要细节：延迟工具**完全排除在初始 prompt 之外**，因此**不破坏 prompt caching**——这是相比"动态拼接工具列表"这类朴素做法的关键优势，朴素做法每改一次工具集就击穿缓存。 简化 API 示例（关键片段）： ```json { "tools": [ { "name": "tool_search_tool", "type": "tool_search_tool", "max_results": 5 }, { "name": "github.createPullRequest", "defer_loading": true, /* 不常驻 */ "input_schema": { "...": "..." } }, { "name": "shell.exec", "defer_loading": false /* 关键工具常驻 */ } ] } ``` **优点**：token 大幅下降、缓存友好、准确率不降反升（见下一节）。**缺点**：增加一次"搜索"往返；检索质量依赖工具命名/描述的可检索性——描述写得像 `util_3` 这种的名字，搜索也召回不来，所以"工具描述工程"和"动态发现"是**互补**而非替代关系。**变现/训练营评估**：MCP 企业落地是 2026 爆发赛道，"Agent 工具架构师 / MCP 减负工程"是高价值主题，可用"同一 agent 接 10 个 server、开/关 Tool Search 做 A/B token 与准确率对比"作为实操项目。 --- ## 五、准确率反弹：49%→74% 的逆向逻辑 最反直觉的数据是：**给模型看更少的工具，它反而选得更准**。Anthropic 内部在大工具库评测上测得 Opus 4 从 49% 提升到 74%，Opus 4.5 从 79.5% 提升到 88.1%。 机制可以拆成三层： 1. **选择面收敛**：人类做多选题，选项越多越容易犹豫并出错；模型同理。把可见工具从 135 个收敛到 5 个，"在 5 个里选 1 个"远比"在 135 个里选 1 个"可靠。 2. **名称冲突消解**：当 `notification-send-user` 和 `notification-send-channel` 不在同一批可见工具里时，混淆概率自然下降。动态发现天然把"语义簇相近"的工具在时间上错开。 3. **注意力分配**：长 schema 清单会稀释注意力，模型对真正该用的工具投入的"算力"被分摊。常驻的只有少数关键工具，模型对它们的把握更稳。 这条结论对**自建工具库**的人尤其重要：不要迷信"功能全 = 能力强"。一个 agent 暴露 80 个工具，效果常常不如暴露 10 个再配一套动态检索。**变现评估**：这组数据非常适合做成"工具数量 vs 准确率"的曲线图作为课程/产品的论据——它把一个反常识的工程经验变成了可量化的卖点。 --- ## 六、子智能体隔离：主智能体的瘦身术 当工具无法用纯检索收敛（比如不同职能工具集天然泾渭分明），**子智能体隔离**是另一条主路。思路是：主 agent 保持精简，只持有调度能力；把 GitHub 操作、浏览器测试、数据分析分别交给"专门 agent"，每个子 agent 只拥有自己那块工具集。 EclipseSource 在 Theia AI 里演示了这套模式：主 agent 不携带它很少用的工具，只有负责特定步骤的子 agent 才获得对应工具。**但这里有一个大坑**：并非所有支持子 agent 的系统都真正隔离上下文。Claude Code 的子 agent **仍然共享主 agent 的工具集**——也就是说，在 Claude Code 里用子 agent 并不能给主 agent 真正减负，它更多是"分工"而非"瘦身"。Theia AI / VS Code 这类 IDE 才提供真正的隔离和**逐函数级**细粒度开关（可以单独启用/禁用一个 MCP server 里的某个函数）。 工程取舍： ```python # 伪代码：职能隔离的工具路由 def route(intent): if intent.domain == "vcs": return github_subagent # 仅持 github 工具 if intent.domain == "qa": return playwright_subagent if intent.domain == "data": return sql_subagent return main_agent # 主 agent 不持有上述任何工具集 ``` **优点**：上下文天然分离、可并行。**缺点**：路由本身是新的失败点；子 agent 之间要传递中间结果，又产生"结果消化"问题（参见往期"工具返回消化力实测"）。**适用边界**：职能清晰、工具集互不重叠时收益最大；职能混杂、工具频繁交叉调用时反而被路由开销拖累。 --- ## 七、程序化工具调用：用代码编排替代逐次推理 Anthropic 把"程序化工具调用"列为三大特性之一，解决的是另一个过载维度：**结果堆积**。自然语言工具调用每次都要一次完整推理，中间结果无论有用没用都堆进上下文；而循环、条件、数据变换这类逻辑，本来用代码表达更自然。 典型案例是 **Claude for Excel**：它用程序化工具调用读写上千行的电子表格，而不会把整表灌进上下文——代码在执行环境里循环，只把最终结论回传给模型。这把"工具结果过载"和"工具定义过载"一并解决了： - 工具在**代码执行环境**里被调用，结果**默认不进入**模型上下文； - 编排逻辑（loop/if/map）用代码写，省下大量"用自然语言让模型循环"的推理税； - 模型可以在"代码执行"和"推理调用"之间按任务灵活切换。 ```python # 程序化：一次推理里批量处理，结果留在沙箱 rows = tool.excel.read_range(sheet, "A1:Z5000") cleaned = [normalize(r) for r in rows if r.status == "active"] tool.excel.write_range(sheet, "A1", cleaned) # 不回灌全部数据到上下文 ``` **优点**：极适合批量、大数据、确定性循环；上下文几乎零膨胀。**缺点**：要求模型会写正确的编排代码、且执行环境可靠（沙箱逃逸是另一个话题，见往期"代码沙箱七栈横评"）；调试链路更长。**适用场景**：数据处理、报表、ETL、批量化运维——这些恰恰是企业付费意愿最强的场景。 --- ## 八、工具使用示例与设计哲学：Schema 之外的"用法" 第三大特性是 **Tool Use Examples**——一个被低估的点。JSON schema 只能定义"结构上合法"，却表达不了"用法模式"：可选参数什么时候该带、哪些组合有意义、API 约定俗成的调用习惯。光看 schema，模型不知道一个 `mode: "verbose"` 默认该不该开。Examples 提供了一套**通用标准**来示范正确用法，本质是给工具配"few-shot"。 把这条和 EclipseSource 的设计哲学合起来看，对**自建工具**的人有清晰指引： 1. **少而精 > 多而窄**：写 MCP server 时，少数几个设计良好的函数，往往胜过一堆窄函数。"功能覆盖广"对调用方是负担。 2. **复用模型先验**：能复用 LLM 训练数据里已有的概念就别新造。Claude Code 的 `terminal` 是典范——每个模型都懂终端，无需冗长描述，一个函数就能搜索、重命名、执行、检查。同理，Theia IDE 用**两个函数**（一个搜任务、一个执行任务）就能驱动用户自定义任务，把"延迟加载"下沉到函数设计层。 3. **把"可发现"写进函数**：命名和描述要**可检索**，因为动态发现靠的就是语义搜索。`get_user_data_v2` 这种名字在检索里命中率极低，要换成语义明确的 `slack.fetch_user_profile`。 **变现评估**：这一节是"训练营差异化"的富矿。市面上 MCP 教程多停留在"怎么连"，而"怎么设计一个对检索友好、对预算友好的工具"是稀缺内容，可做成"MCP server 设计规范 + 工具检索率测评"的高级模块。 --- ## 架构图：全量预加载 vs 按需发现 ```mermaid flowchart LR subgraph Eager["全量预加载（基线，过载税）"] A1["所有工具定义
GitHub 35 + Slack 11 + Jira..."] -->|一次性灌入| A2["Agent Context
~55K–134K token"] A2 --> A3{"每次推理
都带全部 schema"} A3 --> A4["上下文被挤占
+ 选错/填错率↑"] end subgraph Lazy["按需发现（Tool Search）"] B1["Tool Search Tool
~500 token 常驻"] --> B2["Agent Context
~8.7K token"] B3["defer_loading:true
工具库（不入初始 prompt）"] -.检索.-> B2 B2 --> B4["search 'github'"] B4 --> B5["仅展开 3–5 个
相关工具 ~3K"] B5 --> B6["保留 95% 上下文
准确率↑"] end A4 -. 对比 .-> B6 ``` ## 选型决策流：按规模挑路线 ```mermaid flowchart TD Q{"工具总数 / 上下文占比?"} -->|"≤ ~15 个 且 <10%"| S1["全量预加载
零工程成本"] Q -->|"15–50 个"| S2["手动逐函数精选
+ 子智能体职能隔离"] Q -->|"50–135+ 个"| S3{"选减负路径"} S3 --> S4["Tool Search Tool
defer_loading 自动检索
缓存友好"] S3 --> S5["程序化工具调用
代码编排免推理
适合批量/大数据"] S3 --> S6["RAG-over-tools
自建 embedding 索引
适合跨框架"] S4 --> N1["命名/描述需可检索"] S5 --> N2["依赖可靠沙箱"] S6 --> N3["检索即新失败点"] ``` --- ## 九、推荐方案：按规模与职能分档 - **个人 / 单 server（≤15 工具）**：直接全量预加载，别过度工程。把预算留给工具描述本身（见往期"工具描述工程"）。 - **中小团队（15–50 工具）**：优先**子智能体职能隔离**（Theia/VS Code 类支持真隔离的宿主），主 agent 只持有调度 + 少数高频工具。在 Claude Code 上则直接开 Tool Search，弥补它"子 agent 不隔离"的短板。 - **企业 / 多 server（50–135+）**：**Tool Search Tool 为必选项**。用 `defer_loading:true` 标记全部非关键工具，保留 `defer_loading:false` 的不超过 3–5 个。叠加**程序化工具调用**处理批量数据（Excel/ETL/报表）。 - **跨框架 / 自建协议**：自建 **RAG-over-tools**——给每个工具建 embedding，配一个轻量"工具路由 agent"，按意图召回 Top-K 工具再交给主 agent。注意检索质量本身就是新的失败面，要纳入遥测（见往期"自主智能体遥测六栈归因"）。 - **自建 MCP server 的人**：函数宁少勿多、复用模型先验、命名可检索。每个 server 工具数控制在"单家不触发 10% 阈值"以内，把"规模问题"交给宿主的动态发现，而不是塞满单个 server。 一句话收束：**工具能力的天花板，越来越不在"会不会调"，而在"敢不敢让它只看见该看见的"。** 把上下文预算当成第一公民，让工具按需出场，是 2026 年 Agent 工程从"能用"走向"能扛规模"的分水岭。 ## 参考来源 1. [Introducing advanced tool use on the Claude Developer Platform](https://www.anthropic.com/engineering/advanced-tool-use) — Anthropic 官方，Tool Search Tool / 程序化工具调用 / Tool Use Examples 三大特性，含 58 工具 55K、72K→8.7K、Opus 4 49%→74% 等关键数据 2. [MCP and Context Overload: Why More Tools Make Your AI Agent Worse](https://eclipsesource.com/blogs/2026/01/22/mcp-context-overload/) — EclipseSource，工匠比喻、20% 上下文实测、子智能体隔离与 Claude Code 共享工具集的坑 3. [How Claude Code's New MCP Tool Search Slashes Context Bloat](https://www.techbuddies.io/2026/01/18/how-claude-codes-new-mcp-tool-search-slashes-context-bloat-and-supercharges-ai-agents/) — TechBuddies，10% 阈值自动索引、7 server 67K、Docker 135 工具 125K token 4. [Claude Code Just Cut MCP Context Bloat by 46.9%](https://medium.com/@joe.njenga/claude-code-just-cut-mcp-context-bloat-by-46-9-51k-tokens-down-to-8-5k-with-new-tool-search-ddf9e905f734) — Medium，51K→8.5K 实测削减 46.9% 5. [Tool search tool — Claude API Docs](https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool) — 官方 API 文档，defer_loading 参数与检索返回格式规范 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。