Claude Code工具搜索

有一种特定的痛苦，只有在你建造了过于强大的东西后才会感受到。

一切都工作正常。 工具很坚固。 代理很聪明。

然而……每个提示都感觉比应该的重。响应变慢。上下文填满。你开始像打包行李时有严格的重量限制一样修剪工具描述。

如果你用 MCP 服务器使用过 Claude Code，你知道这种感觉。

说实话，也许你一直生活在其中。

因为 MCP 很棒。它给了我们一个真正的协议。一个干净的方式来暴露工具。一条通往真正代理而不是玩具演示的道路。

但成功创造了一个新问题。

太多工具。太多上下文。太多噪音。

现在 Claude 终于正确地解决了它。

工具搜索在 Claude Code 中上线。这是一个听起来很小但悄悄重写大型代理系统构建方式的变化。

1、问题不是工具。而是一次加载所有工具

关键是：人们没有大声说出足够多。

MCP 没有失败是因为它复杂。 它挣扎是因为一切都是急切加载的。

每个工具。 每个描述。 每个参数模式。

都提前转储到上下文窗口中。

上下文很昂贵。不仅仅是令牌，还在于注意力。

一旦超过大约 30-50 个工具，事情就开始退化。工具选择准确性下降。模型犹豫。它猜测。有时它只是因为一切看起来都模糊相关而选择了错误的东西。

令牌成本？残酷。

人们报告设置有 7+ MCP 服务器在实际任务开始前就消耗了67k 令牌。

这不是边缘情况。这是系统增长时发生的情况。

我们需要延迟加载。真正的延迟加载。不是提示技巧。

工具搜索就是修复。

2、工具搜索实际做什么

从高水平来看，工具搜索翻转了默认行为。

Claude 不将每个工具定义加载到上下文中，而是这样做：

1. 从几乎什么都没有开始
2. 只有在需要时才搜索工具
3. 只加载相关的
4. 其他一切都保持在外面

Claude Code 现在检测您的 MCP 工具何时会消耗超过10% 的上下文窗口。当这种情况发生时，它停止预加载工具并切换到基于搜索的发现。

相同的工具。相同的 MCP 服务器。不同的加载策略。

最好的部分是，一旦发现，工具的行为与正常工具完全相同。您的提示中没有特殊情况。没有新的心理模型。

您不需要重写您的代理。您只是停止浪费上下文。

3、为什么这比您想象的更重要

让我直说。

想象走进一个有 500 个工具挂在墙上的车间。

每个锤子。每个扳手。每个六个月前只用过一次的模糊东西。

现在想象走进一个干净的空间，有一个目录。您询问您需要什么，然后它被递给您。

相同的功能。非常不同的体验。

这就是工具搜索修复的。

两个大问题几乎瞬间消失：

3.1 上下文效率

工具定义很大。令人震惊地大。

粗略计算：

• 50 个工具 ≈ 10-20k 令牌
• 200 个工具 ≈ "为什么我的模型困惑了？"

使用工具搜索，这些令牌在需要前根本不存在。

更多推理空间。 更多对话空间。 更少修剪。更少妥协。

3.2 工具选择准确性

这是一个微妙但关键的问题。

模型不随工具数量线性扩展。在某个点之后，它们在选择上变得更差。一切都模糊在一起。

通过将可见工具集缩小到一次 3-5 个相关工具，Claude 保持敏锐。

更少选择。更好决策。

4、工具搜索底层如何工作

有两种类型的工具搜索。

4.1 基于正则表达式的搜索

这个非常字面。

Claude 生成一个Python 正则表达式模式并搜索工具名称、描述和参数。

示例：

• "weather"
• "get_.*_data"
• "database.*query|query.*database"
• "(?i)slack" 用于不区分大小写匹配

4.2 基于 BM25 的搜索

这个使用自然语言查询。

Claude 用简单英语询问它想要什么，系统使用 BM25 对工具进行排名。

当以下情况时，这工作得更好：

• 工具名称混乱
• 描述冗长
• 您想要没有嵌入的语义匹配

两种方法都返回3-5 个工具引用，然后自动扩展为完整的工具定义。

Claude 从未看到整个目录。只有它询问的内容。

5、延迟加载：改变一切的单个标志

这个功能中最重要的行是：

"defer_loading": true

就是这样。就是开关。

标记这个的任何工具：

• 最初不加载到上下文中
• 只能通过工具搜索出现
• 在发现前不会花费您任何令牌

没有这个标志的工具与之前完全一样。

Claude 推荐的设计模式是：

保持您的3-5 个最常用工具非延迟。 延迟其他一切。

这种平衡保持事情快速和灵活。

6、示例

让我们看看最简单的设置。

您想要天气数据。您还有一个文件搜索工具。您不希望在需要前加载任何一个。

这是它的样子。

您包含工具搜索工具：

{
  "type": "tool_search_tool_regex_20251119",
  "name": "tool_search_tool_regex"
}

然后您的实际工具，都延迟：

{
  "name": "get_weather",
  "description": "Get the weather at a specific location",
  "input_schema": {
    "type": "object",
    "properties": {
      "location": {"type": "string"},
      "unit": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"]
      }
    },
    "required": ["location"]
  },
  "defer_loading": true
}

Claude 从只有搜索工具可见开始。

当用户询问天气时，Claude 搜索 "weather"，发现 get_weather，加载它并调用它。

没有浪费上下文。没有猜测。

7、响应实际看起来像什么

如果您正在围绕 API 构建系统，这一部分很重要。

当工具搜索运行时，您将在响应中看到新的块类型：

• server_tool_use —— Claude 调用搜索
• tool_search_tool_result —— 发现的工具
• tool_reference —— 指向延迟工具的指针
• tool_use —— 实际调用

重要细节：

您不要自己扩展工具引用。

API 自动这样做，只要工具定义存在于您的 tools 列表中，并带有 defer_loading: true。

这是一个干净的抽象。说实话，一个罕见的抽象。

8、MCP + 工具搜索

如果您使用 MCP 服务器，这才是真正的升级。

您现在可以：

• 附加多个 MCP 服务器
• 默认延迟所有工具
• 覆盖一些热路径工具以始终加载

示例思维：

• 数据库服务器：延迟一切
• 搜索或 "list events" 工具：始终加载
• 其他一切：按需发现

是的，这可以跨数百或数千个工具工作。

这不是理论性的。系统限制是10,000 个工具。

在这个规模上，急切加载永远不会工作。

9、程序化工具组合没有入选

Claude 的团队实验了更大的东西：程序化组合 MCP 工具。工具调用工具。以代码编写的代理管道。

那很激动人心。但他们还没有发布。

为什么？

因为这个问题更紧急。

减少上下文使用并不光鲜。但它是基础性的。没有修复这个，更高级的代理组合只会因自身的重量而崩溃。

说实话，我认为他们做出了正确的决定。

10、自定义工具搜索：当内置不足时

这里有一个容易错过的细节。

您没有锁定在 Claude 的搜索逻辑中。

您可以实现您自己的工具搜索，使用：

• 嵌入
• 向量数据库
• 特定领域启发

只要您的自定义工具返回 tool_reference 块，Claude 会接受它们。

这意味着：

• 语义搜索
• 混合排名
• 企业目录
• 无论您想要什么

Claude 不关心您如何找到工具。只有它存在并且是延迟的。

这是一个强大的逃生舱口。

11、人们会犯的常见错误

一些需要注意的事情。

延迟一切至少一个工具必须是非延迟的。通常是搜索工具本身。

模糊的工具描述搜索只有在描述有意义时才工作。"做东西" 不行。

太多始终加载的工具如果一切都是"经常使用"，那么什么都不是。无情。

期望示例工作工具搜索不支持工具使用示例。如果您需要那些，请使用标准调用。

12、何时不应该使用工具搜索

这不是强制性的。

如果您有：

• 少于 10 个工具
• 所有工具在每个请求中使用
• 微小模式

那么急切加载很好。甚至更简单。

工具搜索是为成长的系统设计的。大多数真实系统都会。

这不仅仅是一个 Claude 功能。

这是一个信号。

我们正在从"将一切转储到上下文中并希望最好"转向结构化发现。

代理不需要看到一切。它们需要在正确的时间看到正确的东西。

工具搜索使这成为可能。

如果您曾经盯着一个臃肿的提示，一行一行地修剪工具描述，想知道这如何成为您的生活……是的。这一个是为您准备的。

如果您正在构建 MCP 服务器，请正确使用 server instructions。如果您正在设计工具目录，请编写对搜索重要的描述。因为现在，它确实重要。

原文链接：Tool Search now in Claude Code

汇智网翻译整理，转载请标明出处