Ralph Loop：用新鮮上下文讓 Coding Agent 反覆逼近規格
Alex Booker 說這是他讀過最清楚的 loop 解釋之一：Ralph loop 反覆用同一份規格啟動 coding agent，但每一輪都給它全新的 context window。重點不是打造複雜 agent swarm，而是讓規格、待辦、檔案系統與 git 成為記憶，讓模型每輪重新讀現況、完成一小步。
Ralph loop 的價值在於簡單，而不是玄學
Ralph loop 常被描述成一個 while loop：每輪把同一份 prompt 或規格餵給 coding agent，讓它讀取目前 codebase、挑下一個任務、完成修改，然後結束。下一輪重新啟動 agent，不沿用前一輪對話歷史，只沿用檔案系統、待辦清單、測試結果與 git history。
這個設計針對的是長對話的品質衰退。當 agent 在同一個 context 裡跑太久，舊工具輸出、過期假設、壓縮摘要與已解決錯誤會一起堆在上下文裡，模型容易變慢、遺忘重點或對已完成狀態產生錯判。Ralph loop 反過來要求每輪都重新讀最小必要資料，讓規格成為來源，而不是聊天紀錄。
每輪重置思考空間
Agent 不背著上一輪的完整對話前進，避免 context rot 與 compaction 後的錯誤摘要污染判斷。
把記憶放在 repo
規格、實作計畫、待辦清單、測試與 git diff 是跨輪狀態；它們比聊天紀錄更容易審查與修正。
靠多輪逼近，而非一輪全包
每輪只做下一個高價值變更，讓 codebase 一步一步靠近規格，而不是期待單次長跑完成全部工作。
一個實用 Ralph loop 需要三種文件，而不是很多框架
最小版本可以很粗糙：一份規格、一份 agent prompt、一個進度檔，再加上一個會反覆呼叫 coding CLI 的 shell loop。更成熟的版本會加上測試門檻、提交策略、成本上限、人工暫停機制與安全邊界，但核心仍然是同一個：每輪 fresh start，每輪讀真實 repo。
定義要收斂到哪裡
寫清楚目標、範圍、非目標、驗收條件、設計約束與不能破壞的行為。規格越清楚，agent 每輪越不需要猜。
拆成可勾選的小任務
每輪讓 agent 選最高槓桿的未完成項目，完成後更新清單。這讓下一輪能從結構化狀態接手。
規定每輪工作方式
要求 agent 先讀規格與計畫、檢查 repo、只做一組明確變更、執行可用驗證，最後記錄結果與剩餘風險。
負責重啟，不負責思考
腳本只做節奏控制：呼叫 agent、限制輪次、遇到失敗時停下或升級處理。不要把核心判斷藏在難審查的 orchestration 裡。
它很適合工程收斂，但不是萬能自動駕駛
Ralph loop 最大的好處，是用低複雜度換到長任務 persistence。它不需要多 agent 協議、不需要巨大的共享記憶系統，也不需要把所有中間推理留在同一段對話裡。這讓它特別適合有明確規格、有測試、有版本控制、有可驗收終點的工程工作。
代價也很明確：每輪都重新讀上下文會花 token；如果規格含糊，agent 只是更穩定地做錯事；如果缺少測試與審查，loop 可能把錯誤越堆越深。因此 Ralph loop 的關鍵不是「無限跑」，而是「在明確界線內重複跑，並讓每輪有可檢查的輸出」。
適合使用
- 大型重構或模組遷移，有清楚完成條件。
- 逐步清空 issue queue、TODO list 或測試失敗清單。
- 需要多輪修正，但每輪都能用測試或 diff 審查。
容易失控
- 需求仍在探索，成功條件無法明確寫下。
- 沒有測試、沒有人工 checkpoint、沒有輪次或成本上限。
- 把網頁內容、錯誤輸出或外部資料當成可執行指令。
要把 loop 跑穩，先把收斂條件寫得像測試
Ralph loop 的工程品質取決於外部結構。好的 loop 會讓 agent 每輪面對同一套事實：規格、限制、目前待辦、最近驗證結果。差的 loop 只是把「再試一次」自動化，最後產生更多需要人收拾的 diff。
給工程團隊的 takeaway
- 01Ralph loop 的核心是 fresh context，不是某個特定外掛或工具品牌。
- 02長任務 agent 最需要的是穩定規格、可檢查狀態與測試門檻，而不是更長的聊天紀錄。
- 03如果工作沒有清楚驗收條件，先讓人類補規格；如果工作有清楚驗收條件，loop 才可能安全地放大產能。