Codex 开放 OSS 模式：国产模型的「App Store 时刻」来了

公众号名称：程叙架构与AI.

作者名称：AI兴观点

发布时间：2026-06-18 20:37

✅点击上方🔺公众号🔺关注我✅

一周之内，国内两个大厂接连放了大招——

月之暗面发布了 Kimi K2.7 Code，一款专为代码场景优化的模型，宣称在 SWE-bench 上刷新纪录。

智谱端出了 GLM-5.2，1M 上下文、MIT 协议开源、编程能力据说能持平 Claude Opus 4.8。

这俩放在一起，国内开发者群里一片叫好。

同时，Kimi 有自己的 Kimi Code，智谱也有 ZCode，而且做得都不错。

但问题在于：你的 Agent 做得再好，也只能服务你自己的模型。

Kimi Code 只能用 Kimi 的模型跑，ZCode 只能用 GLM 的模型跑。你用惯了某个 Agent 的交互和 workflow，想换个模型试试？对不起，Agent 是绑死的。

而昨天，OpenAI 悄悄更新了一页文档，把这件事彻底打开了。

那篇不起眼的文档

开发圈里最近有条推文火了，来自 Tibo 的账号，内容很短：

Reminder that you can use the Codex App, CLI and SDK with any open source model, not just with OpenAI models.

配了一个链接：developers.openai.com/codex/config-advanced#oss-mode-local-providers

推文目前 1000+ 点赞、70+ 转发，但在国内少有人讨论。

这就牵扯到一个重要的事：Codex——OpenAI 的编程 Agent——现在可以用任何模型了。

对，你没看错。OpenAI 自己官方的文档里，写得很清楚：

# 用 --oss 跑本地开源模型
codex --oss

# 或者指定默认的本地 provider
oss_provider = "ollama"   # 或 "lmstudio"

不只是 --oss。Codex 的「Custom model providers」配置允许你定义几乎任何兼容 OpenAI API 的模型作为 backend：

[model_providers.moonshot]
name = "Moonshot/Kimi"
base_url = "https://api.moonshot.cn/v1"
env_key = "MOONSHOT_API_KEY"

[model_providers.zhipu]
name = "Zhipu/GLM"
base_url = "https://open.bigmodel.cn/api/paas/v4"
env_key = "ZHIPU_API_KEY"

把地址换成国产模型的 API 端点，Codex 就能直接调用它们。

这是 OpenAI 开发者文档上白纸黑字写的。

Codex 是什么？为什么这件事很重要

如果你还没用过 Codex，简单说，

它是 OpenAI 推出的编程 Agent，功能上对标 Claude Code、Coder、Cursor 的 Agent 模式。

但它不一样的地方在于：Codex 不仅仅是个 AI 写代码工具，它是一个完整的 Agent 框架。

有 sandbox（沙箱隔离）
有 hooks（生命周期钩子，可以在工具调用前后做安全检查）
有 rules（自定义规则引擎）
有 MCP 支持（Model Context Protocol，可以连接外部工具）
有 subagents（子 Agent 编排）
有 project config（项目级配置文件）
还有 Obsidian 级别的记忆系统（Chronicle）

说人话：Codex 是 OpenAI 用自己全部基础设施堆出来的一个 AI 编程工作站。

以前你想用这些功能？可以。但你必须用 OpenAI 的模型。

现在不用了。

国产模型拿到了一张什么入场券

这就回到 Kimi K2.7 Code 和 GLM-5.2 了。

这俩模型最近的评测数据确实漂亮。从公开信息来看：

模型	核心亮点	编程能力
Kimi K2.7 Code	专为代码 Agent 优化，SWE-bench 高分	接近顶尖闭源模型
GLM-5.2	1M上下文，MIT协议开源	持平 Claude Opus 4.8

它们各自有 Kimi Code 和 ZCode，体验不差。但问题是：这些都是「一家一店」的模式——你的 Agent 绑死你的模型，用户的切换成本很高。

Codex 的 OSS 模式相当于开了一个「大商场」：模型厂商不需要自己从头搭店铺（Agent 框架），直接入驻就行。开发者也不用为了换模型而换工具。

这跟当年 VS Code 的插件生态有多大区别？

VS Code 搞了一个开放的扩展市场，让任何人都能写插件，结果催生了 GitHub Copilot、GitHub Codespaces 等一系列服务。VSCode 本身是免费的，但围绕它建立了一个完整的生态。

Codex 现在做的事情是一样的——它把自己的 Agent 基础设施开放给第三方模型。你不需要重新造一个 sandbox、不用自己写 hooks、不用设计 MCP 集成，直接使用。

一个大胆的推测

这件事如果推演下去，可能会发生什么？

第一，国产模型找到了第一个「海外分发渠道」。

以前国产模型出海难，不是因为技术不行，而是因为没有跟海外开发者生态对等的产品形态。你做了一款牛逼的模型，但海外开发者打开的是 ChatGPT、Claude、Cursor——不会去开你的网页对话框。

现在有了 Codex，只要你的模型兼容 OpenAI API（Kimi、GLM 都兼容），海外开发者一行配置就能切过去。等于 OpenAI 帮国产模型铺了路。

第二，模型切换成本降到零，倒逼模型厂商卷能力。

Codex 的配置方式让切换模型变得极其简单——改一个 model = "xxx" 和对应的 base_url 就够了。开发者今天用 GPT-5.5 写代码，明天想试试 Kimi K2.7 Code？一条 --config 搞定。

这对开发者是好事，对模型厂商是残酷的竞争。因为切换没有摩擦，厂商只能靠硬实力说话。

第三，Codex 可能成为「模型界的浏览器」。

现在回头看 OpenAI 的策略，就很清楚了——他们不是在卖模型，他们在卖平台。

就像当年 Google Chrome 跑你的网页不需要你买 Chrome 一样，Codex 跑你的模型——只要你兼容它的协议。OpenAI 不做 Agent 的围墙花园，他们要做 Agent 的底座。

但事情没那么简单

等等，别急着欢呼。

Codex 跑第三方模型，有一个很现实的问题：OpenAI 的工具调用（Tool Use）格式是私有的。

Codex 的 hooks、sandbox、subagents 等基础设施都是 Codex 自己的逻辑，跟模型无关——这部分没问题，Codex 自己管。

但模型本身需要支持 Responses API 规范（OpenAI 最新的 API 格式），才能顺畅使用 Codex 的全部功能。

Kimi K2.7 Code 和 GLM-5.2 都是标准的 Chat Completions API，能不能完美适配 Codex 的 Responses API 格式、能不能理解 Codex 发的 tool call 指令，这些还需要验证。

简单说：能跑起来很容易，跑得好需要磨合。

另外，Codex 本身的定价也是个门槛——Codex 的收费模式是独立于模型调用的，即使你用本地模型跑，Codex 本身也有月费。

但这些都不是根本障碍。格式兼容的问题，三个月内就会被解决。月费的问题，对于正经做开发的团队来说不是问题。

方向是对的，剩下的只是时间。

总结

OpenAI 开放 Codex 的 OSS 模式，是 AI 编程工具走向平台化的关键一步。

对于国内模型厂商来说，这可能是他们等了很久的那个机会——一个不需要自己从头搭建 Agent 框架，就能直接触达全球开发者的渠道。

Kimi K2.7 Code 的技术实力、GLM-5.2 的开源策略和上下文能力，正好在这个时间点卡在了正确的位置上。

以前是「各家的模型只能跑各家的 Agent，换模型就得换工具」。

现在是「Agent 是中立的，谁的模型好就用谁的」。

问题留给了模型厂商：你有能力接住这个机会吗？

如果觉得这篇文章有帮助，欢迎点赞、在看、转发！有问题也可以在评论区留言，我会尽量回复！

内容效果不满意？点此反馈