在开始之前，我得先把话说透。 Microsoft Foundry Toolboxes 真正要收拾的烂摊子，其实不是“Agent 能不能调用工具”这种老生常谈。它真正棘手的问题是：工具一多，Agent 怎么在几十上百个选项里精准找到对的，如何受权限约束，以及怎么避免每次对话都把一长串工具 schema 塞进大模型上下文。如果你只有 5 个工具，这可能不叫事；当规模涨到 50、200 个，这就直接变成了成本、稳定性和治理层面的硬仗。 所以，短期来看，这套方案更适合那些已经在 Microsoft Foundry、Azure AI 或 Microsoft 365 数据体系内搭建多工具 Agent 的团队。反过来，如果你只是给个人脚本挂一两个 API，Toolboxes 自带的那层治理框架，很可能比你想解决的问题还要沉重。 关键信息 入口：Microsoft Foundry portal。在这里可以创建 project、部署模型、构建 hosted agent。 核心能力：Tool Search、Skills、Work IQ、Fabric IQ、Browser Automation、Managed MCP servers、Guardrails。 接口事实：示例代码中使用了 AIProjectClient、DefaultAzureCredential、WebSearchTool、MCPTool、ToolboxSearchPreviewTool。 运行边界：Routines 属于 Foundry Agent Service 的 preview 功能，负责 agent 的 run control，但请注意，它不是复杂工作流引擎。 关键验收指标：工具检索命中率、工具调用失败率、每轮输入消耗的 token 数、权限越权拦截记录。 项目来源 这套能力的直接来源，是 Microsoft Foundry Blog 在 2026 年 6 月 3 日发布的一篇文章，标题叫《Discovery to Execution: Scaling Agents with Toolboxes and Routines in Microsoft Foundry》，作者是 Linda 和 Maria。文章围绕 Build 2026 展示了 Foundry 里 Toolboxes 和 Routines 的扩展方向：前者管理 Agent 运行时如何发现、访问和调用工具；后者则管理 Agent 何时被触发、排队、执行和追踪。 全文最有价值的一点，是 Microsoft 并没有继续把工具调用包装成“一个函数列表”，而是彻底拆解成了目录、检索、权限、运行历史和审计这几个环节。对那些正在对接 MCP Server、内部 API 和 SaaS 连接器的团队来说，这个思路比重新写一个 function calling demo 更贴近真实的工程挑战。 核心技术点：配置与权限 Tool Search 是这次最值得细拆的模块。 传统做法是把所有工具的定义一股脑全发给模型，让模型自己选。Foundry 的做法很不一样：启用 Tool Search 后，只会暴露两个“元工具”。一个叫 **tool_search**，用来按意图检索相关工具；另一个叫 **call_tool**，用来按名称调用已经发现的工具。其他所有工具默认是隐藏的。 这会彻底改变 Agent 的数据流：用户意图进入模型后，模型先描述“我需要什么工具”，Toolbox 根据描述返回候选工具，然后模型再通过 call_tool 去执行。好处显而易见：上下文干净多了，成本不会随着工具总数线性上涨。但风险也很现实——检索层一旦漏召回，模型根本看不到正确的工具，那就全完了。 Toolbox 还提供了几类控制手段： - pin 某些关键工具，让它们始终对模型可见； - 补充工具上下文，让工具描述更贴近团队内部习惯的叫法； - auto-pin 高频工具，减少每次多一次搜索的开销。 这些配置看似零碎，其实直接决定了 Agent 在复杂工具目录里是“会找工具”还是“看起来有很多工具但经常选错”。 数据和权限部分分得更细了。Work IQ 让 Agent 接入 Microsoft 365 组织上下文，并强调沿用现有权限和策略，不直接暴露原始数据。Fabric IQ 连接业务数据层，涉及 ontology、Fabric data agents 和 Power BI semantic models。Browser Automation 则基于 Playwright workspaces，提供 MCP-native 的网页自动化能力。Managed MCP servers 来自 Azure Connector Namespace，可以连接 Jira、Confluence、LinkedIn、Box 等系统。 安全侧的重头戏是 Guardrails。它位于 Foundry Control Plane，可以对工具的输入和输出执行策略，拦截合规违规、敏感数据暴露、不安全内容或偏离任务的调用。这里有一个很明确的判断：如果缺少 Guardrails、连接权限和调用审计，多工具 Agent 在规模扩大后，不但不是效率工具，反而会成为一个新的数据外泄面。 最小使用路径 原文提供了 Python SDK 片段，但没有给出完整的安装命令、账号开通成本或端到端配置文件。以下是最小路径，适合做试用，别把它当生产部署清单。 1. **确认前置条件**：你已经拥有 Microsoft Foundry 访问权限，可以创建 Foundry project，能部署模型，并且具备 Azure 身份认证能力。示例代码中使用的是 DefaultAzureCredential。 2. **创建项目**：打开 Microsoft Foundry portal，创建 project，部署一个可用于 Agent 的模型，然后创建 hosted agent。原文建议从 portal、Quickstart 或 Microsoft Learn 课程开始。 3. **创建 Toolbox version**：把 WebSearchTool、ToolboxSearchPreviewTool 和 MCPTool 都放进同一个 toolbox。MCPTool 的示例字段包括 server_label、server_url、require_approval 和 project_connection_id。 4. **为工具补充细节**：为每个工具补全描述、命名和权限连接。高频或关键工具可以考虑 pin；容易被误解的内部工具需要额外补充上下文；敏感工具则必须配置连接权限和审批策略。 5. **记录测试结果**：在测试 run 中记录三类关键结果：tool_search 返回的候选是否准确，call_tool 调用是否成功，Guardrails 是否能拦截不合规的输入或输出。因为原文没有提供完整的命令或 API 示例，人工验证这个步骤不能跳过。 可以替代的工作流 Toolboxes 能替代的，是“手动维护工具清单”那种吃力不讨好的做法。过去很多团队会在 Agent prompt、配置文件或代码里写死一组工具，新增一个内部 API 就要改一次描述、权限和调用逻辑。工具少的时候还能勉强忍受，工具一多，重名、描述不准、权限遗漏、schema 占满上下文这些问题就会一起爆发。 Routines 替代的是轻量触发层。它允许你声明一个 schedule 或 event，再指定 Agent action，剩下的调用、权限、连接和 run history 全由 Foundry 处理。它适合 daily summaries、one-time reminders、periodic checks 这类简单自动化。但如果你的场景需要分支、多 Agent 协作、人类审批或复杂状态机，原文说得非常明确：请使用 workflow，不要硬把 Routines 当成编排系统来用。 验收与失败边界 - **验收指标**：在一组真实任务里，统计 Tool Search 的 top-k 命中率、错误工具调用率、平均每轮输入 token，以及 run history 中的失败重试比例。 - **权限边界**：在接入 Work IQ、Fabric IQ、MCP server 或 SaaS connector 之前，务必确认 project_connection_id、组织权限、数据访问策略和 Guardrails 是否覆盖了输入与输出。 - **隐私边界**：Microsoft 365、Power BI semantic models、Jira、Confluence 等系统都包含高敏数据。不能用模型回答“看起来很合理”来替代审计。 - **失败条件**：如果工具描述混乱、命名没有规范、Tool Search 经常漏召回，或者 call_tool 错误无法追踪，那就说明这套方案还不适合扩大到更多团队共用。 - **预览风险**：Skills、Work IQ、Fabric IQ、Browser Automation、Tool Search、Managed MCP servers、Routines 目前大多处于 preview 状态。投产前，必须单独验证稳定性、区域可用性和权限模型。 这事意味着什么 对于开发者而言，Toolboxes 把 Agent 的工具层从“写几个函数给模型选”，推进到了“建立一个可治理的运行时工具目录”。这意味着 Agent 项目的重心，正从 prompt 技巧转向工具资产管理：谁来注册工具、工具怎么描述、什么时候废弃、哪些必须审批、哪些始终暴露、哪些只能检索后调用——这些都成了核心问题。 对于小团队选型来说，这件事的取舍也很现实。如果团队已经深度使用 Azure、Microsoft 365、Fabric、Power BI 和 Foundry，那么 Toolboxes 能把工具、数据和 run control 放在同一个平台里，减少自己搭建胶水层的成本。如果团队主要在 LangChain、OpenAI Assistants、自托管 MCP 或非微软云上工作，就要警惕生态绑定和迁移成本。 真正值得试的点，不是“又多了几个 preview 功能”，而是 Tool Search 这种意图检索式的工具暴露方式，能不能实实在在地降低上下文成本、减少错选工具。 读者决策 - **今天可以试的人**：已经在 Microsoft Foundry 里构建 hosted agent，而且工具数量开始超过十几个，还接入了 MCP Server 或企业数据连接的开发团队。 - **应该先观望的人**：只做个人自动化、工具数量很少，或者没有 Azure / Microsoft 365 数据权限治理需求的团队。 - **试用时只看三项指标**：Tool Search 是否能稳定找对工具；每轮 token 成本是否明显下降；Guardrails 和 run history 是否能解释失败、越权和敏感输出。 最后再提醒一句：原文没有给出完整安装步骤、定价和生产 SLA。所以，不要直接把 preview 能力放进关键链路。更稳妥的做法，是在 Foundry portal 跑一个受控 demo，用 20 到 50 个工具模拟一个真实目录，跑一遍流程，再决定是否要替换现有的工具注册层。