Project Polaris × Microsoft Build 2026:Azure AI Foundry 支持模型目录大扩容,GitHub Copilot 升级 & 私有化部署

微软 Build 2026 核心发布:Project Polaris——微软自研 MoE 编程模型——将于 2026 年 8 月替换 GitHub Copilot 中的 GPT-4 Turbo。Azure AI Foundry 支持模型目录扩展至 Anthropic、Cohere、DeepSeek、Mistral、xAI 等多厂商,统一计费,并通过 Azure Arc 支持私有化部署。

发布于 更新于 来源 Microsoft

归档条目:由 AI 根据所引信源辅助生成,发布时未经逐篇审阅。责任编辑:Joe Werner。

微软 Build 2026:Project Polaris 与 Azure AI Foundry 多模型扩展,面向 AI 工程团队

微软 Build 2026 上最值得关注的不是某个 Windows 新特性,而是一次模型替换——而且这次替换如此平静,恰恰说明 AI 栈垂直整合已经成为行业常态。

发生了什么

Satya Nadella 在 6 月 2 日旧金山 Fort Mason Center 的主题演讲中开门见山:Agent 已是 Windows 运行时的一等公民。三项紧密相连的发布定义了这次大会。

GitHub Copilot 换上微软自研模型。 Project Polaris 是一个完全在微软基础设施上训练和运行的 MoE 编程模型,将于 2026 年 8 月起取代 GPT-4 Turbo 成为 Copilot 的默认引擎。微软的基准测试显示,Polaris 在 HumanEval 和 MBPP 上均领先 GPT-4 Turbo,尤其在 Rust、Haskell 等低资源语言上提升明显。Pro 版订阅者可获得跨多文件最多 10 万行的上下文窗口,以及自动化测试生成能力。不愿立即迁移的团队有三个月的回退期,之后 Polaris 将成为唯一默认选项。

Azure AI Foundry 成为多厂商模型目录。 以往 Foundry 的模型选择集中在 OpenAI 和 Meta,此次 Build 新增了 Cohere、Mistral 和 Stability AI,并提供统一的原生多模态管道,支持文本、图像、视频和音频输入。同时推出了面向 fine-tuning 和 RAG 的可视化设计器,以及按项目配置的 token 预算和费用告警——这正是企业 AI 平台团队长期以来的核心诉求。

Windows Agent 架构正式定型为三层栈。 Windows Agent Framework v1.0 是 MIT 授权的开发者 SDK,Agent 以 YAML manifest 定义,可无缝部署到本地 Windows 机器、Windows 365 Cloud PC 和 Azure Arc 边缘节点,无需因规模扩大而重新架构。其上是 Windows Agent Runtime(Insider Preview),OS 层级的 Agent 宿主,Agent 以原生 Shell 进程而非应用层守护进程运行。分发通过 Windows Agent Store 进行,这是一个经过安全审查的 Agent Manifest 商城,85% 分成比例。Azure Agent Mesh 是覆盖上述三个部署目标的联邦控制面,根据延迟和 GPU 可用性将 Agent 任务路由到最近的节点,预计 2026 年 Q4 正式 GA,按 Agent 计算 SKU 消耗计费。

Copilot Workspace 正式 GA,带来两种新模式:Fleet(在限定代码库范围内自主执行 CLI 任务,无需逐步确认)和 Autopilot(后台定时处理 Issue,无需开发者在场)。Jira、Datadog 和 ServiceNow 可在活跃 Workspace 会话中作为 Copilot Extensions 调用。

对 AI 工程团队意味着什么

Polaris 迁移重新定义了 GitHub Copilot 在供应商格局中的位置。此前将 Copilot 视为"微软代理的 OpenAI GPT-4"的团队需要更新认知:8 月之后,Copilot 是一个微软主导的推理服务,不再是 OpenAI 的代理入口。这会影响供应商依赖分析、定价预期,以及按任务类型在供应商间切换的路由逻辑。

对于已在 Azure 上运行的工程团队,Foundry 多厂商扩展解决的是另一个问题:无需再单独维护 Cohere、Mistral 和 OpenAI 各自的 API 凭证、配额和账单关系,统一通过 Foundry 接入并集中监控费用。按项目 token 预算功能直接击中多部门 AI 部署的成本归因难题——Foundry 的项目级管控让它成为治理层,而不只是模型宿主。

Azure Agent Mesh 是 2026 年生产规划中值得密切跟踪的架构。它提出的联邦任务路由模式本质上是 HTTP 负载均衡器解决 Web 流量问题的 Agent 版本。关键差异在于 Agent 任务的有状态性远高于典型 HTTP 请求;Mesh 如何跨节点边界处理任务状态,将决定它是真正可用还是演示级产品。Q4 GA 的时间线给团队留出了在生产压力之前评估 Preview 的空间。

需要关注的节点

8 月 Polaris 切换:使用 GitHub Copilot 处理生产编程工作流的团队应尽早在代表性任务上对 Polaris 进行基准测试,尤其是那些微软公开数据中基准覆盖较薄的语言。三个月回退窗口是真实存在的,但不会无限延长。

Foundry 目录扩展与路由整合:如果你目前通过独立 API 合同对接 Cohere 或 Mistral,同时在 Azure 上运行其他工作负载,Foundry 目录更新引出了一个实际的整合问题:费用可见性需求高于供应商灵活性的工作负载,是否值得将路由收口到 Foundry 内部?

Agent Mesh Preview 评估:规划多站点企业 Agent 部署的团队现在就可以开始 Preview 测试。消耗定价方案将在 GA 前公布;联邦任务分发能否满足你的状态管理需求,这个核心设计问题在 Preview 阶段就可以得出答案。

动手试试 / 相关资源

  • Azure AI Foundry — 访问扩展后的模型目录,配置按项目预算,测试多模态管道。
  • Windows Agent Framework(MIT 授权) — YAML 定义的 Agent Manifest,无需重构即可部署到本地、云端和边缘目标。
  • TheRouter 供应商路由指南 涵盖多供应商配置模式;Foundry 目录扩展使 Azure 成为已在 Azure 生态的团队更可行的单一路由聚合点。
帮助与联系