近日，OpenAI Codex团队负责人Tibo在社交平台X上发布一则重磅消息：Codex应用、命令行工具（CLI）及软件开发工具包（SDK）现已支持接入任意开源模型，不再局限于OpenAI自家模型。这一消息引发广泛关注，毕竟OpenAI长期被视为相对封闭的科技公司，此次开放自定义模型供应商接口，着实令人意外。
Codex并非普通工具，它是一个功能完备的工作台。模型在该工作台中，不仅能进行语言交流，更要具备实际工作能力，例如读取和写入文件、调用shell命令、抓取网页信息、执行各类命令，还能依据工具返回的结果进一步推理判断，最终输出可直接交付的成果。
此前，OpenAI饱受诟病，被指封闭。原因不仅在于其模型未开源，更关键的是其工具、模型以及工作流都被整合在自家体系内。用户虽可使用，但难以对其进行拆解和重新组合。特别是Codex这类智能体（Agent）工具，它融合了模型能力、工具调用、上下文管理、权限控制以及本地环境等多方面要素。模型能力越强，工作台功能越完善，用户就越难脱离该体系。如今，OpenAI为Codex开放自定义模型供应商入口，在产品姿态上，不再将Codex与自家模型紧密捆绑。
然而，实际情况并非表面那般简单。许多人误以为，既然DeepSeek、Qwen、Kimi等模型提供API，且部分声称兼容OpenAI API，那么只需将接口地址和API Key填入Codex，就能直接使用。但实测发现并非如此。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这类智能体工作台来说，这些差异会直接影响任务能否顺利执行。
不过，转机出现在DeepSeek的另一个入口——Anthropic API兼容端点。DeepSeek官方文档除常见的OpenAI格式入口外，还提供了Anthropic格式入口。该入口更适合承载智能体场景所需的工具调用、工具返回结果等数据结构，与Codex的工作方式更为契合。最终，通过在本机添加一层轻量级“翻译器”，成功实现Codex与DeepSeek的对接。Codex仍按自身熟悉的方式发起任务，翻译器将请求转换为DeepSeek能理解的格式，待DeepSeek返回结果后，再将其翻译成Codex可继续执行工具的形态。
目前，大家期待的DeepSeek、Mimo、Kimi、智谱GLM等模型，均无法直接使用API Key接入Codex，只能借助转接桥，这与之前流行的CC Swich方案类似。当然，若想直接接入，阿里百炼大模型目前提供Responses接口，不过价格为200元/月。
在成功实现配置后，选择让DeepSeek与Codex协作完成一些符合日常需求的任务，以此检验第三方开源模型与Codex结合是否会出现不兼容问题。第一个任务是全网搜索相关资料，结合官网介绍、文章以及特色报道，如MWC、IFA、AWE等展会报道，制作一份商务招商文档，并输出为Markdown文件。此任务看似简单，实则涉及多个智能体能力点。它需要先查找资料，若搜索工具不可用，则要能更换策略。获取网页后，要能提取有用信息，并按招商文档结构重新组织，最后将结果写入本地Markdown文件。
DeepSeek V4 Pro在尝试过程中，起初内置网页搜索工具无法使用，网页搜索能力也不顺畅，于是它转换方式，直接从本地终端抓取官网一手页面，包括首页、关于我们、联系我们、历史专题列表、MWC26专题、MWC26凯旋报道、AWE2026专题等。最终生成一份320行的Markdown文档，内容涵盖品牌定位、媒体矩阵、用户画像、内容栏目、核心数据、展会报道能力、视频化分发、商务合作模式、合作案例以及联系方式。
第二个任务更具挑战性，需读取上一步生成的招商文档，制作一份2026年度招商报告PPT，并输出为HTML格式。此任务测试的是连续任务能力。若第一步是从网页生成Markdown，那么第二步则是从已有文档生成结构化展示内容。模型需理解上一步文件中的9个章节，并将其改造成10页幻灯片，包括封面、关于、媒体矩阵、内容体系、核心数据、全球展会、视频战略、商务合作、合作案例以及联系我们。最终输出一个单文件HTML，约790行，接近40KB，包含暗色科技风主题、蓝紫强调色、滚动触发动画、右侧圆点导航、键盘上下翻页、响应式布局以及打印导出PDF支持等功能。虽非精修设计稿，但已是一个可打开、预览和继续修改的交付物。从完成度来看，DeepSeek在这组轻量任务中表现可用，其优势在于资料整理速度快，长文档组织能力不错，遇到工具不可用时会尝试绕路，生成Markdown和HTML这类文本型文件较为顺畅，对于“写一份介绍”“整理一份资料”“根据文档生成展示页”等任务，已能承担初稿生产工作。
不过，在体验上，DeepSeek与官方模型相比仍不够成熟。Codex与GPT 5.5的所有能力处于同一生态，模型、工具调用、上下文、视觉能力等均可顺利调用。但Deepseek在Codex中运行需经过较长链路，中间还需经过转接桥，速度自然不如“官配”组合。在响应速度方面，DeepSeek在简单文本和资料整理任务中虽未慢到无法使用，但确实不如官方模型迅速。尤其在Codex的智能体工作流中，它并非一次性完成回答，而是要一边调用工具，一边等待结果，一边继续推理。链路增加本地翻译环节，工具调用也需来回运行，速度体感明显变慢。
在资源消耗方面，此次实测感受直观。为DeepSeek账户充值10元，完成上述两个任务，中间还穿插几轮聊天和调试，最后余额还剩9.27元，即这一整轮轻量实测仅花费7毛多。DeepSeek堪称性价比之王，若所有任务均为此类型，确实可放弃ChatGPT Plus每月20美元的订阅费。
此次Codex开放自定义模型供应商接口，对多数普通用户而言，意义或许有限。若追求简单、流畅的体验，开通Plus会员性价比也不错，毕竟它与ChatGPT捆绑销售。但对于开源模型来说，这无疑是一个重大机遇。
过去，国产和开源模型若想融入开发者真实工作流，需自行构建众多产品层能力。发布模型API仅是第一步，后续还需开发集成开发环境（IDE）插件、命令行工具，处理文件权限、工具调用、项目上下文、任务记忆、错误恢复、协作界面、审阅流程等问题，这些并非模型论文所能解决。
Codex这类工具的价值在于，它已搭建好工作台。它负责与本地文件系统交互、执行命令、展示工具调用、将任务拆分为多轮操作，并让模型在上下文中持续工作。第三方模型一旦接入，便相当于直接获得一个成熟的智能体容器。这对智谱、DeepSeek、Qwen、Kimi等模型而言，都是难得的机会。
以智谱为例，其近期上线GLM-5.2模型，着重强调1M无损上下文、长程任务能力提升，在Coding与长程任务评测中达到开源最优水平，在复杂系统工程、深度调试中表现更为稳定。近来，开发者圈对该模型评价颇高，不少人称赞其在代码任务和长程智能体场景中的性能强劲。更有意思的是，智谱的GLM Coding Plan因过于火爆，许多人抢不到，这从侧面反映出国产模型的竞争已不再局限于发布强大模型，而是开始围绕Coding Plan、开发工具接入、智能体工作流额度以及真实工程体验展开。
当然，智谱并非没有自己的智能体工具。它也在开发类似Codex的图形化智能体工作台，用户可在其中交给模型代码任务、长程任务和工程任务。但对于模型厂商而言，自建工作台与接入Codex这类成熟工作台并不冲突。自家工具更适合展示完整能力和打磨闭环体验，接入Codex则如同进入一个已被大量开发者熟悉的工作环境。用户原本就在Codex中写代码、运行命令、阅读项目、交付文件，若国产模型能出现在同一任务流中，被使用和比较的机会将大幅增加。
在OpenAI发布相关消息后，智谱股价一路攀升，盘中一度大涨超22%，股价突破2000港元大关，市值也创下新高，这足以说明问题。不过，OpenAI也有自身考量。Codex开放自定义模型供应商接口，并不意味着OpenAI放弃控制权。相反，工作台标准仍由其定义。Responses API、模型配置、官方推荐模型、工具调用协议、权限机制等关键环节，均围绕OpenAI的体系展开。OpenAI或许希望借此让Codex成为更通用的智能体工作台，官方模型提供最强能力和最佳体验，第三方模型则负责扩展场景、降低成本、满足更多供应商需求。用户虽有选择，但选择发生在OpenAI定义的工作台内，这无疑比单纯封闭更为明智。目前来看，OpenAI的开放程度仍显不足。
