之前的文章，我分享了最近用 AI 做项目的一些心得。我觉得程序员用 AI 做项目，就像在管理一群会偷懒的 AI 员工。
过去几个月里，一个被讨论得比较多的问题是，如何让 AI 能独立自主地持续运行很长时间，而不用人工参与，每隔一会就给它发一句继续。
目前比较常用的一个工具是 Raplph。它的原理是用 Shell 脚本循环调用 Codex 或者 Claude 这种 Agent。每当它退出以后，就再次调用。循环一定次数以后，把问题整个解决掉。
不过近期 Codex 已经悄悄推出了自己的工具，也就是 Goal 模式。我已经成功用 Goal 模式运行过多次超过 10 小时的任务。有了 Goal 模式，那些第三方工具就不再需要了。
下面介绍 Goal 模式的使用。
安装 Codex
首先需要安装 Codex CLI 0.128.0 或以上版本。目前 Goal 模式只能在 CLI 里面运行，图形界面暂时不支持。
建议在命令行中运行 npm install -g @openai/codex@latest，安装最新版的 Codex CLI。安装好后，如果你有官方账号，就直接登录官方账号。没有官方账号，也可以用 CC Switch 工具或直接修改配置文件的方式设置 API Key。
开启 Goal 模式
安装好后，打开 ~/.codex/config.toml 文件，增加一段：
1 | [features] |
然后启动 Codex，就可以使用 Goal 模式了。当你在命令行里输入 /g，如果可以看到下面有 goal 的候选项，说明已经正确打开。
权限设置
Codex 默认是在沙箱里运行的，所以会有很多权限限制。比如运行命令行需要用户 approve，比如访问网络有限制，比如不能启动 Playwright 浏览器环境。
平时如果人一直在电脑前，运行命令时需要 approve，点一下就行。但 Goal 模式需要持续运行。如果你人不在电脑前，可能睡一觉醒来，发现它早早的就卡在了 approve 界面几乎什么都没干。所以这个问题一定要提前解决。
最简单的方式，是直接运行下面的命令进入 YOLO 模式，这样就是最大权限。YOLO = You Only Look Once Mode，你只需要看一次，后面都可以让 Agent 自己跑。
1 | codex --yolo |
在界面里面也能看到 YOLO 模式已经打开。
如果你对 AI 比较放心，或者提前做好了安全措施，比如把 Codex 放在一台独立电脑上运行，或者放在 Docker 里运行，把项目做好备份，不担心它误删文件，那可以直接开 YOLO 模式。我实际上就是用的 YOLO 模式。
如果你觉得这样太危险，也可以自己设置权限。打开 ~/.codex/config.toml 文件，修改如下，如果 Codex 正在运行需要重启生效。这套配置可以满足大多数场景，但还是会有一些场景在这种设置下没法工作。
1 | sandbox_mode = "workspace-write" # 允许在工作区内编辑，并在该边界内运行常规本地命令 |
更详细的内容，可以参考官方文档。
https://developers.openai.com/codex/agent-approvals-security
https://developers.openai.com/codex/concepts/sandboxing
设置 Goal 目标
最简单的场景下，你只要在 Codex 里输入 /goal 你的目标，就可以运行 Goal 模式，直到目标完成。
但实际上，如果你只是用一句话来描述目标，它大概率会跑偏。要么自由发挥，做了很多和你设想不符的事，要么偷懒，变相完成了目标，但并不是你真正想要的结果。
所以更推荐的做法，是写一个完整的 Markdown 文件来解释你的目标，比如就叫 GOAL.md。然后输入 /goal 参考 GOAL.md，它就会自己读这个文件，再去实现对应的目标。
这个目标文件很关键。我推荐参考下面的结构去写。当然，我列出来的这些内容不一定都要写，可以根据实际情况调整。如果你觉得自己写得比较乱，也可以在启动 Goal 前先让 Codex 帮你整理。
1、目标，也就是简要说明这次任务要做什么。
2、状态记录与断点恢复。我一般会指定让 Codex 把进度保存到 GOAL_STATUS.md 里，并在文档中说明，每次启动后如果存在 status 文档，就应该先读里面的状态再继续执行，后续变动也都要记录进去。
3、流程。比如先阅读项目的 PRD、Spec 和 Plan 文档理解项目作用，再按设定步骤分别进行后续工作。
4、范围。如果你的项目里已经有文件，应该明确允许它改什么。另外最好再加一个限制，只能改 Workspace 里的文件，不要改外面的文件。当然，这还是建立在 AI 不出错的前提下。如果它出错，外面的文件也还是有可能被改到，所以最终还是要靠前面说的权限设置来兜底。
5、限制。明确不要改什么，不要做什么操作。比如修复项目复杂 Bug 这类任务，可以要求它不要大幅修改整体架构。
6、验收标准。也就是满足什么条件才算目标完成，可以停止。比如项目中的测试覆盖率达到多少，且所有测试都通过。
7、异常处理。如果遇到特定的阻塞异常，无法继续，可以直接停止。如果遇到不阻塞、但需要人工干预的异常，可以让它记录下来，并说明为什么需要人工干预，但剩余任务还要继续跑。
8、Token 预算。比如最多使用 100M Token 就停止，避免成本失控。
Goal 运行过程中的干预
如果 Goal 启动后，你看它的运行过程，发现它理解得不对，或者你的 GOAL.md 写得不完整，可以直接去修改 GOAL.md。改完以后，在命令行里给它发一条消息，我改了 GOAL.md，你再看一遍。
Codex 在运行完正在进行的一步后，就会重新查看你写的 GOAL.md。通常它会比较清楚地告诉你，它发现了哪些地方有变化，然后按照修改后的版本继续跑。
如果运行过程中，你有一些不理解的地方，比如不知道它为什么这么执行，也可以直接跟它对话。如果它解释完你觉得没问题，那就不用管。如果它的解释让你发现你的 Goal 写得不对，那就按前面说的方式去修改。
如果 Goal 已经跑起来了，但你需要临时暂停，或者要重启 Codex，比如为了调整权限设置，可以有两个思路。
第一个思路是直接按 Ctrl+C 终止 Codex。之后你会看到它输出一句话，To continue this session, run codex resume xxx，最后面的一串十六进制字符就是会话的ID。后面按照这个命令继续运行就可以了。
第二个思路，是直接给 Codex 发一条消息，说我现在需要暂停，请你把状态保存到 Goal Status 文档里。然后 Codex 就会把当前任务最新状态保存到 status 文档中，并停止运行。
但在它停止后，你会发现它马上又启动了，并且告诉你“我现在继续运行xxx”。这是因为 Goal 模式就是这么设计的。每次 Agent 自己停止后，系统都会审核目标有没有完成。如果没有完成，就会自动重新启动它。所以你需要在它刚启动的时候，再按一次 Ctrl+C 终止。
等下一次再进入 Codex 后，还是输入 /goal 参考 GOAL.md 就可以了。
实际运行感受
我实际在自己的项目上跑过几次 Goal 模式，总的来说效果还不错。
其中有一次，是让它帮我优化项目中的提示词。我的项目本身是通过 AI 实现的工作流。我让它实际运行这个工作流，并优化提示词，同时给它定了几个目标，比如这个项目是否能按照 PRD 中的预期，产出比较可靠的结果。
它确实做了一些优化，也修正了一些很明确的问题。比如两个 AI 步骤之间字段对不上，它帮我都修正了。但再往后，就没有更多优化了。总的来说，这种场景的问题在于，目标没办法非常清晰地量化。我只能在文档里写，让它判断这个结果是不是已经比较稳定、比较可靠了，但这不是一个足够明确的界限。
总的来说，Goal 模式更适合边界清晰的问题。
对于优化提示词，或者各种更模糊的事情，比如让界面更好看，由于 AI 本身的判断能力也是模糊的，所以很难量化，最后做出来的效果通常也没那么理想。
但对于那些需求比较明确的场景，它就很合适。举个例子，假设我想让 Codex 帮我做 100 个经典小游戏，这种场景就很适合 Goal 模式。因为经典小游戏的玩法在网上都能查到，规则比较明确。再加上你又明确规定了要做 100 个，所以这个目标就很清晰。
如果你直接给它发消息，让它做 100 个小游戏，不用 Goal 模式时，它可能做完一个以后就问你，要不要继续做下一个。但用了 Goal 模式以后，系统会自动审核它有没有真的做完 100 个，等全部做完了才会真正停下来。
当然，还有一点要说的是，Goal 模式真的非常消耗 Token。按照我的实际体验，只要连续跑两个小时左右，就会触发 Plus 账号的五小时窗口，还会消耗掉 7d 窗口的大约六分之一额度。
如果你想连续跑 10 小时，甚至更久的任务，至少要用官方 100 刀的 5x Codex 账号，最好是 200 刀的 20x 版本。整体看下来，成本还是有点高，不太适合轻度使用的用户。
我实际运行，有一次就是在持续了13个小时后，把所有的 Token 窗口的额度都消耗完了，直接停止了。
下面是我一次任务的实际成功执行结果截图。
如果觉得文章有帮助，欢迎分享转发，也欢迎关注我的公众号“搬砖的小明”，及时获取更新
