文章总结： 作者对比了OpenClaw和Codex两款AI编程工具的使用体验，指出OpenClaw的优势在于多通道接入和随时可用性，但存在Token消耗过快的隐患；Codex则更适合本地开发和长任务处理，Token利用效率更高。最终建议将Codex作为主力开发工具，OpenClaw作为碎片化场景的补充入口。 综合评分： 78 文章分类： AI安全,产品介绍,实战经验

---

我在用了几天 OpenClaw 后，还是选择了 Codex

原创

ckcsec ckcsec

CKCsec安全研究院

2026年3月11日 00:00 湖北

OpenClaw 很香。这一点我先承认。

它最厉害的地方，不是模型有多强，也不是界面有多酷，而是它真的把 AI 变成了一种“随时可用”的东西。 你不用一直守着 IDE，不用非得坐在电脑前，Telegram、Discord、手机消息通道都能直接叫它出来干活。OpenClaw 官方对自己的定位也很明确：它是一个自托管的 AI Gateway，把消息应用连接到 AI coding agents。

刚上手的时候，我的感受只有一个：

太方便了。

但用了几天之后，我最后还是把主力放回了 Codex。

原因也很直接：

OpenClaw 真的方便，但也真的太烧 Token 了。

---

一、OpenClaw 最让人上头的，不是能力，而是“入口”

以前我们用 AI，动作通常是这样的：

• 打开网页
• 打开 IDE
• 打开某个插件
• 进入一个固定工作台
• 然后开始提问

但 OpenClaw 不是。

它做的事情，是把 AI 直接塞进你原本就在用的沟通工具里。 官方文档和仓库介绍里都提到，它支持多种消息通道和自托管部署，核心思路就是让 AI 以“联系人”的形式存在，而不是一个必须主动打开的工具。

这会带来一种很特别的体验：

你不是“去使用 AI”， 而是“随手叫一下 AI”。

这种感觉非常强。

看到报错，发一句。 看到链接，丢过去让它总结。 在路上也能问，躺床上也能问，手机上也能问。

这就是 OpenClaw 最迷人的地方。

---

二、问题也恰恰出在这里：越顺手，越容易失控

我这几天最大的感受是：

OpenClaw 的问题，不是一次调用贵，而是它太容易让你多问几句。

这件事非常微妙。

在 Codex、Cursor、终端 agent 这类工具里，你通常带着一个明确目标去工作：

• 修一个 bug
• 改一个函数
• 跑一个任务
• 看一个 diff

但 OpenClaw 会让你进入另一种状态：

• 路上顺手问一句
• 群里看到问题顺手问一句
• 手机上看到个文档顺手丢过去
• 看到新闻也想让它搜一下
• 看到报错截图也想让它分析一下

于是你会发现：

你并没有刻意高频使用它，但你已经在高频使用它了。

而且 OpenClaw 本身又不是一个单纯的聊天框。 它是 Gateway，是 Skills，是多通道，是工具路由，是持久化对话，是一整套“让 AI 随时待命”的系统。官方安装和 Docker 文档也都说明了它是围绕这种自托管网关能力来设计的。

这就意味着，很多时候你表面上只发出了一句话，背后实际发生的却可能是：

• 带上更长的上下文
• 带上 agent 的系统提示
• 带上 skills 描述
• 触发工具调用
• 返回结构化结果后再总结一次

用户感觉只是“发了条消息”， 模型那边感觉可能是“又跑了一套工作流”。

所以 OpenClaw 的 Token 体验很容易变成一句话：

不是一次烧得特别猛，而是它会像漏水一样慢慢往外流。

---

三、为什么我后来更愿意回到 Codex？

因为我后来发现，我最核心的需求，还是写代码。

不是“把 AI 做成随时随地的联系人”， 而是更朴素的几件事：

• 看项目
• 改文件
• 跑命令
• 做 agent 工作流
• 处理长任务

而在这个场景下，Codex 的优势会一下子变得非常明显。

OpenAI 这段时间对 Codex 的推进其实已经很清楚了： 从 Codex CLI 到 Codex App，再到最近把 GPT-5.4 写成整合 reasoning、coding 和 agentic workflows 的推荐模型，方向非常明确，就是把 Codex 做成更专业的编码与 agent 工作台。

https://openai.com/index/introducing-the-codex-app/?utm_source=chatgpt.com

这不是“顺便支持写代码”， 而是它本来就冲着“开发者怎么更高效地干活”去做的。

---

四、如果你的主战场在本地开发，Codex 的优势真的很直接

1. 链路更短，额外消耗更少

OpenClaw 的路径大致是：

聊天应用 → Gateway → Skills / 路由 → 模型

Codex 的路径更像：

终端 / 桌面 → 模型

少一层通道逻辑，少一层通用路由，也少一层“为了什么都能接，所以必须更复杂”的系统设计。

这不是说 OpenClaw 做得差， 而是它解决的问题更广，所以天然更重。

如果你的任务就是在本地仓库里改代码，那么 Codex 的路径显然更短，也更直接。

---

2. Codex 更贴近“开发现场”

OpenAI 官方对 Codex App 的描述里，一个很重要的关键词就是：多 agent、长任务、并行工作。

这说明它不是做成一个“会聊天的开发工具”， 而是想做成一个真正能推进工程任务的工作台。

开发者真正需要的很多东西，其实都不是“聊天感”，而是：

• 对当前项目目录有感知
• 对终端上下文有感知
• 对 diff 有感知
• 对当前任务链路有感知

Codex 在这方面，明显更像“主力工具”。

---

3. Token 更容易花在刀刃上

这一点特别重要。

OpenClaw 的问题在于，它太容易把这些东西混在一起：

• 日常聊天
• 实时搜索
• 文档总结
• 文件操作
• GitHub
• 代码分析
• 提醒与任务

而 Codex 通常更容易维持在一个明确目标上：

我现在就是在处理这个仓库。 我现在就是在完成这个任务。 我现在就是在这个终端上下文里工作。

这不一定意味着 Codex 绝对更便宜， 但通常意味着：

你的 Token 更容易花在真正的开发任务上，而不是被碎片化调用慢慢稀释掉。

---

五、那 OpenClaw 就不值得用了么？

也不是。

说实话，OpenClaw 依然有它非常独特、而且很难被完全替代的价值。

第一，它是“多通道入口”

这是它最大的差异化。

Codex 再强，现在的核心场景依然偏本地终端和桌面工作流； 而 OpenClaw 最大的魅力，就是它能让 AI 活在 Telegram、Discord、Signal、iMessage 这些地方。

这意味着它更适合：

• 碎片化提问
• 手机上求助
• 跨设备协作
• 把 AI 变成长期在线助手

第二，它有自托管的控制感

如果你很在意：

• 数据掌控
• 自己部署
• 自己接 API
• 自己接技能
• 自己跑在 VPS 上

那 OpenClaw 的味道会很对。

第三，它更像一套“个人 AI 基础设施”

Codex 更像一个专业工具。 OpenClaw 更像一套底座。

你可以给它加通道、加 Skills、加自动化，把它慢慢拼成自己的 AI 系统。 这种“自己搭生态”的感觉，确实很吸引人。

---

六、我的最终结论：Codex 更适合当主力，OpenClaw 更适合当入口

如果一定让我用一句话总结这几天的感受，我会这么说：

OpenClaw 赢在“随时可用”，Codex 赢在“正经干活”。

OpenClaw 像一个很聪明、随叫随到、到处都能找到的 AI 助手。 Codex 则更像一个坐在你工位上的高级工程搭档。

所以最合理的关系，可能不是谁替代谁，而是：

• Codex 负责主力开发
• OpenClaw 负责碎片化入口

但如果你非要让我二选一，只留一个，我现在的答案还是：

我会选 Codex。

不是因为 OpenClaw 不好， 而是因为我发现，方便本身，也是有成本的。

而 OpenClaw 最大的隐藏成本，就是：

它会让你在不知不觉中，把 Token 烧得很快。

---

最后一句

如果你是那种：

• 经常在本地写代码
• 需要 agent 帮你推进长任务
• 更在意工程效率和主力工作流

那 OpenAI 的 Codex，大概率会比 OpenClaw 更适合当核心工具。

如果你更想要的是：

• 手机上也能用
• 消息通道直接接 AI
• 自托管、多通道、可扩展技能

那 OpenClaw 依然很值得玩。 只是你最好先接受一件事：

龙虾很香，但也真的很能吃。

---

你怎么看？

你会把 OpenClaw 当主力，还是当入口？

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：CKCsec安全研究院 ckcsec ckcsec《我在用了几天 OpenClaw 后，还是选择了 Codex》