升级到 Claude Code 2.1.69 后，我输入 /context 看了一眼。System tool 那一栏显示 0。
之前这个数字是 10% 左右，有时候更高。现在直接归零了。
2.1.69 版本把所有工具都改成了延迟加载（defer loading）。启动时不加载任何工具定义，需要的时候才去搜索、才去加载。
另外如果你用过 Claude Code 连接多个 MCP 服务器，应该能感受到这个变化有多大。
以前是什么样的？
如果你用过旧版本，可能遇到过这种情况：
工具越加越多，响应越来越慢。明明只是想让 AI 帮忙查个 GitHub Issue，它却在几十个工具里犹豫半天，最后还可能选错。
打开 /context 一看，系统工具的上下文占用直接飙到 10%。还没开始干活，大半个上下文窗口就被工具定义塞满了。
这不是你的问题，是 MCP 的"成功陷阱"。
MCP（Model Context Protocol）给了我们一个标准化的工具协议，让 AI Agent 可以轻松接入各种服务。但它的设计有个隐含假设：所有工具定义都要一次性加载到上下文里。
当你只有几个工具时，这没问题。但当你连接了 GitHub、Slack、Jira、Google Drive、Sentry、Grafana……工具数量突破 50 个时，问题就来了。
2.1.69 改变了什么？
Claude Code 2.1.69 引入了 Tool Search 功能，思路很简单：所有工具默认不加载，需要的时候再去找。
最明显的变化有两个：
系统工具上下文占用降为 0（以前启动就占用 10% 上下文）。工具选择准确率也提升了，因为 Claude 不需要在几十个工具里犹豫。
而且你什么都不用做，装上最新版就自动生效。
问题的根源：工具定义比你想象的更"重"
MCP 工具为什么会吃掉这么多上下文？看一个典型的 3 服务器配置：
• GitHub：35 个工具，约 26K tokens • Context7：2 个工具，约 3K tokens • Exa：2 个工具（默认启用），约 2K tokens
总计：39 个工具，约 31K tokens。
这还只是 3 个服务器。如果再加上 Slack（11 个工具，21K tokens）、Jira（17K tokens）、Linear……很容易就突破 100K tokens。
Anthropic 团队在内部测试中，见过工具定义消耗 134K tokens 的极端案例。对话开始前，上下文窗口已经被工具定义占据了大半。
但 token 消耗只是表面问题。更严重的是：工具越多，AI 越容易选错。
当 Claude 面对 50+ 个工具时，很多工具的名字和描述都很相似：
• notification-send-uservsnotification-send-channel• github-create-issuevsgithub-create-pull-request• slack-post-messagevsslack-send-dm
人类都要仔细看才能分清，何况 AI。
MCP 工具越多，AI 反而越"笨"。不是模型能力不行，是信息过载了。
Tool Search：从"全量加载"到"按需发现"
Claude Code 的解决方案：不要一次性加载所有工具，需要的时候再去找。延迟加载（Lazy Loading）。
工作流程
传统方式：
对比一下：
• 传统方式：约 77K tokens（工具定义 72K + 系统提示 5K） • Tool Search：约 8.7K tokens（搜索工具 0.5K + 发现的工具 3K + 系统提示 5K）
节省了 95% 的上下文空间。
两种搜索方式
Tool Search 提供了两种搜索策略：
1. Regex 搜索
Claude 生成一个 Python 正则表达式，匹配工具名称、描述和参数。
示例：
• "weather"- 查找天气相关工具• "get_.*_data"- 查找所有 get 开头、data 结尾的工具• "(?i)slack"- 不区分大小写查找 Slack 工具
适合工具命名规范、描述清晰的场景。
2. BM25 搜索
Claude 用自然语言描述需求，系统用 BM25 算法排序匹配。
示例：
• "send a message to a user" • "create a pull request on GitHub" • "search customer orders by date"
适合工具命名不规范、描述较长的场景。
两种方式都会返回 3-5 个最相关的工具，然后自动展开成完整定义。Claude 看到的，只是这几个工具，而不是全部 50+ 个。
defer_loading：一个标记改变一切
实现 Tool Search 的关键，是一个简单的标记：
{
"name": "github-create-pr",
"description": "Create a pull request on GitHub",
"input_schema": {...},
"defer_loading": true
}加上 defer_loading: true，这个工具就不会在启动时加载，只能通过搜索发现。
Claude 推荐的最佳实践：
• 保留 3-5 个最常用的工具，设置 defer_loading: false（或不设置）• 其他所有工具，设置 defer_loading: true
这样既保证了高频操作的响应速度，又避免了上下文浪费。
如何使用？你可能已经在用了
如果你用的是 Claude Code 2.1.69 或更高版本，Tool Search 已经自动启用了。
Claude Code 会检测你的 MCP 工具是否超过上下文窗口的 10%。如果超过，自动切换到 Tool Search 模式。
你不需要修改任何配置，不需要改任何代码。升级，就行了。
总结
Anthropic 的工程实践发现，在很多实际任务中，1M 上下文窗口的表现不如 200K。上下文窗口大小不是关键，资源管理的精准度才是。Tool Search 就是这个思路的实践。
有人说 Skills 可以完全替代 MCP，从技术角度看确实有一定道理。但现实是，主流厂商提供的集成，基本都是以 MCP server 的形式交付的，所以 MCP 的工具膨胀问题，短期内不会消失，Tool Search 这类优化的价值也就一直在。
