Claude Code

Claude Code 官方把 AI Agent 拆成 4 種循環：比 Prompt 更重要的，是停止條件

Anthropic 公開 Claude Code 的 4 種 Loop 設計：Turn-based、Goal-based、Time-based 與 Proactive，整理各自適用情境、驗證方式與 Token 控制重點。

最近 AI 開發圈開始流行一句話：不要只寫 Prompt，要設計 Loop。

問題是，大家口中的 Loop 不一定是同一件事。有人指的是讓 Agent 自己重試，有人指的是排程任務，也有人把多 Agent 協作都算進去。最後很容易變成「自動化程度越高越好」，卻忽略最重要的問題：這個流程到底要在什麼時候停下來？

Claude Code 團隊在 2026 年 7 月 7 日發布的 Getting started with loops 中，第一次用相對完整的框架整理這件事。官方把 Loop 定義為：Agent 重複執行一連串工作，直到符合停止條件。

這次整理真正重要的，不是多了幾個斜線指令，而是 Anthropic 把「誰觸發工作、什麼算完成、誰負責驗證」正式放進 Agent 的設計裡。

從 Prompt Engineering 走向 Loop Engineering，差在哪？

傳統使用 AI 的方式，大多是人類負責推進流程：下指令、等結果、檢查，再根據結果補下一個 Prompt。AI 會做事，但人仍然是那個負責確認狀態、決定下一步的人。

Loop Engineering 想交出去的，不只是某一個步驟，而是流程中的一部分控制權。Anthropic 用 3 個問題區分不同 Loop：

工作如何被觸發？
Loop 在什麼條件下停止？
應該使用 Claude Code 的哪一種機制？

這也是為什麼同一句「幫我持續處理到完成」，可能需要完全不同的做法。臨時改一個按鈕、把測試修到全部通過、每 5 分鐘檢查 PR，以及每天自動分流 Bug，並不是同一種自動化問題。

Claude Code 的 4 種 Loop 怎麼選？

Loop 類型	觸發方式	停止條件	適合情境	Claude Code 機制
Turn-based	使用者下 Prompt	Claude 判斷完成，或需要更多資訊	一次性、較短、仍需人類判斷的工作	一般 Agent 對話、Skills
Goal-based	使用者設定目標	達成目標，或到達回合上限	有明確驗收條件的複雜任務	`/goal`
Time-based	固定時間或間隔	使用者取消，或外部工作完成	定期整理、監控 PR、等待外部系統變化	`/loop`、`/schedule`
Proactive	排程或外部事件	單次任務達標；Routine 持續運作直到關閉	穩定、重複、可清楚定義的長期工作流	`/schedule`、`/goal`、Skills、Dynamic workflows、Auto mode

真正的選擇關鍵不是「哪一種最強」，而是你準備交出哪一種控制權：檢查、停止條件、觸發時機，還是整段流程。

Turn-based Loop：你仍然掌握每一回合

Turn-based Loop 就是多數人現在使用 Claude Code 的方式。你下一個 Prompt，Claude 讀取專案、修改程式、跑測試、檢查結果，再把它認為完成的內容交回來。

這種方法的優點是可控，也最適合探索中的任務。例如需求還沒完全定義、改動範圍不大，或每一輪都需要產品與工程一起做判斷時，保留人工確認反而比較有效率。

Anthropic 建議把重複的驗證流程寫成 SKILL.md。例如 UI 修改不能只看編譯成功，而要啟動網站、操作按鈕、確認狀態變化，再檢查 Console。根據 Claude Code Skills 官方文件，Skill 可以保存檢查表、多步驟流程與支援檔案，並在相關任務中由 Claude 自動載入。

這裡的轉變很實際：你不一定要立刻升級成全自動 Agent，而是先把每次都要提醒的驗收方式寫下來。Loop 還是由人推進，但每一輪的品質會更穩定。

Goal-based Loop：把「完成」寫成可驗證的條件

有些任務不是一個回合就能完成，但你其實很清楚最終要看到什麼結果。這時適合使用 Goal-based Loop。

例如：

/goal 將首頁 Lighthouse 分數提升到 90 以上，最多嘗試 5 次。

依照 /goal 官方文件，Claude 每完成一個回合後，會由另一個較小、較快的 Evaluator model 檢查條件是否成立。如果未達成，就把原因交回主 Agent 繼續處理；達成後才結束 Loop。/goal 需要 Claude Code v2.1.139 或以上版本。

這個設計比「做到最好」或「完成為止」可靠，因為它把模糊期待換成可測量的終點。測試是否全部通過、Build 是否回傳 0、待處理清單是否清空，都比「品質夠好」更適合當停止條件。

不過，目標一定要有上限。官方也建議把回合數或時間限制寫進條件，例如「最多 10 回合」。否則一個寫得不夠清楚、實際上無法達成的目標，就可能讓 Agent 持續消耗 Token，卻沒有更接近完成。

Time-based Loop：工作不是沒做完，而是時機還沒到

另一類任務會卡在外部系統。例如 PR 還在等 Review、CI 尚未結束、Slack 每天都有新訊息，或資料來源會固定更新。這時再怎麼要求 Agent「一次做完」都不合理，因為下一步還沒發生。

Claude Code 提供兩種時間型做法：

/loop：在目前電腦上按照間隔重新執行 Prompt。關閉電腦或結束工作階段後，Loop 就會停止。
/schedule：建立在 Anthropic 雲端運行的 Routine，即使筆電關閉仍能執行。

例如：

/loop 5m 檢查我的 PR，處理 Review 留言並修復失敗的 CI。

根據 Claude Code Routines 官方文件，雲端 Routine 可以由排程、API 呼叫或 GitHub 事件觸發；目前仍屬 Research Preview，功能、限制與 API 介面都可能調整。這代表它已經可以拿來做實際流程，但不適合在缺乏監控的情況下，直接接上高風險權限。

Time-based Loop 的重點不是讓 Agent 更勤勞，而是把檢查頻率設得合理。PR 一小時才可能有變化，就不需要每分鐘查一次。過密的輪詢只會增加 Token、API 與外部服務成本。

Proactive Loop：從定時執行，走向自主工作流

Proactive Loop 是 4 種模式中自動化程度最高的一種。它通常不是單一指令，而是把多個 Claude Code 能力組合起來：

用 /schedule 或外部事件啟動工作。
用 /goal 定義單次任務的完成條件。
用 Skill 保存處理與驗證 SOP。
用 Dynamic workflows 分配多個 Agent。
用 Auto mode 讓流程不必逐次等待工具權限確認。

官方舉的例子是每小時檢查專案回饋頻道，把新 Bug 完成分流、處理與回覆；修 Bug 時，還可以在不同 Worktree 中平行探索 3 種解法，再由另一個 Agent 做對抗式 Review。

依照 Dynamic workflows 官方文件，這類工作流會把編排邏輯放進可重複執行的 JavaScript 腳本，適合大型稽核、數百個檔案的 Migration，或需要多個來源交叉驗證的研究。目前 Dynamic workflows 需要 Claude Code v2.1.154 或以上版本，仍不該被理解成「任何任務都要開多 Agent」。

對團隊來說，Proactive Loop 的價值是把穩定、重複的工作變成持續運作的系統；風險也在同一個地方。如果停止條件、權限範圍與驗證流程沒寫清楚，錯誤會跟著自動化一起放大。

Agent 能跑多久，不等於工作品質有多好

Anthropic 在文章後半特別提醒，Loop 的輸出品質取決於周邊系統，而不是 Agent 願意跑幾個回合。

第一，專案本身要乾淨。Claude 會沿用既有程式碼的命名、架構與慣例；混亂的 Codebase 也會被放大。

第二，驗證要能被 Agent 執行。與其寫「確認畫面正常」，不如定義要開哪一頁、操作什麼、檢查哪個狀態，以及失敗後如何重跑。

第三，高風險變更要有獨立 Reviewer。Anthropic 建議讓第二個 Agent 在新脈絡中檢查結果，降低主 Agent 對自己解法過度有信心的問題。Claude Code 的 Code Review 也採用多 Agent 分析與後續驗證來過濾誤報。

真正值得注意的不是「AI 可以自己做多久」，而是它失敗時，系統能不能看得出來。

如何避免 Loop 變成 Token 黑洞？

Loop 一旦開始自動重試或開出多個 Agent，成本很容易從「多跑幾次」變成「同時跑很多條工作流」。Anthropic 提出的控制方式很務實：

先用最簡單的模式。 短任務不需要多 Agent，能用 Turn-based 解決就先不要升級。
寫清楚完成與停止條件。 除了成功標準，也要設定回合數、時間或預算上限。
先小規模試跑。 Dynamic workflow 可能產生大量 Agent，先拿少量檔案或單一 Queue 測試。
確定性工作交給 Script。 固定格式轉換、表單填寫與資料清理，不必每次都讓模型重新推理。
不要過度輪詢。 檢查頻率應該跟外部資料實際變動速度一致。
定期查看用量。 /usage 可拆解 Skills、Subagents 與 MCP 的使用量，/goal 與 /workflows 也能查看目前回合與 Token 消耗。

這套原則也說明了一件事：Loop Engineering 並不是把 Prompt 寫得更長，而是把成功條件、失敗處理與成本邊界設計得更清楚。

不只寫程式，內容與營運流程也能套用

雖然原文聚焦 Claude Code，但這個分類也能拿來檢查一般 AI 工作流。

例如寫一篇科技新聞時，Turn-based 適合先做一次研究與草稿；如果要求「所有重要說法都有官方來源、圖片已標示出處、檢查清單全部通過」，就接近 Goal-based；每天固定抓取消息並整理成待審稿件，屬於 Time-based；若還要自動去重、查證、分配不同 Agent 審稿，再交給人類決定發布，就逐漸走向 Proactive。

差別不在於行業，而在於流程是否足夠穩定、輸入是否可取得，以及結果能不能被驗證。

哪一種 Loop 最適合開始？

如果目前仍在探索需求，先使用 Turn-based，並把最常重複的檢查寫成 Skill。

如果你已經能清楚說出「什麼狀態代表完成」，再使用 /goal。如果工作是固定發生，或必須等待外部系統變化，才考慮 /loop 或 /schedule。

Proactive Loop 應該是最後一步。當流程已經跑過多次、例外情況可預期、權限能縮到最小，而且有獨立驗證者時，自動化才真的能省下人力。否則只是把尚未整理好的流程，交給 AI 更快地重複。

常見問題

Claude Code Loop 是什麼？

Claude Code 團隊將 Loop 定義為 Agent 重複執行工作週期，直到符合停止條件。不同 Loop 的差異，在於觸發方式、停止條件，以及使用的 Claude Code 機制。

`/goal` 和一般 Prompt 有什麼不同？

一般 Prompt 完成一個回合後，Claude 可能直接把結果交回來。/goal 則會在每回合結束後，交由另一個 Evaluator model 檢查目標是否達成；未達標就繼續工作，直到條件成立或到達你設定的上限。

`/loop` 和 `/schedule` 有什麼差別？

/loop 在目前電腦與 Session 中按照時間間隔重跑 Prompt；/schedule 建立雲端 Routine，即使筆電關閉也能執行，並可搭配排程、API 或 GitHub 事件觸發。

Loop 是否會消耗更多 Token？

會。重試回合、多 Agent 與過密排程都會增加用量。建議設定明確成功條件與上限，先以小範圍試跑，並把可預測的步驟改成 Script。

所有任務都適合做成 Proactive Loop 嗎？

不適合。仍在探索、驗收方式不清楚，或涉及高風險外部操作的任務，保留人工確認通常更安全。Proactive Loop 比較適合穩定、重複、可以驗證，而且權限範圍明確的流程。

結語：先設計「怎麼停」，再談讓 AI 自己跑

Anthropic 這次提出的 4 種 Loop，替 AI Agent 自動化補上了一個常被忽略的問題：人類究竟把哪一段責任交出去？

最實際的起點不是建立一個永遠運作的 Agent，而是先找出自己最常卡住的一個步驟。你是否一直在重複同一種檢查？完成條件能不能量化？工作是否真的需要定時觸發？

當這些答案變清楚，Prompt 才會開始變成流程；而一個能被驗證、能在正確時間停止的流程，才有資格被自動化。