人們不斷問我如何管理編碼代理。這是實際的系統。 核心見解：一次長時間的 AI 編碼會話是脆弱的。它會累積上下文、產生幻覺、停滯不前。因此，我不進行一次馬拉松，而是進行多次短跑。每個代理會話都是全新的，並通過 git 歷史和文件狀態接續上次的工作。 這被稱為“Ralph 循環”。一個包裝腳本不斷啟動一個編碼代理，使用相同的提示，直到工作完成。如果它停滯或崩潰——沒問題。下一次迭代從零開始，沒有任何負擔。 我使用 Opus 4.6 進行規劃——撰寫 PRD、分解架構、定義任務規範。然後 Codex 5.3 負責實際的編碼執行。我們發現這種分工能產生最可靠、高質量的代碼，並且最少需要修復錯誤或後續問題。 我將 PRD 寫成 markdown 清單。循環通過檢查所有框是否被勾選來驗證完成情況。代理聲稱已完成，但仍有 12/47 的任務未完成？重新啟動。不會與困惑的模型進行談判。 代理在 tmux 會話中運行，因此它們能夠在重啟後存活。我通過心跳監控它們——如果有一個死掉了，我會自動重啟它。如果一個停滯（兩次連續檢查的輸出相同），則終止並重啟。 每個 tmux 會話在結尾都包括一個喚醒鉤子：當代理完成時，它會觸發一個事件，立即通知我。沒有靜默完成。我知道工作何時完成，無論我是否在監控。 在好的一天，我會在不同的項目上並行運行 3-4 個代理，每個代理在自己的 git 工作樹中。上週我在大約 4 小時內同時運行了 108 個任務，跨越 3 個項目。 另一個關鍵：測試驅動的提示。我告訴代理先編寫失敗的測試，然後實施。測試是對非確定性工作者的確定性接受標準。大幅減少合併後的失敗。 這不是魔法。這是將過程工程應用於 AI 勞動。清晰的規範、自動化驗證、在卡住時重啟、驗證輸出。 這是我最常被問到的問題之一，所以我打算好好寫一下，並將其作為新章節添加到《如何雇用 AI》中。所有已經購買的人都會獲得更新版本。