https://www.knightli.com/zh-tw/tags/ralph/ Recent content in Ralph on KnightLi的博客 Hugo -- gohugo.io zh-tw Mon, 27 Apr 2026 08:19:02 +0800 https://www.knightli.com/zh-tw/2026/04/27/ralph-multi-agent-long-running-ai-workflows/ Mon, 27 Apr 2026 08:19:02 +0800 https://www.knightli.com/zh-tw/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/zh-tw/2026/04/27/ralph-autonomous-agent-loop-claude-code-amp/ Mon, 27 Apr 2026 08:08:55 +0800 https://www.knightli.com/zh-tw/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 instance，跨輪記憶只靠 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>