GitHub Copilot已弃用四款旧模型：替代名单明确，企业需检查模型策略与客户端

昨天 2阅读

2026年10月2日，GitHub宣布四款模型在GitHub Copilot各项体验中弃用，范围包括Copilot Chat、行内编辑、ask与agent模式以及代码补全。公告使用的是已经生效的状态，依赖这些模型的团队需要检查当前配置，而不是把日期当作未来迁移提醒。

配图为AI生成的概念插图，表现旧模型路径切换至受支持替代项的迁移过程，不是Copilot界面，不代表模型能力排名。

四项退役对应三种推荐替代

以上对应关系来自此次GitHub公告。官方同时说明，用户无需手动移除退役模型，但应更新工作流和集成以使用受支持模型。“推荐替代”提供的是迁移方向，公告没有承诺新旧模型在提示词响应、工具调用、速度和资源消耗上完全等价。

因此，第一轮盘点宜覆盖显式指定模型的配置、团队共享操作说明，以及自动化调用入口。模型选择器中旧项已经消失，也不代表其他入口里保存的旧名称已经更新。对使用自动模型选择的流程，则应先查看实际可用集合，避免把固定模型迁移方式机械套上去。

GitHub提示，Copilot Enterprise管理员可能需要在模型策略中启用替代项。管理员可以检查个人Copilot设置与具体模型的策略状态，启用后再确认VS Code和github.com的模型选择器。企业设置文档进一步说明，模型是否可用可以由企业统一控制，也可以交由组织决定。

这意味着“同事已经能选，我这里没有”未必是迁移失败。排查应同时确认许可证来源、企业与组织策略、具体客户端。官方Copilot CLI管理文档也说明，企业启用的模型会影响CLI可选项，用户可用/model查看当前可用模型。团队验收应覆盖实际使用入口，而非只在管理员自己的网页账户上测试一次。

官方支持列表单独列出了部分模型的最低IDE或扩展版本，并提醒这些信息可能随支持推进改变。未列最低版本，不等于任意旧版本都能工作；文档建议保持IDE和Copilot扩展更新。对于暂时无法统一升级的团队，应先核实目标模型在既有开发环境中是否真正可选、能否完成请求。

功能验收可以选取团队已经熟悉的代表任务：一次小范围补全、一次多文件修复、一次需要工具调用的代理操作。保持输入与验收标准一致，记录生成差异和测试结果，再调整提示词或默认模型。不能只以“成功返回文本”判定迁移完成，也不应未经测试就断言新版一定更快或更适合所有代码库。

这份公告描述的是GitHub Copilot产品中的模型生命周期，不能据此推断Google、Moonshot AI或Anthropic的原生API也在同日停用同名模型。若系统同时使用Copilot和供应商直连接口，应分别维护支持状态与迁移依据，避免因一份集成平台公告误改另一条生产链路。

此次最明确的操作顺序是找到旧模型依赖、确认替代模型获得策略许可，再在目标客户端跑通代表任务。把模型名称、可用入口和验收结果一起记录，后续遇到类似退役时才有可靠的迁移基线。

资料核对：2026年10月3日（北京时间）。产品状态、价格与支持范围以官方后续更新为准。