过去一年，很多开发者尝试通过构建复杂系统来实现AI自主编程——多智能体协调器、专职任务子智能体、繁琐的上下文传递……然而最终发现，解决方案可能只需要一个bash 循环（for-loop）。
这套技术被称为Ralph Wiggum，由Geoffrey Huntley于2025年7月提出。名称取自《辛普森一家》中那位单纯而执着的角色。随后，该机制获得Anthropic官方认可，并集成进Claude Code的官方插件体系；目前在社区热门的OpenCode中也已内置支持。
本文将从原理到实践，介绍这一简单而高效的设计理念：重复运行同样的操作，直到它成功为止。
Ralph循环的核心原理
最简实现
Ralph的最小实现形式如下：
while true; do
claude -p "$(cat PROMPT.md)"
done你只需要准备一个提示文件并执行它。Claude每次执行完成后，都会在当前目录留下执行结果；下一次运行时，这些结果会继续被使用。
由于执行状态保存在文件系统中，每一轮都能看到完整的代码变更、git提交和历史执行记录。
核心思路：Claude的执行结果会持久化到文件系统中。
工作原理详解
整个流程可以分几步理解。第一次迭代，Claude根据提示实现部分功能并提交代码。第二次迭代，它看到已有代码后，会从上次停下的地方继续，或者修复之前的问题。第三次迭代同理。循环会一直进行，直到任务完成或触发安全限制。
这个方法之所以行得通，是因为模型能读懂已有代码。Claude每次运行时，面对一个未完成的代码库，会推断出接下来要做的事情，并在已有实现上继续推进。虽然上下文会重置，但代码本身不会丢失，从而保证任务的连续性。
技术优势分析
简单胜过复杂，主要体现在：
• 没有交接风险：智能体之间的任务交接容易出问题，单循环就避免了这些麻烦 • 状态统一管理：文件系统记录当前状态，Git保存历史，让信息不丢失 • 减少协调工作：不用在多个智能体之间来回同步，系统更轻松
Anthropic的研究发现，长期运行智能体的难点在于跨上下文窗口管理信息。解决方法不是增加更多智能体，而是充分利用文件系统。进度日志、功能检查清单、Git历史等简单工具，就能让每次新的迭代都清楚地知道之前做了什么。
实战技巧：让Ralph真正可靠工作
1. 定义明确的完成标准
Ralph循环运行的前提是有清晰的完成信号。你需要告诉Claude任务什么时候算完成，例如：
当以下条件全部满足时，输出COMPLETE：
- 所有函数都有单元测试
- 测试通过
- 没有TypeScript错误
- README文档化了API我会把这些标准放在一个清单文件里。Claude每轮迭代都会检查清单，只处理未完成的部分，全部达成后才输出完成标志。
2. 小迭代原则
每轮迭代尽量只处理一个任务。原因是上下文窗口的「效率」会随迭代变化：
• 迭代开始时，Claude 对上下文的理解能力最佳 • 随着token增多（读取文件、写代码、运行命令），模型性能会下降
如果一次迭代里做太多事情，后半部分的任务可能效果不佳。
小迭代还有一个好处：调试更容易。如果出问题，你能马上定位到是哪次提交造成的，而不是在一堆改动里找问题。
3. 反馈循环设计
Ralph循环要起作用，Claude必须能够检查自己的工作。这就需要你在任务里加入测试、类型检查、代码审查等自动化验证环节。
没有验证的话，Claude可能会把还没完成或者有问题的任务当作完成。Anthropic的研究也指出，模型在没有验证机制时容易过早认定任务完成。
因此，验证应该成为完成标准的一部分。例如，你可以在提示中指定：
在标记任何完成之前：
1. 运行测试套件
2. 运行类型检查
3. 手动验证功能按预期工作
如果任何检查失败，在继续之前修复问题。4. 安全限制设置
Ralph循环必须限制迭代次数。没有限制，它可能在同一个任务上反复尝试，浪费API配额却没有实际产出。
常用策略：
• 小任务：最多20次迭代 • 大任务：最多50次迭代
如果达到上限仍未完成，说明任务定义或提示可能有问题，需要人工干预。
示例实现：
for i in $(seq 1 50); do
claude -p "$(cat PROMPT.md)"
# 检查完成信号，若完成则中断循环
done5. 进度文件模式
一个实用技巧是使用进度文件，一个简单的文本文件，用来记录Claude每次迭代完成的任务。例如：
## 迭代 1
- 设置项目结构
- 创建初始数据库模式
- TODO: API 端点尚未开始
## 迭代 2
- 实现 GET /users 端点
- 添加输入验证
- 测试通过每次新迭代开始时，Claude会读取这个文件，了解当前进度。这样即使模型上下文被清空，也能接着上一次工作继续。开发者也可以通过这个文件快速判断任务是否在按计划推进。
适用场景与最佳实践
Ralph循环最适合处理可量化、可验证的任务。
🌟 适用场景
• 项目重构：迁移完成且测试通过 • 增加测试覆盖率：达到设定覆盖率 • 文档编写：所有公共API均有文档 • 功能实现：满足明确的验收标准 • 批量转换：将多个组件迁移到新模式
❌ 不适用场景
• 探索性任务：目标不明确或方向不清 • 主观设计决策：需要人工判断美学或体验 • 安全敏感代码：需人工严格审查 • 无法量化的完成标准：需要人工确认完成
核心原则：Ralph依赖客观的完成标准。如果任务可以用脚本或自动化检查验证完成情况，Ralph可以全自动处理；否则仍需要人工干预。
📌 最佳实践建议
如果你打算试试Ralph循环，建议不要一上来就跑自动化。
先手动跑一轮，看看Claude实际会怎么理解你的提示、会不会跑偏，这一步能帮你快速校准预期。
从低风险任务入手，比如补测试、写文档，失败了也不至于影响核心功能。
尽量使用官方插件，那样循环控制和安全限制都有保障。
安装方式主要有两种，如果是安装claude-plugins-official市场下的ralph，命令如下：
# 安装插件
/plugin install ralph-loop@claude-plugins-official
# 使用方式
/ralph-loop:ralph-loop "你的任务" --max-iterations 20 --completion-promise "DONE"那么如果是安装claude-code-plugins市场下的ralph，命令如下：
# 注册市场
/plugin marketplace add anthropics/claude-code-plugins
# 安装插件
/plugin install ralph-wiggum@claude-code-plugins
# 使用方式
/ralph-loop "你的任务" --max-iterations 20 --completion-promise "DONE"注意成本，迭代次数越多、上下文越大，花费就越高。先跑小循环，摸清效果和账单，再决定要不要放大。
写到最后
Ralph最吸引我的，是它让我换了一种用AI的思路。过去写提示，我总是把步骤拆得很细，生怕模型一不小心走偏。用了Ralph之后，我反而不太关心过程细节，而是先把系统本身设计好：什么才算完成、怎么测试结果、出了问题如何反馈、边界在哪里。哪一轮中途跑偏并不重要，只要还能继续跑、还能被检查，整体方向一般不会失控。
这背后其实是一种信任的变化：不再盯着每一步对不对，而是相信模型在反复尝试中会慢慢走对；相信反馈能把跑偏的地方拉回来；也相信边界条件不会让成本失控。
在折腾了一年复杂的多智能体编排之后，一个简单的for-loop反而带来久违的轻松感。不是因为简单永远更好，而是当模型足够强时，简单已经够用了。
