摘要
一、为什么会有这两个东西 当一个 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 三件套 之一：…
摘要可能不完整，可查看原文