OpenAI 给 Codex CLI 加了个新命令，叫 /goal。
你给它设一个目标，它就一直跑，跨多轮不丢上下文，不达目的不罢休。
这个功能随 Codex CLI 0.128.0 版本发布，目前还是实验性功能，需要手动开启。Codex 团队的 Felipe Coury 是这样介绍它的：
“ 让目标在多个回合中保持活跃。不达成，就不停。
不达目的不罢休
而在我看来，这个功能背后其实藏着一个趋势：在 AI 时代，过程正在变得不那么重要了，重要的，是目标。
01
Ralph Loop
要理解 /goal，得先聊聊 Ralph Loop。
这个名字来自《辛普森一家》里的 Ralph Wiggum，那个「无知、执着、乐观」的小男孩。开发者 Geoffrey Huntley 用他的名字命名了一种 Agent 循环模式：给 Agent 设定一个目标，让它自己不断迭代，失败了就重来，直到目标达成。
VentureBeat 甚至写了篇文章叫《Ralph Wiggum 如何从辛普森一家变成 AI 界最火的名字》。
在社区的原始实现里，Ralph Loop 的做法比较「暴力」：每一轮结束后，Agent 从头开始一个新的上下文窗口，靠 git 记录和进度文件来保持记忆。
相当于每次换班，都交一份书面交接。
而 Codex 的 /goal ，则采取了不同的路线。
它是一个进程内的持续循环，目标在同一个会话里跨轮次保持活跃，不需要从头启动新上下文。
换句话说，社区的 Ralph Loop 像是接力赛，每一棒换个新人。
接力赛 vs 马拉松
而 Codex 的 /goal，更像是一个马拉松选手，从头跑到尾，累了可以暂停，但不换人。
02
如何使用
用法很简单。
先确保 Codex CLI 版本在 0.128.0 以上，然后在配置文件 ~/.codex/config.toml 里加一段：
●●●
[features]
goals =true
└
开启后，在 Codex CLI 里输入：
●●●
/goal 重构所有的数据库查询，添加连接池
└
Codex 就会开始围绕这个目标持续工作，写代码、跑测试、检查结果，一轮做完如果目标没达成，它会自动开启下一轮。
收到指令
此外，还有几个辅助命令：
• /goal pause：暂停当前目标
• /goal resume：恢复暂停的目标
• /goal clear：清除目标
如果你按 Ctrl+C 中断，目标会自动暂停，下次恢复线程时会自动继续。
一个实用的小技巧是：如果你的目标描述太长，直接写在命令里可能会出错。可以把详细的指令写在一个 .md 文件里，然后用 /goal follow instructions.md 来执行。
这个技巧我好早前就反复推荐过，放在文件里还有个好处是，不会被上下文压缩而丢失细节。
该版本还附带了一个 /side 命令，可以在不打断主线目标的情况下，临时开一个分支会话问问题。问完按 Esc 就回到主线，分支会话直接丢弃。这两个命令配合起来，其实挺顺手的。
不过……这应该为了避嫌抄袭 Claude Code，不然直接叫 /btw 不就得了 ，见：Claude Code 新增 /btw 功能
03
不会停，但也不傻
一个会自动循环的 Agent，最让人担心的就是：它会不会在无意义的事情上空转呢？
Codex 的实现里做了一套防护机制。
零工具调用抑制。如果一轮续跑中，Agent 没有调用任何工具（没写代码、没跑命令、没读文件），系统会判定它「卡住了」，自动停止循环，直到有新的输入才会重新触发。
预算控制。每个目标可以设置 token 预算和时间上限。当消耗超出预算时，系统会注入一条提示，告诉模型：别再开新任务了，总结一下进展，给用户一个明确的下一步。
三根绳子拴着的机器狗
完成审计协议。每次续跑开始时，系统会给模型注入一条隐藏的 developer 指令，要求它执行一套「完成审计」：
1. 把目标拆解成具体的可交付物
2. 建一份检查清单，把每个需求映射到实际证据
3. 检查真实的文件、输出、测试结果
4. 不能仅凭「测试通过了」就认为目标完成
也就是说，系统在机制层面防止了模型的一种常见问题：把「我产出了东西」错当成「我达成了目标」。
测试通过了不等于功能完成了，代码写完了不等于需求满足了。这种「代理证据接受」（proxy-evidence acceptance）是 Agent 循环中最隐蔽的失败模式之一。
04
源码分析
Codex 是开源的，所以可以直接来看它是怎么实现的。我更新了代码后让 AI 给我翻了一把。
功能的核心逻辑在 codex-rs/core/src/goals.rs 里，大约 1570 行 Rust 代码。
整个系统有三层：
持久化层： 目标状态存在 SQLite 数据库里，进程重启、线程恢复都不会丢失。目标有四种状态：Active（进行中）、Paused（暂停）、BudgetLimited（预算耗尽）、Complete（完成）。
工具层： 系统给模型暴露了三个工具：get_goal（读取当前目标）、create_goal（创建目标）、update_goal（更新目标状态）。
三层架构
这里有个关键的设计决策：模型只能把目标标记为「完成」，不能暂停或恢复。 暂停和恢复，只有用户能做。
源码里的逻辑是：
●●●
if args.status != ThreadGoalStatus::Complete {
return Err(FunctionCallError::RespondToModel(
"update_goal can only mark the existing goal complete"
));
}
└
为什么这么设计呢？
这是为了防止模型自己「偷懒」，觉得差不多了就给自己暂停一下（是不是很有经验？）。
从而，在你设了目标之后，模型要么完成它，要么你来喊停。
没有第三条路。
续跑层： 这是最核心的部分。每一轮结束后，系统会执行一个检查链：
1. 目标功能是否开启
2. 当前是否有活跃的目标
3. 是否有其他轮次在跑
4. 是否有待处理的消息队列
5. 续跑是否被抑制（前一轮零工具调用）
6. 当前是否在 Plan 模式（Plan 模式下目标被忽略）
全部通过后，系统注入一条 developer 消息，包含目标描述、预算使用情况，和那套完成审计协议。然后新一轮开始。
还有个小细节：token 计算只统计非缓存的输入 token 加上输出 token。 缓存命中的部分不算入预算。也就是说，预算追踪的是「新增的工作量」，复读已有上下文不收费。
这个功能的开发者是 Eric Traut，也就是 Pyright（Python 类型检查器）的作者。Felipe Coury 称他是「每天能一起工作的 GOAT 之一」。
05
实验性功能
当然了，/goal 毕竟还是实验性功能，目前也有一些局限。
目前它只在 CLI 里可用，Codex 的桌面应用暂时还没有这个功能。
另外，如果 API 配额用完了，/goal 会陷入一个尴尬的循环 BUG：不断发请求，不断收到配额耗尽的错误，然后继续重试……有人称之为「ralph loop of errors」。
在 Plan 模式下，目标系统会被自动忽略。也就是说，你不能一边规划一边设目标，两种模式是互斥的。
这倒是好理解，目标是制定好目标，有点奇怪……
不过从实测看，当前的目标完成判断依然存在「过早关闭」的问题。模型有时候会因为产出了某个 artifact 就认为目标完成了，即使实际上只完成了表面工作。
06
最重要的，是目标
/goal 的代码量不大，概念也不复杂。但它代表的方向，我想可能比大多数「重大更新」都更有意义。
因为它改变的并非 AI 的能力边界，而是人和 AI 的协作界面。
从「你说一句我做一步」，变成「你定目标我全程负责」。
从「对话」，变成了「委托」。
这背后的以终为始的思维方式的转变，比功能本身更值得思考。
我自己现在的编程中，也基本不太涉及动手编写代码的过程了。我更多的时间和精力花在了：我到底要达成什么目标？我怎么验证这个目标真的完成了？
如何制定正确的目标，如何想清楚到底要做什么，这其实才是更为考验人的、也更为重要的判断和工作。
过去我们习惯了「过程导向」的工作方式：先规划步骤，再逐步执行，每一步都要人盯着。
但 AI Agent 正在把这套逻辑翻转了过来：你只需要定义终点，路径是 Agent 自己走出来的。
这和传统编程的区别，就像导航 App 和手绘地图的区别。手绘地图时代，你得自己规划路线、记住每个路口。有了导航之后，你只需要输入目的地，至于走哪条路、怎么避堵、哪里右转，那是导航的事了。
过程导向 vs 目标导向
而 Karpathy 在最近 AI Ascent 的演讲里，也表达了类似的判断。他把这个趋势总结为 Software 3.0（见前文：软件 3.0 时代来临）：
“ 传统软件自动化的是你能规格化的东西，而 AI 自动化的是你能验证的东西。
三代软件范式的演进主线，其实就是人类参与方式的变化。
从 how（告诉机器怎么做），到 show（给机器看该怎么做），再到 what（告诉机器你要什么）。
作者→教练→指挥官
/goal 功能，也算是这条主线上最新的一个注脚。
你定义目标，也就是那个可验证的终态。Agent 自己去找路径。你验证结果，它负责过程。
当 Agent 开始管理自己的进度，并能真正达成设定的目标，人类唯一需要做好的事情，就只剩下一件了：
想清楚，自己到底要什么。
◇ ◆ ◇
• Codex CLI 开源仓库：https://github.com/openai/codex
• Felipe Coury 的原帖：https://x.com/fcoury/status/2049917871799636201
• Ralph Loop 社区实现：https://github.com/Th0rgal/open-ralph-wiggum
