承接： 从 Copilot 到 Agent 的角色跃迁 · GitHub Actions 工作流执行前审批
调研日期：2026-07-31
本文目标：把 GitHub Models 正式退役转成一份可执行的资产盘点、模型接入迁移与验收清单，避免 Agent 项目把“换一个端点”误当成一次可控迁移。

2026-07-30，GitHub 确认 GitHub Models 已正式退役：playground、模型目录、推理 API 与 BYOK 均不再向任何客户提供服务，包括仍有活跃用量的现有客户。GitHub 在公告中把 Microsoft Foundry 指向需要模型访问的项目，把 GitHub Copilot 指向直接在 GitHub 内构建 AI 工作流的场景。

这里最容易被忽略的一点是：公告没有承诺存在“原端点、原密钥、原模型名不变”的一键替换。因此，正确问题不是“哪个 SDK 能最快跑通”，而是：哪些 Agent 能力依赖这项已退役服务、它们失败时会不会误做决策、以及新接入是否通过了与业务相同的验收。

---

一、先把官方事实和迁移决策分开

维度	已核验事实	团队需要自行决定的事
服务状态	截至 2026-07-30，GitHub Models 的推理 API、模型目录、playground 与 BYOK 都已退役	哪些系统必须立刻切换，哪些功能应先降级或暂停
官方指向	GitHub 提到 Microsoft Foundry 与 GitHub Copilot 两个方向	是否适合你的地区、合规、模型能力、成本与现有架构
兼容性	公告未给出 API 级的无缝替代承诺	模型参数、结构化输出、工具调用、流式返回、限流与审计如何重新验证
回滚	已退役服务不能作为回滚目标	为新接入预留开关、第二条受控路径和人工降级流程

本文中的清单、代码边界和验收矩阵是工程建议，不是 GitHub 对替代服务的功能承诺。

---

二、第一小时先画出爆炸半径，而不是先改 SDK

GitHub Models 的依赖通常不只在一处业务代码。Agent 项目至少要同时检查下面五类资产：

位置	要找什么	为什么容易漏
应用代码	直接 HTTP 调用、推理 SDK、模型名、endpoint	一个工具节点可能绕过了统一客户端
Agent 编排	默认模型、fallback、工具调用与 JSON 输出约束	“主对话能答”不代表子 Agent 还能正确协作
CI/CD	冒烟测试、评测、发布后验证中的模型调用	运行时已迁移，流水线仍可能用旧凭据
配置与密钥台账	环境变量名、Secret 名称、BYOK 说明	不应把新厂商凭据误塞回旧变量语义
人工流程	playground 调试、模型选型记录、值班手册	人手验证路径失效，故障时没人知道该看哪里

下面的 PowerShell 只用于初步定位字符串；它不会也不应该打印任何 Secret 值。按你的代码栈补充扩展名和项目专用关键字：

$extensions = @(".ts", ".tsx", ".js", ".mjs", ".py", ".yml", ".yaml", ".json", ".toml")
$patterns = @(
  "github[ .-]?models",
  "models\.inference",
  "BYOK",
  "model[_-]?endpoint",
  "model[_-]?provider"
)

Get-ChildItem -Path . -Recurse -File |
  Where-Object { $extensions -contains $_.Extension } |
  Select-String -Pattern $patterns |
  Select-Object Path, LineNumber, Line

把结果整理成一张小表：调用者、用途、是否面向用户、输入数据等级、当前失败行为、负责人。只要有一项不清楚，就不要直接替换默认模型。

---

三、迁移目标不是“换供应商”，而是建立可替换的模型边界

面对这次退役，常见的三种落点如下：

方案	适用场景	需要额外验证的点
迁往 Microsoft Foundry	业务需要直接调用模型，并希望集中管理模型接入	区域、身份、模型能力、配额、数据处理与费用边界
改用 GitHub Copilot 能力	工作本来就发生在 GitHub 内，例如编码、审查或工作流辅助	它是产品工作流能力，不应假定等价于通用推理 API
自建模型网关并接入一个或多个提供方	多 Agent、多个环境或需要明显的可移植性	网关本身的鉴权、审计、限流、回退和配置治理

无论选哪一种，应用侧都应只认识自己的模型契约，而不是某一家平台的 SDK。下面是一个不绑定提供商的 TypeScript 最小边界；它可直接通过 TypeScript 编译，但其中的具体 ProviderClient 需要由你的项目实现。

// model-client.ts
export type GenerateInput = {
  messages: Array<{ role: "system" | "user" | "assistant"; content: string }>;
  jsonMode?: boolean;
  traceId: string;
};

export type GenerateOutput = {
  text: string;
  provider: string;
  model: string;
  requestId?: string;
};

export interface ModelClient {
  generate(input: GenerateInput): Promise<GenerateOutput>;
}

export class RoutedModelClient implements ModelClient {
  constructor(
    private readonly primary: ModelClient,
    private readonly secondary: ModelClient | undefined,
    private readonly allowFallback: boolean,
  ) {}

  async generate(input: GenerateInput): Promise<GenerateOutput> {
    try {
      return await this.primary.generate(input);
    } catch (error) {
      if (!this.allowFallback || !this.secondary) throw error;
      return this.secondary.generate(input);
    }
  }
}

这个边界刻意不把“任意错误都回退”写死。涉及扣费、部署、删改数据或高风险工具调用的 Agent，失败后更合理的默认值通常是停在人工复核，而不是悄悄换一个模型继续执行。

---

四、把迁移验收拆成能力、风险和可观测性三层

只做一次“你好世界”不能证明迁移完成。建议用一个非生产项目跑下面的验收矩阵，再逐步扩大到真实流量：

验收项	最小测试	通过标准
身份与隔离	用最小权限凭据发起一次调用，并故意使用错误凭据	正常请求可用；错误凭据被拒绝且日志不泄露敏感内容
输出契约	为 JSON、函数调用或结构化字段准备固定样例	成功输出能被下游解析；失败不会被当成有效业务数据
Agent 工具链	跑一次包含检索、工具调用、汇总的最小任务	工具参数、停止条件与审计关联仍然正确
延迟与限流	以可控并发重复调用	超时、429 或服务错误进入明确的重试/降级路径，而不是无限重试
风险动作	模拟需要发布、付款或写入的数据操作	模型异常时不能绕过审批、授权或幂等保护
观测	从请求入口追到模型调用和最终业务结果	每次调用能关联 trace、provider、model、耗时和结果类别；日志不记录提示词中的敏感数据

如果你的 Agent 依赖模型输出生成工具参数，还要添加“坏输出”测试：缺字段、额外字段、错误类型、过长文本和看似正确但违反业务规则的值。模型服务迁移最危险的情况往往不是调用直接报错，而是返回了不同风格的成功结果，随后被下游当真。

---

五、迁移顺序：先建立开关，再逐步移动调用

1. 冻结旧依赖的扩散。 在新需求中禁止复制旧 endpoint、旧 SDK 初始化代码和旧 Secret 名称。
2. 盘点并标记风险。 将前文扫描到的调用分为读操作、业务自动化和高风险写操作。
3. 建立适配层与配置开关。 让 provider、model、超时、重试策略和是否可回退都能按环境调整；不要把这些值散落在各个 Agent 提示词中。
4. 影子验证或低风险灰度。 使用脱敏样例比较结构正确性、耗时和失败路径，而不是只比较自然语言“看起来像不像”。
5. 把高风险路径留在人类门后。 即使新模型通过了普通问答测试，发布、权限变更和外部写操作仍应保留上一篇所说的审批与最小权限边界。
6. 记录新运行手册。 更新负责团队、Secrets 所在位置、预算/配额告警、故障降级和“不能回滚到 GitHub Models”这条事实。

---

六、四个常见误区

1）把 GitHub Copilot 当成通用推理 API 的直接替身

GitHub 提到 Copilot 是为了在 GitHub 内构建 AI 工作流；这并不等价于它提供与原推理 API 相同的请求协议、模型目录或计费行为。先按你的调用形态评估，再做接口设计。

2）把旧的 GitHub 凭据复制给新平台

新的模型接入应签发与新用途相符、范围最小的凭据。不要因为变量名方便就复用旧 Token，也不要在日志、Issue 或评测快照中写入新 Secret。

3）只测试主聊天，不测试工具调用

Agent 在真实场景中的失败经常发生在 JSON 约束、函数参数、长上下文、流式中断和重试。至少把一条端到端工具链作为迁移门槛。

4）把“fallback”理解成回滚

GitHub Models 已退役，不能在出问题时切回去。真正的回滚是：事先验证的第二条路径、特性开关、人工接管和可解释的暂停机制。

---

结语

平台退役是一场架构边界考试。把模型调用留在一个可观察、可配置、可限制权限的适配层里，下一次模型变更才不会变成全仓库搜字符串的救火。

建议先完成资产盘点和一条低风险 Agent 的端到端验收，再迁移涉及外部写操作的流程。只有当错误、降级和审计同样被验证过，新的模型接入才算真正可用。

---

来源与延伸阅读

• GitHub Models is now retired：GitHub 官方公告，发布于 2026-07-30。
• GitHub Models is being fully retired on July 30, 2026：退役范围与此前演练中断的官方说明。
• GitHub Models is being fully retired on July 30, 2026:将模型能力放入清晰验收与人工审阅流程
• 供应链防线深度实践：GitHub Actions 的执行前拦截来了，Agent CI/CD 还要补哪三道门:为迁移后的高风险 Agent 动作保留执行前门禁。