https://www.knightli.com/tags/ralph/ Recent content in Ralph on KnightLi的博客 Hugo -- gohugo.io zh-cn Mon, 27 Apr 2026 08:19:02 +0800 https://www.knightli.com/2026/04/27/ralph-multi-agent-long-running-ai-workflows/ Mon, 27 Apr 2026 08:19:02 +0800 https://www.knightli.com/2026/04/27/ralph-multi-agent-long-running-ai-workflows/ <p>如果你最近在折腾 coding agent，很快就会遇到一个现实问题：<strong>AI 当然能干活，但怎么让它连续干几个小时，还不在中途跑偏、忘要求、返工一堆？</strong></p> <p>围绕 <code>Ralph</code> 和多智能体协同的这类讨论，真正值得看的也正是这个问题。它不是单纯比较某个模型有多强，而是把重点放在一层更实际的东西上：<strong>怎么设计工作流，才能让 AI 在长任务里保持稳定输出。</strong></p> <p>把这个问题拆开看，常见的路线主要有两条：</p> <ul> <li><code>Ralph</code> 方案：不断启动新会话，通过文件系统衔接上下文</li> <li>多智能体方案：主 Agent 做协调，子 Agent 分工执行</li> </ul> <p>如果把它压成一句更好理解的话，这期内容讲的其实不是“哪个模型更厉害”，而是“怎么把 AI 组织起来，让它更像一个能持续交付的小团队”。</p> <h2 id="01-为什么长时任务容易失控">01 为什么长时任务容易失控 </h2><p>短任务里，很多问题不明显。你给一句指令，模型读几份文件，改几行代码，事情也就结束了。</p> <p>但任务一旦拉长，问题会集中冒出来：</p> <ul> <li>会话越来越长，上下文开始膨胀</li> <li>早先的要求被新信息挤掉</li> <li>一个 Agent 既要想方案，又要写代码，还要自己测，容易顾不过来</li> <li>没有明确验收环节时，看起来“做完了”，其实只是“说自己做完了”</li> </ul> <p>所以长时间运行 AI，真正考验的往往不是模型单次输出能力，而是 <strong>任务拆分、状态衔接、角色分工和反馈回路</strong>。</p> <h2 id="02-ralph-方案把长任务拆成很多短回合">02 Ralph 方案：把长任务拆成很多短回合 </h2><p><code>Ralph</code> 的思路很适合先解决“上下文越跑越脏”这个问题。</p> <p>它的核心做法是：</p> <ul> <li>用循环不断启动新的 agent 会话</li> <li>每轮只处理一个足够小的任务</li> <li>把跨轮状态放到文件里，而不是全压在同一个对话上下文里</li> </ul> <p>这样做的好处很直接：每次都是 fresh context，单轮会更聚焦，也更不容易被历史消息拖慢。</p> <p>如果你已经看过 <code>Ralph</code> 相关项目，会发现这套方法背后的逻辑很一致：</p> <ul> <li>当前任务写在结构化文件里</li> <li>中间经验写到进度文件里</li> <li>代码变化留在 git 历史里</li> </ul> <p>换句话说，<code>Ralph</code> 不是试图让一个 Agent “永远记住所有事”，而是主动把记忆外置，让会话本身保持轻一点。</p> <p>这类方案特别适合下面几种情况：</p> <ul> <li>任务已经能拆成一组小 story</li> <li>每个 story 都能在单个上下文窗口里完成</li> <li>项目里已经有测试、typecheck 或其他检查机制</li> </ul> <p>它解决的是“如何让 AI 一轮一轮稳定推进”。</p> <h2 id="03-多智能体方案把一个人做不完的事分出去">03 多智能体方案：把一个人做不完的事分出去 </h2><p>另一条路线是多智能体协同。</p> <p>从这类工作流设计思路来看，更值得推荐的通常是这种方式：主 Agent 不直接埋头干活，而是负责协调；子 Agent 各自处理开发、测试、检查、验收等不同任务。</p> <p>这和 <code>Ralph</code> 的区别在于：</p> <ul> <li><code>Ralph</code> 更像串行迭代</li> <li>多智能体更像并行分工</li> </ul> <p>如果任务里天然有不同角色，多智能体会更顺手。比如：</p> <ul> <li>一个 Agent 负责拆任务和写执行计划</li> <li>一个 Agent 负责具体实现</li> <li>一个 Agent 负责测试和验证</li> <li>一个 Agent 负责回看结果是不是符合最初需求</li> </ul> <p>这样做的价值不是“多开几个窗口显得很高级”，而是让不同工作职责分离开。原来塞在一个 Agent 身上的几件事，现在可以拆成几个更明确的环节。</p> <p>一旦角色边界清楚，很多问题都会变轻：</p> <ul> <li>写的人不必同时当审的人</li> <li>跑测试的人不必重新推导整套需求</li> <li>主 Agent 不会被实现细节淹没</li> </ul> <p>它解决的是“如何让 AI 像一个小团队那样配合”。</p> <h2 id="04-真正关键的不是多开而是怎么拆">04 真正关键的，不是多开，而是怎么拆 </h2><p>无论是 <code>Ralph</code> 还是多智能体，最容易被忽略的一点都是：<strong>流程设计比多开几个 Agent 更重要。</strong></p> <p>如果任务拆分不对，就算开再多 Agent，也只是把混乱并行化。</p> <p>比较稳的拆法通常有几个特点：</p> <ul> <li>一个任务只对应一个明确目标</li> <li>一个角色只负责一类输出</li> <li>每轮都有清楚的完成标准</li> <li>上一轮的结果能被下一轮直接消费</li> </ul> <p>比如比起给 AI 一个“把整个功能做完”的大指令，更稳的方式往往是：</p> <ul> <li>先拆出需求和边界</li> <li>再拆实现</li> <li>再拆测试</li> <li>最后单独做验收</li> </ul> <p>这类拆法的好处是，问题一旦出现，更容易知道是出在理解、实现、测试，还是交付标准上。</p> <h2 id="05-为什么验收环节特别重要">05 为什么验收环节特别重要 </h2><p>很多 AI 工作流失败，不是因为前面完全没做事，而是因为最后缺了一个真正独立的确认动作。</p> <p>在长任务里，“已经生成结果”和“结果真的可用”之间，经常隔着一整层差距。</p> <p>这里有个很值得重视的方向，就是把开发和验收拆开看。哪怕不做到特别复杂，至少也应该把这些问题单独问一遍：</p> <ul> <li>它真的完成了最初那条任务吗</li> <li>有没有只改表面、没解决根因</li> <li>测试是不是只验证了最顺利的路径</li> <li>有没有把上游要求悄悄改掉</li> </ul> <p>只要这层检查缺位，AI 很容易在长流程里不断“自我宣布成功”。</p> <h2 id="06-两条路线怎么选">06 两条路线怎么选 </h2><p>如果只是想快速判断，可以先这么理解：</p> <ul> <li>你最痛的是上下文膨胀和长会话失焦，先看 <code>Ralph</code></li> <li>你最痛的是一个 Agent 身兼多职、任务之间互相打架，先看多智能体</li> </ul> <p>再具体一点：</p> <ul> <li><code>Ralph</code> 更适合流程清楚、任务细碎、可以按回合推进的工作</li> <li>多智能体更适合角色明显、需要并行和交叉验证的工作</li> </ul> <p>很多时候，这两条路也不是非此即彼。比较成熟的做法，反而可能是把它们组合起来：</p> <ul> <li>外层用 <code>Ralph</code> 这种迭代循环推进大任务</li> <li>内层在单轮里再用多智能体处理研究、实现、测试和验收</li> </ul> <p>这样既能控制长上下文，又能提高单轮内部的协作效率。</p> <h2 id="07-一句话总结">07 一句话总结 </h2><p>这类方法最值得看的地方，不是单独推荐了 <code>Ralph</code> 或多智能体，而是把一个很现实的问题讲清楚了：<strong>让 AI 长时间稳定工作，关键从来不只是模型本身，而是你有没有把上下文、任务、角色和验收设计好。</strong></p> <p>如果你已经开始让 <code>Claude Code</code>、<code>Codex</code> 或其他 coding agent 处理更长的真实任务，这类工作流思路会比“再换一个更强模型”更值得优先补课。</p> https://www.knightli.com/2026/04/27/ralph-autonomous-agent-loop-claude-code-amp/ Mon, 27 Apr 2026 08:08:55 +0800 https://www.knightli.com/2026/04/27/ralph-autonomous-agent-loop-claude-code-amp/ <p>如果你最近在关注 coding agent 的长流程执行，<code>snarktank/ralph</code> 是个很值得看一眼的小项目。它不是再做一个新的模型壳子，也不是再包一层聊天界面，而是把 <code>Claude Code</code> 或 <code>Amp</code> 组织成一个可以反复运行的 autonomous loop，让 AI 按 <code>PRD</code> 里的 story 一项一项往前做，直到全部完成。</p> <p>它的核心思路其实很直接：<strong>不要让同一个 agent 在一个越来越长、越来越脏的上下文里硬撑，而是每轮都重新启动一个全新的 AI coding session。</strong> 这样做的好处是，上下文不会一路膨胀，任务边界也更清楚。</p> <h2 id="01-ralph-是什么">01 Ralph 是什么 </h2><p>Ralph 的官方定位很明确：它是一个 autonomous AI agent loop，会反复调用 AI coding tool，直到 <code>PRD</code> 里的项目都做完。</p> <p>当前仓库支持两种工具：</p> <ul> <li><code>Amp CLI</code></li> <li><code>Claude Code</code></li> </ul> <p>每一轮迭代都会启动一个 fresh instance。也就是说，不依赖“同一个会话一直聊下去”，而是依赖这些外部状态来保存记忆：</p> <ul> <li>git 历史</li> <li><code>progress.txt</code></li> <li><code>prd.json</code></li> </ul> <p>这点非常关键。很多人让 agent 跑长任务时，最大的痛点不是模型不会写，而是会话越跑越重，最后开始漏上下文、忘要求、反复返工。Ralph 的设计，基本就是冲着这个问题去的。</p> <h2 id="02-它怎么工作">02 它怎么工作 </h2><p>Ralph 的工作流分成三步：</p> <h3 id="1-先写-prd">1. 先写 PRD </h3><p>README 里建议先用配套的 <code>prd</code> skill 生成需求文档，把功能拆成比较细的 story。</p> <h3 id="2-再把-prd-转成-prdjson">2. 再把 PRD 转成 <code>prd.json</code> </h3><p>然后用 <code>ralph</code> skill，把 Markdown 版 PRD 转成结构化的 <code>prd.json</code>。这个文件里会保存 user stories，以及每一项是不是已经通过。</p> <h3 id="3-运行循环脚本">3. 运行循环脚本 </h3><p>真正执行的是 <code>ralph.sh</code>。命令大致是：</p> <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code><span class="lnt">1 </span><span class="lnt">2 </span></code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">./scripts/ralph/ralph.sh <span class="o">[</span>max_iterations<span class="o">]</span> </span></span><span class="line"><span class="cl">./scripts/ralph/ralph.sh --tool claude <span class="o">[</span>max_iterations<span class="o">]</span> </span></span></code></pre></td></tr></table> </div> </div><p>默认是 10 轮。每一轮大致会做这些事：</p> <ol> <li>从 <code>branchName</code> 创建分支</li> <li>选择优先级最高、<code>passes: false</code> 的 story</li> <li>只实现这一项</li> <li>跑质量检查，比如 typecheck 和 tests</li> <li>检查通过后提交代码</li> <li>更新 <code>prd.json</code></li> <li>把经验追加到 <code>progress.txt</code></li> <li>继续下一轮</li> </ol> <p>也就是说，Ralph 并不追求“一口气把整件事做完”，而是把任务压缩成很多个能在单个上下文窗口里完成的小闭环。</p> <h2 id="03-ralph-最有意思的地方">03 Ralph 最有意思的地方 </h2><h3 id="1-每轮都是-fresh-context">1. 每轮都是 fresh context </h3><p>这是 Ralph 最核心的设计点。README 里强调，每次迭代都是一个新的 AI 实例，跨轮记忆只靠 git、<code>progress.txt</code> 和 <code>prd.json</code>。</p> <p>这和很多人平时直接在一个长对话里让 Claude Code 或其他工具连续工作很不一样。后者在任务变大后，很容易被历史消息拖慢，还会逐渐失去焦点。Ralph 则是主动接受“单轮记不住全部”，然后把记忆放到外部文件里。</p> <h3 id="2-强制把任务拆小">2. 强制把任务拆小 </h3><p>仓库文档特别强调，单个 PRD item 必须小到能在一个 context window 里完成。像“加一个筛选器”“改一个 server action”“补一列数据库字段”这种粒度比较合适；而“重构整个 API”“做完整 dashboard”这种就太大了。</p> <p>这个约束其实很现实。很多 autonomous agent 跑崩，不是 loop 本身有问题，而是任务切分太粗，让模型一轮里就背了过量目标。</p> <h3 id="3-不是只有代码连经验也要沉淀">3. 不是只有代码，连经验也要沉淀 </h3><p>除了 <code>progress.txt</code>，README 还特别强调要更新 <code>AGENTS.md</code>。原因也很实际：未来迭代和未来开发者都会读这些说明，所以每轮发现的模式、坑点、约定，最好都落到项目文档里。</p> <p>换句话说，Ralph 不只是让 agent 连续写代码，也想让它连续积累对代码库的工作记忆。</p> <h2 id="04-它适合什么场景">04 它适合什么场景 </h2><p>如果你的任务具备这些特征，Ralph 会比较对路：</p> <ul> <li>已经能拆成一组明确的 user stories</li> <li>代码库里有比较可靠的反馈回路，比如测试、typecheck、CI</li> <li>你希望 agent 持续推进，但不想把所有事压在单个长对话里</li> <li>你接受它按迭代方式一点点完成，而不是一次性全做完</li> </ul> <p>反过来说，如果你的需求还很模糊，或者任务本身高度依赖来回讨论、频繁改方向，那 Ralph 可能还不是第一选择。它更适合“需求已经整理好，现在需要稳定推进执行”的阶段。</p> <h2 id="05-它和普通-claude-code-用法有什么不同">05 它和普通 Claude Code 用法有什么不同 </h2><p>如果平时直接用 <code>Claude Code</code>，常见模式是你开一个会话，让它持续读代码、改代码、跑命令。这个方式在中小任务上很好用，但在大任务上容易碰到两个问题：</p> <ul> <li>上下文越来越长</li> <li>中间决策不容易结构化沉淀</li> </ul> <p>Ralph 的做法更像把 <code>Claude Code</code> 或 <code>Amp</code> 变成一个“批处理执行器”：</p> <ul> <li>任务来源不是临时聊天，而是 <code>prd.json</code></li> <li>每轮只认一个 story</li> <li>完成状态写回文件</li> <li>经验写进 <code>progress.txt</code></li> <li>代码提交进 git</li> </ul> <p>所以它更像是“给 coding agent 加了一层迭代控制器”，而不是换了一个新的 AI assistant。</p> <h2 id="06-一个值得注意的前提">06 一个值得注意的前提 </h2><p>Ralph 能不能跑顺，关键不在 loop 本身，而在反馈回路够不够好。README 里写得很直白：如果没有 typecheck、tests、CI 这些机制，错误会在后续迭代里不断累积。</p> <p>对于前端任务，仓库甚至明确建议把“用浏览器验证”写进 acceptance criteria。因为如果没有实际验证，agent 很容易把“看起来写完了”和“真的可用”混在一起。</p> <p>这点很重要。Ralph 不是 magical automation，它更像把你现有的工程纪律放大。如果你的项目本来就有清晰任务拆分和可靠检查，它会更有价值；如果这些基础还没有，loop 只会把混乱重复很多次。</p> <h2 id="07-一句话总结">07 一句话总结 </h2><p><code>Ralph</code> 最值得看的地方，不是它写了多少新基础设施，而是它把一个朴素但很有用的思路落成了现成流程：<strong>让 <code>Claude Code</code> 或 <code>Amp</code> 每轮只做一个足够小的 story，用 fresh context 保持专注，再靠 <code>git</code>、<code>prd.json</code> 和 <code>progress.txt</code> 维持跨轮连续性。</strong></p> <p>如果你已经开始把 coding agent 用到真实项目里，并且正在被“长任务怎么稳定推进”这个问题困住，Ralph 这套方法很值得参考。</p> <h2 id="参考链接">参考链接 </h2><ul> <li>GitHub 仓库：<a class="link" href="https://github.com/snarktank/ralph" target="_blank" rel="noopener" >https://github.com/snarktank/ralph</a></li> <li>交互式流程图：<a class="link" href="https://snarktank.github.io" target="_blank" rel="noopener" >https://snarktank.github.io</a></li> </ul>