azure.microsoft.com/products/ai-foundry
微软的业务规模极为庞大。Foundry平台是微软用于构建、部署、运行 Agent的专用平台
微软自研的各类copilot产品均运行在该平台之上，其中Microsoft 365 Copilot就服务超2000万用户，原生智能体的月活跃使用量今年以来同比增长6倍
为深入了解规模化交付智能体的实际落地难点，下面参考微软核心AI产品副总裁马尔科·卡萨利纳的访谈
分享了团队在生产环境运维这套系统沉淀的经验、面临的工程挑战，以及他对企业级AI未来发展方向的判断。
- 原型智能体为何无法适配生产环境
- 生产级智能体支撑架构包含哪些模块，以及微软为何认为上下文是核心关键
- Foundry背后两大核心工程设计：检索作为子智能体、为智能体赋予独立身份与执行权限
- 微软如何通过基于评分标准的评估体系和自动迭代优化机制评测生产环境智能体
- 技术团队的经验启示
智能体落地生产环境会出现哪些问题
原型阶段无法暴露智能体在生产环境的故障问题。模型本身很少出问题，出问题的是模型周边的整套体系：包括智能体检索的数据、调用的工具、对接真实用户的处理逻辑，以及外部环境变化带来的效果漂移。今年计划落地智能体的企业，面临的工程难题和去年截然不同
生产级智能体远不止一个大模型，系统的绝大部分组件都是围绕模型搭建的配套设施。
想要理解这一点，先要认清企业开发目标发生的本质变化。马尔科对此趋势的解读如下：
我们正在告别AI问答时代。2026年，大量客户开始采用语音作为前端交互入口，我们也正在告别AI聊天机器人时代
过去的形态是聊天机器人：用户输入问题，机器人回复，仅能完成问答。而新形态的智能体，能够代替用户完成实际业务工作：预定会议、执行数据分析、发送邮件、提交工单。用户甚至无需手动输入文字，前端可直接采用语音交互。例如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. 智能体运行
模型上层是智能体运行时，负责将纯模型转化为可执行的智能体。运行时统筹调度循环、工具调用、对话状态维护，以及支撑架构其他模块的通信协议。
调度循环并非所有步骤都交由大模型处理。设计优良的智能体，只会把需要逻辑推理的内容发送给大模型，其余工作交由常规代码完成。数据库查询、专用抽取模型的执行效率，远比让大模型完成同类任务更快、成本更低、稳定性更强。
当前智能体框架层出不穷，既有LangChain、LangGraph、CrewAI这类开源框架，也有厂商自研的运行时环境。核心原则是框架无侵入性：基于某一框架开发的智能体，无需重构周边支撑架构，就能迁移到其他框架运行。例如Foundry支持智能体在任意框架间无缝切换。
智能体运行层
3. 可观测与治理层
智能体上线生产后，企业需要完善的可观测能力与治理体系。平台需要统一管控所有项目下运行的智能体，实现健康度评分、令牌消耗统计、延迟指标监控、漂移检测，以及跨项目数据汇总，方便平台团队统一管理智能体集群。缺失该层级，服务退化问题无法感知，成本也会失控。微软侧的对应组件是Foundry控制平面，实现跨项目集群可视化，同时将智能体遥测数据接入Azure Monitor和Application Insights，复用现有基础设施告警流水线。
可观测与治理层
4. 身份层
当智能体开始在企业内部执行真实操作，就必须拥有独立身份。智能体需要专属的角色权限分配和审计日志，行为异常的智能体，需要和违规员工一样受到访问权限约束。行业目前仍在探索最优落地方案，主流平台的共识是：复用现有企业身份体系，将智能体划为全新的主体类型，而非搭建独立的并行身份系统。例如Foundry基于微软企业身份平台Entra，将智能体纳入身份体系管理。这是访问控制的基础单元，本文后续"为智能体赋予执行场景"章节，会详细介绍智能体拥有身份后的具体操作能力。
身份层：智能体作为全新的主体类型
5. 上下文层
当智能体可以稳定运行、凭借独立身份执行操作后，核心问题就变成了能否给出准确答案，这正是上下文层的核心价值。支撑架构的其他层级保障智能体可以运行，而上下文层保障智能体正确运行。缺少优质上下文的智能体极易产生幻觉，即便给出回复，错误也难以识别，因为智能体本身无法感知自身的知识盲区。马尔科明确表示，为智能体提供落地工作所需的上下文，是团队攻克的最难课题之一，也是微软重点打磨的核心能力。
上下文层
微软如何为智能体搭建上下文层
为智能体匹配精准上下文的难点，不在于企业缺少数据，恰恰相反，企业拥有海量数据，但数据分散在各个系统：SharePoint、知识库的非结构化文档，OneLake、数据仓库的结构化数据表，Outlook、Teams、Word等生产力应用。没有单一检索方式可以覆盖全部数据源。
企业上下文数据分散在各个系统
过去两年的主流方案------传统检索增强生成（RAG），本身就无法适配这类复杂场景。传统RAG是一次性检索模式：接收用户问题、向量化处理、检索单一索引库、返回top-k结果送入模型。该方案仅适用于小型干净语料库的简单问答
一旦问题存在歧义、数据源异构、答案需要多源信息整合、首次检索无结果，这套方案就会失效。智能体无法从检索失败中恢复，正如马尔科所说，RAG效果不佳时，整个智能体的运行都会受影响，一次性检索的模式本身就不适配复杂业务场景。
传统RAG：一次性检索查询
解决方案: 将检索设计为可迭代的流程，和智能体执行任务的迭代逻辑保持一致。
迭代式检索
规划查询语句、尝试调用数据源、评估检索结果、首次检索无结果则切换其他数据源、整合多源信息。这是生产级上下文层的核心工程思路。
检索作为循环流程：规划查询、调用数据源、评估结果、重试检索
微软的落地方案，是将上下文层拆分为四大独立服务，合称Microsoft IQ：
- Foundry 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原生内置该能力，一旦服务质量退化，团队会收到和服务宕机相同的告警通知。这套评估机制也可前置部署为流水线门禁，在功能上线前拦截退化问题。
基于评分标准的评估
下篇见👋🏻