一、SpringAI和SolonAI
Anthropic提出的ToolSearchTool模式旨在解决这些问题。SpringAI和SolonAI都基于此模式，
SpringAI的ToolSearchToolCallingAdvisor是一个横切组件，通过配置即可使用，而SolonAI的ToolGatewayTalent是其Gateway三件套之一，
| 网关 Talent | 工具来源 | 管理粒度 |
|---|---|---|
OpenApiGatewayTalent |
远程或本地 OpenAPI/Swagger 定义 | 以 API 源为单位 |
ToolGatewayTalent |
代码注册的 FunctionTool（本地工具或 MCP Tool） |
以单个 Tool 为单位 |
McpGatewayTalent |
MCP Client 连接的多服务端工具 | 以整条 MCP 连接为单位 |
二、核心一致
两者的运行j架构模式基本一致。
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 注入里，按当前所处模式动态生成清单与提示，随生命周期挂载。
三、差异化的单档检索 vs 四阶段自适应
Spring 是"全有或全搜"的二元结构。 传统模式（全量下发），要么挂上 Advisor 走搜索模式（只给搜索工具）。
Solon 是四阶段自适应 ，按工具数量自动切档（ToolGatewayTalent 默认阈值）：阈值可通过 dynamicThreshold/listThreshold/searchThreshold 调整。这个设计的出发点是：工具不多时全量最省事、模型一步到位；多到一定程度再逐级折叠。它比 Spring 多了 SUMMARY 和 LIST 两个中间档
| 模式 | 触发条件（默认） | 对 LLM 的表现 |
|---|---|---|
| FULL（全量） | ≤ 8 | 直接看到所有工具完整定义 |
| SUMMARY（摘要） | 8 < n ≤ 40 | 展示"工具名 + 描述"清单 |
| LIST（名字） | 40 < n ≤ 100 | 仅展示分组与工具名，需检索 |
| SEARCH（搜索） | > 100 | 清单完全折叠，强制关键词检索 |
四、场景优化选择
- Solon 的多档位理论上能在"中等规模工具集"（比如 30~50 个）上做更精细的 token/精度平衡------不必为几十个工具就跳到完全靠搜索。代价是配置项更多、心智模型更复杂，使用者要理解四个阶段和三个阈值。
- Spring 的二元结构更简单直接，开箱即用（一行配置开启），心智负担低。代价是缺少中间过渡，要么全量要么全搜。
Spring 生态 ：直接用 ToolSearchToolCallingAdvisor（或官方 starter）。它机制成熟、有公开 benchmark、一行开启，是当下治理工具膨胀的标准答案。工具规模在 20 个以上、或已经遇到选择准确率问题时，收益明显
Solon 生态 ：用 Gateway 三件套，按接入方式与管理粒度选------OpenApiGatewayTalent（对接 OpenAPI/Swagger 文档）、ToolGatewayTalent（代码注册的 FunctionTool，含本地工具与 MCP Tool，按单个 Tool 增删）、McpGatewayTalent（按整条 MCP 连接管理）。需要管到 MCP 单个工具就用前者、按服务整体接入就用后者。如果你的工具集规模处在"中等偏多"的区间，四阶段自适应能让你少做一些手动权衡；但要花点时间理解阈值配置。