Claude 動態工作流是什麼？AI 代理調度、成本與驗收

Claude Managed Agents 的動態工作流，讓主代理依任務撰寫程式，再由程式分派子任務、收集代理回覆並安排後續步驟。Anthropic 文件寫的「最多啟動 1,000 個代理」，指的是單次工作流整段生命週期的總量，不是 1,000 個代理同時執行。團隊評估這項能力，得先問工作能否切成可獨立檢查的部分，以及產出要如何驗收。

很多人看到多代理協作，第一個想到的是把任務切成更多份，讓工作更快完成。但這裡要先問一個更前面的問題：哪些子任務真的能各自處理、各自驗證，最後還能合併成可信的結果？代理數量只是工作流設計的一個參數，不能單獨代表速度、可靠度或成本效益。

Claude 動態工作流適合哪些可拆分任務？

它較適合有大量邊界清楚子任務、可分開產出結果，且能在最後彙整或複核的工作；若每一步都依賴前一步的完整判斷，增加並行代理未必有幫助。

工作流（workflow）是主代理為特定工作撰寫的調度程式。程式可建立多個代理執行緒（thread），各自帶著任務提示處理一部分工作，然後將結果交回程式。程式能把回覆傳給下一階段，也能依回覆決定重試、補查或結束。Anthropic 官方文件以大量文件審閱為例，說明單次對話難以容納的工作可以交由多個代理處理，再彙整結果。

適合拆分的工作，通常有明確的切割單位，例如逐份檢查合約條款、分模組找程式問題、逐筆分類客服案件，或分別核對報告中的主張與來源。每個子任務要能交付可辨識的結果，例如文件編號、發現事項、證據位置和信心限制。彙整步驟則負責去重、處理互相矛盾的發現，並確認是否漏掉原始任務要求。

相反地，若任務的後續判斷必須等前面一個關鍵答案出現，工作流就需要分階段，而不是同時把所有步驟丟出去。共享程式碼的修改、需要一致全局假設的分析，或每一步會改變下一步問題定義的工作，都可能因切割過細而增加整合成本。規劃時應先畫出依賴關係，再決定哪些步驟能平行、哪些必須依序進行。

1,000 個代理代表工作流總量，不等於同時執行

不能這樣解讀。官方文件列出單次工作流一生最多啟動 1,000 個代理，而同一工作流同時工作的執行緒上限目前列為 64；文件也註明 64 並非保證值，未來可能調整。

「一生最多 1,000 個」是每個 workflow run（工作流執行）從開始到結束累計能啟動的代理數；「同時最多 64 個」才是目前文件列出的單次執行並行量。工作流可分階段重複派工，因此總啟動量會累加。同一個代理若失敗後在新執行緒重跑，執行緒總數甚至可能超過 1,000，但工作流啟動代理的上限仍然是 1,000。

「單一工作流同時工作的執行緒數為 64；API 不保證這個數值，因此可能改變。」— Anthropic Claude Platform 文件（中文譯述）

工作流的預設生命週期為 24 小時，代理也能設定更短的期限。暫停等待使用者或預算處理時，時鐘仍會繼續走，逾時可能以 timeout error 結束。單一 session 預設最多有 10 個開啟中的工作流；這些都是平台目前文件列出的產品限制，不是永久承諾。產品仍處於 beta，部署前要重新核對官方文件和實際方案支援狀態。

把上限當成預估產能會忽略等待、重試、模型速率限制及外部工具耗時。實際可完成的工作量，還取決於工作切分方式、各代理使用的模型、是否需要人類確認，以及每個階段的失敗處理。因此，團隊應先用預期工作負載測量吞吐量，不要把理論上限直接寫進服務承諾或排程估算。

代理數量增加，成本和驗收也要一起設計

應把所有代理的模型用量及 session 執行時間一起計入預算，並用任務自己的品質指標驗收；平台回報工作流已完成，不代表子任務結果正確或完整。

Anthropic 文件指出，工作流本身沒有另外一筆執行費，代理使用的 token 會依各自模型費率計入 session 預算，Managed Agents 也依 session 執行時間計費。

多個代理共用同一 session 預算時，單一子任務沒有獨立的預算上限；工作流達到預算後會暫停等待處理。若沒有設定預算，工作仍可能持續消耗用量，因此應在建立 session 時就決定支出上限，並預留正在執行的請求可能造成的少量超額空間。

Anthropic 對外介紹的找錯測試屬於廠商自行公布的單一程式碼任務結果，尚無獨立研究重現，也沒有足以比較的成本資料。它最多呈現該次測試設定下的結果，不能推論代理數增加會普遍提升可靠度、速度或成本效益。要判斷對團隊是否有價值，還需量測漏報與誤報、模型用量、人工複核時間，以及結果能否重現。

驗收指標應事先寫清楚。像是文件審查可記錄重大條款召回率、誤報率與人工確認時間；程式檢查可看問題是否能重現、修正是否通過測試，以及是否引入新缺陷。比較單代理與動態工作流時，應用同一批輸入、同一套評分規則與可比的模型設定，並記錄 token、session 時間、重試數及人工修正成本。若只看完成時間或代理回報的自評分數，可能把較快但錯誤較多的結果誤判為改善。

「工作流完成，不表示其執行緒上的工作已經通過。」— Anthropic Claude Platform 文件（中文譯述）

共用 sandbox 需要權限、資料隔離與失敗處理

工作流中的代理共用 session sandbox 檔案，且可使用 session 解析出的工具與憑證；導入者需先界定資料可見範圍、檔案寫入規則、工具權限、稽核方式和失敗後的復原責任。

sandbox（受控執行環境）裡的共享檔案能讓代理交換中間成果，也會帶來寫入衝突或讀到其他代理暫存資料的可能。若不同子任務會修改同一份檔案，應改採分開輸出、唯讀輸入或明確的合併步驟，並為衝突設計人工檢查方式。

敏感資料則需先確認部署環境、保留方式與可存取角色是否符合團隊規範。產品文件也指出 Managed Agents session 會在伺服器端保存對話、sandbox 狀態和輸出，且目前不符合 Zero Data Retention 或 HIPAA BAA 資格。

工具、MCP 服務和 session 憑證應依最小權限配置。讀取不可信文件的代理，不必同時擁有修改正式資料或觸發外部交易的權限。較安全的流程是先讓低權限代理讀取和整理，再由具有限定權限的後續步驟處理經確認的結果；所有關鍵工具呼叫都要保留可追查紀錄，記下執行者、輸入、輸出及操作時間。

工作流也可能重跑失敗代理，或為同一工作建立新執行緒。會寄信、開票、更新資料庫或部署程式的工具，若重試會造成重複動作，就要設計冪等性（同一操作重複執行仍只產生一次效果）、去重鍵或人工確認點。失敗處理則要說清楚哪些錯誤可重試、重試幾次、哪些錯誤要停止，以及部分完成時如何回復或交由人員接手。

工程團隊如何用小規模測試判斷是否適用？

先挑結果可獨立驗證、失敗風險可控的一項任務，設定代理與預算上限，再用相同資料比較單代理和動態工作流的品質、用量、耗時、權限邊界與復原結果。

評估可從六個問題開始：任務是否能切成彼此獨立的子工作？各子工作有沒有明確輸入、輸出和檢查標準？同時處理是否真的能縮短等待？預算和時限到達時要如何停止？代理能讀寫哪些資料、呼叫哪些工具？部分失敗或重複操作時，誰負責復原與最後核准？回答不出來時，應先補流程定義，而不是先增加代理數。

試跑時保留單代理作為基準組，固定樣本、提示、模型條件和驗收標準，並納入不同難度的案例。除了平均值，也記錄錯誤分布、最差結果、重跑變異和人工複核成本。若工作流用了較多 token，卻沒有降低漏檢或人工時間，或結果難以追溯，這些都應列為導入成本，而非留給上線後才處理。

動態工作流是否適合，取決於任務可拆分性、並行需求、預算、資料邊界、權限設計和維運能力。工程團隊可先設定代理數與支出上限，盤點共享檔案及工具存取，再用同一批資料比較品質、token 用量、耗時和失敗復原。只有當結果能被獨立檢查、收益足以抵銷協調成本，而且故障時有人能接手，擴大使用才有可判斷的依據。

• 1,000 是單次工作流的代理總啟動量；同時執行緒上限目前列為 64，且可能調整。
• 優先拆分輸入與輸出明確、可獨立驗收的任務，保留彙整和複核步驟。
• 將 token、session 時間、共享資料、工具憑證、重試與人工復原納入試跑評估。

常見問題

Q1：Claude 動態工作流的 1,000 個代理可以同時工作嗎？

不可以把 1,000 解讀為同時執行數。Anthropic 文件目前列出單一工作流同時工作的執行緒上限為 64，且註明 API 不保證這個數值，可能改變。

Q2：工作流顯示 completed，是否代表所有結果正確？

不是。官方文件說明，completed 只表示工作流執行結束；仍需檢查各執行緒的事件、失敗狀況和實際輸出，並依團隊設定的品質標準驗收。

Q3：多代理會比單代理便宜嗎？

無法只憑代理數量判斷。代理 token 依各模型費率計入 session 預算，session 另有執行時間費用；應以相同工作負載量測用量、品質和人工修正成本。

Q4：多個代理會看到同一批檔案嗎？

同一工作流的執行緒會使用 session sandbox 中的同一批檔案。需確認檔案讀寫邊界、敏感資料處理與合併規則，避免衝突或超出預期的資料存取。