SpringAi工具搜索工具

智能工具选择：利用 Spring AI 的动态工具发现功能节省 34-64% 的 Token 开销

背景

随着 AI Agent 连接的服务越来越多——Slack、GitHub、Jira、MCP 服务器——工具库也在迅速膨胀。一个典型的多服务器配置往往包含 50 多个工具，在对话开始前就可能消耗 55,000 多个 Token。更糟糕的是，当模型面对 30 多个命名相似的工具时，工具选择的准确率会显著下降。

由 Anthropic 首创的 工具搜索工具（Tool Search Tool） 模式解决了这个问题：模型不再一次性加载所有工具定义，而是按需发现工具。最初，它只接收一个搜索工具，在需要时查询相关能力，然后将相关的工具定义扩展到上下文中。这种方法在保持对数百个工具访问能力的同时，实现了 显著的 Token 节省。

关键洞察： 虽然 Anthropic 是为 Claude 引入了这种模式，但我们可以利用 Spring AI 的 递归增强器（Recursive Advisors） 为 任何 LLM 实现相同的方法。Spring AI 提供了一个可移植的抽象层，使得动态工具发现功能可以在 OpenAI、Anthropic、Gemini、Ollama、Azure OpenAI 以及任何 Spring AI 支持的 LLM 提供商上运行。

介绍

首先让我们去了解工具是怎么去调用的？

ToolCallAdvisor 是一个特殊的递归增强器，它会：

  1. 在请求到达 LLM 之前 拦截 ChatClient 请求。
  2. 在发送给模型的 Prompt 中 包含工具定义 —— 针对所有已注册的工具！
  3. 检测 模型响应中的工具调用请求。
  4. 使用 ToolCallingManager 执行被请求的工具。
  5. 带着工具执行结果 循环回传，直到模型给出最终答案。

工具执行发生在一个 递归循环 中——Advisor 会持续调用 LLM，直到不再有工具调用请求为止。

那么这样就很容易出现问题！因为我们是会一次性将tool的返回交给大模型，比如：

  1. 上下文膨胀（Context bloat） —— 在对话开始前就消耗了海量的 Token。
  2. 工具混淆（Tool confusion） —— 面对 30 多个相似工具时，模型难以做出正确选择。
  3. 更高的成本（Higher costs） —— 每次请求都要为未使用的工具定义付费。

所以就出现了我们的工具搜索工具

通过扩展 Spring AI 的 ToolCallAdvisor，我们创建了 ToolSearchToolCallAdvisor 来实现动态工具发现。它拦截工具调用循环，根据模型发现的需求选择性地注入工具。

流程如下：

  1. 索引（Indexing）：对话开始时，所有注册的工具都在 ToolSearcher 中建立索引（但不会发送给 LLM）。
  2. 初始请求（Initial Request）：只有 Tool Search Tool (TST) 的定义被发送给 LLM —— 节省上下文。
  3. 发现调用（Discovery Call）：当 LLM 需要某些能力时，它会调用 TST 进行搜索查询。
  4. 搜索与扩展（Search & Expand）：ToolSearcher 找到匹配的工具（例如 “Tool XYZ”），并将其定义添加到下一次请求中。
  5. 工具调用（Tool Invocation）：LLM 现在既能看到 TST 也能看到被发现的工具定义，从而可以调用实际的工具。
  6. 工具执行（Tool Execution）：执行被发现的工具，并将结果返回给 LLM。
  7. 响应（Response）：LLM 使用工具结果生成最终答案。

这个工具的具体仓库在https://github.com/spring-ai-community/spring-ai-tool-search-tool下面

然后我们的搜索可以使用：

  • 使用 Lucene 搜索
  • 使用 VectorStore 搜索
  • 使用工具正则进行搜索

这样之后我们的效果呢？

所有模型均显著节省 Token：根据模型和搜索策略的不同，Tool Search Tool 模式实现了 34-64% 的总 Token 消耗削减。

Prompt Token 是主要驱动力：节省主要来自于 Prompt Token 的减少 —— 使用 TST 后，仅包含被发现的工具定义，而不是一开始就包含所有 28 个工具。

权衡：请求更多，Token 更少：TST 需要 4-5 次请求，而不使用 TST 需要 3-4 次，但总 Token 成本显著降低。

两种搜索策略表现相似：Lucene 和 VectorStore 产生了相当的结果，在此测试中 VectorStore 在 OpenAI 上显示出稍好的效率。

所有模型均成功完成任务：这三个模型（Gemini, OpenAI, Anthropic）都明白在调用其他工具之前需要先调用 currentTime，展示了对工具依赖关系的正确推理。

不同的工具发现策略：模型表现出不同的方法——有些设法预先请求所有必要的工具，而有些则逐个发现。然而，所有模型都在可能的情况下利用并行工具调用来优化执行。

旧模型可能会遇到困难：较旧的模型版本可能难以适应工具搜索模式，可能会遗漏所需的工具或做出次优的发现决策。建议添加自定义的 systemMessageSuffix 为模型提供额外指导，尝试不同的 tool-searcher 配置，或将此方法与 LLM 作为裁判（LLM as Judge） 模式结合使用，以确保跨不同模型的行为可靠且一致。

结论

工具搜索工具（Tool Search Tool）模式是迈向可扩展 AI Agent 的一步。通过结合 Anthropic 的创新方法和 Spring AI 的 可移植抽象，我们可以构建能够高效管理数千个工具的系统，同时在 任何 LLM 提供商 上保持高准确率。

Spring AI 递归 Advisor 架构的强大之处在于，它允许我们实现通用的复杂工具发现工作流——无论您使用的是 OpenAI 的 GPT 模型、Anthropic 的 Claude、本地 Ollama 模型，还是 Spring AI 支持的任何其他 LLM。您都能获得相同的动态工具发现优势，而无需被锁定在特定提供商的原生实现中。