当一台 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 做不到：它无状态，每次请求都带着完整工具清单入场，没有任何"先放一边、只看手头"的机制。
这造成了两重同时发生的税：
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 做的。
Claude Code 团队的 Thariq Shihipar 把 Tool Search 称作"被请求最多的功能之一"。落地的核心是一条自动阈值：当工具描述占用即将超过可用上下文的约 10% 时，系统停止预加载全部定义，转而对它们建一个轻量搜索索引。
实测数字很有冲击力：
工程含义：10% 是一条设计红线。如果你的工具定义 token 数 ÷ 上下文窗口 ≥ 10%，就该上动态加载；接近 40% 则是危险区。这条红线也可以反过来指导 MCP server 的拆分——单个 server 工具数最好控制在触发阈值之内。
Tool Search Tool 的架构很优雅，核心是"把工具定义从 prompt 里抽出来，放进可检索的库"：
defer_loading: true 标记那些"可延迟"的。被标记的工具初始不进入 Claude 的上下文，只有 Tool Search Tool 本身（约 500 token）和少数 defer_loading: false 的关键工具常驻。简化 API 示例（关键片段）：
{
"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 与准确率对比"作为实操项目。
最反直觉的数据是：给模型看更少的工具，它反而选得更准。Anthropic 内部在大工具库评测上测得 Opus 4 从 49% 提升到 74%，Opus 4.5 从 79.5% 提升到 88.1%。
机制可以拆成三层：
notification-send-user 和 notification-send-channel 不在同一批可见工具里时，混淆概率自然下降。动态发现天然把"语义簇相近"的工具在时间上错开。这条结论对自建工具库的人尤其重要：不要迷信"功能全 = 能力强"。一个 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 里的某个函数）。
工程取舍：
# 伪代码：职能隔离的工具路由
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：它用程序化工具调用读写上千行的电子表格，而不会把整表灌进上下文——代码在执行环境里循环，只把最终结论回传给模型。这把"工具结果过载"和"工具定义过载"一并解决了：
# 程序化：一次推理里批量处理，结果留在沙箱
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、批量化运维——这些恰恰是企业付费意愿最强的场景。
第三大特性是 Tool Use Examples——一个被低估的点。JSON schema 只能定义"结构上合法"，却表达不了"用法模式"：可选参数什么时候该带、哪些组合有意义、API 约定俗成的调用习惯。光看 schema，模型不知道一个 mode: "verbose" 默认该不该开。Examples 提供了一套通用标准来示范正确用法，本质是给工具配"few-shot"。
把这条和 EclipseSource 的设计哲学合起来看，对自建工具的人有清晰指引：
terminal 是典范——每个模型都懂终端，无需冗长描述，一个函数就能搜索、重命名、执行、检查。同理，Theia IDE 用两个函数（一个搜任务、一个执行任务）就能驱动用户自定义任务，把"延迟加载"下沉到函数设计层。get_user_data_v2 这种名字在检索里命中率极低，要换成语义明确的 slack.fetch_user_profile。变现评估：这一节是"训练营差异化"的富矿。市面上 MCP 教程多停留在"怎么连"，而"怎么设计一个对检索友好、对预算友好的工具"是稀缺内容，可做成"MCP server 设计规范 + 工具检索率测评"的高级模块。
flowchart LR
subgraph Eager["全量预加载（基线，过载税）"]
A1["所有工具定义<br/>GitHub 35 + Slack 11 + Jira..."] -->|一次性灌入| A2["Agent Context<br/>~55K–134K token"]
A2 --> A3{"每次推理<br/>都带全部 schema"}
A3 --> A4["上下文被挤占<br/>+ 选错/填错率↑"]
end
subgraph Lazy["按需发现（Tool Search）"]
B1["Tool Search Tool<br/>~500 token 常驻"] --> B2["Agent Context<br/>~8.7K token"]
B3["defer_loading:true<br/>工具库（不入初始 prompt）"] -.检索.-> B2
B2 --> B4["search 'github'"]
B4 --> B5["仅展开 3–5 个<br/>相关工具 ~3K"]
B5 --> B6["保留 95% 上下文<br/>准确率↑"]
end
A4 -. 对比 .-> B6
flowchart TD
Q{"工具总数 / 上下文占比?"} -->|"≤ ~15 个 且 <10%"| S1["全量预加载<br/>零工程成本"]
Q -->|"15–50 个"| S2["手动逐函数精选<br/>+ 子智能体职能隔离"]
Q -->|"50–135+ 个"| S3{"选减负路径"}
S3 --> S4["Tool Search Tool<br/>defer_loading 自动检索<br/>缓存友好"]
S3 --> S5["程序化工具调用<br/>代码编排免推理<br/>适合批量/大数据"]
S3 --> S6["RAG-over-tools<br/>自建 embedding 索引<br/>适合跨框架"]
S4 --> N1["命名/描述需可检索"]
S5 --> N2["依赖可靠沙箱"]
S6 --> N3["检索即新失败点"]
defer_loading:true 标记全部非关键工具，保留 defer_loading:false 的不超过 3–5 个。叠加程序化工具调用处理批量数据（Excel/ETL/报表）。一句话收束：工具能力的天花板，越来越不在"会不会调"，而在"敢不敢让它只看见该看见的"。 把上下文预算当成第一公民，让工具按需出场，是 2026 年 Agent 工程从"能用"走向"能扛规模"的分水岭。
[!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 等场景全覆盖。