Claude Code工具搜索

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

令牌成本？残酷。

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

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

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

工具搜索就是修复。

2、工具搜索实际做什么

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

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

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

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

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