迴圈工程 · Loop Engineering 手冊

Agentic Engineering · 給建構 AI agent 的工程團隊

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

迴圈工程是設計 AI agent 執行迴圈的工程實踐。一個 agent 的本質，是一個「蒐集上下文 → 採取行動 → 驗證結果 → 重複」的迴圈。當底層模型能力固定時，迴圈的結構、上下文管理、與收斂條件，決定了 agent 是穩定交付還是空轉燒錢。本手冊把這套實踐拆成三個主題 — 迴圈結構、上下文工程、收斂與控制 — 每個模式都標註用途、風險與適用情境。

迴圈的基本步驟

3 Steps

蒐集上下文 → 採取行動 → 驗證結果，再依結果決定是否續跑。

手冊主題

3 Pillars

迴圈結構 · 上下文工程 · 收斂與控制，對應 agent 從啟動到停機的全程。

收錄模式

16 Patterns

每個模式標註用途、風險與適用情境，可直接對照到自己的 agent 實作。

適用環境

Agent SDK

適用 Claude Code、Claude Agent SDK 及任何自建 agent harness。

01 / 總論 WHAT IS LOOP ENGINEERING

Agent 不是一次性的提問，而是一個會自己跑的迴圈。

定義 DEFINITION

迴圈工程，是設計這個迴圈的每一圈要讀什麼、做什麼、用什麼條件停下來。模型決定單圈能做多好，迴圈設計決定整個任務能不能收斂。本手冊整理的 16 個模式，都是在這三件事上反覆被驗證有效的做法。

迴圈是 agent 的執行單位。

每一圈包含三個動作：蒐集這一步需要的上下文、呼叫工具或產生輸出、檢查結果是否達標。達標就停，未達標就把新結果寫回上下文再跑一圈。設計 agent，本質就是設計這三個動作的內容與順序。

模型能力固定時，迴圈設計是主要槓桿。

同一個模型，配上會自我驗證、會裁剪上下文、有明確停止條件的迴圈，產出品質遠高於「把整段對話一路堆到爆 context」的樸素迴圈。多數 agent 失敗不是模型不夠強，而是迴圈讓它在錯誤的上下文裡空轉。

讓迴圈停下來，比讓它跑起來難。

啟動一個迴圈很容易；讓它在「做完了」時準確停下、在「卡住了」時不要無限重試，才是工程難點。收斂條件、驗證閘門、預算守衛，是把 demo 級 agent 推上生產的關鍵差異。

02 / 迴圈結構 LOOP ARCHITECTURE · 迴圈的基本形狀

迴圈結構 Architecture

決定 agent 每一圈「想什麼、做什麼、如何分工」的骨架：基本 agentic 迴圈、ReAct、先規劃後執行、反思自審、協調者—工作者多代理。

5 Patterns
Single · Multi-agent
執行骨架

01^/05

參考 · Building Effective Agents

基本 agentic 迴圈：蒐集 → 行動 → 驗證

一切迴圈模式的基底：模型在工具回饋的環境中持續自我導航

最小可用的 agent 迴圈只有一圈邏輯：把當前任務與環境狀態交給模型 → 模型決定呼叫哪個工具或產生何種輸出 → 把工具結果寫回上下文 → 檢查是否滿足停止條件，否則再跑一圈。與固定的工作流（workflow）不同，每一步該做什麼由模型在執行期決定，因此具備處理開放式任務的彈性，代價是需要明確的停止條件與護欄。先用這個樸素版本跑通，再按需要疊加後面的模式。

✓ 所有模式的基底 Tool-use loop 動態決策開放式任務

核心 Gather · Act · Verify 適用開放式任務前提明確停止條件

模式 · ReAct（Reason + Act）

在每次行動前，先寫出推理

交錯「思考」與「行動」，讓決策過程留在上下文裡可被檢查

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

Reason→Act→Observe 可除錯減少盲目工具呼叫

節奏思考→行動→觀察取捨 Token 開銷

模式 · Plan-then-Execute

先產出一份計畫，再逐步執行

把長任務拆成「規劃階段」與「執行階段」，降低中途迷路

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

規劃 / 執行分離長任務可重新規劃

階段 Plan → Execute 適用多步依賴任務

模式 · Reflection（自我批判）

產出後再跑一圈自我審查

用「生成 → 評審 → 修訂」的內迴圈提升單次產出品質

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

生成→評審→修訂品質把關需設迭代上限

內迴圈 Generate · Critique 風險不收斂

模式 · Orchestrator–Worker

主迴圈派工，子代理各跑各的迴圈

把可平行、可獨立的子任務交給隔離上下文的 subagent

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

多代理平行上下文隔離扇出 / 彙整

結構協調者 / 工作者適用可平行子任務

03 / 上下文工程 CONTEXT ENGINEERING · 讓迴圈每一圈讀到對的東西

上下文工程

迴圈跑越多圈，上下文越容易膨脹、失焦。這一節是控制「每一圈模型實際讀到什麼」的方法：壓縮、外部記憶、工具結果裁剪、子代理隔離、即時檢索。

5 Patterns
Compaction · Memory
上下文治理

01^/05

主題 · Context Engineering

上下文壓縮：逼近視窗上限前先摘要

長迴圈最常見的失敗點，是上下文塞滿後品質斷崖式下降

迴圈每跑一圈，工具輸出、中間推理、歷史訊息都在累積。當上下文逼近視窗上限，模型不僅變慢變貴，還會開始遺漏關鍵資訊。壓縮（compaction）的做法：在達到門檻時，把前段對話摘要成「已完成的事 + 關鍵決策 + 待辦」，丟掉冗長的原始工具輸出，只保留結論。關鍵是摘要什麼、丟什麼 — 保留決策與未解問題，捨棄可重新取得的原始資料。Claude Code 的自動 compaction 即依此運作。

✓ 長迴圈必備摘要保留決策捨棄原始工具輸出門檻觸發

時機逼近視窗上限保留決策 · 待辦捨棄可重取原始資料

模式 · External Memory

把要記住的事，寫到上下文之外

用檔案或筆記當記憶，跨壓縮、跨工作階段保留狀態

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

檔案即記憶跨壓縮保留 to-do 持久化

載體外部檔案解決易失工作記憶

模式 · Tool Result Curation

工具回傳的東西，不要原封不動塞回去

迴圈膨脹最快的來源，是未經裁剪的工具輸出

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

分頁 / 欄位過濾摘要取代全文回傳引用 ID

原則回傳形狀即介面效果延後視窗上限

模式 · Context Isolation

把髒活外包給子代理的乾淨上下文

用 subagent 隔離大量探索，只把結論帶回主迴圈

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

探索外包只回結論保護主上下文

用途隔離大量探索取捨需充分任務描述

模式 · Just-in-Time Retrieval

需要時才取，而非預先全塞

給 agent 取資料的工具，而不是把所有資料前置灌進提示

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

按需檢索取代前置灌入壓低每圈成本

時機執行期按需前提可靠檢索工具

04 / 收斂與控制 CONVERGENCE & CONTROL · 讓迴圈準時停、不空轉

收斂與控制

把 demo 級 agent 推上生產的關鍵：明確的停止條件、驗證閘門、人為檢查點、預算守衛、可觀測性、錯誤恢復。沒有這一層，迴圈會在該停時不停、該停時亂停。

6 Patterns
Stop · Verify · Guard
生產護欄

01^/06

模式 · Termination Conditions

明確定義「做完了」與「該放棄了」

沒有停止條件的迴圈，不是會空轉，就是會提早交差

每個迴圈都要回答兩個問題：什麼情況算成功完成、什麼情況該停止重試。常見的停止條件包括：通過驗證（測試綠燈、結構符合 schema）、達到迭代上限、連續數輪無新進展（loop-until-dry）、耗盡預算。沒有明確條件時，agent 要嘛在已完成後仍反覆動作，要嘛在第一個看似合理的結果就停。把停止條件寫成可程式判斷的規則，而非交給模型自行感覺，是迴圈可靠的前提。

✓ 迴圈可靠的前提迭代上限 loop-until-dry 可程式判斷

成功條件通過驗證放棄條件上限 · 無進展原則規則化，非靠感覺

模式 · Verification Gates

每一圈的產出，交給可信工具驗證

用測試、type check、schema 校驗當迴圈的真值來源

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

測試 / lint 閘門 schema 校驗獨立查證代理

真值來源工具，非自評失敗時回寫錯誤訊息

模式 · Human-in-the-Loop

在不可逆動作前，把方向盤交回人手

高風險步驟設檢查點，由人確認後迴圈才繼續

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

不可逆動作暫停人為核可節制打斷頻率

觸發高風險 · 不可逆設計只在關鍵節點

模式 · Budget Guards

給迴圈一個硬上限

用 token、步數、時間或金額的上限，兜住失控的迴圈

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

token / 步數上限逼近時優雅收尾無人值守必備

上限 token · 步數 · 時間行為優雅收尾回報

模式 · Observability

每一圈都留下可追溯的紀錄

看不見迴圈在做什麼，就無法判斷它為何失敗

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

逐圈 trace 可回放成本歸因

紀錄輸入 · 呼叫 · 結果用途回放 · 定位偏離

模式 · Error Recovery

把錯誤當成迴圈的輸入，而非終點

工具失敗、輸出不合格時，讓迴圈能退一步重試而非崩潰

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

錯誤回寫上下文有限重試 + 退避區分可否恢復

可恢復迴圈自行修正不可恢復上報並停止

想把 agent 迴圈接上生產環境？

迴圈模式是公開的。
接上生產環境這一段，
是 Tenten 在做的事。

Tenten 是 AI-First 設計與技術顧問公司。我們把 Claude、MCP、Agentic Commerce 接進 Headless CMS、Webflow、Shopify Plus 的企業級交付 — 把這份手冊裡的迴圈模式，落實成跑在你正式 pipeline 上、有驗證閘門與護欄的可靠 agent。

預約 30 分鐘諮詢 → Tenten Awesome List

Tenten 如何協助你建構 agent

Agent 迴圈架構諮詢

依任務類型設計迴圈結構、上下文策略與驗證護欄，建立 CI/CD 部署流程。

Claude Design System Sprint

兩週固定價格，接上 frontend-design + brand-guidelines 到 production。

Agentic Commerce Build

Shopify Plus / Webflow / Headless 遷移，搭配 Claude + MCP 營運層。