azure.microsoft.com/products/ai-foundry微软的业务规模极为庞大。Foundry平台是微软用于构建、部署、运行Agent的专用平台微软自研的各类copilot产品均运行在该平台之上其中Microsoft 365 Copilot就服务超2000万用户原生智能体的月活跃使用量今年以来同比增长6倍为深入了解规模化交付智能体的实际落地难点下面参考微软核心AI产品副总裁马尔科·卡萨利纳的访谈分享了团队在生产环境运维这套系统沉淀的经验、面临的工程挑战以及他对企业级AI未来发展方向的判断。原型智能体为何无法适配生产环境生产级智能体支撑架构包含哪些模块以及微软为何认为上下文是核心关键Foundry背后两大核心工程设计检索作为子智能体、为智能体赋予独立身份与执行权限微软如何通过基于评分标准的评估体系和自动迭代优化机制评测生产环境智能体技术团队的经验启示智能体落地生产环境会出现哪些问题原型阶段无法暴露智能体在生产环境的故障问题。模型本身很少出问题出问题的是模型周边的整套体系包括智能体检索的数据、调用的工具、对接真实用户的处理逻辑以及外部环境变化带来的效果漂移生产级智能体远不止一个大模型系统的绝大部分组件都是围绕模型搭建的配套设施。过去的形态是聊天机器人用户输入问题机器人回复仅能完成问答。而新形态的智能体能够代替用户完成实际业务工作预定会议、执行数据分析、发送邮件、提交工单。用户甚至无需手动输入文字前端可直接采用语音交互例如Foundry的Voice Live功能团队无需重构代码就能将现有文本智能体快速改造为语音智能体从聊天机器人到智能体从问答到执行工作这一转变直接改变了工程实现的难度。聊天机器人给出错误答案只是糟糕的使用体验而智能体执行错误操作则会引发企业业务事故。产品上线的标准门槛大幅提升。这也是原型智能体和生产级智能体的核心差距。原型开发十分简单半天就能快速编码实现。模型能力充足、测试提示词效果良好、演示效果亮眼一周内就能完成试点上线原型阶段的预期需求生产环境才会暴露所有隐患真实用户会提出预料之外的问题、智能体依赖的文档数据过期、评估数据集从未覆盖的边缘场景不断出现、模型版本更新会细微改变智能体行为往往直到客户投诉才会被发现。没有身份管控智能体以共享系统身份运行出现问题后无审计日志没有安全护栏智能体会擅自输出不当内容没有可观测体系无法判断服务质量是提升还是下降。这些问题在原型阶段都不会出现却都会在生产环境集中爆发。在生产环境暴露、原型阶段从未出现的故障当我们问及Foundry团队规模化运维系统收获的最重要经验时他的答案是配套支撑架构和模型同等重要支撑架构涵盖模型之外的所有组件运行时环境、工具调用、上下文检索、身份层、安全护栏、评估模块、部署流水线。模型迭代频繁不能像数据库版本一样固化管理。Postgres数据库升级版本后基本可以直接稳定运行但模型不一样每个模型特性不同支撑架构必须针对性适配。例如Anthropic发布Claude Opus 4.8版本后微软GitHub Copilot CLI团队必须重新调优支撑架构、重新完成全量评估才能上线新版本模型新版本发布后的支撑架构重调优化What’s in a Production Agent Harness既然支撑架构和模型同等关键那么这套架构具体包含哪些模块自下而上拆解各层级就能理解每个模块的存在意义以及缺失模块会引发的问题。harness的五层结构1. 推理层最底层是推理层是支撑架构对接各类模型的统一接口。模型本身独立于支撑架构之外支持灵活替换。不同智能体适配不同模型最优模型每隔几周就会更新。Foundry平台兼容超11000个模型涵盖OpenAI、Anthropic、xAI、DeepSeek以及微软自研的MAI系列模型。支持数千款可替换模型的推理层2. 智能体运行调度循环并非所有步骤都交由大模型处理。设计优良的智能体只会把需要逻辑推理的内容发送给大模型其余工作交由常规代码完成数据库查询、专用抽取模型的执行效率远比让大模型完成同类任务更快、成本更低、稳定性更强。当前智能体框架层出不穷核心原则是框架无侵入性基于某一框架开发的智能体无需重构周边支撑架构就能迁移到其他框架运行。例如Foundry支持智能体在任意框架间无缝切换3. 可观测与治理层智能体上线生产后企业需要完善的可观测能力与治理体系。平台需要统一管控所有项目下运行的智能体实现健康度评分、令牌消耗统计、延迟指标监控、漂移检测以及跨项目数据汇总方便平台团队统一管理智能体集群。缺失该层级服务退化问题无法感知成本也会失控。微软侧的对应组件是Foundry控制平面实现跨项目集群可视化同时将智能体遥测数据接入Azure Monitor和Application Insights复用现有基础设施告警流水线。可观测与治理层4. 身份层当智能体开始在企业内部执行真实操作就必须拥有独立身份。智能体需要专属的角色权限分配和审计日志行为异常的智能体需要和违规员工一样受到访问权限约束。行业目前仍在探索最优落地方案主流平台的共识是复用现有企业身份体系将智能体划为全新的主体类型而非搭建独立的并行身份系统。例如Foundry基于微软企业身份平台Entra将智能体纳入身份体系管理。这是访问控制的基础单元本文后续“为智能体赋予执行场景”章节会详细介绍智能体拥有身份后的具体操作能力。身份层智能体作为全新的主体类型5. 上下文层当智能体可以稳定运行、凭借独立身份执行操作后核心问题就变成了能否给出准确答案这正是上下文层的核心价值。支撑架构的其他层级保障智能体可以运行而上下文层保障智能体正确运行。缺少优质上下文的智能体极易产生幻觉即便给出回复错误也难以识别因为智能体本身无法感知自身的知识盲区。马尔科明确表示为智能体提供落地工作所需的上下文是团队攻克的最难课题之一也是微软重点打磨的核心能力。上下文层微软如何为智能体搭建上下文层为智能体匹配精准上下文的难点不在于企业缺少数据恰恰相反企业拥有海量数据但数据分散在各个系统SharePoint、知识库的非结构化文档OneLake、数据仓库的结构化数据表Outlook、Teams、Word等生产力应用。没有单一检索方式可以覆盖全部数据源。企业上下文数据分散在各个系统过去两年的主流方案——传统检索增强生成RAG本身就无法适配这类复杂场景。传统RAG是一次性检索模式接收用户问题、向量化处理、检索单一索引库、返回top-k结果送入模型。该方案仅适用于小型干净语料库的简单问答一旦问题存在歧义、数据源异构、答案需要多源信息整合、首次检索无结果这套方案就会失效。智能体无法从检索失败中恢复正如马尔科所说RAG效果不佳时整个智能体的运行都会受影响一次性检索的模式本身就不适配复杂业务场景。传统RAG一次性检索查询解决方案: 将检索设计为可迭代的流程和智能体执行任务的迭代逻辑保持一致。迭代式检索规划查询语句、尝试调用数据源、评估检索结果、首次检索无结果则切换其他数据源、整合多源信息。这是生产级上下文层的核心工程思路。检索作为循环流程规划查询、调用数据源、评估结果、重试检索微软的落地方案是将上下文层拆分为四大独立服务合称Microsoft IQFoundry IQ处理非结构化数据Fabric IQ处理结构化数据Web IQ负责实时网页检索Work IQ对接Microsoft 365生产力场景涵盖邮件、日程、文档、Teams协作工具每个IQ都是通过MCP协议被智能体调用的无头服务贯穿两大核心工程设计第一检索作为子智能体是四大IQ的通用底层逻辑第二为智能体赋予独立身份与执行场景是Work IQ在检索能力之上额外拓展的能力让智能体不仅能查询信息还能完成实际业务操作。检索作为子智能体生产级上下文层的技术核心是将检索逻辑封装为智能体循环不再是单次调用接口查询单一索引并返回结果而是让检索模块本身成为一个小型智能体规划待查询的数据源、执行检索操作、对照原始问题评估结果再决定直接返回结果、优化查询语句或是更换数据源重试检索从单次查询升级为可从首次失败中恢复的迭代流程。Foundry IQ是目前落地最成熟的案例下图展示智能体调用它的完整工作流attention当迭代检索穷尽所有方案后Foundry IQ会返回结构化的“无法解答”标识而非强制生成答案传统RAG没有降级机制模型会编造看似合理的虚假内容Foundry IQ会向调用方智能体明确传递检索失败的信号方便智能体后续处理避免出现难以排查的隐性错误答案这套逻辑不仅适用于数据检索同样适配工具调用。智能体工具数量较少时可以全部写入提示词工具数量多达几十个时全量罗列会占用大量上下文空间拖慢模型检索速度。解决方案和智能检索逻辑一致不再暴露全部工具智能体按需检索匹配工具获取后再执行调用Foundry将该能力封装为工具检索功能OpenAI、Anthropic的智能体也已普遍采用该模式。也就是说支撑知识检索的同一套循环逻辑同样用于能力调用智能体在需要时才调取对应能力而非预先加载全部工具。其他IQ服务也沿用这套设计Fabric IQ针对结构化数据执行智能检索循环逻辑围绕OneLake数据表、Fabric数据智能体规划查询而非文本索引Web IQ在亚秒级延迟内对公开网页执行同款迭代检索。检索作为子智能体是所有IQ服务的通用架构设计。An Identity and a Place to Act检索为智能体获取精准信息但仅有信息无法完成完整任务。智能体知晓客户不满后仍需要撰写致歉邮件、办理订单退款。要稳妥完成这类操作智能体需要两个前提企业可识别的独立身份以及可执行操作的业务场景。身份就是前文身份层提到的访问控制基础单元。没有独立身份所有操作都是匿名执行或是借用用户身份运行审计日志只会记录“AI执行操作”无法追溯责任这对受监管的企业完全不可行。解决方案是将智能体划为独立主体和企业员工同属一个目录体系拥有专属角色权限与审计日志行为异常的智能体会和违规员工一样受到权限管控。执行场景让身份具备实际价值。仅在目录中存在、却无法发送邮件、编辑文档的智能体无法完成实际工作。执行场景需要开放企业内部员工日常使用的全部操作权限让智能体可以读取收件箱、发送消息、预定会议、编辑共享文档。微软侧由Entra负责身份管理Work IQ提供执行场景。智能体可以拥有独立的目录账号、在组织架构中归属对应负责人、拥有专属邮箱。拥有独立身份与执行场景的智能体身份限制智能体的访问范围安全护栏约束智能体执行操作后的数据流。传统聊天机器人仅需要校验用户输入和模型输出智能体的防护边界更广还需要校验工具返回结果、检索获取的文档这些内容都可能携带用户未输入的恶意指令这也是间接提示词注入的实现方式。例如文档中隐藏“忽略此前所有指令”的语句会被智能体当作指令执行。解决方案是将安全护栏迁移至工具调用边界校验工具输入与输出而非仅管控模型的输入输出微软侧的实现方式是在工具调用、工具响应层面在模型原生安全能力之上额外部署自研分类器。这套管控逻辑部署在共享工具层而非每个智能体内部团队只需一次性配置所有调用该工具的智能体都会继承对应规则无需为每个智能体重复开发护栏、凭证、权限策略。所有搭建这套体系的团队可得到的核心经验检索、操作执行、配套安全护栏都需要设计为独立的核心层级。检索采用可从失败中恢复的迭代循环操作执行依托企业认可的独立身份并配套完整审计日志安全护栏部署在工具调用边界而非仅局限于模型交互层面。生产级智能体的评估体系上下文是智能体适配生产环境的一半关键评估体系则是另一半。即便上下文配置完善随着业务流量变化智能体仍会出现效果漂移、功能退化、全新故障。评估体系是闭环管控的核心既能感知系统变化也能校验智能体是否符合预期运行标准。持续评估多数团队将评估视为上线前的一次性校验跑完测试用例、指标达标就直接上线。这套模式适用于传统确定性软件但智能体并非确定性系统。相同提示词输入同一模型都可能生成不同回复模型厂商版本更新会改变模型特性智能体检索的数据源每日都会更新。上线前的测试用例只能捕捉某一时刻的行为无法保障长期稳定运行。持续评估填补了这一缺口基于线上真实流量采样用户交互数据按照团队自定义标准打分结果接入现有基础设施告警的可观测流水线。Foundry原生内置该能力一旦服务质量退化团队会收到和服务宕机相同的告警通知。这套评估机制也可前置部署为流水线门禁在功能上线前拦截退化问题。基于评分标准的评估下篇见 微软如何交付企业级Agent
azure.microsoft.com/products/ai-foundry微软的业务规模极为庞大。Foundry平台是微软用于构建、部署、运行Agent的专用平台微软自研的各类copilot产品均运行在该平台之上其中Microsoft 365 Copilot就服务超2000万用户原生智能体的月活跃使用量今年以来同比增长6倍为深入了解规模化交付智能体的实际落地难点下面参考微软核心AI产品副总裁马尔科·卡萨利纳的访谈分享了团队在生产环境运维这套系统沉淀的经验、面临的工程挑战以及他对企业级AI未来发展方向的判断。原型智能体为何无法适配生产环境生产级智能体支撑架构包含哪些模块以及微软为何认为上下文是核心关键Foundry背后两大核心工程设计检索作为子智能体、为智能体赋予独立身份与执行权限微软如何通过基于评分标准的评估体系和自动迭代优化机制评测生产环境智能体技术团队的经验启示智能体落地生产环境会出现哪些问题原型阶段无法暴露智能体在生产环境的故障问题。模型本身很少出问题出问题的是模型周边的整套体系包括智能体检索的数据、调用的工具、对接真实用户的处理逻辑以及外部环境变化带来的效果漂移生产级智能体远不止一个大模型系统的绝大部分组件都是围绕模型搭建的配套设施。过去的形态是聊天机器人用户输入问题机器人回复仅能完成问答。而新形态的智能体能够代替用户完成实际业务工作预定会议、执行数据分析、发送邮件、提交工单。用户甚至无需手动输入文字前端可直接采用语音交互例如Foundry的Voice Live功能团队无需重构代码就能将现有文本智能体快速改造为语音智能体从聊天机器人到智能体从问答到执行工作这一转变直接改变了工程实现的难度。聊天机器人给出错误答案只是糟糕的使用体验而智能体执行错误操作则会引发企业业务事故。产品上线的标准门槛大幅提升。这也是原型智能体和生产级智能体的核心差距。原型开发十分简单半天就能快速编码实现。模型能力充足、测试提示词效果良好、演示效果亮眼一周内就能完成试点上线原型阶段的预期需求生产环境才会暴露所有隐患真实用户会提出预料之外的问题、智能体依赖的文档数据过期、评估数据集从未覆盖的边缘场景不断出现、模型版本更新会细微改变智能体行为往往直到客户投诉才会被发现。没有身份管控智能体以共享系统身份运行出现问题后无审计日志没有安全护栏智能体会擅自输出不当内容没有可观测体系无法判断服务质量是提升还是下降。这些问题在原型阶段都不会出现却都会在生产环境集中爆发。在生产环境暴露、原型阶段从未出现的故障当我们问及Foundry团队规模化运维系统收获的最重要经验时他的答案是配套支撑架构和模型同等重要支撑架构涵盖模型之外的所有组件运行时环境、工具调用、上下文检索、身份层、安全护栏、评估模块、部署流水线。模型迭代频繁不能像数据库版本一样固化管理。Postgres数据库升级版本后基本可以直接稳定运行但模型不一样每个模型特性不同支撑架构必须针对性适配。例如Anthropic发布Claude Opus 4.8版本后微软GitHub Copilot CLI团队必须重新调优支撑架构、重新完成全量评估才能上线新版本模型新版本发布后的支撑架构重调优化What’s in a Production Agent Harness既然支撑架构和模型同等关键那么这套架构具体包含哪些模块自下而上拆解各层级就能理解每个模块的存在意义以及缺失模块会引发的问题。harness的五层结构1. 推理层最底层是推理层是支撑架构对接各类模型的统一接口。模型本身独立于支撑架构之外支持灵活替换。不同智能体适配不同模型最优模型每隔几周就会更新。Foundry平台兼容超11000个模型涵盖OpenAI、Anthropic、xAI、DeepSeek以及微软自研的MAI系列模型。支持数千款可替换模型的推理层2. 智能体运行调度循环并非所有步骤都交由大模型处理。设计优良的智能体只会把需要逻辑推理的内容发送给大模型其余工作交由常规代码完成数据库查询、专用抽取模型的执行效率远比让大模型完成同类任务更快、成本更低、稳定性更强。当前智能体框架层出不穷核心原则是框架无侵入性基于某一框架开发的智能体无需重构周边支撑架构就能迁移到其他框架运行。例如Foundry支持智能体在任意框架间无缝切换3. 可观测与治理层智能体上线生产后企业需要完善的可观测能力与治理体系。平台需要统一管控所有项目下运行的智能体实现健康度评分、令牌消耗统计、延迟指标监控、漂移检测以及跨项目数据汇总方便平台团队统一管理智能体集群。缺失该层级服务退化问题无法感知成本也会失控。微软侧的对应组件是Foundry控制平面实现跨项目集群可视化同时将智能体遥测数据接入Azure Monitor和Application Insights复用现有基础设施告警流水线。可观测与治理层4. 身份层当智能体开始在企业内部执行真实操作就必须拥有独立身份。智能体需要专属的角色权限分配和审计日志行为异常的智能体需要和违规员工一样受到访问权限约束。行业目前仍在探索最优落地方案主流平台的共识是复用现有企业身份体系将智能体划为全新的主体类型而非搭建独立的并行身份系统。例如Foundry基于微软企业身份平台Entra将智能体纳入身份体系管理。这是访问控制的基础单元本文后续“为智能体赋予执行场景”章节会详细介绍智能体拥有身份后的具体操作能力。身份层智能体作为全新的主体类型5. 上下文层当智能体可以稳定运行、凭借独立身份执行操作后核心问题就变成了能否给出准确答案这正是上下文层的核心价值。支撑架构的其他层级保障智能体可以运行而上下文层保障智能体正确运行。缺少优质上下文的智能体极易产生幻觉即便给出回复错误也难以识别因为智能体本身无法感知自身的知识盲区。马尔科明确表示为智能体提供落地工作所需的上下文是团队攻克的最难课题之一也是微软重点打磨的核心能力。上下文层微软如何为智能体搭建上下文层为智能体匹配精准上下文的难点不在于企业缺少数据恰恰相反企业拥有海量数据但数据分散在各个系统SharePoint、知识库的非结构化文档OneLake、数据仓库的结构化数据表Outlook、Teams、Word等生产力应用。没有单一检索方式可以覆盖全部数据源。企业上下文数据分散在各个系统过去两年的主流方案——传统检索增强生成RAG本身就无法适配这类复杂场景。传统RAG是一次性检索模式接收用户问题、向量化处理、检索单一索引库、返回top-k结果送入模型。该方案仅适用于小型干净语料库的简单问答一旦问题存在歧义、数据源异构、答案需要多源信息整合、首次检索无结果这套方案就会失效。智能体无法从检索失败中恢复正如马尔科所说RAG效果不佳时整个智能体的运行都会受影响一次性检索的模式本身就不适配复杂业务场景。传统RAG一次性检索查询解决方案: 将检索设计为可迭代的流程和智能体执行任务的迭代逻辑保持一致。迭代式检索规划查询语句、尝试调用数据源、评估检索结果、首次检索无结果则切换其他数据源、整合多源信息。这是生产级上下文层的核心工程思路。检索作为循环流程规划查询、调用数据源、评估结果、重试检索微软的落地方案是将上下文层拆分为四大独立服务合称Microsoft IQFoundry IQ处理非结构化数据Fabric IQ处理结构化数据Web IQ负责实时网页检索Work IQ对接Microsoft 365生产力场景涵盖邮件、日程、文档、Teams协作工具每个IQ都是通过MCP协议被智能体调用的无头服务贯穿两大核心工程设计第一检索作为子智能体是四大IQ的通用底层逻辑第二为智能体赋予独立身份与执行场景是Work IQ在检索能力之上额外拓展的能力让智能体不仅能查询信息还能完成实际业务操作。检索作为子智能体生产级上下文层的技术核心是将检索逻辑封装为智能体循环不再是单次调用接口查询单一索引并返回结果而是让检索模块本身成为一个小型智能体规划待查询的数据源、执行检索操作、对照原始问题评估结果再决定直接返回结果、优化查询语句或是更换数据源重试检索从单次查询升级为可从首次失败中恢复的迭代流程。Foundry IQ是目前落地最成熟的案例下图展示智能体调用它的完整工作流attention当迭代检索穷尽所有方案后Foundry IQ会返回结构化的“无法解答”标识而非强制生成答案传统RAG没有降级机制模型会编造看似合理的虚假内容Foundry IQ会向调用方智能体明确传递检索失败的信号方便智能体后续处理避免出现难以排查的隐性错误答案这套逻辑不仅适用于数据检索同样适配工具调用。智能体工具数量较少时可以全部写入提示词工具数量多达几十个时全量罗列会占用大量上下文空间拖慢模型检索速度。解决方案和智能检索逻辑一致不再暴露全部工具智能体按需检索匹配工具获取后再执行调用Foundry将该能力封装为工具检索功能OpenAI、Anthropic的智能体也已普遍采用该模式。也就是说支撑知识检索的同一套循环逻辑同样用于能力调用智能体在需要时才调取对应能力而非预先加载全部工具。其他IQ服务也沿用这套设计Fabric IQ针对结构化数据执行智能检索循环逻辑围绕OneLake数据表、Fabric数据智能体规划查询而非文本索引Web IQ在亚秒级延迟内对公开网页执行同款迭代检索。检索作为子智能体是所有IQ服务的通用架构设计。An Identity and a Place to Act检索为智能体获取精准信息但仅有信息无法完成完整任务。智能体知晓客户不满后仍需要撰写致歉邮件、办理订单退款。要稳妥完成这类操作智能体需要两个前提企业可识别的独立身份以及可执行操作的业务场景。身份就是前文身份层提到的访问控制基础单元。没有独立身份所有操作都是匿名执行或是借用用户身份运行审计日志只会记录“AI执行操作”无法追溯责任这对受监管的企业完全不可行。解决方案是将智能体划为独立主体和企业员工同属一个目录体系拥有专属角色权限与审计日志行为异常的智能体会和违规员工一样受到权限管控。执行场景让身份具备实际价值。仅在目录中存在、却无法发送邮件、编辑文档的智能体无法完成实际工作。执行场景需要开放企业内部员工日常使用的全部操作权限让智能体可以读取收件箱、发送消息、预定会议、编辑共享文档。微软侧由Entra负责身份管理Work IQ提供执行场景。智能体可以拥有独立的目录账号、在组织架构中归属对应负责人、拥有专属邮箱。拥有独立身份与执行场景的智能体身份限制智能体的访问范围安全护栏约束智能体执行操作后的数据流。传统聊天机器人仅需要校验用户输入和模型输出智能体的防护边界更广还需要校验工具返回结果、检索获取的文档这些内容都可能携带用户未输入的恶意指令这也是间接提示词注入的实现方式。例如文档中隐藏“忽略此前所有指令”的语句会被智能体当作指令执行。解决方案是将安全护栏迁移至工具调用边界校验工具输入与输出而非仅管控模型的输入输出微软侧的实现方式是在工具调用、工具响应层面在模型原生安全能力之上额外部署自研分类器。这套管控逻辑部署在共享工具层而非每个智能体内部团队只需一次性配置所有调用该工具的智能体都会继承对应规则无需为每个智能体重复开发护栏、凭证、权限策略。所有搭建这套体系的团队可得到的核心经验检索、操作执行、配套安全护栏都需要设计为独立的核心层级。检索采用可从失败中恢复的迭代循环操作执行依托企业认可的独立身份并配套完整审计日志安全护栏部署在工具调用边界而非仅局限于模型交互层面。生产级智能体的评估体系上下文是智能体适配生产环境的一半关键评估体系则是另一半。即便上下文配置完善随着业务流量变化智能体仍会出现效果漂移、功能退化、全新故障。评估体系是闭环管控的核心既能感知系统变化也能校验智能体是否符合预期运行标准。持续评估多数团队将评估视为上线前的一次性校验跑完测试用例、指标达标就直接上线。这套模式适用于传统确定性软件但智能体并非确定性系统。相同提示词输入同一模型都可能生成不同回复模型厂商版本更新会改变模型特性智能体检索的数据源每日都会更新。上线前的测试用例只能捕捉某一时刻的行为无法保障长期稳定运行。持续评估填补了这一缺口基于线上真实流量采样用户交互数据按照团队自定义标准打分结果接入现有基础设施告警的可观测流水线。Foundry原生内置该能力一旦服务质量退化团队会收到和服务宕机相同的告警通知。这套评估机制也可前置部署为流水线门禁在功能上线前拦截退化问题。基于评分标准的评估下篇见