工具太多怎么办:Spring AI 的 ToolSearch 与 Solon AI 的 ToolGateway 对比分析

一、为什么会有这两个东西

当一个 AI Agent 接入的工具（Tool）越来越多——本地业务函数、几十上百个 REST API、外加若干 MCP 服务端——会同时撞上两个问题：

Token 成本
。所有工具的完整定义（名称、描述、参数 JSON Schema）默认会在每次请求时全量塞进上下文。Spring AI 文档给的数字是：一个多服务端配置很容易超过 50 个工具，对话还没开始就消耗掉大量 token；其社区项目 README 进一步举例，50+ 工具可能占用 55,000+ token。
选择准确率
。当模型面对 30+ 个名字相似的工具时，选错工具的概率会明显上升。

这两个问题，正是 Anthropic 在 2025 年底提出 Tool Search Tool 模式所要解决的。它的核心思路是：不要一上来就把所有工具定义喂给模型，而是先只给一个"搜索工具"，模型需要某种能力时再去搜，命中的工具定义才动态展开进上下文。

Spring AI 与 Solon AI 都基于这个共同的范式，各自做了落地。这是理解两者"为什么像"的前提——它们解决的是同一个问题，参考的是同一个原始模式。

二、各自是什么

先把对象界定清楚，避免"拿单个类去比一整套体系"的错位。

Spring AI 侧，主体是 ToolSearchToolCallingAdvisor（社区孵化版本中也叫 ToolSearchToolCallAdvisor）。它是一个 Advisor——挂在 Spring AI 的顾问链（Recursive Advisors）上的横切组件，继承自 ToolCallingAdvisor。它来自社区项目 spring-ai-community/spring-ai-tool-search-tool（撰文时约 72 stars），同时 Spring AI 2.0 提供了官方 starter spring-ai-starter-tool-search-advisor，可通过 application.properties 一行开启。

Solon AI 侧，对应的是 ToolGatewayTalent，它是 Gateway 三件套 之一：

网关 Talent	工具来源	管理粒度
`OpenApiGatewayTalent`	远程或本地 OpenAPI/Swagger 定义	以 API 源为单位
`ToolGatewayTalent`	代码注册的 `FunctionTool`（本地工具或 MCP Tool）	以单个 Tool 为单位
`McpGatewayTalent`	MCP Client 连接的多服务端工具	以整条 MCP 连接为单位

它们都属于 Solon v4.0 的 Talent（才能） 体系，依赖包为 solon-ai-talent-gateway。

这里就出现了第一个需要澄清的"不对等"：Spring 的 ToolSearchToolCallingAdvisor 是一个通用的横切增强，工具来源它不区分（本地 @Tool、MCP 都走 Spring AI 统一的 ToolCallback 抽象）；Solon 则拆成了三个 Talent，按"接入方式 + 管理粒度"分工：OpenApiGatewayTalent 对接 OpenAPI/Swagger 文档，ToolGatewayTalent 管理代码注册的 FunctionTool（既可以是本地工具，也可以是 MCP Tool）并以单个 Tool 为单位增删，McpGatewayTalent 则以整条 MCP 连接为单位管理。

这里有个容易被忽略的细节：ToolGatewayTalent 与 McpGatewayTalent 在 MCP 工具上存在能力重叠——前者也能纳管 MCP Tool。区别在治理颗粒度：ToolGatewayTalent 管到单个工具（适合只想暴露某服务端的几个工具），McpGatewayTalent 管到整个服务端连接（适合按服务整体接入、并随连接生命周期统一增删）。

所以严格说，跟 ToolSearchToolCallingAdvisor 在"职责粒度"上最接近的，是 Solon 的 ToolGatewayTalent 这一个；但如果论"工具治理能力的总覆盖面"，要拿 Solon 的三件套整体去对。

三、最像的地方：核心机制一致

两者的运行骨架几乎可以逐条对上，这是它们"像"的实质。

1. 工具先索引、不全量下发。 Spring 在对话开始时把所有工具索引进 ToolIndex/ToolSearcher，但不发给 LLM；Solon 在进入折叠模式后同样不把原始工具直接暴露，而是收进网关内部。

2. 搜索由 LLM 主动发起，引擎负责检索。 两边都是：模型决定"要不要搜、搜什么关键词"，真正的检索算法跑在 Java 侧。Spring 的搜索工具固定叫 toolSearchTool；Solon 的对应工具叫 search_tools。模型只产出 query，命中逻辑由后端引擎执行。

3. 命中结果再展开详情。 Spring 把命中的工具定义注入下一轮请求；Solon 则通过 get_tool_detail 获取完整参数 Schema，再通过 call_tool 代理执行。

4. 都给了模型明确的引导。 这一点常被忽略，但很关键——如果不告诉模型"还有一堆隐藏工具，不够用就去搜"，模型默认不知道该搜。 - Spring 的引导分两层：一是 toolSearchTool 这个工具自身的描述；二是 Advisor 会往 system message 末尾追加一段 systemMessageSuffix，默认从 classpath 模板加载，可通过 Builder 的 .systemMessageSuffix(String) 自定义。 - Solon 的引导写在 Talent 的 Instruction 注入里，按当前所处模式动态生成清单与提示，随生命周期挂载。

可以说，到这一层为止，两者是同一套设计的两种实现。谁也没有"更聪明"，都是 Anthropic 范式的忠实落地。

四、最不像的地方：单档检索 vs 四阶段自适应

差异主要体现在"折叠的颗粒度"上。

Spring 是"全有或全搜"的二元结构。 要么走传统模式（全量下发），要么挂上 Advisor 走搜索模式（只给搜索工具）。它的官方"何时使用"建议也印证了这种取舍——20 个工具以下用传统方式，20 个以上才上 Tool Search。中间没有过渡档。

Solon 是四阶段自适应，按工具数量自动切档（ToolGatewayTalent 默认阈值）：

模式	触发条件（默认）	对 LLM 的表现
FULL（全量）	≤ 8	直接看到所有工具完整定义
SUMMARY（摘要）	8 < n ≤ 40	展示"工具名 + 描述"清单
LIST（名字）	40 < n ≤ 100	仅展示分组与工具名，需检索
SEARCH（搜索）	> 100	清单完全折叠，强制关键词检索

阈值可通过 dynamicThreshold/listThreshold/searchThreshold 调整。这个设计的出发点是：工具不多时全量最省事、模型一步到位；多到一定程度再逐级折叠。它比 Spring 多了 SUMMARY 和 LIST 两个中间档。

怎么客观看待这个差异？ 这是一组真实的取舍，不存在单方面更优：

Solon 的多档位理论上能在"中等规模工具集"（比如 30~50 个）上做更精细的 token/精度平衡——不必为几十个工具就跳到完全靠搜索。代价是配置项更多、心智模型更复杂，使用者要理解四个阶段和三个阈值。
Spring 的二元结构更简单直接，开箱即用（一行配置开启），心智负担低。代价是缺少中间过渡，要么全量要么全搜。

哪个更合适，取决于工具规模分布和团队对"可调 vs 极简"的偏好。

五、一个必须诚实说明的点：性能数据

这是中立分析里最该讲清楚的部分。

Spring 侧有公开的基准数据。其官方文档给出了 28 个工具场景下的实测对比：

模型	启用 Tool Search	未启用	节省
Gemini	2,165 tokens	5,375 tokens	60%
OpenAI	4,706 tokens	7,175 tokens	34%
Anthropic	6,273 tokens	17,342 tokens	64%

文档同时标注这是 "preliminary benchmarks（初步基准）"。

Solon 侧，我目前没有检索到官方公开的、可对比的量化基准数据。其文档描述了机制和设计意图（"平衡模型推理精度与 Token 消耗"），但没有给出类似的 token 节省百分比实测表。

所以这里不能下"谁省得更多"的结论。诚实的说法是：Spring 提供了可验证的初步数字，Solon 的量化效果有待官方或社区补充基准。任何"Solon 因为多两档所以更省 token"的推断，目前都缺乏数据支撑，只是机制层面的合理推测。

六、体系定位的差异

抛开单点机制，两者在框架中的"身份"也不同，这会影响实际选型。

ToolSearchToolCallingAdvisor 是 Spring AI 顾问链上的一个增强。它的好处是与 Spring AI 现有的 ToolCallback、MCP、ChatClient 抽象无缝衔接，是"加一个 Advisor 就生效"的非侵入增强；它的边界也清晰——它就是干工具发现这一件事，权限、生命周期等交给 Spring 生态的其他部分。

ToolGatewayTalent 是 Solon Talent 体系中的一员。Talent 在 Solon 里是比"工具发现"更大的抽象，带准入判断、生命周期钩子、指令注入等。所以 Gateway 三件套除了工具发现，还内置了一些工程化能力，比如（以同体系的 OpenApiGatewayTalent 为例）按源的 allowedTools/disallowedTools 权限过滤、响应结果截断（maxContextLength，默认 8000）、失败重试、MCP 刷新时的"影子交换"原子替换等。ToolGatewayTalent 本身则提供按 category 分组注册、call_tool 代理执行等。

这同样是取舍：Spring 的方式更符合"小而专、组合优于内置"的工程审美；Solon 的方式把更多治理能力收进同一个抽象里，开箱即得但耦合度更高。

七、给开发者的实用结论

如果你在两套生态里做选型，可以这样判断：

你在 Spring 生态：直接用 ToolSearchToolCallingAdvisor（或官方 starter）。它机制成熟、有公开 benchmark、一行开启，是当下治理工具膨胀的标准答案。工具规模在 20 个以上、或已经遇到选择准确率问题时，收益明显。
你在 Solon 生态：用 Gateway 三件套，按接入方式与管理粒度选——OpenApiGatewayTalent（对接 OpenAPI/Swagger 文档）、ToolGatewayTalent（代码注册的 FunctionTool，含本地工具与 MCP Tool，按单个 Tool 增删）、McpGatewayTalent（按整条 MCP 连接管理）。需要管到 MCP 单个工具就用前者、按服务整体接入就用后者。如果你的工具集规模处在"中等偏多"的区间，四阶段自适应能让你少做一些手动权衡；但要花点时间理解阈值配置。
两者通用的认知：搜索动作都是 LLM 主动发起的，效果高度依赖"给模型的引导文本"和"检索引擎的命中质量"。无论用哪个，把工具的 description 写清楚、给 system 引导留出定制空间，比纠结用哪个框架更影响最终表现。

八、一句话总结

像——内核机制是同一套（Anthropic Tool Search 范式：先索引、LLM 主动搜、命中再展开、配引导文本）。 不完全是一回事——Spring 是顾问链上一个简洁的二元开关式增强，有公开性能数据；Solon 是 Talent 体系里按工具来源拆分的三件套，多了 SUMMARY/LIST 两个自适应中间档和若干工程化治理能力，但量化效果尚缺公开基准。