## 开场判断

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，由 Foundry 处理调用、权限、连接和 run history。适合 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 个工具模拟真实目录，再决定是否替换现有工具注册层。


Microsoft Foundry Toolboxes 真正解决的麻烦，不是“Agent 能不能调用工具”，而是工具一多以后，Agent 怎么找到正确工具、怎么受权限约束、怎么避免每轮对话都把一长串工具 schema 塞进模型上下文。这个问题在 5 个工具时不明显，到了 50 个、200 个工具就会变成成本、稳定性和治理问题。

Microsoft Foundry Toolboxes如何瘦身Agent工具上下文

开场判断 Microsoft Foundry Toolboxes 真正解决的麻烦，不是“Agent 能不能调用工具”，而是工具一多以后，Agent 怎么找到正确工具、怎么受权限约束、怎么避免每轮对话都把一长串工具 schema 塞进模型上下文。这个问题在 5 个工具时不明显，到了 50 个、200 个工具就会变成成本、稳定性和治理问题。 短期看，它更适合已经

人工智能

开发工具

云计算

Microsoft Foundry Toolboxes解决多工具Agent治理难题，通过ToolSearch智能检索工具、权限约束和上下文优化，降低50+工具场景下的调用成本。核心功能包括工具目录管理、WorkIQ组织数据集成和Guardrails安全管控，适合Azure/M365生态团队提升Agent稳定性，避免工具泛滥导致的数据泄露风险。

敏感数据

数据流

Agent

SaaS

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Microsoft Foundry Toolboxes解决多工具Agent治理难题，通过ToolSearch智能检索工具、权限约束和上下文优化，降低50+工具场景下的调用成本。核心功能包括工具目录管理、WorkIQ组织数据集成和Guardrails安全管控，适合Azure/M365生态团队提升Agent稳定性，避免工具...

Microsoft Foundry Toolboxes如何瘦身Agent工具上下文-腾讯云开发者社区-腾讯云

Microsoft Foundry Toolboxes如何瘦身Agent工具上下文

Microsoft Foundry Toolboxes如何瘦身Agent工具上下文

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐