Copilot 9 月模型退役与默认启用策略临近：把 Agent 模型迁移做成可回放的准入演练

调研日期：2026-08-22
本文目标：以 2026-08-26 生效的 Copilot 默认模型可用性策略与 2026-09-01 的一批模型退役为时间边界，把模型更替从"换一个下拉项"拆成资产盘点、策略预检、回放验证、灰度切换与撤回证据；避免把可见、可选和适合生产混为一谈。

很多团队把模型退役当成一次 UI 变化：旧名字消失，就从候选列表里挑一个"看上去类似"的新模型。这种做法对随手提问影响不大，但对会运行命令、改写代码、调用 MCP、触发审查或被 CI 依赖的 Coding Agent 来说，模型名其实是一个运行时依赖。它会影响输出形态、工具使用节奏、提示词遵从、成本路径，以及人们对已有验收阈值的理解。

截至 2026-08-22，GitHub 已公告将在 2026-09-01 从各个 Copilot 体验中退役 Gemini 3.1 Pro、Claude Opus 4.5 / 4.6、Claude Sonnet 4.5 / 4.6 和 Raptor mini，并给出建议替代项。与此同时，Copilot Business 与 Enterprise 的 Default availability for released models 策略将从 2026-08-26 起决定未显式配置的 GA 模型默认是启用还是禁用。两件事相隔不远，但解决的问题完全不同：前者是现有依赖将不可用 ，后者是新旧未配置模型将开始继承组织策略。

因此，正确的目标不是证明"替代模型能回答同一个问题"，而是交付一份可追溯的模型准入记录：哪些任务依赖退役模型、哪些客户端和席位真的能使用候选模型、哪些行为已在真实夹具上复验、发生回归时该停用什么、由谁接手人工路线。

**适用前提：**本文面向使用 GitHub Copilot Business 或 Enterprise、且有模型策略或试点环境权限的团队。模型可用性同时受计划、客户端和组织 / 企业策略影响；个人订阅的可见模型与企业席位不应相互外推。下文的清单、YAML、阈值和任务卡是团队运行手册示例，并不是 GitHub 的配置 schema，也不会自动修改模型政策、账单或生产工作流。

一、先把两条时间线拆开：退役是替换，默认可用性是准入面变化

这轮变化最容易被误读成"9 月前换模型即可"。实际上，模型退役和默认可用性是两份不同的变更单，应各自保留负责人和验收结果。

|-------------------|------------|----------------------------------------------------|------------------------------|
| 变化 | 已知时间 | 它实际改变什么 | 不能据此推断什么 |
| 特定模型退役 | 2026-09-01 | 显式选择、脚本、文档或团队约定中对退役模型的依赖需要迁移 | 建议替代项在所有任务、所有客户端、所有策略下具有相同行为 |
| 未配置 GA 模型开始继承默认策略 | 2026-08-26 | Business / Enterprise 中未显式配置的 GA 模型将按默认启用 / 禁用策略处理 | 已显式允许、拒绝或不属于适用范围的模型会被同样处理 |
| 模型在某处显示 | 持续变化 | 当前计划、客户端和政策组合下该表面可能可见 | 它已通过本团队的数据、工具、成本和质量准入 |

GitHub 当前的支持模型文档把即将退役的模型、日期和建议替代项列在同一张退役历史表中；公告还特别说明，Claude Sonnet 4.6 对年度个人订阅者有例外。团队迁移时不要把这一例外扩大为企业策略结论。对组织和企业席位，管理员仍需要确认替代模型在实际政策中已获准，成员才会在相应客户端的模型选择器里看到它。

默认可用性策略也不等于"所有新模型都会自动进入生产"。官方说明明确排除了预览模型、开放权重模型、未覆盖相应数据保留协议的模型，以及不符合数据驻留或 FedRAMP 限制的模型。更稳妥的做法是将它视为待准入模型的默认入口规则：先决定未配置 GA 模型是否默认关闭，再对需要的模型显式建立例外和试点证据。

二、先盘点"模型依赖"，别只看聊天窗口里的默认值

模型依赖通常藏在四个位置。只检查 IDE 的下拉框，会漏掉最需要迁移的自动化路径。

|---------|--------------------------------|-----------------------------|----------------------------|
| 依赖面 | 典型痕迹 | 本轮要回答的问题 | 建议保留的证据 |
| 显式选择 | 提示词模板、仓库指令、Agent 配置、运行手册 | 是否直接写入将退役的模型名？替代项是否被误当成等价物？ | 文件路径、行号、责任人和替换决定 |
| 隐式路由 | Auto、团队默认模型、客户端预设 | 8 月 26 日后它是否会继承默认可用性策略？ | 当前策略截图或审计记录、试点账户观察结果 |
| 执行工作流 | 云端 Agent、CLI、代码审查、计划任务、CI 外围脚本 | 任务究竟在哪个客户端、哪种席位和哪种权限下运行？ | 任务 ID、客户端 / 插件版本、账户类型、触发方式 |
| 行为契约 | 评测夹具、人工审阅习惯、成本上限、失败降级 | 哪些结果必须保持，哪些差异可以接受？ | 基线结果、阈值、审批人和回退路径 |

先做一次只读检索，再由代码或流程的实际负责人解释命中项。例如，下面的命令只在当前 Git 仓库已跟踪的文件中寻找本轮公告中的旧模型名；它不能证明运行时一定会使用这些模型，也不应替代控制台和业务流程盘点。

复制代码

git grep -nE 'Gemini 3\.1 Pro|Claude (Opus|Sonnet) 4\.(5|6)|Raptor [Mm]ini' -- .

没有命中也不代表安全：有的工具使用 auto、环境变量、团队默认值或网页端设置。相反，命中也不表示必须逐字替换------它可能是历史说明、回归样本或明确用于验证退役行为的夹具。把每个结果标成"生产依赖、文档待更新、测试保留、误命中"四类，才能得到可执行的迁移范围。

三、把替代选择写成"模型准入合同"，而不是口头偏好

建议为每一个任务族建立一份小而完整的变更记录。下面是示意模板，字段应按团队的真实目录、模型政策和风险级别调整；请勿在其中写入客户 Prompt、访问令牌或内部 URL。

复制代码

model-admission-change:
  change_id: copilot-model-retirement-2026-09-pilot
  reviewed_on: 2026-08-22
  deadlines:
    default_availability_policy_effective: 2026-08-26
    retiring_model_unavailable: 2026-09-01
  workload:
    name: dependency-triage-agent
    owners: [developer-productivity, application-security]
    client_and_plan_to_verify:
      - copilot-cloud-agent-business-seat
      - vscode-enterprise-pilot
  current_dependency:
    model: Claude Sonnet 4.6
    selection: explicit-in-task-template
  candidate:
    model: Claude Sonnet 5
    policy_state: explicit-enable-required
  acceptance:
    fixtures:
      - read-only-dependency-classification
      - one-sandboxed-draft-pull-request
      - deterministic-lint-and-test-command
    evidence:
      - prompt_template_revision
      - changed_files_and_diff_scope
      - commands_run_and_exit_codes
      - reviewer_decision
  stop_conditions:
    - candidate_not_visible_for_the_actual_seat_or_client
    - tool_calls_exceed_the_approved_scope
    - required_validation_is_skipped_or_not_reported
    - security_or_quality_regression_exceeds_team_threshold
  fallback:
    route: human-owned-manual-triage
    owner: on-call-engineering-manager

这里最关键的字段不是 candidate.model，而是 client_and_plan_to_verify 和 stop_conditions。GitHub 明确指出模型访问取决于 Copilot 计划、所用客户端，以及组织或企业是否限制特定模型；因此，"管理员在网页上看到了候选模型"不是对 CLI、IDE 或 cloud agent 的可用性证明。任何候选模型看不到、权限不一致或上下文边界不符合预期时，都应触发合同里的停止条件，而不是让使用者临时改用另一个模型继续执行。

四、先做策略预检，再做质量对比

团队常常直接拿候选模型跑一组复杂任务，最后才发现结果来自个人席位、错误客户端或未纳入企业策略的试验环境。更可靠的顺序是先确认"是否允许使用"，再比较"是否适合使用"。

1）为真实运行面做可见性检查

在每一个会实际运行任务的表面上，以受控试点账户记录：客户端名称与版本、席位类型、候选模型是否可见、是否能被选中、任务是否仍受原有工具与审批边界约束。不要只在管理员账户中完成一次检查后就宣布全员可用。

若候选模型需要启用，使用组织 / 企业的正式模型政策完成操作；若团队不希望未配置的 GA 模型自动出现，应在 8 月 26 日前调整默认可用性策略或显式拒绝不应开放的模型。官方文档说明这两种控制都存在，但具体的权限层级与最终可用范围仍取决于当前计划和组织配置。

2）冻结基线任务，而不是比较"回答是否更像人"

选 3 到 8 个不含生产秘密的夹具，覆盖团队真正依赖的动作。每个夹具都要有明确的输入、允许工具、预期证据和人工验收人。例如：

|---------|--------------------|--------------------|-----------------|
| 夹具 | 允许的动作 | 必须观察的结果 | 不应拿来判断的事 |
| 只读依赖分诊 | 读取锁文件与已批准文档 | 分类理由、引用路径、无写入 | 一次回答的文采 |
| 小范围修复草稿 | 仅改沙箱模块与相邻测试 | diff 范围、测试命令、未运行检查 | 是否能取代代码所有者审批 |
| 审查意见归纳 | 读取虚构 PR diff 与检查结果 | 风险点、证据链接、未知项 | 是否已证明真实生产变更安全 |
| 工具调用边界 | 仅调用一个只读测试 MCP | 调用理由、参数最小化、拒绝越权动作 | MCP 服务本身的业务授权质量 |

对每个夹具，用同一份版本化 Prompt、同一套工具允许清单和同一个验证脚本运行旧基线（若退役前仍可用）与候选模型。记录事实，不给模型打笼统的"更聪明 / 更差"标签：它修改了哪些文件、实际运行了什么命令、是否声明未运行步骤、是否越过约定目录、人工审阅是否接受。

3）把回放结果写成可审计决策

下面的记录格式足以让另一个审阅者复查迁移理由。数值阈值由团队自己定义；不要把任何单次模型输出当成稳定性能承诺。

复制代码

fixture-run:
  fixture: sandboxed-draft-pr
  baseline_or_candidate: candidate
  model: Claude Sonnet 5
  environment: isolated-test-repository
  observed:
    files_changed: 4
    allowed_paths_only: true
    test_command_reported: true
    test_exit_code: 0
    unrun_checks_declared: true
  human_review:
    decision: accept-with-minor-edits
    blocking_findings: []
  follow_up: repeat-on-next-client-version

若旧模型已不可用，不能再做逐回合对比。此时应以历史 PR、已保存的测试产物或当前人工基线作为参考，并在记录里明确写成"非同模型 A/B 对比"。诚实保留这一限制，比伪造可比性更有价值。

五、按"先收口、再试点、后扩展"切换，而不是全局改默认

推荐把切换拆成三次可回滚的动作：

**收口旧依赖。**将显式旧模型名、过时回退文案和失效的运行手册标记出来；保留一个人工任务入口，不让 9 月 1 日的不可用状态直接变成无人处理的队列。
**启用小范围候选。**只对一个低风险任务族、一个客户端组合和少量试点成员明确启用候选模型。若默认可用性策略保持启用，也要清楚区分"策略继承带来的可见性"与"已通过试点评审的生产准入"。
**扩大前复盘。**检查夹具结果、人工编辑比例、拒绝原因、工具调用异常和成本信号；只有证据支持时，才把同一候选扩展给新的任务族或客户端。

这里的"回滚"也要说清楚：模型退役后通常不能恢复对旧模型的依赖。可回退的是组织自己的路由决定------停止候选模型的自动任务、收回其策略准入、改走人工队列或切换到另一份已经验证的候选合同。不要把"有回滚按钮"写成"能让退役模型复活"。

六、六个常见误区

1）把建议替代项当成行为等价承诺

公告中的建议用于指导迁移，不保证推理方式、工具调用、输出格式、成本和客户端支持完全相同。每一项都要在自己的夹具上复验。

2）只更新聊天模板，忘了自动化和运行手册

真正会中断的往往是云端任务、CLI 别名、代码审查预设或团队默认策略，而不是人手选模型的聊天窗口。

3）把 8 月 26 日和 9 月 1 日当成同一个开关

默认可用性影响未配置 GA 模型的准入面；退役影响具体旧依赖。应分别验证、分别发布、分别留证。

4）拿个人账户的可见性替代企业结论

计划、客户端与企业 / 组织模型政策都会改变可用集合。试点证据必须来自实际的运行主体。

5）只测"能生成代码"，不测工具和验证边界

对 Coding Agent，错误的命令、越界文件修改、未报告的测试遗漏，比一段看似合理的代码更危险。质量回放必须覆盖允许动作与证据格式。

6）将自动选择视为不需要治理

Auto 仍会受到可用模型与政策影响。默认策略生效后，未显式配置的 GA 模型可能改变可见性，因此它本身也是要被记录和复验的路由规则。

结语

模型更新的速度不会变慢，真正可复用的能力是让每一次更新都经过同一条可解释的路径：盘点依赖、确认政策、在受控夹具中回放、只扩大通过准入的组合，并为无法继续的任务准备人工接管。

先在 8 月 26 日前完成默认可用性策略的意图确认，再在 9 月 1 日前收口退役模型的显式依赖。这样，即使模型目录继续变化，团队也不会每次都从"谁能用、能做什么、出了问题怎么办"重新开始。

来源与延伸阅读

Upcoming August 2026 model deprecations in GitHub Copilot：GitHub 官方公告，发布于 2026-07-31；列出 2026-09-01 的退役模型、建议替代项及 Claude Sonnet 4.6 的年度个人订阅例外。
Supported AI models in GitHub Copilot：GitHub Docs；说明模型、客户端与策略可用性，以及当前退役历史表。
About default availability of Copilot models：GitHub Docs；说明 Business / Enterprise 的默认可用性策略将于 2026-08-26 开始影响未配置的 GA 模型，以及适用边界。
Configuring access to AI models in GitHub Copilot：GitHub Docs；说明模型访问受计划、客户端和组织 / 企业限制共同影响。