Claude 動態工作流程開放測試：多個代理分工，為何仍需要總預算？
Claude Managed Agents 動態工作流程進入公開測試，讓主代理以程式協調多個代理。本文分清子代理與動態流程，解析官方找錯實驗，以及分工、成本與結果覆核的限制。
一個大型任務，常包含很多可以分開處理的小問題。
如果全塞進同一個對話，模型可能需要反覆整理前文與切換焦點。
Anthropic 在 10 月 9 日宣佈，Claude Managed Agents 的動態工作流程進入公開測試。
主代理可以先寫計畫，再讓多個代理分階段處理，最後合併結果。
這增加了平行工作的能力，也帶來重複工作、協調與費用問題。
真正值得評估的是分工後能不能得到更完整、可驗證的答案。
動態流程，和一般子代理有什麼差別？
子代理是主代理直接交辦工作，再讀取回報並決定下一步。
動態工作流程則讓 Claude 撰寫一個程式，在背景組織多個代理與階段，依計畫傳遞內容和合併結果。
官方文件說，前者適合需要持續追問的專家分工，後者適合很多可拆開的工作與長任務。
兩者的限制也不同：文件列出一般子代理同時最多 25 個子執行緒，不能和動態流程的規模混在一起。
官方公告提到動態流程可協調最多一千個代理，這是規模上限，不是每個任務的建議用量。
若任務本身不容易拆開，增加代理可能只會增加重複閱讀與溝通。
找到 66 個錯誤，是哪一種證據？
Anthropic 另外公佈一項測試：在約十一萬六千行程式中放入 70 個錯誤，比較不同處理方式。
單一代理在三輪分別找到 14、15 與 27 個。動態工作流程在三輪各找到 66 個。
這是官方在特定程式庫與測試條件下回報的結果，支持分工可能提高搜尋覆蓋率。
它沒有證明所有程式庫都能找到相同百分比，也沒有表示剩下的問題已經不存在。
如果要導入自己的審查流程，仍需要可重現的問題集，並逐項核對代理的回報。
尤其要區分真正問題、同一問題的多次回報，以及沒有證據的猜測，不能只看留言數量。
分工需要清楚的任務邊界
把同一份模糊指令複製給很多代理，容易產生重複結果。
比較可控的做法，是依資料範圍或問題類型分工，指定每個代理需要回報的證據與不確定性。
例如文件研究可以按來源分配，再由合併階段處理衝突。程式審查則可以按模組分配，保留跨模組問題的整合步驟。
主流程仍要知道哪些任務完成、哪些失敗，以及某個結果是否依賴其他尚未完成的工作。
如果只把所有摘要拼在一起，分工可能增加篇幅，卻沒有增加理解。
所以，合併與覆核是流程中的正式工作，不能留到最後才靠一個籠統指令處理。
規模上限之外，還要設定成本與停止條件
每個代理都會使用模型運算，因此更多平行工作也可能帶來更多費用。
官方文件建議設定工作階段預算，涵蓋其中執行的流程，並指示代理何時適合使用動態工作。
任務也應有明確完成標準，例如回報可核對的問題與引用位置，而不是無限搜尋「還有沒有其他可能」。
遇到外部服務失敗時，系統需要保留部分結果與錯誤狀態，讓使用者知道哪些仍未完成。
動態流程在背景執行，監測階段與執行紀錄也會影響使用者是否能及時介入。
因此，試用應從小而可驗證的分工開始，先比較品質、時間與總成本，再提高規模。
常見問題
一般子代理也能同時開一千個嗎？
不能把兩種上限混用。文件列出子執行緒與動態工作流程各自的限制。
找錯實驗表示代理可以取代所有程式審查嗎？
沒有這個結論。那是特定測試，實務仍需核對問題、測試與修改影響。
什麼任務比較適合？
可拆成明確範圍、能各自提供證據，且有合併方法的工作，通常更容易衡量分工效果。
結語
Claude 動態流程的價值，是把大型工作拆成可協調的階段。先證明小規模分工能提高覆蓋率，再把成本、失敗與覆核納入流程，才能把更多代理變成更好的成果。
延伸閱讀：Every 用 Claude Managed Agents 做公司代理：把共用 Skills 放進 Slack
延伸閱讀：Lovable 接入 Microsoft 企業環境：AI 做出應用後，如何交給公司真正使用
