Ralph 循环:让 AI 自己干活、自己查、自己改
人类坐在循环上,不坐在循环里。
什么是 Ralph 循环?
Ralph Wiggum 循环是驭缰工程最核心的实现模式。
名字来自《辛普森一家》里那个不太聪明的角色 Ralph Wiggum--讽刺的是,这个模式比它的名字机灵多了:
说白了,人只管给目标,AI 自己跑循环、自己查、自己改,达标了再叫你。
这种循环一跑经常就是 6 小时以上--通常你还在睡觉。
六条核心信条
Ralph 循环的哲学被总结为六条信条，跟驭缰工程的几个核心概念是对得上号的。
1. Fresh Context Is Reliability（新鲜上下文 = 可靠性）
每次迭代重新读取上下文,不积累错误。
传统的人类编码中,经验积累是好事。但在 AI 编码中,上下文窗口的"记忆"是负担--它会累积过时信息、错误假设、不相关的细节。
Ralph 的做法:每次循环迭代,清空上下文,重新读取仓库。 智能体像第一天上班一样重新理解代码库--但这次它已经知道了任务目标。
2. Backpressure Over Prescription（用背压，不用指令）
不规定怎么做,但门控拒绝坏结果。
你不告诉智能体"先写测试再写实现"。你设置一道门:lint 检查 + 测试运行 + 类型检查。结果不达标,门就不开。
这比写 50 行的"编码规范"有效得多。因为智能体会找到你没想到的路径--有些是好路径,有些是坏路径。背压机制只拦截坏路径。
3. The Plan Is Disposable（计划是可抛弃的）
重新生成的成本只是一次 planning loop。
在 Ralph 循环中,计划不是神圣不可侵犯的。如果智能体发现计划走不通,它直接重来。
这和传统工程完全不同--传统工程里,推翻计划意味着前功尽弃。但在 Ralph 模式下,计划的成本很低,因为编码本身是 AI 做的。
4. Disk Is State, Git Is Memory（磁盘是状态，Git 是记忆）
文件是交接机制,Git 是时间机器。
Ralph 循环的核心设计:所有中间状态都写入文件。这样即使上下文窗口被清空,智能体也能从磁盘恢复状态。
Git 则记录了每一次尝试的轨迹。成功了,合并。失败了,回退。不需要人类手动保存任何东西。
5. Steer With Signals, Not Scripts（用信号引导，不用脚本）
加路标,不加方向盘。
你不说"在第 47 行加一个 if 判断"。你说"这个函数不应该返回 null"--然后让 lint 规则和测试来表达这个约束。
信号是方向性的("这个方向是对的"),脚本是操作性的("做这个动作")。智能体需要信号,不需要脚本。
6. Let Ralph Ralph（让 Ralph 做它的事）
坐在循环上,不坐在循环里。
这是最重要的信条。人类的工作不是盯着 AI 每一步操作,而是:
- 设计好约束系统(AGENTS.md + Lint + CI)
- 设定好目标
- 让 Ralph 跑
- 醒来检查结果
OpenAI 的 Codex 经常在人类睡觉的时候跑 6 个小时。早上起来,PR 已经准备好等人审查了。
Mitchell Hashimoto 的个人版 Ralph
HashiCorp 创始人 Mitchell Hashimoto 说了句更接地气的:
"每当发现 AI 犯了一个错误,你就花时间 engineering 一个解决方案,使 AI 永远不再犯那个错误。"
他的做法分两种:一是改 AGENTS.md(堵住 AI 反复犯的错),二是写工具(截图脚本、过滤测试之类),然后在 AGENTS.md 里告诉 AI 这些工具的存在。
Mitchell 的目标是:始终有一个 AI 在后台跑。目前他大约 10-20% 的工作时间有 AI 在处理任务。
Ralph 循环的三代进化
第一代:snarktank/ralph(13.6k ⭐)
最原始的实现--一个 bash 脚本,反复启动 AI,每次迭代清空上下文,直到 PRD 全部完成。
简单粗暴,但证明了核心概念。
第二代:ralph-orchestrator(2.3k ⭐)
Rust 重写的进化版:
- Hat 角色系统 - 不同角色(架构师、开发者、审查者)有不同的权限和工具
- 事件驱动协调 - 不再是简单的顺序循环,而是基于事件的异步流程
- 多后端支持 - Claude / Kiro / Gemini / Codex 都能用
- 背压门控 - 每一步都有质量门槛
- 持久化记忆 - 跨迭代保持关键状态
第三代:bmad-ralph
结合 BMAD 方法论的进化版:
- 并行 Claude Code worktree - 多个智能体在不同 worktree 上并行工作
- 三层自愈 - retry(重试)→ restart(重启)→ diagnose(诊断)
- SQLite 状态机 - 精确追踪每次迭代的状态
一个真实的 Ralph 循环长什么样
以 OpenAI 的实践为例:
bash
08:00 PM - 人类描述任务:"给支付模块加退款功能,需要处理部分退款和超时场景"
附带执行计划和验收标准
08:01 PM - Codex 启动,读取 AGENTS.md、架构文档、支付模块代码
08:15 PM - 生成初始实现,创建 PR
08:16 PM - 自动触发 lint + 测试 → 3 个 lint 错误
08:20 PM - 根据 lint 错误信息修复(无需人类)
08:21 PM - 重新跑 lint → 全过
08:25 PM - 自动触发 AI review agent → 2 条反馈
08:35 PM - 根据反馈修改实现
08:36 PM - 重新跑 AI review → 通过
08:40 PM - 自动合并 PR
(如果中途出了严重问题,会在 PR 中标注,等人类早上处理)
06:00 AM - 人类起床,看到 PR 已合并
审查变更记录,确认符合预期
发现一个小问题 → 留评论
06:05 AM - 新一轮 Ralph 循环自动处理评论
06:15 AM - 修复 PR 合并,完成人类参与时间:总共约 10 分钟。
AI 工作时间:约 10 小时。
什么时候该用 Ralph,什么时候不该
✅ 适合 Ralph 循环
- 任务目标明确,有清晰的"完成"定义
- 有自动化验证手段(测试、lint、CI)
- 任务可以拆分成独立的小步骤
- 需求可测试
⚠️ 不适合 Ralph 循环
- 需求模糊,"完成"标准不清晰
- 需要人类的创意判断(设计、产品方向)
- 没有自动化验证手段
- 涉及安全关键或合规关键的决策
写在最后
Ralph 循环解决的问题很具体:怎么让 AI 干 6 小时活,而你只需要花 10 分钟。
不是靠更聪明的模型,也不是靠更详细的指令。靠的是把"人盯着 AI 做事"变成"系统盯着 AI 做事"。lint、测试、CI 这些你本来就有的工具,换个用法就行。
这是驭缰工程系列的第五篇。上一篇:《AI 写的代码,你怎么知道是对的?》 下一篇:《Anthropic 的三智能体实验:用 AI 监督 AI》
觉得有用?关注这个号,下一篇讲 Anthropic 怎么用 AI 监督 AI。