8.3
深览指数
科技人人都是产品经理·Talen··AI 生成
折腾把 Claude 塞进 Codex 后，我劝大家别再迷信“接口兼容”了
作者亲手将Claude接入OpenAI Codex，在解决了接口404、有状态/无状态冲突、模型名伪装报错等一系列工程坑后，却发现同一个模型在Codex壳子里的表现远差于Claude Code。通过抓包对比请求，揭示了“模型与壳子联合设计”（Model-Harness Co-Design）机制：大厂原生工具在后训练阶段将特定工具语法和报错反馈格式训进模型权重，形成只有自家模型听得懂的“黑话”，外模型接入时通信虽通但干活灵巧度大降。文章进而对比DeepSeek主动对齐Claude Code题库的成功策略，并指出设计Agent系统时，不能给模型和壳子简单赋值为“1”——厚壳子托底弱模型、薄壳子释放强模型，工程层应随模型迭代定期“拆拐杖”。适合正在设计或维护企业级Agent/SDK的架构师、AI产品经理阅读。原文 ↗
核心观点
- ▍接口兼容只是通信格式层面的翻译，无法弥合“模型与壳子联合设计”造成的深层隔阂：原生工具在后训练阶段把自家工具语法和报错反馈写入了模型权重，外模型接入后即使API调通，干活灵巧度也会大打折扣。
- ▍在AI产品设计中，模型和壳子不是各自等于“1”的简单相加；厚壳子能托举弱模型到可用水准，薄壳子充分释放强模型潜力，工程层应随模型水位定期去做减法（拆掉替弱模型补短板而加的硬编码步骤）。
- 01Codex已移除旧的chat模式，写死了只认/v1/responses协议，与大多数模型/中转站支持的/v1/chat/completions不兼容，直接报404。
- 02Codex的/v1/responses默认有状态，第二轮对话只传previous_response_id；但Claude接口无状态，需在config.toml加disable_response_storage=true强制发完整上下文才能跑通多轮。
- 03在Codex中填OpenAI自家推理模型名(如o3)会触发客户端自动注入推理控制字段和专属工具类型，透传给Claude后报400；必须填非OpenAI模型名让Codex退回基础标准工具模式。
- 04原生Codex声明改代码工具只用tools=[{“type”: “apply_patch”}]，GPT在后训练RL沙箱里已练熟*** Begin Patch … *** Update File语法，直接输出纯文本补丁，绕开了JSON转义导致的解析失败。
- 05DeepSeek在官方服务端上线了/anthropic兼容端点，用户无需第三方中转站；在后训练RL阶段用对齐SWE-bench和Claude Code习惯的合成代码沙箱做强化学习，包括保留工具执行结果后的完整思考链。
- 06几乎没有第三方模型会专门针对Codex私有的apply_patch补丁语法做强化学习，因此在Codex壳子中水土不服。
反方 / 局限
- — 作者承认上述分析主要基于Claude Code和Codex两个编程Agent的对比；对于其他类型(如对话、RAG)的AI产品，模型与壳子的交互机制可能存在不同范式。
- — 文章未深入讨论：如果第三方中转站持续跟进Codex的新协议并做针对性映射/状态管理，能否缩小学术与实践上的体验差距？
OpenAI CodexClaude CodeClaudeDeepSeekSWE-bench/v1/chat/completions/v1/responsesModel-Harness Co-Design
12 分钟 · 3 卡片 · 6 资料
读原文 →