微软如何大规模投产数千个AI代理（18分钟阅读）

# 微软如何以企业级规模交付AI代理 来源：https://blog.bytebytego.com/p/how-microsoft-ships-ai-agents-at [](https://go.bytebytego.com/WorkOS_071326CTA) 调试SSO、管理用户、调整认证策略、配置品牌样式：过去，每一项配置任务都隐藏在只能由人类操作的UI背后。 WorkOS MCP (https://go.bytebytego.com/WorkOS_071326MCP) 服务器赋予了代理与你的仪表盘登录相同的访问权限。数百个操作，运行时即可发现。通过OAuth一条命令即可连接，使用范围限定的令牌而非主API密钥。截一张你的营销网站截图，让代理去匹配登录页。如果以前人类能做的事，现在代理也能做。 连接你的代理 → (https://go.bytebytego.com/WorkOS_071326CTA) 微软的运营规模极其庞大。如今，超过8万家企业基于 Microsoft Foundry 进行构建，这是微软用于构建、部署和运行AI代理及应用的公司级平台。微软自家的Copilot也运行在同一平台上，其中包括Microsoft 365 Copilot，它本身就服务于超过2000万用户，并且第一方代理的月活跃使用量今年迄今增长了6倍。 为了了解在这样的规模下交付代理到底需要什么，我们采访了微软Core AI产品副总裁 Marco Casalaina (https://www.linkedin.com/in/marcocasalaina/)。他向我们介绍了他的团队在生产环境中运行这些系统所积累的经验、随之而来的工程挑战，以及他认为企业AI的下一个发展方向。 在本文中，你将了解到： - 为什么一个原型代理无法在生产环境中存活 - 生产级代理框架（Harness）包含什么，以及为什么微软认为上下文（Context）是关键 - Foundry 背后的两个工程理念：将检索作为子代理，以及赋予代理独立的身份和行动场所 - 微软如何通过基于评分卡（Rubric）的评估和自动改进循环来评估生产级代理 - 对其他团队的经验教训，以及未来展望 [](https://substackcdn.com/image/fetch/$s_!8qaR!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F7a236f08-3b9b-4aee-8eff-1efa2f8f4705_1695x2048.png)微软如何以企业级规模交付AI代理（高层概览） 生产级代理失败的原因在原型中是看不到的。模型很少是问题所在。真正出问题的是模型周围的一切，包括代理检索的数据、它调用的工具、它与真实用户交互的方式，以及随着周围世界变化而出现的质量漂移。今年试图交付代理的企业遇到的是一个与去年截然不同的工程问题。 [](https://substackcdn.com/image/fetch/$s_!QIhS!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fdb83fbd3-eedb-492a-8026-7b59f3a6be2d_2006x1508.png)生产级代理不仅仅是模型。系统的大部分是围绕模型构建的机制。 要理解这一点，我们首先需要看看企业试图构建的东西实际上发生了什么变化。Marco 这样描述这种转变： > 我们正在告别AI的问答阶段。到2026年，我们预计将有大量客户使用语音作为前端，因此我们也在告别AI的聊天机器人时代。 旧形态是聊天机器人。用户输入，代理回复，它只能回答问题。新形态是能够代表用户执行有效工作的代理。它预订会议、运行分析、发送邮件、提交工单。用户甚至可能不需要打字，因为前端可以是语音。例如，Foundry 的 Voice Live 可以让团队将现有的文本代理转换为语音代理，而无需重建。 [](https://substackcdn.com/image/fetch/$s_!ocaR!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F1f264bc6-4089-4e45-a021-af25f6db6ae7_2048x725.png)从聊天机器人到代理，从回答问题到执行工作的转变 正是这种转变使得工程问题变得不同。聊天机器人返回错误答案是一种糟糕的体验。代理采取错误行动则是一次业务事故。判定“足够好”以交付的标准已经改变了。 这就是原型代理和生产级代理之间的差距所在。第一个原型很容易。你可以在一个下午用“氛围编码”（vibe-code）搞定。模型很智能，你的测试提示词运行良好，演示令人印象深刻，原型在一周内就能上线。 [](https://substackcdn.com/image/fetch/$s_!BYut!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F15775bb1-e15c-4041-ae92-2b64c2e8ca49_1908x1832.png)原型中的预期请求 生产环境才是问题暴露的地方。真实用户会提出你未预料到的问题。代理依赖的文档会过时。新的边缘情况会出现，而这些从未出现在你的评估数据集中。模型更新会微妙地改变代理行为，直到客户投诉才被发现。没有身份控制，代理会以共享系统主体的身份运行，出现问题时没有审计追踪。没有护栏，它会自信地说出不该说的话。没有可观测性，你无法判断质量是提升还是下降。这些问题没有一个出现在原型中。但它们全部出现在生产环境中。 [](https://substackcdn.com/image/fetch/$s_!LMuz!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F370f0b98-544e-455e-946a-255a9a705e88_1771x2048.png)仅在生产环境中出现、不会在原型中出现的失败。 当我们问 Marco，Foundry 团队在大规模运行这些系统中学到的最重要的一课是什么时，他的回答是：“框架（Harness）和模型同样重要。” 框架就是模型周围的一切：运行时、工具、上下文检索、身份层、护栏、评估器、部署流程。模型在不断变化，你不能像对待数据库版本那样对待它们。使用 Postgres，你更换版本，基本可以预期它能直接工作。模型则不然。每个模型都有不同的属性，框架必须随之调整。当 Anthropic 发布 Claude Opus 4.8 时，微软的 GitHub Copilot CLI 团队不得不重新调整他们的框架并重新运行评估，然后才能交付。 [](https://substackcdn.com/image/fetch/$s_!G_gv!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F2167655c-e015-4281-82e0-6a29f19e770f_2048x822.png)新模型发布时的框架重新调整 [](https://go.bytebytego.com/Spacelift_071326) AI 正在重塑基础设施，但方式与大多数团队的预期不同。从中获益最多的团队并非采用速度最快的。他们正在利用平台、治理和自动化流水线，使AI生成的基础设施能够安全地投入生产。 《2026年基础设施自动化报告》(https://go.bytebytego.com/Spacelift_071326) 调查了406位基础设施和平台工程领导者，揭示了先驱者如何从AI中获益最多。你将了解到： - 为什么平台工程是AI采用的关键组成部分 - 除了传统指标之外，需要监控的新AI特定信号和指标 - 达到AI成熟度指数先驱者群体的5个战术步骤 下载报告 (https://go.bytebytego.com/Spacelift_071326) 如果框架和模型同样重要，那么下一个问题就是框架里包含什么。从下往上审视框架，可以理解每一层的存在原因，以及如果缺少它会出现什么问题。 [](https://substackcdn.com/image/fetch/$s_!7-2q!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc873f4ef-54cb-461e-93bf-0722cc7a6243_1636x1508.png)生产级代理框架内的五层结构 最底层是推理层（Inference Layer），这是框架用来访问模型的单一接口。模型本身位于框架之外，并且保持可替换性。不同的代理需要不同的模型，而合适的模型每隔几周就会变化。Foundry 支持超过11,000种模型，来自 OpenAI、Anthropic、xAI、DeepSeek 以及微软自家的 MAI 系列。 [](https://substackcdn.com/image/fetch/$s_!jZU9!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F33cc4984-69a7-4f8e-bdfd-199f1d22611d_2048x1181.png)包含数千种可替换模型的推理层 模型之上是代理运行时（Agent Runtime），它将模型转换为代理。运行时负责处理编排循环、工具调用、对话状态以及框架其余部分所使用的协议。 该循环中的每一步并非都需要经过模型。一个构建良好的代理会将需要推理的部分发送给LLM，其余部分留给普通代码处理，因为数据库查询或专门构建的提取模型比让模型完成相同工作更快、更便宜、也更可靠。 代理框架的数量持续增长，从 LangChain、LangGraph、CrewAI 等开源选项到供应商构建的运行时。重要的原则是框架中立性。基于一个框架构建的代理应该能够移植到另一个框架，而无需重写周围的框架。例如，Foundry 允许代理在任何框架上互换运行。 [](https://substackcdn.com/image/fetch/$s_!vUaL!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Feaffe768-8845-4f20-b368-8757569bc700_2010x1374.png)代理运行时层 一旦代理投入生产，组织就需要可观测性和治理。需要能够统一查看跨所有项目运行的每个代理，包括健康评分、令牌用量、延迟指标、漂移检测，以及能让平台团队管理整个代理群的跨项目汇总数据。没有这一层，回归问题将不可见，成本也无法控制。在微软的案例中，这就是 Foundry 控制平面，它提供跨项目的代理群可见性，并将代理遥测数据路由到 Azure Monitor 和 Application Insights，这与处理基础设施告警的同一管道。 [](https://substackcdn.com/image/fetch/$s_!lsZ4!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3f00015a-130a-4559-9d11-9308dd6bad07_2048x801.png)可观测性和治理层 一旦代理开始在组织内采取实际行动，它们就需要有自己的身份。它们需要自己的角色分配和审计追踪，因为行为不当的代理必须受到与行为不当的员工相同的访问控制约束。业界仍在就如何做好这一点达成共识，大多数平台的答案是扩展现有的企业身份系统，将代理视为一种新的主体类别，而不是发明一个并行系统。例如，Foundry 扩展了微软的企业身份平台 Entra，以这种方式对待代理。这是访问控制的基本原语；在本文后面，“赋予代理行动场所”部分将展示代理在获得这类身份后能做什么。 [](https://substackcdn.com/image/fetch/$s_!wQG8!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F67ec5a9d-8304-4487-b3e0-0d8edbb12c3e_2048x1163.png)身份层。代理被视为一种新的主体类别 一旦代理能够可靠地运行并使用自己的身份行动，问题就变成了它是否能正确回答。这是上下文层（Context Layer）的工作。虽然框架中的每一层都是为了让代理运行，但上下文才能让它正确运行。没有良好上下文的代理可能会产生幻觉。它会给出答案，但答案会以难以检测的方式出错，因为代理本身并不知道自己不知道什么。Marco 明确指出，为代理提供它们实际工作所需的上下文，是他的团队正在解决的最困难的问题之一，也是微软相当热衷于正确解决的事情。 [](https://substackcdn.com/image/fetch/$s_!5a62!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F2e0f5006-067a-4a71-868a-a6634d94e01f_2048x906.png)上下文层 下一节是关于微软如何构建这个上下文层的。 为代理提供正确上下文的难点并不在于上下文缺失。企业拥有大量的上下文。难点在于上下文无处不在。它存在于 SharePoint 和 wiki 的非结构化文档中。它存在于 OneLake 和数据仓库的结构化表格中。它存在于 Outlook、Teams 和 Word 等生产力应用中。没有单一的检索方法能够触及所有这些上下文。 [](https://substackcdn.com/image/fetch/$s_!Cto5!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F6ee761c5-8482-496c-a2ee-3c6ee60de21b_1746x1584.png)企业上下文无处不在 过去两年的标准答案——经典检索增强生成（RAG）——从未被设计用来应对这种情况。经典 RAG 是一种一次性模式。你获取用户的问题，进行嵌入，搜索单个索引，返回前k个结果，然后传递给模型。它适用于针对小型、干净语料库的简单问题。当问题模糊、语料库异构、正确答案需要结合多个来源，或者第一次检索返回空结果时，它就会失效。代理无法从一次糟糕的检索中恢复，正如 Marco 所说，当 RAG 效果不佳时，整个代理的效果就不佳。一次性模式对于这个问题来说，形态是错误的。 [](https://substackcdn.com/image/fetch/$s_!maup!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe3ca1dbe-9867-4624-99c0-1f07da95fd93_2048x826.png)经典 RAG，一种一次性查找 解决方案是将检索视为系统可以迭代的东西，就像代理迭代任务一样。 [](https://substackcdn.com/image/fetch/$s_!_33T!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb6791c0a-9aec-43c1-aaa5-e8f8d29349bf_2048x1063.png)迭代式检索 规划查询，尝试一个来源，评估结果，如果第一个来源返回空结果则尝试不同来源，并将找到的内容组合起来。这就是生产级上下文层背后的核心工程理念。 [](https://substackcdn.com/image/fetch/$s_!X26m!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd6c6ddbf-7d4a-487f-9c61-0504b28adf05_2046x1010.png)检索作为一个循环：规划查询，尝试来源，评估，重试。 微软的解决方案是将上下文层本身作为一组服务来交付。共有四个服务，统称为 Microsoft IQ。Foundry IQ 处理非结构化数据，Fabric IQ 处理结构化数据，Web IQ 处理实时网络检索，Work IQ 处理 Microsoft 365 的生产力表面，包括电子邮件、日历、文档和 Teams。 [](https://substackcdn.com/image/fetch/$s_!fAuq!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8474bfb2-927d-4433-8c30-fd494967e2ad_2048x1319.png)四个 IQ 作为无头服务 每个 IQ 都是一个无头服务，代理通过 MCP 调用它们。有两个工程理念贯穿其中。第一个，检索即子代理（Retrieval-as-a-subagent），是所有四个服务背后的模式。第二个，赋予代理身份和行动场所，则更具体