GitHub公告显示，GitHub Models已于2026年7月30日全面退役，Playground、模型目录、推理API以及自带密钥BYOK入口均停止服务，现有客户也受影响。官方建议需要模型目录与推理服务的项目迁移到Microsoft Foundry，在GitHub内的开发辅助则继续使用Copilot。对开发者而言，这类平台退役提醒我们：模型调用不能写死在一个供应商接口里。
先盘点哪些地方依赖GitHub Models
搜索代码中的旧端点、模型名称、环境变量和SDK包，同时检查CI任务、定时脚本、演示环境与内部文档。很多团队只改了主服务，却遗漏测试脚本或无服务器函数，最终在夜间任务中报错。建议建立清单，标出调用量、用途、负责人、数据敏感级别和允许停机时间。
设计统一模型适配层
业务代码不要直接依赖某家SDK返回结构。建立内部接口，统一messages、温度、最大输出、工具调用和错误类型，再为不同平台实现适配器。模型名称通过配置管理，密钥只从安全存储读取。这样迁移时主要替换适配器，而不是修改每个业务模块。
迁移不能只做到请求成功
不同平台即使兼容OpenAI格式，系统提示、工具调用、流式输出、JSON约束和限流规则仍可能不同。准备一组真实评测样本，比较正确率、格式稳定性、首Token延迟、总成本和拒答情况。特别检查中文、长上下文、函数参数以及异常重试，不要拿一个“你好”请求作为验收。
密钥与权限处理
旧密钥应在完成切换后撤销，不要长期保留“备用入口”。新平台使用独立项目和最小权限身份，开发、测试、生产分开计费与限额。日志中隐藏Authorization头和用户敏感内容。若使用托管模型目录，还要确认数据区域、保留策略和是否用于模型训练。
双写、灰度与回滚
低风险阶段可以把少量请求同时发送给新旧服务，只向用户返回旧结果，用于比较差异；退役后则使用历史结果做回放。正式切换时从内部用户或5%流量开始，观察错误率和成本，再逐步扩大。配置中保留另一家可用模型作为灾备，但故障切换要设置最大次数，避免服务异常时产生费用风暴。
如果项目只需要编程辅助
不要为了替代Playground而搭建过重平台。个人开发者可选择Copilot或其他成熟编码工具；需要在产品中调用模型、做Agent和多模型评测时，再使用Foundry或独立API。选择应由业务需求决定，而不是因为某个平台曾经免费。
长期架构建议
建立模型资产表，记录供应商、版本、价格、上下文、数据政策和替代方案；每季度做一次切换演练。提示词、评测集和工具定义都应独立保存并版本化。平台会改名、涨价、限流甚至退役，真正稳定的是自己的协议层、数据治理和测试能力。
