Codex 和 OpenClaw，我为什么先选了前者

最近身边聊 AI 开发工具的人多了起来，两个名字出现的频率最高：Codex 和 OpenClaw。

说实话，我一开始也搞不清楚该怎么选，甚至觉得它们是在竞争同一个位置——直到我真正去用，才意识到这两个东西解决的根本不是同一个问题。

先说我作为个人开发者，实际上最缺什么。

不是想法。想法从来不缺。缺的是时间，或者更准确地说，缺的是在有限时间里不被卡住的能力。

我白天要工作，晚上能用来推项目的也就两三个小时。这两三个小时里，如果有一个 bug 卡了我一个多小时，基本上那晚就废了。一个重构拖到周末、一个部署脚本一直“以后再弄”，项目很快就从“在推进”变成“搁置”。

所以我对 AI 工具有一个很直接的判断标准：它能不能让我少被卡住。

从这个角度看，Codex 的定位很合我的胃口。

它本质上就是一个 coding agent，可以在本地终端、IDE 或桌面应用里读代码、改代码、跑测试。如果任务比较长，可以交给 agent 去跑，甚至开多个 worktree 并行处理。

我手上有个 side project，积了不少小任务：补分页逻辑、修一个登录状态偶尔丢失的问题、给旧模块补测试、还有一段很久没人敢动的类型定义要整理。这些事情不需要什么宏大的 agent 架构，需要的就是：看懂我的代码、改完能跑、出了 diff 我能放心 merge。

Codex 干的就是这件事。

我也很在意它的边界感。本地任务默认限制在工作区内，网络访问默认是关的，越界需要审批。听起来像是在说废话，但对一个人维护的项目来说，这种边界真的很重要——没有人帮你兜底，工具越主动，越需要清楚它会动哪里。

OpenClaw 让我心动的地方在于，它不像一个开发工具，而更像是“随时能召唤一个 agent”的基础设施。

它是开源的、可以自托管的，支持通过 Telegram、WhatsApp、iMessage 等发消息，有多 agent、技能、定时任务这些概念。理想状态下，你在地铁上发一句话，它去查日志；你睡前让它启动一个分析任务，第二天起来看结果。

这个画面确实很诱人。

但我去认真看了一下，发现想用好它，需要想清楚的事情比想象中多：模型凭证放在哪、哪些 session 有权限访问主机、工具要不要跑在 sandbox 里、远程访问怎么安全暴露……官方文档也提醒，在对外开放之前先读安全配置那一节。

这不是说它不好。它只是把控制权交给了你，同时也把维护责任交给了你。

对喜欢折腾基础设施的人来说，这是优点。但我已经有太多没写完的项目了，不太想再开一个“维护我的 agent 系统”的坑。

有意思的地方在于，这两个东西其实不是非此即彼的。

OpenClaw 文档里已经有 Codex harness，可以用 OpenClaw 负责消息路由和会话管理，然后把实际的代码任务交给 Codex 去跑。一个管接入，一个管执行，逻辑上是通的。

所以我现在的想法是分阶段来。项目还在早期，主要是写代码、修问题、推功能，先把 Codex 真正用起来。等到项目稳定了，开始有跨场景的需求——远程触发、定时巡检、消息渠道——再认真考虑 OpenClaw 值不值得投入。

如果让我现在只选一个，我会选 Codex，理由很简单：它离我最核心的产出更近。

我做项目，最先要解决的是代码能不能写出来、问题能不能修掉。Codex 直接参与这段，而且不需要我先搭一套长期运行的服务来支撑它。

OpenClaw 更像是第二阶段的事——等我真的遇到了“需要一个长期在线的个人 agent”这个问题，再去认真对待它，会比现在就折腾更划算。

AI 工具发展很快，很容易把“最新”当成“最适合”。但个人开发者最宝贵的东西不是工具数量，是注意力。

能帮我更快把功能写完、更稳地修掉 bug、少在重复劳动里耗掉晚上和周末的工具，就是我需要的工具。