Microsoft Foundry

为什么选择 Azure AI Foundry？

虽然在目前的微软官方文档中已更名为 Microsoft Foundry，但许多开发者和采购决策者仍习惯搜索旧名 Azure AI Foundry。两者的核心理念一致：提供一个企业级治理的微软云平台，用于构建 AI 应用和 Agent，无需开发者自行拼凑零散的模型 API、向量工具、评估脚本和部署基础设施。

选择 Foundry 的最强理由是微软生态的向心力。如果您的组织已经在使用 Azure、Entra ID、Microsoft 365、GitHub、Visual Studio Code、Azure Monitor、Azure 网络和微软安全控制，Foundry 为 AI 团队提供了一条完全契合现有运营模式的路径。

它并非 AI 代码编辑器的替代品，而是 AI 应用背后的支撑平台：团队在这里发现模型、部署端点、编排 Agent、连接工具、将响应关联至企业数据（Grounding）、运行评估、观测质量，并在生产发布前应用治理策略。

核心工作流

典型的工作流始于 Foundry 门户或目录中的模型探索。开发者可以对比候选模型，在游乐场（Playground）测试提示词，部署模型，然后通过 Azure SDK、REST API 或兼容 OpenAI 的模式从应用程序代码中调用。

随着应用的成熟，工作流通常会扩展到单一模型调用之外。团队会加入私有数据的检索、定义 Agent 工具、构建动作组、追踪 Agent 行为、运行评估、配置安全控制，并监控生产环境中的质量和 Token 使用情况。这种从提示词测试到生命周期管理的转变，正是 Foundry 的价值所在。

针对代码 Agent 工作流，微软正在推动 MCP（模型上下文协议）和 VS Code 的集成。Foundry MCP Server 允许兼容的客户端通过自然语言工具与 Foundry 资源交互，而 Visual Studio Code 的 Foundry Toolkit 则帮助开发者在本地和微软 AI 技术栈中协同工作。这并不会让 Foundry 变成 IDE，但确实让它在开发环境中更易于触达。

适用场景

Foundry 非常适合构建企业级 Copilot、客户支持 Agent、内部知识助手、文档搜索、销售赋能工具、代码与数据助手、受监管的工作流自动化、呼叫中心摘要、多模态分析以及基于业务数据的 RAG 应用。

此外，当公司希望在不逐一谈判集成协议的情况下对比不同模型供应商时，Foundry 也非常有用。团队可以在统一的 Azure 治理模型下，评估来自 OpenAI、Anthropic、Meta、Mistral、DeepSeek、xAI、Hugging Face、Microsoft 等系列的模型。

Foundry Local 增加了另一个使用场景：由于隐私、低延迟、离线运行或降低云端推理成本等需求而需要端侧 AI 的应用。这使得该平台不仅适用于云端托管的企业 Agent，也适用于需要本地 AI 功能的 Windows 和跨平台应用程序。

竞品对比

与 Amazon Bedrock 相比，选择通常取决于云战略。AWS 原生团队可能更倾向于 Bedrock，因为它契合 IAM、VPC、CloudWatch 等 AWS 基础设施。而微软原生团队则更青睐 Foundry，因为它与 Azure、Entra ID、Microsoft 365、GitHub、VS Code 及其治理体系高度一致。

与 Google Vertex AI 相比，Foundry 与微软的企业生产力生态及 Azure/OpenAI 的合作关系绑定更紧，而 Vertex AI 则更适合已深度投入 Google Cloud、Gemini、BigQuery 及谷歌广义机器学习平台的团队。

与直接使用 OpenAI API 或 Anthropic API 相比，Foundry 增加了云治理和模型管理层。直接使用供应商 API 可能更简单，且能更早体验原生特性，但在涉及采购、审计、私有网络、合规策略和企业级控制时，Foundry 更具吸引力。

与 Hugging Face Inference Endpoints、Fireworks AI 或 Together AI 相比，Foundry 功能更广但也更重。对于开源模型的推理实验或特定模型托管，上述平台可能响应更快，但当 AI 系统必须融入企业级 Azure 架构和治理时，Foundry 是更好的选择。

最佳配置建议

理想的 Foundry 配置应从任务分类开始。不要假设一个模型能处理所有场景。提取、对话、推理、编码、嵌入（Embedding）、重排序（Reranking）、图像生成、摘要和后台批处理任务，可能各自需要不同的模型和部署方案。

对于 RAG，检索质量应被视为核心产品问题。数据权限、分块策略、元数据、索引、引文、连接器选择和评估数据集，往往比切换类似的系列模型更重要。

对于 Agent，应从定义明确的小型工具和可观测的工作流开始。工具权限、身份验证、审批步骤和回滚计划应在模型之外进行设计。MCP 工具功能强大，但应像对待任何生产集成一样进行治理，因为它们会将真实系统暴露给 AI 驱动的操作。

在成本控制方面，团队应在发布前进行使用量建模。Token 消耗、模型路由、预留容量、工具调用、向量检索、托管 Agent 计算、评估作业和监控都会产生费用。从项目初期开始，利用 Azure 成本管理并明确项目归属至关重要。

迁移建议

从仅使用 Azure OpenAI 的应用迁移到 Foundry 通常比较容易，因为身份验证、计费和模型访问模式已经是 Azure 导向的。主要的转变在于操作层面：应用将获得此前可能需要自定义构建的评估、Agent、RAG 工具、提示词管理和治理工作流。

从直接使用 OpenAI 或 Anthropic API 迁移需要仔细的重新测试。即使模型系列听起来很熟悉，通过云平台调用时，请求格式、模型版本、可用性、流式传输行为、配额、延迟、内容过滤和响应行为都可能存在差异。

从 Amazon Bedrock 或 Vertex AI 迁移不仅仅是更换模型。团队需要将 IAM 或 Google Cloud 的控制项映射到 Azure RBAC 和 Entra ID，重建监控，审查网络，迁移数据连接器，更新评估流水线，并重新测试每一个 Agent 工具路径。

从自托管开源模型迁移到 Foundry 可以减轻基础设施负担，但可能会降低对底层服务的控制力。在切换前，请记录当前的提示词模板、批处理、缓存、GPU 假设、模型版本、安全过滤以及应用所依赖的任何自定义运行时行为。