Claude Flows：Anthropic 動態工作流程，千名 AI 代理協作執行任務

Claude Flows：給定目標，千名代理為你執行任務。Anthropic 於 10 月 9 日為 Claude Managed Agents 推出了動態工作流程的公開測試版。其機制看似簡單，但影響深遠：一個主代理會撰寫 JavaScript 程式，在分階段執行中生成多達 1,000 個子代理，其中 64 個可同時運行，並由 Anthropic 的伺服器在背景執行。

你只需啟用一個配置旗標（multiagent_20261001），Claude 便會自行決定何時以及如何使用它。在紐約的 AI 工程師大會上，Anthropic 員工將其稱為「flows」，此名稱隨後在社群中廣為流傳。上週我們報導了此功能發布時的協作工具格局，當時文章探討了 AI 前沿的轉變方向。而本文則提出一個不同的問題：其實際機制是什麼，它是否經得起嚴格檢視？答案比標題所暗示的更為細緻。

為何單一代理會失效？在深入探討其機制之前，了解動態工作流程所解決的問題會有所幫助。Anthropic 自己的部落格文章指出了當你使用單一長上下文視窗時，會出現三種失敗模式。

首先是「代理惰性」，即 Claude 在部分進度後就宣布任務完成，例如在 50 個安全審查項目中只處理了 35 個就聲稱已完成。其次是「自我偏好偏差」，代理傾向於偏好自己的結果或發現，尤其是在被要求根據標準驗證或判斷時。最後是「目標漂移」，在多輪互動中，特別是在壓縮後，對原始目標的忠誠度會逐漸喪失。

這些問題並非理論，任何在複雜程式碼庫上運行過 50 輪 Claude Code 會話的人都曾遇到這三種情況。其中，「代理惰性」尤其陰險，因為代理會自信地報告完成，而你只有在審查時才會發現遺漏。動態工作流程透過將工作分配給具有獨立上下文視窗的代理來解決這些問題。

每個代理都獲得目標的一個有限部分，因此不會有宣告整個任務勝利的誘惑。一個獨立的綜合代理會比較結果，而不會受到其自身產出所帶來的沉沒成本偏見影響。核心洞察是：問題不在於 Claude 無法處理大型任務，而是單一上下文視窗會產生結構性誘因，導致部分完成、自我確認和目標漂移。獨立的上下文視窗則消除了這個結構性問題。

三個基本元素。動態工作流程的核心是一個 JavaScript 檔案。Claude 會為每個任務撰寫一個量身定制的檔案。運行時提供了三個基本元素：agent(prompt, opts) 用於生成一個子代理。prompt 是唯一必需的輸入，選項包括：schema，用於返回經過驗證的 JSON 而非自由文本；model，可為每個代理選擇 Opus、Sonnet 或 Haiku 模型；isolation，可選擇 worktree 或 remote，讓代理能夠並行處理程式碼而不會產生衝突；agentType，用於從你的名單中選擇預定義的代理。

parallel() 則同時分派多個代理，並等待所有結果。這是一種屏障模式，只有當所有並行代理都報告完成後，執行才會繼續。pipeline() 則會依序將每個項目串流通過每個階段，可以將其視為 array.map()，但每個階段都是一個代理呼叫。

這就是整個 API 介面，僅有三個函數。其他所有功能，例如分階段、錯誤處理和資料傳遞，都是標準的 JavaScript。JSON、Math、Array 等都可使用。這個執行框架是一次性的：Claude 會為每個任務撰寫一個新的，並在任務完成後丟棄。

以下是一個簡化的並行安全審計範例：

```javascript

const files = await agent ( " List all API route files " , { schema : { files : [ " string " ] } });

const findings = await parallel ( files . map ( f => agent ( Audit ${ f } for SQL injection and XSS , { model : " opus " , schema : { file : " string " , vulnerabilities : [{ type : " string " , severity : " string " , line : " number " }] } })) );

const report = await agent ( `Synthesize findings and rank by severity:

${ JSON . stringify ( findings )} ` , { model : " opus " } );

```

六種工作流程模式。Anthropic 文件中記載了從這些基本元素中衍生出的六種模式，每種模式都解決了不同的協調問題：

• 分類與執行（Classify-and-act）：將項目路由到專業處理器，適用於混合類型輸入（錯誤、功能、文件）。
• 分派與綜合（Fan-out-and-synthesize）：並行工作、屏障與合併，適用於獨立子任務（檔案審計、研究）。
• 對抗性驗證（Adversarial verification）：第二波代理駁斥第一波代理的結果，適用於高風險決策、程式碼審查。
• 生成與篩選（Generate-and-filter）：產生多個候選方案，選出最佳，適用於創意任務、解決方案搜尋。
• 錦標賽（Tournament）：兩兩評估直到選出贏家，適用於排名、從替代方案中選擇。
• 循環直到完成（Loop until done）：每輪迭代都進行品質檢查，適用於收斂性任務（優化、清理）。

在生產環境中，對抗性驗證模式最為引人注目。它不是讓一個代理審查自己的工作（自我偏好偏差），而是讓第二波代理獨立地嘗試在第一波代理的輸出中找出問題。這正是推動其標題基準測試的關鍵。CJ Avilla 和 Harrison Stall 在 AI Engineer NYC 演講中對 Latent Space 的深入探討，是這些模式在實踐中如何組合的最佳技術分析。

基準測試：70 個錯誤中找出 66 個。Anthropic 的內部測試在一個 116,000 行的程式碼庫中植入了 70 個錯誤。三次運行的結果如下：單一代理分別找到 14、15 和 27 個錯誤（召回率 20-39%，變異性高）；動態工作流程每次都找到 66 個錯誤（召回率 94.3%，變異性接近零）。

一致性與召回率同樣重要。單一代理的性能在不同運行中差異近兩倍，你無法預測會得到找到 14 個錯誤的結果還是 27 個錯誤的結果。而動態工作流程每次都能找到 66 個錯誤。然而，背景資訊很重要，這是 Anthropic 在自己的基準測試中測試自己的功能。

這個程式碼庫是合成的，錯誤是預先植入的，並且沒有公布成本或運行時間數據，目前也尚無獨立的重複驗證。值得注意的是：94.3% 的召回率令人印象深刻，但缺乏數據卻很說明問題。每個工作流程運行消耗了多少 token？成本是多少？如果一個工作流程運行 50 個以上的 Opus 代理，每個都耗盡其完整上下文，那麼每次運行很容易超過 50 到 100 美元。

如果沒有成本分母，66/70 這個數字就沒有意義。而它仍然遺漏的四個錯誤呢？這些才是生產環境中最關鍵的，是那些能經受住所有考驗的錯誤。

兩種運行時，兩種規模。動態工作流程存在於兩個地方，且它們並不完全相同：

• Claude Code（開發者工具）：於 2026 年 5 月 28 日推出（研究預覽版，現已普遍可用）。支援最多 16 個子代理同時運行，每次運行總計最多 1,000 個。觸發方式為在提示詞中使用「workflow」一詞、使用 ultracode 模式，或要求「quick workflow」。運行時為本地 JavaScript 執行，由 Opus 4.8 模型撰寫執行框架。
• Claude Managed Agents（API）：於 2026 年 10 月 9 日推出（公開測試版）。支援最多 64 個代理同時運行，每次運行總計最多 1,000 個。配置方式為 multiagent_20261001 類型，以及 managed-agents-2026-04-01 beta 標頭。運行時為 Anthropic 的伺服器，在背景執行，費用為標準模型 token 費率加上每會話小時 0.08 美元。

API 版本對於生產系統至關重要。以下是其最低配置：

```json

{

"multiagent": {

"type": "multiagent_20261001",

"workflows": {

"type": "enabled",

"inline_agents": {

"type": "enabled"

}

}

}

}

```

你無需發出單獨的 API 呼叫來啟動工作流程，代理會根據你的訊息或系統提示詞決定是否啟動。工作流程的進度會以 workflow_run.* 事件的形式在會話事件流中傳輸。官方文件中的主要限制包括：委派深度僅限一層，子代理無法創建自己的子代理；一個工作流程最多可以列出 20 個預定義代理；運行預設最長可持續 24 小時；一個會話可以同時開啟 10 個運行；代理在運行結束後無法向該運行的執行緒發送後續訊息。

社群的實際看法。Hacker News 上的討論串（200 點讚，135 條評論）比發布文章更具啟發性。社群的意見分為三個陣營。

懷疑論者：成本與控制。 SkyPuncher，最熱門的評論，認為「正確性而非速度才是瓶頸」，並希望有更好的方法來引導長時間會話和注入修正。這點擊中了實際的限制：一旦工作流程啟動，你無法在運行中途進行修正，程式碼已經被提交。Syntaf 報告了最明確的成本數據點：生成 62 個 Opus 子代理在大約 18 分鐘內耗盡了 Max 方案的五小時使用限制。

ncphillips 在大約 90 個代理運行小型套件的程式碼審查後，首次達到了他們的 Max 方案限制。

實用主義者：在有限範圍內有效。 afro88 報告稱「良好的並行化和分階段執行，以及更清晰的上下文視窗，在大型任務上產生了更好的結果。」他們喜歡終端機使用者介面的可見性，但也指出無法在運行中途引導代理。來自 Claude Code 團隊的 bcherny 分享了內部指標：工作流程在重複任務上減少了約 15% 的 token 使用量，並將 Agent SDK 的啟動時間縮短了 61%。這些數據比錯誤偵測基準測試更具可信度，因為它們衡量的是營運改進，而非合成性能。

架構評論者。 vadansky 描述了「混亂債務」（slop debt），即重複的代理傳遞會使程式碼變得更混亂。在他的例子中，模型不斷添加型別轉換和複雜性，而不是建議人類最終看到的型別拆分。tomjakubowski 稱工作流程產生的 Bun Rust PRs 是「他們見過最糟糕的程式碼之一」，並指出測試只是重複了實作。這是任何基準測試都未能解決的品質問題。

這對你意味著什麼：從有限、高價值的任務開始，例如安全審計、依賴項升級、遷移驗證。使用對抗性驗證（推動基準測試數字的模式）。在首次運行前設定會話預算。並且，在沒有人工審查的情況下，不要信任其輸出，尤其是生成的測試。

與替代方案的比較。動態工作流程並非唯一的多代理協作方法。以下是它與領先的協作工具的比較：

• 協作方式： Claude 動態工作流程透過運行時生成的 JavaScript 實現，而 LangGraph 使用靜態圖，CrewAI 採用基於角色的代理，OpenAI Swarm 則透過函數交接。
• 執行框架： Claude 的執行框架是一次性的，為每個任務生成，而其他工具（LangGraph、CrewAI、Swarm）則使用持久的圖、團隊配置或路由。
• 最大代理數： Claude 每次運行最多可達 1,000 個代理，其他工具則無硬性限制。
• 並行性： Claude 在 API 中支援 64 個，CLI 中支援 16 個並行代理；其他工具的並行性則依執行器而定，或預設為循序執行。
• 運行中途引導： Claude 不支援運行中途引導，而所有其他競爭對手都支援。
• 模型鎖定： Claude 動態工作流程僅限於 Claude 模型，而 LangGraph 和 CrewAI 支援任何大型語言模型（LLM），OpenAI Swarm 則僅限於 OpenAI 模型。

一次性執行框架是其關鍵差異點。LangGraph、CrewAI 和 Swarm 都要求你預先定義協作結構，而 Claude 則為每個任務撰寫一個新的。這種權衡的代價是控制性。每個競爭對手都允許你在運行中途進行干預，但動態工作流程不允許。如果計畫有誤，你只能在運行完成後才能發現。對於大規模的代理協作來說，這是一個實實在在的限制。

實際成本計算。目前尚無人發布詳細的成本分析，但我們可以從以下數據點進行推斷：Syntaf 的報告指出，62 個 Opus 代理在 18 分鐘內消耗了 Max 方案的五小時使用量。ncphillips 則在約 90 個代理執行小型程式碼審查後達到了其方案限制。

Anthropic 的範例運行顯示，「review-changes」使用了 14 個代理和 482K token，耗時約 6 分鐘；「deep-research」使用了 22 個代理和 1.1M token，耗時約 11 分鐘。Managed Agents 的定價為標準模型 token 費率加上每會話小時 0.08 美元。

如果每個 Opus 代理使用約 50K token（這對於一個有限的審查任務來說是個保守估計），那麼一個 20 代理的工作流程將消耗 1M token。以 Opus 的費率計算，每次運行的輸入約為 15 美元，輸出約為 75 美元。一個 100 代理的工作流程很容易達到 300 至 500 美元。

這種經濟效益只有在任務值得時才成立。一個能在生產前發現關鍵漏洞的安全審計，花費 300 美元是值得的。但對於一個拉取請求的程式碼審查，使用單一代理可能就足夠了。對於準備整合的團隊，API 的實際應用如下...