How Microsoft Ships AI Agents at Enterprise Scale

微软如何在企业级规模部署AI代理

ByteByteGo

2026年7月13日

WorkOS MCP：通过任何AI代理管理你的认证平台（赞助内容）

调试SSO、管理用户、调整认证策略、配置品牌：所有配置任务都曾依赖只能由人类操作的界面。

WorkOS MCP服务器为代理提供与仪表板登录相同的访问权限。数百种操作可在运行时发现。通过一条OAuth命令连接，使用范围限定的令牌而非主API密钥。向代理传递营销网站的截图，并要求其匹配登录页面。如果以前需要人类完成，现在代理也能完成。

连接你的代理 →

微软运营规模庞大。目前已有超过80,000家企业基于微软Foundry平台构建，该平台用于构建、部署和运行AI代理及应用。微软自己的Copilot系统也运行在该平台上，包括服务超过2000万用户的Microsoft 365 Copilot，其一线代理的月活跃使用量同比已增长6倍。

要了解在如此规模下实际部署代理需要什么，我们采访了微软核心AI产品副总裁Marco Casalaina。他向我们展示了团队在生产环境中运行这些系统所学到的经验、面临的工程挑战，以及他对企业AI未来发展的看法。

在本文中，你将了解：

• 为什么原型代理无法在生产环境中存活

• 生产代理框架包含什么，以及微软为何认为上下文是关键

• Foundry背后的两个工程理念：检索作为子代理，以及为代理赋予独立身份和行动空间

• 微软如何通过基于评分标准的评估和自动优化循环评估生产代理

• 对其他团队的启示及未来发展方向

微软在企业级规模部署AI代理（概览）

代理进入生产环境时会发生什么

生产环境中的代理失败原因在原型中无法显现。模型本身很少是问题所在。真正崩溃的是围绕模型的一切，包括代理检索的数据、调用的工具、处理真实用户的方式，以及随着周围世界变化导致的质量漂移。今年试图部署代理的企业所面临的工程问题，与去年解决的问题已截然不同。

生产环境中的代理不仅仅是模型。系统大部分是围绕模型构建的基础设施。

要理解这一点，先从企业试图构建的内容实际发生了哪些变化开始。Marco这样描述这一转变：

我们正在走出AI的问答阶段。2026年，我们看到越来越多客户使用语音作为前端界面，因此我们也在走出AI的聊天机器人时代。

旧模式是聊天机器人。用户输入文字，代理回复文字，只能回答问题。新模式是代表用户执行实际工作的代理。它预订会议、执行分析、发送邮件、提交工单。用户可能根本不需要输入文字，因为前端可以是语音。例如，Foundry的Voice Live功能可以让团队无需重建现有文本代理，即可将其转换为语音代理。

从聊天机器人到代理的转变，从回答问题到执行任务的转变

这一转变正是使工程问题变得不同的关键所在。聊天机器人给出错误答案会带来糟糕的用户体验，而智能体采取错误行动则可能引发业务事故。对于可以上线的标准，门槛已经提高。

这就是原型与生产级智能体之间差距的体现。创建第一个原型非常简单。你甚至可以在一个下午就快速编写出一个原型。模型很聪明，测试提示词有效，演示令人印象深刻，试点版本甚至能在一周内上线。

原型中预期的请求

生产环境才是问题真正暴露的地方。真实用户会提出你始料未及的问题。智能体依赖的文档会变得过时。新的边缘情况不断出现，这些情况在你的评估数据集中从未出现。模型更新可能微妙地改变智能体的行为，直到有客户投诉才被发现。没有身份控制时，智能体会以共享系统主体身份运行，出现问题时无法追溯审计记录。没有防护机制时，它会自信地做出不应做出的陈述。没有可观测性时，你无法判断质量是提升还是下降。这些问题在原型中从未出现，但在生产环境中却全部显现。

仅在生产环境中出现而原型中从未暴露的失败案例。

当我们询问Marco，Foundry团队在大规模运行这些系统过程中学到的最重要教训是什么时，他的回答是：“模型本身和运行时框架同样重要。”

运行时框架包含模型之外的一切。运行时环境、工具、上下文检索、身份层、防护机制、评估器、部署流水线。模型在持续变化，不能像数据库版本那样对待。使用PostgreSQL时，你更换版本并期望它能正常工作。但模型并非如此。每个模型都有不同的特性，运行时框架必须进行相应调整。当Anthropic发布Claude Opus 4.8时，微软GitHub Copilot CLI团队必须重新调整他们的运行时框架并重新运行评估，才能上线该模型。

新模型发布时的运行时框架重新调整

了解406位基础设施领导者对AI准备情况的见解（赞助内容）

AI正在重塑基础设施，但方式与大多数团队预期的不同。从中获益最多的团队并不是采用速度最快的团队。他们正在利用平台、治理和自动化流水线，使AI生成的基础设施能够安全地投入生产。

《2026基础设施自动化报告》调查了406位基础设施和平台工程领导者，揭示了先驱者如何从AI中获益最多。你将了解到：

• 为什么平台工程是AI采用的关键组成部分
• 需要监控的新AI特定信号和指标，这些指标超越了传统指标
• 实现AI成熟度指数先驱者群体的5个战术步骤

下载报告

生产级智能体运行时框架包含哪些内容

如果运行时框架与模型同样重要，那么下一个问题是它到底包含什么。从底层向上分析运行时框架，可以解释每一层存在的原因以及缺少它时会发生什么问题。

生产级智能体运行时框架的五层结构

1. 推理层

最底层是推理层，这是运行时框架与模型交互的单一接口。模型本身位于运行时框架之外并保持可替换性。不同的智能体需要不同的模型，而合适的模型每隔几周就会发生变化。Foundry支持超过11,000种模型，包括来自OpenAI、Anthropic、xAI、DeepSeek和微软自身MAI系列的模型。

可替换数千个模型的推理层

2. 代理运行时

模型之上是代理运行时，它负责将模型转化为代理。运行时处理编排循环、工具调用、对话状态以及其余部分的 harness 协议。

该循环中的每个步骤都不应都经过模型处理。一个设计良好的代理只会将需要推理的部分发送给 LLM，其余工作交给普通代码处理，因为数据库查询或专用提取模型比让模型执行相同任务更快、更便宜且更可靠。

代理框架的数量持续增长，从开源选项如 LangChain、LangGraph 和 CrewAI 到供应商构建的运行时。关键原则是框架中立性。在一个框架上构建的代理应能无缝移植到另一个框架，无需重写周围的 harness。例如，Foundry 允许代理在任何框架上互换运行。

代理运行时层

3. 可观测性与治理层

一旦代理投入生产，组织就需要可观测性和治理能力。需要对所有项目中运行的每个代理有一个统一视图，包括健康评分、令牌使用情况、延迟指标、漂移检测以及跨项目汇总，使平台团队能够管理整个舰队。没有这一层，回归问题将难以察觉，成本也无法控制。在微软的案例中，这是 Foundry 控制平面，它提供跨项目的舰队可见性，并将代理遥测数据路由到 Azure Monitor 和 Application Insights，这两者已经是处理基础设施警报的同一流程。

可观测性与治理层

4. 身份层

一旦代理开始在组织内部执行实际操作，它们就需要自己的身份。它们需要自己的角色分配和审计跟踪，因为行为不当的代理必须受到与行为不当员工相同的访问控制限制。行业仍在就如何有效实现这一点达成共识，大多数平台的解决方案是扩展现有的企业身份系统，将代理视为一种新的主体类别，而不是创建并行系统。例如，Foundry 扩展了微软的企业身份平台 Entra，以这种方式对待代理。这是访问控制的基本原理；文章后面关于为代理提供行动场所的部分将展示代理在获得此类身份后能执行什么操作。

身份层。将代理视为新的主体类别

5. 上下文层

一旦代理能够可靠运行并拥有自己的身份，问题就变成了它是否能正确回答。这就是上下文层的任务。虽然 harness 中的其他每一层都旨在让代理运行，但上下文层决定了代理能否正确运行。缺乏良好上下文的代理可能会产生幻觉。它会给出答案，但答案会以难以察觉的方式出错，因为代理本身并不知道自己不知道什么。Marco 明确指出，为代理提供实际工作的必要上下文是其团队正在解决的最困难问题之一，也是微软非常重视要正确解决的问题。

上下文层

下一节将介绍微软如何构建这一上下文层。

为代理构建上下文层

为代理提供正确上下文的难点不在于上下文缺失。企业拥有大量上下文信息。真正的难点在于这些上下文信息无处不在。它们存在于SharePoint和维基的非结构化文档中，存在于OneLake和数据仓库的结构化表格中，也存在于Outlook、Teams和Word等生产力应用中。没有任何一种单一的检索方法能够覆盖所有场景。

企业上下文无处不在

过去两年的标准解决方案——经典检索增强生成（RAG）——从未被设计用于应对这种复杂性。经典RAG是一种单次检索模式。你将用户的问题进行嵌入，搜索单一索引，返回前k个结果，再传递给模型。这种方法适用于针对小型、干净语料库的简单问题。当问题存在歧义、语料库异构、正确答案需要整合多个来源，或首次检索返回空结果时，这种方法就会失效。代理无法从糟糕的检索中恢复，正如Marco所说，当RAG运行不佳时，整个代理系统也会表现不佳。单次检索的模式与问题本身完全不匹配。

经典RAG的单次检索模式

解决方案是将检索视为系统可以迭代优化的环节，就像代理迭代执行任务一样。

迭代检索

规划查询，尝试一个来源，评估结果，如果第一个来源返回空结果则尝试不同来源，并整合找到的信息。这是生产级上下文层背后的核心工程理念。

将检索视为循环：规划查询、尝试来源、评估结果并重试。

微软的解决方案是将上下文层本身作为一组服务进行交付。共有四个服务，统称为Microsoft IQ。Foundry IQ处理非结构化数据，Fabric IQ处理结构化数据，Web IQ处理实时网络检索，Work IQ处理Microsoft 365的生产力表面，包括电子邮件、日历、文档和Teams。

四个IQ服务作为无头服务

每个IQ都是一个无头服务，代理通过MCP调用它们。贯穿这四个服务的有两个工程理念。第一个是“检索作为子代理”，这是所有四个服务背后的核心模式。第二个是“为代理赋予身份和操作空间”，这是Work IQ在检索基础上特别增加的功能，使代理不仅能查找信息，还能执行操作。

检索作为子代理

生产级上下文层的技术理念是将检索封装在代理循环中。不再是单一函数调用针对单一索引执行一次查询并返回前k个结果，检索本身成为一个独立的小型代理。它规划需要查询的来源，执行查询，将结果与原始问题进行评估，并决定是返回结果、优化查询还是尝试其他来源。检索不再只是简单的查找，而是能够从糟糕首次尝试中恢复的迭代过程。

目前生产环境中最清晰的示例是Foundry IQ。下图展示了代理调用它时的工作流程。

Foundry IQ的检索循环

最后一步是最值得关注的。当迭代耗尽时，Foundry IQ会返回结构化的“我不知道”而非强行给出答案。经典RAG没有备用方案，模型会生成看似合理的幻觉内容。Foundry IQ则向调用代理发送明确的检索失败信号，代理可以据此采取行动，而非接受难以察觉的错误答案。

到目前为止，这还只是关于数据的内容。同样的循环也适用于工具。拥有少量工具的代理可以在其提示中列出所有工具，但拥有数十个工具的代理则无法做到这一点。列出所有工具会消耗每次调用的上下文空间，并因扫描列表而减慢模型速度。解决方案与代理式检索类似。代理不必暴露所有工具，而是搜索合适的工具，获取后调用。Foundry 将此功能称为工具搜索，这也是 OpenAI 和 Anthropic 的代理所采用的模式。因此，同样的检索循环不仅引入知识，也引入能力。代理在需要时即时查找所需内容，而非提前携带所有信息。

其他 IQ 产品也依赖这一模式。Fabric IQ 在结构化数据上运行代理式检索，循环过程针对 OneLake 表和 Fabric 数据代理规划查询，而非针对文本索引。Web IQ 在开放网络上以亚秒级延迟运行相同循环。将检索作为子代理的理念是所有产品的架构共性。

身份与行动场所

检索为代理提供了正确的信息。但仅有信息本身无法完成任务。即使代理知道客户不满，仍需撰写道歉邮件并退款。要负责任地完成这些操作，代理需要两样东西：组织可见的身份，以及可以采取行动的界面。

这个身份来自前面身份层的访问控制原语。没有它，所有操作都将是匿名的，或以用户借出身份的名义进行。日志会显示“AI 做了这件事”，审计追踪也失效，这对任何受监管的企业来说都是不可行的。解决方案是将代理视为独立的主体类别，与员工位于同一目录中，拥有自己的角色分配和审计追踪。行为不当的代理将受到与行为不当员工相同的访问控制限制。

操作界面使身份具有实际意义。如果代理在目录中存在但无法发送邮件或更新文档，就无法执行工作。操作界面必须暴露组织内部人员已执行的相同操作，使代理能够读取收件箱、发送消息、安排会议和编辑共享文档。在微软的案例中，身份通过 Entra 管理，操作界面是 Work IQ。现在代理可以拥有命名的目录条目，在组织架构图中向经理汇报，并拥有自己的邮箱。

拥有独立身份和操作界面的代理

身份决定了代理可以达到的范围。防护措施则限制了代理在采取行动后所允许通过的内容。聊天机器人只需筛选用户的提示和模型的回复即可。而代理需要防御的范围更广，因为它还会读取工具输出和检索到的文档，这些内容中可能包含用户从未输入过的指令。这就是间接提示注入的工作方式。例如，像“忽略之前的指令”这样的语句可能隐藏在代理摄入的文档中，代理会将其视为命令。解决方案是将防护措施转移到工具边界，不仅要筛选模型的输入和输出，还要筛选工具的输入和输出。在微软的案例中，Foundry在工具调用和工具响应层级运行自己的分类器，这在模型本身已有的安全措施之上。由于这些控制措施位于共享的工具层而非每个代理内部，团队只需配置一次，所有使用这些工具的代理都会继承这些设置，而无需逐个代理重新实现相同的防护措施、凭证和策略。

对于任何构建此类系统的团队来说，关键在于将检索、操作以及围绕这两者的防护措施设计为第一层级的架构。检索应是一个能够从不良查询中恢复的循环，操作应在组织认可的身份下运行，并附带匹配的审计追踪，而防护措施应位于工具边界而非仅限于模型边缘。

评估生产环境中的代理

上下文决定了代理能否在生产环境中存活的一半因素。评估则是另一半。即使代理拥有正确的上下文，随着流量模式的变化，它仍可能偏离轨道、出现退化或以新的方式失败。评估的作用就是闭合这个循环。它是一个能够告知你何时发生变更的系统，也是一个能够告知你代理是否按预期执行任务的系统。

评估框架

持续评估

大多数团队将评估视为上线前的检查项。他们运行一次测试套件，看到通过就上线。这种方法对传统软件有效，因为传统软件具有确定性。但代理并非如此。相同的提示针对相同的模型可能产生不同的响应，模型本身会在提供商发布更新时发生变化，代理检索的数据每天也会变化。上线前的测试套件只能捕捉行为的一个快照，而非对其的保证。

持续评估

持续评估通过针对实时流量运行，采样真实用户交互，根据团队定义的标准进行评分，并将结果反馈到已处理基础设施事件的相同可观测性管道中，从而弥补这一差距。在Foundry中，这一功能已内建。当质量下降时，团队会从与服务中断时通知他们的相同告警系统中发现问题。这些评估也可以更早地运行，作为部署管道中的门禁，防止退化版本上线。

基于评分标准的评估

持续评估能告知你何时发生了变化。更困难的问题是判断代理的行为本身是否正确。目前大多数评估系统依赖于通用指标，如相关性、连贯性和任务完成度。这些指标虽然有用，但存在上限。正如Marco所说，通用指标能告诉你代理是否工作，但无法告诉你代理是否正确工作。

考虑一个帮助用户预订餐厅预订的代理。这是从一开始就出现的错误操作失败的典型例子。一个通用指标可以告诉你代理成功调用了预订工具并返回了预订信息，但它无法告诉你代理在过程中是否做了正确的事情。当用户只说“明天两人桌”时，代理是否询问了用户想要的具体时间？在声称6点有空位之前，代理是否检查了预订系统以确认桌子确实可用？没有这些检查而创建的预订在通用指标上是技术上的成功，但在用户眼中却是失败。

餐厅代理的评分标准检查

弥补这一差距的方法是根据代理应表现出的具体行为进行评估，而不仅仅是通用指标。常见的方法是基于评分标准的评估。评分标准是一种具体、与用例相关联的检查，它会针对代理应执行的某项操作提出一个是非问题。对于餐厅代理，评分标准可能如下：

• 当用户给出部分请求时，代理是否会询问缺失的信息？
• 在声称预订可用之前，代理是否会根据预订系统验证可用性？
• 在完成预订后，代理是否会将详细信息确认回用户？

在实践中，评估系统会将代理运行在一组测试交互中，对每次交互的每个评分标准进行评分，并汇总结果。团队不仅能看到代理是否正常工作，还能看到代理在哪些具体行为上正确，哪些行为上错误。评分标准比通用指标更有效，因为负责代理的团队编写了这些标准，因此它们反映了代理实际应执行的操作。

手动编写评分标准并不是唯一途径。Foundry可以通过阅读代理的配置和生产追踪来起草评分标准，根据代理实际行为提出值得评分的维度。团队仍然拥有并编辑结果，但起点是真实流量而非空白页面。

评分标准如何评分交互并指导下一步

微软已将其基于评分标准的评估功能集成到其Agent Optimizer套件中。Optimizer处理评分标准的循环部分，并通过在评分标准失败时自动改进代理本身，使评分标准具有可操作性。它可以重写系统提示，使缺失行为更加明确，调整代理使用工具的方式，或改变代理优先考虑的来源。

它调整的范围不仅限于提示。它还可以更换底层模型并调整代理的技能。与其一次测试一个修复方案，它会并行生成多个候选方案，根据评分标准对每个方案进行评分，并将最佳方案作为新代理版本推广。现在，衡量代理的同一循环也改进了它。它成为一个自我改进的循环。

自我改进的循环

对于任何在生产环境中运行代理的团队，评估并不是一个结束的阶段。它是一个与代理并行运行的层级，随着代理职责的变化而演变评分标准，并通过一个优化器将回归问题转化为可操作的更改，而不是手动修复。团队的工作不再是在第一天就写出完美的代理，而是随着周围世界的变化持续确保代理的诚实性。这就是生产AI的实际样子，也是Foundry构建的框架的第二部分。

其他团队的关键教训

框架的重要性不亚于模型本身，这是贯穿整个对话的核心线索。上下文难以处理、评估难以推进、原型无法通过生产环境验证的根本原因在于：大多数团队将“围绕模型的工作”视为次要环节，但实际上这些工作决定了代理能否真正运行。将框架视为后期添加的模块，是企业级代理始终无法落地生产的最常见原因。

对于自主构建上下文层的团队而言，这条经验的实践意义在于：即使不使用Foundry平台，也必须认真对待本文前文提到的两个架构理念。检索功能应具备自主性，对检索层的调用应隐藏一个由规划器驱动的多源、可重试的子代理，该子代理能够在检索失败时自动恢复而非直接崩溃。执行操作的代理应具备组织可识别的身份，并拥有能通过合规审查的审计追踪。这些功能均可在任意平台上实现。

下一步

Marco关注AI未来的方式是观察未来一年内即将实现的可能，而非十年后的远景。他关注某个能力何时从研究演示或开发者工具转变为普通人可使用的功能。他最关注的模式是：原本需要CLI编码代理完成的能力，最终将向所有人开放。

这种模式在过去八个月中已逐步显现。曾经需要开发者在编码代理内部手动实现的功能（如根据自然语言生成文档、管理日历或运行自定义工作流），如今已出现在各类工具中。最初作为编码代理概念的“技能”功能，现已集成到Excel中用于财务分析和私募股权工作流。Marco的预期是，这种趋势将在未来一年加速推进，更多原本仅限开发者的功能将进入通用领域。

他预见的更大变革是具备自我优化能力的代理。这种架构需要全局和局部记忆、技能模块，以及能够使代理自动保留用户学习成果并加以应用的行为机制。Copilot CLI新推出的Chronicle功能就是早期尝试。如果Marco在创建Git仓库后立即推送到GitHub，Chronicle会学习这一习惯并自动执行，无需用户提示。Marco的判断是，将这种组合应用到企业已部署的代理系统中，将是明年最值得关注的进展。这不是科幻小说，而是又一批能力进入通用领域的自然演进。