Skip to main content
Loop Engineering：從 Anthropic、OpenAI、IBM 文件看 Agent Loop 的工程脈絡

Architecture Journal

Last updated on
agentaiagentops

Loop Engineering：從 Anthropic、OpenAI、IBM 文件看 Agent Loop 的工程脈絡

最近大家開始講 loop engineering。它不是另一套 agent framework，而是把工程焦點從「怎麼寫好下一個 prompt」移到「怎麼設計一個讓 agent 持續工作的循環」。這個說法最有代表性的來源是 Addy Osmani 的〈Loop Engineering〉：loop 的重點變成設計一個系統，由它取代你來 prompting agent。[1]

先分清楚三個詞：agent loop 是 agent 實際執行工作的循環；loop engineering 是設計這個循環的工程實務；loop engineer 是負責設計觸發、工作分派、驗證、重試、狀態保存與停止條件的人。

這個轉變的關鍵在於，當 agent 能連續工作數十分鐘、數小時，甚至跨 session 接續任務時，人就不用逐輪手動提示。但工程師得先設計好它何時開始、每輪做什麼、怎麼知道做對了、什麼時候該停。

本文回到 Anthropic、OpenAI、IBM 的官方文件，把 loop engineering 落到具體的工程問題：觸發、停止、排程、事件、狀態、記憶、驗證與治理。Addy 的文章提供 practitioner 側的定義，官方文件提供的是它被實作出來的能力。下面的 pattern 與分類是為了方便讀文件而整理，每一項都附上原始文件，方便回頭對照。

先講結論：Loop Engineering 可以拆成三組可驗證的問題

從這幾條文件脈絡看，loop engineering 至少包含三組問題：

  1. 下一輪怎麼開始：由人、目標條件、時間或外部事件觸發。
  2. 什麼時候停止：由完成條件、驗證結果、grader 或人工 gate 決定。
  3. 跨輪次留下什麼：保存 state、artifacts、memory 與 audit trail，讓後續工作可以接續，也讓發生過的事可以追溯。

後文先看前兩組問題對應的 loop pattern，再補上長時間執行時必須處理的 continuity、memory、eval 與 governance。

Anthropic 文件怎麼描述 agent loop

先看 Anthropic。Claude Code 文件其實已經把 agent loop 講得很清楚。

在〈How Claude Code works〉裡，Claude Code 把自己的工作方式描述成三個反覆循環的階段：gather context、take action、verify results。文件也明講，Claude 會根據前一步拿到的資訊持續重複這個循環，使用者可以中途插手改變方向。[2]

在 Agent SDK 文件裡，Anthropic 又把它說得更工程化：agent 啟動後，系統接收 prompt、評估當前狀態、請求工具呼叫、接收結果，再重複直到任務完成。[3]

Anthropic 真正做的，是把 agent 當成一個可重複執行、可控制、可觀測的 loop。這比「它會呼叫工具」這個說法更值得注意。

從 Anthropic 的產品文件可以看到四種 loop pattern

1. Human-triggered：由人決定下一輪什麼時候開始

這是最基本的 pattern。你下 prompt，agent 開始工作；做完一輪，結果回給你；下一輪要不要繼續，通常還是由你決定。

Anthropic 在 Claude Code 文件裡描述：你給 Claude 一個 task，它進入 gather context / take action / verify results 的循環，你可以隨時中斷與引導，這就是人類逐輪驅動的 loop。[2]

這也是大多數聊天式 agent 最自然的起點。好處是控制感強，代價是 outer loop 還在你身上。agent 會做內部推理與工具循環，但「下一輪要不要開始」常常還是你在決定。

2. Goal-driven：給定完成條件，直到條件成立才停

這一類在 Anthropic 文件裡最明確。

Claude Code 的 /goal 文件直接寫到：你可以設定 completion condition，Claude 會跨多輪持續工作，直到條件成立為止。每一輪結束後，還有一個小模型檢查條件是否達成，沒達成就繼續下一輪。[4]

這就是典型的 goal-driven loop。重點不在「跑很多輪」，而在停止條件被外顯化。它判斷完成的標準，是某個可描述、可驗證的條件是否成立，不是模型自己覺得差不多。Addy 在整理 loop 的 primitive 時也特別指出，/goal 這類「由獨立小模型判斷是否完成」的機制，Codex 與 Claude Code 兩邊都已經內建。[1]

這裡可以接回經典的 agent 分類。IBM 在〈Types of AI Agents〉裡把 goal-based agents 列為五大類之一，定義是 agent 會圍繞一個明確目標做規劃與推理，選擇最有可能讓自己接近目標的行動。[5]

也就是說，goal-driven 在本文同時連到兩個層次：IBM 的 goal-based agent 是 agent 類型；Anthropic 的 /goal 是跨輪執行、以 completion condition 判斷是否停止的產品能力。

3. Time-driven / scheduled：按時間重跑，不等人再問一次

這一類在 Claude Code 也有清楚的產品對應。

在〈Run prompts on a schedule〉裡，Anthropic 把 /loop 定義成按固定時間重跑 prompt，用來輪詢狀態、檢查長時間建置、照顧 PR 或做一次性提醒。文件還特別區分兩件事：

  • /loop 是按時間間隔重跑
  • /goal 是按完成條件持續重跑

這個區分值得留意，因為它代表 Anthropic 已經把「時間驅動」和「目標驅動」視為兩種不同的 outer loop。[6]

同一份文件也說得很清楚：如果你不是想輪詢，而是想在事件發生時立刻反應，就去看 Channels；如果你想讓排程獨立於目前工作階段存在，就使用 Routines。也就是說，時間驅動的 loop 在 Anthropic 的產品實作裡又細分成：

  • session 內的 /loop
  • 本機或雲端持久排程
  • 事件發生時觸發，而不是定時輪詢

4. Event-driven：由外部事件觸發工作

Claude Code 的〈Automate work with routines〉明講，Routines 可以：

  • 按排程觸發
  • 被 API 呼叫觸發
  • 對 GitHub 事件自動反應

而且這些 routine 可以在 Anthropic 管理的雲端基礎設施上持續運作，就算你的筆電關了也能繼續跑。[7]

從這份文件可以直接看到三種觸發方式：定時啟動、API trigger、event-driven trigger。

Agent loop 拉長之後，會連到四個外層問題

一旦 agent loop 不是單輪回覆，而是要長時間持續工作，問題立刻變多。這部分不只 Anthropic 有寫，OpenAI 也已經把其中幾塊拆成正式工程主題。

1. Checkpoint / continuity：不是只保存對話，而是要能接著做

Anthropic 對這件事寫得很實際。

在 Claude Code 的核心文件裡，session 會被保存，工具呼叫與結果會寫入檔案，而且在 Claude 改檔前也會做 snapshot，讓你可以回退。這是 Anthropic 在工作階段層處理 continuity 的方式。[2]

再往長時間 agent 看，Anthropic 在〈Effective harnesses for long-running agents〉裡講得更直接：光靠 context compaction 不夠，長時間 agent 需要把工作切成可接續的增量，留下讓下一輪或下一個 session 能理解的清楚 artifact，不然下一輪只會花很多時間猜前一輪做到哪裡。[8] Addy 把這件事放進 loop 的第六件套件：一個放在 conversation 之外的 memory，它記得做完了什麼、下一步是什麼。因為 agent 每一輪之間會忘，但 repo 不會忘。[1]

所以這裡真正的問題在於三件事：狀態怎麼保存；保存的是原始對話、摘要，還是明確工作產物；下一輪能不能不靠猜測就接手。

2. Memory：把向量搜尋接上去不算做完

OpenAI 在 memory 相關 cookbook 裡講得很清楚，memory 不是單一模型能力，而是整條 orchestration pipeline：包含 distillation、consolidation、injection。

文件特別提醒，memory eval 和一般 model eval 不一樣，因為它有時間依賴：過去的資訊應該在相關時幫上忙，但不該壓過當前使用者意圖。[11]

Anthropic 的 multi-agent research system 文章也提到，長程對話需要 external memory 和 intelligent compression，否則 context window 不夠用。[9]

兩邊的共識很清楚：memory 是獨立的架構層，不是「多塞一點上下文」就結束。

3. Eval：loop 能不能停，不該只靠 agent 自己說了算

這大概是現在 Anthropic 與 OpenAI 文件裡最一致的一點。

Anthropic 的 /goal 文件說，每輪結束後會檢查 completion condition。OpenAI 的 agent eval 文件則把 traces、graders、datasets、eval runs 都明確列成 agent workflow 的正式工具鏈。[4] [10]

OpenAI 特別強調，當你還在 debug agent 行為時，應該先從 traces 開始，因為 trace 會把模型呼叫、工具呼叫、guardrails、handoffs 記下來，讓你看見整條 workflow 到底怎麼跑。等你比較知道「好」長什麼樣，再把這些判準變成可重複的 eval。

這代表 eval 在 agent loop 裡已經不是附屬功能，而是 outer loop 是否可靠的核心。Addy 在 practitioner 側講的其實是同一件事：loop 在無人監督時自己跑，也就會自己犯錯；把 verifier sub-agent 從 maker 分開，目的就是讓 loop 的「完成」有意義。但即便如此，「done」也只是一個 claim，不是 proof。[1]

4. Governance：長時間 agent 的問題，很多時候是邊界，不是能力

Governance 在 OpenAI 和 Anthropic 的文件裡不是抽象口號。

OpenAI 的 agents / eval 文件已經把 governance、compliance、audit events、observability 放進正式文件結構裡。[10]

Anthropic 在提交給 NIST 的 agentic security 意見書裡，則把 persistent memory poisoning 講得很具體：如果錯誤或惡意資訊進入 agent 的長期狀態，它可能在很久之後才拿這些內容去做看起來「很合理」的推理與行動。[12]

這其實點出了長時間 agent 最麻煩的地方：風險會被累積、被延後、被正常化，而且常常不發生在當下那一輪。Addy 對 loop 也有類似的提醒：loop 會加速理解，也可能成為逃避理解的工具。同一套 loop，一個人拿來加速自己已經懂的工作，另一個人拿來避免理解工作本身，loop 自己分不出差別。[1]

把這些 pattern 放回 Loop Engineering

前面的 pattern 可以直接對應到文件裡的產品能力：人類逐輪互動對應 Claude Code 的工作循環；goal-driven 對應 /goal 的 completion condition；time-driven 對應 /loop 與 scheduled tasks；event-driven 則對應 Routines 的排程、API 與 GitHub 事件觸發。

這些 pattern 不是彼此排斥的選項。實際系統通常會把它們組合起來：外部事件或排程啟動工作，agent 在內部反覆呼叫工具，驗證器判斷結果是否達標，state 或 artifact 讓下一輪接續。

Addy 在〈Loop Engineering〉裡把同一個組合整理成五件套加 memory：Automations 負責排程觸發、Worktrees 隔離並行、Skills 寫下專案知識、Plugins / connectors 接上既有工具、Sub-agents 把「提出想法的人」和「檢查想法的人」分開，最後用一個放在 conversation 之外的 state 記住做到哪裡。[1] 這套切法和前面的 pattern 是一體兩面：官方文件描述能力，Addy 描述它們怎麼組成一個能自己跑的 loop。

閱讀或設計一個 loop 時，可以固定檢查三件事：

  1. 誰觸發下一輪：人、目標條件、時間或外部事件？
  2. 怎麼知道該停：完成條件、測試、grader、hook、guardrail 或人工審核？
  3. 跨多輪之後留下什麼：state、artifacts、memory 或 audit trail？

結語：Agent Loop 是 Loop Engineering 的基本單位

從現在 Anthropic、OpenAI、IBM 這幾條文件脈絡看，可以很明確地說：Loop Engineering 的核心，已經轉向把 agent 放進一個可持續執行、可驗證、可停止、可追蹤的 outer loop。

這也解釋了為什麼最近的 loop engineering 討論，會和 long-running agents、harness、eval、memory、observability 同時出現。它們是同一組工程問題的不同切面，不是互相競爭的流行名詞：agent loop 負責工作循環，harness 提供執行環境，eval 與 verifier 判斷結果，state 與 memory 讓下一輪接得起來。Addy 的結論也落在同一個地方：loop 會改變工作方式，但不會把你從工作中刪掉，驗證的責任最後還是在你身上。[1]

把這三組問題想清楚，再去設計或檢視一個 agent loop，會比直接套用任何一套分類更有把握。

參考資料