大语言模型之动态工具发现：Anthropic Tool Search Tool 架构、设计与生态系统整合

综合技术综述 · 2026年6月

摘要

大语言模型智能体生态系统之迅猛扩张，催生了一项根本性之扩展挑战：当智能体得以访问数十个模型上下文协议服务器上之数百乃至数千工具时，将所有工具定义载入上下文窗口之令牌成本已不堪重负，且模型准确选择正确工具之能力亦显著退化。本文对 Anthropic 于 2025 年 11 月推出之 Tool Search Tool（TST）作深入技术综述，从根本上重塑了大语言模型与工具生态系统之交互方式。TST 采用延迟加载与双模态搜索相结合之策略，仅加载当前任务所需之工具。本文提供与 OpenAI Function Calling、传统全量加载、编程式工具执行及多智能体方案之全面对比分析。分析表明，TST 可实现 85% 以上之令牌削减，保留约 95% 之上下文窗口，并将 Opus 4 之工具选择准确率自 49% 提升至 74%。

CCS 概念： 计算方法论 → 人工智能；软件及其工程 → 软件组织与属性；信息系统 → 信息检索。

关键词： 工具搜索，大语言模型，MCP，上下文工程，延迟加载，智能体架构，函数调用，Anthropic Claude，OpenAI

引言

大语言模型自文本补全引擎演进为自主智能体，乃人工智能领域最为重大之范式转移之一。现代 AI 智能体须与日益膨胀之外部系统阵列交互：查询数据库、管理文件系统、发送消息、更新客户关系记录、搜索网络、执行代码。此能力之实现，端赖工具使用——大语言模型基于自然语言指令选择并调用外部函数之能力。 模型上下文协议（Model Context Protocol，简称 MCP），由 Anthropic 于 2024 年 11 月推出，已成为连接 AI 智能体与外部工具及数据源之事实标准 [mcp_spec]。MCP 以通用开放协议消除每对智能体—工具之间定制集成之需求，其采纳速度之快令人瞩目：社区已构建数千 MCP 服务器，各主流编程语言皆有 SDK 可用，主要平台亦已集成 MCP 支持 [code_exec_mcp]。 然则，此番成功催生一根本性扩展悖论：智能体因接入更多工具而愈加强大，却因工具过多而愈难有效使用之。此悖论通过三种相互关联之机制显现： Anthropic Tool Search Tool（以下简称 TST），作为 2025 年 11 月高级工具使用能力集之一部分推出，通过动态工具发现机制直面上述挑战。TST 从根本上重塑大语言模型与其工具生态系统之关系：非预先加载所有可用工具，模型通过搜索按需发现工具，仅加载当前任务所需者。此"即时"上下文管理方式，代表智能体 AI 中一种新颖之架构模式。 本文对 Tool Search Tool 作深入技术综述，考察其架构、设计原理、搜索机制、性能特性及生态系统整合。本文之贡献如下： 本文余下部分组织如下。第 §sec:bg 节提供工具泛滥问题、上下文工程原理及 MCP 生态系统之背景。第 §sec:problem 节量化分析扩展危机。第 §sec:comparison 节呈现工具管理方案之对比分析。第 §sec:arch 节详述 TST 之架构与设计。第 §sec:search 节深入检视搜索机制。第 §sec:integration 节探索 MCP 生态系统整合。第 §sec:perf 节呈现性能评估。第 §sec:impl 节涵盖平台与实现细节。第 §sec:best 节综合最佳实践。第 §sec:limits 节讨论局限与权衡。第 §sec:future 节勾勒未来方向。第 §sec:related 节将本文定位于更广泛文献之中。第 §sec:conclusion 节作结。

背景与动机

大语言模型工具使用之演进

大语言模型使用外部工具之能力，经由若干明晰阶段而演进。工具增强语言模型之早期工作 [toolformer] 证明，大语言模型可通过工具调用示例之监督微调学会使用工具。此等早期系统限于少量工具（通常五至十项），依赖模型于训练期间学习工具使用模式。 通用工具调用 API 之引入——首由 OpenAI 以 Function Calling（GPT-4，2023 年）推出，继由 Anthropic 以 Tool Use（Claude，2023 年）推出——开启一新范式：工具可通过 JSON Schema 描述于推理时定义。此举将工具知识与模型训练解耦，使得动态演进之工具库无需重新训练即可变更。 MCP 协议，于 2024 年末推出，进一步抽象化工具通信，为智能体—工具交互提供通用协议 [mcp_spec]。每一智能体不再为每一外部系统维护定制集成代码，MCP 服务器通过标准化接口暴露工具，智能体实现 MCP 一次即可访问整个生态系统。

MCP 生态系统

MCP 生态系统以非凡速度增长。截止 2026 年中，社区已构建数千 MCP 服务器，覆盖领域自生产力工具（Google Workspace、Notion）至开发（GitHub、GitLab）、通信（Slack、Discord）、可观测性（Sentry、Grafana、Datadog）及企业系统（Salesforce、Jira、SAP）。SDK 可用于 Python、TypeScript、Java、Kotlin、C# 及 Go 等语言。 MCP 协议架构分层而建： 此分层架构使 MCP 服务器得以标准化、可发现之格式暴露工具。然其未规定工具如何载入大语言模型之上下文——此一缺口随工具数量增长而日益关键。

上下文工程基础

TST 之设计深植于上下文工程之原理，此学科与大语言模型系统之成熟相伴而生。如 Anthropic 研究团队所定义："上下文工程乃大语言模型推理期间策划与维护最优令牌集合之策略集合" [context_engineering]。 上下文工程之核心洞见在于：上下文乃珍贵而有限之资源。每一令牌消耗模型有限注意力预算之一部分，目标在于觅得"最大化期望结果可能性之最小高信号令牌集合"。此哲学直接指导 TST 之设计：非预先加载所有可能工具，系统力求仅于需要之时加载与当前任务最相关之工具。 上下文工程识别出 TST 所体现之若干关键原则：

问题分析：扩展危机

令牌消耗之量化

工具定义之令牌成本不可小觑，随工具数量线性增长。表 §tab:server_token 展示一代表性 MCP 部署之令牌消耗，基于 Anthropic 已发布之测量数据 [advanced_tool_use]。 此成本超越令牌而延及财务支出。按典型 API 定价计，每次请求十三万四千输入令牌可累积可观成本，尤于智能体每日处理数百乃至数千请求之高吞吐场景为甚。

准确率退化

工具膨胀对准确率之影响已有充分文献记载且意义重大。表 §tab:acc_degrade 呈现 TST 于 MCP 评估任务之已发表基准数据 [advanced_tool_use]。 由此结果可见若干模式。其一，能力较弱之模型从 TST 获益比例更大，Opus 4 提升 25 个百分点，而 Opus 4.5 提升 8.6 个百分点。此暗示工具选择对能力较弱之模型构成更显著之瓶颈，TST 通过简化决策空间有效消除此瓶颈之大部。其二，即便最先进模型（Opus 4.5 基线 79.5%）亦可测量地受益，表明工具选择准确率于先进模型仍为挑战，TST 所应对者乃根本性、模型无关之局限。

上下文衰减现象

工具膨胀所致之准确率退化非仅选择混淆之函数——其根植于 Transformer 架构之基本特性。关于"上下文衰减"之研究 [context_engineering] 已证明，随上下文窗口中令牌数量增加，模型准确回忆与利用信息之能力沿性能梯度（而非硬性悬崖）下降。 此现象已通过"大海捞针"测试获得实证验证：模型被要求检索嵌入于长上下文不同位置之特定事实。结果一致显示，位于上下文开头与末尾之信息召回准确率最高，位于中间之信息则出现显著下降——即所谓"迷失于中间"效应。 当工具定义数以十计乃至百计，每项独立工具皆成为日益庞大"草堆"中之一根"针"。模型不仅须选择正确工具，更须记住其参数模式、默认值及使用约定——而此等细节皆与对话历史、系统指令及中间结果争夺有限之注意力带宽。

工具管理方案之对比分析

传统全量加载方案

传统工具管理方式——仍为大多数 MCP 客户端与智能体框架所采用——将全部工具定义于任何推理发生之前载入上下文窗口。此"全量加载"策略具简单性之优势：模型自始即拥有对可用工具之完整知识，且无需额外交互轮次以发现工具。 然则，此方案存若干关键弱点： 于小型部署（少于十项工具，或定义不足一万令牌），传统方案仍属适当，亦为推荐策略 [tool_search_docs]。

OpenAI Function Calling

OpenAI 之 Function Calling 机制，随 GPT-4 引入并经后续模型世代精炼，代表工具使用之主导替代方案。其关键架构特征包括： 关键在于，OpenAI Function Calling 亦采用全量加载——所有工具定义随每次 API 请求发送。虽 OpenAI 提供更大上下文窗口（GPT-4.1 可达百万令牌），根本扩展问题依然存在：工具定义仍消耗上下文预算，工具选择准确率仍随工具数量增加而退化。 一显著差异在于，OpenAI API 架构于 tools 参数（工具定义）与 tool_choice（选择行为）之间维持分离，而 Anthropic 工具架构通过 defer_loading 及按工具级别之 tool_choice 提供更精细之控制。

编程式工具调用（代码执行）

编程式工具调用，亦称 MCP 代码执行，采用与上下文效率根本不同之方法 [code_exec_mcp]。工具不作为直接函数调用暴露，而是呈现为代码 API，模型编写脚本以编排多项工具调用。中间结果留于代码执行环境中，而非流经大语言模型上下文。 此方案于某些场景可实现更大之令牌节省——基准测试中自十五万令牌之工具定义减至二千令牌，节省高达 98.7%。其亦通过消除多次推理往返降低延迟：单次脚本进行二十余次工具调用，较之逐次调用节省十九次以上推理传递。 然则，编程式工具调用具重要之运行要求： 实践而言，编程式工具调用与 Tool Search Tool 互补而非竞争。TST 解决"有何可用工具"之发现问题，而编程式工具调用解决"如何高效使用众多工具"之组合问题。

多智能体架构

应对工具可扩展性之一新兴方案乃多智能体架构，其中专业化子智能体以各自工具集处理聚焦领域。如 Jenova 等系统报告通过专家路由与多模型编排于生产中达 97.3% 之工具使用成功率 [jenova_tool]。 核心洞见在于：无一智能体需同时访问所有工具。路由层将用户意图分类并分派至专业化智能体，各具聚焦之工具集。此减少任一智能体须管理之工具数量。 然则，多智能体架构引入自身之复杂性：

综合对比矩阵

表 §tab:comp_matrix 呈现四大工具管理方案跨关键维度之全面对比。 }

系统架构

架构概述

Tool Search Tool 于 Claude API 内作为元工具运行：其自身即为一工具，目的乃发现其他工具。此递归自相似性为其设计之根本——TST 始终可用（永不被延迟），并提供发现与加载所有延迟工具之机制。 系统架构包含四个主要组件：

延迟加载机制

TST 之核心创新在于工具定义上之 defer_loading 属性。当设为 true，完整工具定义自初始系统提示排除，留存于延迟注册表中。当设为 false（或省略），工具立即加载，遵循传统模式。 此机制启用一混合部署模型：少量必要、频繁使用之工具始终可用，而绝大多数工具仅于需要时加载。表 §tab:defer_rules_zh 总结治理延迟加载之规则。 API 强制执行一硬性约束：全部工具延迟部署（无非延迟工具）返回 HTTP 400 错误。此确保模型始终拥有至少基线能力与发现额外工具之机制。

执行流程

完整执行流程经由五个阶段：

提示缓存集成

TST 之一项关键架构特性乃其与提示缓存之兼容性。因系统提示前缀（含 TST 与非延迟工具定义）贯穿对话始终不变，其可一次缓存并跨多次 API 调用重用。仅对话主体随工具之发现而增长。 此设计用意深远：defer_loading 机制确保工具定义永不出现在缓存前缀中，而工具展开器确保其始终出现在可变之对话主体中。结果提示缓存于对话期间无论发现多少工具皆保持完全有效。

工具定义格式

TST 部署中之工具定义格式遵循标准 Claude API 工具模式，附加 defer_loading 属性： { "name": "get_weather", "description": "获取指定位置之当前天气", "input_schema": { "type": "object", "properties": { "location": { "type": "string", "description": "城市名称" }, "unit": { "type": "string", "enum": ["celsius", "fahrenheit"] } }, "required": ["location"] }, "defer_loading": true } 此格式与标准工具定义一致——仅增加 defer_loading 标志。此设计选择确保向后兼容，使开发者得以通过为现有工具定义添加标志而渐进采用 TST。

搜索机制：深入剖析

基于正则表达式之搜索

基于正则表达式之搜索，类型标识为 tool_search_tool_regex_20251119，采用 Python 正则表达式匹配（re.search() 语义）针对工具名称、描述、参数名及参数描述。此模态于模型对工具生态系统命名约定有清晰理解时可进行精确、确定性查询。

查询构建与语义

模型以正则表达式模式构建查询字符串，最大长度二百字符。搜索引擎以模式测试每项延迟工具之组合文本表示，按匹配精确度排序。 常见有效模式包括：

基于 BM25 之搜索

基于 BM25 之搜索，类型标识为 tool_search_tool_bm25_20251119，采用 Okapi BM25 概率检索模型按自然语言查询之相关性排序工具。

BM25 基本原理

BM25 乃一词袋检索函数，以文档长度归一化扩展经典 TF-IDF 加权方案。对于工具文档 d 与查询 q，评分计算如下： 其中 f(t,d) 为词项 t 在工具文档 d 中之词频，|d| 为文档长度（以令牌计），{avgdl} 为整个工具注册表之平均文档长度，{IDF}(t) 为词项 t 之逆文档频率，k_1 与 b 为可调参数（通常 k_1 = 1.5，b = 0.75）。 IDF 分量确保罕见但具区分力之词项对评分贡献大于常见词项，而文档长度归一化防止较长之工具描述纯因长度而主导排名。

查询构建与排序

BM25 查询以自然语言表达，使模型得以表述意图而非预测命名模式。搜索引擎将查询分词，计算每项工具组合表示之 BM25 评分，返回前三至五项结果。 例如，查询向频道发送消息''将匹配名称与描述中含消息''、发送''及频道''等词项之工具——包括名为 post_message、send_notification 及 channel_broadcast 之工具——即便无一与查询短语精确匹配。

搜索模态之对比分析

表 §tab:search_comp_zh 提供两种内置搜索变体之详细对比。

自定义搜索实现

于内置搜索变体之外，平台通过一明确定义之扩展机制支持自定义搜索实现。开发者可实现自有搜索逻辑——例如使用基于嵌入之语义搜索、领域特定本体或学习相关性模型——并自自定义工具返回 tool_reference 块。 自定义搜索之机制遵循标准工具结果格式：自定义工具于其结果中返回 tool_reference 块，API 处理向完整工具定义之展开。关键要求在于每项引用工具名必须在 tools 参数中有对应定义且设 defer_loading: true。 此可扩展性于领域特定部署尤有价值。例如：

搜索质量考量

搜索结果之质量关键取决于工具名称与描述之质量，因此二者乃正则与 BM25 双后端所索引之唯二字段。影响搜索质量之关键因素包括：

MCP 生态系统整合

MCP 协议架构与 TST 整合

Tool Search Tool 于多层面与 MCP 生态系统整合，构成一完整之工具管理架构。此整合利用 MCP 之分层协议设计，实现对哪些工具于何时消耗上下文之精细控制。 于服务器层面，整个 MCP 服务器可配置为延迟加载，个別高频工具选择性标记为非延迟。此启用一部署模式，其中：

渐进式揭示架构

TST 与 MCP 共同实现一映射人类信息搜寻行为之渐进式揭示架构。模型始于最小工具集（非延迟工具）及对可用工具类别之高层理解（来自系统提示）。随任务需求，其逐步发现并加载额外工具。 此方案具若干优势：

互补技术：TST + 代码执行

Tool Search Tool 与编程式工具调用（MCP 代码执行）应对工具管理挑战之互补侧面。TST 解决发现问题（任务可用何工具），而编程式工具调用解决组合问题（如何高效编排多项工具调用）。 表 §tab:complement_zh 展示此等技术如何基于任务特征组合运用。

Skills 系统集成

Skills 系统——模型可引用并用于专业化任务之可重用指令、脚本及资源文件夹——提供与 TST 之额外整合层。Skills 可封装常见工具编排模式，减少工具发现频率并提升一致性。 例如，``部署至生产环境''技能可捕获部署工作流所需之 GitHub、Slack 及 Jira 工具之特定序列。模型通过 TST 发现该技能，加载技能指令，执行工作流而无须为每次部署重新发现每一项独立工具。

状态管理与工具持久化

已发现之工具于会话期间留存于对话上下文中，模型无需为已发现之工具重新搜索。此持久化通过 API 跨完整对话历史自动展开 tool_reference 块而实现——此乃一项关键架构特性，于多轮交互中减少搜索开销。 对于长时间运行之智能体会话，此持久化可通过上下文压缩与结构化笔记策略加以扩展，其中已发现之工具引用包含于压缩摘要中，并重新注入后续上下文窗口。

性能评估

令牌效率

TST 之主要量化收益在于令牌消耗之大幅削减。表 §tab:token_eff_zh 对比传统全量加载方案与基于 TST 之加载于五十余工具 MCP 配置下之表现。 令牌效率收益于多服务器 MCP 部署中最为显著。当可用工具数量接近一万，传统方案已不可行，而 TST 维持近乎恒定之上下文开销。此使得此前架构上不可能之部署场景成为可能。

工具选择准确率

TST 所带来之准确率提升跨模型世代皆有显著意义，如前述表 §tab:acc_degrade 所示。提升尤以 Opus 4 为显著，TST 提供 51% 相对提升（49% 至 74%）。即便已近 80% 基线准确率之 Opus 4.5 亦测量上受益。 此等提升源于两种机制：

延迟分析

TST 引入一延迟权衡：额外之 API 往返以发现工具，对比因更小上下文窗口而缩减之每调用处理时间。 于基准场景（五十余工具 MCP 配置），传统方案每调用处理约七万七千令牌。TST 方案每调用处理约八千七百令牌，但需初始搜索往返。对于：

可扩展性分析

TST 之可扩展特性乃一项关键架构优势。表 §tab:scale_zh 展示传统方案与 TST 方案工具数量与上下文成本之关系。 关键洞见在于：TST 实现相对于可用工具数量之 O(1) 上下文成本，而传统方案以 O(n) 扩展。此使得传统方案架构上不可能之部署场景成为可能。

跨模型性能

TST 之性能跨模型世代而异，反映模型能力与工具选择难度间之相互作用：

平台与实现细节

API 集成架构

TST 作为一等工具类型集成于 Claude Messages API，通过将其纳入 tools 数组（与延迟及非延迟工具并列）而激活。此集成设计为对现有工具使用实现透明——开发者添加 TST 与 defer_loading 标志，API 处理所有搜索、展开及缓存。 高级工具使用功能集（含 TST）通过 beta 头访问：advanced-tool-use-2025-11-20。部署推荐模型为 claude-sonnet-4-5-20250929，max_tokens 至少设为 4096。

流式支持

TST 通过 SSE 协议完全兼容流式响应。流式流程包含工具搜索之专用事件类型： event: content_block_start data: {"type": "content_block_start", "index": 1, "content_block": {"type": "server_tool_use", "id": "srvtoolu_xyz789", "name": "tool_search_tool_regex"}} event: content_block_delta data: {"type": "content_block_delta", "index": 1, "delta": {"type": "input_json_delta", "partial_json": "{"query":"weather"}"}} 此结构化流式传输使模型搜索并发现工具时之实时 UI 更新成为可能。

批量处理

TST 于 Messages Batches API 中受支持，定价与常规 Messages API 请求相同。批量处理集成维持相同之搜索、展开及缓存行为，使 TST 适用于交互式与批量两类工作负载。

模型兼容性矩阵

表 §tab:model_comp_zh 展示 TST 之模型支持情况。

错误处理

TST 为数种失败模式定义结构化错误响应： 配置错误返回 HTTP 400 及描述性消息：

零数据保留与隐私

对于具有零数据保留安排之组织，通过 TST 发送之数据于 API 响应返回后不被存储。用量统计包含 server_tool_use.tool_search_requests 计数器，跟踪搜索操作次数而不保留查询内容。

平台可用性

TST 于以下平台获完整支持： 于 Amazon Bedrock 上，TST 通过 InvokeModel API 受支持，但非通过 Converse API。此平台限制于多云部署架构中应予考虑。

最佳实践

部署决策框架

部署 TST 之决策应基于对部署特征之量化评估。表 §tab:deploy_decision_zh 提供决策框架。

工具命名与描述设计

TST 之有效性关键取决于工具名称与描述之质量，因此二者乃双搜索后端所索引之唯二字段。最佳实践包括：

非延迟工具选择

保留哪三至五项工具为非延迟之选择显著影响用户体验。选择标准包括：

系统提示工程

为模型提供描述可用工具类别之系统提示，助其构建有效搜索查询。TST 有效之系统提示补充或如下所示： "你可访问与 Slack（消息、频道管理）、GitHub （仓库、议题、PR）、Jira（工单管理）及若干其他 服务交互之工具。需此等类别之特定工具时，使用 Tool Search Tool。" 此引导帮助模型理解工具空间之``形状''，而无须消耗实际定义所需之令牌。

监控与优化

TST 支持若干监控与优化模式：

迁移策略

对于采用 TST 之现有部署，推荐分阶段迁移策略：

局限与权衡

工具使用示例不兼容

TST 当前最显著之局限在于其与工具使用示例之不兼容。工具使用示例提供传达使用模式、格式约定及参数关系之具体实例——此为 JSON Schema 单独无法传达之信息。Anthropic 数据显示工具使用示例将复杂参数处理准确率自 72% 提升至 90%。 此不兼容源于工具使用示例为通常预加载之工具定义之一部分。当 defer_loading 活跃，示例随定义一同延迟，API 当前不支持延迟示例展开。 此代表一权衡：开发者须于发现效率（通过 TST）与基于示例之引导（通过工具使用示例）二者间抉择。对于正确调用至关重要且参数复杂度高之工具，将此等工具保持为非延迟并附带示例或为更佳选择。

搜索延迟开销

工具发现之额外 API 往返引入于延迟敏感型应用中或可察觉之延迟。虽此开销部分由更小上下文窗口之更快处理所抵消，并于多轮交互中摊销，然需要新工具之单轮交互将经历可测量之延迟。

查询质量依赖

TST 之有效性依赖模型构建高质量搜索查询之能力。若模型构建形式不当之正则模式或不够具体之 BM25 查询，搜索或返回无关或不完整之结果，需额外搜索往返。 此依赖创造一递归问题：模型需理解工具生态系统以构建有效查询，然其构建查询恰为理解工具生态系统。系统提示关于工具类别之引导乃此挑战之主要缓解措施。

平台限制

TST 当前限于 Anthropic 生态系统（Claude API、AWS Claude Platform、Bedrock InvokeModel）。使用其他模型提供商（OpenAI、Google、开源模型）之部署无法直接使用 TST 之延迟加载机制。对于跨提供商部署，需一在不同模型 API 间模拟 TST 式行为之统一工具管理层。

描述质量瓶颈

因双搜索后端以工具名称与描述为其唯一信息源，此等描述之质量成为搜索质量之硬性上限。工具文档不佳、命名约定不一致或工具有机演化之组织或发现 TST 搜索性能欠佳，直至其投入工具描述改善。

未来方向

语义搜索集成

TST 最为自然之演进乃将基于嵌入之语义搜索集成为一等搜索模态。虽自定义搜索扩展机制已支持此模式，原生语义搜索支持将降低采用门槛，并为语义相似而词汇相异之工具提供开箱即用之消歧。 语义搜索将解决当前正则与 BM25 后端之数项局限：其将正确匹配上传''与创建文件''，处理多语言查询，并支持概念级而非词项级匹配。权衡在于嵌入生成增加之计算成本，此可通过存储于延迟注册表之预计算工具嵌入加以缓解。

跨轮次工具推荐

当前 TST 行为将每次工具搜索独立对待。一学习自历史工具使用模式——跨对话、用户及任务类型——之系统可于模型显式搜索之前主动预加载工具，将常见工作流之搜索开销降为近乎零。 此需一观察工具共现模式与用户行为之推荐引擎，生成个性化工具预加载建议。隐私考量至关重要，因工具使用模式或揭示用户工作流之敏感信息。

层级工具命名空间

于一万工具之规模，即便三至五项搜索结果，当众多工具共享广泛功能类别时或仍显繁杂。一层级命名空间系统——模型首先发现高层工具类别，继而逐步深入特定工具——将维持极端规模下之可发现性。 此可通过不仅按名称与描述、亦按工具注册表中定义之类别层次索引工具而实现。搜索工具将支持``类别''过滤器，于详细匹配前将结果缩小至特定领域。

工具使用示例集成

解决 defer_loading 与 input_examples 之间之不兼容乃高优先级工程任务。将示例与延迟工具关联之机制——将示例存储于工具注册表中并于展开阶段与工具定义一同展开——将结合发现效率与基于示例之引导两者之优势。

跨提供商标准化

延迟工具加载之概念于 Anthropic 生态系统外亦具价值。一跨提供商延迟工具发现标准——或作为 MCP 协议之扩展——将使跨 OpenAI、Google、开源模型及其他提供商之统一工具管理方案成为可能。此将允许开发者实现工具搜索一次即可跨多模型后端部署。

自主工具组合

展望更远，TST（发现）、编程式工具调用（组合）与 Skills（重用）之结合指向自主工具组合：智能体无需人工干预而发现、组合并创建新工具能力之可能。一智能体或搜索现有工具，判定无一完美匹配任务，自部分匹配组合解决方案，并将该组合保存为新技能以供未来使用。 此将代表自使用工具之智能体''向创造工具之智能体''之质变，闭合发现与能力增长之间之循环。

相关工作

本文借鉴并贡献于若干研究领域。

工具增强语言模型

大语言模型使用外部工具自大规模语言模型出现以来即为活跃研究领域。Toolformer [toolformer] 证明大语言模型可通过工具调用示例之监督微调学会使用工具，于下游任务取得显著改进。Gorilla [gorilla] 探索基于检索之 API 选择方案，使用文档检索将自然语言查询匹配至大规模 API 空间中适当之 API。 此等早期工作确立了工具使用之可行性，然假设相对较小之工具库（数十而非数百或数千工具）。Tool Search Tool 延伸此工作线，提供通过动态发现扩展至数千工具之机制。

检索增强生成

TST 与检索增强生成系统 [rag] 共享概念基础，后者自知识库检索相关文档并注入大语言模型上下文。TST 可视为 RAG 之一特殊形式，其中``文档''为工具定义，检索优化为短结构化文本，且检索内容展开为可函数调用之工具。 与通用 RAG 系统不同，TST 与大语言模型推理循环之紧密集成——搜索、展开及工具调用形成无缝管道——乃一区分性架构特征。

上下文窗口优化

有限上下文窗口之挑战驱动多种优化策略。提示压缩技术如 LLMLingua [llmlingua] 通过令牌裁剪减少提示长度。流式架构分块处理上下文。记忆增强模型维护外部记忆存储。 TST 对此领域之贡献在于聚焦工具定义开销之特定问题——通用压缩技术或未能有效应对此问题，因其可能丢失关键工具细节（参数类型、枚举值、必填字段）。TST 通过仅为所需工具加载完整定义而保留完整工具保真度。

智能体框架

若干智能体框架自不同角度应对工具管理。LangChain [langchain] 通过思维链推理提供工具选择。AutoGPT 及类似框架维护具基于规划之工具选择之工具注册表。模型上下文协议 [mcp_spec] 标准化工具通信，然将工具加载策略留予各实现。 TST 之新颖性在于将工具发现集成于大语言模型推理循环之内，使基于当前对话状态之工具加载上下文感知决策成为可能。

多智能体工具架构

新兴之多智能体方案，以 Jenova 等系统为代表 [jenova_tool]，通过专家路由与领域特定智能体专业化应对工具可扩展性。此等系统将用户请求路由至专业化智能体，各具聚焦之工具集，而非向单一智能体呈现所有工具。 TST 与多智能体方案互补：TST 优化单一智能体内之工具发现，而多智能体架构优化跨智能体之工具分布。一组合方案或可兼得两者之优势。

结论

Anthropic Tool Search Tool 代表大语言模型智能体管理其工具生态系统之一项重大架构进步。通过自"全量加载"转向"即时"工具加载模式——根植于上下文工程之原理——TST 跨多维度实现同步且实质之改进： 本文所呈现之对比分析表明，TST 于工具管理格局中占据独特位置。不同于 OpenAI Function Calling（采用全量加载与更大窗口）、编程式工具调用（需安全执行环境）或多智能体架构（增加协调复杂性），TST 以最小运维开销与最大向后兼容性提供动态发现。 若干重要局限——尤其工具使用示例之不兼容与查询质量依赖——代表活跃之改进领域。本文所勾勒之未来方向——语义搜索集成、跨轮次推荐、层级命名空间及跨提供商标准化——指向一生态系统，其中动态工具发现不仅为一功能特性，更是智能体 AI 系统之基础架构模式。 随 AI 智能体持续获得自主性，其导航之工具生态系统持续扩张，自"加载一切"向"按需发现"之范式转移将证明必不可少。Tool Search Tool 既为今日扩展挑战之实用解决方案，亦为未来 AI 系统与其所栖软件生态系统交互方式之先兆：非记忆每一项可用能力，而是知悉如何于所需之时觅得所需之物。 Anthropic, 模型上下文协议规范,'' 2024. [Online]. Available: <https://modelcontextprotocol.io/specification/> A. Jones and C. Kelly, MCP 代码执行：构建更高效之智能体,'' Anthropic 工程博客, 2025年11月. [Online]. Available: https://www.anthropic.com/engineering/code-execution-with-mcp Anthropic, Claude 开发者平台高级工具使用介绍,'' Anthropic 工程博客, 2025年11月. [Online]. Available: <https://www.anthropic.com/engineering/advanced-tool-use> Anthropic, AI 智能体之有效上下文工程,'' Anthropic 工程博客, 2025. [Online]. Available: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents Anthropic, 工具搜索工具 —— Claude 平台文档.'' [Online]. Available: <https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool> T. Schick *et al.*, Toolformer：语言模型可自教使用工具,'' 载于 神经信息处理系统进展, 2023. S. G. Patil, T. Zhang, X. Wang, and J. E. Gonzalez, Gorilla：连接大规模 API 之大语言模型,'' arXiv:2305.15334, 2023. P. Lewis *et al.*, 知识密集型自然语言处理任务之检索增强生成,'' 载于 神经信息处理系统进展, 2020. H. Jiang, Q. Wu, C.-Y. Lin, Y. Yang, and L. Qiu, LLMLingua：压缩提示以加速大语言模型推理,'' 载于 *EMNLP 会议录*, 2023. LangChain, LangChain：通过可组合性构建大语言模型应用.'' [Online]. Available: https://github.com/langchain-ai/langchain Anthropic, 深入 Claude Code：今日与未来 AI 编码智能体之设计空间,'' arXiv:2604.14228, 2026. Jenova, Jenova 如何解决 AI 工具可扩展性问题,'' MintMCP 博客, 2025年11月. [Online]. Available: https://www.mintmcp.com/blog/how_jenova_solved_the_ai_tool_scalability_problem X. Liu et al., MemTool：优化大语言模型智能体多轮对话中动态工具调用之短期记忆管理,'' 2025. OpenAI, 函数调用 —— OpenAI API 文档.'' [Online]. Available: https://platform.openai.com/docs/guides/function-calling ``工具使用与函数调用：大语言模型工具调用架构深度对比,'' CSDN 技术博客, 2026年4月.

参考文献

[1] Anthropic, "模型上下文协议规范," 2024. https://modelcontextprotocol.io/specification/

[2] A. Jones and C. Kelly, "MCP 代码执行：构建更高效之智能体," Anthropic 工程博客, 2025年11月.

[3] Anthropic, "Claude 开发者平台高级工具使用介绍," Anthropic 工程博客, 2025年11月.

[4] Anthropic, "AI 智能体之有效上下文工程," Anthropic 工程博客, 2025.

[5] Anthropic, "工具搜索工具 —— Claude 平台文档," https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool

[6] T. Schick 等, "Toolformer：语言模型可自教使用工具," NeurIPS, 2023.

[7] S. G. Patil 等, "Gorilla：连接大规模 API 之大语言模型," arXiv:2305.15334, 2023.

[8] P. Lewis 等, "知识密集型自然语言处理任务之检索增强生成," NeurIPS, 2020.

[9] H. Jiang 等, "LLMLingua：压缩提示以加速大语言模型推理," EMNLP, 2023.

[10] LangChain, "LangChain：通过可组合性构建大语言模型应用," https://github.com/langchain-ai/langchain

[11] Anthropic, "深入 Claude Code," arXiv:2604.14228, 2026.

[12] Jenova, "Jenova 如何解决 AI 工具可扩展性问题," MintMCP 博客, 2025年11月.

[13] X. Liu 等, "MemTool：优化动态工具调用之短期记忆管理," 2025.

[14] OpenAI, "函数调用 —— OpenAI API 文档," https://platform.openai.com/docs/guides/function-calling

[15] "工具使用与函数调用：大语言模型工具调用架构深度对比," CSDN 技术博客, 2026年4月.