多代理系統最近很紅，但多數企業真正需要的，不是「更多代理」，而是「更少失控」。能把一個大型語言模型（LLM，能理解與生成文字的模型）接上幾個工具，不等於能把工作穩定做完。單一代理常卡在上下文過長、角色混亂、工具調用失序；多代理看似是解法，但如果沒有任務分工、權限邊界與監控機制，它只會把單點失誤放大成系統性失誤。
我對多代理的基本判斷很直接：它不是「更聰明的聊天機器人」，而是一種新的數位勞動編排方式。真正的價值不在於同時跑幾個 agent（代理），而在於能否把規劃、執行、驗證、交接拆成可管理的流程。這也是為什麼在香港、台灣、新加坡和大中華區的導入現場，我們反覆看到一個現象：企業不是敗在模型不夠強，而是敗在流程沒有被工程化（engineering，變成可測試、可監控、可追責的系統）。
我建議用一個更實用的框架來看多代理：三層價值模型。第一層是「分工」（把複雜任務拆開），第二層是「協作」（代理之間能互相交接與驗證），第三層是「治理」（權限、成本、合規、觀測都可控）。大部分市場宣傳只談第一層，少數團隊做到第二層，真正能進 production（真正對外服務的階段）的，往往卡在第三層。
多代理真的比單代理強嗎？先看任務複雜度，不要看熱度
不是所有場景都適合多代理。對 FAQ 客服、簡單表單填寫、單一步驟摘要，單代理加上檢索增強生成（RAG，先查企業資料再回答）通常已經足夠，而且更便宜、更容易維護。Gartner 在 2024 年多次提醒，生成式 AI（GenAI）專案進 production 的最大障礙，不是模型能力，而是治理、資料品質與系統整合。換句話說，複雜架構不會自動帶來商業價值。
什麼時候多代理開始有意義？通常是三種情境。第一，任務天然跨職能，例如跨境電商營運：一個代理看廣告投放、一個看庫存、一個看物流 SLA（服務水準協議）、一個做價格建議。第二，任務需要互相校驗，例如法務草擬合約後，必須由風險審查代理檢查條款偏差。第三，流程長且容易中斷，例如銀行 KYC（認識你的客戶）與 AML（反洗錢）審查，要在多系統拉資料、比對、升級人工複核。
McKinsey 2023 的研究估計，生成式 AI 每年可創造 2.6 兆至 4.4 兆美元經濟價值；但最大價值往往出現在端到端流程重構，而不是單點自動化。這句話對多代理尤其重要：如果你只是把一個流程切成五個 agent，卻沒有重設責任、例外處理與 KPI（關鍵績效指標），你得到的通常不是 5 倍效率，而是 5 倍排錯成本。
真正的關鍵不是「多個 agent」，而是三層架構有沒有站穩
我把成熟的多代理系統拆成三層：編排層、能力層、治理層。
編排層（orchestration，負責派工與流程控制）決定誰先做、誰後做、何時回退給人。這層像數位主管。常見模式包括主管型（supervisor，一個主代理分派子任務）、流水線型（planner→researcher→writer→reviewer）與黑板型（blackboard，共享任務板，多代理讀寫同一狀態）。能力層是每個代理的專長與工具，例如 CRM（客戶關係管理）查詢、ERP（企業資源規劃）下單、Web 搜尋、文件分析。治理層則是最常被忽略、但真正決定能不能上線的一層：權限控管、審計紀錄、成本上限、資料分級、人工批准閘門。
Stanford 2024 AI Index 指出，企業對 AI 的採用持續上升，但同時對風險管理、透明度與可靠性的要求更高。這正好說明，企業級多代理不是 demo（展示原型）競賽，而是可控系統競賽。在實戰中，我們會要求每個 agent 都有明確的輸入、輸出、工具白名單（允許使用的工具清單）、失敗回報格式；否則一個代理「合理猜測」下一步，就可能在財務、採購或客訴流程造成不可逆錯誤。
協作不是大家一起想，而是誰可以做什麼、做到哪裡
很多人把多代理想成一群 AI 開會。這個比喻有趣，但對落地幫助不大。企業真正需要的不是「討論感」，而是「責任鏈」。有效協作通常包含四件事：任務拆解、共享記憶、交叉驗證、升級機制。
任務拆解是把目標變成可分派的工作單，例如「完成香港與新加坡市場季度銷售分析」拆成資料擷取、清洗、洞察、簡報草稿、管理摘要。共享記憶（shared memory，讓代理讀到同一份任務狀態與上下文）避免重複工作。交叉驗證是讓第二個代理檢查第一個代理的輸出，特別適合法遵、風控、醫療行政等高風險場景。升級機制則是碰到低信心、資料矛盾、超權限操作時，自動轉人工。
Deloitte 2024 在 GenAI 企業導入觀察中提到，多數組織的瓶頸不在模型，而在工作流程改造與信任設計。這與多代理高度一致：如果沒有信心分數（confidence score，系統對自己答案把握度）、審批節點與例外佇列，多代理只會把「看起來自動化」誤當成「已經可營運」。尤其在大中華區常見的跨境供應鏈、雙語文件、不同司法轄區合規要求下，交接失誤的成本遠高於單次模型推論費用。
選框架與平台，別只看酷炫 Demo：你要的是可觀測、可接系統、可算成本
下表不是「誰最好」，而是幫企業分辨不同路線：你是要快速原型，還是要企業級治理？
| 產品/路線 | 定位 | 價格/成本特徵 | 優勢 | 風險/限制 |
|---|---|---|---|---|
| Microsoft Copilot Studio + Azure AI | 企業工作流與 M365 生態整合 | 依授權與 Azure 用量計費；企業通常需搭配既有微軟合約 | 與 Teams、Outlook、Power Platform 整合強，適合大型企業治理 | 靈活度不如自建；跨非微軟系統深度客製成本高 |
| Google Vertex AI Agent Builder | 雲端代理開發與搜尋/RAG 整合 | 依模型、搜尋、向量資料庫與 API 用量收費 | 搜尋、資料連接與模型選擇彈性佳 | 需較強雲架構能力；成本監控要做細 |
| Amazon Bedrock Agents | AWS 內代理編排與工具調用 | 依模型呼叫、代理步驟、雲資源計費 | 適合已在 AWS 的企業，安全與基礎設施成熟 | 初期設計偏工程導向，業務部門較難直接上手 |
| Salesforce Agentforce | CRM 場景中的銷售/客服代理 | 與 Salesforce 授權及用量綁定 | 客戶服務、銷售流程、案例處理整合度高 | 適用場景偏 Salesforce 中心，不一定適合全企業流程 |
| 開源框架（LangGraph、CrewAI、AutoGen） | 快速實驗與客製多代理 | 軟體可低成本起步，但開發、維運、監控另計 | 自由度高，能做複雜編排與自訂治理 | 真正 production 需要補齊觀測、權限、測試、回滾 |
這裡有一個現實判斷：中小企（SME，中小企業）不要一開始就追求「全自動自治代理」。對多數香港、台灣企業，先做「人機協作型多代理」更務實，也就是代理負責蒐集、草擬、比對，人類負責批准、例外與最終決策。IDC 與 Forrester 近年對企業 AI 導入的共同結論都很接近：能持續擴大的專案，通常不是最炫的，而是最容易嵌入既有流程、最容易被稽核與最容易量化 ROI 的。
多代理不是萬能藥：越多角色，越多延遲、成本與責任空窗
這不是說多代理沒有價值，而是說它的成本結構比很多人想像得更重。每多一個 agent，通常就多一次模型呼叫、多一段上下文傳遞、多一個失敗點。a16z 與多家開發者社群在 2024 年對 agentic workflow（代理式工作流）的觀察很一致：可靠性往往不是被模型上限限制，而是被流程複雜度拖垮。
實務上最常見的三個坑。第一，過度拆分：原本兩步能做完，硬切成六個角色，結果 token（模型處理文字單位）成本與延遲大幅上升。第二，權限失控：代理能直接寄信、下單、改 CRM，卻沒有雙重確認。第三，責任模糊：出了錯，無法追到是哪個 agent 用了哪份資料、在什麼提示詞（prompt，給模型的指令）下做了判斷。
尤其在亞太市場，企業常同時面對個資法、金融監管、跨境資料流限制。新加坡 PDPA（個人資料保護法）、香港私隱要求、台灣個資法，以及中國大陸對資料出境的嚴格要求，都意味著多代理若牽涉共享記憶與跨系統調用，就不能只從「能不能做」評估，還要從「資料能否這樣流動」反推架構。
重點帶走：先用「3×3 決策法」判斷你該不該上多代理
我的建議很簡單，用 3 個適用條件 × 3 個治理條件 來判斷。適用條件是：任務是否跨職能、是否需要互相校驗、是否有長流程與高例外率。三項裡面若只有一項成立，通常先別上多代理。治理條件是：是否有清楚權限邊界、是否能完整記錄與追溯、是否設有人類批准閘門。這三項若做不到，再厲害的 agent 也不應直接接上核心系統。
落地順序上，我建議企業走三步。第一步，挑一個高頻、可量化、可容錯的流程做 pilot（試點），例如客服工單分流、銷售報表生成、採購資料比對。第二步，先用兩到三個角色建立最小可行協作（minimum viable collaboration），不要一開始就做十代理系統。第三步，把 KPI 鎖在營運結果，不是模型指標：處理時間縮短多少、人工複核率下降多少、錯誤率是否可控、每單成本有沒有下降。
自我檢查
- 我們想解決的是「流程卡點」，還是只是想展示 AI 很先進？
- 這個流程一旦出錯，誰負責、怎麼追溯、能不能立刻切回人工？
- 若只用單代理加工作流引擎（workflow engine，流程自動化系統）就能做到 80 分，我們為什麼一定要上多代理？
