你手上有一把中转站或第三方平台的 Key，想塞进 Codex 用它替代默认模型，结果要么启动就报协议错，要么能连上但工具调用失灵、跑到一半断掉。这篇不讲原理，只给改法：配置该动哪几个位置、遇到不兼容先试哪三种绕法、实在不行按什么顺序降级，最后附一份从连不上到能跑通任务的排查顺序。
先说结论：Codex 接第三方模型失败，绝大多数不是模型不行，而是配置没对上。要么地址选错、要么模型名写错，要么能力声明吹得比上游实际支持的高。这三件事有一个不对，表现就是连不上或者跑到一半断掉。下面按「改哪几处 → 不兼容怎么绕 → 按什么顺序降级 → 怎么排查」的顺序讲，照着做就行。
有一点先提醒：第三方通道的稳定性和能力经常变，今天能用的模型名明天可能就改了。所以下文所有涉及具体数值、可用模型、延迟水平的地方，我都只给判断方法，具体数字请到站内对应页面核对当时的情况，不要拿旧结论套现在的通道。
Codex 里真正要改的只有这几个位置
配置文件看着复杂，但跟你这个任务相关的其实就两块：一块决定请求发到哪里、用什么身份，一块决定用哪个模型名、它宣称能做什么。这两块必须同时对上，只改一块的结果一般是启动就报错，或者连上了但一调用工具就失灵。
- 地址与鉴权层：确认 base url 指向的是上游真正接受请求的入口，Key 填在正确的字段里，别把中转站的 Key 塞进官方字段，也别把官方 Key 填到第三方地址上
- 模型名层：不要照抄宣传页上的名字，要用上游实际接受的那个字符串；名字写错通常报 404 而不是 401，很容易被误判成 Key 过期
- 能力声明层：上下文长度、是否支持工具调用、是否支持流式，这三项能改就改成保守值；宁可低估让任务稳一点，也别高估导致跑到中途崩
- 连通性基线：改完先发一个最小请求确认能通，再上真实任务；通道本身的延迟和成功率可以到 /tools/speed-test 先量一遍，别把通道问题算到配置头上
- 改完留痕：把每次改的地址、模型名、结果记一行，改到第三轮你就会靠这份记录找路
最容易漏的是能力声明
地址和模型名错了会立刻报错，反而好查；能力声明错了则是「能连上、也能出字、就是工具调用时炸」，症状隐蔽得多。所以第一次接新通道时，把三项能力都往低了写，跑通了再一项一项往上放，比反过来省时间。
| 配置项 | 写错的典型症状 | 先确认什么 |
|---|---|---|
| base url | 全请求失败，鉴权类报错 | 是不是 Codex 期望的那种协议路径 |
| Key 字段 | 401 类报错，换了 Key 也一样 | Key 该填的字段有没有填错位置 |
| 模型名 | 404 类报错，看着像 Key 问题 | 上游真实接受的字符串是哪个 |
| 工具调用声明 | 能出字但一调工具就断 | 上游到底支不支持这一项 |
| 流式声明 | 输出中途断掉或超时 | 上游流式是否真开着 |
| 上下文长度 | 长输入被截断或直接报错 | 上游实际能吃的上限是多少 |
协议对不上时，三种绕法按成本从低到高试
第三方通道和 Codex 期望的协议不一定一致，硬对硬大概率报错。遇到这种情况别急着重写配置，先按成本从低到高试下面三种。注意是成本递增，不是效果递增，第一种能解决就别上第二种。
- 先换入口同一个上游经常同时开两套协议的地址，先确认你选的是 Codex 期望的那一套。很多「不兼容」其实只是路径写错，把地址换成对应的那套再试一次，具体路径差异可以对照 /base-url 的说明判断。
- 再加本地转发换入口还不行，就在中间加一层转发，把请求转成上游认识的格式。好处是不用改上游也不用改 Codex，代价是多一个进程要维护，而且以后排错得先怀疑这层是不是挂了。
- 最后砍能力工具调用和严格的结构化输出是最常缺的两项。缺了就把它降级成「让模型只输出文本，由本地脚本去解析」，稳定性通常立刻回来，代价是本地要写点解析逻辑。
跑不通时的降级顺序
降级不是「换个更便宜的模型」那么随意，而是按能力逐项往下砍，每砍一项就重跑同一个任务看能不能过。这样你才能知道到底是哪一项能力拖垮了整条链路，而不是笼统地觉得「这通道不行」。
- 第一刀砍工具调用：改成纯文本交互，看任务能不能靠本地脚本缝合完成
- 第二刀砍流式：关掉流式输出，用一次性返回，很多中途断掉的问题会消失
- 第三刀砍上下文长度：把输入压短，长文档先做本地切分再分段送进去
- 剩下单轮纯文本问答：如果这样还失败，问题就不在能力层，而在鉴权或地址层，排查方向完全不同
- 设退出条件：同一类失败连续出现几次就别继续降了，换通道或回默认模型，别在一个不稳的通道上反复重试烧额度
什么情况下不适用：如果你的任务本身强依赖多轮状态或工具调用，砍掉这些能力后就算跑通也没意义，这种情况应该直接换通道，而不是硬降级。判断标准很简单：砍完这一项，任务目标还能不能达成，不能就别浪费时间。
从连不上到能跑通：排查顺序
排查最忌讳一上来就动配置。按下面这个顺序走，能少改很多轮。每一层确认过了再往下一层走，不要跳步。
- 确认真连通用一个最简单的请求打同一个地址，先分清是 Codex 侧的配置问题，还是通道本身就不通。
- 判断错误分类看报错属于鉴权类、路径类、限流类还是上游故障类。不同类的含义和该修哪边都不一样，可以到 /api-errors 看当时的分档说明再动手。
- 单独验能力工具调用、流式、长输入分别测一次。别指望一个真实任务能同时把三种缺失都暴露出来，那样你只会看到一句失败。
- 逐项改并留记录每改一次地址、模型名或能力声明，就记一行改了什么、结果如何。改到第三轮以后，这份表是你唯一的依据。
- 回到稳定性数据跑通了不等于能长期用。通道的成功率和延迟趋势可以去 /sites 看当时的情况，把不稳的通道换掉比反复重试划算。
还有一件出在配置阶段、代价最小的事：安全检查。Key 是不是填进了不该填的地方、数据要经过哪几层转发、有没有敏感内容会被中转方看到。这些问题在接之前想清楚，比事后补救容易得多。
下一步先把你要接的通道的地址、模型名和当前成功率核对一遍，再动手改配置，比改完试错省很多轮。→常见问题
Codex 能接任意第三方模型吗？
能不能接取决于两件事：上游是否提供 Codex 使用的那套协议，以及模型是否声明支持工具调用和流式。协议对得上、能力声明完整的基本能跑；只提供另一种协议、或者模型不支持工具调用的，就得靠本地转发或砍掉对应能力来绕，功能会打折，不是所有模型都能完整替代。
改完配置模型还是报错，先怀疑什么？
先怀疑模型名字符串和地址路径，而不是 Key。名字写错常见表现是 404，路径写错也类似，而 Key 无效通常是 401，两者混淆会白折腾很久。把地址、模型名、错误码三个一起记下来对照一次，通常几分钟就能定位是哪一层的问题。
降级到哪一步该放弃？
看你的任务是否强依赖被砍掉的能力。如果砍掉工具调用后模型只能输出文本、还得你手工搬运，那已经失去用 Codex 的意义，这时候应该换上游而不是继续降。给自己定个门槛：连续两次同类失败就停手，别在同一通道上反复试。
