微软正用自研 Project Polaris 替换 Copilot 底层 GPT-4 Turbo,已于8月自动推送。如果你的流程依赖 Copilot 输出的稳定响应形状(如 CI gate、prompt 调优),行为将悄然改变且无任何变更通知。
在某次滚动部署中,此刻正有数以百万计的 GitHub Copilot 会话在悄然切换回答它们的模型。没有变更日志通知会进入你的收件箱。没有任何对话框会征求你的同意。补全结果就这样……变了。这就是这个故事中值得关注的部分。
标题版本——"Microsoft 在 Copilot 中用自研模型替换了 OpenAI 的 GPT-4 Turbo"——是真的,就其本身而言也是一件大事。但对于以写代码为生的人来说真正重要、也更让人不安的版本要更窄、更令人不适:如果你构建过任何将 Copilot 输出视为稳定、可预测产物的系统——CI 门禁、代码生成流水线、调优过针对 GPT-4 Turbo 响应格式的提示词模板——那么这个系统即将在你不知情的情况下改变行为,而当有人问起原因时,你甚至找不到一个代码变更来指向。
在 2026 年 6 月的 Microsoft Build 2026 上,微软公布了 Project Polaris,这是一款自研的混合专家(mixture-of-experts)编程模型,旨在取代 GPT-4 Turbo 成为 GitHub Copilot 的默认引擎。微软给出的推送窗口是"2026 年 8 月起"——现在就是 8 月。对于个人版、企业版和企业版订阅者,迁移是自动的;有一个可选的三个月回退到 GPT-4 Turbo,但它不是默认选项,而且据报道也没有被突出展示——组织管理员必须在切换完成前找到设置并主动申请。
这个细节值得深思。Copilot 大约有 2000 万付费席位。据多家报道 Build 2026 的媒体称,这是有记录以来最大规模的一次将 AI 编程量从一家模型提供商转移的事件——而且它是以"opt-out 默认"而非"opt-in 选择"的方式发生的。
同一次 Build 2026 主题演讲还将 Copilot Workspace 从 beta 推向了正式发布,同时推出了两种新的自主运行模式:
Fleet 模式——Copilot CLI 在代码库上并行调度多个子 Agent,执行范围狭窄的任务,不需要每步都确认。
Autopilot 模式——针对有限范围的 GitHub Issue 进行定时、无值守运行,开发者在运行期间不需要在场。
把这两个公告放在一起看,故事的轮廓就更清晰了:微软不仅仅是在更换哪个模型来回答你的自动补全请求。它同时在这个模型被从七年的 OpenAI 合作关系下换掉的 exact 时刻,扩大了该模型在你的代码库内被允许执行的无人值守、多步骤工作范围——提交、测试运行、多文件编辑。
还有第三点值得单独提出:GitHub Copilot Enterprise 也在获得自主 Agent 模式,允许平台自主编写、测试并提交整个功能分支。每个自主变更仍需人工审批后才能合并,每个任务据报道都在一个临时的 Agent Sandbox 中运行——一个一次性 Linux 容器,在审核者实际合并生成的 Pull Request 之前与生产代码库隔离。GitHub Compliance Scanner 应该会在 PR 打开之前对生成的代码进行安全和许可策略检查。这是一个纸面上合理的设计——控制爆炸半径,在合并处设置门禁——但"纸面上合理的设计"也是你在多 Agent VS Code 集成发布前会说的话,直到研究人员在发布时在其中发现了 Prompt Injection 和 Allowlist 绕过问题。
根据微软在 Build 上的披露,Polaris 是一个混合专家(MoE)架构,具有按编程语言和框架专门化的子网络,而不是一个处理所有请求的单一巨型 Transformer。微软特别指出了在资源较少的语言——特别是 Rust 和 Haskell——上声称的最大基准测试收益,这与你对 MoE 设计的预期一致:路由到专家子网络恰恰在通用训练数据最薄弱的地方帮助最大。
Pro 级别订阅者获得高达 100,000 行的多文件上下文,以及微软所谓的自主测试生成。该模型运行在微软自有的 Azure Maia AI 加速器上,而非 OpenAI 运营的基础设施——这是把这件事从"更好的模型"故事变成"供应链"故事的细节。每一个曾经通过 OpenAI 计算路由并作为外部 API 成本记在微软账上的 Copilot 补全,现在都运行在微软端到端拥有的硅芯片上。Polaris 作为更广泛的 MAI 模型系列的一部分发布(与 MAI-Thinking-1 和 MAI-Code-1-Flash 并列),多份报告称其训练过程没有从第三方模型蒸馏——这是微软首次尝试完全独立的前沿模型组合,而不是在别人权重基础上的微调或包装。
在官方口径中,微软声称 Polaris 在 HumanEval 和 MBPP 上优于 GPT-4 Turbo。对待这个要带上一个适用于所有供应商基准声明的标准警告:这些是微软自己的数字,没有经过独立审计,而且 HumanEval/MBPP 是老旧的、被广泛刷分的基准,在多年前就不再是现实世界编程能力的可靠信号了。有趣的测试——SWE-bench Verified、真实仓库任务、与 Claude 或 GPT-5 级模型在混乱的真实代码库上的正面交锋——在撰写本文时还没有任何独立方的测试结果。
七年来,GitHub Copilot 的整套卖点建立在 OpenAI 的模型之上——先是 Codex,然后是 GPT-4,再是 GPT-4 Turbo——外面罩着一个 GitHub 品牌界面。每一次严肃的"我们是否应该采用 Copilot"讨论都隐含了"因此我们信任 OpenAI 的模型质量"。这种耦合现在不复存在了。2026 年 11 月回退窗口关闭后,Copilot 实际上变成了一个微软优先的推理服务:微软的模型,在微软的硅芯片上,在微软的 IDE 里,由微软的合规工具治理。
这与 Cursor、Windsurf 或 Claude Code 等工具是有本质不同的竞争定位——它们默认保持多模型,你可以根据任务选择或路由到 Claude、GPT 等。微软赌的是相反的方向:完全垂直整合,一个专门为其发货的 IDE 和工作流程调优的第一方模型。如果 Polaris 真的表现出色,这种整合是一个真正的优势——比任何第三方集成能匹配的都更紧密的模型训练和产品遥测之间的反馈循环。如果做不到,2000 万开发者现在就要依赖微软的模型质量路线图,而在 11 月之后没有可见的退出通道。
同样值得用一个数字来衡量这有多不寻常。供应商更换开发者工具背后的模型并非新鲜事——很多 AI 编程产品以前都悄悄更换过后端。但新鲜的是规模和默认方式:据报道,这是有记录以来最大规模的将 AI 辅助编程量从一家提供商转移的事件,而且是以自动迁移而非选择提示的方式执行的。对比一下一个负责任的团队会如何内部推出一个破坏性依赖升级——功能开关、opt-in、按队列分阶段、需要有回滚计划而不需要有人已经知道一个隐藏开关才能回滚——用那个标准来评判微软的推送机制,而不是用"他们是否公告了",差距就更明显了。
成本。没有标价变化——Polaris 被打包进现有的 Copilot 计划。但 Copilot 在 6 月已经转向按 Token 计费的 AI Credits,而 Polaris 在推理时的思维链(chain-of-thought)据报道在复杂多步骤任务上增加了开销,这是旧的固定费率心智模型没有考虑到的。如果你的团队用量预测假设了每个补全成本是稳定的,这个假设已经过时了。
延迟。微软声称在 Maia 硬件上标准补全比 GPT-4 Turbo 基线快 15–25%。对于启用思维链的多文件 Agent 任务没有公布 P95 数字,而这恰恰是延迟变化真正伤害开发者心流的场景。
锁定。这是没有人的基准图表能捕捉到的一点。现在,"我们用 Copilot"是关于一个 IDE 集成的声明。迁移完成后,它同时也是关于你依赖哪一家公司的模型来产生你组织所交付代码中相当一部分的声明。多模型工具让你可以更换底层提供商而无需触碰工作流程。垂直整合的 Copilot 不提供那个杠杆。
安全。这是相对于其严重程度受到关注最少的一部分。对 Build 2026 公告的报道指出,安全研究人员在新的多 Agent VS Code 集成的发布时发现了 Prompt Injection 和 CLI Allowlist 绕过漏洞——这意味着,同一个事件在扩大 Copilot 的自主操作能力(Fleet 模式无人值守运行 Shell 命令、Autopilot 在无人在场的情况下向有限范围的 Issue 提交),同时其护栏在对抗性输入下是否能 hold 住还存在疑问。如果你正在评估 Autopilot 做真实工作,"沙箱实际上能contain住一次成功的 Prompt Injection 吗"这个问题值得你在把它指向任何涉及密钥或生产配置的东西之前自己回答。
可维护性。这是被忽视的风险。如果你的流水线任何部分——CI 审核门禁、自动 PR 描述生成器、输出需要与预期格式进行 diff 的代码生成步骤——依赖于 Copilot 产生结构一致的输出,你就对一个特定模型的响应模式有了未声明的依赖。注释风格、代码格式约定、它如何措辞测试名称、它的解释有多详细——所有这些都会在底层模型更换时发生变化,而且没有任何东西会在你仓库的历史中显示为代码变更。一篇专门覆盖这个的报告称之为"模型替换静默回归":你的流水线行为在 8 月发生变化,不是因为你的团队做了什么,而是因为微软做了什么,而且没有可以用于二分查找的提交。
如果你是一个用 Copilot 做行内建议的个人开发者,这基本算是一个无关紧要的事件——UX 没有变化,只是生成它的模型变了,而且对大多数人来说这是完全透明的。
如果你在任何自动化场景中运行 Copilot,把这当作一次没有版本锁定可用的依赖升级来处理:
如果你在受监管行业——金融、医疗、在 EU AI Act 等模型溯源或 AI 治理要求下——这是一次正式变更管理事件,而非常规工具更新。你的合规签字可能引用了一个特定模型;那个模型即将消失。
如果你正在试点 Fleet 或 Autopilot 做无人值守工作,先把它限制在真正低风险的任务上——依赖更新、文档更新、Flaky 测试分类——在信任它处理任何敏感内容之前,根据报道的 Prompt Injection 问题验证沙箱的实际隔离保证。
抛开"微软结束 OpenAI 依赖"的叙事框架——这是真的,但也是每个媒体已经在讲的——更有用的视角是:这是一个活生生的案例研究,研究当一个被数百万工程师悄然提升为关键基础设施的 AI 编程工具在其核心依赖未经询问的情况下发生变化时会发生什么。没有人会在 2000 万部署上以 opt-out 默认和隐藏的回退开关的方式推送数据库引擎更换、编译器升级或基础镜像更换。Copilot 的模型对于在 Agentic 或 CI 场景中运行它的团队来说,可以说比上述任何一种都更是一个关键依赖——而它的变更管理严谨程度却像是一个 UI 微调。
所有这些并不意味着 Polaris 不好。架构选择——带有语言专门化路由的 MoE——是一个合理的赌注,而且如果基准测试在独立审查下站得住脚,微软自有的硅芯片应该在成本和延迟上真正提供帮助。但"供应商透明地更换了模型"和"这个变更对你透明"是两个不同的声明,而目前有真实证据支撑的只有第一个。第二个正是你的回归测试套件存在的意义。
无需行动:将 Copilot 用于行内建议的轻度个人用户。迁移设计得对你透明,而且据各方反映确实如此。
立即行动:任何将 Copilot 输出接入 CI/CD、审核自动化或多步骤 Agentic 流水线的团队。本周就建立回归基线,而不是等到生产环境出问题、没有人能解释原因之后。
认真评估但不要恐慌:考虑将 Fleet 或 Autopilot 用于真实自主工作的团队。该功能对有限的维护任务确实有用;但其安全态势尚未被充分验证,"确实有用"和"安全地指向重要内容"还不是同一个声明。
值得重新审视:专门因为 Copilot 意味着"OpenAI 的模型、GitHub 的打磨"而选择它的人。这一论据在 11 月失效。如果模型提供商选择对你的原始评估很重要,这是一个用当前格局重新在 Cursor、Windsurf 或 Claude Code 上跑一遍评估的合理时机——不是因为 Polaris 一定会更差,而是因为"我们实际上还不独立地知道"这个说法在今天比三个月前更站得住脚。
讨论:如果你正在通过任何自动化门禁运行 Copilot 输出——CI 检查、PR 生成、代码生成流水线——你实际上建立了检测静默模型行为变化的方法吗,还是你的流水线只是信任返回的任何结果?如果 Fleet/Autopilot 风格的无人值守 Agent 成为你工作流程的常态,"可以自动化"和"需要人看着"之间的界限对你来说在哪里?
Build 2026: Polaris Replaces GPT-4 in GitHub Copilot
Project Polaris at Microsoft Build 2026: GitHub Copilot Model Swap, Azure AI Foundry Supported Models & On-Prem Options
Microsoft Polaris Ends OpenAI Reliance in Copilot 2026
Copilot Drops GPT-4 for Polaris — What Changes for Enterprise Dev Pipelines
Microsoft unveils Project Polaris at Build 2026
Microsoft Drops GPT-4 Turbo for Polaris in GitHub Copilot