Claude 的多 Agent 建議：什麼時候該拆任務？

依 Claude 公開的多 Agent 資料整理：用資料污染、真正平行與獨立驗證三個訊號，判斷何時該拆、何時先把單一 Agent 做好。

本文整理 Anthropic／Claude 公開的工程與產品文件，並加入 Gwarket 對可驗證 AI 工作流的分析；不是 Anthropic 官方文件或產品承諾。

最近很多人分享自己的 AI 工作流：一個 agent 做研究，一個寫程式，一個審稿，再由另一個協調前面三個。畫面很像多了一支數位團隊。

但不少人的真實經驗是，agent 開得越多，自己反而越忙。你得分派任務、搬運上下文、確認誰做了什麼，最後還要收拾重複、矛盾或沒有完成的結果。

問題通常不是 agent 不夠多，而是還沒判斷清楚：這件工作到底需不需要拆開。

多 Agent 解決的是協作問題

多 agent 不會自動讓任務變聰明。它處理的是三種特定瓶頸：主工作被大量資料淹沒、工作可真正平行，或不同任務需要不同視角與權限。

如果一份工作必須先讀懂資料，再形成觀點，最後寫成文章，把它硬切給多個 agent 往往不會更快。每次交接都要摘要、重建脈絡與檢查遺漏。Anthropic 也提醒，許多複雜的多 agent 架構最後可被一個工具設計得當的單一 agent 取代；在相近工作上，多 agent 的成本可能高很多。

你正在做提案，卻要同時追查歷史文件、競品資料與既有程式。這時可讓 subagent 深入一條支線，最後只帶回發現、來源、不確定性與對主任務的影響。它不是另一名員工，而是替主工作隔離一條調查支線。

同時盤點三個互不相依的模組，或用三個角度檢查同一份文件，可以平行。若 B 必須根據 A 的結論才知道該做什麼，這仍是順序工作，拆開只會增加交接成本。

高風險工作不該讓同一個 agent 同時產出又判定自己做得對。可讓一個負責形成草稿，另一個只核對來源、限制、格式與完成條件。這不是為了讓流程顯得專業，而是避免同一個系統同時當選手與裁判。

很多工作流一開始就出現「研究 agent、策略 agent、寫作 agent、審稿 agent」。這些名稱聽起來合理，但名稱不是分工本身。

真正的分工要能回答兩件事：這一段工作交給別人後，主工作少了什麼負擔？這個人回來時，交付什麼能被使用的結果？如果答案只是「它會再想一次」，那通常不是值得獨立的一段工作。

以一篇文章為例，研究、判斷與寫作彼此緊密相連。研究時發現資料不足，會改變論點；寫到一半才發現讀者真正的問題，也可能回頭調整研究方向。過早把它們拆開，會讓每個 agent 都只完成自己的局部任務，卻沒有人對整體論證負責。

比較好的拆法是依「交接契約」而不是依職稱。你可以把一段研究支線交出去，但要規定它回來時只帶：來源、可成立的主張、反證或限制，以及尚未回答的問題。主任務拿到的是一個可判斷的 dossier，而不是一大串未消化的筆記。

判斷要不要拆 agent，不必憑感覺。連續做幾次同類任務後，觀察哪一種失敗重複出現：

前面三項才是加 agent 的候選理由。最後一項則是警報：你的交接格式還沒有設計好，不應該再增加角色。

假設你真的需要獨立研究。第一版不必建一個團隊，只要保留一個主 agent，並加一個唯讀研究 subagent。讓它每次都用同一份回傳格式，連續跑幾次後，再看是否真的縮短主工作時間、減少漏項，或提升驗證品質。

如果沒有，就把它收回。這不是失敗，而是證明任務還不值得拆。

多 agent 的最大風險不是技術做不出來，而是人一開始就愛上「看起來像組織」的複雜度。成熟的設計應該能隨時退回更少的角色，而不是越堆越多。

真正值得觀察的不是系統裡有幾個 agent，而是使用者是否更容易做出正確決定。若多了一個 agent 之後，來源更清楚、等待更少、錯誤更早被攔下，才是改善。若只是多了更多狀態、更多訊息與更多需要人工解釋的交接，系統是在消耗注意力。

你可以為任何新增角色寫一張小卡：它接收什麼？不得做什麼？交付什麼？誰驗收？如果寫不出來，代表角色還只是概念，不適合進入流程。

這也是為什麼「先做小、再觀察」不是保守，而是一種更快的學習方式。你不需要先證明自己會管理一群 agent；你需要先證明某個被拆出的步驟，能穩定地為主工作增加價值。

下次想增加 agent 前，先問：主工作是否因資料過量而失焦？工作是否真的互不依賴？結果是否需要可明確說出的獨立驗證？三題都不是肯定，就先把單一 agent 的任務、工具與完成條件設計好。

成熟的 AI 工作法，不是讓畫面同時跑更多 agent，而是讓人不必再當資訊搬運工與錯誤收容員。

先單一 agent；資料污染用 subagent；真正獨立才平行；高風險產出要獨立驗證。