OpenAI Codex的新变化：支持自定义模型了，但别指望轻松接入哦！
在6月17日，X上的OpenAI Codex团队负责人Tibo（@thsottiaux）发了一条推文，告诉大家Codex App、CLI和SDK现在可以接入任何开源模型，不再局限于OpenAI自家的模型。他还贴出了官方配置文档的链接，具体说明了OSS模式和本地提供者的相关信息。看到这条消息，我的第一反应是有点惊讶，因为OpenAI一直给人一种相对封闭的印象，这次突然放开自定义模型，确实让人眼前一亮。
其实，Codex可不是个普通的工具，它更像是一个完整的工作平台，能处理文件的读取、写入，调用shell，抓取网页，执行命令，甚至还能根据工具的反馈继续推理，最终输出结果。换句话说，在Codex中，模型不仅要会“说话”，更要能实际“干活”。
（图源：X）
以前很多人对OpenAI的封闭性有意见，其实不仅仅是因为模型不开源，更主要是它的工具、模型和工作流程都被封闭在自己的生态系统里。你可以使用，但拆开重组就比较困难。尤其是像Codex这样的Agent工具，它本质上是模型能力、工具调用、上下文管理、权限控制和本地环境的结合体。也就是说，模型越强大，工作台越完整，用户就越难以跳出这个生态圈。如今OpenAI为Codex开设了custom model provider的入口，从产品角度来看，至少不再把Codex死死绑定在自家模型上。
不过，你以为OpenAI真的就这么放开了吗？从雷科技（ID：leitech）的实测来看，事情并没有那么简单。
填个Key就想用第三方模型？可没那么容易。
最容易被误解的其实就是“Codex支持第三方模型”这句话。很多人一看就觉得，既然DeepSeek、Qwen、Kimi这些模型都提供API，有些甚至自称兼容OpenAI API，那我是不是只需把接口地址和API Key填到Codex里，就能直接用呢？我们最开始也这样尝试。Codex的官方高级配置文档确实提到可以定义自定义模型供应商，简单说就是一个provider可以指定Codex如何连接模型，包括接口地址、协议类型、鉴权方式和附加请求信息。你可以在配置文件里添加一个模型供应商，然后让Codex指向它。
然而，当我们首次尝试接入DeepSeek V4 Pro的API时，却遭遇了失败。
看完官方技术文档后，答案也变得明了，Codex确实开放了，但只是部分开放，是有条件的。文档中明确指出，目前自定义供应商公开支持的协议只有Responses API这一种，省略不填时也是默认使用这个协议。简单来说，Codex允许你更换模型供应商，但它目前的公开配置路径只支持Responses API这套协议，模型供应商能否接入，不仅要看它有没有API，还要看它能否提供Codex所需的Responses格式。
（图源：雷科技制图）
DeepSeek的官方API主入口是Chat Completions，可以通过OpenAI SDK调用，模型也能正常填充DeepSeek V4 Pro。对很多聊天应用、普通API调用和OpenAI SDK兼容的场景来说，这都没问题，但Codex的请求方式可不是这样。我们尝试让Codex直接连接DeepSeek，模型填入DeepSeek V4 Pro，鉴权使用DeepSeek的Key，启动后Codex实际去找的是DeepSeek并不存在的Responses接口，结果返回404。
其实是DeepSeek的OpenAI格式入口并没有提供Codex当前需要访问的Responses API端点。
同样是“兼容OpenAI”，其中也有很多讲究。Chat Completions是一套接口，Responses API则是另一套接口。普通聊天、工具调用、流式输出、推理块、函数调用结果的返回，在不同协议中结构并不完全相同。对用户来说，这些差别都隐藏在配置的后面，但对Codex这种Agent工作台来说，这些差别会直接影响任务能否正常运行。
真正的突破来自DeepSeek的另一个入口，即Anthropic API兼容端点。DeepSeek的官方文档除了提供常见的OpenAI格式入口外，还提供了Anthropic格式入口，后者更适合处理工具调用和工具返回结果这类Agent场景所需的结构，跟Codex的工作方式更契合。我们最终实现的路径，并不是让Codex直接访问DeepSeek，而是在本地加了一个轻量的“翻译器”。Codex依旧按照自己熟悉的方式发起请求，这个翻译器会将请求转换为DeepSeek能理解的格式，DeepSeek返回结果后，再翻译回Codex可以继续执行的格式。
（图源：雷科技制图）
更简单地说，目前大家期待的DeepSeek、Mimo、Kimi、智谱GLM等模型，目前都无法直接用API Key接入Codex，只能通过转接桥，和之前流行的CC Switch方案没什么区别。当然，如果非要试试“直接”的方式，阿里百炼大模型当前提供了Responses接口，价格是200元/月，确实有需要的小伙伴可以试试看。
DeepSeek驱动的Codex，体验真的好吗？
配置跑通后，我们决定用DeepSeek加Codex来做一些跟雷科技日常工作更贴合的任务，主要是看看第三方开源模型和Codex的结合效果如何。
第一个任务是全网搜索与雷科技相关的信息，包括官网介绍、文章、特色报道，比如MWC、IFA、AWE等展会的报道，最终输出一份雷科技的商务招商文档，格式为Markdown文件。这个任务表面上看似写稿，其实涉及到好几个Agent能力点。它需要先找资料，如果找不到合适的搜索工具，还得能灵活调整策略。获取网页后，要能够提取出有用的信息，信息不能只是简单堆积，还需按照招商文档的结构重新整理，最后还得把结果写成本地的Markdown文件。
（图源：雷科技制图）
刚开始尝试DeepSeek V4 Pro时，发现内置的网页搜索工具不可用，网页搜索的能力也不太顺畅，它直接选择从本地终端抓取雷科技官网的页面，包括首页、关于我们、联系我们、历史专题列表、MWC26专题、MWC26凯旋报道、AWE2026专题等。最终它生成了一份320行的Markdown文档，内容涵盖了雷科技的品牌定位、媒体矩阵、用户画像、内容栏目、核心数据、展会报道能力、视频化分发、商务合作模式、合作案例和联系方式。
AI 助手的进化之路：DeepSeek 和智谱的竞争
（图源：雷科技制图）
虽然界面看起来有点简陋，但其实用起来还是不错的。
接下来的任务更具挑战性，我们要基于之前生成的招商文档，制作一份雷科技 2026 年度招商报告的 PPT，并且要输出成 HTML 格式。这一环节主要考验模型的连贯性。如果第一步只是把网页转成 Markdown，那么第二步就是把已有的文档转化为结构化的展示。模型需要搞清楚上一个文件里的九个章节，然后把它们整理成十页的幻灯片，包括封面、雷科技的介绍、媒体矩阵、内容体系、核心数据、全球展会、视频战略、商务合作、合作案例以及联系信息。
（图源：雷科技制图）
最终，我们得到了一个大约790行的单文件 HTML，文件大小接近40KB，包含了科技感十足的深色主题，搭配蓝紫色的强调，滚动触发的动画效果，右侧的圆点导航，还有键盘的上下翻页功能，支持响应式布局和导出为 PDF。这虽然不是经过精修的设计稿，但已经是一个能打开、预览并继续修改的实用文件。从完成度来看，DeepSeek在这组轻量级任务中的表现还是不错的。它的优势在于资料整理速度快，长文档的组织能力也很强，一旦遇到工具无法使用的情况，它会尝试其他方式生成 Markdown 和 HTML 等文本文件。对于“写介绍”“整理资料”“根据文档生成展示页”这些任务，它已经能够胜任初稿的制作。
（图源：雷科技制图）
不过，说实话，它的体验还有待提升，和官方模型相比，仍显得不够成熟。Codex + GPT 5.5的所有能力都在一个生态系统里，模型、工具调用、上下文和视觉能力等都能顺畅运行。然而，DeepSeek在Codex的运行链路较长，还经过了一层转接，速度自然没法和“官方组合”相比。
因此在响应速度上，DeepSeek在简单文本和资料整理方面表现尚可，不至于慢到无法使用，但确实比官方模型要慢一些。尤其是进入Codex的这种Agent工作流后，它不是一次性给出答案，而是需要边调用工具边等待结果，同时还要继续推理。多了一层本地翻译，工具调用来回跑，速度感受自然就慢了。
在使用成本上，这次的体验很直接，我们为DeepSeek账户充了10元，完成这两个任务的同时还进行了几轮聊天和调试，最后余额剩下9.27元。也就是说，这一轮轻量测试实际上只花了7毛多。DeepSeek真的是性价比之王，如果全是这样的任务，完全可以考虑放弃每月20美元的ChatGPT Plus订阅。
这波要让智谱和DeepSeek们赢得胜利？
体验下来，对于大多数普通用户来说，Codex能否支持第三方模型，其实意义没有那么大。如果只是想要简单流畅的使用体验，开通Plus会员也还是不错的选择，毕竟它是和ChatGPT捆绑在一起的。
更值得关注的是那些开源模型。
过去，国产和开源模型想要在开发者的实际工作流中占有一席之地，得花费很多功夫去完善产品能力。发布一个模型的API只是第一步，后面还需要IDE插件、命令行工具、文件权限、工具调用、项目上下文、任务记忆、错误恢复、协作界面、审阅流程，这些都是单靠模型论文无法解决的问题。
Codex这类工具的价值在于，它先为工作台搭建好了基础架构。它负责与本地文件系统的交互，执行命令，展示工具调用，把任务拆分成多个阶段，并让模型在上下文中持续工作。第三方模型一旦能够接入，就相当于直接获得一个成熟的Agent容器，这对智谱、DeepSeek、Qwen、Kimi等都是机遇。
（图源：雷科技制图）
例如智谱，最近推出的GLM-5.2，强调其1M无损上下文和长程任务能力的提升，Coding和长程任务的评测达到了开源的SOTA，在复杂系统工程和深度调试方面表现更为稳定。最近几天，开发者圈对这个模型评价很高，很多人认为它在代码任务和长程Agent场景中的性能非常强。更有趣的是，智谱的GLM Coding Plan已经变成了一种稀缺资源，因其火爆，很多人抢不到，这其实说明国产模型的竞争已经不再只是发布一个强模型，而是围绕Coding Plan、开发工具接入、Agent工作流额度和真实工程体验展开。
（图源：智谱）
当然，智谱也不是没有自己的Agent工具。它正在打造类似Codex的图形化Agent工作台，让用户能够在其中交给模型进行代码、长程和工程任务的处理。问题在于，对于模型厂商来说，自建工作台和接入Codex这样的成熟工作台并不矛盾。自家的工具更适合展示完整能力和打磨闭环体验，而接入Codex则更像是进入一个已经被大量开发者熟悉的环境。用户本来就在Codex里写代码、运行命令、阅读项目、交付文件，如果国产模型能够出现在同一个任务流里，使用和比较的机会就会增多。
在OpenAI发布消息后，智谱的股价一路飙升，今天盘中一度上涨超过22%，股价突破2000港元大关，市值也达到了新高，创下近期新纪录，这已经说明了一些问题。
（图源：雅虎财经）
不过，OpenAI也有自己的考量，Codex的开放并不意味着它放弃了控制权。相反，工作台的标准依然由它来定义。Responses API、模型配置、官方推荐模型、工具调用协议、权限机制等关键环节，仍然围绕OpenAI的体系展开。OpenAI可能想要的局面，是让Codex成为更通用的Agent工作台，官方模型负责提供最强能力和最佳体验，而第三方模型则负责扩展场景、降低成本并满足更多供应商的需求。用户可以有选择，但这种选择是在OpenAI定义的工作台上进行的，这显然比单纯的封闭更聪明。
总的来说，Codex的开放显然是一种双赢的局面，对OpenAI来说，它能够推动Codex朝着平台化发展，有可能在不久的将来成为一家独大的AI工作台；而对国产和开源模型而言，它们终于有机会进入一个成熟的工作台，而不再只是停留在自己的Agent里。但目前来说，OpenAI的开放程度仍然不够，远远不够。
