Microsoft 推出了 Foundry Toolbox 及其配套功能 Tool Search。这是一个单端点服务，允许开发人员将 AI agent 连接到数百个工具，而无需为每个 agent 单独进行连接。当工具目录包含超过 600 个工具时，Tool Search 可减少高达 94% 的输入 token。

为什么中央工具箱至关重要

AI agent 需要外部能力（如数据库、CRM、分析平台）来满足用户请求。直到现在，许多组织仍将每个 agent 直接连接到所需的 API。工程师们必须为每个新 agent 重复进行凭据配置、策略执行和错误处理代码编写。其结果是形成了一个由重复设置构成的复杂网络，难以审计且容易出现安全漏洞。

Foundry Toolbox 用统一的服务层取代了这种零散的模式。与其让数十个 agent 分别指向数十个独立的端点，不如让所有 agent 都与单一的“toolbox”端点进行通信。Toolbox 负责版本控制、连接字符串和安全策略，让团队能够从一处管理整个工具生态系统。在多个业务部门运行数十个 agent 的企业，其运营开销会立即下降。

通过 Tool Search 减少 token 膨胀

大型工具目录会产生一项隐藏成本：token 使用量。当语言模型接收到一个列出所有可用工具的提示词（prompt）时，上下文窗口（context window）会膨胀，消耗掉原本可以用于推理或面向用户的文本的 token。Tool Search 从源头上解决了这个问题。

当 agent 启用 Tool Search 时，模型首先会调用一个名为 tool_search 的元工具（meta-tool），用自然语言描述其需求（例如，“查找 X 地区的最新销售预测”）。该服务会返回一个与意图匹配的候选工具简短排名列表。随后，模型调用 call_tool，从该列表中选择最合适的条目。通过仅暴露相关的子集，提示词保持极小规模，在 600 个工具的基准测试中，可节省高达 94% 的输入 token。

这种两步工作流还提高了选择的准确性。在同样的基准测试中，与被迫筛选整个目录时相比，模型选择正确工具的频率更高，减少了错误调用和不必要的重试。

如何充分利用工具箱

  • 编写高质量的元数据 – Tool Search 依赖于每个工具的名称和描述。像“获取数据”这样模糊的标签很难为模型提供有效信息。而像“检索客户续约风险和联系方式”这样详细的标题，能引导搜索引擎找到正确的匹配项。
  • 固定常用工具 – 如果 agent 在每次交互中都需要某个特定的工具，请将该工具固定到 agent 的配置中。固定操作可以跳过搜索步骤，从而降低延迟并减少 token 消耗。
  • 按功能进行组织 – 不要创建一个覆盖整个企业的庞大工具箱，而是将工具拆分为逻辑组（例如，sales-tools、CRM-tools）。较小的分组可以限制配置错误的影响范围，并使搜索结果更加聚焦。
  • 部署前进行测试 – Toolbox 版本是不可变的；一旦某个版本被设为默认版本，所有 agent 都会开始使用它。在全公司推广之前，请使用开发人员端点在隔离环境中验证新版本。

当工具数量增加到数百个时，这些实践显得尤为重要。对于仅拥有少量工具的单个 agent 而言，直接连接可能仍然是最简单的途径。但随着团队规模扩大和工具箱的扩展，这种集中式模型通过减少重复、加强安全性和实现可衡量的 token 节省，将展现出其显著价值。

核心结论： Foundry Toolbox 和 Tool Search 为大规模 AI 部署提供了一种治理工具蔓延的方法，通过增加一个单一且管理良好的服务层，即可减少高达 94% 的 token 浪费并执行一致的安全策略。能够投入初始设置并保持元数据规范的团队，将获得一个更精简、更易于控制的 agent 生态系统。