GitHub 在 2026 年 7 月 31 日公布，Gemini 2.5 Pro 和 Gemini 3 Flash 已在所有 GitHub Copilot 体验中停用。范围包括 Copilot Chat、inline edits、ask mode、agent mode 和 code completions，因此影响的不只是聊天界面的模型选择，也包括 IDE 内的代码编辑和 Agent workflow。
GitHub 建议以 Gemini 3.1 Pro（Preview）取代 Gemini 2.5 Pro，以 Gemini 3.6 Flash 取代 Gemini 3 Flash。官方也提醒，Copilot Enterprise 管理员可能需要在 Copilot 设置的 model policies 中开启替代模型，并在单独的 Copilot 设置确认用户是否真的能看到该模型。至于移除已停用模型，管理员不需要另外进行清理操作。
这类变更的真正成本通常不在点击替换，而在于既有 workflow 对模型名称、输出格式和上下文行为的依赖。使用 agent mode 的团队可能有固定的工具权限、提示词、测试 prompt 或审批流程；模型更换后，即使功能仍然可以执行，输出长度、工具选择、代码风格和失败模式也可能改变。
企业应把 model identifier 当成受管制的配置，而不是写死在操作手册或自动化脚本里。先列出受影响的 Copilot policy、IDE 设置、团队 onboarding 文档和内部评测，再为替代模型建立最小回归测试。Gemini 3.1 Pro 仍然是 Preview，不能假设它与已停用的 Gemini 2.5 Pro 完全等价；关键工作要保留人工 review、版本记录和可回退的替代方案。
GitHub 这次公告也反映模型供应已经变成平台管理问题。当 Copilot 同时覆盖 Chat、completions 和 agent mode，企业的 AI 治理就不能只管理「谁可以使用 Copilot」，还要管理「团队实际允许哪一个模型、何时替换、替换后怎样验证」。model policy、可观测性和回归测试会直接影响开发流程能否平稳过渡。
对开发者来说，现在最值得做的是检查现有工作流有没有直接指定两个已停用的 model identifier，确认替代模型是否已在组织 policy 中开放，并重新验证高风险的 agent 任务。GitHub 不要求额外移除旧模型，但企业仍然需要主动更新集成和测试，才不会把平台的 model lifecycle 变成生产中的突然中断。
