回光返照还是重生？Claude 给 MCP 打补丁：Tool Search 到底解决了什么，以及它没解决的
Claude 官方把“Tool Search”推入 Claude Code，号称为 MCP 的上下文与 Token 地狱“止血”。从社区实测到官方数据，这个补丁的确让大型工具集的使用更轻更稳。但别急着庆祝：它既不是银弹，也不是“MCP 瞬间翻身”的信号。
一、问题的病灶：上下文挤爆 + 智商打折
-
旧模式是“预加载”：无论是否需要，先把一大堆工具定义塞进上下文。几十到上百个工具的描述让 Token 飙升，甚至还会拖慢模型的思考“带宽”。
-
社区与官方一致反馈：工具定义一多，准确率显著下滑；30–50 个工具是个分水岭，再多就开始明显“变笨”。
二、补丁的思路：把“记住一切”改成“按需索引”
-
Tool Search 的核心就是“延迟加载”：仅把工具名 + 简要说明进入索引，真正调用前再拉取完整定义。
-
流程更像“渐进式披露”：模型先识别意图（比如查天气），再用搜索工具找匹配的 tool，之后只加载那一个的定义并调用。
三、官方收益与社区实测
-
官方宣称：在 50+ 工具的复杂环境中，Token 消耗可降约 85%，复杂任务准确率从 49% 跳到 74%。
-
开发者实测：把环境变量打开后，项目启动即占用的上下文从 ~223k 直接降到 ~69k；“一行设置”带来显著缓解。
-
Claude Code 的“自动门槛”：当工具定义占用超过 10% 上下文时，系统会自动启用 Tool Search；Agent 自研时可用 defer_loading 标记。
四、怎么用：两条路径
- 在 Claude Code：在 ~/.claude/settings.json 中增加
{
“env”: {
“ENABLE_TOOL_SEARCH”: “true”
}
} 重启即可。超过阈值会自动触发。- 在自定义 Agent：将需要延迟的工具加上 defer_loading: true，并引入搜索工具（tool_search_tool_regex_20251119 等），由搜索返回匹配列表后再加载完整定义。
五、外网舆情与开发者声音：好用，但不完美
-
“降本增效是对的，但它只是把问题挪了个位置。”有人认为 Tool Search更多是在容错“工具管理不善”的场景，让系统不至于崩。
-
“命名长度坑”：部分实现会在工具名前加 select: 前缀，导致超过 64 字符的工具名直接报错。
-
“MCP vs Skills/Plugins”：不少人已经转向 Skills/Plugins，认为这一类路由问题在技能体系里已更自然地解决。
-
“规模化检验”：有人塞了 4,027 个工具做压力测评，命中率约 60%。这凸显了“大型工具目录的语义检索”在精度与召回之间的权衡，提示需要分层/嵌入/层次意图路由等更系统的设计。
-
“并非处处灵药”：也有人反馈，与其堆 MCP，不如让 LLM 直接调用少量关键工具；在实际项目里，工具策略与编排逻辑的重要性胜过“多即是好”。
六、我们该怎么落地？
-
先做“工具瘦身”：把高频、核心的工具稳定好；低频工具才交给搜索 + 延迟加载。
-
做“意图分层”：用父子工具（DoGithubOperation -> 子操作）或技能层次，缩短检索路径，降低干扰。
-
设“路由护栏”：给工具写清晰、短描述与稳定命名；避免过长的工具名与歧义动词。
-
观察与回滚：在大型工程中持续对 Token 开销与准确率做 A/B 比较；必要时局部关闭 Tool Search 保持关键链路的确定性。
-
和技能并行：把 MCP 当作“标准化的工具协议”，在应用层拥抱 Skills/Plugins 的组合拳，减少“全局上下文挤压”。
七、结论：MCP 的接口价值在，应用层在变
Tool Search 是一次务实的“止血”，有效解决了“预加载带来的上下文拥堵”，在复杂项目里很有价值。但它不是万能路由，更不意味着 MCP 作为应用层“万用胶”的时代回来了。未来更像是：MCP 继续作为模型与工具的标准化接口，而应用层逐渐由技能化/插件化的编排来主导，搜索与分层路由只是工具箱里的一个模块。
附：快速启用清单
-
打开 ENABLE_TOOL_SEARCH（Claude Code）
-
给冗长工具 defer_loading: true（自研 Agent）
-
统一工具命名规范，避免超长
-
为工具写“短而准”的描述，提升检索质量
原文地址
https://www.anthropic.com/engineering/advanced-tool-use