👀 最新、最有用的AI编程姿势，总来自「知识药丸」
《贾杰的AI编程秘籍》付费合集，共10篇，现已完结。30元交个朋友，学不到真东西找我退钱；）
以及我的墨问合集《100个思维碎片》，1块钱100篇，与你探讨一些有意思的话题（文末有订阅方式
写在前面
就在刚刚，看到 Claude Code 一条推送：Tool Search now in Claude Code。
点进去一看，我人傻了。
这个困扰了我整整 4 个月的问题——MCP 工具占满 context window——居然就这么被解决了。
问题有多致命？
先说说这个问题有多恐怖。
我的 Claude Code 配了 7 个 MCP 服务器：GitHub、filesystem、sequential-thinking、brave-search、context7、puppeteer，还有一个 Google Drive。
打开会话，直接给我来了这个：
Context Usage: 67k/200k tokens (33.5%) 还没开始聊，三分之一没了。
更惨的在 GitHub issue #7336 里。有个哥们儿的配置：
- • MCP tools: 39.8k tokens
- • Custom agents: 9.7k tokens
- • System tools: 22.6k tokens
- • Memory files: 36.0k tokens
108k tokens，占了 54%。
好家伙，200k 的 context window，还没开始干活就烧掉一半。
而且这还不是最糟的。真正要命的是 tool selection accuracy 会随着工具数量暴跌——超过 50 个工具，Claude 挑错工具的概率直线上升。
想象一下，你给 Claude 提供 73 个工具，让它从里面找一个合适的。这就像让人从 73 把相似的螺丝刀里，闭着眼睛挑出最合适的那把。
能选对才怪。
Tool Search 怎么干的？
Anthropic 的解法超级简单：lazy loading（懒加载）。
工作流程是这样的：
- 1. 启动时只加载索引 - 不塞所有工具定义进 context，只加载一个 5k tokens 的「工具目录」
- 2. 需要时再搜索 - Claude 想用工具时，先搜这个目录
- 3. 按需加载 3-5 个 - 只把真正需要的工具加载进来
- 4. 自动触发 - 工具描述超过 10% context？Tool Search 自动接管
其他时候，MCP 完全不变。对开发者透明。
两种搜索方式
API 层面提供了两个变体：
Regex 版（tool_search_tool_regex_20251119）
用 Python 正则搜索：
- •
"weather"- 匹配包含 weather 的工具 - •
"get_.*_data"- 匹配get_user_data、get_weather_data - •
"database.*query|query.*database"- OR 模式
BM25 版（tool_search_tool_bm25_20251119）
自然语言搜索。Claude 把需求转成语义查询，找最相关的工具。
用法？加一行：
{ "name": "get_weather", "description": "Get current weather for a location", "defer_loading": true // 就这 }
效果
Token 消耗：
- • 之前：108k tokens（54%）
- • 现在：5k tokens（2.5%）
- • 省了 95%
准确率：
- • Opus 4：49% → 74%
- • Opus 4.5：79.5% → 88.1%
（数据来自 Anthropic 官方博客）
原本只剩 92k tokens 的场景，现在有 195k tokens 了。
你可以：
- • 聊更长的对话
- • 处理更复杂的代码
- • 加载更多文档
- • 连接更多 MCP 服务器
Claude Code 的实现
Claude Code 团队没用 Anthropic API 的内置功能，而是自己写了自定义搜索函数。
为什么？
因为 Claude Code 的场景更复杂：
- 1. 多个 MCP 服务器同时跑 - 不同服务器可能有相似工具，需要更精确匹配
- 2. Server instructions 变重要了 - 你可以在 MCP 配置里写"什么时候用这个服务器的工具"
- 3. 和 Skills 整合 - Skills 也要按需加载
最妙的是，自动触发：
When triggered, tools are loaded via search instead of preloaded
工具定义超过 10% context？Tool Search 自动接管。你什么都不用做。
给 MCP 开发者的建议
如果你在写 MCP 服务器，server instructions 现在变得超级重要了。
以前这个字段是可选的说明。现在是 Claude 决定何时搜索你的工具的关键线索。
举例：
{ "name": "database-server", "instructions": "Use this server when you need to query PostgreSQL databases, search user records, or analyze sales data." }
这样，用户说「查最近的销售数据」时，Claude 就知道该去这个服务器搜工具了。
为什么不早点做？
其实社区早就在折腾各种 workaround：
- • McPick 工具手动开关 MCP 服务器
- • 写脚本启动时选择性加载
- • 优化每个工具的描述长度
都是治标不治本。
Tool Search 是从根上解决——让 Claude 自己决定需要什么工具。
这个思路在软件工程里是经典模式：
- • VS Code 的插件按文件类型懒加载
- • JetBrains IDE 的功能按项目类型加载
- • Vim 的 lazy.nvim
现在，这个思路来到了 AI Agent 领域。
一个有意思的细节
文章里提到他们「实验了 programmatic tool calling」（编程式工具调用），最终还是先推 Tool Search。
编程式调用是让 MCP 工具通过代码互相组合，处理更复杂的工作流。
但他们发现，大部分用户更迫切需要的是「减少 context 消耗」，而不是「工具编排」。
Context window 用完了，再强的工具也白搭。
优先级抓得很准。
总结
Tool Search 解决的问题看似简单，实则致命：工具太多会把 context window 撑爆。
对普通用户：Claude Code 突然变「聪明」了——记住更多上下文，处理更复杂任务，选工具也更准了。
对开发者：可以放心接入更多 MCP 服务器，不用担心 context 爆炸。
这就是 Anthropic 的思路——不只是扩大 context window，而是让它被更高效地使用。
这才是工程。
参考资料
- • Tool Search now in Claude Code（官方公告）
- • GitHub Issue #7336: Lazy Loading for MCP Servers
- • Anthropic 官方文档：Tool search tool
- • Scott Spence: Optimising MCP Server Context Usage
P.S. 去看看你的 /context 输出。说不定你也在不知不觉中浪费了几万 tokens。
坚持创作不易，求个一键三连，谢谢你～❤️
以及「AI Coding技术交流群」，联系 ayqywx 我拉你进群，共同交流学习～
