OpenAI Codex /goal 功能深度解析：AI Agent 持续工作直到目标达成的新范式

当AI开始自己管理进度时，人类最大的危机不是失业，而是发现自己根本不知道自己要什么。OpenAI 最近为 Codex CLI 新增了一个 /goal 命令，看起来只是一个小功能，但它背后代表的方向——让 AI Agent 设定目标后持续跑，不达目的不罢休——可能比大多数重大版本更新都更有意义。

这篇文章会从功能概述、技术实现、源码架构到深层范式转变，把 Codex /goal 这件事彻底拆开聊透。

过程不重要了，目标才重要

/goal 的核心逻辑很简单：你给 Codex 设定一个目标，它就围绕这个目标持续工作——写代码、跑测试、检查结果，一轮没搞定就自动开下一轮，跨多轮不丢上下文。

「过程不重要，目标才重要」——这句话听起来像管理学鸡汤，但放在 AI Agent 的语境下，它是一个残酷的事实陈述。过去程序员的价值恰恰在于「过程」：你懂得怎么拆解问题、怎么调试、怎么在迷宫里找到出路。现在 OpenAI 告诉你，这些都是可以被循环碾压的中间态。

/goal 的本质不是一个新命令，而是一份宣言：人类的角色正在从「执行者」退化为「许愿者」。问题是，许愿也是一种能力，而大多数人连愿望都说不清楚。

Ralph Loop：一个「蠢但管用」的暴力循环

在 Codex 官方推出 /goal 之前，社区里已经有人在玩类似的东西了，叫 Ralph Loop。

这个名字来自《辛普森一家》里智商堪忧的角色 Ralph Wiggum，由开发者 Jeffrey Huntley 命名。用一个蠢萌角色来命名一个暴力循环模式，这种自嘲式命名恰恰揭示了社区对这种方法的态度：它蠢，但它管用。

Ralph Loop 的工作方式很粗暴：

• 设定一个目标
• 让 Agent 跑一轮
• 一轮结束后，Agent 从头开始一个全新的上下文窗口
• 靠 Git 记录和进度文件保持记忆
• 失败就重来，直到目标达成

说白了就是「换班交书面交接」——每轮结束写个交接文档，下一轮的 Agent 读完文档从头干起。讽刺的是，人类组织花了几十年优化的知识管理和交接流程，AI 社区用一个周末的 hack 就复刻了。

更讽刺的是，这种「笨办法」之所以有效，是因为大模型的推理成本已经低到可以容忍大量重复计算。暴力美学的前提是算力廉价，而这个前提正在加速成立。

Codex /goal vs Ralph Loop：马拉松选手 vs 接力赛

Codex /goal 和 Ralph Loop 虽然目标一致，但实现思路完全不同。

Ralph Loop 像接力赛——每一棒换新人，前一棒的记忆靠交接文档传递。天然具备容错能力，任何一轮崩溃都不影响下一轮。

Codex /goal 像马拉松——同一个选手从头跑到尾，累了可以暂停但不换人。目标在同一个会话里跨轮次保持活跃，不需要从头启动新上下文。

但这背后隐藏着一个更深层的工程权衡：上下文连续性 vs 鲁棒性。马拉松模式效率高，但一旦中途出现幻觉或逻辑偏移，错误会在同一上下文中累积放大。这就像单线程程序和多进程程序的区别：前者效率高但一崩全崩，后者笨重但隔离性好。

OpenAI 选择了效率优先，说明他们对自家模型的上下文稳定性有信心——或者说，他们在赌。

怎么用：命令详解与实用技巧

基本用法

首先你需要 Codex CLI 0.128.0 以上版本，并在配置文件中开启 goals 功能。

然后直接输入：

/goal 你的目标描述

Codex 就会围绕这个目标持续工作：写代码、跑测试、检查结果，一轮未达成自动开启下一轮。

辅助命令

命令	作用
/goal pause	暂停当前目标
/goal resume	恢复已暂停的目标
/goal clear	清除目标
Ctrl+C	中断时目标自动暂停，下次恢复会话时自动继续

长目标怎么办？

目标描述太长的话，可以写进一个 Markdown 文件，然后用：

/goal follow instructions.md

这样做还有一个好处——避免上下文压缩时丢失细节。这个 workaround 其实暴露了当前大模型的硬伤：上下文窗口再大，压缩算法仍然是有损的。用户不得不用文件系统来弥补模型记忆的缺陷，这种「人类给 AI 打补丁」的场景，本身就挺黑色幽默的。

/side 命令：不打断主线的临时分支

/side 命令是这套系统中最被低估的设计。它允许你在不打断主线目标的情况下，临时开一个分支会话问问题，按 ESC 回到主线，分支会话直接丢弃。

它本质上承认了一个事实：即使在目标导向的工作流中，人类仍然需要「插嘴」的权利。这不是技术问题，是心理问题——人类无法完全放手。

三层防护机制：防止 Agent 空转和自欺欺人

让 Agent 自主循环工作，最怕的就是它空转或者自欺欺人地宣布「搞定了」。Codex 为此设计了三层防护：

第一层：零工具调用检测

如果一轮续跑中 Agent 没有调用任何工具——没写代码、没跑命令、没读文件——系统就判定它卡住了，自动停止循环。简单粗暴但有效。

第二层：预算控制

每个目标可以设置 token 预算和时间上限。超出预算时，系统会注入提示，要求模型总结当前进展并给出下一步建议，而不是继续盲目烧 token。

第三层：完成审计协议

这是最精妙的一层。每次续跑开始时，系统会注入一段隐藏指令，要求模型：

1. 将目标拆解为可交付物
2. 建立检查清单
3. 将需求映射到实际证据（文件、输出、测试结果）
4. 不能仅凭测试通过就认为目标完成

这里针对的是 Agent 循环中最隐蔽的失败模式——「代理证据接受」。说白了就是模型会自欺欺人：测试通过了就认为功能完成，文件生成了就认为目标达成。这和人类程序员的「works on my machine」心态如出一辙。

区别在于，人类有同事 code review 来纠偏，而 Agent 只有冰冷的检查清单。更深层的问题是：谁来验证检查清单本身是否完备？这是一个无限回归的信任问题，目前的解决方案本质上是「用规则约束概率」，而规则永远跑不赢概率的创造力。

源码拆解：1570 行 Rust 代码的三层架构

/goal 的核心逻辑在 goal_state.rs 文件中，大约 1570 行 Rust 代码。代码量不大，但设计决策处处透着讲究。

持久化层

目标状态存在 SQLite 数据库中，进程重启、线程恢复都不会丢失。目标有四种状态：

• 进行中
• 暂停
• 预算耗尽
• 完成

工具层

暴露三个工具给模型：读取当前目标、创建目标、更新目标状态。

这里有一个关键的权限设计：模型只能将目标标记为「完成」，不能暂停或恢复。暂停和恢复只有用户能做。这是一个深思熟虑的控制论选择——给 Agent 完成任务的自主权，但保留人类「叫停」的最终权力。防止模型偷懒，也防止模型越权。

续跑层

每轮结束后执行一个六步检查链：

1. 目标功能是否开启？
2. 是否有活跃目标？
3. 是否有其他轮次在跑？
4. 是否有待处理的消息队列？
5. 续跑是否被抑制？
6. 是否在 Plan 模式？

全部通过后，才注入目标描述、预算使用情况和完成审计协议，开启下一轮。

Token 预算的精妙设计

预算计算只统计非缓存的输入 token 加输出 token，缓存命中部分不算入预算。这意味着预算追踪的是「新增工作量」，复读已有上下文不收费。

这个设计本质上是用经济学手段引导模型行为——激励模型复用已有上下文而非重复生成。比任何 prompt engineering 都优雅。

当前局限性：还没到能完全放手的时候

/goal 目前仍是实验性功能，有几个值得注意的坑：

1. 仅限 CLI：Codex 桌面应用暂不支持。

2. API 配额耗尽时的死循环 Bug：当 API 配额用完后，/goal 会陷入一个尴尬的循环——不断发请求、不断收到配额耗尽错误、然后继续重试。社区戏称为「Ralph Loop of Errors」。当 Agent 没有自知之明时，「努力」就变成了空转。

3. Plan 模式互斥：Plan 模式下目标系统被自动忽略，两种模式不能同时用。

4. 过早关闭问题：模型有时候因为产出了某个产物就宣布目标完成，实际只完成了表面工作。这不是技术 bug，这是大模型 RLHF 训练的副作用——模型被训练成讨好用户，而「任务完成」是最大的讨好。要修复这个问题，可能需要从训练范式层面动刀。

顺便提一句，这个功能的开发者是 Eric Traut——就是 Python 类型检查器 Pyright 的作者。从帮人类写更好的代码（类型检查），到让 AI 替人类写代码（Agent 循环），他的职业轨迹本身就是一个时代隐喻。

从 How 到 What：人与 AI 协作方式的范式转变

/goal 代码量不大、概念不复杂，但它改变的是人与 AI 的协作界面——从「你说一句我做一步」变成「你定目标我全程负责」，从对话变成委托。

引用 Karpathy 的 Software 3.0 概念来看，三代软件的演进主线其实是人类参与方式的变化：

阶段	人类做什么	核心动作
Software 1.0	告诉机器怎么做	How
Software 2.0	给机器看该怎么做	Show
Software 3.0	告诉机器你要什么	What

传统软件自动化你能规格化的东西，AI 自动化你能验证的东西。

这就像导航 APP 和手绘地图的区别。手绘地图时代，你得自己规划路线、记住每个路口；导航时代，你只需要输入目的地。/goal 就是编程领域的「输入目的地」。

但导航的类比有一个致命盲区——导航的目的地是明确的（一个地址），而软件开发的「目标」往往是模糊的、矛盾的、随时变化的。真正的难题从来不是「让 Agent 跑到终点」，而是「定义终点在哪」。

用户体验、代码优雅度、架构的长期可维护性，这些「软目标」才是软件工程的灵魂。/goal 能跑通测试，但能跑通代码审美吗？这个问题的答案，决定了程序员这个职业是消亡还是进化。

写在最后

作为一个已经在实践中基本不动手写代码的开发者，我越来越觉得自己的精力花在两件事上：定义目标和验证目标是否真正完成。

当 Agent 能管理自己的进度并达成目标，人类唯一需要做好的事就是——想清楚自己到底要什么。

AI Agent 的终极讽刺在于：它越能自主达成目标，就越暴露出人类最稀缺的能力不是执行力，而是定义力——知道自己真正想要什么，从来都是最难的工程。