旧模型按时走、新策略可以编程管：GitHub Copilot 10 月 19 日的两次变更一次讲清

2026 年 10 月 19 日，GitHub 在同一天做了两件看似相反的事：一边退役了六个 Copilot 模型，一边把管理模型可用性的 REST API 推到正式可用（GA）。退役名单是 Gemini 3.7 Flash、GPT-5.5、GPT-5.4、GPT-5.4 mini、GPT-5 mini 与 Grok 4.5，覆盖 Copilot Chat、行内编辑、ask 与 agent 模式以及代码补全在内的大多数 Copilot 体验；替代名单也同时给出：Gemini 3.8 Flash、GPT-6.1 Sol、GPT-6 Luna 与 Grok 4.7。同一天 GA 的模型策略 API 则给了管理员四组 GET / PATCH 端点，分别对应企业、企业团队、agent 应用与组织。把两件事放在一起读，意思就很清楚了：模型来来去去是常态，真正的新能力是“谁有权决定团队能用哪个模型”终于可以写成代码、放进审计了。

本文先按两份 GitHub Changelog 原文把事实钉牢，再给出个人开发者与企业管理员各自的检查清单，并提醒三处容易误读的地方：退役不等于删除你的代码与对话，替代模型默认启用的前提是管理员没有关掉全局默认，以及 11 月 16 日还有第二批退役在等着——那批里有 Claude Opus 系列，本文末尾会一并列出，但请注意，第二批的细节来自第三方对 changelog 的整理，核对时仍以 GitHub 官方页面为准。

10 月 19 日到底发生了什么

第一份 changelog 的标题就是日期本身：《GitHub Copilot models deprecated on October 19, 2026》。正文第一句定性：自当日起，下列模型在大多数 Copilot 体验中被弃用；第二句交代时间线：这次弃用早在 2026 年 9 月 18 日就已公告。也就是说，10 月 19 日不是“突然通知”，而是一个提前一个月公布的截止日的到来。对团队来说，这个时间差本身就是一条经验：Copilot 的模型变更是有预告期的，错过预告期的人，才会在截止日当天感到突然。

退役与替代的对应关系值得完整抄一遍，因为这就是迁移时要 grep 的清单。Gemini 3.7 Flash → Gemini 3.8 Flash；GPT-5.5 → GPT-6.1 Sol；GPT-5.4 → GPT-6.1 Sol；GPT-5.4 mini → GPT-6 Luna；GPT-5 mini → GPT-6 Luna；Grok 4.5 → Grok 4.7。注意两个细节：其一，GPT-5.4 与 GPT-5.5 共用同一个替代项 Sol，两个 mini 共用 Luna——这意味着迁移后团队的模型种类会收敛，成本与行为的方差也会跟着变；其二，Grok 的替代项是 4.7 而非早期预告里的 4.6，说明即使是官方预告，替代名单也可能在截止日之前调整，迁移前务必以 10 月 19 日当天的 changelog 为准，而不是凭记忆引用 9 月的版本。

changelog 还说了两句安抚性的话，但每句都有适用边界。第一句：“删除被弃用模型不需要任何操作。”意思是 GitHub 会自己把旧模型撤下，你不用去“卸载”它们；但它绝不等于“你的工作流不需要任何操作”——恰恰相反，下一句就是“请更新你的工作流与集成，使用受支持的模型”。第二句是关于管理员的：Copilot Enterprise 管理员可能需要通过 Copilot 设置里的模型策略来启用替代模型，启用后才能在 VS Code 与 github.com 的模型选择器里看到它。换句话说，迁移由两段组成：GitHub 撤下旧模型（自动），以及你的组织放行新模型（手动或策略驱动）。只做前半段假设，后半段就会在周一早上以“模型不见了”的工单形式找上门。

同一天 GA 的模型策略 API：四个端点意味着什么

第二份 changelog 的标题是《Copilot model policy API for enterprise, orgs, and teams》，发布于 2026 年 10 月 19 日 14:32（太平洋时间）。它宣布：用于读取与更新 Copilot 模型策略的 REST API 正式可用，GET 与 PATCH 端点覆盖四个层级——企业（/enterprises/{enterprise}/copilot/model-policies）、企业团队（/enterprises/{enterprise}/teams/{team_slug}/copilot/model-policies）、agent 应用（/enterprises/{enterprise}/copilot/apps/model-policies）与组织（/orgs/{org}/copilot/model-policies）。企业策略可以在组织模式下把模型控制权下放给组织，在企业团队模式下下放给团队与应用。

为什么四个层级重要？因为现实里的模型治理从来不是“一刀切”。总部可能希望全公司默认只开某几个模型，某个团队因为合规原因需要更严的清单，某个 agent 应用（比如自动评审机器人）又需要单独的模型集合。过去这些只能靠逐个组织点设置页来维持， drift（策略漂移）几乎不可避免——有人在某个组织里多开了一个模型，没人知道。现在策略变成可 GET 的资源，漂移就可以被脚本定期审计；变成可 PATCH 的资源，收紧就可以一次性下发，而不是逐个点页面。

但 API 的 GA 不等于治理的自动完成。它给了你“读”和“写”的能力，没有给你“该写什么”的答案。哪些模型该进允许清单、谁有权 PATCH、变更要不要走审批与留痕，这些仍是组织自己的决策。务实的做法是：先用 GET 把全量现状导出来存档，再把“当前实际在用的模型集合”与“10 月 19 日之后的受支持集合”做一次 diff，最后才写 PATCH。顺序反过来——先 PATCH 再审计——很容易把某个团队正在用的合法模型一并关掉。

个人开发者的检查清单：五分钟能做完的事

如果你是个人订阅用户，事情相对简单，但仍有两处值得动手。第一，grep 自己的配置：IDE 设置、agent 配置、CI 脚本、仓库里的 AGENTS.md 或提示词模板，只要出现六个旧模型名字之一，就换成对应的替代项。旧名字不会“自动升级”成新名字——它指向的模型已经不在了，继续引用只会得到不可用的结果或静默的替代，而静默替代恰恰是最难排查的一种故障。

第二，打开模型选择器确认替代模型确实可见。如果看不到，先别怀疑自己的订阅，去看两点：该模型是否在你的套餐内，以及管理员（如果你在组织里）是否已在模型策略里放行。GitHub 的措辞很明确：策略启用后，模型才会出现在选择器里。个人用户没有这层，但组织用户几乎所有“模型消失”问题都卡在这里。

第三，别被“不需要操作”误导而跳过验证。挑一个你最常用的任务——比如一段熟悉的补全或一次 agent 改动——用替代模型跑一遍，对照过去的结果看行为差异。Sol 与 Luna 的定位不同（一个偏通用、一个偏轻量），从 mini 迁到 Luna 未必是等价替换；从 5.4 迁到 6.1 Sol 也可能在长任务上表现出不同的取舍。迁移的终点不是“名字换掉了”，而是“关键任务在新模型上仍然通过”。

企业管理员的检查清单：按委托拓扑办事

对管理员来说，10 月 19 日的真正作业是两张表。第一张是“引用表”：全企业范围内，哪些仓库、CI lane、agent harness、共享提示词引用了旧模型名。grep 的范围要包括代码、workflow 文件与文档，因为模型名经常藏在文档示例里，而文档示例会被新人原样抄走。第二张是“策略表”：用模型策略 API 的 GET 端点，把企业、团队、应用、组织四层的现状拉出来，确认替代模型在每一层的状态。

接下来要按委托拓扑决策。GitHub 的规则是：企业策略可以在组织模式下把控制权交给组织，或在企业团队模式下交给团队与应用。这意味着“在企业层 PATCH 一次”不一定等于“全公司生效”——如果你的企业处于组织模式，真正起作用的可能是组织层的策略。动手前先确认自己企业的模式，否则会出现“明明 PATCH 成功了，开发者那边还是看不到”的困惑。确认模式的方法在 GitHub 关于企业内模型可用性管理的文档里，本文不复述步骤，只强调：先确认拓扑，再写 PATCH。

还有一个默认项要核对：全局默认（global default）。在默认开启的情况下，替代模型通常会自动启用；但如果管理员此前关掉了全局默认或显式禁用过某个模型，替代模型就不会自动出现，必须手动放行。这个“默认”正是 10 月 19 日前后最常见的坑：团队以为迁移是自动的，其实自己的组织早就把自动通道关掉了。把全局默认的状态写进迁移检查表，放在第一行。

三处容易误读的地方

第一，退役影响的是“新的请求”，而不是“已有的产出”。changelog 没有说已生成的代码或已有对话会被改动；按常规理解，退役意味着旧模型名不再承接新请求，而不是追溯改写历史。但这句话仍要谨慎表述：官方文本没有明确承诺历史对话的保留方式，重要的对话记录应当自己导出存档，而不是假设平台永远保留。

第二，替代模型的计费与性能不是旧模型的平移。同一批第三方整理指出，替代模型按各自的费率计费，切换后应当复核用量。changelog 本身没有给出价格表，本文也不引用未经核实的费率数字。迁移后第一个账单周期值得单独看一眼：用量结构变了，成本结构一定跟着变。

第三，10 月 19 日不是终点。根据第三方对 GitHub changelog 的整理，2026 年 11 月 16 日还有一批退役：Claude Opus 4.8、Claude Opus 5 与 GPT-5.6 Terra，替代项为 Claude Opus 5.5、GPT-6.1 Sol 或 GPT-6 Luna；其中按年付费的个人订阅用户可继续保留 Opus 4.8。这一批与 10 月 19 日的批不同：它涉及 Claude 模型，而且 Opus 系列是很多重任务的默认选择。把 11 月 16 日写进日历、提前 grep Opus 引用，是 10 月 19 日这篇最实际的后续动作。但请注意：第二批的细节本文未逐项亲核官方原文，执行前请以 GitHub 官方 changelog 为准。

判断：模型治理正在从“选模型”变成“管策略”

把 10 月 19 日的两条 changelog 并排放，趋势就很明显了。过去一年，Copilot 的新闻大多是“又上了哪个模型”；而这一天，新闻变成了“旧模型按时退场”与“模型策略可以编程管理”。这说明 Copilot 的竞争重心正在从模型数量转向治理能力：企业买家关心的不是选择器里有多少个名字，而是能不能证明“全公司只用了批准的模型”、能不能在一次退役后一小时内完成全量审计。

对 vibe 项目的独立开发者来说，这个趋势同样有启示。哪怕你现在只有一个仓库、一个人，也值得养成一个习惯：模型名只出现在一个配置文件里，而不是散落在十个提示词与脚本中；每次模型变更都当作一次依赖升级来处理——grep、替换、验证、记录。10 月 19 日退役的六个名字，放在一年前可能还是“新模型”；今天它们已经是需要 grep 的旧名字。模型周期的缩短，就是 vibe 项目必须把“模型”当作可变依赖来管理的理由。

最后留一个可直接抄走的收尾动作：今天就做三件事——grep 六个旧名字、GET 一次你所在组织的模型策略、把 11 月 16 日写进日历。做完这三件，10 月 19 日这篇新闻对你来说就不是资讯，而是已经落地的检查项。

与站内已发内容的划界

站内 10 月 26 日发布过 GPT-6.1 Terra 进入 Copilot 的资讯，那篇讲的是“新模型来了”；本篇讲的是同一生态的另一面——“旧模型按时走”以及随之 GA 的模型策略 API。两者互补但不重叠：前者关心选哪个新模型，后者关心旧引用如何迁移、策略如何编程管理。另有 10 月 15 日 Copilot 与 Logitech 按键的资讯，讲的是环境智能入口，与模型退役无交集。