同時跑 5–10 個 agent 的停止條件與約束設計：Practical Loop Engineering 實戰拆解

瀏覽次數: 1

本文大綱

一、卡住你的不是算力，是「你同時能寫清楚幾個停止條件」

Google Chrome 團隊的 Addy Osmani 在 2026 年 8 月 14 日發了一篇〈Practical Loop Engineering〉，裡面有句話很實在：他日常有五到十個 agent 同時在跑，但「Very typically I'll max out at about five concurrently」——通常大概五個就到頂了。

到頂的不是 CPU，不是 API 額度，是他自己。因為每多開一個 agent，你就得多維護三樣東西：這個 agent 什麼時候算做完、它不准碰哪些東西、誰來驗它做得對不對。少任何一樣，它產出的東西你最後還是得整份重看一遍，等於沒省到。

所以這篇不打算教你「怎麼一次開很多 agent」（那很簡單，開很多終端機就好），而是教你怎麼讓第三、第四、第五個 agent 跑起來時你可以不盯著。核心就兩件事：停止條件寫得夠硬，跟約束層做得夠死。

二、背景：loop 是什麼，以及官方定義的四種

Claude Code 團隊的 Delba de Oliveira 和 Michael Segner 在 2026 年 7 月 7 日發的〈Getting started with loops〉裡給了定義：loop 就是「agent 重複執行工作循環，直到停止條件被滿足」。他們把 loop 分成四種，差別在誰觸發跟什麼時候停：

類型	誰觸發	什麼時候停	用什麼
Turn-based	你打的每個 prompt	Claude 判斷做完了	手動
Goal-based	你手動起一次	條件達成 or 撞到上限	`/goal`
Time-based	時間間隔	你取消 or 工作完成	`/loop`、`/schedule`
Proactive	事件或排程（沒人在場）	每個任務各自的 goal 達成；routine 跑到被關掉	`/schedule` + `/goal` + skills + workflows

這個分類法的價值不在名詞，在於它逼你先回答「這個 loop 靠什麼停」。這條路往前推很久了——Geoff Huntley 在 2025 年 5 月就寫過 Ralph Wiggum 技巧，本質是一個 bash while 迴圈把同一個 prompt 一直餵給 agent，進度累積在檔案跟 git history 裡而不是在 context window 裡。現在的 /goal 是同一個想法，但把「什麼時候停」從「跑到你按 Ctrl+C」換成「一個獨立的模型判斷」。

三、運作原理：`/goal` 到底在做什麼

這段是重點，因為大部分人寫爛停止條件，是因為不知道 evaluator 看得到什麼。

從 Claude Code 官方文件看，/goal 是一個 session 範圍的 prompt-based Stop hook 的包裝。每次 Claude 跑完一個 turn，Claude Code 會把「你的條件 + 到目前為止的對話」送給你設定的 small fast model（Claude API 上預設是 Haiku；換 provider 的話預設不同），這個 evaluator 回三種判決之一，每種都附一句理由：

Not yet met：Claude 繼續跑下一個 turn，而且會把 evaluator 給的理由當成下一個 turn 的指引
Met：清掉 goal，在 transcript 記一筆 achieved
Impossible：evaluator 判定這條件永遠不可能滿足，清掉 goal，記一筆 failed 並附理由

這裡有個決定性的細節：evaluator 不會呼叫工具。 它不跑指令、不讀檔案，只能判斷「Claude 已經在對話裡呈現出來的東西」。

這一條直接決定你的條件該怎麼寫。「test/auth 底下所有測試都通過」之所以可行，是因為 Claude 會去跑測試，結果會落在 transcript 裡給 evaluator 讀。反過來，「程式碼品質良好」這種條件 evaluator 沒有任何依據可判，它只能猜。

所以一條撐得住多輪的條件，官方文件給的三個要素是：

一個可測量的終態：測試結果、build exit code、檔案數量、queue 空了
講明怎麼證明：「npm test exits 0」「git status is clean」
路上不准變的東西：「不准改到其他測試檔」

條件上限 4,000 字元，一個 session 同時只能有一個 goal。想限制跑多久，就把上限寫進條件本身，例如 or stop after 20 turns——Claude 每個 turn 會回報進度，evaluator 從對話裡判斷。

照著改的停止條件模板

Addy 文章裡那個 /goal 範例基本上就是模板本身：

/goal Refactor the data-fetching layer in Dashboard.tsx until Lighthouse
performance score is >= 92 and LCP is under 1.8s as shown by the Lighthouse
CLI output. Do not change the public API of any hooks. Each turn must improve
at least one reported metric; abort if two consecutive turns show no
improvement. Stop after 10 turns.

拆開看四個零件，缺一個都會出事：

目標 + 數字 + 量測工具：Lighthouse performance >= 92 and LCP < 1.8s as shown by the Lighthouse CLI output。指定量測工具是關鍵，因為那是 evaluator 唯一能看到的證據來源
不變量：Do not change the public API of any hooks
進度條款：Each turn must improve at least one reported metric; abort if two consecutive turns show no improvement。這條是防「原地打轉」用的
硬上限：Stop after 10 turns

Anthropic 官方部落格給的短版是同一個骨架：/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

反例 Addy 也講了：「a vague goal would be『keep going until this UI design is good』. What does that mean?」——這種條件 evaluator 只能亂猜，而它猜錯的方向永遠是「還沒好，繼續」，你的 token 就這樣燒掉了。

三個內建的煞車

官方文件寫得很清楚，值得記起來：

空轉偵測：如果 Claude 連續好幾個 turn 都只回話、沒有任何 tool use，Claude Code 會停下 loop、印警告、把控制權還你，但 goal 仍然保留，你下一個 prompt 之後評估會繼續。Addy 講的失敗訊號是同一件事：「the same command being tried over and over without any change in the result」
四種不可恢復錯誤會直接清掉 goal：認證失敗（Claude Code 自己管憑證時）、額度用盡、auto-compaction 清不掉的 context overflow、模型不可用。警告開頭是 Goal cleared after an unrecoverable error。其他錯誤（rate limit、伺服器過載這類）不清 goal
背景工作會延後評估：subagent 或背景 shell 還在跑時，那個 turn 不評估。等背景工作卡了 30 分鐘會觸發一次 check-in（列出正在跑的任務、叫 Claude 去讀輸出、決定要繼續等還是砍掉），之後每次間隔加倍、上限四倍（預設就是 1 小時後、之後每 2 小時）。用 CLAUDE_CODE_GOAL_CHECKIN_MINUTES 調，設 0 關掉

跑無人值守時記得配 auto mode：/goal 不改權限模式，manual mode 下該問還是會問，你的 loop 會卡在第一個權限對話框。

四、並行的約束層：worktree 不是為了整潔，是為了不用檢查

停止條件解決「什麼時候停」，約束層解決「跑歪的時候傷害範圍多大」。

Addy 的做法是 git worktree 隔離每個平行 agent。Claude Code 現在原生支援：

claude --worktree feature-auth

預設建在 repo root 的 .claude/worktrees/<name>/，開新分支 worktree-<name>，換個名字在另一個終端機再跑一次就是第二個隔離 session。要讓某個 subagent 永遠跑在自己的 worktree，在 .claude/agents/ 的 frontmatter 加一行就好：

---
name: refactorer
description: Applies mechanical refactors across many files
isolation: worktree
---

三個開跑前先做的設定，不做會很煩：

.gitignore 加 .claude/worktrees/，否則主 checkout 會被一堆 untracked 檔案淹掉
建 .worktreeinclude（.gitignore 語法），把 .env、.env.local、config/secrets.json 這類被 gitignore 的檔案自動複製進每個新 worktree。worktree 是乾淨 checkout，沒有這一步你的 dev server 起不來
決定 worktree.baseRef：預設 "fresh" 從遠端預設分支開，"head" 從你當前的本地 HEAD 開。要 agent 接著你手上還沒 push 的工作做，就得設 "head"

隔離不是靠自律，Claude Code 在 worktree session 裡會擋掉四類 tool call：改到主 checkout 路徑的 Edit/Write/NotebookEdit；工作目錄解析到主 checkout 的 Bash/PowerShell/Monitor 指令；透過 git -C、--git-dir、GIT_DIR、GIT_WORK_TREE 或先 cd 把 git 導回主 checkout 的指令；以及它無法靜態驗證會留在 worktree 內的指令形狀——brace expansion、delimiter 沒加引號的 heredoc 都會被拒，而且這一項關不掉。

最後一條是實戰陷阱：你如果習慣叫 agent 用 heredoc 寫檔（cat > file <<EOF），在 worktree 裡會一直被擋。改成 <<'EOF'（引號 delimiter）或拆成分開的指令就好。

第三層：驗的人不能是做的人

Addy 這句是整篇文章最該抄走的一句：「One sub-agent drafts the change. A separate one verifies it.」——不要讓做這份工作的 agent 自己判斷這份工作夠不夠好。

他給 UI 改動的驗證流程可以直接寫成一個 skill：

起 dev server，打開被改的那一頁
直接操作那個改動（點下去、確認狀態有變、截圖）
檢查 browser console，新的 error/warning 必須為零
跑 Chrome DevTools performance trace，看 Core Web Vitals
任何一步失敗，從第 1 步重跑，不准把做一半的東西交回來

Anthropic 官方的建議也是同一句話：把你團隊的驗證步驟寫進 SKILL.md，讓 agent 自己驗，而不是每個 turn 都要人接手。這件事的複利很高——寫一次，之後每個平行 agent 都免費繼承。

什麼委派、什麼要盯

Addy 分三類，這個分法值得照抄：

可以全權委派（前提是停止條件夠清楚）：寫文件、確認測試覆蓋率、例行維護
要盯著看、要 code review：複雜問題、碰到認證／安全／金流的功能、有敏感系統存取權的任務
不要委派：judgment 跟 taste、主觀的設計決策、開放式的創意探索

他自己的說法是：「you are not delegating the taste and the judgment to your agent. You're delegating the task, and then you are actually checking back that it's meeting your bar.」

五、限制與數字（含適用前提）

/loop 的部分，官方文件上這些數字直接影響你怎麼排班：

七天過期：recurring task 建立後 7 天自動過期，最後燒一次然後自刪。這是「避免你忘掉的 loop 一直跑」的保險絲。要更久就取消重建，或改用雲端 Routines／Desktop scheduled tasks
session 範圍：開新對話（含 /clear）會清掉所有 session 範圍的排程；--resume / --continue 會救回未過期的 recurring task
jitter：recurring task 最多延後 30 分鐘才燒（間隔短於一小時的話是間隔的一半），one-shot 排在整點／半點會提早最多 90 秒。時間要準就別排 :00 或 :30，排 3 9 * * * 而不是 0 9 * * *
一個 session 最多 50 個排程任務
不補跑：Claude 忙的時候錯過的觸發不會累積補跑，只會在它閒下來時燒一次
只在 Claude Code 執行中且閒置時會觸發，關掉終端機就停

/loop 給不給 interval 行為完全不同：給了（/loop 5m check the deploy）就是固定 cron；不給（/loop check whether CI passed）Claude 會每輪自己在 1 分鐘到 1 小時之間挑一個延遲，並印出它挑了多久跟為什麼。但這個自選間隔在 Amazon Bedrock、AWS 上的 Claude Platform、Google Cloud Agent Platform、Microsoft Foundry 上不成立——那些平台上沒給 interval 會退回固定 10 分鐘。這點很容易踩到。

至於 Addy 提到的規模數字，要標清楚來源：他說 Agent Skills repo 有 80,000+ stars、以前一天收 80–90 個 PR，這是他自己在文章裡的說法。我 2026 年 8 月 24 日查 GitHub API，addyosmani/agent-skills 是 89,296 stars、113 個 open issue（Anthropic 官方的 anthropics/skills 是另一個 repo，171,201 stars）。PR 流量那個數字我沒有獨立來源可以驗，當作量級參考就好。

另外要老實說：這篇裡「五到十個 agent」「通常五個到頂」是 Addy 的個人工作方式，不是實驗數據，沒有對照組。我自己沒有跑過他那套完整流程，這裡拆的是機制跟可照做的設定，不是效果背書。

六、什麼時候不要用 loop

Addy 的判準很乾脆：「If you don't have a clear idea of what the end-state/done/good means for your completion, it may not be the right pattern.」

具體來說，這幾種情況開 loop 是純燒 token：

終態是主觀的（「這個 UI 設計要好看」）
需要品味或審美判斷
開放式的創意探索
驗證證據落不進 transcript 的任務——這是從 /goal 機制推出來的：evaluator 不跑指令、不讀檔，你的成功條件如果沒辦法讓 Claude 在對話裡「秀出來」，這個 loop 就沒有煞車

反過來，適合的都長一樣：把一個模組遷移到新 API 直到所有 call site 都能編譯且測試通過、實作一份 design doc 直到所有驗收條件成立、把大檔案拆到每個都小於某個行數、把一個貼了標籤的 issue backlog 清空。共通點是終態可以用一個指令的輸出證明。

七、對工程團隊的意義：可以這週就做的四件事

把驗證流程寫成 skill，而不是寫在腦子裡。 挑你團隊最常做的一種驗證（跑測試＋lint＋開頁面點一下），寫成一個 SKILL.md，量化的檢查優先。這是所有平行 agent 的共用地板
給停止條件一個團隊模板。 四個欄位：目標 + 量測工具、不變量、進度條款、硬上限。寫在 CLAUDE.md 裡，讓大家貼上去改就好，不要每次重新發明
把 worktree 設定一次做完。 .gitignore 加 .claude/worktrees/、建 .worktreeinclude、決定 worktree.baseRef。做完之後「開第五個 agent」的邊際成本才會接近零
拆開做的人跟驗的人。 至少讓 draft 跟 verify 是兩個 subagent。這是整套裡投報率最高、最不需要新工具的一招

平行度的真正上限不是機器，是你能同時維護幾組「停止條件 + 約束 + 驗證」。這三樣每寫成一次可重用的資產，你的上限就往上抬一格。

來源

Addy Osmani, Practical Loop Engineering, 2026-08-14 — https://addyosmani.com/blog/practical-loop-engineering/
Delba de Oliveira & Michael Segner (Claude Code team), Loop engineering: Getting started with loops, 2026-07-07 — https://claude.com/blog/getting-started-with-loops
Anthropic, Keep Claude working toward a goal（/goal 機制、evaluator、錯誤處理）— https://code.claude.com/docs/en/goal
Anthropic, Run prompts on a schedule（/loop、七天過期、jitter、cron）— https://code.claude.com/docs/en/scheduled-tasks
Anthropic, Run parallel sessions with worktrees（--worktree、四類隔離檢查、.worktreeinclude）— https://code.claude.com/docs/en/worktrees
Geoffrey Huntley, Ralph Wiggum as a "software engineer" — https://ghuntley.com/ralph/
GitHub API 查詢（2026-08-24）：addyosmani/agent-skills、anthropics/skills star 數