https://codexer.com/tags/openclaw/Recent content in OpenClaw on CodexerHugozh-cnSun, 24 May 2026 09:00:00 +0800https://codexer.com/posts/2026-05-24-codex-as-agent-runtime/Sun, 24 May 2026 09:00:00 +0800https://codexer.com/posts/2026-05-24-codex-as-agent-runtime/<h2 id="你在造轮子还是在造车">你在造轮子，还是在造车？</h2> <p>假设你要做一个 AI Agent 平台。用户可以通过 Telegram、Discord、Slack 跟你的 Agent 对话，它能记住上下文，能定时执行任务，能搜索网页，能操作浏览器。</p> <p>听起来很酷，对吧？但当你真正动手写代码的时候，会发现自己面对一个尴尬的问题：模型的「思考循环」到底该由谁来管？</p> <p>是你自己写一套推理引擎，把模型的输出解析出来，判断它要不要调用工具，再把工具结果塞回去让它继续想？还是让模型背后的基础设施来处理这些事？</p> <p>这个问题听起来技术性很强，但它决定了你的 Agent 平台到底能走多远。</p> <p>OpenClaw 最近给出了自己的答案。</p> <h2 id="openclaw-是什么">OpenClaw 是什么？</h2> <p>OpenClaw 是一个开源的 AI Agent 平台，它的核心卖点是「多渠道」。你可以在 Telegram、Discord、Slack、WhatsApp、Matrix、网页聊天等任意渠道部署同一个 Agent，它共享记忆、人格、工具权限和定时任务。</p> <p>这跟市面上那些只能在网页上对话的 AI 助手完全不同。OpenClaw 的 Agent 是一个真正「活」在你日常通讯工具里的存在。</p> <p>但 OpenClaw 有一个老问题：它之前是自己驱动模型循环的。</p> <h2 id="自己管模型循环有什么问题">自己管模型循环，有什么问题？</h2> <p>所谓「模型循环」，就是 Agent 从接收用户消息开始，到返回最终回复之间发生的那一整套流程：</p> <ol> <li>把用户消息和上下文发给模型</li> <li>模型决定要调用某个工具（比如搜索网页）</li> <li>执行工具，把结果返回给模型</li> <li>模型继续推理，可能还要调用更多工具</li> <li>最终生成回复</li> </ol> <p>这个循环看起来简单，但实际实现起来非常复杂。你需要处理线程状态管理、上下文压缩、工具调度、代码执行环境、长对话的连贯性，等等。</p> <p>OpenAI 在 Codex 的 app-server 里已经把这些问题都解决了。而且他们是针对自家模型的特性专门优化过的。</p> <p>当 OpenClaw 自己管模型循环的时候，相当于在 Codex 已经修好的高速公路旁边，又修了一条坑坑洼洼的土路。模型在两条路上都能跑，但体验天差地别。</p> <h2 id="一个大胆的架构决策">一个大胆的架构决策</h2> <p>OpenClaw 团队做了一个很多人可能觉得「疯了」的决定：<strong>把模型循环的控制权交给 Codex</strong>。</p> <p>具体来说，他们重新画了一条边界线：</p> <p><strong>Codex 负责的部分：</strong> OpenAI 模型的推理循环、原生线程状态管理、工具调用延续、上下文压缩、代码执行模式、动态工具搜索。</p> <p><strong>OpenClaw 负责的部分：</strong> 多渠道接入、Agent 人格配置、记忆系统、会话管理、定时任务、媒体处理、浏览器控制、网关、以及 OpenClaw 自己的工具集。</p>