你在造轮子，还是在造车？#

假设你要做一个 AI Agent 平台。用户可以通过 Telegram、Discord、Slack 跟你的 Agent 对话，它能记住上下文，能定时执行任务，能搜索网页，能操作浏览器。

听起来很酷，对吧？但当你真正动手写代码的时候，会发现自己面对一个尴尬的问题：模型的「思考循环」到底该由谁来管？

是你自己写一套推理引擎，把模型的输出解析出来，判断它要不要调用工具，再把工具结果塞回去让它继续想？还是让模型背后的基础设施来处理这些事？

这个问题听起来技术性很强，但它决定了你的 Agent 平台到底能走多远。

OpenClaw 最近给出了自己的答案。

OpenClaw 是什么？#

OpenClaw 是一个开源的 AI Agent 平台，它的核心卖点是「多渠道」。你可以在 Telegram、Discord、Slack、WhatsApp、Matrix、网页聊天等任意渠道部署同一个 Agent，它共享记忆、人格、工具权限和定时任务。

这跟市面上那些只能在网页上对话的 AI 助手完全不同。OpenClaw 的 Agent 是一个真正「活」在你日常通讯工具里的存在。

但 OpenClaw 有一个老问题：它之前是自己驱动模型循环的。

自己管模型循环，有什么问题？#

所谓「模型循环」，就是 Agent 从接收用户消息开始，到返回最终回复之间发生的那一整套流程：

  1. 把用户消息和上下文发给模型
  2. 模型决定要调用某个工具（比如搜索网页）
  3. 执行工具，把结果返回给模型
  4. 模型继续推理，可能还要调用更多工具
  5. 最终生成回复

这个循环看起来简单，但实际实现起来非常复杂。你需要处理线程状态管理、上下文压缩、工具调度、代码执行环境、长对话的连贯性，等等。

OpenAI 在 Codex 的 app-server 里已经把这些问题都解决了。而且他们是针对自家模型的特性专门优化过的。

当 OpenClaw 自己管模型循环的时候，相当于在 Codex 已经修好的高速公路旁边，又修了一条坑坑洼洼的土路。模型在两条路上都能跑，但体验天差地别。

一个大胆的架构决策#

OpenClaw 团队做了一个很多人可能觉得「疯了」的决定：把模型循环的控制权交给 Codex。

具体来说，他们重新画了一条边界线：

Codex 负责的部分： OpenAI 模型的推理循环、原生线程状态管理、工具调用延续、上下文压缩、代码执行模式、动态工具搜索。

OpenClaw 负责的部分： 多渠道接入、Agent 人格配置、记忆系统、会话管理、定时任务、媒体处理、浏览器控制、网关、以及 OpenClaw 自己的工具集。

这个分工看起来很简单，但效果立竿见影。

为什么要这样分？#

原因其实很朴素：让每一层做它最擅长的事。

Codex 的 app-server 是 OpenAI 专门为 Agent 场景打造的运行时。它知道怎么高效地管理模型的推理状态，知道怎么在长对话中保持连贯性，知道怎么处理工具调用的中断和恢复。这些是底层能力，OpenClaw 自己重写一遍既费时又费力，还不一定写得好。

OpenClaw 的价值在上层：它知道你的 Agent 在哪些渠道活动，知道怎么管理记忆和人格，知道怎么调度定时任务，知道怎么处理媒体消息。这些是产品层面的能力，Codex 不会也不应该管这些。

当边界画对了，很多之前让人头疼的问题自然消失了。

动态工具加载：解决「提示词膨胀」#

这次架构改造中最让人眼前一亮的特性，是动态工具加载。

做过 Agent 开发的人都知道一个痛点：你的 Agent 有越多工具，初始提示词就越长。每个工具的 schema（参数定义、功能描述）都要塞进上下文里，模型每次推理都要「看」一遍所有工具的定义。

OpenClaw 的 Agent 可能有几十个工具：消息发送、会话管理、媒体处理、定时任务、浏览器控制、网关管理、网页搜索、MCP 服务器、各种插件工具，以及不同渠道特有的操作。如果把所有工具的 schema 都塞进初始提示词，不仅浪费 token，还会让模型更容易选错工具。

Codex 提供了一个优雅的解决方案：可搜索的动态工具。OpenClaw 把自己的工具能力注册为动态工具，模型在需要的时候可以主动搜索、按需加载工具的 schema，而不是一次性全部塞进去。

这意味着初始上下文更小，模型的选择更精准，推理速度也更快。

而且这个思路是双向的。OpenClaw 团队正在把从 Codex 学到的「动态工具」模式反哺到自己的默认 harness 中，让非 OpenAI 的模型也能受益。

你的 ChatGPT 订阅，现在能驱动 Agent 了#

还有一个很实际的好处：不用重复付费。

如果你已经有 ChatGPT Plus 或者 Pro 的订阅，你可以直接用这个订阅来驱动 OpenClaw 的 Agent。不需要额外买 API key，不需要单独计费。

每个 OpenClaw 的 Agent 都有自己独立的 Codex 运行环境，包括独立的线程状态、独立的账户绑定、独立的插件配置。你的个人 Codex CLI 配置不会被 Agent 偷偷导入，Agent 的状态也不会泄露回你的个人环境。

这种隔离设计很关键。当 Agent 越来越自主，越来越「有记忆」的时候，你需要确保它不会意外访问到不该访问的东西。

安全边界：放手但不放纵#

自主 Agent 需要有用的默认行为，但也需要可理解的安全边界。

Codex 的 harness 支持两种模式：自由执行模式和审批模式。在自由执行模式下，Agent 可以直接执行操作；在审批模式下，敏感操作需要人工确认。

OpenClaw 保持了「默认自由执行」的实用主义立场，同时允许运维人员按需切换到审批模式。在审批模式下，Codex 的审批请求可以通过 Codex 自己的审查流程处理，包括自动审查。

这样，模型可以使用 Codex 原生的安全机制，同时 OpenClaw 也不会放弃自己的策略层。两层安全，各司其职。

这对整个 Agent 生态意味着什么？#

OpenClaw 的这个选择，其实反映了一个更大的趋势：Agent 基础设施正在分层。

就像 Web 开发最终分出了浏览器（运行时）、框架（React/Vue）、和应用（你的网站）一样，Agent 生态也在走向类似的分层：

  • 运行时层：Codex app-server、Claude 的 Agent 运行时。负责模型推理循环、工具调度、状态管理。
  • 平台层：OpenClaw、AutoGPT、CrewAI。负责多渠道接入、记忆、人格、任务编排。
  • 应用层：你基于这些平台搭建的具体 Agent。

当运行时层足够强大的时候，平台层就不需要重复造底层的轮子了。这跟当年 Node.js 的出现让前端开发者也能写后端是一个道理：当运行时统一了，上层的创新会更快。

反向赋能：好想法会流动#

值得注意的是，OpenClaw 和 Codex 的关系不是单向的「依赖」。

OpenClaw 团队明确表示，从 Codex 整合中学到的经验正在回流到 OpenClaw 自己的默认 harness 中。比如动态工具加载的模式、更清晰的工具边界、结构化的静默输出、更好的提示词作用域管理。

这些改进会让所有模型受益，不只是 OpenAI 的。Anthropic、Google、本地模型、DeepSeek、Kimi，最终都会获得更好的 Agent 运行体验。

这是一个健康的生态循环：好的设计模式从专用运行时流向通用平台，再从通用平台惠及所有模型。

写在最后#

OpenClaw 的这个架构决策，表面上看只是「换了个引擎」，但本质上它回答了一个更深层的问题：在 AI Agent 的世界里，什么是基础设施，什么是产品？

模型的推理循环是基础设施。它应该由最懂模型的人来维护，而不是每个 Agent 平台都自己重写一遍。

Agent 的人格、记忆、渠道接入是产品。这是每个平台的核心差异化所在，也是用户选择一个平台而不是另一个的理由。

当这条边界画清楚了，整个生态才能健康地发展。Codex 的 app-server 正在成为这条边界的标准实现之一，而这只是开始。

随着更多 Agent 平台做出类似的选择，我们可能会看到一个有趣的现象：AI Agent 的「运行时战争」，最终会像浏览器战争、容器运行时战争一样，走向少数几个标准的收敛。

对于开发者来说，这意味着选平台的时候，除了看功能列表，还要看它的底层运行时是什么。因为运行时决定了上限。

参考来源：OpenClaw Blog, “OpenAI Models in OpenClaw, Done Right”, Nik Pash, 2026-05-14 原文链接：https://openclaw.ai/blog/openai-models-in-openclaw-done-right