OpenClaw 接入 Codex,我终于看懂了它真正的架构

最近，OpenClaw 发布了对 Codex Runtime 的支持。

很多人第一反应都是：

“是不是 OpenClaw 把 GPT 换成 Codex 了？”

看完官方文档之后，我发现完全不是这么回事。

事实上，OpenClaw 并不是简单地调用 Codex API，而是把 Codex 当成了整个 Agent Runtime（运行时）。

自己则退到了更高的一层，专门负责插件、工具、消息、安全、会话管理等平台能力。

换句话说：

Codex 是 Agent 的”大脑”，OpenClaw 更像 Agent 的”操作系统”。

这也是整个设计里最值得研究的地方。

OpenClaw 没有接管 Codex，而是尊重 Codex。

官方文档里面有一句话，我觉得几乎可以作为全文的核心：

“Codex Mode is not OpenClaw with a different model call underneath.”

很多 Agent 框架的做法，其实都是自己维护上下文、自己决定什么时候调用 Tool、自己决定什么时候压缩 Context，最后把 Prompt 一次性发给模型。

模型只负责生成下一句话。

这种模式，本质上还是 LLM + Agent Framework。

但 Codex Runtime 并不是这样。

Codex 自己已经拥有完整的 Agent Runtime：它有自己的 Thread、自己的 Planning、自己的 Tool Loop、自己的 Context Compaction，甚至还有自己的 Permission 系统。

也就是说，Codex 本身就是一个完整的 Agent。

OpenClaw 并没有试图重新实现这些能力，而是选择了一种更聪明的方式：尊重 Codex，把这些能力全部交还给 Codex。

自己只负责平台层。

这是整个设计最大的不同。

如果一句话总结整个架构，大概就是：Codex 负责思考，OpenClaw 负责执行。

Codex 负责的部分全部是原生能力——Agent 推理、长线程管理（Thread）、Tool 调用循环、Context 压缩、Planning、Memory Continuation。

而 OpenClaw 负责的是平台层——Telegram、Discord 等渠道接入、Plugin 插件系统、Dynamic Tool、MCP 工具管理、Approval（用户审批）、多媒体能力、Session 管理、Diagnostics（诊断）、Workspace 配置。

可以理解成：

Codex 是 CPU。

OpenClaw 是整个操作系统。

两者各司其职。

这是我觉得官方设计最有意思的一点：真正的上下文，其实保存在 Codex 里。

以前很多 Agent Framework 都会维护自己的 Conversation，因为模型本身没有长期线程。

但 Codex 不一样。

Codex 自己拥有 Native Thread。

官方甚至用了一个词：Canonical Thread。

意思就是：真正可信、真正完整的聊天历史，只存在 Codex 里面。

OpenClaw 并不会复制一份重新管理。

它维护的是一份 Transcript Mirror（聊天镜像）。

很多人看到这里会问：既然 Codex 已经保存了 Thread，为什么还需要 Mirror？

原因其实很简单。

因为 OpenClaw 不只是一个 Runtime，它还是一个平台。

平台需要聊天搜索、Session 管理、聊天记录、渠道同步、模型切换、运行日志。

所以它需要维护一份自己的镜像。

但真正的 Agent 状态，仍然属于 Codex。

这个边界划分非常清晰。

很多人比较关心：既然 Agent 已经交给 Codex，那 OpenClaw 的插件是不是全部失效了？

答案恰恰相反。

官方做了一层 Runtime Adapter。

整个 Tool 调用过程大概是这样：Codex 决定调用哪个 Tool → OpenClaw 收到请求 → Plugin 开始工作 → Approval 判断是否允许 → 真正执行 Tool → 再把结果返回 Codex。

注意这里有一个非常重要的区别。

Codex 决定”调用什么”，OpenClaw 决定”怎么调用”。

因此插件还能继续运行，Hook 还能继续触发，权限还能继续检查，日志还能继续记录。

对于已有插件来说，几乎不用推倒重来。

这也是 Runtime Adapter 最大的价值。

过去很多人都会讨论 Prompt 应该怎么写、System Prompt 应该放哪里。

到了 Codex Runtime，这件事情开始变成”两层 Prompt”。

第一层属于 Codex——Base Prompt、Model Instructions、Project Docs、Agent 原生行为，这一部分 OpenClaw 不会去修改。

第二层属于 OpenClaw——Workspace Personality、MEMORY、BOOTSTRAP、Skill Catalog、Dynamic Tools、Workspace Profile。

简单来说：Codex 决定 Agent 的底层行为，OpenClaw 决定这个 Agent 属于哪个公司、拥有哪些插件、有哪些工具、有什么记忆。

这种设计其实很合理。

因为 Platform 和 Runtime 本来就是两个层次。

Codex 自己其实已经有 Permission 系统，比如删除文件、执行危险命令、访问网络都会触发 Native Permission。

而 OpenClaw 自己也有 Approval。

如果两个系统互相独立，就会出现重复确认的问题。

所以官方做了一层桥接。

用户最终看到的仍然是 OpenClaw 的审批界面，但底层其实对应的是 Codex Native Permission。

这一点用户几乎感觉不到，却保证了 Runtime 的一致性。

这是我个人最喜欢的一点：Context 压缩终于不用框架自己管了。

以前很多 Agent Framework 最大的问题就是 Context Compression——什么时候压缩、压缩哪些内容、摘要怎么生成，全部需要框架自己维护。

不仅复杂，而且不同框架效果差异很大。

到了 Codex Runtime，官方直接规定：Compaction 全部交给 Codex。

OpenClaw 不负责压缩，也不能修改压缩结果。

它最多只能请求 Codex：”该压缩了。”

至于怎么压，完全由 Runtime 自己决定。

这一点其实意味着：未来越来越多 Agent Framework 可能都会放弃自己维护 Context，而选择直接依赖模型 Runtime。

看完整份文档，我最大的感受就是：OpenClaw 已经不像传统意义上的 Agent Framework 了，它越来越像一个 Agent Operating System。

Runtime 可以换。

今天可以接 Codex，未来也可以接其他 Runtime。

但插件不会变、消息系统不会变、MCP 不会变、Workspace 不会变、渠道不会变、审批不会变、平台能力不会变。

真正变化的，只是下面那颗”大脑”。

这种设计其实很符合软件工程里的经典思想：把平台能力和智能能力彻底解耦。

智能模型不断升级，平台保持稳定，两者各自独立演进。

过去几年，我看到的大多数 AI Agent 都是围绕”模型”搭框架——模型只是一个推理引擎，Agent Framework 才是真正的核心。

而 Codex Runtime 的出现，似乎开始改变这种模式。

Planning、Thread、Tool Loop、Memory、Compaction……这些过去属于 Framework 的职责，如今正在逐步下沉到底层。

在这样的趋势下，OpenClaw 也没有选择与 Codex 重复造轮子，而是重新定义了自己的位置。

它不再试图成为另一个 Agent，而是成为 Agent 之上的平台。

未来，无论底层 Runtime 是 Codex 还是其他更强大的 Agent Runtime，OpenClaw 都可以作为统一的平台层，提供插件生态、工具管理、多渠道接入、安全审批和工作空间管理。

Runtime 越来越智能，Platform 越来越稳定，而开发者只需要关注如何构建自己的 Agent 能力。

也许，这才是下一代 AI Agent 架构真正值得关注的方向。

官网链接：

https://docs.openclaw.ai/plugins/codex-harness-runtime