很多人第一次看到能连续干几个小时的 coding agent，脑子里冒出的第一个想法是：模型又变强了，所以它能自己一直干活。
这个直觉对了一半。
模型确实在变强。但真正让 agent 能持续工作、反复修 bug、跨多轮上下文的，不是一句神奇的提示词，而是一套工程循环 – Ralph Loop 和 Codex /goal 就是这套循环里的两个典型设计。
Ralph Loop 用外部脚本和文件记忆让 agent 反复重启干活，Codex /goal 把长期目标内建进运行时，让 agent 自动续跑。
它们解决的是同一个问题 – 怎么让 agent 围绕一个长期目标持续推进，而不是执行完一轮 prompt 就下班。
差别在哪呢？Ralph Loop 把这个机制做成了外部脚本加文件记忆；Codex /goal 把它塞进了运行时内部，变成一个持久目标状态机。
先抛结论。
Ralph Loop 的核心是：反复启动 fresh agent，用文件和 git 保存记忆。Codex /goal 的核心是：持久目标状态加 runtime 自动续跑加预算控制。
再压缩成一句话：Ralph Loop 是外部 orchestrator，Codex /goal 是内建状态机。
这两个机制都不是在让模型"凭意志坚持工作"，而是在模型外面加了一层控制系统。这层系统负责保存目标、保存进度、触发下一轮、判断停止条件，让 agent 每次都能从真实状态继续往下干。
Ralph Loop：别信长上下文，信文件
Ralph 的设计很朴素。
它不是什么大模型，也不是一套复杂的 agent framework。它的主循环本质上就是一个 shell orchestrator。
Ralph 会反复运行 Amp 或者 Claude Code。每一轮都是一个全新的 agent 实例，拿着干净的上下文。上一轮做了什么，不靠聊天历史记住，靠的是文件、git 和任务状态恢复。
Ralph 的典型状态来自这些地方：
prd.json– 任务列表和 story 状态progress.txt– 当前进展、下一步、风险记录git history– 已经落地的代码变化test output– 真实的验证结果
Ralph Loop 的思路说白了就一句：上下文可以丢，状态不能丢。
聊天上下文越长，越容易出问题 – 模型开始遗忘早期的约束，误解当前状态，或者在错误的方向上继续往前冲。这就像让一个人靠记忆背下整本菜谱做菜，和让他每次翻到菜谱当前步骤接着做的区别。
Ralph 的处理方式不是想办法压缩聊天上下文，而是主动重启上下文。每一轮重新启动 agent，让它从项目文件、PRD、进度记录和 git 状态重新理解任务。
我帮你把 Ralph Loop 的流程简化一下：
- 读取
prd.json、progress.txt、git 状态 - 启动一个 fresh coding agent
- agent 选一个未完成的 story
- agent 改代码、跑测试、更新进度
ralph.sh捕获 agent 输出- 看到
COMPLETE就停，否则 sleep 一下，再启动下一轮
所以 Ralph 的外层脚本其实只做三件事：启动 agent、捕获输出、决定继续还是停止。
至于"该做哪个 story"“怎么改代码"“怎么跑测试"“怎么更新进度”，这些不写死在 shell 里，而是写在 prompt contract 里。本质上，Ralph Loop 是这么个组合：
shell loop + prompt contract + file-based memory + completion token
Ralph 让人眼前一亮的地方，不是那个 shell 脚本本身，而是它对 agent 记忆该放哪里的判断。
大部分 agent 系统默认把记忆放在对话历史里。Ralph 反过来：
- 目标放进 PRD
- 进度放进 progress.txt
- 事实放进代码和测试
- 变化放进 git
这样一来，下一轮 agent 不需要"记得"上一轮自己说过什么，只需要重新读取这些外部状态，就能恢复现场。
这对长任务特别关键。因为长期 coding task 真正可靠的状态，不应该是"模型记忆里觉得自己做过什么”，而应该是：文件里写了什么、测试是否通过、git diff 里有什么、PRD 里哪些 story 已完成、progress.txt 里记了什么阻塞。
Ralph Loop 把 agent 从"长聊天"拽回了"工程工作流”。
Codex /goal：把继续干变成运行时职责
Codex /goal 解决的是同一类问题，但路线不同。
Ralph 是外部脚本反复启动 agent。Codex /goal 则是把长期目标内建进 Codex 的运行时。
普通 prompt 是一次性的：你输入任务，agent 执行一轮，返回结果，回合结束。而 /goal 会创建一个持久目标：
- 你设置 goal
- runtime 保存 goal state
- agent 执行一轮
- runtime 统计进度和预算
- 如果目标仍然 active，自动注入 continuation prompt
- agent 继续下一轮
- 直到 complete、budget-limited 或者 paused
所以 /goal 的重点不在 slash command 本身，而在 goal state。一个 goal 至少需要保存这些信息：objective（目标是什么）、status（当前 active 还是 complete 还是 budget-limited）、tokens_used、budget、thread。
这意味着目标不只是聊天记录里的一句话，而是运行时可以读取、更新和审计的状态对象。就像你银行账户的余额不是一个口头承诺，而是一个存在数据库里的数字。
Codex /goal 能持续工作的关键，在于 runtime continuation。
每一轮 agent turn 结束后，runtime 会检查当前线程状态：
- 是否存在 active goal
- 是否还有预算
- 当前是否没有正在运行的 turn
- 是否没有新的用户输入排队
- 是否允许继续推进
如果条件全部满足，runtime 就会主动构造一个 continuation turn。
这和用户手动说"继续"不一样。手动"继续"依赖人类记得当前任务，也依赖模型从上下文里找回目标。/goal 则是运行时知道当前存在一个 active goal，于是自动把目标、预算、用量和完成要求一起注入给模型。
所以 Codex /goal 的本质是：
persisted goal state + runtime continuation + budget accounting + structured completion
它把"继续干"从聊天习惯升级成了运行时机制。
另外 Codex /goal 还有一个重要的边界设计：完成不是模型在自然语言里随便说一句"我做完了"就行的。
在 Codex 的实现里，模型得通过结构化工具把 goal 标记为 complete。预算耗尽、暂停、恢复这类状态，则由系统或用户控制。
这个边界很重要。如果模型可以随便改所有状态，它可能为了结束任务而把没完成的目标标成完成。结构化状态更新把模型的权限收窄了：模型可以推进任务，可以在确认完成后标记 complete，但预算和暂停等控制权属于 runtime 或用户。
这也是 /goal 比普通 prompt 更像工程系统的地方。它不仅会让 agent 继续，还会约束 agent 什么时候能停。
Ralph Loop vs Codex /goal：外部工作流与内建状态机
把它们放一起看，区别就很清楚了。
第一眼看过去，状态放的位置就不一样。
Ralph Loop 把状态放在项目外部可见的工程资产里：prd.json、progress.txt、git、测试结果。Codex /goal 把目标状态放在 Codex runtime 的持久线程状态里：thread goal state、goal status、token accounting、continuation scheduling。
续跑方式也不同。Ralph Loop 是 shell for loop，启动 fresh agent，检查输出，重复。Codex /goal 是 turn 结束，runtime 检查 active goal，注入 continuation prompt，下一轮。
完成信号也不同。Ralph 用输出约定 – 看到 COMPLETE 标记就停。Codex 用结构化工具状态更新 – update_goal status=complete。
换个角度说：Ralph Loop 是把 agent 长任务做成一个可见的外部工作流，Codex /goal 是把 agent 长任务做成一个内建的运行时能力。
一个在外部，一个在内部。一个靠 shell 和文件，一个靠 runtime 和状态机。
但它们底层原则一致：
- 目标必须持久化
- 进度必须可恢复
- 反馈必须可验证
- 续跑必须可控制
- 停止必须有明确边界
对开发者有什么用：agent 长期任务的五个关键问题
如果你想理解 long-horizon coding agent，别只盯着 prompt 研究。
更应该琢磨这几个问题：怎么把目标从一句话变成可追踪状态，怎么把进度从聊天历史迁移到文件或 git，怎么让 agent 每一轮都有明确反馈而不是靠自我感觉，怎么设计预算和停止条件避免自动循环失控，怎么让完成状态可审计而不是靠模型口头保证。
Ralph Loop 给了一个最小可实现版本。Codex /goal 给了一个产品化运行时版本。
它们都指向同一个方向：未来的 coding agent，不是更长的聊天窗口，而是更可靠的目标执行系统。
如果你也在折腾 AI 编程工具，想搞清楚 agent 到底怎么持续干活，关注「全栈之巅-梦兽编程」公众号，每周更新 AI 编程实战干货。
也欢迎了解 梦兽编程 AI 编程助手服务 ，帮你把 agent 工具真正用到日常开发里。
参考资料
- Ralph 项目仓库 – 完整的 shell orchestrator 实现
- ralph.sh 主循环脚本 – 不到 200 行的核心循环
- Codex goals.rs – goal state 的 Rust 实现
- Codex continuation prompt 模板 – runtime 自动续跑时的注入 prompt
- Codex budget limit prompt 模板 – 预算耗尽时的通知 prompt
FAQ
Ralph Loop 和 Codex /goal 我应该用哪个？
看你手头有什么。Ralph Loop 是开源的 shell 脚本，你可以直接拿去改，适合想自己折腾工作流的开发者。Codex /goal 是 Codex 内置功能，开箱即用但绑定了 Codex 生态。如果你用 Codex CLI，直接用 /goal 最省事；如果你想把 Claude Code 或者其他 agent 也纳入长期任务流程，Ralph 的思路更容易迁移。
为什么不直接给模型一个超长的上下文窗口？
上下文越长，模型的注意力越分散。不少实验都发现，模型在长上下文的中间部分容易"遗忘" – 就像你看一本500页的书，翻到第300页的时候第一章讲了什么已经模糊了。Ralph Loop 和 Codex /goal 的做法本质上是让模型每次都只面对"当前这一步"的信息，而不是把整个项目历史塞进一个窗口里。
长期 agent 任务最大的坑是什么？
方向漂移。agent 干着干着可能偏离原始目标，因为它每一轮都在当前上下文中做局部最优决策。Ralph 用 PRD 和 progress.txt 防止这个问题，Codex 用 goal state 和结构化状态更新来约束。两者都强调"外部锚点"，而不是靠模型自己记住方向。