Skills Atlas · Claude Code Dynamic Workflows
Claude Code · 多代理編排

Dynamic Workflows — 動態工作流腳本編排多個 subagent。
確定性的 fan-out、驗證與合成。

Workflow 是 Claude Code 的多代理編排工具。以 JavaScript 撰寫腳本,用迴圈、條件與 fan-out 把工作分派給數十個 subagent,而非交給單一代理即興處理。腳本決定哪些步驟並行、哪些步驟驗證、哪些步驟合成。

核心原語
5 種
agent、pipeline、parallel、phase、log 組成腳本主體。
並行上限
16
每個 workflow 同時執行的 agent 上限為 min(16, CPU 核心數 − 2)。
生命週期上限
1,000
單一 workflow 累計 agent 數上限,作為失控迴圈的防護。
執行方式
Background
背景執行,完成時送出通知,以 /workflows 即時檢視進度。
01 / 概述 WHAT IT IS · ORCHESTRATION

Workflow 把多代理編排寫成確定性程式

概述 OVERVIEW

一般委派交給單一 agent 即興完成;workflow 則把控制流寫成 JavaScript,由腳本決定 fan-out、驗證與合成的順序。它適用於三種情境:需要全面覆蓋(分解後並行)、需要高信心(多個獨立觀點與對抗式檢查),以及單一 context 裝不下的規模(遷移、稽核、大範圍掃描)。

01

腳本是結構所在。

哪些步驟 fan-out、哪些步驟驗證、哪些步驟合成,都寫在腳本裡。每個 workflow 是一次範圍明確的 fan-out;較大的工作拆成多個 workflow 依序執行。

02

opt-in,不會自動觸發。

workflow 可能產生數十個 agent 並消耗大量 token,因此僅在使用者明確要求時執行:訊息含 workflow 關鍵字、直接要求 fan-out、或呼叫具名或已存的 workflow。

03

結構化輸出免解析。

agent() 加上 schema(JSON Schema)會強制 subagent 呼叫 StructuredOutput 工具並回傳通過驗證的物件,不符時模型自動重試,省去字串解析。

02 / 核心原語 PRIMITIVES · SCRIPT BODY
01

核心原語 Primitives

腳本主體由五個 hook 組成:spawn 單一代理、兩種並行結構、進度分組與訊息輸出。

5 Hooks
agent · pipeline · parallel
phase · log
01/04
agent(prompt, opts) — Spawn 單一 subagent

單一代理的基本單位

不帶 schema 回傳文字;帶 schema 回傳通過驗證的物件

opts 可設 label(顯示名稱)、phase(進度分組)、schema(結構化輸出)、model(模型覆寫)、isolation:'worktree'(獨立 git worktree,僅在 agent 並行改檔會衝突時使用)、agentType(自訂 subagent 類型)。使用者中途略過時回傳 null,以 .filter(Boolean) 過濾。

schema 驗證 worktree 隔離 model 覆寫
Returns text or object Skipped null
02
pipeline(items, ...stages)

無屏障的多階段管線

每個 item 獨立通過所有階段,階段間無屏障

item A 可在第三階段,而 item B 仍在第一階段。這是多階段工作的預設選擇。每個階段 callback 收到 (prevResult, originalItem, index)。某階段拋錯會讓該 item 落為 null 並跳過其餘階段。整體耗時等於最慢的單一 item 鏈,而非各階段最慢值的總和。

預設選擇 無屏障 最慢單鏈
Stages 任意數量 Failure drop to null
03
parallel(thunks)

屏障式並行

並行執行所有 thunk,全部完成後才回傳

屏障:回傳前等待所有 thunk。拋錯的 thunk 解析為 null,呼叫本身不會 reject,使用結果前先 .filter(Boolean)。僅在確實需要同時取得所有結果時使用,例如跨全體結果去重或合併。

屏障 等待全部 null on error
Use when 需全體結果 On error null
04
phase · log · workflow · budget

進度、巢狀與預算

phase 分組進度、log 輸出敘述、workflow 巢狀、budget 控管 token

phase(title) 將後續 agent 歸入進度群組;log(message) 輸出敘述行;workflow(nameOrRef, args) 將另一 workflow 內聯為子步驟(僅一層巢狀);budget 提供本回合 token 目標,可用於依預算動態調整深度。

phase log workflow budget
Nesting 一層 budget token 目標
03 / 動態模式 DYNAMIC PATTERNS · RUNTIME SHAPE
02

動態模式 Dynamic patterns

控制流是真實程式碼,因此編排形狀在執行期依結果調整。以下為常見的品質模式。

4 Patterns
Verify · Loop
Synthesize
01/04
Adversarial verify

對抗式驗證

為每個發現派出多個獨立 skeptic,要求其反駁

每個驗證者被指示嘗試反駁該發現,不確定時預設為「已反駁」。多數反駁則淘汰。可避免看似合理但實際錯誤的發現存活。當一個發現可能以多種方式失效時,給每個驗證者不同視角(正確性、安全性、效能、能否重現)優於相同的重複驗證者。

多數決 預設反駁 視角多樣
Votes N skeptics Survive 多數未反駁
02
Loop-until-dry

掃到無新發現為止

持續派出 finder,直到連續 K 輪沒有新結果

用於規模未知的探索(bug、議題、邊界情況)。以 seen 集合對既有發現去重,連續若干輪沒有新發現才停止。簡單的固定次數迴圈會漏掉長尾。

未知規模 去重 收斂
Stop K 輪無新 Dedup seen set
03
Loop-until-budget

token 預算調整深度

依使用者設定的 token 目標放大或縮小深度

budget.total 為本回合 token 目標(未設定時為 null),budget.remaining() 回傳剩餘額度。可用 while (budget.total && budget.remaining() > 50_000) 動態放大規模;未設目標時 remaining() 為 Infinity,需以 budget.total 守門避免衝到 agent 上限。

動態規模 硬上限 守門
Target token 目標 Guard budget.total
04
Judge panel · Multi-modal sweep

評審團與多模掃描

從不同角度產生多個方案評分合成;多代理各以不同方式搜尋

評審團:從不同角度(MVP 優先、風險優先、使用者優先)產生 N 個獨立方案,以並行評審評分,從勝出者合成並擷取次優者的優點。多模掃描:多個 agent 各以不同方式搜尋(依容器、依內容、依實體、依時間),彼此不知對方所見,適合單一搜尋角度無法找全時。

評審團 多模掃描 合成
Panel N 方案 Sweep 多角度
04 / 執行與續跑 RUN · PERSIST · RESUME
03

執行與續跑 Run & resume

workflow 背景執行,腳本自動持久化,可在暫停或修改後從快取續跑。

4 Topics
Background · Persist
Resume
01/04
Background 執行

背景執行與監看

工具立即回傳 task ID,完成時送出 task-notification

workflow 在背景執行,不阻塞當前回合。以 /workflows 即時檢視進度樹與 log 敘述行。每次呼叫會把腳本持久化到 session 目錄下的檔案,並在結果中回傳該路徑與 runId

背景執行 /workflows task ID
Returns runId + path Watch /workflows
02
Resume

從 runId 續跑

以 resumeFromRunId 重啟,未變動的前綴瞬間回快取

暫停、中止或修改腳本後,以 Workflow({scriptPath, resumeFromRunId}) 重啟。最長的未變動 agent() 呼叫前綴會立即回傳快取結果,第一個被修改或新增的呼叫起才即時執行。相同腳本與相同 args 為 100% 快取命中。

續跑 前綴快取 同 args 全命中
Resume scriptPath Cache unchanged prefix
03
迭代腳本

編輯後再執行

不重送整份腳本,改檔後以 scriptPath 重新呼叫

每次 Workflow 呼叫都會持久化腳本並回傳路徑。要迭代時,以 Write 或 Edit 編輯該檔,再以 {scriptPath} 重新呼叫,而非重送完整腳本。

scriptPath 編輯重跑
Iterate edit file Re-run scriptPath
04
腳本環境限制

純 JavaScript 的約束

純 JavaScript,無檔案系統,部分時間與亂數 API 不可用

腳本是純 JavaScript(非 TypeScript),不可用型別註記。可用標準 JS 內建,但 Date.now()Math.random()、無參數 new Date() 會拋錯(以免破壞續跑)。無檔案系統或 Node.js API。MCP 工具可透過 ToolSearch 取用,schema 依需求逐一載入。

純 JS 無 fs 無亂數
Lang plain JS Tools via ToolSearch
05 / 使用說明書 HOW TO USE · STEP BY STEP

從觸發到續跑的操作流程

Workflow 是 opt-in 工具。以下是從觸發、撰寫腳本、執行到迭代的完整步驟。

01

觸發 workflow

在訊息中包含 workflow 關鍵字,或直接要求「fan out agents」「用 subagent 編排」。也可呼叫具名或已存的 workflow。未明確要求時,Claude 會改用單一 agent 或先詢問。

02

撰寫 meta 標頭

每個腳本以 export const meta = {name, description, phases} 開頭,且必須是純字面值,不可有變數、函式呼叫或樣板插值。phases 的標題需與 phase() 呼叫一致。

03

用原語組合主體

agent() spawn 代理、pipeline() 串接無屏障的多階段、parallel() 做屏障式並行、phase() 分組進度。需要結構化結果時為 agent() 加上 schema

04

背景執行與監看

提交後 workflow 在背景執行,工具立即回傳 task ID 與 runId。以 /workflows 即時檢視進度樹與 log 敘述行,完成時收到 task-notification。

05

讀結果、迭代或續跑

讀回傳結果後,若要調整,編輯持久化的腳本檔(回傳路徑),再以 {scriptPath} 重新呼叫。要從中途續跑,用 resumeFromRunId,未變動的前綴會瞬間回快取。

範例:變更審查 workflow(review → verify)
// 每個維度獨立通過「審查 → 驗證」,階段間無屏障
export const meta = {
  name: 'review-changes',
  description: '審查變更檔案,逐項對抗式驗證',
  phases: [{ title: 'Review' }, { title: 'Verify' }],
}
const DIMENSIONS = [
  { key: 'bugs', prompt: '找出變更中的正確性 bug' },
  { key: 'perf', prompt: '找出效能問題' },
]
const results = await pipeline(
  DIMENSIONS,
  d => agent(d.prompt, { phase: 'Review', schema: FINDINGS }),
  review => parallel(review.findings.map(f => () =>
    agent(`對抗式驗證:${f.title}`, { phase: 'Verify', schema: VERDICT })
      .then(v => ({ ...f, verdict: v }))))
)
return results.flat().filter(Boolean).filter(f => f.verdict?.isReal)
06 / 使用情境 SAMPLE USE CASES

四個可直接套用的編排情境

以下情境取自常見的單階段 workflow 形狀,每個標註所用的原語與模式。

01/04
review → verify

變更審查與對抗式驗證

各維度審查完成即進入驗證,不等全部審完

以 pipeline 讓每個審查維度(bug、效能、安全)獨立通過「審查 → 驗證」兩階段。維度 A 的發現在維度 B 仍在審查時就開始驗證,最後以 verdict 收斂出確認的問題。

pipeline 對抗式驗證 schema
Pattern review→verify Primitive pipeline
02
sweep → synthesize

深度研究的多模搜尋與合成

多角度搜尋 → 深讀來源 → 合成引用報告

以 parallel 同時從不同角度搜尋(依實體、依時間、依來源類型),各自深讀後合成。可加上完整性評論者檢查未涵蓋的模態。

parallel 多模掃描 完整性評論
Pattern sweep→synthesize Primitive parallel
03
discover → transform → verify

大規模遷移的探索、轉換、驗證

找出所有改動點 → 逐點轉換 → 驗證

先內聯偵察出工作清單,再以 pipeline 對每個檔案執行「轉換 → 驗證」。轉換階段以 isolation:'worktree' 隔離,避免並行改檔衝突。

pipeline worktree 逐點驗證
Pattern discover→transform Isolation worktree
04
scan → fix

找出 flaky 測試並提案修復

grep CI 日誌標記 → 每個 flaky 測試一個 agent

第一階段掃描 CI 日誌找出重試標記,第二階段對每個 flaky 測試派出一個 agent 分析並提案修復。屬經典的 scan → fix 兩階段。

pipeline scan→fix
Pattern scan→fix Stages 2
07 / 落地建議 WHEN TO ORCHESTRATE

把 Workflow 變成落地流程

依任務形狀選擇結構。多數情況採混合策略:先內聯偵察出工作清單,再以 workflow 對清單 pipeline。

01 · 何時用 / 何時不用

先判斷任務形狀

需要全面覆蓋、高信心、或超出單一 context 規模時用 workflow。單一事實查詢、已知檔案的小修改則直接處理。對於會受益但使用者未明確要求的任務,先說明 workflow 能做什麼與大致成本,再詢問。

02 · 預設用 pipeline

預設 pipeline,屏障要有理由

只有當第 N 階段需要第 N−1 階段的跨 item 全體結果(去重、合併、零結果早退)時才用 parallel 屏障。「需要先 flatten 或 filter」不構成屏障理由,放進 pipeline 階段內即可。

03 · 審查型流程

review → verify 管線

經典多階段形狀:各維度審查完成即進入對抗式驗證,維度 A 的發現在維度 B 仍在審查時就開始驗證,不浪費 wall-clock。最後以 .filter(Boolean) 與驗證結果收斂。

04 · 不要靜默截斷

邊界要 log 出來

若 workflow 以 top-N、不重試、抽樣等方式限制覆蓋,用 log() 說明被捨棄的部分。靜默截斷會讓人誤以為「全部都看過了」。

想把這些 Skills 接進你的團隊?

Skills 已經開源。
接上 生產環境這一段,
是 Tenten 在做的事。

Tenten 是 AI-First 設計與技術顧問公司。我們把 Claude、MCP、Agentic Commerce 接進 Headless CMS、Webflow、Shopify Plus 的企業級交付 — 讓這份 Skills Atlas 裡每一個好的開源資產,都能真正跑在你正式上線的 pipeline 上。

Tenten 如何部署這些 Skills
Skills 架構諮詢
依團隊與堆疊選出適配 skills,建立 OpenClaw 路由與 CI/CD 部署流程。
Claude Design System Sprint
兩週固定價格,接上 frontend-design + brand-guidelines 到 production。
Agentic Commerce Build
Shopify Plus / Webflow / Headless 遷移,搭配 Claude + MCP 營運層。