最近收到不少用户反馈，大家对 OpenClaw 各种模型的实际体验，形成了一个比较一致的排行：
Codex Pro（订阅账号） > Business Team > 中转 > 除 Opus 4.6 之外的其他模型
这个排行让我很好奇——为什么同样是 OpenClaw，不同的接入方式差距这么大？
作为一名写了十多年代码的老程序员，遇到”知其然不知其所以然”的事情就睡不着。今天下午特意把 OpenClaw 2026 年 3 月 7 日的源代码拉下来，一行一行翻了个底朝天。下面把我找到的根本原因，用尽量通俗的语言分享给大家。
一、先说结论：Codex 走的是”VIP 专属通道”
你可以把 OpenClaw 连接 AI 模型的方式，想象成去一个大型游乐园：
- Codex Pro：你有年卡 + 人脸识别，走 VIP 专属入口，直达游乐设施
- 普通 API Key（中转）：你拿的是通用门票，和所有人一起排队过安检
- 虚拟 Key：你拿的其实不是门票，而是长得像门票的传单
我翻源码后发现，这个比喻并不夸张。OpenClaw 里的 Codex 和普通模型，走的根本不是同一扇门，甚至不是同一栋楼。
| 接入方式 | 实际走的门 | 需要的”证件” | 用户体感 |
|---|---|---|---|
| Codex Pro | ChatGPT 专属后端 chatgpt.com |
ChatGPT 账号 + 身份证明（JWT） | 🟢 最稳最快 |
| Business Team | 同上，但团队配额 | 团队 ChatGPT 账号 | 🟢 稳，但有额度限制 |
| 普通中转 | 公共 API api.openai.com |
API 钥匙（sk-…） | 🟡 能用，但体验打折 |
| 虚拟 Key | 试图走 ChatGPT 专属门 | 格式不对的钥匙 | 🔴 大概率进不去 |
二、两扇门到底有什么不同？
翻源码后我发现，OpenClaw 对 Codex 和普通 OpenAI 模型，在底层实现上是完全分开的两套系统。
🚪 普通 OpenAI 模型的门
- 地址：
api.openai.com（就像一个面向所有开发者的公共商场入口） - 钥匙：你在 OpenAI 官网申请的 API Key，长得像
sk-proj-xxxxxxxx... - 验证方式：拿着钥匙（Key）刷一下就行，不管你是谁
🚪 Codex 的 VIP 门
- 地址：
chatgpt.com/backend-api（ChatGPT 自己家的后门，不对外公开） - 钥匙：不是普通 Key，而是一张电子身份证（JWT Token）——你用 ChatGPT 账号登录后，系统发给你的
- 验证方式：不但要刷身份证，还要从身份证里读出你的 ChatGPT 账户 ID，确认你是谁、你有没有 Codex 的使用权
打个更生活化的比方：
普通 API Key 就像一把钥匙——谁拿了都能开门，丢了别人也能用。
Codex 的 JWT Token 就像一张带照片的银行卡——不但要刷卡，还要核身份。卡上写着你是谁、属于哪个账户、有什么权限。
三、虚拟 Key 为什么走不通？
搞清楚了”两扇门”的区别，虚拟 Key 失败的原因就很好理解了。
我在源码里找到了这段关键代码（用大白话翻译一下）：
Codex 每次发请求前，都会把你的”身份证”（Token）拆开来检查：
- ✅ 先看格式——是不是由三段内容用点号拼起来的（JWT 格式）
- ✅ 再读中间那段——解码出你的个人信息
- ✅ 最后找一个特定字段——你的 ChatGPT 账户 ID
三步有任何一步不通过，直接报错。
虚拟 Key 长什么样？sk-xxxxxxxx——一串没有结构的字符。用点号一拆？拆不成三段。第一步就挂了。
就算有人精心伪造了一个三段式的假 Token？第三步也过不了——里面没有真实的 ChatGPT 账户信息。
所以这不是"钥匙型号不对"的问题，而是"你拿着一把钥匙去刷人脸识别"——根本不是同一种认证方式。
四、为什么 Codex Pro 比中转体验好？
除了”能不能进门”之外，进门之后的体验也不一样。我在源码里还发现了几个有意思的差异：
| 对比项 | Codex 专属通道 | 普通 API 通道 |
|---|---|---|
| 数据存储 | 不存储你的对话（store=false） |
会存储（store=true） |
| 传输方式 | 默认用 WebSocket（双向实时通信） | 默认用 HTTP SSE（单向推送） |
| 计费方式 | 走 ChatGPT 订阅额度 | 走 API 付费额度 |
| 连接效率 | 支持连接复用，省去重复握手 | 每次请求重新建立连接 |
简单说：Codex 走的通道，天生就是为”连续对话、工具调用、多步任务”这类 Agent 场景优化的。 而普通 API 通道更像是一个通用的”问一句答一句”的接口。
这就像高铁和普通列车：两者都能到达目的地，但高铁的轨道、车型、调度系统都是专门设计的，跑起来自然更快更稳。
五、正确的打开方式
搞明白了原理，配置就很简单了：
✅ 第一步：准备一个真实的 ChatGPT 账号
- 需要有 Codex 使用权限（Pro 或 Business Team 都行）
- 这是唯一的硬性要求——没有真实账号，后面都白搭
✅ 第二步：在 OpenClaw 里选择内建的 Codex 路径
- 选择
openai-codex作为 provider，而不是普通的openai - 不需要手动填写 API 地址、自定义请求头——OpenClaw 已经帮你配好了
✅ 第三步：用浏览器完成 OAuth 登录
- OpenClaw 会弹出 ChatGPT 的登录页面
- 登录成功后，系统自动获取你的”电子身份证”（JWT Token）
- 之后所有请求都会带上你的真实身份，畅通无阻
一句话：用真实账号 + 内建路径 = 最佳体验。不需要折腾中转、不需要虚拟 Key、不需要手动配置。
写在最后
翻了一下午源码，最大的收获不是记住了几个技术细节，而是看清了一个规律：
在 AI Agent 时代，”走正路”往往比”抄近路”更快。
很多朋友想用虚拟 Key、中转代理省钱，心情完全可以理解。但从源码层面看，Codex 和普通 API 从地址、认证、传输到计费都是两套独立的系统。强行用一套方案去套另一套，效果打折是必然的。
用户反馈的排行 Codex Pro > Business Team > 中转 > 其他，背后的技术原因就是这么朴素——越接近原生的路径，摩擦越少，体验越好。
正道未必最省钱，但往往最省时间。用 OpenClaw，优先走内建路径、用真实账号，这条路反而最短。
相关阅读
OpenClaw 实战系列
OPC 时代，你必须学会使用 OpenClaw：我的四个数字员工