Claude Code官方解密！一次看懂4種「迴圈」設計法，讓AI Agent自動搞定複雜任務

原文標題：Claude Code官方解密！一次看懂4 種「迴圈」設計法，讓AI Agent自動搞定複雜任務 作者：李先泰 發布時間：2026-07-16T08:00:00+08:00 來源：數位時代 BusinessNext 文章引用的官方來源：https://claude.com/blog/getting-started-with-loops 擷取方式：BusinessNext JSON-LD NewsArticle.articleBody；保留文章主體，正規化版面空白並補上段落標題。

原文擷取

最近 X（原 Twitter）上很流行討論「設計迴圈（loop）」：代理重複執行工作循環，直到滿足停止條件。Claude Code 團隊將分類邏輯整理成四個維度：怎麼觸發、怎麼停止、使用哪一種內建工具或指令，以及適合哪一類任務。文章提醒，不是所有任務都需要複雜迴圈，應先從最簡單的做法開始，再依任務需求升級。

第一種：回合制迴圈

• 觸發方式：使用者輸入一則 prompt。
• 停止條件：Claude 自己判斷任務完成，或需要使用者補充資訊。
• 適用場景：時間較短、不是例行公事或排程的任務。
• 用量管理：把提示寫得更具體，並用 skill 檔加強自我檢查，減少來回輪數。

直接對 Claude 下指令，其實就是回合制迴圈：Claude 收集上下文、採取行動、檢查結果，不足時再修正。文章建議把原本由人手動檢查的步驟寫進 SKILL.md，並提供前端改動的驗收例子：啟動開發伺服器、直接操作改動、拍下操作前後截圖、檢查瀏覽器主控台，以及用 Chrome DevTools MCP 檢查效能與 Core Web Vitals；任一步失敗就修正後重跑。

第二種：目標式迴圈 /goal

• 觸發方式：即時手動下的一句提示。
• 停止條件：目標達成，或達到設定的最高回合數。
• 適用場景：有明確、可驗證完成條件的複雜任務。
• 用量管理：寫出具體完成標準，並設定最多執行幾個回合。

/goal 讓使用者先說清楚「怎樣才算完成」，再讓 Claude 反覆嘗試。每次嘗試結束前會由 evaluator model 檢查條件，未達標就送回重做；因此測試數量、分數門檻等可量化條件通常比模糊形容詞有效。評估模型只看對話中呈現的證據，不會自行讀檔或執行測試，所以 Claude 必須把測試輸出或分數報告放進對話。/goal 不會自動改變權限模式；要完全無人值守仍需搭配 auto mode。

第三種：時間式迴圈 /loop 與 /schedule

• 觸發方式：設定固定時間間隔，或使用雲端排程。
• 停止條件：固定間隔的本機迴圈由使用者手動停止，或建立滿 7 天自動到期；未指定間隔、由 Claude 自行調節節奏的迴圈，可能在工作完成後結束。
• 適用場景：例行重複工作，或需要定期檢查外部系統的任務。
• 用量管理：拉長間隔，或改成事情發生才反應。

/loop 可讓同一句提示按固定間隔重跑，例如每 5 分鐘檢查 PR，有審查意見或 CI 失敗就處理。它在本機與目前 Claude Code session 中執行，電腦與 session 都必須保持運作；最低間隔為 1 分鐘，週期任務 7 天後自動到期。若要讓工作離開本機、在關機後仍持續運作，可用研究預覽階段的 /schedule 常駐排程，由 Anthropic 管理的雲端環境執行；雲端週期最低間隔為 1 小時，且需使用 claude.ai 訂閱帳號登入。

第四種：主動式迴圈

• 觸發方式：事件發生，或排程時間到。
• 停止條件：每項任務達成自己的目標後結束；整套常駐排程由使用者手動關閉。
• 適用場景：持續發生但定義明確的工作串流，例如 bug 回報、issue 分類、系統遷移與依賴升級。
• 用量管理：例行工作交給較小、較快的模型，關鍵決策才使用較強模型。

主動式迴圈讓代理在雲端持續運行，由事件或排程自動觸發，主代理完成並驗證後開啟 PR，再由第二代理進行程式碼審查。它通常由三種原語加上額外能力組成：用 /schedule 建立常駐排程、用 /goal 定義完成條件、用 skill 寫清楚驗證方式，再以 dynamic workflows 編排多個子代理，並用 auto mode 減少不必要的人工確認。文章提醒，實際使用前仍需設定 GitHub／Slack connectors、雲端環境、版本與權限。

迴圈品質與成本邊界

迴圈結果取決於周邊系統，而不只是模型能力。應維持乾淨的既有程式碼、用 skill 固化自我檢查、讓官方文件容易被找到，並安排獨立代理或 /code-review 做審查；失敗後也要把教訓寫回 skill，讓下一輪受益。

迴圈必須有清楚邊界：挑對模型、定義可驗收條件、大量執行前先小規模試跑、把確定性重複工作交給腳本、不要過度頻繁排程，並用 /usage、/goal 與 /workflows 檢視 token 用量。對沒有明確驗收標準、需要每一步人工把關或只是一次性的任務，回合制迴圈加上驗證 skill 往往比堆疊複雜迴圈更划算。

四種迴圈的選擇表

類型	交出去的內容	適用時機	對應指令
回合制迴圈	檢查這一步的動作	仍在探索或尚未決定方向	自訂驗證 skill
目標式迴圈	停止條件	已清楚定義「做完」的樣子	/goal
時間式迴圈	觸發時機	工作在專案之外、按排程發生	/loop、/schedule
主動式迴圈	整句提示本身	工作持續發生且定義明確	以上功能加 dynamic workflows

文章最後建議先挑一項自己是瓶頸的任務，問哪些部分可以交出去、能否寫出驗證標準，以及工作是否本來就按排程進來；先跑一次、觀察卡點與過度擴權，再逐步調整。若任務量不大或涉及敏感資料與對外發布，先使用較簡單的回合制迴圈，不要直接堆疊目標式、時間式與主動式迴圈。

資料來源：Claude 官方部落格〈Loop engineering: Getting started with loops〉、Claude Code 官方 X 貼文、Claude Code 官方文件（/goal、/loop、/schedule、權限模式、Dynamic Workflows、指令與多代理協作）。本文初稿為 AI 編撰，整理．編輯／李先泰。