Jarrod Watts 花了几个月时间实测 Codex 的 /goal 功能，结论是：Ralph Loop 的原始形式（把同一个 prompt 循环跑）不够用。
他拆解了 Codex /goal 的实现原理，分析了它的三个核心缺陷，并给出了自己长期迭代出来的完整工作流。
Codex /goal 底层原理
Codex 的 /goal 功能基于 SQLite：
- 创建一个
thread_goals表，存储每个 goal 的 objective、id、status、token budget - 提供
get_goal和update_goal两个工具让 Agent 更新进度 - 本质上是一个标准的 Ralph Loop（prompt 反复运行）+ 解决了 15 分钟需要人工确认的问题
问题不在实现，在架构。
三个核心缺陷
1. 歧义会累积（Ambiguity Compounds）
LLM 在 loop 中每次迭代的输出会成为下一次迭代的输入——这意味着歧义会随每次决策指数级放大。
Agent 在完成一个任务时要做出无数个决策。在没有反馈的情况下，它做的决策可能和你的意图方向性不一致，然后所有后续工作都在这个错误方向上累积。
这和现实一样：如果你让别人建一个需求模糊的东西，你大概率拿不到你想象的结果。
2. 多角色系统优于单 Agent（Multi-Agent Mogging）
研究和实践都证明：orchestrator + subagent 架构比单个强 Agent 效果好。
本质上是"水平扩展 token 消费"——不是让一个聪明的 Agent 花更多 token，而是让多个 Agent 协作花时间。
Jarrod 的实现：主 Agent 作为 orchestrator，每个任务分配一个实现者 + 一个审查者，两个 Agent 来回讨论直到都对质量满意。审查者的价值在于：它是用全新视角看这段代码的，不受之前上下文偏见影响。
Boris（Claude Code 创造者）很早就指出了这一点。
3. 跨上下文记忆（Cross-Context Memory）
Codex 的 loop 没有结构化的跨 context 记忆机制——每次开新 context，Agent 不知道之前做了什么决定。
Jarrod 的解法是在 planning phase 之后让 Agent 创建并维护四个文件：
- GOAL.md：顶层目标
- STANDARDS.md：不可妥协的代码质量标准
- IMPLEMENT.md：工作流说明（多 Agent 审查、测试、验证等）
- PROGRESS.md：持续更新的决策和进度日志
新 Agent 加入时读取这四个文件，快速对齐所有上下文。
Jarrod 的完整工作流
Phase 1：Setup Phase（关键前置环节）
在让 Agent 自由跑之前，投入大量时间做 rigorous clarification——类似 Matt Pocock 的"grill-me"skill。
具体动作：
- 用 interview skill 做严格的需求澄清
- 把 goal 拆解成 milestones（每个 milestone 是小而可完成的任务块）
- 这一步强制你自己想清楚"我到底要什么"
每一步几乎都会暴露你自己没考虑到的假设和细节。
这个步骤是整个流程中最最重要的环节——它修剪了决策树，把 Agent 之后会走的路限制在你想要的范围内。
Phase 2：带多 Agent 协作的 Long-Running Loop
- 主 Agent（orchestrator）负责整体调度
- 每个任务块分配实现者 + 审查者
- 实现者完成 → 审查者 review → 来回修改 → 都满意后报告给 orchestrator
- 配合 git worktrees 做并行工作
Phase 3：跨上下文记忆维护
每个 context window 结束后，更新 PROGRESS.md，新 Agent 加入时读取四个文件。
对比：Ralph Loop vs Jarrod's Workflow
| 维度 | Ralph Loop | Jarrod's Workflow |
|---|---|---|
| 歧义处理 | 无，在 loop 中累积 | Setup phase 前置澄清 |
| 架构 | 单 Agent | Orchestrator + Reviewer 多 Agent |
| 跨上下文 | 无 | 四个记忆文件强制维护 |
| 质量门控 | 无 | Reviewer Agent 双重确认 |
开源实现
Jarrod 把整套工作流做成了一个 SKILL.md，可以插入 Claude 或 Codex：
- GitHub:
jarrodwatts/long-running - 推荐搭配 GPT-5.5 xHigh + Codex App（内置 subagent 可视化）
- 支持 git worktrees 并行化
和 Harness Engineering 的关系
这篇文章和 Martin Fowler 刚发布的 Harness Engineering 文章形成了有趣的互补：
- Fowler 说的是框架：feedforward guides + feedback sensors + 人类掌舵
- Jarrod 说的是具体实现：怎么在让 Agent 跑之前把 feedforward guides 建好（setup phase + 四文件记忆）
两者合在一起：setup phase = 建 harness，long-running loop = harness 在跑，reviewer = feedback sensor。