TL;DR

• 场景:GitHub Models 将于 2026-07-30 全面退役(Playground、Model Catalog、Inference API、BYOK Endpoint),7-23 还有一次 Brownout
• 结论:正确的迁移对象不是某个 Base URL,而是完整的模型访问契约;OpenAI-compatible 只能减少客户端改造,不能证明语义、配额、治理兼容;迁移必须建立 Provider Capability Registry + Capability Probe + Shadow Traffic + 分批 Cutover + 可回滚
• 产出:GitHub Models 四类角色拆解 + 迁移 Inventory 模板 + AI Access Layer 内部契约 + Provider Capability Registry YAML + Capability Probe 12 项 + 5 步 Cutover + Brownout 演练清单 + 7-20 到 7-30 实施日历 + Provider 退出预案 13 项

版本矩阵

功能	状态	说明
2026-06-16 GitHub Models 不再向新客户开放	⚠️ 待官方公告核验	原文母稿日期 2026-07-20;web 搜索未命中 2026 年 GitHub Models 退役官方公告,具体日期需以 GitHub Changelog 为准
2026-07-16 第一次 Brownout	⚠️ 待官方公告核验	原文自述"已过去;本文未取得用户系统的实测日志",需在 GitHub Changelog 核验
2026-07-23 第二次 Brownout(请求返回错误)	❓ 未公开	母稿日期 7-20,此事件为未来,需主动探测
2026-07-30 全面关闭(Playground/Catalog/Inference API/BYOK)	❓ 未公开	母稿日期 7-20,此事件为未来,需以当日官方公告为准
关闭范围:Playground + Model Catalog + Inference API + BYOK Endpoint	⚠️ 按作者主张	原文明确,需以 GitHub 官方公告为准
现有客户同样受影响	⚠️ 按作者主张	原文明确,需以 GitHub 官方公告为准
官方建议:模型目录、部署、推理 → Microsoft Foundry	⚠️ 按作者主张	原文明确,需以 GitHub/F5 官方公告为准
官方建议:GitHub 工作流内 AI → GitHub Copilot	⚠️ 按作者主张	原文明确,需以 GitHub 官方公告为准
GitHub Models REST API 曾支持 Streaming、JSON Schema、Tool Calling、组织归因	✅ 已验证	多源开发者文档 + 第三方迁移文章
Microsoft Foundry 模型目录 + 部署 + 推理	✅ 已验证	Microsoft 官方 Azure AI Foundry 文档
Vercel AI Gateway(统一 API + 用量/预算 + 路由/Fallback)	✅ 已验证	Vercel 官方文档
OpenRouter(多 Provider 路由 + Fallback + BYOK/ZDR)	✅ 已验证	OpenRouter 官方文档
LiteLLM(开源 LLM Gateway,支持多 Provider)	✅ 已验证	LiteLLM 官方仓库
4 类 GitHub Models 角色:Model Discovery / Playground / Inference API / BYOK	✅ 已验证(作者分析)	原文第二段,作为分析框架
AI Access Layer 6 模块(Model Alias / Capability Registry / Policy / Routing / Telemetry / Credential Broker)	✅ 已验证(作者架构)	原文第四节,作为架构图
OpenAI-compatible 14 维差异表	✅ 已验证(作者分析)	原文第七节表,作为兼容性测试清单
Capability Probe 12 项	✅ 已验证(作者设计)	原文第八节,作为探测清单
5 步 Cutover(0%/1%/5%/25%/50%/100%)	✅ 已验证(作者设计)	原文第十节,作为分批切换建议
自动回滚 4 条件(error_rate/schema_invalid_rate/p95/cost)	✅ 已验证(作者设计)	原文第十节,作为示例
Provider 退出预案 13 项(资产/Owner/Alias/Registry/第二 Provider/Probe/质量基线/Shadow/Flag/Key 轮换/数据导出/最长迁移/退出触发器)	✅ 已验证(作者设计)	原文第十五节,作为预案模板
7-20 到 7-30 实施日历	✅ 已验证(作者设计)	原文第十四节,作为时间表
Brownout 演练 5 项(错误/降级/状态/密钥/回滚)	✅ 已验证(作者设计)	原文第十一节,作为演练清单
AscendLab Provider Capability Tester 工具机会(CLI + Key 不写日志 + 可重复 Probe + capability-registry.yaml + Markdown)	✅ 已验证(作者设计)	原文第十六节,作为工具机会描述
GHM-01 / GHM-02 / GHM-03 / FOUNDRY-01 / GW-01 / GW-02 / GW-03 来源链接	⚠️ 待验证	原文给出来源代号但未给完整 URL,需在 [S01] 链接核验

GitHub Models 将于 2026 年 7 月 30 日全面退役,关闭 Playground、Model Catalog、Inference API 和 BYOK Endpoint;7 月 23 日还有一次 Brownout。GitHub 建议将模型目录与推理场景迁往 Microsoft Foundry,把 GitHub 工作流中的 AI 使用转向 GitHub Copilot。但这不是一对一替换:模型 ID、版本、鉴权、限流、Streaming、Tool Calling、Structured Output、多模态、Embedding、数据策略和计费都可能不同。

正确的迁移对象不是某个 Base URL,而是完整的模型访问契约。团队需要先建立 Inventory,再把调用能力描述为 Provider Capability Registry;使用兼容探针验证接口和行为;通过 Shadow Traffic 对比质量、延迟、成本与失败;最后进行分批 Cutover 和可回滚切换。OpenAI-compatible 只能减少客户端改造,不能证明语义、配额和治理兼容。

GitHub Models 的退出也说明一个产品事实:通用模型入口若缺少独立工作流和治理价值,容易被更大的 Agent 产品、云平台或 AI Gateway 吸收。独立开发者应把 Provider 当作可替换依赖,并为平台退出建立标准预案。

核心结论

1. 先拆解 GitHub Models 的四类角色:发现、试验、推理、BYOK。每类能力的替代方案不同。
2. GitHub 官方迁移建议是方向,不是无损映射。Foundry 和 Copilot 的产品边界不同,不能替代所有自定义应用。
3. OpenAI-compatible 只是接口家族。Tool Schema、JSON 约束、错误、Streaming 事件、Usage、重试和费用仍需逐项测试。
4. Brownout 是最有价值的演练窗口。应记录错误码、恢复时间、Retry 行为和业务降级,而不是等待 7 月 30 日直接切断。
5. 迁移必须可回滚:Feature Flag、双写、Shadow Traffic、Provider Registry、Key Rotation 和状态对账缺一不可。

1. 官方时间线与关闭范围

日期	事件	状态
2026-06-16	GitHub Models 不再向新客户开放	已发生
2026-07-16	第一次 Brownout	已过去;本文未取得用户系统的实测日志
2026-07-23	第二次 Brownout,请求返回错误	未来
2026-07-30	全面关闭	未来

官方公告列出的关闭范围:

• Playground;
• Model Catalog;
• Inference API;
• BYOK Endpoint;
• 现有客户同样受影响。

官方方向:

• 模型目录、部署与推理迁向 Microsoft Foundry;
• GitHub 工作流内的 AI 能力转向 GitHub Copilot。

需要注意,GitHub Models REST API 曾支持 Streaming、JSON Schema、Tool Calling 和组织归因等能力。迁移清单不能只记录模型名称和 Prompt。

2. GitHub Models 原本承担的四个角色

Model Discovery+ Playground / Prompt Experiment+ Unified Inference API+ BYOK Endpoint= GitHub Models Product Surface

2.1 Model Discovery

用户通过 Catalog 比较模型、能力、发布者和基础信息。替代它需要的是 Registry、筛选、能力说明和版本治理。

2.2 Playground

用于快速测试 Prompt、参数和输出。替代它需要保存实验配置、结果、成本和可复现性,而不只是另一个聊天界面。

2.3 Inference API

承担应用运行时调用。这里迁移风险最高,涉及:

• Endpoint 和鉴权;
• 模型 ID 与版本;
• 请求/响应 Schema;
• Streaming;
• Tool Calling;
• Structured Output;
• 多模态与 Embedding;
• 限流、错误、重试;
• Usage 和计费;
• 数据处理和区域。

2.4 BYOK

BYOK 不只是"把自己的 Key 放进去"。它通常还涉及统一 Endpoint、路由、用量归因、失败回退和凭据托管。迁移时必须决定:继续使用 Gateway BYOK、直连 Provider,还是迁入云平台托管部署。

3. 迁移 Inventory

在改代码前,先列清所有使用点:

application,owner,environment,endpoint,model_id,capability,requests_per_day,p95_latency_ms,max_tokens,tools,structured_output,streaming,embedding,byok_provider,data_classification,criticality,rollback_ownersupport-bot,cs-platform,prod,github-models,gpt-x,chat,120000,1800,4096,true,true,true,false,openai,internal,critical,alicecontent-pipeline,growth,prod,github-models,model-y,chat,8000,4200,8192,false,true,false,false,,public,medium,bobsemantic-search,search,prod,github-models,embed-z,embedding,600000,350,,false,false,false,true,,internal,critical,carol

必须补充的隐藏依赖:

• SDK 包和版本;
• CI/CD Secret;
• Terraform/Helm 配置;
• Prompt Template;
• Tool Schema;
• JSON Parser;
• Timeout/Retry;
• 缓存 Key;
• 评测基线;
• 成本告警;
• 合规文档;
• Dashboard 和日志字段。

4. 目标架构:应用不直接绑定 Provider

Application↓ Stable Internal ContractAI Access Layer├── Model Alias Registry├── Capability Registry├── Policy / Budget / Data Region├── Routing / Retry / Fallback├── Telemetry / Evaluation└── Credential Broker↓Foundry / Direct Provider / Vercel Gateway / OpenRouter / Other

内部契约需要稳定,但不能过度抽象成最低公分母。建议把通用字段与 Provider Extension 分开:

{"model_alias": "reasoning-medium","messages": [{"role": "user", "content": "..."}],"response_format": {"type": "json_schema", "schema": {}},"tools": [],"policy": {"data_classification": "internal","region": "us","max_cost_usd": 0.08,"fallback_allowed": true},"provider_options": {"reasoning_effort": "medium"}}

provider_options 应通过 Allowlist,避免业务随意把 Provider 私有参数渗透到所有代码。

5. Provider Capability Registry

providers:foundry-prod:type: microsoft-foundryendpoint: ${FOUNDRY_ENDPOINT}region: eastus2auth: managed-identitydataPolicy: enterprise-approvedvercel-gateway:type: vercel-ai-gatewayauth: api-keydataPolicy: review-requiredmodels:reasoning-medium:candidates:- provider: foundry-prodmodel: deployment-reasoning-v3capabilities:chat: truestreaming: truetools: trueparallel_tools: falsejson_schema: strictvision: falseembeddings: falsemax_input_tokens: 128000usage_in_stream: verified- provider: vercel-gatewaymodel: provider-x/model-ycapabilities:chat: truestreaming: truetools: trueparallel_tools: unknownjson_schema: best_effortvision: trueembeddings: falsemax_input_tokens: 200000usage_in_stream: unknownpolicy:primary: foundry-prodfallback: [vercel-gateway]allowedData: [public, internal]

Registry 中的能力必须来自自动探针和人工评测,不能只抄营销页面。

6. OpenAI-compatible 能解决什么

通常可以减少:

• Client 初始化差异;
• /chat/completions 或 /responses 请求结构差异;
• Message、Temperature、Max Tokens 的基础映射;
• Streaming 的基本消费方式;
• Tool 定义的基础 Schema;
• 常见 SDK 的替换成本。

7. OpenAI-compatible 不能保证什么

维度	可能差异
模型 ID	名称、版本、部署名、别名不同
System/Developer Message	支持程度和优先级不同
Structured Output	严格 Schema、Best-effort、拒绝行为不同
Tool Calling	Tool Choice、并行调用、参数修复不同
Streaming	SSE Event、Delta、Usage、Finish Reason 不同
多模态	图片输入格式、大小、URL 支持不同
Embedding	维度、归一化、Batch 上限不同
错误	HTTP 状态、错误码、可重试性不同
限流	RPM/TPM/并发/动态配额不同
Tokenizer	Token 数和费用估计不同
Safety	拒绝、过滤、内容策略不同
数据治理	保留、训练、区域、ZDR 不同
费用	输入/输出/缓存/工具/区域不同
输出质量	Prompt 对同类模型也可能漂移

因此,迁移验收必须覆盖"接口可调用"和"业务行为可接受"两层。

8. Capability Probe

本内容包的 tools/provider_probe.py 提供一个最小探针。生产探针应覆盖:

1. 基础非 Streaming Chat;
2. Streaming 首 Token、结束事件和 Usage;
3. JSON Schema 严格符合率;
4. 单 Tool、并行 Tool、无效参数;
5. 长上下文边界;
6. Unicode、中文和代码;
7. 图片输入;
8. Embedding 维度、批量和确定性;
9. 429、5xx、Timeout 和连接中断;
10. Request ID、Trace、Usage 和费用字段;
11. 数据区域和日志策略;
12. Key 权限与失效行为。

结果示例:

{"provider": "foundry-prod","model": "deployment-reasoning-v3","tested_at": "2026-07-20T09:00:00Z","capabilities": {"chat": {"status": "pass", "p50_ms": 1320},"streaming": {"status": "pass", "first_token_p50_ms": 410},"json_schema": {"status": "pass", "valid_rate": 1.0},"parallel_tools": {"status": "fail", "reason": "single tool only"}}}

9. Shadow Traffic

Shadow Traffic 将生产请求复制到候选 Provider,但候选结果不返回用户。

Production Request├── Current GitHub Models → User Response└── Redacted Shadow Copy → Candidate Provider↓ Evaluation Store

必须控制

• 去除或 Tokenize PII;
• 只对允许的数据等级双写;
• Shadow 请求不触发真实 Tool 副作用;
• 记录 Prompt Template、模型版本和参数;
• 控制额外成本;
• 避免把用户数据发到未批准区域;
• 对 Streaming 与非 Streaming 分开评估。

评估指标

• 请求成功率;
• P50/P95 延迟、首 Token;
• JSON Schema 合规率;
• Tool Call 正确率;
• 任务完成率;
• 自动评测 + 人工盲评;
• 输入/输出 Token 与实际费用;
• 拒绝率;
• 安全和数据策略事件;
• 输出漂移。

LLM-as-a-Judge 只能作为一层,应加入确定性验证、任务结果和人工抽样。

10. Cutover 与 Rollback

分阶段切流

0%→ Probe1%→ Internal / Synthetic5%→ Low-risk Tenants25% → Broader Production50% → Compare Capacity / Cost100% → Primary→ Keep Old Path Disabled-but-Ready until retirement

由于 GitHub Models 将退役,旧路径的最终回滚窗口有限。迁移完成前应至少保留两个可用候选 Provider,而不是把单点从 GitHub 转移到另一个平台。

自动回滚条件示例

rollback:window: 10mconditions:- metric: request_error_rateop: ">"value: 0.02- metric: schema_invalid_rateop: ">"value: 0.01- metric: p95_latency_msop: ">"value: 6000- metric: cost_per_success_usdop: ">"value: 0.12action:setPrimary: secondary-providerdisableNewProvider: truepage: ai-platform-oncall

11. Brownout 演练

2026-07-23 应把 Brownout 当成故障演练:

• 从多个 Region 和应用执行 Canary;
• 记录 HTTP 状态、错误 Code、Body、Header、Request ID;
• 记录开始、恢复和间歇成功;
• 检查 SDK 是否错误重试导致请求风暴;
• 检查 Gateway 是否按策略 Fallback;
• 检查 Queue、Timeout、熔断和用户提示;
• 检查 Dashboard 和告警是否能区分 Provider 故障;
• 保存日志用于 7 月 30 日前最终验收。

不能提前写死具体错误码。实验模板见 ../research-bundles/2026-07-20-ai-engineering-content-pack/experiments/github-models-brownout-test-plan.md。

12. Key 与凭据迁移

不要复用旧 Key 语义

• GitHub Token、Provider Key、Foundry Managed Identity 和 Gateway Key 的权限模型不同;
• 新系统应建立 Key Owner、用途、环境、创建/到期、轮换和撤销;
• BYOK Key 从旧平台移出后,应在 Provider 侧轮换,而不是长期保留同一 Key;
• 应删除 CI、Secret Manager、日志和开发环境中的旧引用;
• 应用不直接持有多个 Provider Key,优先通过 Credential Broker 或托管身份。

轮换流程:

Create New Credential↓ Test In Non-prodAdd To Gateway / Broker↓ Shadow TrafficSwitch Primary Credential↓ MonitorRevoke Old Credential↓ Search Residual References

13. Foundry、Gateway、OpenRouter 与直连的比较维度

方案	优势	风险/成本	适合
Microsoft Foundry	企业部署、Azure 身份/网络/治理、模型目录	云绑定、Deployment 管理、SDK/Endpoint 变化	Azure 企业团队
Vercel AI Gateway	统一 API、用量/预算、路由/Fallback	平台依赖、兼容需验证	Web/AI SDK 生态、快速迁移
OpenRouter	多 Provider 路由、Fallback、BYOK/ZDR 选项	Provider 链复杂、费用/数据策略需逐路由理解	多模型探索与冗余
LiteLLM/自建 Gateway	控制强、可自托管、可定制策略	运维、兼容、监控、安全责任	有平台团队、强合规
Provider 直连	功能最完整、最少中间层	业务耦合、凭据分散、退出成本高	单 Provider、专有能力关键

决策不应只看请求价格,还应看故障域、数据路径、审计、预算、延迟和退出能力。

14. 迁移实施日历

2026-07-20

• 冻结新增 GitHub Models 依赖;
• 完成 Inventory;
• 建立模型 Alias;
• 选择至少两个候选路径;
• 部署 Capability Probe。

2026-07-21—22

• 迁移低风险开发/测试;
• 运行 Shadow Traffic;
• 完成 Key Rotation 预案;
• 配置 Brownout 监控和 Fallback。

2026-07-23

• 记录 Brownout;
• 验证自动降级;
• 修复 Retry Storm、错误解析和告警缺口。

2026-07-24—27

• 分阶段生产切流;
• 对账成功率、质量、延迟和成本;
• 处理 Embedding 索引或 Tool Schema 差异。

2026-07-28—29

• 100% 切离;
• 执行恢复演练;
• 清理旧 Key 与 Endpoint;
• 完成业务 Owner 签字。

2026-07-30

• 只做退役确认和残留扫描,不应再进行主迁移。

15. 模型平台退出预案

每个外部 Provider 都应有:

• 资产清单;
• Owner 和严重度;
• 模型 Alias 而非业务硬编码;
• Capability Registry;
• 第二 Provider;
• 兼容探针;
• 质量基线;
• Shadow Traffic;
• Feature Flag;
• Key 轮换;
• 数据导出;
• 最长迁移时间;
• 退出触发器;
• 演练频率。

退出触发器包括:退役公告、价格上涨、配额下降、区域/合规变化、模型删除、质量漂移、重大故障和公司风险。

16. AscendLab 工具机会:Provider Capability Tester

定位

输入多个 OpenAI-compatible Endpoint、模型和 Key 环境变量,执行安全、无副作用的能力测试,输出:

• Chat/Streaming;
• JSON Schema;
• Tool Calling;
• 多模态;
• Embedding;
• 错误与重试;
• Usage/费用字段;
• Markdown 兼容报告。

MVP

• 本地 CLI;
• Key 不写日志;
• JSON/YAML Provider 配置;
• 可重复 Probe Case;
• 输出 capability-registry.yaml 和 Markdown;
• 支持历史 Diff 和 CI 失败阈值。

后续

• 浏览器本地版;
• Provider 价格快照;
• Shadow Evaluation;
• Prompt/Tool Fixture 管理;
• Gateway Migration Checklist;
• SaaS 团队报表。

17. 发布检查表

• 7 月 23 日与 7 月 30 日写成未来时间。
• 关闭范围包含 Playground、Catalog、Inference API、BYOK 和现有用户。
• 不把 Foundry/Copilot 写成所有用例的一对一替代。
• Inventory 覆盖模型、工具、Structured Output、Streaming、Embedding、数据和成本。
• OpenAI-compatible 差异逐项探测。
• Shadow Traffic 不触发真实 Tool 副作用。
• Cutover 有 Feature Flag 和自动回滚。
• Brownout 记录真实错误,不提前编造错误码。
• Key 迁移包含轮换与旧 Key 撤销。
• 至少保留两个可行 Provider 路径。
• 7 月 30 日前完成 100% 切离和残留扫描。

18. 常见错误

只换 Base URL

可能在 Tool、JSON、Streaming、Tokenizer、Error 或 Usage 上静默失败。

只做离线 Prompt 对比

生产差异包括并发、限流、长尾延迟、网络、Tool 副作用和数据策略。

Fallback 到不满足数据政策的 Provider

高可用不能凌驾于数据等级和区域限制。

在 Brownout 期间无限重试

会造成请求风暴和费用放大。应使用熔断、指数退避和全局并发控制。

把 Gateway 当成永久保险

Gateway 自身也可能退役或故障。内部契约、导出和第二路径仍然必要。

19. 限制与待验证

• Brownout 的具体错误行为需 2026-07-23 实测;
• 各候选 Provider 的价格、模型和能力在发布前需刷新;
• Microsoft Foundry 的具体模型映射取决于 Region、Subscription 和 Deployment;
• GitHub Models 的用户用量导出方式需要账户级核验;
• Embedding 迁移可能需要重建索引,不能与 Chat Endpoint 同等处理。

20. 延伸章节

• Provider Capability Registry 与自动探针。
• OpenAI-compatible 行为兼容 Benchmark。
• Shadow Traffic 与 LLM 输出对账。
• 多 Provider Fallback 的数据政策。
• AI API 供应商退役演练。
• BYOK Key Broker 与短期凭据。

参考来源

• GHM-01:GitHub Models 全面退役公告,2026-07-01。
• GHM-02:新客户停止开放公告,2026-06-16。
• GHM-03:GitHub Models Inference REST API 文档。
• FOUNDRY-01:Microsoft Foundry Models Endpoint 文档。
• GW-01:Vercel AI Gateway 文档。
• GW-02、GW-03:OpenRouter Routing 与 BYOK 文档。

错误速查卡

症状	根因	定位	修复
把 GitHub Models 退役当成 7-30 当天切换	忽略 Brownout 演练窗口和 7-24 之后的分阶段切流	查原文第十一节 Brownout 演练 + 第十四节实施日历	改写为"7-20 冻结 / 7-21-22 准备 / 7-23 演练 / 7-24-27 切流 / 7-28-29 切离 / 7-30 退役"
假设 Foundry / Copilot 是 GitHub Models 一对一替代	Foundry / Copilot / GitHub Models / 直接 Provider 产品边界不同	查原文第十三节比较表 + 核心结论第 2 条	改写为"Foundry 更接近企业云治理 / Copilot 更接近 GitHub 内 Agent 工作流 / 不能替代所有自定义应用"
只换 Base URL	把 OpenAI-compatible 等同于行为兼容	查原文第七节 14 维差异表	改写为"Tool Schema/JSON/Streaming/Tokenizer/Error/Usage/限流/数据治理 14 维需逐项探测"
把 Shadow Traffic 当成"安全测一下"	忽略 PII 去除、数据等级、Tool 副作用、用户数据发到未批准区域	查原文第九节 Shadow Traffic 必须控制 6 项	改写为"Shadow 也要 PII 处理 + 数据等级限制 + 工具不真触发 + 控制额外成本"
在 Brownout 期间无限重试	没有熔断/退避/全局并发控制	查原文第十八节常见错误	改写为"使用熔断 + 指数退避 + 全局并发控制,避免请求风暴和费用放大"
把 Gateway 当成永久保险	Gateway 自身可能退役	查原文第十八节 + 第十五节退出预案 13 项	改写为"内部契约 + 导出 + 第二路径仍然必要,Gateway 不是银弹"
用 model 字符串做能力判断	同一 model 字符串在不同 Provider / Region / Deployment 行为可能不同	查原文第五节 Provider Capability Registry + 能力必须来自自动探针	改写为"Registry 中的能力必须来自自动探针和人工评测,不能只抄营销页面"
假设 Microsoft Foundry 的 Deployment 跟 GitHub Models 模型 ID 1:1	同一模型在不同 Foundry Region / Subscription / Deployment 有差异	查原文第十三节 Microsoft Foundry 风险栏 + 第十九节"具体模型映射取决于 Region"	改写为"Foundry Deployment 取决于 Region / Subscription / Deployment,需要按账户级核验"
用"Provider 也支持 OpenAI API"作为迁移标准	忽略 Tool Schema / JSON / Streaming / Tokenizer / 错误 / 用量 / 限流 / 数据治理	查原文第七节 14 维差异表	改写为"接口兼容 ≠ 行为兼容;14 维差异表必须逐项探测"
假设 Fallback Provider 自动满足数据政策	Fallback Provider 可能不满足数据等级和区域	查原文第十八节常见错误"Fallback 到不满足数据政策的 Provider"	改写为"Fallback 也要走 Capability Registry + 数据政策 + 区域校验,不能凌驾于数据等级"
用 Capable but 慢的 Provider 作为 Primary	没测延迟,只看能力	查原文 Capability Probe 12 项 + Shadow Traffic 评估指标	改写为"Capable + 延迟 + 成本 + 数据政策多维评分,不只看功能"
假设 Brownout 期间能用同一 Key 重试	同一 Key 在 Brownout 期间可能临时失效	查原文第十二节 Key 轮换流程	改写为"Brownout 期间旧 Key 可能临时失效,Key Rotation 需提前演练"
假设 7-30 后 Gateway 会自动把数据从旧 Provider 导到新 Provider	7-30 旧 Provider 关闭,Gateway 不会自动迁移	查原文第十二节 Key 与凭据迁移 + 第十五节退出预案	改写为"7-30 前 100% 切离 + Key 轮换 + 数据导出 + 残留扫描"
把 Embedding 和 Chat 混在同一 Gateway 路由	Embedding 维度/归一化/Batch 上限不同	查原文第七节 + 第十九节限制	改写为"Embedding 和 Chat 走不同 Capability Registry / Probe / Provider,Embedding 迁移可能重建索引"
假设"用一个 SDK 跑通所有 Provider"	不同 Provider 的 SDK / 鉴权 / 路由不同	查原文第四节 AI Access Layer 架构 + 第六节 OpenAI-compatible 范围	改写为"统一内部契约 + Provider 适配层,而非用一个 SDK 跑通所有 Provider"
假设迁移完成 = 项目结束	平台退出需要长期预案	查原文第十五节退出预案 13 项	改写为"迁移完成 = 退出预案执行完成(资产清单/Owner/Alias/Registry/第二 Provider/Probe/质量/Shadow/Flag/Key 轮换/数据导出/最长迁移/退出触发器/演练频率)"