GitHub 宣布，2026 年 10 月 19 日起，将在 GitHub Copilot 的多个使用场景中弃用 6 个 AI 模型，范围包括 Copilot Chat、内联编辑、Ask 模式、Agent 模式和代码补全。官方同时给出了建议替代模型，但这不是一次简单的“把下拉框选项换掉”：模型切换可能改变响应速度、代码风格、工具调用路径、上下文使用方式和请求成本。
这次变更值得开发者提前处理的原因，是很多团队已经把模型选择写进了使用规范、Agent 提示词、评测记录和开发流程。模型名字从产品界面消失只是最后一步，真正需要迁移的是围绕旧模型形成的质量基线和使用预期。现在先盘点引用、建立小型回归集，通常比 10 月 19 日之后才发现 Agent 行为改变更从容。
先看清楚：这次具体弃用了哪些模型
GitHub Changelog 给出了明确的弃用日期和建议替代模型：
| 将被弃用的模型 | 弃用日期 | 官方建议替代模型 |
|---|---|---|
| Gemini 3.7 Flash | 2026-10-19 | Gemini 3.8 Flash |
| GPT-5.5 | 2026-10-19 | GPT-5.6 Sol |
| GPT-5.4 | 2026-10-19 | GPT-5.6 Sol |
| GPT-5.4 mini | 2026-10-19 | GPT-5.6 Luna |
| GPT-5 mini | 2026-10-19 | GPT-5.6 Luna |
| Grok 4.5 | 2026-10-19 | Grok 4.6 |
这里有三个边界需要先说清楚。
第一，这不是 Copilot 整体停止服务，也不是所有模型同时退役，而是公告列出的 6 个模型在指定日期后不再继续提供。第二，表格里的替代模型是 GitHub 给出的建议，不意味着两者在代码风格、推理深度、延迟或计费权重上完全一致。第三，变更覆盖的不只是聊天窗口，也包括代码补全和 Agent 相关体验，因此“我平时不用 Copilot Chat”并不能自动排除影响。
为什么模型迁移会影响工程结果
模型选择常被当作个人偏好：觉得某个模型写代码顺手，就在设置里一直选它。但一旦模型参与 Agent 或团队协作，它实际上已经成为工程流程的一部分。
代码补全影响的是节奏和局部风格
代码补全通常发生在编辑器的高频交互中。模型切换后，最先被感知的可能不是“能不能写出来”，而是建议出现的速度、补全长度、对局部上下文的取舍，以及对项目现有命名和风格的贴合程度。
如果团队把生成结果直接纳入日常开发，建议至少抽取一组真实但不含敏感信息的代码片段，比较新旧模型的接受率、修改次数和明显错误类型。不要只用一个算法题或一段人工编写的 Prompt，因为那样测到的更像模型演示效果，而不是团队自己的编辑器工作流。
Agent 模式影响的是完整执行链
Agent 不只返回一段代码，它还可能读取文件、规划步骤、调用工具、运行测试，再根据结果继续修改。模型换代后，变化可能出现在：
- 是否能准确理解仓库约束和已有实现；
- 是否会把一个简单任务拆成过多步骤；
- 工具调用参数是否更稳健，失败后是否能恢复；
- 是否倾向于修改更多文件，或留下更大的审查面；
- 测试失败时，是修复根因还是反复尝试表面改动。
因此，Agent 的迁移不能只比较最终补丁是否能通过一次测试，还要记录修改范围、命令调用、失败次数和人工返工量。
团队策略影响的是可用性和治理
GitHub 公告说明，在默认模型启用的情况下，Copilot Business 和 Copilot Enterprise 客户的建议替代模型会自动启用，前提是管理员没有关闭全局默认设置或显式禁用对应模型。如果组织关闭了全局默认启用，则需要在 Copilot 设置中的模型策略里主动开放替代模型。
这意味着个人用户和组织管理员面对的迁移动作不完全一样：个人需要重新确认常用模型和工作习惯；管理员还要检查模型策略、默认模型、团队文档和内部培训材料，避免用户在弃用后才发现替代模型根本没有权限。
一份不依赖具体平台配置的迁移清单
1. 盘点旧模型出现在哪里
先不要急着修改所有文档，先把引用位置找出来。可以从仓库里的工作流、开发工具配置、脚本和文档开始：
1 | rg -n -i \ |
仓库搜索只能覆盖代码和配置，不能代替平台设置检查。还应盘点：
- 团队是否在 Copilot 使用规范中指定了某个模型；
- Agent 或提示词模板是否暗含某个模型的能力假设；
- 评测报告和示例截图是否仍然以旧模型为基线；
- 组织或企业的模型策略是否关闭了建议替代模型；
- 自动化脚本、内部代理或网关是否保存了旧模型名称。
不要把官方建议替代模型直接写成一个全局硬编码值。模型可用性还会受到 Copilot 计划、使用客户端、组织策略和平台发布节奏影响，应该以实际支持列表为准。
2. 给每类任务建立最小回归集
迁移评测不需要一开始就做成复杂基准。一个有代表性的最小集合，通常包含：
| 任务类型 | 需要观察的结果 |
|---|---|
| 补全一个已有函数 | 采纳率、无关改动、类型和边界错误 |
| 修改一个跨文件功能 | 依赖理解、修改范围、测试是否完整 |
| 修复一个带失败测试的缺陷 | 定位速度、修复根因、回归测试质量 |
| 编写脚本或查询 | 命令安全性、异常处理、可维护性 |
| 让 Agent 运行测试并迭代 | 工具调用、失败恢复、总步骤和总耗时 |
每个任务保留输入提交、允许使用的工具、测试命令和验收标准。这样比较的是模型迁移前后的工程结果，而不是某一次回答是否“看起来更聪明”。
3. 把模型切换和代码变更分开
迁移期间尽量不要同时升级框架、重写提示词、调整测试和更换模型。否则即使结果变好或变坏，也很难判断原因。
可以给团队保留一份简单的迁移记录：
1 | 任务：为订单查询增加分页 |
这种记录比一句“新模型也能用”更有价值。它可以帮助团队决定哪些任务适合自动迁移，哪些任务需要保留人工检查或改用另一个受支持模型。
4. 提前检查配额和计费影响
替代模型可能拥有不同的请求乘数、速率限制或上下文特性。即使功能结果相近，Agent 的多轮调用也可能放大成本差异。
在迁移评估中，建议同时记录：单任务请求次数、输入输出规模、总耗时、失败重试次数和实际计费指标。不要只比较一次回答的价格，尤其是 Agent 任务；真正的成本往往来自多轮规划、工具调用和失败后的再次执行。
管理员和平台团队应该提前做什么
管理员可以把这次弃用当作一次模型治理演练，而不只是被动通知用户。
首先，在 10 月 19 日前确认组织和企业策略没有无意中阻止建议替代模型。其次，把模型弃用日期、替代关系和支持范围放进团队的变更记录。再次，为 Agent、代码审查和代码补全分别设置反馈渠道，因为同一个替代模型在这三个场景里的表现未必相同。
如果团队有内部质量门禁，还可以把“模型名称”从唯一的配置维度改成更稳定的任务能力描述。例如，文档可以记录“用于快速补全的低延迟模型”或“用于跨文件 Agent 的高质量模型”，同时保留当前实际选择的模型和评测日期。这样下一次模型退役时，迁移的是能力目标，而不是到处搜索一串旧名字。
结语
GitHub Copilot 的这次变更给了开发者一个很具体的提醒：模型不是永远存在的工具开关，而是有生命周期的工程依赖。官方已经给出了 2026 年 10 月 19 日这个明确日期和替代建议，剩下的工作是确认组织策略、盘点旧引用，并用自己的代码和 Agent 任务做一次小规模回归。
最稳妥的迁移方式，不是等旧模型从列表里消失后临时选择一个新模型，而是提前把“模型更换”变成可观察、可比较、可回滚的工程变更。这样模型升级带来的不确定性，才不会直接传导到代码质量和交付节奏上。
参考来源
- GitHub Changelog： Upcoming deprecation of selected GitHub Copilot models in mid-October
- GitHub Docs： Supported AI models in GitHub Copilot
- GitHub Docs： Managing access to AI models for your organization