要点
- OpenAI 区分直连 API（1P）与云厂商托管的 OpenAI 模型（3P），并把计划路由与应急故障转移分开。
- 只有自包含、可安全重复的推理步骤才应自动转移；Agents API 会话与不确定的工具动作需要对账，而非盲目重放。
- Private Link、数据驻留、功能对等，以及 401/403/拒答/配额等错误类，是阻断条件，不是换提供方的理由。
OpenAI 开发者博客发了一篇相当冷静的运维笔记：当同一模型族既能直连（1P），也能经 Bedrock、Azure OpenAI 等云提供方访问（3P）时，该如何设计故障转移。贯穿例子是支付流程里的只读欺诈评估——典型的「AI 在关键路径上」问题，最容易催生「要多云冗余」的行政冲动，以及不安全的重试实现。
真正贡献不是新 API，而是一条边界：多提供方支持可以是平台能力；自动故障转移必须仍是工作流决策。二者混淆，就会得到重复副作用、驻留违约，或被包装成韧性的静默功能降级。
[1]OpenAI 的用词有益地迂腐。计划路由——分流、卸载——需要自己的容量与质量测试。提供方故障转移指主路径无法服务时，经另一已批准提供方重试请求。它只在请求可安全重复、且备路径满足工作流要求时才有帮助。
欺诈评估例子在「结果尚未被使用且截止时间仍够」的超时场景下可能合格。进行中的 Agents API 会话则否：换提供方并不能恢复对话状态、已保存工作或对先前动作对账。仅此一点，就让一大类「智能体」负载不适合网关层的天真故障转移。
[1]这是准则而非基准，证据在于程序精确性。OpenAI 列出可考虑转移的条件（瞬时故障、可能突破截止期的持续限流）与绝不可自动转移的条件（畸形请求、401/403、安全拒答、配额/额度耗尽、未分类错误、部分输出、不确定的工具动作）。它要求应用、SDK 与网关共用一个重试控制器；有界预算；尊重 Retry-After；以及渐进回切。
私网连通性被同等强调。OpenAI Private Link 目前走 Azure Private Endpoint；AWS/GCP 负载若要私网访问 1P，需要客户自管到 Azure 的通路。3P 则用各云原生私网端点。在公网 HTTPS「能通」的转移，对受监管客户可能根本不被允许。功能缺口同样关键：若 1P 的 web search 没有经过验证的 3P 对等实现，静默跳过搜索不是故障转移——那是另一个产品。
[1]文章无法完全解决、也基本承认的是所有权。它勾勒分工：平台团队拥有路由器就绪、目的地控制与急停；应用负责人定义哪些操作可转移、质量目标与防重复动作。许多企业里这些角色塌缩成同一支过劳团队，于是「临时」自动转移变成永久混乱。
也缺少独立事故数字：没有公开数据说明 1P↔3P 转移曾多少次挽救支付 SLA，又多少次造成重复执行。用 Codex 提示词实现默认关闭的网关策略很实用，但把验证负担交给客户自己的 harness——正确，且昂贵。
[1]对建设者而言，未来半年的含义偏文化：两提供方一个开关的可靠性剧场，会继续同时输掉审计与生产。更耐久的模式是：枚举自包含只读步骤；用同一评测 harness 证明备路径对等；在容量、驻留与错误映射测完前保持转移关闭；把智能体会话当作重启问题，而非重试问题。
厂商会继续售卖「多云 AI」。这篇笔记是 OpenAI 小心地在说：难点不是第二个端点，而是搞清楚哪些请求被允许移动。
[1]值得观察的是：主流网关是否默认内置这些拒绝类——尤其阻止对部分工具结果的重放——以及受监管客户是否公开自己的故障转移矩阵。若这些产物仍停留在口口相传，多提供方就仍是幻灯片，而不是恢复预案。
[1]