OpenAI新指令：AI目标达成前绝不停止

《辛普森一家》中的Ralph Wiggum，以其天真、执着和乐观的特质著称。设定一个目标给他，他便会不懈追求，即便跌倒也会爬起，撞墙则会另辟蹊径，直至目标实现。

澳大利亚开发者Geoffrey Huntley将此机制命名为“Ralph Loop”，意指为AI（Agent）设定目标，使其通过不断迭代、重试直至成功。

VentureBeat曾撰文探讨《Ralph Wiggum如何从《辛普森一家》跃升为AI界的焦点》。

近日，OpenAI官方将此功能整合进Codex CLI，命名为“/goal”。

这并非社区的非官方修改或第三方插件，而是OpenAI的正式发布，由Pyright作者Eric Traut基于1570行Rust代码精心打造。

这意味着，用户将摆脱“指令一句，AI执行一步”的模式。

用户只需提出需求，例如“我要这个”，AI便能自主规划、执行、应对失败、反复尝试，直至任务完成，用户则可轻松旁观。

社区早已存在Ralph Loop的实现方式。

然而，社区方案存在一个根本性缺陷：每轮对话结束，Agent需重新启动，上下文信息丢失，如同接力赛，每一棒的选手都需重新熟悉情况。

OpenAI的/goal指令则不同，它实现了进程内的持续循环——在同一会话中，跨轮次保持活跃，如同马拉松选手贯穿全程，而非接力赛的选手。

使用方法同样便捷：

Codex将自行开展工作，持续多轮，直至目标达成。

如需暂停，可输入“/goal pause”；继续执行，则为“/goal resume”；若要彻底清除，输入“/goal clear”。

通过Ctrl+C中断后，目标会自动暂停，下次恢复线程时将从中断点继续。

此外，还有一个极为实用的技巧：

若目标描述冗长复杂，可将其写入.md文件，然后使用此命令：

如此操作不仅能避免命令行输入错误，还能确保细节信息在上下文中不被压缩丢失。

更令人称道的是/side指令。

在等待AI执行主线任务时，若需临时处理其他问题而不打断主任务，可使用此功能。

/side指令开启一个临时的分支会话，完成后按Esc键即可返回主线，分支会话将直接被废弃。

有开发者戏称，此功能本应命名为/btw，但OpenAI为避免与Claude Code的嫌疑，改名为/side。

OpenAI推出此功能，最担心的并非AI“跑不动”，而是“停不下来”。

设想一下，用户设定一个目标后，AI陷入无限循环，不断调整却偏离目标，耗尽API额度，最终生成一堆混乱的结果。

为规避此类风险，Eric Traut在代码中设置了三层防护机制。

第一层：零工具调用抑制。

如果在某轮续跑中，Agent未执行任何工具调用（如未编写代码、未执行命令、未读取文件），系统将判定其“卡住”，自动终止循环，直至用户提供新输入方可重新触发。

简而言之：只思考不行动，则暂停工作。

第二层：预算控制。

每个目标均可设定token预算和时间上限。超出预算时，系统将自动注入提示，要求停止新任务，总结当前进展，并明确下一步指示。

值得注意的是，预算计算方式十分智能——仅统计非缓存的输入token和输出token，缓存命中不计费。

此举旨在追踪“新增工作量”，避免重复读取已有上下文产生额外费用。

第三层：完成审计协议。

这是最关键的一层。

每次续跑开始时，系统会秘密注入一段developer指令，要求AI执行四个步骤：

此机制旨在应对一种隐蔽的AI失败模式——“代理证据接受”（proxy-evidence acceptance）。

具体而言，AI可能将“我已产出内容”误认为“我已达成目标”。例如，代码编写完成不等于需求满足，测试通过不等于功能完成，生成某个文件不等于目标达成。

完成审计协议强制AI：必须检查实际文件和输出，避免自我欺骗。

/goal的源代码是开放的，位于codex-rs/core/src/goals.rs，约1570行Rust代码。

作者Eric Traut，正是Pyright（Python类型检查器）的开发者，被誉为“值得共事的最伟大开发者之一”。

整个设计分为三个层次：

持久化层：目标状态存储于SQLite数据库，进程重启或线程恢复后也不会丢失。四种状态包括：Active（进行中）、Paused（暂停）、BudgetLimited（预算耗尽）、Complete（完成）。

工具层：向模型暴露三个工具：-get_goal（读取当前目标）、-create_goal（创建目标）、-update_goal（更新目标状态）。

然而，一个关键设计在于——模型只能将目标标记为“完成”，而不能自行暂停或恢复。

代码中对此有明确规定：

这样做的目的是：

防止模型“偷懒”。

若模型可自行暂停，可能在认为“差不多”时便停止工作。但现在，模型必须完成目标，或由用户手动停止。

不存在第三种选择。

续跑层：每轮结束后执行检查链——

全部通过后，注入developer消息，包含目标描述、预算使用情况及完成审计协议。

随后，新一轮开始。

该功能虽强大，但现阶段仍存在一些明显问题。

第一，仅支持CLI。Codex桌面应用暂不支持，用户只能在命令行中使用。

第二，API配额耗尽可能导致死循环。有用户反馈，配额用尽后，Codex会持续发送请求，不断收到“配额耗尽”错误，并继续重试，陷入真正的“错误循环”。

第三，与Plan模式互斥。若启用Plan模式，目标系统将被自动禁用，无法同时进行规划和设定目标。

第四，模型有时会“过早结束”。一旦产出某个文件，就认为已完成，实际上仅完成了表面工作。

这些问题表明：/goal仍处于实验阶段，距离“完全可信的自主执行”尚有差距。

但其发展方向是正确的。

/goal功能表面上看是为Codex增添了一个新指令。

实际上，它正在推动协作界面的根本性变革。

过往，人与AI的协作模式是：“你告诉我，我做一步。”

如今，则演变为：“你定目标，我全程负责。”

从“对话”转向“委托”。

如同从“手绘地图时代——自行规划路线、记忆每个路口”，升级为“导航App——输入目的地，路线导航自动处理”。

这不禁让人联想到Andrej Karpathy提出的Software 3.0：

“传统软件自动化的是可规格化的事物，而AI自动化的是可验证的事物。”

/goal正在将Software 3.0从理论变为现实。

在这个新范式下，人类唯一需要做好的事情，便是：

清晰地思考，自己究竟想要什么。

因为过程？AI会自行完成。

路径？AI会自行寻找。

失败？AI会自行重试。

你只需确保——设定的目标，是正确的。

“机会之窗现在是敞开的，但不会永远如此。”

而这一次，窗外的风景是：

一个人，一杯咖啡，一句话。

然后AI会朝着那个目标，完成整个过程。