模型退役不是换个 ID：Agent 迁移最容易丢的是岗位能力

凌晨的定时任务收到 model_not_found。值班者把配置里的模型名换成平台建议项，接口重新返回 200，于是迁移被标记为完成。

第二天才发现：客服 Agent 不再按固定 JSON 返回，内容 Agent 开始跳过来源核验，另一个有写权限的 Agent 在信息不足时更愿意直接调用工具。

这不是"新模型更差"的结论。问题在于团队把模型可调用 误当成了岗位可交付。

GitHub 公告中，一批模型在 2026 年 9 月 1 日从 Copilot 的多个体验中退役。官方给出了建议替代项，同时提醒企业管理员可能需要先在模型策略中启用它们。Anthropic 的生命周期文档也明确：请求 Retired 模型会失败，替代模型应在退役日前用真实应用充分测试。

建议替代解决的是"下一次请求发给谁"。生产迁移还要回答：它能否完成这个岗位、会不会越界、多少流量可以交给它、失败时退到哪一版。

把模型迁移当成一次路由发布

不要直接修改 MODEL_ID。先创建一个不可变的候选路由：

ts 复制代码

type RouteBundle = {
  id: string;
  provider: string;
  model: string;
  parametersHash: string;
  promptAdapter: string;
  toolSchemaVersion: string;
  policyVersion: string;
  timeoutMs: number;
  fallbackRoute?: string;
};

const current: RouteBundle = loadBundle("content-r17");
const candidate: RouteBundle = buildBundle("content-r18");

为什么回滚单元要这么大？因为模型迁移经常伴随参数、系统提示、工具描述和 timeout 调整。只保存旧模型名，回滚后仍可能运行新 Prompt 或新 Schema，得到一个没人测试过的混合版本。

迁移过程至少经过五道门：

第一扇门不是测试，是找到所有调用者

模型依赖不只在代码仓库：

Agent 默认路由；
数据库里保存的助手副本；
定时任务创建时冻结的配置；
工作流某个节点的硬编码；
fallback 与重试链；
企业、组织、团队和服务身份的访问策略；
为旧模型写的解析器、Prompt 适配和 timeout。

给每条依赖建立 WorkloadBinding：

ts 复制代码

type WorkloadBinding = {
  workloadId: string;
  jobContract: string;
  principal: string;
  environment: "dev" | "staging" | "prod";
  effectClass: "read" | "draft" | "external-write" | "irreversible";
  currentRoute: string;
  candidateRoute: string;
  rollbackRoute: string;
  owner: string;
};

优先处理 external-write、irreversible 和没有回退路线的定时任务。只读问答失败通常会暴露；后台任务静默降级才最容易拖到业务现场。

权限核验要用运行身份，不要用管理员下拉框

GitHub 的企业模型策略可以在企业层启用、禁用或下放访问，组织和团队还可能继续影响最终可用性。管理员个人看得到候选模型，不代表生产服务身份调得到。

所以迁移前需要一条确定性的 Probe：

ts 复制代码

type AccessProbe = {
  principal: string;
  routeId: string;
  status: "ALLOWED" | "DENIED" | "UNKNOWN";
  policySource?: string;
  checkedAt: string;
};

UNKNOWN 很重要。网络超时、策略 API 不可用、页面状态读不清，都不能被自动折算成 ALLOWED。需要扩大权限时，应返回最小管理员动作，而不是让 Agent 自己换一把更大的 Key。

影子运行比较的是副作用和交付，不是文案相似度

把同一份脱敏输入分别交给当前路由和候选路由，记录统一的运行事件：

ts 复制代码

type ShadowRun = {
  caseId: string;
  routeId: string;
  output: unknown;
  toolPlan: Array<{ name: string; argsHash: string }>;
  effects: Array<{ type: string; target: string; executed: false }>;
  citations: string[];
  latencyMs: number;
  cost: number;
  failure?: { code: string; retryable: boolean };
};

注意 executed: false。影子环境的关键不是多跑一遍，而是不把测试变成第二次真实操作：

发布工具只生成预填计划，不点提交；
邮件写入隔离收件箱；
支付、删除和权限修改只返回模拟结果；
草稿写入独立空间，并带自动清理标记。

逐字相似度对生成式任务价值有限。应该比较：

JSON 与必填字段是否通过；
引用是否在允许来源中；
工具是否属于岗位白名单；
参数是否通过确定性校验；
是否出现未授权外发或写入意图；
人工修改率是否超过当前基线；
P95 延迟和单位交付成本是否越线。

可以把规则分成硬门和软指标：

ts 复制代码

function decide(r: Evaluation): "PASS" | "REVIEW" | "FAIL" {
  if (!r.schemaValid) return "FAIL";
  if (r.forbiddenEffects > 0) return "FAIL";
  if (r.unverifiableFacts > 0) return "FAIL";

  if (r.p95LatencyMs > r.latencyBudget) return "REVIEW";
  if (r.humanEditRate > r.editRateBaseline) return "REVIEW";
  if (r.costPerDelivery > r.costBudget) return "REVIEW";
  return "PASS";
}

不要把工具越界和文风改善平均成一个 82 分。高风险错误必须是不可被抵消的硬失败。

灰度不是随机抽 5%，而是先放低风险工作

随机流量适合相近请求，不适合风险差异很大的岗位。

更稳的顺序是：

内部分类、摘要、只读检索；
可丢弃的草稿和临时文件；
需要人工确认的外部沟通；
公开发布和业务写入；
支付、删除、权限变更等不可逆动作。

迁移期可以让高风险动作继续走旧路由或人工执行，即使低风险任务已经切到候选模型。所谓"全量"应该按岗位能力定义，不是把所有 Tool Call 在同一秒切过去。

三层分离后，模型才是可替换依赖

最终要稳定下来的不是模型，而是三类资产：

岗位契约

定义输入、产物、允许工具、禁止副作用、需要审批的动作和失败交接格式。它不引用具体模型。

模型路由

记录当前与候选 RouteBundle，允许版本化、灰度和原子回滚。

验收基线

保存脱敏的真实任务、历史失败和边界输入。每个 Case 都带岗位契约版本，不把旧断言强加给已经改变的业务规则。

这三层分开后，可以讨论"模型 A 是否能替代模型 B"；否则团队只是在比较两个聊天框的印象。

回滚条件应该在切流量前写好

至少为以下事件设硬回滚：

未授权工具、域名或运行身份；
Schema 硬失败超过错误预算；
事实引用无法核验；
公开写入结果无法确认；
定时任务因延迟发生重叠；
人工修改率持续显著高于同岗位基线。

回滚动作也要幂等。路由已经回到 r17 时，再执行一次回滚应返回"已完成"，不能创建第二条混乱的配置分支。

如果旧模型已经 Retired，旧路由就不再是有效回滚目标。这也是为什么迁移不能拖到最后一天：你需要的是另一条仍可用且已经验证的路由，而不是一份过期配置。

这也是我们做 Tipkay 时的一个取舍

Tipkay 面向小微企业、一人公司和小团队。不同垂类助手各自带岗位经验、流程、Skill、MCP 和工具，多模型档位是执行资源之一，而不是岗位说明书本身。

这意味着模型可以切换，但内容助手仍要完成事实核验、平台改写、配图、排版和发布准备；发布助手仍要回读真实页面并确认结果。不能因为换了一个模型，就把完整交付退化成"生成了一段看起来不错的文本"。

一个人的生意，也能有一支专业团队。真正有用的不是永远押中同一个模型，而是模型换班时，岗位能力仍有契约、有样例、有观测，也有回来的路。

一个下午能完成的最小版本

不做平台，也能先建四样东西：

text 复制代码

model-inventory.yaml       # 谁在用什么
job-contracts/             # 岗位交付与禁止项
golden-cases/              # 脱敏真实任务与断言
route-snapshots/           # 当前、候选、回滚路由

然后按"盘点 → 授权 → 影子 → 灰度 → 回滚演练"走一遍。模型退役不可避免，停工不是。

参考资料

GitHub Changelog, Upcoming August 2026 model deprecations in GitHub Copilot: github.blog/changelog/2...
GitHub Changelog, GitHub Copilot in VS Code, August 2026 releases: github.blog/changelog/2...
GitHub Docs, Managing availability of models in your enterprise: docs.github.com/en/copilot/...
GitHub Docs, About default availability of Copilot models: docs.github.com/en/copilot/...
Anthropic Claude Platform Docs, Model deprecations: platform.claude.com/docs/en/abo...