Loop Engineering — 迴圈工程 Agent 的產出品質，取決於迴圈怎麼設計。 16 個可落地的 agent 迴圈模式。

ReAct 在每一圈讓模型先產出一段明確的推理（為什麼要呼叫這個工具、預期得到什麼），再執行工具呼叫，然後把觀察結果接回下一輪推理。把思考顯式寫進上下文有兩個好處：降低盲目連續呼叫工具的機率，以及讓除錯時能看到每一步的決策依據。代價是 token 開銷增加，對簡單任務可能過重。

先讓模型針對整個任務產出一份明確的步驟計畫，再由迴圈逐步執行每一步，必要時在某步失敗後重新規劃。對需要多步、有先後依賴的任務，先規劃能固定住整體方向，避免 agent 在中途被局部資訊帶偏。Claude Code 的 plan mode 即是此模式的具體實作：先審計畫、再放手執行。風險是計畫過早定死，遇到執行期才浮現的事實時需要明確的重規劃路徑。

在交付前，讓模型（或另一個扮演評審角色的呼叫）對自己的產出提出具體缺陷，再據此修訂。把生成與評審分成兩個角色，能避免模型對自己的答案過度自信。對程式碼、長文、結構化資料特別有效，因為缺陷通常可被明確指出。務必設上限：固定迭代次數或「連續兩輪無新缺陷即停」，否則容易陷入反覆微調而不收斂。

協調者迴圈負責拆解任務、分派給多個工作者代理、再彙整結果；每個工作者擁有自己獨立的上下文視窗，只回傳結論而非整段過程。這讓主迴圈的上下文保持精簡，並能平行處理彼此無依賴的子任務（如同時審查多個檔案、多角度查證同一主張）。適合「廣度掃描 + 收斂彙整」型任務；不適合子任務間需頻繁共享中間狀態的情形。

上下文視窗是易失的工作記憶，壓縮或重啟後就沒了。把需要長期保留的內容（待辦清單、已確認事實、產出進度）寫進外部檔案，迴圈每圈再按需讀回，就能在不佔用視窗的前提下跨越壓縮邊界。常見實作是讓 agent 維護一份 todo.md 或結構化筆記檔；Claude Code 的 memory 與計畫檔即屬此類。原則：上下文放當前要用的，外部記憶放之後要用的。

一次檔案讀取、API 回應或搜尋結果，可能塞進幾千 token，其中對當前決策有用的往往只有幾行。讓工具層先做裁剪：分頁、只回需要的欄位、用摘要取代全文、對大型結果回傳引用 ID 而非內容本身。設計工具時就把「回傳給模型的形狀」當成介面的一部分，而非把原始 payload 直接倒進上下文。這直接決定迴圈能跑多少圈才撞上視窗上限。

有些子任務（翻遍整個程式庫找某個用法、讀十篇文件抽結論）會產生大量中間上下文，但主迴圈只需要最終結論。把這類工作交給一個子代理：它在自己的視窗裡盡情翻找，主迴圈只收到一段精煉答案，過程不污染主上下文。這與 Orchestrator–Worker 結構互補 — 前者談如何分工，這裡談為何分工：隔離是為了保護主迴圈的上下文預算。代價是子代理看不到主迴圈的全部背景，分派時要給足任務描述。

與其在迴圈開始前把可能用到的文件全部塞進系統提示，不如給 agent 檢索與讀取的工具，讓它在某一圈真正需要時才去拿。這讓上下文只承載「當前這步用得到」的資訊，而非「整個任務可能用到」的全部。即時檢索 + 工具結果裁剪是控制長迴圈上下文成本的主要組合。前提是檢索工具要可靠且可被 agent 正確選用，否則它會反覆取錯資料而空轉。

不要讓 agent 自己宣稱「完成了」就相信。在迴圈中插入確定性的驗證閘門：程式碼任務跑測試與 lint、結構化輸出做 schema 校驗、事實主張交給獨立的查證代理。驗證結果（而非模型的自我評估）才是決定續跑或停止的依據。這把「模型覺得對」轉成「工具證明對」，是 agent 從看起來能用到實際能用的分水嶺。驗證失敗時，把具體錯誤訊息寫回上下文，讓下一圈據此修正。

完全自動的迴圈適合可逆、低風險的任務；一旦涉及刪除資料、發送對外訊息、動用花費或修改生產環境，就該插入人為檢查點：迴圈暫停、呈現它打算做什麼、等人核可後再繼續。設計重點是只在真正需要的節點打斷 — 太頻繁的確認會抵消自動化的價值，太少則放任風險。Claude Code 的權限提示與 plan mode 審核即是此模式：危險動作要人點頭，安全動作放手跑。

自主迴圈最貴的失敗是無聲地燒掉預算：卡在某個無解狀態反覆重試，或在已偏離的方向上越走越遠。設定明確的資源上限 — 最大 token、最大工具呼叫次數、最長執行時間 — 並在每圈檢查；逼近上限時優雅收尾並回報已完成的部分，而非硬切。預算守衛與停止條件互補：停止條件管「做完就停」，預算守衛管「再做下去不划算就停」。對排程或無人值守的 agent 尤其必要。

自主迴圈的失敗往往發生在第幾十圈的某個決策，事後若沒有紀錄就無從重現。把每圈的輸入摘要、工具呼叫、結果、與停止判斷記錄下來（結構化日誌或 trace），讓你能回放整段執行、定位是哪一步開始偏離。可觀測性不改變迴圈行為，但決定了你能不能改進它。對長時間執行、多代理、排程型 agent，這是除錯與成本歸因的基礎設施，不是事後補件。

真實環境的工具會超時、回傳錯誤、給出不合格式的結果。穩健的迴圈把這些當成正常輸入：捕捉錯誤、把錯誤訊息寫回上下文、讓模型在下一圈據此調整（換參數、換工具、或回報無法完成）。配合有限的重試次數與退避策略，避免對同一個失敗無限重撞。關鍵區分：可恢復的錯誤交給迴圈自行修正，不可恢復的錯誤明確上報並停止，而不是讓 agent 假裝成功繼續往下走。