Posted inAgent 365 AI Adoption AI Agent AI Transformation Code AI Community Community & News Defend Against Threats Digital Transformation GenAI Newsletter Modern Work Modern Work Adoption Secure AI Productivity Secure and Govern AI Security Newsletter Threat Protection with XDR Workplace AI

一文读懂 Build 2026：Copilot 走到下一步，微软如何用 Agent、IQ 与 MAI 重构企业 AI 操作系统

Posted inAgent 365, AI Adoption, AI Agent, AI Transformation, Code AI, Community, Community & News, Defend Against Threats, Digital Transformation, GenAI Newsletter, Modern Work, Modern Work Adoption, Secure AI Productivity, Secure and Govern AI, Security Newsletter, Threat Protection with XDR, Workplace AI

清晨，当你打开电脑的那一刻，也许楼下打印机里的文档已经准备好、收件箱里繁琐的邮件已被自动分类，甚至今天的日程冲突都被悄然协调好了。而你所做的，只是喝了一杯咖啡。这听起来像未来，但在 Microsoft Build 2026 大会上，我们看到了这样未来的雏形。一反过去“发布新软件或硬件”的惯例，微软高调宣示了一个全新的战略方向：“Agent First”（智能体优先）。简而言之，软件的主角正在从界面和按钮，变成幕后的 AI 数字同事。在 ChatGPT 等聊天 AI 火出圈之后，微软把目光瞄向了下一个阶段：让 AI 不只是回答问题，而是主动帮我们干活。Build 2026 上亮相的一系列技术表明，我们正站在一场操作系统与数字生活范式转移的门口——计算机将不再只是被动的工具，而会变成我们工作和生活中默默但高效的合作者。对于普通人和企业来说，这意味着什么？这篇文章希望帮你理清背后故事：为什么“智能体时代”已悄然来临，它如何改变我们看待软件和工作的方式，以及它将给未来几年带来哪些机会和挑战。

主题 1：Agent 优先与智能体生态

A 深度总结（10要点）

  1. 智能体优先战略：微软高层在Build 2026大会上明确提出“Agent优先”的战略转向，展望一个以AI智能体为核心的应用生态。智能体将不再被动等待用户提问，而成为主动、持续运行的数字员工，从仅在聊天框回答问题，进化到能跨设备、跨应用自主执行复杂任务。
  2. 多智能体协作：微软强调通过Copilot Studio 等开发工具实现多智能体编排（Multi-agent Orchestration），支持开发人员设计和管理一组协同工作的智能体，每个智能体执行专门子任务，共同完成复杂工作流。这促进了智能体间的任务分工与合作，提升整体效率和可靠性。
  3. Copilot副驾驶的演进：微软对现有Copilot（副驾驶AI）进行界面与交互设计升级，提供统一的“Copilot超级应用”界面，让用户可以在单一入口与各类Copilot交互。这个新版Copilot集成了聊天、文档生成功能，界面更简洁直观，并将适配PC、移动端等多种环境。【待核实：新Copilot应用是否具备全渠道统一界面，需要微软官方演示确认。】
  4. “Autopilot”始终在线智能体：微软推出全新AI智能体分类——Autopilot，即始终在线、在后台自主运行的个人AI智能体。首款产品 Microsoft Scout 正式发布（Frontier计划客户优先体验），内置于Teams和Outlook等工作应用。Scout基于开源OpenClaw框架和Work IQ，能够持续监控用户的团队聊天、日历和邮件等工作内容，自动执行任务如会议准备、日程管理和冲突协调等。它利用企业且受控的自身Entra ID身份，确保每个决策和操作都可被追踪和审核。
  5. Agent 365 工具集：微软扩展Agent 365 平台，实现对本地运行的各种类型智能体（20多种）进行统一监控、治理与安全管控。通过Agent 365，企业可获得智能体目录视图，IT/安全团队了解每个智能体由谁部署、访问了哪些数据与工具、当前行为状态及资源消耗。管理员能设置策略规则、对违规行为进行提醒与阻断，并通过记录审计满足合规要求。
  6. Computer-using Agents （具备操作电脑能力的智能体）：微软推出Windows 365 for Agents（现已GA）作为**“云端电脑”专属平台，为AI智能体提供安全、可管理、按需扩展的虚拟Windows PC运行环境。这使智能体可以模拟人类，用键盘鼠标在真实Windows界面下跨应用执行任务（如打开Office软件处理文件、使用浏览器UI完成网页操作等），延伸AI从API调用扩展到全面的RPA式业务流程自动化**。每台智能体云PC都预集成Entra身份、Intune管理和策略控制，IT部门可应用统一安全与合规措施大规模部署“电脑智能体”。
  7. Copilot Studio 新功能开放预览：Microsoft Copilot Studio 是微软针对企业的AI智能体开发与管理中心。它集成了设计、构建、调试工作流的工具，并提供可视化的安全治理仪表盘。通过Copilot Studio，企业可把自有数据与模型相结合，创建和部署自定义企业Copilot 或智能代理，同时确保数据流动符合DLP和合规要求。2026年4月的更新为Studio引入了治理与工作流管理功能，使其逐步成为AI智能体的控制中心。
  8. 智能体工作流自动化：智能体生态强调工作流自动化的重要性。例如，借助OpenClaw（已支持Windows OS）和其他框架，智能体可以自主调用工具（应用程序、Shell命令、外部API等）执行一系列步骤，直至完成复杂任务。OpenClaw on Windows (Preview) 在Windows上实现了对OpenClaw（热门开源AI代理框架）的支持，结合MXC容器，允许智能体在本地执行多步骤工作流而不影响主机安全。
  9. Project Solara 平台：微软预览了Project Solara，定位为面向开放多智能体世界的全新芯片到云技术平台。Solara的愿景是为客户和合作伙伴提供可定制的智能体硬件参考设计和管理平台，使AI智能体能在更广泛的设备形态上存在并协同（例如可穿戴工牌和桌面伴侣设备概念）。这些参考设计致力于让智能体超越单一屏幕或应用的限制，提供更自然、更随时随地的人机交互体验，同时由云端服务保障数据安全与上下文同步。
  10. 生态合作与统一标准：微软推动智能体生态的开放合作。例如，与NVIDIA合作打造统一的智能体AI软硬件栈，推出搭载NVIDIAGrace Hopper和Blackwell GPU的Windows PC （如Surface Laptop Ultra）、工作站（如DGX Station for Windows），满足开发和运行超大参数智能体模型的需求。同时，微软发布Model Context Protocol (MCP) 的安全与治理扩展（见主题5），倡导跨平台统一智能体上下文与安全标准，为支持多厂商智能体协作和工具调用打下基础。

B 企业使用场景

  • 客户服务：大型电商企业引入持续运行的AI智能体为客服团队赋能。例如，一个智能体整合Work IQ上下文，全天候监控客户邮件、在线咨询等渠道，并自动分类、回复高频问题，仅在复杂问题时才通知人工客服介入。这个主动型客服智能体能降低响应时间、提升客户满意度，同步缓解人工团队压力。
  • 销售与市场：SaaS软件公司部署智能体生态支持销售流程。多个合作智能体协同工作：一个智能体持续跟踪领英和邮件线索，识别潜在客户；另一智能体分析CRM数据和市场信息提供销售建议；还有一个Copilot智能体实时协助销售撰写个性化营销邮件。这种 Agent 团队模式 帮助销售人员高效获取线索、制定策略并执行触达客户的工作流，提高转化率。
  • 研发与项目管理：制造业企业应用Autopilot智能体作为数字项目助理。智能体连接项目管理工具（如Planner/Jira）和工程协作平台，每日自动更新任务状态、提醒关键里程碑，甚至协调跨团队会议。研发经理也可以让智能体监控技术社区，将相关创新动态推送给团队。借助智能体的不间断工作，项目沟通更顺畅，研发进度透明度和准时率显著提升。
  • 财务与人事：金融企业的人力资源部门利用Copilot Studio创建HR智能体辅助内外部流程。该智能体每天扫描员工邮件（权限过滤后）识别请假、出差申请等，然后自动填报系统表单提交审批；也可面向求职者通过公司网站进行24/7 面试问答和资料收集。另一个财务报表智能体每日从财务系统提取数据，自动生成报告给CFO审阅，并根据历史模式标记异常或风险指标。这些智能体让管理支持部门提升效率，准确度和合规性也通过系统集成得到保证。
  • 安全运营：网络安全团队部署Agent安全扫描智能体（类似MDASH）在企业开发流水线中自动审计代码和配置变更。该智能体作为“安全顾问”，在代码提交或应用部署前，以100多个特化子智能体对新代码进行漏洞扫描、验证攻击场景，提前发现安全隐患。一旦发现异常模式，它自动生成漏洞描述和修复建议推送给开发者，并记录至Defender安全中心供审查。这种自主安全Agent可大幅提高安全审计覆盖率、降低人力负担，并在企业快速开发周期中提供实时防御。

C 如何落地（0→1）

  • 前置条件：评估企业的数字化基础和AI准备度。确保已部署微软Microsoft 365生态（Teams、Outlook等）及Azure基础设施，以提供智能体所需的身份、数据和工具集成环境。若计划使用Microsoft Scout等前沿智能体，需要申请加入微软Frontier计划并拥有GitHub Copilot订阅。企业应建立跨部门AI能力中心，明确AI战略目标和业务优先级，为智能体落地提供组织支持。
  • 架构与集成思路：设计智能体生态系统架构，包含智能体开发环境（Copilot Studio等）、运行时平台（Foundry+Agent Framework）、上下文层（Microsoft IQ）、数据平台（Fabric、HorizonDB等）与安全治理层（Agent 365、MXC等）。在企业现有IT架构中为智能体平台预留接口，将智能体需要访问的内部系统、数据库、第三方API通过MCP或OpenAPI等方式连接进入智能体的工具箱。可采用渐进集成：先在测试环境部署小规模智能体实例，确保与AD、单点登录、业务系统等顺畅对接，再逐步推广。
  • 权限与合规：遵循“内置信任”原则，从设计上确保智能体符合企业安全与合规要求。给每个智能体分配唯一的受管身份（Entra ID），将其行为纳入现有权限管理和审计框架。使用Agent Control Specification (ACS) 等机制为智能体定义行为红线（如禁止访问特定系统、敏感操作需人批等）。结合Microsoft Purview 敏感数据标签和DLP策略，对Work IQ、Fabric IQ里涉及敏感/机密信息的内容加以标记，确保智能体调用上下文时自动过滤/遮蔽机密数据。所有智能体与用户交互内容和行为日志都需保留审计记录，满足行业法规（如金融业的SOX、GDPR等）的合规要求。
  • 试点范围：选择低风险、高价值的业务场景开展智能体落地试点。例如内部流程自动化（如IT支持问答Agent、会议助手Agent）、或面向员工的辅助（如日程助理、培训问答）等。避免一开始即在客户敏感或高风险领域大规模部署；优先内部应用场景以积累经验并验证效果。在试点中，明确评估周期（如8-12周），选定小范围用户群与特定KPI，便于观察智能体表现并快速调整。
  • 指标与验收：设定量化指标衡量智能体试点成果，包括：效率提升（任务完成速度、自动完成任务占比）、质量改进（结果准确率、错误率降低）、用户满意度（采纳率、反馈评分）、合规性（无违规操作率）等。在试点结束时，对照基准数据评估这些指标是否达标，以确定智能体是否实现预期价值。如果部分KPI未达到，分析根因（如模型能力、上下文不足或权限限制），拟定优化方案再行验证。
  • 风险与缓解：识别并持续监控智能体落地的潜在风险点。主要风险包括：错误操作或决策（智能体输出错误信息或执行错误动作）、数据泄露（访问未经授权信息）、合规违规（违反法规或道德准则）等。为此采取多层次缓解措施：建立人工反馈与监督机制（关键决策需人批准）；利用ASSERT 等测试框架在上线前模拟评估智能体行为，发现潜在问题；采用隔离环境和最低权限策略确保即使智能体出错也不致引发重大损害（如限制其仅访问必要系统）；制定应急预案，在智能体异常时可即时停用或回滚。定期举办红队演练来测试智能体的防滥用和安全性，并根据演练结果完善策略。
  • 成本与计费关注点：预算智能体部署可能涉及的各类成本：模型调用费用（如微软Copilot/APIs按 token 计费模式）、算力消耗（Azure云GPU/CPU实例费用，Windows 365 for Agents的按用量计费）、开发和DevOps集成投入、订阅许可费用（GitHub Copilot企业版订阅、Microsoft 365 E5/Azure OpenAI服务月费等）。建议采用试点期间的用量数据估算长期成本，并评估使用本地硬件（如Spark Dev Box）与云资源的平衡以优化TCO。采购部门应与微软销售代表沟通最新商业模式（如Copilot按用户订阅 vs. 按用量计费）对预算的影响，确保成本透明可控。

D 相关角色与责任（RACI）

角色 主要责任（在引入智能体优先及生态时）
业务Owner 确定业务痛点及智能体应用场景；定义成功标准与ROI指标；推动组织资源投入并监督项目方向与成效。
IT部门 负责技术架构选型与实施（部署Copilot Studio、Foundry等平台）；整合智能体与现有IT系统；提供基础设施支持（云资源、网络、安全组配置等）。
安全/合规团队 审查智能体解决方案的合规性（数据保护、法规遵从）；配置访问控制与监控策略；在项目各阶段执行风险评估和隐私/安全审核。
数据团队 准备和治理数据资源供智能体使用（确保训练/上下文数据质量、正确标注敏感数据）；建立知识库（Work IQ等）并维护数据更新；监控模型输出质量及偏差。
开发团队 开发和调优智能体应用（使用Copilot Studio、Microsoft Agent Framework等构建和测试智能体）；实现定制功能与集成业务逻辑；持续迭代改进智能体性能。
采购/财务 评估解决方案成本及ROI；与微软及合作伙伴协调合同采购（如Copilot订阅、设备购买）；跟踪费用（云服务用量、许可）并优化成本结构。

E 7/30/90 天行动清单

主题 2：上下文/智能层（Microsoft IQ 等）

A 深度总结（10要点）

  1. Microsoft IQ 智能层：微软推出Microsoft IQ（现已GA）作为智能体时代的共享上下文基础设施。Microsoft IQ 将企业内外的各类数据和知识汇聚为统一的语义层，服务于所有AI智能体，确保它们随处可取用相关知识、遵从统一治理。微软称其为**“情报层”（Intelligence Layer），让智能体理解企业语境**成为可能。
  2. Work IQ：Work IQ（现已GA）是Microsoft IQ中的职场智能层，通过挖掘企业沟通、文档、会议、业务系统等数据，建立对“工作如何发生”的语义理解。Work IQ可视作对Microsoft Graph的智能升级版：它不仅提供权限控制下的企业内容访问，更注重捕捉人与人、人与信息之间的关联，例如自动识别团队组织结构、项目关系、常用文件/沟通频率等。Work IQ确保每个智能体调用企业语境时都恰如其分。
  3. Fabric IQ：Fabric IQ（预览）是Microsoft IQ的业务数据智能层，面向企业的结构化业务数据（如供应链、ERP数据，数据仓库等）。通过建立统一的业务术语本体（Ontology），Fabric IQ为智能体提供对实时业务运营状态的语义理解。这意味着智能体在提供分析和决策支持时，能够精准把握企业数据定义和上下游关系（如理解“客户订单”、“库存水平”的业务语义），从而提高输出的准确性与业务相关性。
  4. Foundry IQ：Foundry IQ（现已GA）是智能体知识检索与整合的核心枢纽。它负责统筹 Work IQ、Fabric IQ、文件搜索、SQL 数据库、MCP 等各种知识源，为企业智能体提供统一的语义检索服务。Foundry IQ通过统一的API和SLA保障，在模型推理前执行检索规划，确保智能体能检索到正确、高相关的信息片段来支撑推理。这一层将企业内知识（via Foundry IQ）与外部实时网络（via Web IQ）无缝衔接。
  5. Web IQ：Web IQ（有限预览中）是Microsoft IQ平台里面向互联网的AI检索层。它提供一套专为AI设计的网络检索API，在大规模分布式技术下，具备子165毫秒95分位响应延迟和2.5×同类方案的速度。Web IQ不仅返回原始网页，还会提取关键段落和结构化证据，帮助AI智能体基于最新、经模型未见的数据做出有依据的决策。这一服务已用于微软Copilot和ChatGPT的联网插件，并正开始提供给部分Azure客户试用。
  6. IQ 平台价值：借助Microsoft IQ，上下文成为关键基础设施，而非零散功能。对于企业而言，它可将多年积累的信息转化为持续增长的情报飞轮：每次智能体被使用，其对上下文的获取、反馈（如决策、结果）又进一步丰富IQ知识。因此，智能体越用越聪明，持续完善企业数字大脑的“记忆”和“知识库”。对企业用户来说，意味着无缝、及时且有依据的AI辅助决策能力。
  7. Work IQ APIs：微软宣布Work IQ在6月16日提供公共API。这允许开发者通过编程接口访问和利用Work IQ的语义情报，把工作智能能力嵌入自有应用。透过这些API，第三方系统或自研应用也可查询企业的知识层（如找到某个主题相关的所有会议纪要，或某专家的过往项目经验），丰富业务应用的智能。
  8. 上下文隐私与安全：Microsoft IQ的各子层均遵循现有权限体系。Work IQ对个人数据（如邮件内容、聊天记录等）的访问受用户隐私设置和合规策略限制，确保输出只在合法可见范围内抽取信息。Fabric IQ的业务数据则继承数据平台的分级权限和敏感数据标签。通过Purview等工具，且因IQ本身是企业内部服务，所以上下文提取不会导致数据外泄。企业可在IQ的配置中设置数据保留和脱敏策略，进一步满足内部和监管要求。
  9. 对开发者/数据科学家的影响：IQ平台降低了企业开发自有智能体应用的数据准备门槛。开发团队不必单独构建检索系统或爬虫，直接利用IQ 即可获取企业知识和外部资讯，以结构化形式输入模型。这加速了AI应用的原型开发，也减少“幻觉”等不可信输出，因为模型有据可依。同时，IQ提供一致的SLA和费用模式，开发者无需关心背后复杂的知识源整合逻辑，可专注应用逻辑实现。
  10. 未来展望：统一上下文层的引入被视为AI应用的游戏规则改变者。它为企业的AI转型奠定了坚实基础 —— 在Microsoft Build 2026之后，所有新推出的硬件、软件、开发平台均集成IQ支持，如微软自己的Scout和Copilot应用无缝依赖Work IQ、Web IQ 等。展望未来，随着更多企业系统通过IQ接入AI时代，智能体将能即时掌握整个组织的知识网络，真正成为团队不可或缺的数字成员。

B 企业使用场景

  • 客户支持：大型银行利用Microsoft IQ打造智能客服Agent。在客户通过手机App咨询信用卡问题时，该智能体可即时从Work IQ抓取用户最近交易记录、从Fabric IQ检索用户产品持有情况，并结合Web IQ查询最新的金融法规。最终，它生成符合合规要求的个性化答复，提高客户满意度并减少前线客服工作量。
  • 合规审核：医药行业公司部署智能体辅助文档合规性审核。智能体借助Work IQ获取公司内部沟通记录，结合Fabric IQ模型描绘业务流程图，再从Web IQ调取监管法规文本。当研究人员提交新药研发报告时，智能体自动对比报告内容与法规要求，标记潜在不合规段落，并从监管文本提取必要的引用。这样的人机协作使合规团队能够大规模高效识别风险。
  • 销售提案自动化：跨国IT企业采用IQ层为销售团队配备提案生成智能体。智能体调用Work IQ整合过去类似客户的方案、Fabric IQ提取标准产品配置及关键指标，然后通过Web IQ获取该客户所在行业最近动态数据。凭借这些上下文，智能体自动起草量身定制的销售提案，让销售人员专注客户沟通，显著加速提案准备并提高客户响应率。
  • 知识管理：咨询公司部署IQ平台作为内部知识库智能助理。顾问在项目中可以通过聊天向Work IQ询问类似案例的经验总结，或者让智能体从Fabric IQ和Foundry IQ找出相似项目的财务数据与结果。当遇到领域新课题时，智能体借助Web IQ搜索相关文献和市场报告，供顾问参考。借助IQ层，企业知识资产充分盘活，新人也能更快积累行业洞察。
  • 研发创新：制造领域的技术研发团队使用微软IQ平台和智能体加速创新流程。例如，工程师提出一个产品改进想法后，智能体利用Work IQ搜集公司以往类似想法的讨论记录和专利库条目，从Fabric IQ获取相关产品的现场数据表现，再通过Web IQ检索公开学术论文或行业标准。最终，智能体输出一份涵盖内部经验和外部洞见的可行性分析报告，帮助团队更快速地评估创意并决策。

C 如何落地（0→1）

  • 前置条件：确保企业具备整合数据源的能力和权限。首先，需要现代化的IT环境（如已部署Microsoft 365、Azure等），包含电子邮件、IM、文档库、数据库等核心数据，供IQ智能层连接。IT团队应梳理企业知识资产（如现有知识库、文档系统）及权限结构，为后续整合做好准备。必要时，对数据进行梳理和标签（尤其是敏感数据），使用微软Purview等工具加以分类，以便Work IQ、Fabric IQ等能正确识别权限边界。
  • 架构与集成思路：设计智能上下文层集成方案。识别出企业关键的上下文来源（如邮件与IM记录、SharePoint文件、数据库、数据仓库等），规划通过Microsoft IQ 将它们集中管理。例如，将SharePoint、OneDrive文件库接入Fabric IQ，将客户关系管理（CRM）和ERP数据库通过Fabric IQ Ontology 模型描述；确保企业的Microsoft 365服务开启Work IQ集成。有条件的企业申请Web IQ预览资格，以便智能体能访问实时网络信息。整个实施过程中由数据团队牵头，逐步将不同数据源接入IQ层，测试检索质量与性能，确保按需扩展和服务SLA满足预期。
  • 权限与合规：在整合上下文层时，要遵循**“零信任”和最小权限原则。确立数据访问策略**，定义每类数据在IQ层的访问可见性和保留策略。将Microsoft Entra 权限模型覆盖到Work IQ和Fabric IQ中，确保智能体对用户通讯和业务数据的访问不超出其原有权限范围。IT与合规团队在上线前审阅整合的数据源，识别敏感数据并设定红线，如不将HR系统中个人敏感信息暴露给IQ层或要求脱敏。利用Purview 等对接IQ层，达到自动同步权限/标签的效果。在Web IQ的应用上，制定网络数据使用规范（如只检索公共可用信息，不引入受版权或隐私保护的数据），并监控Web IQ可能返回的内容类型以防范合规风险。
  • 试点范围：建议选择一个对上下文依赖强、技术风险相对低的场景试点IQ层。例如内部知识问答Bot：选取某一部门或项目组，让智能体通过IQ接口回答员工关于文档、项目历史、专家联系人的咨询，提升知识获取效率。或者邮件/会议要点智能提取：利用Work IQ生成关键决策点推送给经理。通过局部场景试点，评估IQ层带来的改善，并根据反馈进一步完善数据整合的范围与细节。
  • 指标与验收：验证上下文层价值的关键指标包括智能体响应质量和效率提升。对试点场景比较上线前后的回答准确率、相关知识检索覆盖率，以及用户对回答质量的满意度。监控智能体的提示字数或会话长度与回答正确率之间的变化，评估IQ层长上下文是否被有效利用（如是否减少“我不知道”回答或事实错误）。同时关注系统性能指标（查询延迟、Query成功率）、权限违规尝试次数等，确保情报层服务稳定、安全。
  • 风险与缓解：主要风险在于数据安全与隐私。应密切监控智能体访问的内容，防止跨越权限界限。对Work IQ，IT部门可定期审计其日志，查看是否有敏感信息被智能体访问（通过Purview输出报告）。对Web IQ，警惕外部信息源的质量和可信度，避免为智能体引入错误或有偏见的外部信息（可通过证据日志回溯检查）。另一个风险是知识混淆：如果上下文源数据质量差，可能导致智能体输出错误结论。需定期维护和清洗知识库，或对重要内容设置**“金标准”答案以校准AI。最后，持续培训用户合理使用上下文API**，避免不必要地暴露信息或不恰当的问题。
  • 成本与计费关注点：上下文层服务通常按数据存储与检索量计费。例如Work IQ可能以MIUs（百万项查询请求）或用户数量定价【待核实】。使用Web IQ可能产生外部检索调用消耗（如按API调用次数收费）。为控制成本，企业可在试点中设置调用频率限制，并监测查询量峰值；充分利用Work IQ API本地缓存（如在应用本地缓存常用上下文）减少重复调用。需要注意的是，构建IQ层还涉及数据工程成本，如数据清洗、标签和定义业务语义模型的人员投入，应纳入项目预算。此外，与微软沟通争取预览期免费额度，通过Azure成本管理工具实时跟踪IQ相关资源消耗，提早发现异常用量。

D 相关角色与责任（RACI）

角色 主要责任（在部署统一上下文智能层时）
业务Owner 确认哪些业务领域受益于上下文智能层（如客服知识库、项目经验复用）；投入资源支持数据整合项目，协调业务部门配合提供数据；衡量统一智能层对业务决策和效率的提升。
IT部门 搭建并维护IQ平台环境（Work IQ、Foundry IQ等）；实施数据管道开发，将各种数据源接入统一层；监控上下文服务的性能与可用性，确保满足SLA。
安全/合规团队 对上下文层进行安全风险评估，定义数据接入的权限策略和合规标准；审核数据分类和标记策略，确保敏感信息在上下文层得到适当保护；持续监控智能体上下文访问行为，处理异常访问告警。
数据团队 负责数据源梳理与准备：清洗结构化数据、整理非结构化文档、构建业务语义模型；定义Work IQ、Fabric IQ所需的数据索引，确保知识持续更新；与IT合作，调整数据管道和知识库性能。
开发团队 使用Work IQ API等接口将上下文智能能力集成到应用和智能体中；优化应用调用上下文的逻辑（如检索调用频率、缓存策略）；与数据团队合作调整上下文检索结果格式以适配模型的要求；测试智能体在有无IQ上下文时的表现差异，并根据需要改进上下文使用方式。
采购/财务 与微软沟通IQ平台和Web IQ的收费模式与合同；评估内部构建和维护统一情报层所需的资源投入与潜在收益；控制试点和全面上线阶段的相关费用，管理云服务开销的预估与持续监控。

E 7/30/90 天行动清单

主题 3：模型与定制（MAI 模型家族、Frontier Tuning 等）

A 深度总结（10要点）

  1. MAI 模型家族：微软发布MAI (Microsoft AI) 系列七款最新自研AI模型，包括推理、编程、图像、语音和转录等多个类型。这套模型家族采用统一的技术基础，全部自底向上重新训练（不依赖第三方模型蒸馏）。MAI-Thinking-1 是其中的旗舰推理大模型，拥有350亿活跃参数和256K上下文窗口。微软强调这些模型使用企业级干净数据训练，具备高效低成本推理特性。
  2. MAI-Thinking-1 推理模型：MAI-Thinking-1 是微软首款专注推理的中型大语言模型，设计用于复杂多步指令和长上下文推理场景。它在软件工程基准测试中表现媲美业界顶级超大模型Sonnet 4.6，在代码生成等任务上达到同等水准，同时推理成本更低。该模型已向特定早期合作伙伴开放体验。这标志着微软不再仅依赖外部OpenAI模型，而是拥有了自研高性能语言模型内核，强化了AI战略自主权。
  3. MAI-Image-2.5 & Flash 变体：MAI-Image-2.5 是微软首个集成文生图和图像处理能力的模型。在Arena等公开评测中，它的文本生成图像质量排名世界前列，而Flash版本在效率和速度上更优化。这款模型可用于开发者工作流（如从创意草图到原型UI自动生成）。MAI-Image模型已首先内置于PowerPoint并即将推广到OneDrive照片应用，提供高质量/高效率的视觉AI生成体验。
  4. MAI-Code-1-Flash 编程模型：MAI-Code-1-Flash 是一款针对GitHub Copilot和VS Code调校的高性能、低延迟代码生成模型。其约50亿参数，但通过优化能以极快速度提供准确代码建议。微软宣称MAI-Code-1在SWE Bench Pro基准上与OpenAI Codex等最先进模型持平，但代价显著降低。由于GitHub Copilot本身是多模融合，MAI-Code-1成为其核心模型意味着企业编码场景的AI质量和成本都有望改善。
  5. MAI-Voice-2 和 MAI-Transcribe-1.5：MAI-Voice-2 (语音生成) 和 MAI-Transcribe-1.5 (语音识别转录) 是微软面向多语言语音处理的模型。MAI-Voice-2现支持15+种语言和多种可定制音色，生成自然流畅的语音，并有防滥用机制；其Flash版本将以更低成本实现接近效果。MAI-Transcribe-1.5提供43种语言的高精度语音转文本，并将支持流式实时转录。这些模型的发布巩固了微软在多模态AI领域的版图，为全球企业提供了跨语言、跨媒介的AI互动能力。
  6. 模型分发与开放：微软宣布将推动MAI模型的多渠道分发。除了直接在Azure Foundry和微软自家产品中部署，这些模型还将通过第三方ML平台供开发者调用，如Open Router、Fireworks AI、Baseten等。尤其值得关注的是，微软将首次允许开发者对其模型进行权重级调优，表明微软正采取更开放的合作态度吸引开发者生态，与OpenAI等外部模型形成差异化竞争。
  7. Frontier Tuning 前沿调优：为解决模型通用性与业务专用性之间的矛盾，微软发布Frontier Tuning，提供企业自定义模型的新方法。Frontier Tuning允许企业在合规边界内，使用自身数据和工作流对基础模型进行强化学习调优，使模型更懂企业。这一方法以强化学习环境 (RLE) 实现，让智能体在完成实际业务任务过程中持续收集反馈并改进。调优后的模型由企业完全拥有，知识和演进闭环内化于企业自身，从而显著提升输出质量和资源利用率。Frontier Tuning现已开启有限预览。
  8. 模型性能与效率：微软展示了Frontier Tuning提升模型性能的显著效果。经Frontier Tuning定制的Excel专用模型达到与GPT-5.4等价水平，但效率提高10倍。麦肯锡公司将MAI模型用Frontier Tuning调整到其严格标准后，该模型胜率登顶且成本降低约10倍。这表明针对具体领域优化模型能够获得远超通用模型的性价比，对企业应用具有重要意义。
  9. Mayo Clinic 合作：在医疗保健领域，微软宣布与全球顶尖医疗机构梅奥诊所合作，共创前沿医疗AI模型。此模型将梅奥诊所的临床专业知识和大量脱敏医疗数据与微软的AI研发能力结合，目标是打造专攻医疗场景的旗舰级模型，涵盖广泛的临床推理和医疗用例。模型将在梅奥内部部署验证，通过Azure Foundry API开放给医疗行业的其他机构使用，且所有知识产权归梅奥诊所所有。这体现了微软以合作共创和客户掌控为导向的企业AI战略。
  10. 模型透明度与责任：围绕MAI模型家族，微软强调“Humanist Superintelligence”理念：打造以人为本的超级智能，让AI服务人类而非取代人类。微软公开了MAI模型的安全与技术细节报告，提高透明度。凭借自研模型，微软可以提供端到端责任：从数据源到算法调优都可控可查，方便回答客户对于AI行为可信度和合规的疑问。这种透明和控制能力对银行、医疗等敏感行业尤为重要。

B 企业使用场景

  • 金融服务：投资银行通过Frontier Tuning技术打造定制的风控模型。在使用MAI-Thinking-1基础模型的基础上，将内部市场数据、交易历史和风控规则输入强化学习环境，使模型学习机构特有的风险偏好和决策流程。这一专属模型可用于市场预测、投资组合优化等，性能超越通用模型且符合该行的合规标准，帮助风控团队更准确地识别投资风险。
  • 制造业：汽车制造商使用MAI模型开发质量检测智能体。他们利用MAI-Image-2.5模型搭配MAI-Transcribe，在生产线上实现自动视觉检测和语音警报——在零部件检测过程中，图像生成模型将缺陷部位高亮显示并生成报告，语音合成模型实时播报发现的异常。企业可通过Frontier Tuning微调MAI-Image模型，使其熟悉特定零部件缺陷模式，提高检测准确率并减少漏检率。
  • 零售行业：电子商务平台采用MAI-Voice-2和MAI-Transcribe开发智能客服呼叫中心。MAI-Voice-2生成拟人化的多语种语音客服响应，与客户自然对话，而MAI-Transcribe将客户语音请求实时转文本供后端理解。通过Frontier Tuning，平台对模型进行风格和术语的调优，使语音客服更符合企业品牌语调，增加客户信任度。
  • 软件开发：科技企业对MAI-Code编码模型进行Frontier Tuning，使其掌握企业内部代码库风格和最佳实践，打造专属代码智能体。开发者在VS Code中使用这款智能体，可获得针对公司代码标准定制的即时代码补全、错误检查与修复建议。结合GitHub Copilot CLI的新功能（/fleet），部分代码生成和分析任务可在开发者本地机器上由小模型完成，降低云端调用成本。
  • 科研创新：制药公司应用MAI思考模型和Frontier Tuning创建药物研发专用AI。模型在其安全环境中学习历史实验数据、药理知识和企业know-how，以建议新的药物化合物或研发路径。通过持续强化学习，这款模型逐步积累该公司的独特研发经验，成为虚拟研究员。该AI已经在内部试验中帮助研究团队更快地筛选潜在药物靶点，预期将缩短药物开发周期并提高成功率。

C 如何落地（0→1）

  • 前置条件：确定企业对自有模型的需求，以及现有AI基础。例如，评估当前使用的通用模型（OpenAI等）是否存在成本高、输出不够贴合业务的问题。如果决定采用微软MAI模型和Frontier Tuning，需要Azure Foundry服务使用权限，并在本地或Azure上准备足够算力资源（例如GPU或Azure H100实例），也可配合Surface RTX Spark Dev Box等本地机器来承载模型调优任务。此外，需准备高质量训练数据（企业自有数据、历史记录、交互日志等），确保符合作品权和隐私要求。
  • 架构与集成思路：整体采用“模型平台 + 持续学习”架构。在Azure Foundry上配置模型开发工作区，选择合适的MAI基础模型（如Thinking-1、Image-2.5等），然后使用Frontier Tuning框架进行企业微调。将企业真实工作流接入强化学习环境，比如通过模拟环境或影子模式运行，让模型可以观察人类如何完成任务。调优完成后，将自研模型部署至安全的推理服务或Microsoft Foundry Hosting环境，并通过标准化API（OpenAI兼容REST接口或MCP）供业务应用/智能体调用。同时，设计MLOps流程（训练-评估-上线-反馈-再训练）及相应平台支撑，确保模型可以不断改进。
  • 权限与合规：模型定制过程应全程在企业合规边界内进行。确保训练/微调数据经过脱敏处理（客户隐私数据匿名化、敏感字段脱敏等），并通过数据访问权限控制，让模型仅学习允许范围内的信息。针对医疗、金融等高度监管行业，还须满足行业指南（如HIPAA、GDPR），在调优前与合规团队确认数据可用性。模型调优完成后，在部署前对模型进行安全评估（通过ASSERT等工具自动测试，以及专家对输出进行审查），确保模型不会生成涉敏或有害内容。应用水印、审计机制记录模型提供的关键结论，方便人工复核，实现责任可追溯。
  • 试点范围：以一个明确业务用例为切入点进行模型定制试点。例如在客服领域，选择一个具体产品线的FAQ应答模型进行Frontier Tuning。通过有限范围试点，可以验证：自研调优模型与原先通用模型相比性能提升（如准确率更高，响应更快），以及ROI（是否降低了API调用费用）。以此为依据，再决定在更多用例中扩展。对多模态模型（如图文或语音），也可挑选单个功能点开始（如产品图片生成、客服语音助手），逐步积累经验。
  • 指标与验收：定义清晰的评估指标评估模型定制效果。主要包括准确率（回答/预测正确率提升幅度）、效率（推理速度、计算成本降低幅度）、模型使用率（新模型相较通用模型被选用的频率）等。在模型上线前，可通过A/B测试对比新旧模型输出质量。如某金融文本摘要任务，评估MAI模型摘要和原先GPT摘要的差异。验收标准应包括安全检查（输出是否无偏见、无违禁内容）。通过这些指标判断模型是否满足业务需求，如不达标则需分析问题（可能是训练数据不足或微调方式需要调整）并进行二次迭代。
  • 风险与缓解：自研模型定制的风险主要包括训练数据偏差和过拟合、知识更新滞后等。为缓解，数据团队在训练前应仔细清洗和审查数据，确保代表性，避免模型学到过时或偏颇的信息。另一个风险是上线后的质量控制：微调模型可能在未覆盖的情况下表现不佳，因此需要持续监控模型输出，利用ASSERT等评测框架定期“体检”，并动态更新模型（如出现显著错误则触发再训练）。此外，要注意知识局限风险：自有模型脱离大规模公共预训练数据，可能在出域问题上能力不足，故可通过混合使用外部大模型或通过MCP + Web IQ弥补外部知识来降低此风险。
  • 成本与计费关注点：引入自研模型需要考虑算力投入。训练350亿参数模型较昂贵，应充分利用Azure的按需计算和预约实例来节约成本。Microsoft Frontier Tuning在预览阶段可能需要特殊商业条款，可与微软沟通合作方式。未来，若自研模型推理在微软Foundry上运行，考虑按调用计费模式对比现有OpenAI API成本，确保ROI合适。此外，监测调优过程中云资源使用（例如GPU时长），避免超出预算；有条件时利用本地硬件（如Spark Dev Box）分担部分训练任务以降低云成本，同时关注电力、散热等配套费用。采购部门应与微软协商可能的预览期折扣及产学合作（如梅奥诊所模式）降低费用的途径。

D 相关角色与责任（RACI）

角色 主要责任（在模型定制与应用时）
业务Owner 决定模型定制的战略目标（如提高客服准确率、降低成本等）；提供所需行业知识与用例场景定义，确保模型开发对准业务需求；在验收阶段评估模型ROI并批准上线与推广。
IT部门 提供所需计算资源和基础设施支持（云GPU、本地算力设备等）；负责部署和维护Foundry、模型训练环境；监控模型运行时的性能/可用性；确保模型与现有系统集成顺畅。
安全/合规团队 审查训练数据集及模型输出，确保遵循数据隐私和行业监管要求；配置并应用ACS、ASSERT等安全框架保障模型行为在合规范围内；建立模型上线前/后的审核流程。
数据团队 收集、清洗、标注用于模型调优的企业数据；确保数据覆盖业务场景且降低偏差；执行数据脱敏和授权；在模型使用期间持续提供新数据用于模型更新。
开发团队 负责模型调优实施（配置Frontier Tuning、编写强化学习脚本等）；开发模型集成接口和应用逻辑；运行和评估模型性能，调整参数直至达到预期输出效果；可能需要开发保障模型资源管理、扩容等辅助工具。
采购/财务 评估模型调优和托管服务的预算；与微软协商Frontier Tuning服务条款和费用；采购必要的硬件（如开发者高性能工作站）；监控训练与推理阶段云资源费用，调整资源配置避免超支，确保项目经济可行。

E 7/30/90 天行动清单

主题 4：开发者平台与运行时（Foundry、Agent Framework、评测治理体系）

A 深度总结（10要点）

  1. Microsoft Foundry 平台：微软完善了Microsoft Foundry 平台，确立其为企业级智能体运行时核心。Foundry集合模型服务、工具箱、跟踪评估和持续优化能力，支持各类AI智能体在上面开发、部署、观测、改进生命周期的闭环管理。正如微软所述：“Foundry 就是专为这个现实设计的智能体运行时”，无论任务或成本要求如何，开发者都可以在Foundry上选择最佳模型并通过自动路由平衡质量、速度和成本。
  2. Microsoft Agent Framework (MAF)：MAF v1.0 在Build 2026宣布正式GA。MAF是用于构建AI智能体的框架，将“智能体”作为一等概念提供：包括技能、上下文、记忆和中间件等模块，帮助开发者将不同AI服务（如GitHub Copilot SDK或Anthropic Claude）纳入一个确定性可控的智能体工作流。开发者可以无缝地把多种智能体或模型嵌入到MAF workflow中，组合它们的能力而不用担心不可预测的竞态，MAF会确保依序执行。
  3. Hosted Agents（Foundry Agent Service）：微软发布Foundry Agent Service的Hosted Agents功能（预览），提供即启即用、隔离的会话级沙箱来运行不受信任代码。Hosted Agents实现子100毫秒冷启动和零空闲成本的无服务器智能体执行环境。微软将其类比为“智能体的容器”，意味它提供类似容器对云原生应用的价值：弹性可扩展、隔离安全、随时调度。企业部署Hosted Agents，可让智能体调度调优后在大规模负载下可靠运行，同时降低资源浪费。
  4. Toolboxes 工具箱：新的Toolboxes 功能（预览）在Foundry中统一管理智能体的各种功能扩展。这包括Web检索（接入Web IQ）、文件/产品文档搜索、Azure SQL数据库查询、MCP模型场景工具等多个类型，使开发者能在Foundry内通过单一端点调用所有已注册工具。这解决了以往智能体接入大量外部工具的碎片化问题，让工具接入与权限可被统一治理。举例来说，一家企业可以在Foundry Toolbox中预注册自家内网API和知识库，让后续构建的所有智能体统一调用这些能力。
  5. Observability & Evaluation：微软为生产智能体提供了完善的可观测性与评估框架。Foundry内建OpenTelemetry兼容的Tracing系统，将智能体的每步操作都记录在案，便于审计和调试。此外，Adaptive Evaluations（预览）将策略要求转化为自动测试，实现即时行为评估。由此，每次智能体运行都会生成“行为足迹”，并即时通过评估指标反馈质量，为持续改进提供依据。
  6. Agent Optimizer：微软披露Foundry Agent Service即将上线Agent Optimizer（预览），自动根据智能体的追踪和评估结果生成改进建议。它会针对提示、工具选择、技能调用、上下文使用等方面给出优化建议，提供差异比较和一键回滚可能修改。这为AgentOps（智能体运维）提供了类似DevOps在传统软件中持续改进软件的能力：让生产环境的数据和信号直接驱动智能体升级。
  7. Agent Control Specification (ACS)：微软开源发布了 Agent Control Specification (ACS)，作为AI智能体运行时的治理层开放标准。ACS通过便携的策略清单（manifest）来定义在智能体执行循环的8个拦截点上如何评估和强制执行策略。这与具体智能体框架或执行环境无关，使智能体安全策略可跨框架迁移。借助ACS，开发、合规与安全团队可以以统一方式定义AI智能体可做/不可做的行为以及何时需要人类审批。ACS是Agent Governance Toolkit的一部分，帮助企业标准化智能体治理。
  8. ASSERT 评测框架：微软发布 ASSERT（Adaptive Spec-driven Scoring for Evaluation & Regression Testing），用于将智能体行为规范翻译为机器可执行的自动测试。开发者可使用自然语言编写对智能体预期行为的描述（policy/spec），ASSERT框架会将其结构化为场景和用例，对智能体进行分层次测试并给出定量得分。实际验证显示，相较基准方法，ASSERT覆盖了1.2倍的问题空间、发现1.5倍更多值得关注的案例，能更好区分不同模型/智能体的优劣。这一工具将成为企业质量保证 (QA) 团队的利器，有助于在部署前充分测试智能体行为。
  9. Foundry 开发者工具：为提高开发体验，微软发布Foundry 工具包 (Toolkit) for VS Code（现已GA）。这一插件支持开发者在VS Code中直接编写和调试智能体应用，并将Foundry丰富的模型、工具、上下文直接集成IDE。开发者还可使用GitHub Copilot SDK（现已GA，支持多种语言）将Copilot智能体集成至自有应用或服务当中。GitHub Copilot SDK提供与Copilot应用相同的agentic runtime，让开发者可创建自定义智能体或扩展现有Copilot。此外，Foundry还支持包括LangGraph、Claude Agent SDK等多种智能体框架，方便企业利用不同的开源或商用AI代理技术。
  10. Teams & M365 发布：为了让智能体开发成果迅速服务终端用户，微软宣布Foundry将提供一键发布的能力到Microsoft Teams 和Microsoft 365 Copilot。这意味着开发者构建的智能体可以通过几乎无缝的方式出现在Teams对话界面或Office应用里，带着完整的身份和租户策略环境。智能体界面与用户熟悉的工作流融为一体，有助于加快企业内部推广应用AI智能体的步伐。

B 企业使用场景

  • IT 服务管理：大型零售连锁企业IT部门利用Microsoft Foundry构建内部IT支持智能体。开发团队使用MAF框架快速组装了一个能理解员工技术请求的智能体，并通过Toolbox调用企业知识库和PowerShell脚本来解答或自动处理常见IT问题（如密码重置、软件安装）。应用Hosted Agents，使这些智能体可以按需大规模并发处理请求，而无需预分配常驻服务器。同时Agent 365持续监控这些智能体调用系统命令的行为，保障不会越权操作。启用OpenTelemetry追踪后，IT经理可以实时查看每个支持请求的智能体回答细节和响应时间，从而精细评估智能体服务质量。
  • 软件开发流程：金融科技公司将AI智能体引入软件开发流水线。开发团队在Foundry上创建了代码审核智能体，并应用ASSERT定义了一系列代码规范检查规则。当开发者提交Pull Request时，智能体自动检查代码风格、一致性和潜在安全缺陷，并附上评估报告。通过Copilot CLI的新功能（/fleet），某些静态分析任务可交由本地轻量模型执行，节省云端调用。开发经理通过Agent Control Spec在不同阶段设定Agent行为拦截点（如禁止合并未经智能体审核通过的代码），确保开发流程符合质量标准。
  • 数据分析：保险公司的数据团队应用Foundry平台创建数据分析助手智能体。借助Foundry IQ集成，智能体可访问数据仓库和文档报告等知识源，能响应高管提出的复杂数据问题。Toolbox使智能体可以直接运行SQL查询或调用BI报表API获取实时数据。当管理层提出新的数据需求时，开发者可在Foundry里快速调试智能体查询流程，并通过Hosted Agents方案在业务高峰时弹性扩展算力。Foundry的可观测性允许数据团队看到每次分析任务所用的模型、工具调用和结果，让他们持续优化智能体回答准确性。
  • 供应链管理：制造企业开发了供应链智能体应用。通过Foundry Agent Framework，该智能体结合多个AI服务：一个模型负责预测库存需求，另一个模型生成采购订单，第三个子智能体监控物流延迟。Foundry确保这些子智能体按顺序执行并共享上下文（库存数据、采购规则），不会相互干扰。IT部门通过Agent 365设置策略，规定此智能体只能访问采购系统API、不可访问财务系统，从而限定权限。供应链部门报告，智能体帮助他们将库存周转天数降低了10%，采购响应速度提高显著。【待核实：10%周转天数减少的数据来源】
  • AI运维 (AgentOps)：科技企业的AI平台团队把AgentOps实践纳入工作流。每当一个面向客户的AI智能客服Agent上线，他们通过Foundry自带的tracing和evaluation每周监控其表现，收集对话质量评分。然后利用Agent Optimizer生成优化建议，发现某些场景下Agent表现不佳，通过调优提示或工具配置进行改进。每次改进前都由ACS策略限制新Agent行为（如禁止特定回复），再通过一键回滚机制确保安全试验。这种持续改进循环让AI客服质量在数月内明显提升，问题解决率提高了约15%。【待核实：15%提升为假设值，需企业内部统计数据验证】

C 如何落地（0→1）

  • 前置条件：企业需要具备一定AI开发基础，注册并开通Microsoft Foundry服务。按照Build 2026公布的信息，Foundry和相关Agent Framework在近期要么已GA（例如MAF 1.0）、要么即将预览GA。联系微软销售代表获取Foundry订阅或进入预览计划（Hosted Agents等）。提前准备CI/CD基础设施和Azure权限，特别是权限管理（Azure AD/Entra ID）、网络配置（确保Foundry服务与企业内数据源连通）等。组织内部需要选定试点项目以及组建多技能团队（开发、数据、安全等成员参与），保证技术落地渠道畅通。
  • 架构与集成思路：通过Foundry构建智能体开发运维一体化平台。设置GitHub + Foundry联动：使用GitHub作为智能体代码仓库和协作平台，把构建智能体纳入标准开发生命周期。在Foundry上，搭建Agent Service运行时，导入应用所需模型（MAI系列或OpenAI等）和Toolbox工具，将MCP相关服务/工具注册其中（如接入Web IQ，文件检索等）。把Agent 365结合Foundry，确保开发出的智能体一经部署就进入IT可见的管理范围。同时，在开发流程中引入开源智能体治理库（ACS、ASSERT），让安全/合规要求从开发阶段就融入Agent逻辑。最终，设计一键部署管道从Foundry发布Agent至Teams/M365，确保用户触手可及。
  • 权限与合规：规划Foundry平台时，需强制纳入企业安全/治理管道。利用Agent 365和ACS对不同环境Agent的权限和活动进行政策设定。例如，在测试环境，允许Agent访问仿真系统和虚拟数据；在生产环境，必须通过Entra ID赋予明确权限且限定于最小范围。确保日志和评价指标可追溯：OpenTelemetry的trace日志存在和访问需满足审计要求，由安全团队定期检查。对智能体所有交互保留审核记录。安全团队应该主导设定评分阈值和告警规则。如果Foundry Agent检测到异常行为或评估得分低于阈值，可配置自动暂停Agent实例并通知负责人。
  • 试点范围：在全面推广智能体开发平台之前，建议选一个垂直领域或团队进行试点。例如从内部IT自动化或客服Agent开发流程入手进行实践。通过在小范围试点，评估Foundry工具链对开发效率提升（如开发时间缩短X%）以及运营稳定性的帮助，然后再扩展至更多部门。试点期间关注开发者学习曲线：提供培训，确保团队熟练使用Copilot SDK、MAF等新工具。
  • 指标与验收：跟踪开发者平台的ROI。研发效率指标包括：Agent开发周期缩短时间，新Agent上线频率；质量指标包括：智能体产品错误率下降，关键行动全程可追溯率，策略违例事件数量降低。运营指标包括：Hosted Agents的资源利用率提升（减少闲置）、扩容时间减少，MTTR（平均恢复时间）降低等。通过这些指标对试点进行验收，确认Foundry平台是否在降本增效。如果效果达成，则沿成功模式推广；如某些指标未达预期，分析原因——例如开发团队可能需要更多培训或平台配置需要优化——再进一步完善。
  • 风险与缓解：实施过程中可能出现风险：一是新平台不稳定或集成复杂导致的项目进度延误。为此可与微软技术团队定期沟通，及时获得支持与最新补丁。二是开发者采用阻力：新工具和流程需要培训，因此安排专业赋能（如微软提供的Copilot加速器资源），并在团队内培养“智能体教练”，答疑解惑。第三，安全合规风险：Agent误用系统资源或数据。对此在开发和部署阶段就要使用ACS防范，此外通过MXC容器或Windows 365沙盒限制Agent执行环境。最后，持续调整组织流程**，比如将Agent开发纳入正式DevSecOps流程，由安全团队和架构师共同评审每个Agent上线申请，形成制度化的缓解。
  • 成本与计费关注点：评估采用Foundry等平台的总成本需综合考虑平台订阅或按量费用、云计算资源费用以及人力投入。微软Foundry平台目前可能处于预览或定制合作阶段**【待核实】，需与微软谈判费用模式。一般情况下，Foundry服务可能按租户月费叠加使用量收费【待核实】。Hosted Agents弹性伸缩可降低闲置成本，但同时需注意峰值用量带来的费用波动。使用Azure GPU推理和模型服务将产生runtime费用，应通过负载测试预估典型月度消耗。采购部门还需关注Copilot Studio和GitHub Copilot企业版**等开发工具订阅费用。将这些成本与未使用AI时的运营成本对比计算ROI，并追踪试点期实际费用以调整资源配额或上云 vs. 本地部署的策略。

D 相关角色与责任（RACI）

角色 主要责任（在构建开发者平台与运行时时）
业务Owner 从业务角度支持AI平台搭建（如提供测试用例、评估业务效益）；协调跨部门资源投入Foundry项目；决定试点应用场景及成功标准。
IT部门 主导Foundry平台部署与维护；确保平台与企业基础设施（网络、身份认证等）集成；提供云资源及运维支持；建立对智能体服务的监控和报警机制。
安全/合规团队 设计并部署智能体治理策略（ACS规则、权限范围）；在开发和部署过程中评审安全问题；持续监控Foundry平台上的Agent行为日志和评估结果，处理异常情况。
数据团队 协助配置Foundry与企业数据系统的连接，确保智能体需要的知识库/数据库能被安全访问；调整Foundry IQ知识源，保证Agent查询到最新准确数据；监控模型推理效果，提供数据支持进行性能调优。
开发团队 实现智能体开发与集成，使用MAF、Toolbox等开发Agent逻辑；编写自动化部署Pipeline，使新Agent能快速上线到Teams/M365；根据观察指标调整Agent性能；开发满足业务需求的新功能并持续迭代改进。
采购/财务 参与Foundry/Agent 365平台的商业合同谈判，确保了解订阅或预览费用结构；监督试点和扩展期间的平台和云资源费用；协调将开发者平台相关成本纳入年度预算并跟踪ROI。

E 7/30/90 天行动清单

主题 5：安全与隔离（MXC 沙箱、身份与权限、审计、后量子安全）

A 深度总结（10要点）

  1. MXC 安全沙箱：微软推出Microsoft Execution Containers (MXC)，为AI智能体提供由操作系统原生支持的策略驱动型沙箱环境（现预览）。MXC允许开发者和IT管理员定义智能体的访问权限（如文件、网络、UI等），由Windows内核在智能体运行时强制执行这些边界。MXC支持多级隔离：从快速进程隔离（GitHub Copilot CLI已经使用）到微虚拟机，乃至集成于Windows 365的完整云实例。通过MXC，企业可以在PC、VM、云端等各层面拥有统一的Agent隔离管控能力。
  2. 智能体身份与可控性：随着智能体在企业环境中的自主性增强，微软引入了智能体身份和可控性概念，以确保每个Agent都是可管理的。OS强制智能体身份：Windows能为本地Agent分配独立的本地或云身份（通过Entra ID），将其所有操作都关联到该身份，明确区分人类用户与Agent。Agent 365 原生集成MXC（2026年7月预览），Agent 365 平台将Entra身份、Intune设备管理、Defender威胁防护和Purview数据治理等安全能力层叠到MXC环境，帮助IT部门统一管理本地Agent的隔离和权限。通过这些机制，企业可以为每个Agent设置精细粒度的权限边界，并监控/限制其执行权限，防范潜在风险。
  3. 自主安全智能体 (MDASH)：微软安全团队研发了多模型Agentic安全扫描系统“MDASH”，用100多个特化AI智能体组成漏洞挖掘与验证流水线。MDASH能够自动地发现、论证并修复软件（如Windows OS）中的复杂漏洞：通过“审计Agent”扫描代码发掘潜在漏洞，再由“辩论Agent”验证漏洞可利用性，最后用“验证Agent”自动生成漏洞利用输入进行确认。在内部评测中，MDASH实现了对历史漏洞96%召回率、在CyberGym公开基准赛上取得88.45%顶级成绩。微软已将MDASH应用于内部工程实践（如在2026年5月的Windows补丁星期发现16处重要漏洞）。MDASH系统表明安全领域的AI应用也需要多智能体协作，并获得生产实用级成效，将AI用于超大规模漏洞发现和修复成为现实。
  4. 加密与后量子安全：微软在Build 2026上加强量子安全战略。Windows 11操作系统进一步扩展了对后量子加密 (PQC) 算法的支持：TLS协议栈已导入PQC混合密钥交换机制，Windows加密API (CNG) 与证书功能支持组合PQC算法，Active Directory证书服务可颁发PQC证书。这些增强为企业IT环境提前适应未来量子计算威胁做好准备。微软还在持续推进新式网络协议安全：与AMD、Intel、NVIDIA等共同开发多路径可靠连接 (MRC) 网络协议，通过在端点引入智能，使数据流可以动态避障，提高云工作负载可靠性。MRC提供了更高效、抗故障的网络传输，提升大型AI模型在云上的性能稳定性。
  5. 安全贯穿开发全流程：Build 2026的发布体现微软将安全“内建”而非“外加”的理念。从开发初期到部署运营，均有对应工具：Copilot Studio 中就提供治理仪表盘用于实时监控所构建智能体调用的数据与行为；Agent Control Specification 为Agent运行时提供跨平台一致的基本安全规范；ACS、ASSERT 等可帮助开发者在上线前发现并修复潜在不当行为。Agent 365 则使所有Agent纳入统一管控。这些举措表明企业有工具将AI创新置于严格的安全和合规框架之内，降低风险。
  6. Zero Trust 原则应用：智能体时代的安全强化与微软Zero Trust零信任模型密切相关。每个Agent被视为一个不被默认信任的实体，因此在访问所有资源时都需经过验证和授权。MXC和Agent 365将此原则执行到底：每个Agent在本地或云中都运行在隔离环境，拥有独立身份，默认不可信任一切系统资源，必须显式授予所需权限。这一理念将安全前置到AI架构，企业利用MXC和Agent 365即相当于从操作系统到底层云全面实施Zero Trust，显著提高AI应用防御水平。
  7. 人机协同：微软强调人类保持在环（Human in the Loop）。例如Microsoft Scout（智能助理Agent）尽管可以自主执行流程，但仍给予用户随时监督和控制的途径，并让管理员配置行为策略。在MDASH漏洞扫描中，Agent找到漏洞会将验证报告反馈给安全工程师决策。通过组合人类和AI的优点，企业才能既享受AI效率又避免完全自动化可能带来的不可控风险。
  8. 伙伴生态：微软正与生态伙伴合作提升AI运行时安全。NVIDIA OpenShell（NVIDIA开源的Agent运行时）已宣布与MXC集成。此外，OpenAI、Nous Research等AI公司宣布将在MXC基础上构建其新的智能体应用。这意味着行业在安全隔离方面逐渐形成共识，微软提供的平台化能力将被广泛采用，企业可以预期未来更多第三方智能体应用将默认兼容这些安全机制，降低企业采用的阻力。
  9. 侧重可审核性：Build 2026的新安全特性都围绕一个核心：可审核（Auditable）。无论是Agent 365提供的Agent目录，还是MXC的强制身份绑定，都确保每个智能体行为可以被事后追踪。例如，企业CISO可随时查看任意时刻有多少Agent在运行、它们访问的资源范围、引入的外部信息源，以及对应消耗的成本。通过这样的透明度，企业更有信心让AI智能体在关键业务中运作，因为一旦出现事故，也能快速追责溯源并采取补救措施。
  10. 从安全到韧性：微软不仅关注智能体的安全，还在提升整个系统的弹性。例如通过MRC网络协议，使AI应用不受网络抖动影响持续运行；通过在Windows和云中齐备容器化技术（MXC），提高跨环境的一致性。这些举措共同构成企业AI基础设施的“双保险”，即使出现意外行为或部分故障，系统也能迅速隔离问题并自动追路切换，确保业务不中断。

B 企业使用场景

  • 法规遵从：大型会计师事务所部署AI合规审计Agent监督员工使用AI。该Agent基于ACS标准监控所有企业AI智能体的对外输出（如邮件回复、文档生成）。一旦检测到潜在违规内容（例如泄露客户信息），Agent立即根据策略拦截输出，要求人工审批并记录事件日志，确保AI在严格遵守公司合规政策框架下运行。
  • IT 安全运维：能源公司引入MXC环境在员工电脑上安全运行各种AI助手。比如安装**“代码修复Agent”帮助开发者调试软件，但通过MXC将其限制在只读源代码目录、禁用互联网访问以防止数据泄露。安全团队通过Agent 365管理每个Agent容器的策略配置，统一推送更新和策略**。随着Agent表现得到验证，范围逐步扩大到更多员工终端，提升生产力的同时确保安全防护不松懈。
  • 渗透测试：网络安全公司利用多智能体架构开发自动渗透测试Agent。它运行在Azure VM上，通过MDASH风格的方法调用多个子Agent扫描客户网络，尝试发现弱点并提供报告。为了避免Agent误用资源或造成损害，公司通过MXC容器和ACS预设测试边界（例如，只允许攻击隔离环境、不触碰生产网络），同时记录所有操作。这样，公司在提升测试效率的同时确保过程受控、结果可信。
  • 数据分享管控：医疗机构部署智能体DLP监控。Work IQ帮助整合了企业聊天、邮件内容，为合规Agent提供上下文。该Agent运行在MXC中持续分析聊天对话和文档外发行为，一旦发现医生试图通过智能助手分享含患者敏感信息的数据图表，Agent将触发防护动作：通过Purview标签识别违规数据并即时阻断消息发送，然后警告用户并报告给合规团队。MXC确保此监控Agent自身没有访问权限以外的数据，Agent 365则记下每一次阻断行为供审计。【待核实：MXC环境下DLP Agent示例需要参考实现】
  • 量子安全过渡：金融机构的CISO团队跟进微软PQC升级进展，并开始采用后量子算法试点。例如，在内部PKI系统中启用支持PQC的证书颁发（基于Windows ADCS的更新），在试验环境让内部服务切换到组合PQC密钥交换模式。同时，聘请安全顾问评估系统对量子攻击的脆弱性，制定路线图准备在微软PQC方案全面GA时迅速切换。通过提前部署微软的PQC能力，该金融机构获得先发安全优势。

C 如何落地（0→1）

  • 前置条件：企业需要现有安全架构基础相对完善，拥有统一的身份管理（如Azure AD/Entra）、设备管理（Intune）、安全信息与事件管理（SIEM）等。联系微软获取MXC 预览版（若在7月或之后可申请Agent 365+MXC预览），确保所需Windows 11版本、Intune等达到要求。安全团队应提前梳理企业AI治理需求：如哪些操作需禁用、哪些场景必须人工审核、对AI使用日志保存要求等，形成初步政策框架作为ACS的输入依据。对于对外AI服务（如Integration with ChatGPT Plugins），需要明确数据共享边界或考虑自建Web IQ以避免敏感信息外泄。
  • 架构与集成思路：采用多层次防御架构。终端层：在Windows 11设备上部署MXC，显式定义本地Agent容器策略。配置Intune策略将MXC和Agent容器在企业设备上统一启用并加固设置。云层：在Azure侧使用Windows 365 for Agents或Hosted Agents提供Cloud PC隔离环境来运行需要访问UI/遗留系统的AI智能体。建统一Agent 365门户，实现对本地和云Agent的一体化管理。为开发者/管理员提供Copilot Studio 或Defender门户界面以配置安全策略和查看Agent活动日志。设计安全自动化：如SIEM集成Agent活动日志，配置告警规则。确保硬件层也跟进：比如考虑采购安全硬件（如支持Secured-core PC的Spark Dev Box）给AI开发者，提升从芯片到应用的安全性。
  • 权限与合规：严格落实最小权限。每个Agent在Agent 365中应设定明确的数据/系统访问清单，超出即禁止。利用Entra ID为Agent分配独立身份和角色，避免共用账号难以溯源。配置Defender策略监控Agent行为，若触发安全规则（如尝试修改未经授权文件）则自动隔离。合规团队应特别关注AI使用过程中隐私数据处理：如通过Purview 屏蔽智能体结果中的PII。对外提供AI功能时，遵循“负责AI”准则：透明地向终端用户标明AI参与，同时记录用户反馈（如不当输出可举报），以满足监管审查。考虑建立AI伦理委员会定期审视智能体决策逻辑符合企业和社会价值观。
  • 试点范围：优先选择内部AI项目进行安全与隔离机制试点，以免初期问题影响客户。示例：在研发部门内部推出一个“AI代码助手”Agent，由开发者在MXC容器中使用，让安全团队观察其行为。或选取一组高阶用户试用Microsoft Scout（通过Frontier计划），让他们的工作流程由Agent辅助，期间收集安全相关指标（如Agent错误尝试权限次数）。试点应有明确时长（4-6周）和定性评估（用户信任感、Agent遵规程度），以便在小范围验证MXC、ACS等的有效性和可用性。
  • 指标与验收：设定衡量智能体安全落地效果的指标，例如：Agent违规事件数（理想为0）、权限异常拦截次数（正确拦截越多表明策略有效）、系统无故障运行时长（MTBF）等。也可跟踪安全运营时间节省：如MDASH Agent扫描发现在研代码的严重漏洞数量和人工+传统工具相比的提升幅度。验收时看这些指标：若关键指标未达标（如仍发生越权访问），需查明原因调整策略（如策略规则完善或技术bug修复）。满足标准的则可认为安全机制落地成功，并计划推广覆盖更多AI项目及用户。
  • 风险与缓解：AI安全最大的风险是未知未知（Agent自主行为难完全预测）。因此需要多重缓解：1）前置测试 – 在上线前用ASSERT尽可能枚举行为场景测试Agent反应，提前发现异常。2）监控告警 – 上线后24/7监控Agent日志与输出，配置关键字或行为模式告警通知。3）预设Kill Switch – 为每个Agent预置紧急停用开关，一旦发现严重异常行为（如连续未授权访问）立即手动或自动停用其进程及账号。4）持续改进 – 定期复盘每个风险事件，更新Agent Control Spec策略和模型，以减少重犯可能。通过这些措施，企业可以将风险降低到可接受水平。
  • 成本与计费关注点：安全与隔离方案往往需要额外资源。如MXC容器可能要求升级终端设备（满足最新Windows安全要求），Agent 365带来的管理工作量需考虑人员成本。MDASH等安全AI在预览期不一定面向全部客户【待核实：MDASH 交付方式与成本】。但部署这样的AI安全工具有潜在替代人工的收益。采购团队需要评估软硬件改造费用与安全投资ROI，同时争取微软安全套件（如Defender、Purview）内集成附赠的价值。Track Windows 365 for Agents按使用量成本和终端硬件成本，将Agent隔离安全纳入IT预算。对于关键的PQC升级，与基础设施供应商配合确认软件升级可能带来的支持成本和风险，不宜引入过早导致兼容性问题，要把成本与风险平衡考虑。

D 相关角色与责任（RACI）

角色 主要责任（在安全与隔离体系实施时）
业务Owner 提供对AI安全的战略指导，确保安全措施与业务连续性間平衡；批准关键安全规范与合规策略变更；在出现安全事故时协调业务应急响应。
IT部门 集成MXC、Agent 365等技术到现有IT环境；配置终端设备策略（Intune等）并实施Zero Trust准则；监控AI服务运行，处理技术层安全事件；升级系统及应用以支持PQC。
安全/合规团队 制定AI智能体使用的安全与合规政策（如ACS策略文件）；配置持续监控与告警，审核Agent行为日志；领导应急响应，协调修复AI导致的安全问题；密切关注法规动向调整内部政策。
数据团队 参与定义数据安全/隐私策略在AI上下文层的实现，确保敏感数据标记正确；配合安全团队调整Purview标签或DLP规则；当安全控件影响数据可用性时提出改进方案。
开发团队 在开发阶段贯彻安全要求，将ACS、ASSERT等工具融入开发流程；及时修复安全团队发现的模型或Agent逻辑问题；积极参与安全测试演练，提供技术支持确保Agent能安全着陆。
采购/财务 评估安全与隔离方案的资金投入及维护成本；管理与微软及安全供应商的合同谈判（安全软件、硬件采购）；在安全方面的投资回报分析，支持决策层了解投入必要性。

E 7/30/90 天行动清单

主题 6：数据与分析平台（Fabric、数据库更新等）

A 深度总结（10要点）

  1. Azure HorizonDB 数据库：发布 Azure HorizonDB（预览），这是Azure上一种全新企业级托管PostgreSQL数据库服务，专门为智能体应用设计。HorizonDB以Postgres兼容性为基础，提供超低延迟、高可用的事务处理和查询能力。其显著特点包括：内置高级向量索引（DiskANN+球面量化），支持语义搜索；内嵌AI模型调用（借助azure_ai扩展，可在SQL查询中直接调用GPT类模型进行推理）；与Microsoft Fabric和Foundry高度集成。内部测试显示HorizonDB的事务吞吐和搜索性能比自管Postgres提升3倍以上。这意味着开发者可在熟悉的PG数据库上直接开发下一代智能应用，无需来回穿梭于数据库和AI服务。
  2. Microsoft Fabric 更新：Fabric作为微软统一分析平台，也在Build 2026推出多项更新以拥抱智能体时代。其中重要一项是Fabric Data Warehouse 引入GPU加速（早期预览），使部分查询可直接在NVIDIA GPU上执行。无需用户改写SQL或调整基础设施，只需在工作区设置中启用硬件加速，查询优化器即可在合适情况下将计算下推GPU。微软称在内部测试中Fabric Data Warehouse对典型报表和AI驱动分析工作负载性能达7倍提升。同时，Fabric宣布图数据库功能正式GA，并预告规划建模能力本月上线，进一步丰富数据分析场景。这些改进让开发者无需引入额外数据平台也能支持实时、大规模的AI分析应用。
  3. Rayfin 开源后端服务：微软推出Rayfin（预览），一个开源SDK和CLI工具，用于自动生成应用后端并部署到Fabric托管环境。Rayfin旨在填补AI快速生成应用与生产部署之间的鸿沟：开发者只需以代码或自然语言描述所需应用，Rayfin即可生成类型安全、附带治理的后端，包括数据库Schema、认证、存储以及访问策略。然后一条CLI命令即可将该后端部署在Microsoft Fabric上，自动继承租户的安全、合规控制，数据默认写入OneLake避免额外ETL。Rayfin与AI代码生成平台Replit集成（合作），用户可在Replit快速构建前端UI，用Rayfin将应用上云生产。这对于企业来说意味着开发到上线周期显著缩短，并且每个由AI创建的应用天生符合公司安全与数据治理要求。
  4. Foundry IQ Serverless：Foundry IQ（企业知识检索层）推出Serverless模式（预览），可按需启动、零保留成本地提供上下文检索服务。企业无需预配服务器，通过Serverless Foundry IQ即可实现自动弹性的上下文查询，按使用量付费。这降低了搭建语义知识库的门槛，特别适用于新项目或初期规模不大的场景，避免闲置资源浪费。Serverless模式仍提供SLA保证，开发者体验与固定资源版本一致。
  5. Fabric IQ GA：Fabric IQ语义层宣布全面GA。Fabric IQ为智能体提供对结构化业务数据的上下文，让AI可以“理解”数据背后的业务含义和实时状态。例如，Fabric IQ可将数据湖中的销量数据转换为带语义单位的指标，从而Agent可以基于此回答“上季度销售额同比增长多少”此类问题。GA后的Fabric IQ确保企业级可用（包括SLA、合规认证），并将与其他IQ能力一起发挥作用，加速数据驱动AI的落地。
  6. Cosmos DB Linux 仿真器 GA：Azure Cosmos DB发布Linux版仿真器（GA）。这一工具允许开发者在本地Linux、macOS或Windows环境离线模拟Cosmos DB，方便构建和验证应用，无需依赖云实例。对于希望利用Cosmos DB打造大规模实时AI应用的企业，这可减少开发调试环节的云成本，并适应多种操作系统下的统一开发流程。
  7. 数据+AI应用统一：微软通过上述举措，描绘了数据平台与AI应用融合的方向。例如，把Rayfin生成的应用后端数据存储在OneLake，在Fabric IQ中暴露语义，Agent构建的应用所产生数据又反哺IQ知识基座。这形成闭环：AI生成应用时已经遵从数据治理规则，应用运行时产生的数据又持续更新企业数据资产。对企业而言意味着越用AI，数据资产越丰富，反之又提升AI决策质量，真正实现数据-模型-应用的正反馈循环。
  8. 异构数据协同：Azure HorizonDB的引入体现微软对多样化数据需求的支持。HorizonDB侧重关系+向量融合查询，用于丰富语义语料；Fabric Data Warehouse引入GPU则服务于高并发/大计算需求。【待核实】微软可能还更新了其他数据库或大数据服务以适应AI，例如Azure Cosmos DB或Azure Data Explorer等，与HorizonDB和Fabric形成互补生态。企业可以根据自身场景，灵活选用这些服务搭配：例如文本嵌入数据存在HorizonDB，结构化仓储在Fabric仓库，通过Foundry IQ统一查询。
  9. 成本效益与性能：数据平台升级旨在提升性能和降低TCO。例如，GPU加速查询无需新增配置即能按需提升速度，Horizo​​nDB让企业不必自行改造Postgres来加入向量功能，省去开发与运维成本。Rayfin简化后端开发流程，也可减少基础架构部署时间和人力投入。综合看，这些创新让企业在构建AI应用的过程中能**“花更少，跑更快”**，以较低的云资源和人力投入获取更高数据处理性能和交付速度。
  10. 前瞻方向：数据与分析平台的这些改进表明AI原生数据架构正在成形。未来还可能见到数据即Agent工具的模式——Agent可以直接调用SQL引擎乃至执行分布式查询完成任务。微软Fabric作为全栈数据湖仓技术，将有望逐步与智能体生态更深度融合，实现数据、模型、智能体三位一体的统一平台。

B 企业使用场景

  • 保险风控：保险公司采用Azure HorizonDB构建风险评估服务。它将传统投保数据（结构化表格）与风险图片或事故描述文本嵌入向量统一存储在HorizonDB中。理赔审核智能体在一个SQL查询中既检索历史索赔数值，又进行语义匹配找相似案例文本。比起以往需要在数据库取数后用AI单独处理文本，这一解决方案大幅简化流程、提高实时性。
  • 制造质量分析：制造企业在Microsoft Fabric上启用GPU加速分析。生产线传感器产生大量数据进入Fabric Data Warehouse。通过GPU加速，工厂数据科学团队能在几秒内运行复杂查询，比如实时关联设备日志与产品良率的数据模型输出（过去需数分钟）。结合Fabric IQ，工厂AI助手可以在班组会议上即时回答“本周产线A的不良率趋势如何”，提高生产运维决策效率。
  • 创业团队开发应用：一家物流行业初创使用Rayfin快速开发货运跟踪应用。产品经理用自然语言描述应用逻辑，Rayfin生成后端服务，包括针对包裹数据的数据库Schema和身份权限。团队将前端代码部署，再由Rayfin CLI一键将全套后端推送到Fabric服务，免去配置服务器。整个MVP应用在数小时内即可上线试运行，让初创团队把精力集中在商业逻辑和用户体验上，不必担心基础架构细节。数据统一进入OneLake，方便后续做分析或训练模型。
  • 电商个性化推荐：电商企业将用户浏览和购买数据存入HorizonDB。数据团队利用HorizonDB内置的Azure AI函数，定期触发向量匹配模型在数据库端计算最相似商品，并将结果直接写入推荐表。这样每当用户登录网站，AI智能体无需调用外部服务，而是通过Fabric IQ检索本地推荐结果即可展示“你可能喜欢”的商品列表，降低推荐延迟。同时，通过Fabric GPU加速，推荐模型训练数据的检索效率也提升，大幅缩短模型更新周期。
  • 金融数仓现代化：大型银行使用Fabric Data Warehouse GPU加速和Azure Cosmos DB仿真器试点数据中台升级。他们将部分风险分析任务迁移至Fabric，开启GPU加速选项，使批量风控报告生成提速。在开发阶段，使用COSMOS DB Linux仿真器离线模拟云数据库，进行模型+查询调优，再无缝迁移到生产Azure Cosmos DB，避免云上开发成本。这种组合让银行实现传统数据仓库向AI原生架构的平稳过渡。

C 如何落地（0→1）

  • 前置条件：企业需要具备稳定的数据基础设施和云权限。确保组织已使用或熟悉Azure数据服务（SQL DB、Cosmos DB、Data Lake等），以便迁移应用HorizonDB、Fabric等新服务。对于Rayfin，需要有GitHub账号和Microsoft Fabric订阅，同时可能要申请Rayfin预览。提前让数据工程团队掌握向量数据库与语义查询基本概念。硬件上，对Fabric GPU加速，要使用Azure支持GPU的工作区；确认团队订阅级别允许这样的预览/配置。
  • 架构与集成思路：设计AI原生的数据架构。在Azure上部署HorizonDB，通过azure_ai扩展加载所需模型；将HorizonDB与现有数据管道集成（例如从系统实时导入数据）。升级组织的数据仓库到Fabric Data Warehouse，并评估哪些查询适合GPU加速，纳入规划。部署Foundry IQ（或Fabric IQ）作为数据检索中介，方便后续AI应用获取语义化数据。Rayfin集成上，将其纳入开发流程：为新应用定义模板，开发者可以通过Rayfin CLI快速生成后端，流水线自动部署。总体架构要保证数据流无缝：如OneLake成为各应用数据的默认存储，Purview持续扫描这些数据，IQ平台更新知识图谱，让Agent可及时使用新数据。
  • 权限与合规：迁移到新数据平台要考虑数据安全。对现有数据库实施的访问控制要在HorizonDB/Fabric上重新实现或迁移。使用Azure RBAC和Purview分类来保持敏感数据访问的精细权限。尤其HorizonDB的语义功能，可能涉及索引敏感文本embedding，需要在使用前咨询合规团队，看embedding是否算可识别个人信息等。确保Fabric OneLake的数据驻留满足监管（例如在欧盟区数据中心）。Rayfin自动部署的应用背后数据因为在Fabric中，也继承Purview规则：验证Rayfin生成的存储和表都按要求贴上敏感标签。如果向外部第三方分享Rayfin应用API，要审视数据暴露范围并做好API安全配置。
  • 试点范围：先选取一个孤立的数据应用进行试点。比如在IT部或小型业务线，创建一套新应用使用Rayfin生成后端 + Fabric储存，或将次要系统数据迁移到HorizonDB进行测试。通过少量测试用例，确认新的数据服务性能和可靠性满足需求，然后再推广。对于GPU加速和其他Feature，先在测试环境验证效果，确保查询结果正确一致。Rayfin试点中监控生成后端是否满足企业代码规范、数据schema是否合理，以改进Rayfin CLI使用指引。
  • 指标与验收：在试点完成时，根据实际目标验证效果。HorizonDB验证性能指标（查询延迟降低X%、吞吐提升）、功能可用性（语义搜索结果准确率）等。Fabric GPU加速验收通过基准测试前后对比执行时间和资源占用。Rayfin验收重点是开发效率提升（从需求到上线时长缩短多少）、后端质量（部署应用是否稳定、无明显漏洞）。对照这些指标判断是否达到预期，如GPU加速提升未达标，可与微软沟通调优方法或检查SQL优化；Rayfin若生成架构不满足预期，可反馈其团队改善开源项目。经验充分肯定后，高层批准在更多项目推广这些服务。
  • 风险与缓解：主要风险有：新技术不成熟 – 因HorizonDB等处于预览，要防范潜在BUG或文档不足。可在试点期间密切关注服务更新日志，必要时对关键场景保留备份方案（如并行保留原有数据库）。查询正确性 – GPU加速引擎需验证与CPU结果一致性；应有回退方案，比如出现错误自动切换到CPU执行。Rayfin自动生成后端可能不完全符合规范：加强code review并限定Rayfin应用在内部使用暂不对外开放，循序渐进。成本 – 新服务预览阶段定价不明朗【待核实：HorizonDB/Fabric GPU加速价格】。可通过Azure Cost Management工具设置预算和警报防止超支。依赖成熟度 – 由于Horizo​​nDB/FoundryIQ这些服务较新，确保团队与微软支持保持联络，及时获得技术支援和补丁。
  • 成本与计费关注点：Azure HorizonDB可能采用按vCore/存储收费，与标准Postgres相比有溢价因附加功能。Fabric Data Warehouse GPU加速或许按查询量或GPU时间收费而非固定成本【待核实】。Rayfin作为开源工具本身无直接成本，但其生成的Fabric服务会产生Fabric平台使用费用（按Compute和Storage usage）。企业应在试点期使用Azure定价计算器估算新方案成本，并考虑预留实例或容量模式节约。监控OneLake存储增长趋势及时清理无用数据以节省费用。采购团队需关注各服务GA后的正式定价结构，如HorizonDB GA时是否按标准Azure数据库定价供应，以及Fabric全面GA后的定价。总体而言，合理使用预览免费额度、云抵扣（Azure credit）等，可以降低初始试水成本。

D 相关角色与责任（RACI）

角色 主要责任（在升级数据与分析平台时）
业务Owner 确定数据平台升级服务于哪些业务用例（如更快数据分析、更丰富AI应用）；提供必要投入（预算、人力）；衡量新平台对业务KPI的影响（如决策提速、成本降低）。
IT部门 规划并实施HorizonDB、Fabric等新服务部署；调整数据架构设计，确保新旧系统平滑过渡；管理数据迁移和Pipelines稳定；召开性能测试确保满足业务SLA。
安全/合规团队 审查新数据平台对数据安全策略影响；验证HorizonDB、OneLake权限配置满足现有政策要求；监控Rayfin生成后端的访问接口确保遵循安全标准；持续评估第三方数据服务合规性。
数据团队 主导数据存储与检索方案落地：配置HorizonDB索引/模型扩展；为Fabric IQ和Foundry IQ创建知识源；优化GPU加速查询逻辑；保证数据质量；培训团队掌握语义查询技术。
开发团队 利用Rayfin、模型函数等开发新应用；修改现有应用连接新数据库/数据源；编写必要的Glue代码确保数据写入OneLake、Foundry IQ可读取；调试因新平台引入的问题。
采购/财务 与微软签订新服务使用协议/订阅；监控预览服务费用和转正后的价格模型；协调内部对项目成本收益的沟通，确保资源投入与产出匹配。

E 7/30/90 天行动清单

主题 8：GitHub 方向（Copilot 应用、代码智能体、SDLC 自动化）

A 深度总结（10要点）

  1. GitHub Copilot 桌面应用：微软发布GitHub Copilot App（桌面版，本次Build提供技术预览）。这是一款Agent原生的桌面开发环境，直接集成在开发者熟悉的GitHub平台中。Copilot App允许开发者从Issue、PR或先前Session入手，由AI智能体基于已有项目上下文并行创建多个Session。其核心是将AI智能体深度融入开发流程：每个Session以git worktree形式隔离，确保多任务并行时代码变更互不干扰；提供Agent Merge功能，智能体可协助PR的审查、测试和合并；通过“My Work”视图集中展示个人跨仓库任务、会话状态，帮助开发者统筹多个Agent工作流。Copilot App支持Windows（含Arm）、macOS和Linux，需GitHub Copilot订阅，未来将向免费版开放。
  2. Copilot CLI 更新：GitHub Copilot CLI 在命令行工具中新增 /fleet 参数（预览），支持将任务委派给本地子智能体。具体而言，Copilot CLI当分析命令请求时，主Agent在云端构建任务计划，然后根据任务复杂度将部分步骤交给本地模型的子Agent执行。例如，/fleet模式下，一个复杂shell脚本可拆解成若干函数：简单子任务由本地（轻量模型）完成，繁重任务由云上大模型完成。这种混合执行降低了响应延迟和云调用成本，实现**“本地+云”协同**的Agent执行模式。对于注重控制成本和数据不出本地的企业，这一特性意义重大。
  3. Copilot SDK：GitHub Copilot SDK 现已GA，支持多种语言（Node.js/TypeScript、Python、Go、.NET、Rust、Java）。该SDK开放了与Copilot App相同的智能体运行时，让开发者可在自己应用中嵌入AI智能体。例如，企业可使用SDK构建针对内部知识库的定制Copilot助手，或为自有IDE/代码托管平台引入类Copilot的AI配对编程功能。Copilot SDK的发布意味着微软将Copilot定位为开放平台，而非封闭产品，这有利于企业根据需要自由扩展AI开发助手的场景。
  4. AI辅助代码审查：Copilot已扩展其在软件开发生命周期 (SDLC) 中的位置。在Build 2026介绍中，微软提到Copilot Code Review功能增强，新增“中等精度”审查层，可将PR提交路由至更高推理能力的模型进行更深入的分析。这使得AI能够给出更精准的代码评审建议，发现潜在问题的覆盖率提升。【待核实：Code Review中模型和检视规则细节】通过高低不同档次模型的组合使用，企业可在成本和质量之间取得平衡，使AI持续参与每个Pull Request的质量控制工作。
  5. 智能体驱动SDLC 自动化：微软的整体愿景是在开发生命周期的各阶段部署AI智能体。例如，Azure方面已推出Copilot 迁移Agent帮助现代化旧应用。GitHub方向的Copilot App+CLI+SDK让AI不再只是写代码，还管理项目、生成提测环境、优化CI/CD。Build 2026强调开发者应像写普通软件一样构建智能体，遵循source -> test -> deploy -> observe -> improve流程。因此GitHub Copilot扩展的一系列功能正好填补source/test阶段：为Issue/PR生成代码、审查合并、自动化执行。企业可以期待AI逐步融入项目管理、发布管理等环节，从根本上提升DevOps效率。
  6. 代码安全与治理：在让AI参与SDLC的同时，微软也重视开发治理。Copilot CLI在Terminal使用MXC轻量隔离运行，确保所执行代码安全。此外，Assert/ACS等工具可以用于AI生成代码的质量检查和策略约束。例如，企业可设定ACS规则禁止Copilot Agent修改关键配置文件，或Assert确保AI在生成代码时遵循安全准则。微软在Build期间展示了端到端的AI SDLC管理思路，强调工业级AI开发不仅要快，也要安全可控。
  7. 社区与生态：GitHub Copilot生态在扩张。微软宣布Copilot CLI和App的持续改进邀请社区试用提反馈，GitHub官网也扩充了Copilot应用案例与指南。这将带动广大开源社区探索Agentic开发模式，更多第三方工具开始与Copilot整合（例如OpenClaw等Agent框架）。企业技术决策者应关注这些社区动态，因为新兴的AI开发Ops方法论可能成为未来开发流程标准，提前布局可占领先机。
  8. 集成Azure DevOps & ALM：虽然Build主舞台重点在GitHub，微软也开始融通Azure DevOps与Copilot。GitHub Copilot SDK的可用让那些使用Azure DevOps的企业有机会集成AI助手。未来Azure DevOps或GitHub Enterprise Server上或将提供类似Copilot App的体验。企业可通过定制开发实现AI辅助跨版本、跨项目的DevOps任务，如自动生成release notes、跨项目代码重构建议等。
  9. 软件开发范式转变：这些发布预示着软件工程范式的变化。开发者从“一行行手写代码”升级为与AI智能体配合完成软件。GitHub Copilot App把源代码管理、任务跟踪和AI创作融为一体，让开发者能以更高抽象层面指挥coding agent完成具体实现。这要求企业重新思考开发者技能结构、培训以及产出衡量标准。例如，如何评价AI生成代码的质量？如何确保Junior开发者在AI帮助下依然学习原理？这些仍需探索。但可以肯定的是，企业开发流程将更自动化和智能化。
  10. 展望：随着GitHub方向持续演进，企业可期待AI in DevOps进入成熟。一方面，AI可以帮助捕获业务需求（未来或许通过自然语言规划coding tasks），另一方面多Agent协作（如Copilot orchestrating pipeline tasks）将显著缩短交付周期。微软在Build 2026展示了构建-治理-部署智能体的连贯闭环（通过多项产品），如果将此模式扩展到所有软件开发，无疑会带来质的提升，值得企业提前试水、积累经验。

B 企业使用场景

  • 持续集成(CI)管道：游戏开发公司将AI融合到CI流程。为每个Pull Request触发Copilot Code Review，AI进行深入审查发现隐藏的性能问题，并自动附上改进建议。然后Copilot App的Agent Merge功能引导通过测试的PR无缝合并，减少人工占用。CI流水线中还配置Copilot CLI /fleet模式在构建阶段运用本地Agent加速特定任务，提升管线速度。结果，合并错误率降低，CI循环时间缩短约20%。
  • 遗留系统现代化：银行IT部门利用Copilot迁移Agent（Azure Copilot migration agent）扫描旧.NET应用，自动生成现代微服务框架的等效代码结构。AI完成初步迁移代码后，开发者再用Copilot CLI /edit命令与Agent互动细化调整代码逻辑。通过AI协助，这家银行将多年积压的遗留系统升级任务完成时间缩短近一半。
  • 跨项目知识共享：大型科技企业内部建立一个Copilot知识助手：基于GitHub Copilot SDK开发的定制AI，通过统一接口访问公司多个代码库与Wiki。开发人员在IDE里向该助手提问某模块为何这样实现，AI检索关联的PR讨论和设计文档给予解释。因为AI背后连通企业知识图谱，它比一般搜索更精准。同时，AI还能根据关注历史在“我的工作”界面推送可能相关的公司代码更新，帮助开发者快速了解跨项目影响。
  • NoOps 应用：SaaS提供商内部启动一个试验项目，让AI全权开发小型应用。产品经理用GitHub Copilot App创建Issue描述需求，并标记为AI可解决。Copilot App Agent读取Issue后在一个新branch上搭建session开发应用。Agent利用Replit等前端工具生成UI，然后通过Rayfin创建后端（Agent orchestrates CLI操作）。在QA验证基本通过后，该分支被AI Agent自动创建PR并Agent Merge部署上线。尽管人类仍需监督和最终审批，但显示AI能大幅减轻全栈开发工作量。【待核实：完整AI自主开发应用场景目前为实验性质】
  • 安全开发：云服务企业采取多道防线的AI开发模式。开发阶段，即用Copilot CLI让AI时刻在Terminal监视命令执行并提供建议，预防低级错误；代码提交阶段用AI Code Review识别漏洞；部署前最后用MDASH风格的安全Agent审视关键组件安全性。通过AI持续介入各环节，这家公司将安全问题发现前移，避免漏洞流入生产环境，并节省了约30%的人工代码审计时间。

C 如何落地（0→1）

  • 前置条件：评估企业现有开发工具链（GitHub/GitLab、CI/CD、IDE等）与Copilot App/CLI/SDK的适配性。需要GitHub企业账号并订阅GitHub Copilot服务，获取Copilot CLI最新版本（需要PowerShell或Bash环境），关注GitHub Copilot App的预览申请（目前预览阶段，需申请Access）。此外，团队开发者需要学习新工具使用。确保企业代码策略允许AI对存储代码进行分析。若用Copilot SDK开发自定义助手，需要熟悉Node/Python等语言和GitHub API。提前引入Microsoft 365 E5 或Visual Studio企业订阅可能包含Copilot服务，可联系微软了解整合方案。
  • 架构与集成思路：把AI开发助手纳入DevOps流水线。在源代码管理上，使用GitHub平台，并部署Copilot App Windows等客户端给开发者；若需离线版本，则考虑GitHub Copilot Server方案【待核实】。在终端环境，推广使用Copilot CLI，在常用shell脚本上集成。CI/CD服务如GitHub Actions或Azure Pipelines，可配置钩子使用AI进行Code Review：例如配合GitHub REST API，在PR触发时调用Copilot服务（或企业自建模型）进行分析打标签。对于定制需求，开发团队可基于Copilot SDK研发公司内部的AI助手Bot。总体上，目标是在不替换现有开发平台的情况下，将AI嵌入开发者日常工作——不论是写代码的IDE，还是CI的Pull Request流程，都要有AI agent参与。逐步实现AI协助无处不在的开发架构。
  • 权限与合规：企业应更新开发者政策，明确AI如何使用内部代码数据。如要开通Copilot对私有仓库的访问，需评估其潜在数据泄露风险（尽管GitHub承诺不会将私有代码用于训练，但仍要签订保密协议）。对Copilot CLI的本地/云交互，需要保证通过防火墙安全端口访问GitHub服务。安全团队也应监控AI开发助手的输出，防范AI可能引入有害或公开的代码片段。如果企业代码受版权保护，需在Copilot设置中打开限制（防止AI输出训练数据片段）【待核实：Copilot for business自动启用限制吗?】。同时，要求开发者审慎复核AI生成代码，不可盲目接受以防优雅退化或隐藏Bug。最后，持续用ACS等工具监视AI助手操作（特别是未来如果AI能自行commit/merge代码）。
  • 试点范围：选择志愿开发小组试点全面的AI辅助开发流程。比如公司内部一个小型工具项目，从需求、开发到部署全流程引入Copilot助力。记录开发者对Copilot App/CLI的使用频率和成效。小组可以尝试不同AI协作程度：例如A工程师高强度使用AI写代码，B工程师低强度辅助，对比两者结果和质量。这个试点应持续一段时间（至少2-4周）以涵盖完整一个release周期。确保试点项目影响面不大，以免AI可能的不成熟导致线上问题引发重大损失。积累经验后，再制定推广计划。
  • 指标与验收：量化AI赋能开发的效果。关键指标包括：开发速度（从任务开始到完成的平均时间，期望缩短）、代码质量（缺陷率、代码审查发现问题数，期望降低）、开发者满意度（反馈调查，期望正面）等。也跟踪成本：如Copilot对私有仓库的用量费用 vs. 人力节省。验收时，如开发速度显著提升且bug率无明显上升，认为试点成功，可以在更大范围应用。若结果欠佳，如AI建议不准确造成返工，则需要培训或优化配置，如精调提示工程（Prompt Engineering）或暂时降低AI参与程度，直至质量稳定。
  • 风险与缓解：AI参与编码的风险包括错误或不安全代码渗入库。缓解办法：在推行初期，要求更严格的Code Review流程，即每个AI生成的代码必须经人工仔细检查。也可以使用静态分析工具对AI贡献部分重点扫描。另一风险是开发者过度依赖AI导致代码理解能力下降。应强调AI是辅助, 而不是替代，建议定期让团队进行不依赖Copilot的练习保持技能。还有法律风险：AI有时会生成与训练数据类似的代码片段，可能涉及版权。因此企业应该考虑开源许可兼容性和启用Copilot for Business的引用模式或simfilter功能来提防【待核实】。通过加强培训、设置合理边界，就能减少这些风险。
  • 成本与计费关注点：GitHub Copilot企业版按用户月费收费（目前官方价约19美元/用户/月【待核实】），需考虑对多少开发者开通，以及抱怨或浪费的可能。Copilot CLI / App 预览期免费，但GA后也可能计算在同一订阅里。Copilot云服务调用以token用量计费，但GitHub企业版用户通常不限次数，只要scenario不超合理范围。一旦AI参与CI/CD触发频繁，要注意可能提高CI运行时，一些CI可能按分钟收费（GitHub Actions有免费额度，超额收费）。如果团队大量使用AI编写代码，云推理算力消耗巨大，考虑使用本地部署模型替代或MCP hooking local models via /fleet。财务需评估如将AI参与开发推向全员，订阅费用和潜在隐藏成本（CI费用、网络流量）总额。

D 相关角色与责任（RACI）

角色 主要责任（在引入GitHub方向AI工具时）
业务Owner 支持在开发流程中引入AI助手的战略决策；评估它对产品交付节奏和质量的影响；平衡自动化与人力培养之间的策略，确保不影响长期技术能力。
IT部门 负责GitHub/CICD等工具与AI服务的集成配置；维护Copilot访问权限（与GitHub管理员协作）；确保内部代码库与AI助手的安全隔离；监控CI/CD性能开销。
安全/合规团队 审视AI开发助手可能引入的安全和版权隐患；为AI访问企业代码设置政策（如许可范围、数据不出境）；协助开发制定ACS规则控制AI commit/merge等操作。
数据团队 （若涉及AI对企业知识库/数据的调用）准备训练/上下文数据供AI学习公司的代码风格或术语；评估AI在开发过程中获取内部文档或数据的需求并提供相应接口。
开发团队 主动学习并日常使用Copilot App/CLI等工具；反馈AI助手的表现和模型建议改进；在AI帮助下编写/检查代码，调整工作方式；充当内部“AI导师”，指导其他开发者有效使用Copilot。
采购/财务 采购Copilot企业版订阅；监控使用情况避免浪费；在成本证明阶段收集人力节省数据，与投入对比计算ROI；与GitHub销售代表沟通大规模部署的价格优惠可能。

E 7/30/90 天行动清单

  • 7天内：工具准备与团队培训

    GitHub管理员联系GitHub获取Copilot App预览资格和Copilot CLI安装指导。为一个试点团队开通Copilot企业订阅。组织培训会向开发者演示Copilot App的使用、/fleet参数的意义、SDK集成方法。选出几位“AI 教练”负责内部推广和答疑。安全团队制定初步方针，如要求AI输出引用等。

  • 30天内：试点项目进行

    选定一个中小型项目团队为期一个月深度试用AI开发助手。在试点项目中，跟踪AI插手的各个环节（需求记录、编码、code review、测试）效果。持续收集开发者反馈：按周讨论AI哪方面有帮助，哪方面需要人工重做。调整设置，例如是否提高AI建议采纳率或加强输出检查。CI团队逐步将AI code review接入流水线，但暂设置仅提示不自动阻止，通过人工观察其可靠性。
Agent First 的大幕刚启，但属于智能体的时代旋律已在各行各业间回响。微软 Build 2026 告诉我们的，不仅仅是几项酷炫的新功能，更是一种趋势的宣告：工作和生活方式正在重塑。当数字助手升级为“数字同事”，我们需要的不只是新技术，更是一种与 AI 共事的新思维。从日常琐事的自动打理，到复杂任务的高效协同，一个**“人机共生”的职场正在成形。展望未来几年，每个人或许都将拥有属于自己的 AI 担当，就像工业时代每个人都学会使用电力一样自然。这并非科幻，而是大势所趋。当然，新范式也带来新命题——关于信任、隐私、能力边界的探讨才刚开始。但无论如何，拥抱或迟疑，这趟技术演进之旅已不可逆转。重要的是，我们如何参与塑造这个充满潜力的时代，让智能体真正成为增进人类创造力与福祉的力量。
Post Views: 7
Tags: