微软怎样在企业规模上交付AI智能体

调试SSO、管理用户、调整认证策略、配置品牌：每个配置任务都隐藏在一个只有人类才能操作的UI后面。

WorkOS MCP服务器为智能体提供了与您的仪表板登录相同的访问权限。数百种操作，可在运行时发现。通过OAuth一键连接，使用作用域令牌代替主API密钥。传入您营销网站的截图，并要求智能体匹配登录页面。如果以前必须由人类完成，现在智能体就可以完成。

连接您的智能体 →

微软以巨大的规模运营。超过80,000家企业现在基于微软Foundry构建，这是公司用于构建、部署和运行AI智能体和应用程序的平台。微软自己的副驾也运行在同一平台上，包括Microsoft 365 Copilot，仅此一项就服务超过2000万用户，第一方智能体的月活跃使用量同比增长6倍。

为了了解在如此规模下实际需要什么来交付智能体，我们采访了微软核心AI产品副总裁Marco Casalaina。他向我们介绍了他的团队从生产环境中运行这些系统中学到的经验、随之而来的工程挑战，以及他对企业AI未来走向的看法。

在本文中，您将了解到：

• 为什么原型智能体无法在生产中存活
• 生产智能体的“ harness”包含什么，以及为什么微软认为上下文是关键
• Foundry背后的两个工程理念：检索作为子智能体，以及为智能体提供身份和行动场所
• 微软如何通过基于评分标准的评估和自动改进循环来评估生产智能体
• 其他团队的经验教训，以及下一步计划

生产智能体失败的原因在原型中并不明显。模型很少是问题所在。出问题的是模型周围的一切，包括智能体检索的数据、调用的工具、处理真实用户的方式，以及随着周围世界变化而导致的质量漂移。今年试图交付智能体的企业正面临与去年不同的工程问题。

要理解这一点，从企业实际构建内容的变化开始会有所帮助。Marco这样描述了这种转变：

我们正在离开AI的问答阶段。在2026年，我们看到使用语音作为前端的客户数量大幅增加，因此我们也正在离开AI的聊天机器人时代。

旧的形态是聊天机器人。用户输入，智能体回复，只能回答问题。新的形态是能代表用户执行有意义工作的智能体。它预订会议、运行分析、发送邮件、提交工单。用户可能根本不需要输入，因为前端可以是语音。例如，Foundry的Voice Live允许团队将现有的文本智能体转换为语音智能体，而无需重新构建。

这种转变使得工程问题变得不同。聊天机器人返回错误答案是一次糟糕的体验。智能体采取错误行动则是一次业务事件。交付标准已经提高。

这就是原型与生产智能体之间差距拉开的地方。第一个原型很容易。你可以在一个下午内编写出一个原型。模型很聪明，测试提示有效，演示令人印象深刻，试点在一周内就能上线。

生产环境是裂缝出现的地方。真实用户提出你未曾预料的问题。智能体依赖的文档变得过时。新的边缘案例在评估数据集中从未出现。模型更新会微妙地改变智能体的行为，直到客户投诉才被注意到。没有身份控制，智能体以共享系统主体身份运行，出错时没有审计轨迹。没有护栏，它会自信地说出不该说的话。没有可观测性，你无法判断质量是在改善还是恶化。这些问题在原型中都没有出现。但它们都会在生产中出现。

当我们询问Marco，Foundry团队从大规模运行这些系统中学到的最重要教训是什么时，他的回答是：“harness与模型同样重要。”

harness是模型周围的一切。运行时、工具、上下文检索、身份层、护栏、评估器、部署管道。模型不断变化，你不能像对待数据库版本那样对待它们。使用Postgres时，你更改版本后基本上可以预期它能直接工作。模型不是这样。每个模型都有不同的属性，harness必须适应这些属性。当Anthropic发布Claude Opus 4.8时，微软的GitHub Copilot CLI团队必须重新调整他们的harness并重新运行评估，然后才能交付。

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

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

• 为什么平台工程是AI采用的关键组成部分
• 需要监控的新的AI特定信号和指标，超越传统指标
• 达到AI成熟度指数先锋段的5个战术步骤

下载报告

如果harness与模型同样重要，下一个问题是它包含什么。从下往上走一遍harness，可以显示每一层存在的原因以及如果缺少它会出什么问题。

最底层是推理层，这是harness用来访问模型的单一接口。模型本身位于harness之外并保持可互换。不同的智能体需要不同的模型，正确的模型每隔几周就会变化。Foundry支持超过11,000个模型，来自OpenAI、Anthropic、xAI、DeepSeek和微软自己的MAI系列。

模型之上是智能体运行时，这是将模型转换为智能体的部分。运行时处理编排循环、工具调用、对话状态以及harness其余部分使用的协议。

循环中的并非每一步都应该通过模型运行。构建良好的智能体只将需要推理的部分发送给LLM，其余部分留给普通代码处理，因为数据库查找或专用提取模型比让模型做同样工作更快、更便宜、更可靠。

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

一旦智能体投入生产，组织需要可观测性和治理。它需要一个单一视图来查看跨每个项目的每个智能体，包括健康评分、令牌使用、延迟指标、漂移检测，以及让平台团队能够治理整个智能体群的跨项目汇总。没有这一层，回归问题是不可见的，成本也无法控制。在微软的情况下，这是Foundry Control Plane，它提供跨项目的智能体群可见性，并将智能体遥测数据路由到Azure Monitor和Application Insights，这是已经处理基础设施警报的同一管道。

一旦智能体开始在组织内部执行实际操作，它们需要自己的身份。它们需要自己的角色分配和自己的审计轨迹，因为行为不当的智能体必须受到与行为不当的员工相同的访问控制限制。行业仍在汇聚如何做好这一点的方法，大多数平台的答案是扩展现有的企业身份系统，将智能体视为新的主体类别，而不是发明并行系统。例如，Foundry扩展了微软的企业身份平台Entra，以这种方式对待智能体。这是访问控制的基本要素；在本文后面关于给智能体提供行动场所的部分中，将展示智能体拥有这种身份后能做什么。

一旦智能体能够可靠运行并以自己的身份行动，问题就变成了它是否能正确回答。这是上下文层的工作。虽然harness中的每一层都存在以让智能体运行，但上下文是让智能体正确运行的关键。没有良好上下文的智能体可能会产生幻觉。它会给出答案，但答案会以难以检测的方式出错，因为智能体本身不知道自己不知道什么。Marco明确表示，为智能体提供实际工作所需的上下文是他团队正在解决的最困难问题之一，也是微软非常热衷于做对的事情。

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

为智能体提供正确上下文的困难部分不是上下文缺失。企业拥有大量的上下文。困难的部分是上下文无处不在。它存在于SharePoint和wiki中的非结构化文档中。它存在于OneLake和数据仓库中的结构化表格中。它存在于Outlook、Teams和Word等生产力应用中。没有单一的检索方法能够触及所有这些。

过去两年的标准答案，经典的检索增强生成（RAG），从未被设计来解决这个问题。经典RAG是一种一次性模式。你获取用户的问题，嵌入它，搜索单个索引，返回前k个结果，然后传递给模型。它适用于针对小而干净语料库的简单问题。一旦问题模糊、语料库异构、正确答案需要结合多个来源，或者第一次检索返回空，它就会失效。智能体无法从糟糕的检索中恢复，正如Marco所说，当RAG不能良好工作时，整个智能体也不能良好工作。一次性模式不适合这个问题。

解决方法是将检索视为系统可以迭代的东西，就像智能体迭代任务一样。

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

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

每个IQ都是智能体通过MCP调用的无头服务。两个工程理念贯穿其中。第一个，检索作为子智能体，是所有四个服务背后的模式。第二个，给智能体身份和行动场所，是Work IQ在检索基础上特别添加的内容，使智能体能够执行工作而不仅仅是查找信息。

生产上下文层的技术理念是将检索包装在智能体循环中。不是运行一次查询针对一个索引并返回前k个结果的单一函数调用，检索变成了自己的小智能体。它规划要查询的来源，执行查询，根据原始问题评估结果，并决定是返回结果、优化查询还是尝试不同来源。检索不再是查找，而是一个可以从糟糕的第一遍中恢复的迭代过程。

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 的赌注是，将这种组合应用于企业已经在部署的智能体类型，将是明年的故事。不是科幻小说。只是下一组能力进入普遍使用。