Google Cloud 8 月 21 日整理 DeepMind 的 Intelligent AI Delegation 研究，給多 Agent 系統一個很實用的提醒：會把工作丟給別的 Agent，不等於會管理工作。 任務切得越碎，交接點、權限與錯誤傳播也跟著增加。
我要下的判斷是，企業現在真正缺的是每次交接都能回答「交了什麼、憑什麼算完成、失敗時誰停下來」。增加子 Agent 數量不會自動補上這些制度。A2A 協定可以統一溝通格式；任務契約與責任仍要由部署團隊設計。
四項原則解決四種失敗
第一是可驗證分解。協調 Agent 應把工作拆到可以驗收，而非只把模糊目標改寫成幾段提示詞。報價流程可以分成讀取品項、查價格、檢查折扣與產生草稿；「讓客戶滿意」則沒有單一可驗收答案，應保留人工判斷。
第二是按任務路由成本。格式轉換不必每次叫最強推理模型，薪資與法遵判斷也不該只看最低單價。Google 的框架把模型選擇視為可靠度、延遲與成本的共同決策，方向與小模型 Agent 的角色分工一致。
第三是最小資料揭露。薪資 Agent 委派格式整理時，子 Agent 只需要欄位結構，未必需要員工姓名與完整薪資。把整段上下文複製給每個子 Agent，既增加成本，也放大外洩範圍。
第四是動態質疑。上游要求若含糊、越權或和現場狀態衝突，Agent 要能要求補件或升級人工，而非一路照做。這種刻意增加的摩擦，正是長委派鏈避免錯誤擴散的煞車。
上線前先寫任務契約
挑一個低風險流程，替每次交接寫五個欄位：允許的輸入、期待的輸出、可用工具、驗收方式與中止條件。接著用故意缺欄位、過期資料、權限不足與互相矛盾的指令測試。
紀錄至少要能追到協調 Agent、受派 Agent、使用的模型、工具呼叫與人工核准。若團隊目前連 Agent 清單與責任人都沒有，先做Shadow AI 治理與AI-SPM 資產盤點，再談自動委派。
我不建議用「完成率」單獨驗收。Agent 可能把錯誤工作順利做完。至少分開看任務成功率、人工退回率、越權嘗試、每次成功成本，以及錯誤在哪一段被攔下。
這份研究還不能證明什麼
這是一套委派框架與研究方向，不能直接證明某個商用多 Agent 平台已具備可靠協商、密碼學驗證或安全質疑能力。零知識證明等做法在研究上有吸引力，企業採購仍應以實際產品文件與自己的對抗測試為準。
真正可用的多 Agent 系統，看起來不一定最熱鬧。它通常有較少但責任清楚的角色、窄權限、可重跑的驗收，以及明確的人類接手點。
常見問題
多 Agent 一定比單一 Agent 準嗎？
不一定。專業分工可能改善複雜任務，但交接也會新增理解誤差、延遲與成本。只有子任務可驗收、權限可控時，增加 Agent 才有明確價值。
A2A 能保證委派結果正確嗎？
A2A 解決 Agent 如何發現、溝通與回報任務，沒有替企業定義業務上的正確答案。你仍要建立驗收規則、權限與人工升級流程。
企業第一個多 Agent 試點怎麼選？
選輸入清楚、結果可核對、出錯可回滾的內部流程，例如資料分類後再產生草稿。先避開付款、醫療、解僱與無法撤回的外部操作。