夜雨聆风
OpenAI偷偷放了个大招:/goal命令,让AI不达目标不罢休
《辛普森一家》里有个角色叫 Ralph Wiggum。特点是：无知、执着、乐观。你给他设定一个目标，他就追着这个目标一直跑。摔倒了，爬起来继续。撞墙了，换个方向继续。直到——目标达成。
澳大利亚开发者 Geoffrey Huntley 给这种机制起了个名字：Ralph Loop。意思是：给 Agent 设定目标，让它自己不断迭代，失败了就重来，直到目标达成。
VentureBeat 专门写了篇文章：《Ralph Wiggum 如何从辛普森一家变成 AI 界最火的名字》。
而就在前几天，OpenAI 官方把这个功能做进了 Codex CLI。命令就叫：/goal。
不是社区魔改，不是第三方插件，是 OpenAI 官方出品。1570 行 Rust 代码，Pyright 作者 Eric Traut 亲手写的。
这意味着什么？意味着你再也不用”说一句，AI 做一步”了。
你只需要说：“我要这个。”然后 AI 会自己规划、执行、失败、重试、再执行……直到把目标搞定。你喝咖啡就行。
一、从”接力赛”到”马拉松”
社区里早有 Ralph Loop 的实现。
但社区的方案有个根本缺陷：每轮对话结束后，Agent 要重新启动，上下文从头来。就像接力赛，每一棒换个新人。前一个跑手记住的东西，后一个不一定知道。
OpenAI 的 /goal 不一样。它是进程内的持续循环——同一个会话，跨轮次保持活跃，从头跑到尾。马拉松选手和接力赛的区别。
使用方法也很简单：
-
确保 Codex CLI 版本 ≥ 0.128.0 -
在 ~/.codex/config.toml里加一行：goals = true -
然后直接说：
/goal 重构所有的数据库查询，添加连接池 Codex 就会开始自己干活。一轮接一轮，直到目标完成。
不想让它跑了？/goal pause。继续？/goal resume。彻底清掉？/goal clear。
按 Ctrl+C 打断，目标也会自动暂停。下次恢复线程时，它会从断点继续。
还有一个特别实用的技巧：
如果你的目标描述很长很复杂，别在命令行里打字——写进一个 .md 文件，然后：
/goal follow instructions.md 这样既能避免命令行输入错误，细节也不会被上下文压缩搞丢。
更绝的是 /side 命令。
你在等 AI 跑主线任务的时候，突然想临时问个别的问题，但又不想打断主任务。
/side 一开，临时分支会话，问完按 Esc，回到主线，分支直接丢弃。
有开发者调侃：这功能应该叫 /btw，但 OpenAI 为了避嫌抄 Claude Code，改叫 /side 了。
二、三层防护：”不会停，但也不傻”
OpenAI 官方做这个功能，最担心的不是”AI 跑不动”，而是“AI 停不下来”。
想象一下：你给 AI 设了个目标，然后它陷入了无限循环。改来改去，越改越偏，烧光你的 API 配额，最后给你一个乱七八糟的结果。
为了避免这种灾难，Eric Traut 在代码里埋了三层防护。
第一层：零工具调用抑制。
如果某一轮续跑中，Agent 没有调用任何工具——没写代码、没跑命令、没读文件——系统就会判定”它卡住了”，自动停止循环。直到你给它新输入，它才会重新触发。
简单说：光想不干，就停工。
第二层：预算控制。
每个目标都可以设置 token 预算和时间上限。超预算的时候，系统会自动注入一条提示：别再开新任务了，总结目前的进展，给用户明确的下一步。
而且预算计算很聪明——只统计非缓存的输入 token + 输出 token，缓存命中不算钱。
追踪的是”新增的工作量”，复读已有上下文不收费。
第三层：完成审计协议。
这是最狠的一层。
每次续跑开始时，系统会偷偷注入一段 developer 指令，要求 AI 必须执行四个步骤：
-
把目标拆解成具体的可交付物 -
建检查清单，每个需求映射到实际证据 -
检查真实的文件、输出、测试结果 - 不能仅凭”测试通过了”就认为目标完成
这针对的是一个特别隐蔽的 AI 失败模式——“代理证据接受”（proxy-evidence acceptance）。
什么意思？AI 把”我产出了东西”错当成”我达成了目标”。代码写完了 ≠ 需求满足了。测试通过了 ≠ 功能完成了。出了个 artifact ≠ 目标搞定了。
完成审计协议就是逼着 AI：你去检查真实的文件和输出，别自己骗自己。
三、源码揭秘：1570行Rust，模型不能给自己放假
/goal 的源码是开源的，在 codex-rs/core/src/goals.rs，约 1570 行 Rust。
作者是 Eric Traut——Pyright 的作者，Python 类型检查器的大牛。有开发者评价他是”每天能一起工作的 GOAT 之一”。
整个设计分三层：
持久化层：目标状态存在 SQLite 数据库里。进程重启、线程恢复都不会丢。四种状态：Active（进行中）、Paused（暂停）、BudgetLimited（预算耗尽）、Complete（完成）。
工具层：暴露三个工具给模型： – get_goal：读取当前目标 – create_goal：创建目标 – update_goal：更新目标状态
但这里有一个关键设计——模型只能把目标标记为”完成”，不能暂停或恢复。
代码里写得很死：
ifargs.status!=ThreadGoalStatus::Complete{returnErr(FunctionCallError::RespondToModel("update_goal can only mark the existing goal complete"));}为什么？
防止模型自己”偷懒”。
如果模型能自己暂停，它可能觉得”差不多了”就给自己放假。现在不行——模型要么完成目标，要么用户喊停。
没有第三条路。
续跑层：每轮结束后执行检查链——
-
目标功能是否开启 -
当前是否有活跃目标 -
是否有其他轮次在跑 -
是否有待处理的消息队列 -
续跑是否被抑制（前一轮零工具调用） -
当前是否在 Plan 模式（Plan 模式下目标被忽略）
全部通过后，注入 developer 消息，包含目标描述、预算使用情况、完成审计协议。
然后——下一轮开始。
四、坑还是不少的
功能很酷，但现阶段问题也挺明显。
第一，仅 CLI 可用。 Codex 桌面应用暂不支持，想用只能在命令行里玩。
第二，API 配额耗尽会陷入死循环。 有用户反馈，配额用完之后，Codex 会不断发请求，不断收到”配额耗尽”错误，然后继续重试……进入一个真正的”ralph loop of errors”。
第三，和 Plan 模式互斥。 如果你开启了 Plan 模式，目标系统会被自动忽略。不能一边规划一边设目标。
第四，模型有时会”过早关闭”。 产出某个 artifact 就认为自己完成了，实际只做了一层表面工作。
这些问题说明：/goal 还处在实验阶段，离”完全可信的自主执行”还有距离。
但方向是对的。
五、最后说句实在的
/goal 这个功能，表面上是给 Codex 加了个新命令。
实际上，它在推动一种协作界面的根本性变革。
以前，你跟 AI 的协作方式是：”你说一句，我做一步。“
现在，变成了：”你定目标，我全程负责。“
从”对话”到”委托”。
从”手绘地图时代——自己规划路线、记住每个路口”，到”导航 App——输入目的地，路线导航处理”。
这让我想起 Andrej Karpathy 说的 Software 3.0：
“传统软件自动化的是你能规格化的东西，而 AI 自动化的是你能验证的东西。”
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
/goal 就是在把 Software 3.0 从理论变成现实。
而在这个新范式里，人类唯一需要做好的事情，只剩下一件了：
想清楚，自己到底要什么。
因为过程？AI 会自己跑。
路径？AI 会自己找。
失败？AI 会自己重试。
你只需要确保——那个目标，是对的。
“窗口现在是开着的。不会永远开着。”
但这一次，窗口里的风景是：
一个人，一杯咖啡，一句话。
然后 AI 追着那个目标，跑完整个马拉松。