💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

企业为什么选择管理型智能体服务

截至 2026 年 4 月 12 日，Azure AI Foundry Agent Service 是一条值得考虑的管理型路径，适合想要快速做出可运维智能体的场景。根据 Microsoft 文档，该服务已于 2025 年 5 月正式 GA，目前被定位为一个用于 build、deploy、scale 智能体的完全托管平台。

企业选择这类服务的理由很直接。如果自己搭建，就必须分别打理 Hosting、identity、observability、security；而使用管理型服务，可以更轻松地做到以下几点。

让部署模式标准化
把 tracing 和 evaluation 纳入日常运维流程
集中管理 RBAC 与 governance
在受支持的智能体类型上使用 private networking
在扩展工具时减少基础设施蔓延

另外值得注意的一点是，这项服务支持 Foundry model catalog 中的多种模型。也就是说，团队并不被局限于只使用 Azure OpenAI 模型，可以更灵活地根据成本、延迟、合规要求来调整模型选择。

如果想了解官方概览，可以从这里开始。

什么是 Microsoft Foundry Agent Service

企业应遵循的生命周期

Microsoft 把这项服务描述为 build-test-deploy-monitor 的流程。

在门户中创建智能体，或用代码构建 hosted agent
在 playground 或本地环境中测试
对每一次 model call、tool invocation、decision 都进行 trace
用 evaluation 衡量质量与回归（regression）
以 managed resource 和 stable endpoint 的形式 publish
通过 dashboard 和 metrics 监控运行状态

这套流程的价值在于，它把智能体开发从实验变成了一种运维模型。对企业来说，关键在于原型能多快转化为可审计的生产环境。

平台判断的核心在于工具

对大多数团队来说，最大的差异在于 tool ecosystem。Microsoft 文档明确列出了 tool catalog，并支持 remote MCP server，可以在门户的 Add Tools catalog 中连接这些服务器。

这一点从根本上改变了架构决策，原因如下。

不必自己搭建所有的工具集成
组织专属工具可以通过 private tool catalog 提供
可以连接 remote MCP server，并控制允许使用的工具范围
可以使用受支持的认证模式，减少自行实现凭证处理的负担

也就是说，Agent Service 并不只是运行模型的托管层，而更接近于一个同时管理工具与权限的 control plane。

有帮助的文档：

tracing、evaluation、monitoring 不是可选项

这项服务之所以有说服力，是因为 observability 被纳入了运维流程本身。Microsoft 的 lifecycle 指南明确包含 trace, evaluate, monitor 三个阶段，monitoring dashboard 会与 Application Insights 和 Azure Monitor 相连接。

在大规模部署中，这一点尤其重要，因为你必须能回答以下问题。

实际被调用的是哪些 tool
latency 出现在哪个环节
model switch 是否影响了质量
失败的原因出在 prompt、tool routing，还是 orchestration
部署之后出现了哪些 regression

从 classic release notes 也能看出这个平台的成熟过程。

2025 年 5 月 GA
2025 年 4 月 Azure Monitor metrics
2025 年 4 月基于 Azure Cosmos DB for NoSQL 的 BYO thread storage
2025 年 6 月支持 Deep Research 与 remote MCP
2025 年 8 月 Browser Automation
2025 年 5 月 connected agents 与 tracing agent threads

这段历史说明，该服务正在从演示功能演进为可运维的生产平台。

governance 与 security 才是真正的差异点

企业选择 Agent Service 的最大理由，往往不是 prompt 编写体验，而是 governance 和 security。

Microsoft 表示该服务支持以下能力。

每个智能体都有专属的 Microsoft Entra identity
通过 Azure RBAC 控制谁可以 create、invoke、manage
有助于缓解 unsafe output 和 prompt injection 的 content filters
在受支持的智能体类型上提供 private networking
用于 thread storage 的客户自有资源，例如 Azure Cosmos DB

对于必须通过安全审查的组织来说，这套组合正是区分 prototype 与 production 的关键。

其中，private networking 文档特别说明了如何用 private endpoint 保护 Foundry、Azure AI Search、Azure Storage、Azure Cosmos DB。如果部署需要网络隔离，最好尽早评估这部分内容。

为 Foundry Agent Service 设置 private networking

部署前检查清单

在把试点扩展为生产环境之前，建议确认以下事项。

确认这个智能体是否真的需要管理型托管。
从 Foundry model catalog 中按 latency、cost、compliance 标准选择模型。
决定哪些工具使用 catalog，哪些工具改用 private tool catalog 或 remote MCP server。
在正式试点之前先打开 tracing。
为质量、regression、safety 制定 evaluation 标准。
判断是否需要基于 Cosmos DB 的 BYO thread storage。
在开放外部访问之前，验证 RBAC、identity、content safety 策略。
确认要部署的 agent type 所需的 private networking 条件。
提前确定 monitoring 责任人与 incident 处理路径。

结语

Azure AI Foundry Agent Service 适合那些更关心 能否安全运维、而不只是 能否搭出一个智能体 的团队。它把模型选择、工具、tracing、evaluation、monitoring、enterprise control 整合进同一个管理型服务中，因此完全可以作为新的企业智能体项目的起点。

如果你还在 custom orchestration 和管理型 control plane 之间犹豫，官方文档明显更倾向于让新项目从管理型路径起步。