Claude Code Tool Search：从全量加载到按需发现

(Updated: )
AI
, , ,

升级到 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 可以轻松接入各种服务。但它的设计有个隐含假设：所有工具定义都要一次性加载到上下文里。

当你只有 5-10 个工具时，这没问题。但当你连接了 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-user vs notification-send-channel
  • github-create-issue vs github-create-pull-request
  • slack-post-message vs slack-send-dm

人类都要仔细看才能分清，何况 AI。

MCP 工具越多，AI 反而越”笨”。不是模型能力不行，是信息过载了。

Tool Search：从”全量加载”到”按需发现”

Claude Code 的解决方案：不要一次性加载所有工具，需要的时候再去找。延迟加载（Lazy Loading）。

工作流程

传统方式：

CNrXr2

Tool Search 方式：
QFIilX

对比一下：

  • 传统方式：约 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 的关键，是一个简单的标记：

1
2
3
4
5
6
{
  "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 这类优化的价值也就一直在。