核心概念

Claude Code 官方團隊將「循環（Loop）」定義為：代理人重複執行工作週期，直到達到停止條件。這個定義看似簡單，卻對應四種截然不同的架構，選錯會導致 token 浪費或任務無法收斂。

四種循環類型的分類維度有三個：觸發方式（誰啟動這一輪）、停止條件（誰決定結束）、最適任務類型。搞清楚這三個維度，就能在設計 Agentic Workflow 時準確選型。

手動回合式循環（Turn-based Loop）

  • 觸發：使用者每次提示
  • 停止：Claude 判斷任務完成，或需要更多上下文
  • 適用：短任務、非固定流程、探索性工作

這是最基礎的 Agentic Loop，即日常對話互動本身。每次你傳送提示，Claude 就會收集上下文、採取行動、自我核查，然後回傳結果。接著你人工判斷，再寫下一個提示。

提升效率的關鍵在於「把驗證步驟寫成 SKILL.md」——讓 Claude 有具體、量化的完成標準可以自我核查，減少來回回合數。驗證越量化（通過幾個測試、達到某個閾值），Claude 越能自主完成整個迭代。

目標導向循環（Goal-based Loop，/goal）

  • 觸發：即時手動提示
  • 停止：達成目標，或達到設定的最大回合數
  • 適用：有明確可驗證結束條件的複雜任務

當單一回合不足夠，且可以明確描述「完成長什麼樣子」時，/goal 是正確工具。定義成功條件後，每當 Claude 想停止，系統會用一個獨立的評估模型核查條件是否達成——未達成就繼續工作，直到目標完成或達到回合上限。

最適合「通過多少測試」、「達到某個分數門檻」這類確定性條件。模糊的目標（如「做到不錯」）無法讓評估模型有效判斷，效果有限。

時間導向循環（Time-based Loop，/loop 與 /schedule）

  • 觸發：指定時間間隔
  • 停止：手動取消，或工作自然完成（PR 合併、佇列清空）
  • 適用：重複性工作，或需要定期輪詢外部系統的任務

適合兩種場景：一是固定輸入變化的重複任務（每天早上摘要 Slack 訊息），二是依賴外部系統的輪詢任務（PR 收到 code review 或 CI 失敗時反應）。

/loop 在本機執行，關機即停；/schedule 把循環移到雲端，形成常駐任務。兩者的核心差異是可用性，而非功能差異。

主動式循環（Proactive Loop）

  • 觸發：事件或排程，無需即時人工介入
  • 停止：每個子任務達成目標後結束；整體常駐任務持續執行直到關閉
  • 適用：有明確定義的重複性工作流——bug 回報分類、依賴升級、資料遷移

主動式循環是將前三種基本功能組合起來的進階架構。以處理使用者回饋為例，可以這樣組合：

  • /schedule 建立常駐任務定期檢查新回報
  • /goal 定義「完成」的判斷標準
  • 動態工作流（Dynamic Workflow）協調多個代理人分別負責分類、修復、審查
  • auto mode 讓整個流程無需每次確認就能執行

這個層次的設計接近自主 Agent 系統，需要完備的停止條件與回滾機制，否則高度自動化反而會放大錯誤。

關鍵要點

  • 從最簡單開始：不是所有任務都需要複雜循環，Turn-based 先試，有收斂問題再考慮 /goal，有重複性才考慮 /loop
  • 停止條件決定品質：/goal 的成功條件越量化越好，模糊目標讓評估模型無從判斷，容易過早或過晚結束
  • /loop 與 /schedule 的部署差異：/loop 依賴本機，/schedule 是雲端常駐；間隔設定要匹配監控對象的實際變化頻率，不要過度頻繁
  • /usage 監控消耗：/usage 按 skills、subagents、MCP 分類顯示用量；/goal 不加參數顯示當前回合數與 token 消耗；/workflows 可即時停止代理人
  • 確定性工作改用腳本：讓模型推導程式碼的成本比直接執行腳本高得多，重複性且結果可預測的工作應先寫腳本，再讓 Agent 呼叫

實務應用

維持程式碼品質的四個系統設計原則：

  1. 保持程式碼庫乾淨：Claude 遵循已存在的模式與慣例，技術債會傳染給所有 Agent 輸出
  2. 明確記錄「好結果」的標準：用 SKILL.md 把驗證步驟文字化，讓 Claude 能自我核查
  3. 讓文件可取得：框架與函式庫文件須包含最新最佳實踐，過時文件會導致 Agent 採用已棄用的做法
  4. 使用第二個 Agent 做 code review：審查者擁有全新上下文，不受主要 Agent 推理過程影響，可用內建 /code-review skill 或 GitHub Code Review 功能

Token 管控的五個方向：

  • 為任務選合適的模型（簡單任務不需最強模型）
  • 定義清楚的成功條件與停止條件
  • 動態工作流先用小規模試跑再全量
  • 確定性工作改用腳本
  • 不要過度頻繁執行常駐任務

延伸觀點

三篇社群實踐文章（Cobus Greyling、buildtolaunch、sderosiaux on Substack）對以下三點達成一致：

「獨立評估者」是所有高品質循環的關鍵機制。 /goal 的設計核心是由 Haiku 等輕量模型擔任獨立評估者，在每個回合結束後「冷讀」完整 transcript 並判斷目標是否達成——而非讓執行模型自我評分。多篇文章以「不要讓 Agent 批改自己的作業」作為核心原則。這與 AI Agent 工作流的人機分工原則 的人機分工邏輯一致。

生成便宜，判斷昂貴。 隨著 loop 讓代理人可以大量產出，稀缺資源從「生成程式碼」轉移到「決定哪個輸出可以接受」。這代表工程師角色的重心從執行轉向定義目標與驗證標準——在設計循環前先把成功條件寫清楚，比設計循環本身更重要。

選工具前先看失敗成本，而非功能差異。 /loop、/schedule、Cloud Routines 的核心差異是「機器關機時還能不能跑」，而不是功能強弱。實際選型應由失敗後果決定：任務失敗只是少一份報告（任何工具皆可）→ 錯誤資料被寫入（需要人工審核步驟）→ 影響生產系統（需要外部核准流程，如 n8n with approvals）。

此外，多個來源強調狀態持久化是長循環的基礎設施要求：進度必須存在外部檔案而非記憶體，否則重啟後所有上下文丟失，與 Claude Code Routines 雲端自動化排程 中的設計原則一致。

→ 相關頁面：Claude Code 工作流程設定、Claude Code Routines 雲端自動化排程、AI Agent 設計模式、AI Agent 工作流的人機分工原則、Harness Engineering

反向連結

以下頁面引用了本頁：