Claude Code loops 的重點，是把一次性的 prompt 改成有觸發條件、停止條件與驗證標準的工作循環；截至 2026 年 7 月，官方文件已把 /goal、/loop、scheduled tasks、routines 與 dynamic workflows 切成不同自動化層級。 對企業和代理商來說，這已超出指令名稱的變化。它把 AI Agent 的管理重心，從寫出更漂亮的提示詞，移到設計「什麼時候開始、什麼時候停、用什麼方式驗證」。
我比較在意的是後半段：token、品質、停損。Agent 一旦可以自己重跑、自己開分支、自己回來修 PR，人類的工作就會變成兩件事。第一，定義邊界。第二，設計便宜、可量化、能重複的驗證方式。這跟 Agentic Coding 時代講的角色轉換一致：工程師越來越像編排者，逐行手敲退到次要位置。
4 種 loop，其實是在分配 4 種責任
Claude Code 官方文件把並行工作拆成 subagents、agent view、agent teams、dynamic workflows；這篇 loop 說明則回答另一個問題：單一任務要怎麼持續推進。兩者接起來看，才會知道該把「下一步」交給誰。
| Loop 類型 | 觸發條件 | 停止條件 | 適合任務 | 成本控制方式 |
|---|---|---|---|---|
| Turn-based | 使用者每次 prompt | Agent 判定完成或需要更多脈絡 | 一次性短任務、探索、局部修正 | 用 skill 固化驗證步驟，減少來回輪數 |
| Goal-based | 使用者設定 /goal |
條件達成，或達到使用者設定的回合上限 | 有明確驗收標準的工作 | 把完成條件寫成測試、分數或檔案狀態 |
| Time-based | 時間間隔 | 使用者取消，或工作完成 | PR 巡檢、CI 觀察、每日摘要 | 拉長間隔，或改用事件觸發 |
| Proactive | 排程或事件 | 單次任務達標；routine 持續到關閉 | issue triage、依賴升級、回饋處理 | 小模型處理例行工作，大模型只做判斷 |
這張表真正有用的地方在於權責清楚，分類只是外殼。Turn-based loop 把檢查留給人；goal-based loop 把停止條件交給模型評估器；time-based loop 把觸發交給時間；proactive loop 把整個提示與觸發方式包成 routine 或 workflow。當一個團隊開始用 agent 處理真實專案，這 4 格會直接影響成本、事故率與交付節奏。
Turn-based loop：先把「人工驗收」寫成 skill
最容易上手的是 turn-based loop。你發一個 prompt，Claude 讀程式、修改、測試，然後回報結果。問題是：如果每一輪都靠人提醒「請開頁面看一下」「請查 console」「請跑效能 trace」，那個人其實還在當排程器。
比較好的做法，是把驗收方法寫進 SKILL.md。原始範例保留如下：
---
name: verify-frontend-change
description: 在声明完成之前，对任何 UI 变更进行端到端验证。
---
# 验证前端变更
不要仅仅因为代码编辑成功，就报告 UI 变更已经完成。要像真人 reviewer 那样验证它：
1. 启动开发服务器，并在浏览器中打开被修改的页面。
2. 直接与变更交互。对于新的控件（按钮、输入框、开关）：点击它，确认预期的状态变化，并截图记录前后对比。
3. 检查浏览器控制台：不能出现新的错误或警告。
4. 使用 Chrome DevTools MCP，运行一次性能 trace，并审计 Core Web Vitals。
如果任何一步失败，修复问题，并从第 1 步重新开始。不要交回只验证了一部分的工作。
Claude Code skills 的商業價值在這裡很明顯：它把「資深工程師腦中的 checklist」變成可重複載入的操作規範。官方文件也指出，skills 只在相關時載入，長篇參考材料平常幾乎不吃 context。對一個月處理數十個網站修改的團隊來說，這比每次重寫 prompt 更接近流程資產。
Goal-based loop：用 /goal 把 done 寫清楚
Goal-based loop 適合有明確出口的任務，例如測試通過、Lighthouse 分數達標、清空 backlog、或把一組 API call site 全部遷移完成。/goal 文件顯示，這個功能需要 Claude Code v2.1.139 以上；每一輪結束後，較小且較快的模型會檢查條件是否成立。條件沒達成，Claude 進下一輪；條件成立，goal 自動清除。
原始範例：
/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.
同一段也保留了中文版本：
/goal 将首页 Lighthouse 分数提升到 90 或以上，最多尝试 5 次后停止。
這句話有兩個值得保留的設計。第一，成功條件明確寫成 90 分以上，避免停在「改善效能」這種模糊要求。第二，最多 5 次，避免 agent 在模糊目標裡燒 token。官方成本文件寫得很直接：Claude Code 依 API token 消耗計費，企業部署平均約 USD 13（約 NTD 416）每位開發者活躍日，月均約 USD 150-250（約 NTD 4,800-8,000）每位開發者。當 loop 會自動跑多輪，停止條件就是成本控制。
Time-based loop：用 /loop 看外部世界，但別讓它變成噪音
Scheduled tasks 文件把 /loop 定義為 session-scoped 的重複 prompt。它可以每 5 分鐘查一次部署、觀察 PR、處理 review comment，也可以讓 Claude 自己選 1 分鐘到 1 小時之間的延遲。固定 interval 的最小粒度是 1 分鐘；同一 session 最多 50 個 scheduled tasks；recurring task 會在建立後 7 天到期。
原始範例：
/loop 5m check my PR, address review comments, and fix failing CI
同一段也保留了中文版本與本機限制提醒：
/loop 每 5 分钟检查我的 PR，处理 review 评论，并修复失败的 CI。
/loop 在你的电脑上运行，所以如果你关机，它也会停止。你可以通过 /schedule 创建 routine，把这个 loop 移到云端。
這類 loop 很好用，也最容易失控。PR 還在 CI 排隊時，每 5 分鐘查一次合理；一個低頻依賴更新檢查若也每 5 分鐘跑，成本和噪音都會被放大。官方文件建議，若工作需要離開當前 session、在筆電關機後仍持續，就改用 routines、Desktop scheduled tasks 或 GitHub Actions。
Proactive loop：routine、workflow 與 code review 才是組織層級的形狀
Proactive loop 的差異在於人不一定在線上。保留下來的操作範例把 /schedule、/goal、dynamic workflows 和 auto mode 組起來，用於回饋處理：
/schedule every hour: check the project-feedback channel for bug reports. /goal: don't stop until every report found this run is triaged, actioned, and responded to. When fixing a bug, use a workflow to explore three solutions in parallel worktrees and have a judge adversarially review them.
同一段也保留了中文版本：
/schedule 每小时：检查 project-feedback 频道中的 bug 报告。 /goal：不要停止，直到本次运行发现的每个报告都已被分类、处理并回复。
修复 bug 时，使用 workflow 在并行 worktrees 中探索三种方案，并让一个 judge 以对抗性方式审查它们。
這個 prompt 可怕之處不在長度，而在它開始像一個小型營運系統：定時查資料、定義完成條件、平行探索三個修法，再要求另一個 judge 做反向審查。Dynamic workflows 官方文件也把用途講得很窄：它適合 codebase-wide audit、500-file migration、cross-checked research 這類一個 conversation 不好承載的工作。v2.1.154 以上才支援 dynamic workflows，Pro 方案還需要在 /config 打開。
這也是 Agent Harness 這類觀念會變重要的原因。模型能力只是底層。真正決定產出的，是外面那層觸發、記憶、工具、權限、review、rollback 和成本儀表板。
原始比較表：選錯 loop，成本會先爆
教學素材最後用一張表收斂判斷。原始表格保留如下，因為它把每種 loop 交出去的責任寫得夠清楚：
| Loop | 你交出去的部分 | 什么时候用 | 该选什么 |
| --- | --- | --- | --- |
| Turn-based | 检查步骤 | 你还在探索或做决策时 | 自定义验证 skills |
| Goal-based | 停止条件 | 你知道什么叫完成时 | `/goal` |
| Time-based | 触发器 | 工作按日程发生在项目外部时 | `/loop`、`/schedule` |
| Proactive | prompt 本身 | 工作是周期性的，而且定义清楚时 | 上面所有能力，加上 dynamic workflows |
臺灣讀者可以把它換成這個判斷表：
| Loop | 交出去的責任 | 適用時機 | 優先工具 |
|---|---|---|---|
| Turn-based | 檢查步驟 | 仍在探索或做決策 | 自訂驗證 skills |
| Goal-based | 停止條件 | 已經知道完成狀態 | /goal |
| Time-based | 觸發器 | 工作按時程發生在專案外部 | /loop、/schedule |
| Proactive | prompt 本身 | 工作週期固定且定義清楚 | 前述能力，加上 dynamic workflows |
我會把它翻成一個更務實的選擇題：你現在最想移交的是「檢查、停止、觸發，還是整個提示」？如果只是想少打一點字，先寫 skill。若完成條件可以量化，才用 /goal。工作來自外部時間或事件，再考慮 /loop 或 /schedule。至於 proactive loop，最好先從低風險任務開始，例如 issue 分類、文件 drift、PR smoke check；別一開始就讓它改核心結帳流程。
對企業導入的 5 個操作建議
| 決策點 | 建議做法 | 可衡量指標 |
|---|---|---|
| 驗證 | 把重複驗收流程寫成 skill | 每次任務少 1-3 輪人工提醒 |
| 停止條件 | /goal 必須含分數、測試或明確檔案狀態 |
每個 goal 都有 pass/fail 證據 |
| 觸發頻率 | /loop 先用 15-60 分鐘，除非真的需要 5 分鐘級別 |
每日 scheduled task 次數 |
| 模型分工 | 例行分類用小模型，架構判斷用高階模型 | 每類任務 token 占比 |
| 審查 | 重要變更交給第二 agent 或 /code-review |
高風險 PR 覆蓋率 |
這裡的商業結構會很快浮現。Agent loop 降低人力切換成本，但會增加 token、審查和治理成本。能賺回來的團隊，通常會避免把 agent 開到最大，改把例行工作壓到便宜模型與 deterministic checks，把高價模型留給判斷、例外和設計。
FAQ
Claude Code loops 跟一般 prompt engineering 差在哪裡？
Prompt engineering 主要優化單次輸入；Claude Code loops 管理的是重複執行。它多了觸發條件、停止條件、驗證與成本邊界。這讓 AI Agent 可以處理跨多輪、跨時間或跨事件的任務。
什麼任務最適合先用 /goal？
先選有明確驗收方式的任務，例如測試通過、Lighthouse 達 90 分、lint 為零錯誤、某個 queue 清空。不要用「把產品做得更好」這種條件。官方文件明確提醒，評估器不會自己讀檔或跑工具，它只能根據對話中 Claude 提供的證據判斷。
/loop 和 /schedule 要怎麼選？
/loop 適合目前 session 裡的輪詢，例如等待 CI、處理 PR review。/schedule 對應 cloud routine，適合筆電關機後仍要跑的週期工作。Scheduled tasks 文件也列出差異：/loop 跑在你的機器、需要 open session；cloud routine 跑在 Anthropic cloud、最小間隔 1 小時。
Proactive loop 會不會讓品質下降？
會，如果沒有驗證層。Loop 本身只保證工作會持續，不保證輸出正確。比較穩的做法，是把每次變更接上測試、截圖、console 檢查、second-agent review 或 managed Code Review，再把失敗案例寫回 skill。
Tenten 會怎麼用這套方法在客戶專案裡？
我們會先把高重複、低風險流程做成 skill 和 /goal，例如廣告素材 QA、網站改版驗收、SEO 技術檢查和文件同步。等驗證指標穩定後，再把部分流程升級成 scheduled task 或 routine，避免一開始就把不可逆工作交給自動化。
權威引用
- Claude Code Docs — Run agents in parallel
- Claude Code Docs — Extend Claude with skills
- Claude Code Docs — Keep Claude working toward a goal
- Claude Code Docs — Run prompts on a schedule
- Claude Code Docs — Orchestrate subagents at scale with dynamic workflows
- Claude Code Docs — Automate work with routines
- Claude Code Docs — Manage costs effectively
Author Insight
我們在導入 AI 開發流程時，最常看到的失敗來自流程錯置：團隊把「跑很多次」誤認成「有流程」。真正有用的 loop 會留下驗證證據、成本紀錄和可回收的操作規範。Tenten 在網站改版、SEO 技術檢查與 AI agent 工作流導入中，已經把這類檢查拆成可重複的驗收步驟。
術語表
| 術語 | 定義 |
|---|---|
| Claude Code loops | 讓 Claude Code 依觸發與停止條件重複工作的模式 |
| Turn-based loop | 使用者每次 prompt 觸發的一輪 agentic work |
| Goal-based loop | 用 /goal 定義完成條件，由評估器決定是否繼續 |
| Time-based loop | 用 /loop 或 scheduled task 依時間間隔重跑 prompt |
| Proactive loop | 由排程、事件或 routine 觸發，無需人類即時在線 |
| Skill | 以 SKILL.md 固化操作規範、檢查流程或工具知識的能力包 |
| Dynamic workflow | 用 JavaScript 腳本編排多個 subagents 的 Claude Code 工作流 |
