什么是 Foundry 中的工具箱？

随着组织采用 AI 代理，跨代理管理工具可能变得越来越复杂。 代理通常直接连接到工具、API、MCP 服务器和其他服务，需要针对每个实现单独配置、身份验证和治理。 随着代理数量的增长，此方法可能会导致重复的工作、不一致的行为、脆弱的生产部署和其他操作开销。

工具箱提供了一种在 Microsoft Foundry 中管理和共享工具的集中方法。 使用工具箱，可以定义一组特选的工具，并通过一个与 MCP 兼容的终结点公开它们，代理可以在框架和运行时之间使用这些终结点。 工具箱有助于简化工具集成，同时启用集中式凭据管理、治理、可观测性和访问控制。   团队无需为每个代理单独配置工具，而是可以在一个位置管理工具，在多个代理中重复使用它们，并更新工具实现，而无需更改代理代码。 此方法可帮助组织缩放代理开发，同时保持一致的安全性和操作实践。

本文介绍工具箱的工作原理、其核心概念和体系结构，以及如何在 Microsoft Foundry 中创建和管理工具箱。

为何使用工具箱？

请考虑有助于加入新员工的代理。 单个请求可能需要代理：

• 使用 知识库检索载入指南。
• 使用 REST API 创建Microsoft Entra ID帐户。
• 使用 长时间运行的代理预配云资源。
• 使用 代理技能起草个性化欢迎电子邮件。
• 使用 MCP 服务器向Microsoft Teams通道发布欢迎消息。

这是五种类型、五种身份验证模型和五个拥有团队 - 一个 代理。 现在，将组织生成的每个代理相乘：

• Teams 独立地重新实现相同的工具。
• 凭据重复，每个代理管理自己的机密和令牌刷新。
• 治理不一致或缺失，对哪些工具存在或正在使用这些工具几乎没有可见性。

如果没有集中式方法，每个代理都必须使用自己的工具定义、凭据和集成逻辑进行配置。 当组织创建更多代理时，此模型可能会导致重复的工具实现、不一致的安全控制以及增加操作开销。

工具箱通过允许团队集中定义和管理工具，并通过与 MCP 兼容的单个终结点公开这些挑战。 然后，代理可以使用批准的工具，而无需每个代理的自定义集成，帮助组织改进工具重用、简化凭据管理，并在代理部署中一致地应用治理。

工具生命周期 - 生成、发现、使用和管理

工具箱通过四大支柱涵盖完整的工具生命周期 - 生成、发现、使用和管理：

支柱	价值主张
Build	创建可重用的工具和 技能集合（预览版），发布一次，并集中配置身份验证，以便任何团队都可以使用相同的工具，而无需复制每个代理配置或凭据。
发现	使用 工具搜索（预览版） 帮助代理在运行时查找最相关的工具。 单个工具箱可以容纳数百个工具，而不会淹没模型的上下文、膨胀令牌成本或降低选择准确性。
消费	将代理连接到单个 MCP 兼容的终结点，该终结点提供对工具箱中工具的访问权限。 代理可以跨协议和身份验证模型发现和调用工具，而无需自定义集成。
Govern	在工具箱级别应用身份验证、授权、防护措施、可观测性和版本管理。 集中式治理可帮助组织跨代理和工具保持一致的安全性和操作控制。

Foundry-homed，not Foundry-bound

工具箱是在 Microsoft Foundry 中创建和管理的，但它们不限于基于 Foundry 的代理。 任何 MCP 兼容的运行时或客户端都可以使用工具箱，包括使用 Microsoft Agent Framework、LangGraph 或你自己的代码生成的自定义代理。

由于工具箱是托管资源，因此无需更改代理代码即可添加、删除或更新工具。 当管理员集中管理工具可用性和配置时，代理将继续连接到同一终结点。 使用 版本控制，可以升级工具箱的新默认版本，并使它可用于使用代理，而无需重新部署这些代理。

观看这些演示，查看工具箱的操作：

关键功能

Microsoft Foundry 代理工具箱添加了功能，这些功能使大型、快速增长的工具集合可管理且安全。

• 单个终结点。 代理连接到一个 MCP 兼容的终结点，并在运行时发现每个工具。 无需更改代理代码或重新部署即可添加、删除或重新配置工具。
• 集中式身份验证。 工具箱使用 Microsoft Entra ID 和 OAuth 标识传递在运行时处理凭据注入、令牌刷新和策略强制实施，因此使用代理不会管理每工具凭据。
• 默认情况下，治理。 将防护措施（负责任的 AI 策略）应用于工具箱级别的工具输入和输出。
• 版本控制。 创建并测试新的工具箱版本，然后在准备就绪时将其提升为默认值。 指向工具箱的每个代理都会自动选取升级的版本，无需更改代码。

除了这些关键功能之外，工具箱还启用以下新的预览功能：

工具搜索（预览版）

随着应用程序的增长，可用工具的数量也随之增加。 一个以几个工具开头的工具箱可以快速扩展到数十甚至数百个。 使用每个模型请求发送每个工具定义都会带来挑战：

• 随着工具计数的缩放，成本增加： 每个工具定义都会添加输入令牌，无论模型是否使用该工具。
• 减少上下文容量： 工具定义与模型上下文窗口中空间的对话历史记录、域知识和其他上下文竞争。
• 不太准确的工具选择： 当模型必须从数百个工具中进行选择时，更有可能选择类似但不正确的工具或忽略最佳选项。

工具搜索默认通过隐藏工具并仅公开两个元工具来解决这些难题：

• tool_search - 描述所需内容并获取最相关的工具。
• call_tool - 按名称调用任何发现的工具。

你可以控制工具的显示方式。

• 固定 关键工具，使其始终可用。
• 添加上下文 以使用组织使用的术语改进工具发现。
• 自动固定 常用工具。

了解详细信息：工具搜索（预览版）。

技能（预览版）

工具 定义代理 可以执行的操作。 技能 定义它 如何执行任务。

• 技能包 可重用的多步骤工作流作为代理可以像任何其他工具一样调用的功能。 例如，技能可能会生成格式化报表、执行会审工作流或协调工具调用序列。

• 技能是 版本控制且不可变的。 可以将特定技能版本附加到工具箱，以确保跨环境保持一致且可预测的行为。

• 技能减少了使用共享工作流 所需的设置 。 代理在启动时通过 MCP 资源自动发现和加载技能。

请参阅技能（预览版）。

支持的工具

支持以下工具。

工具	工具箱	直接工具集成
模型上下文协议 （MCP）	✅ 是的	✅ 是的
Web 搜索	✅ 是的	✅ 是的
Azure AI 搜索	✅ 是的	✅ 是的
代码解释器	✅ 是的	✅ 是的
文件搜索	✅ 是的	✅ 是的
OpenAPI	✅ 是的	✅ 是的
代理到代理（A2A）	✅ 是的	✅ 是的
浏览器自动化	✅ 是的	✅ 是的
Fabric IQ	✅ 是的	✅ 是的
工作 IQ	✅ 是的	✅ 是的
工具搜索	✅ 是的	❌ 否
技能	✅ 是的	❌ 否
提醒工具	✅ 是的	❌ 否
函数调用	❌ 否（客户端执行）	✅ 是的
使用必应进行地面	❌ 否	✅ 是的
计算机使用	❌ 否	✅ 是的
图像生成	❌ 否	✅ 是的
SharePoint	❌ 否	✅ 是的
Fabric 数据代理	❌ 否	✅ 是的
Azure Functions	❌ 否	✅ 是的

开始

• 在 Foundry 中创建和管理工具箱 - 设置工具箱并将其集成到代理中。
• 工具箱快速入门 - 生成工具箱并将其与托管代理端到端配合使用。