先拆解任務，再決定要不要 multi-agent：AI 系統的架構取捨

一位老會員寄來一封信：「最近搬家了，麻煩把我這筆還沒出貨的訂單收件地址改成新地址，順便確認一下如果改錯了還能不能退換貨。」

把這句話丟給一個只接了大型語言模型（LLM，能讀懂自然語言並生成文字的模型）的客服機器人，多半會得到一段語氣客氣、卻沒解決問題的回覆：它讀懂了情緒，卻碰不到訂單資料庫，查不到此刻生效的退換貨政策，更不可能真的去改訂單、寄確認信。

這種回覆有個技術上的名字：open-loop（開迴路）回覆，系統沒有外部工具可動、沒有環境回饋可讀，只能憑模型內部知識生成一段話，走不完「動作，看結果，再修正」這個閉迴路。同樣一段需求，為什麼有的 AI 系統只會說漂亮話，有的卻能把事情辦完？差別不在模型有多大，而在系統設計者有沒有先做一件最基礎、卻常被忽略的動作：把任務拆解（task decomposition）清楚，再決定每一步交給誰、用什麼工具、要不要動用多個 agent。這篇就從技術角度把這條鏈講清楚：任務怎麼拆、每一步配什麼工具與檢驗、MCP 的角色、什麼時候該上 multi-agent，以及更難的問題，什麼時候不該上。

我們為什麼在乎先拆解這件事

91APP CDMP 團隊每天面對的是品牌客戶的真實需求，而非論文裡的玩具題目：會員改地址、退貨進度查詢、訂單異常通知、活動資格判定。共同點是聽起來像一句話，做起來卻是一條流程。

我們踩過的坑很具體：一開始想用「一個夠聰明的模型」解決所有事，結果模型在不該猜的地方猜（編造訂單編號）、在該查資料的地方憑印象答（背出過期的退貨政策）。後來才認清，起點是先把任務拆對。拆對了，每一步都能單獨被檢驗、替換、授權；拆錯了，整條鏈會在看不見的環節默默出錯。「資料底座要先就位、模型才接得上事實」的教訓，我們在 AI agent 的數據底座 裡也談過，它是本文所有步驟的前提。

把一句話的需求，拆成一串可被檢驗的步驟

拆解任務最可靠的起手式，是先看一位資深真人客服怎麼處理改地址：先確認本人、調出訂單、看還能不能改、改下去、確認政策、寫信、寄出。AI 系統要做的，就是把這些動作各自獨立，配上最適合的工具。

值得先點破一個常被略過的事實：改地址不是純查詢，而是一個會寫進資料庫、影響真實出貨的動作（side-effect）。凡是會改動真實資料的步驟都得先過身分驗證與授權，拆解後的骨架中間必須有一道驗證與授權閘門。

下面這張表是同一個需求拆解後的骨架：

這張表看起來樸素，關鍵在於把「一個模型猜全部」變成「每個專責環節各做一件事」。職責單一就能被單獨驗證；任何一步出錯，都看得出是哪一步。

逐步說明背後的關鍵判斷：

1. 抽資訊用 LLM，只負責聽懂、不碰資料庫，把信裡的意圖整理成結構化欄位（會員 ID、訂單編號、動作＝改地址）。要注意一個強假設：真實信件常沒有可驗證的訂單編號，也不確定寄件人本人；拿不到可驗證的身分時，流程只能進入驗證分支，不能憑信件內容就去查、去改。
2. 查可否修改並更新地址，是整條鏈風險最高的一步，因為要寫入資料。設計上先問訂單狀態允不允許改（已出貨就不行），允許才寫入，寫完還要回讀確認。這一步必須走有權限控管的授權工具，不可讓 LLM 自己決定要不要寫；高風險動作即使技術上能執行，也該設一道核可閘門（approval gate）。
3. 查政策用 RAG（Retrieval-Augmented Generation，檢索增強生成，先去外部撈相關段落，再讓模型根據撈到的內容回答），因為退換貨政策會更新，寫死在模型參數裡等於鎖進一份會過期的文件。但 RAG 只保證去撈，不保證撈回來就是最新最對的版本，得接一個帶版本與生效日的政策資料源，回覆時附上版本與生效日，多版本衝突轉人工。RAG 的原始概念由 Lewis 等人 2020 年提出（Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020, arXiv:2005.11401），主張把模型內建的參數記憶與外部可更新的非參數記憶結合，資料新不新取決於資料源的治理。
4. 送出用發送工具，不是讓模型假裝寄出。交易型通知還要處理重送，寄送工具要帶 message_id、重試策略與寄送紀錄，避免確認信因流程重跑寄好幾遍。

這串步驟裡藏著一個易被忽略的判斷：LLM 出現兩次，但任務相反。抽資訊要收斂，把散漫的自然語言壓成幾個準確欄位；起草回信要發散，把冰冷的事實展開成一封有條理的信。職責不同，就該是兩個獨立、可檢驗的環節。

拆到這裡還少了一塊：每一步都要套上 eval（evaluation，對系統輸出設計的檢驗與監控機制），它是讓這條鏈持續可信的安全帶，可以是離線標準答案集、程式斷言、人工抽審加上線上監控，高風險步驟更要程式規則加人工覆核。要每步各驗，而不是只驗最後一封信，因為錯誤會沿著鏈往下傳，越往後越難看出根因。假設抽資訊那步把會員 ID 抽錯，後面查到別人的訂單，最後生成的信卻通順得體，只看最後一步很可能判它合格，但地址早已改錯。所以更新地址那步要做狀態一致性檢查（沒拿到 update_success=true 就不准生成「已完成」），錯誤才會在當下被攔下。沒有 eval，這條鏈第一天能跑，第三十天悄悄壞掉也不會有人知道。

「把難題拆成由淺到深的子問題、再依序解決」這個思路，學界也有旁證。Zhou 等人 2022 年提出的 least-to-most prompting（由淺到深提示法），在符號操作、組合泛化與數學推理任務上證明，先分解再循序求解能解出比示範例子更難的題目（Zhou et al., Least-to-Most Prompting Enables Complex Reasoning in Large Language Models, 2022, arXiv:2205.10625）。要提醒的是，這只是提示技巧層次的旁證，工程流程的可靠度終究得靠工具回傳、權限控管與 eval 來保證。

一個情境，看懂為什麼不能一步到位

假設我們偷懶，只給模型一段超長指令：「你是客服，請讀這封信，幫客人改地址並回信。」模型沒有資料庫權限，於是要嘛禮貌地請客人自行至會員中心修改（沒解決問題），要嘛更糟，自信地回覆「已為您將訂單 #88231 的地址更新完成」，而這個編號是它編出來的；政策同理，它會背出一版聽起來合理、其實早已改過的規則。

換成拆解後的版本：抽資訊那步發現信裡沒訂單編號、也無法確認本人，於是不硬編，而是觸發驗證分支查未出貨訂單；更新地址那步先檢查狀態再寫入、回讀確認；查政策那步用 RAG 撈今天生效的版本。每一步都被 eval 盯著，狀態一致性檢查會擋下「已完成」這種還沒成功就報喜的句子。

兩個版本的差別，不在模型聰不聰明，而在系統設計者有沒有承認：有些事實只能查不能想，有些動作只能執行不能描述，且其中有些即使能執行也得先核可。拆解就是把想和查、描述和執行、執行和核可分到不同環節，各用各的工具。這也是為什麼把資料底盤從 CDP 升級成 CDMP 這麼關鍵：當 agent 要查的事實散落在各自為政的系統裡，再好的拆解都接不上料，這個資料困局我們在 Agentic Commerce 資料困局：CDP 升級成 CDMP 裡有完整討論。緊接著的問題是：查訂單、查物流、查庫存這些步驟，要怎麼穩定接上後端？這就帶到 MCP。

MCP：讓 agent 不必認識每一個後端的通用插頭

上面第二步說用 MCP 接資料庫，這裡把它的角色講清楚。

先看沒有 MCP 的世界。一個 agent（能感知、決策並呼叫工具去完成任務的 AI 系統）若要查訂單、查物流、查庫存，傳統做法是替每個後端各教模型一套呼叫方式，每接一個新系統就要再寫一份客製化對接，系統一多就成了維護地獄。

MCP（Model Context Protocol，模型脈絡協定，一套讓 AI 應用與外部資料、工具溝通的開放標準）是一個 client-server 協定：agent 所在的應用扮演 MCP client，去連接一個個 MCP server，由 server 把訂單 API、資料庫查詢這些後端能力包裝成標準介面。Agent 不必替每個後端各寫一套接法，它透過 MCP client 用同一種方式呼叫不同的 server，就像出國帶一個萬用插頭，不必為每個插座各買轉接頭。Anthropic 在 2024 年 11 月開源 MCP 時，正是把它定位成「取代零散整合的單一通用標準」，連接 AI 系統與資料源、工具（Anthropic, Introducing the Model Context Protocol, 2024）。

對拆解後的客服流程來說，MCP 讓查訂單這一步用統一方式接上資料庫，不必為這個專案寫一套只能用一次的對接。要補一句免得誤會：MCP 的核心定位是工具與資料存取的介面，不是專給 agent 對 agent 溝通的協定。你可以把某個 agent 包成 MCP server 讓別的 agent 當工具呼叫，但真要做 multi-agent 協作，通訊、狀態、權限與追蹤還得另外設計。

當任務可平行或要跨場景重用時，才需要 multi-agent

到目前為止，改地址這個需求其實一個 agent 配上拆好的步驟就能解決。那 multi-agent（多個 agent 協作完成任務的架構）什麼時候才該登場？

表象上，很多人以為多個 agent 一定比一個強。這是誤區，多一個 agent 不會自動變聰明。導入 multi-agent 的理由不只一種，常見的有平行化、專家分工、獨立審查、動態拆派與可重用元件，每一種都該用延遲、成本、準確率與可追蹤性評估。這裡聚焦兩個最好判斷的：

1. 平行處理。需求換成「規劃一趟出差」，要同時訂機票、找飯店、查天氣，三件事彼此不相依，同時做總時間趨近於最慢的那一件。但平行不必然要動用 multi-agent，若只是固定的幾個獨立子任務，一個 orchestrator 在一條 workflow 裡同時發出幾個工具呼叫就夠了；只有子任務需要各自維持長期狀態、各有獨立策略，才值得升級成多個 agent。
2. 高可重用性。一個做好的查訂單能力，行銷部、產品部、客服流程都要用，做成能被重複呼叫的元件比各做一個划算。但可重用的能力不一定要包成 agent，只是查詢或更新做成工具或 service 更輕，需要自主判斷、維持狀態或跨流程協調才值得包成。

機制上，multi-agent 分兩種架構，差別在 agent 怎麼溝通：

1. 階層式（hierarchical）。有一個總管（orchestrator，負責拆派與彙整的協調者），把子任務派給底下的 agent，再把結果整合成回覆。使用者只跟總管對話，上下文集中、入口單一，較容易給出一致回覆。這正是 Anthropic 在 2024 年「Building Effective Agents」描述的 orchestrator-workers 樣式（Anthropic, Building Effective Agents, 2024）。代價是總管集中所有訊息，可能成為延遲瓶頸與單點失效。
2. 扁平式（flat）。沒有總管，agent 透過約定的介面直接水平溝通，把彼此當工具呼叫。少了中間轉一手，省溝通成本、反應更直接。代價是 agent 一多，誰呼叫誰會變複雜，行為較難追蹤。

底層原理上，這是老問題的新版本：集中協調對上分散協作，沒有哪種絕對較好，怕失控就集中，怕遲鈍就分散。學界對 multi-agent 的協作機制與適用邊界這兩年有系統性整理（Tran et al., Multi-Agent Collaboration Mechanisms: A Survey of LLMs, 2025, arXiv:2501.06322），這份綜述也誠實把協調成本、錯誤沿鏈傳遞與評估困難列為待解挑戰。換成白話：多請幾個顧問開會不保證決策更好，反而可能因協調成本上升、責任互相推諉而更糟。複雜度本身有成本，好處要大過混亂才划算。

決策清單：先拆解，再判斷要不要 multi-agent

把上面的原理收斂成可執行的判斷順序，面對新需求照這清單走：

1. 先拆解，不要先選架構。把需求拆成抽資訊、驗證授權、查資料、查政策、生成、執行這類獨立步驟，看清楚職責；沒拆清楚之前，討論要不要 multi-agent 都太早。
2. 每一步問四件事：用什麼工具、會不會更新（會更新的用 RAG）、要不要授權（改動真實資料設核可閘門）、怎麼檢驗（這步的 eval）。
3. 預設只用一個 agent，把它加拆好的步驟當基準線。
4. 需要平行時先想 workflow，彼此不相依的子任務在一條 workflow 裡並行呼叫工具就好，需要各自維持狀態或獨立策略才升級成多個 agent。
5. 需要跨場景共用一個能力時先想工具，只是查詢或更新就做成工具或 service，需要自主判斷或跨流程協調才包成 agent。
6. 真要 multi-agent 才選架構：重視入口單一、需要集中控管選階層式，重視溝通成本低選扁平式。
7. 永遠不要過度設計（overdesign）。這是整份清單最該刻在心上的一條：單一 agent 能解決的事就別硬上 multi-agent。Anthropic 在「Building Effective Agents」反覆強調的也是同一件事：先找最簡單的解法，只在需要時增加複雜度。

看一個落地的例子。91APP CDMP 團隊在替品牌設計會員旅程自動化時，遇過想一口氣上一整組 agent 的衝動：受眾、內容、通路、成效各一。照清單一走才發現，多數情境其實是一個 agent 配上拆好的步驟（抽出活動目標、用 RAG 撈當期優惠規則、用授權工具圈出受眾、再生成訊息）就辦完了，根本不需要四個 agent 互相溝通。真正值得拆成獨立、可重用 agent 的，反而是圈受眾這種多個專案都要用、又需要自主判斷的能力。挑選現成 AI agent 工具時也適用同一套眼光，這點我們在 如何挑選 CDP AI Agent 裡談過。

收尾：好的 AI 系統，贏在拆得對，不靠堆得多

回到開頭那封改地址的信。它之所以難，不是因為哪個模型不夠強，而是因為它把好幾種不同性質的工作（理解、驗證授權、查事實、查會變的規則、生成、執行）包在一句話裡。AI 系統設計的功力，就在於把這句話拆開，讓每種工作各歸各位、各配對的工具。

任務拆解（task decomposition）是這一切的地基。地基打對了，MCP 讓你不必為每個後端重寫對接，RAG 接上治理良好的資料源讓會變的知識保持更新，eval 讓你睡得著覺；multi-agent 架構則是樓上的選配，只在求速度或求重用、且 workflow 與工具都解不了時才蓋。

最該帶走的一句話很簡單：先拆解任務，再決定要不要 multi-agent；很多時候，最好的答案是不要。

常見問題

Q1：什麼是任務拆解（task decomposition）？為什麼 AI 客服流程設計要先做這件事？ 任務拆解是把一個看似一句話的需求，分解成多個職責單一、可被獨立檢驗的步驟。以改訂單地址為例，可拆成抽出關鍵資訊、驗證身分與訂單歸屬、查可否修改並更新地址、查退換貨政策、起草回信、送出 Email，每步配上最適合的工具。先拆解的價值在於把一個模型猜全部變成每個環節各做一件事，任何一步出錯都看得出是哪一步，也能單獨替換或授權。學界的 least-to-most prompting 研究在符號與數學推理任務上提供了先分解再循序求解的旁證。

Q2：拆解任務時，每一步該怎麼選工具？ 原則是依工作性質選工具。理解自然語言、整理意圖、生成文字交給 LLM；查資料庫裡的確定事實用自訂工具或 MCP，不要讓模型憑記憶生成；查會更新的知識（如退換貨政策）用 RAG，並接到帶版本與生效日的資料源；會改動真實資料的動作（如更新地址、寄信）用有權限控管的授權工具，並設核可閘門。此外每一步都要套上 eval，高風險步驟用程式規則與人工覆核補強。

Q3：MCP 在這套架構裡扮演什麼角色？ MCP（Model Context Protocol）是一個 client-server 協定。agent 所在應用扮演 MCP client，去連接一個個把後端能力包裝成標準介面的 MCP server。沒有它時，agent 要查訂單、物流、庫存得各教一套呼叫方式；有了 MCP，agent 用同一種方式呼叫不同 server，像出國用一個萬用插頭。要注意 MCP 的核心定位是工具與資料存取介面，不是專為 agent 對 agent 溝通設計；真要做多 agent 協作，通訊、狀態與權限還得另外設計。

Q4：什麼時候才該用 multi-agent 架構？ 導入 multi-agent 的理由不只一種，常見的有平行化、專家分工、獨立審查、動態拆派與可重用能力，每一種都要用延遲、成本、準確率、可追蹤性評估。最容易判斷的兩個是平行處理（彼此不相依、可同時做的子任務換取速度）與高可重用性（一個能力多處共用攤提成本）。但要先問：平行常常用一條 workflow 並行呼叫工具就夠，共用能力常常做成工具就夠，不一定要拆成多個 agent。多一個 agent 不會自動變聰明。

Q5：階層式（hierarchical）和扁平式（flat）架構差在哪？ 差別在 agent 之間怎麼溝通。階層式有一個總管（orchestrator）接命令、派發子任務給底下 agent、再彙整結果，使用者只跟總管對話、入口單一、上下文集中，通常較容易給出一致回覆，對應 Anthropic 描述的 orchestrator-workers 樣式，代價是總管可能成為延遲瓶頸與單點失效。扁平式沒有總管，agent 直接水平溝通、把彼此當工具呼叫，省下中間轉一手的成本、反應更直接，代價是 agent 一多關係會變複雜、行為較難追蹤。

Q6：什麼是過度設計（overdesign）？怎麼避免？ 過度設計指在單一 agent 就能解決的問題上硬上 multi-agent，徒增複雜度與成本。避免的方法是把單一 agent 加拆好的步驟當成基準線，需要平行時先想 workflow、需要共用時先想工具，只有在確定需要自主判斷或維持狀態時才升級成 agent。Anthropic 在 Building Effective Agents 裡也強調先找最簡單的解法、只在需要時增加複雜度，很多時候最好的選擇是根本不做成複雜的 agentic 系統。

Q7：為什麼退換貨政策這類知識要用 RAG，不直接寫進模型？ 因為政策會更新。把政策寫死在模型參數裡，等於鎖進一份會過期的文件，模型答的會是訓練時的舊規則。用 RAG（檢索增強生成）即時去外部撈，可以接上會更新的政策資料源。但 RAG 只保證去撈，不保證撈回來就是最新最對的版本，所以要接帶版本與生效日的資料源，回覆時附上版本與生效日，遇到多版本衝突就轉人工。RAG 的原始概念由 Lewis 等人 2020 年提出，核心是結合模型內建記憶與外部可更新知識。

多 agent 是手段不是目的。設計每個 agent 的原則見 用經理人思維設計 AI 工作流，怎麼確認整套系統做對沒有見 你的 AI 到底做對沒有。

延伸閱讀

1. 選 CDP AI Agent 前先問 4 個問題：用四個問題快速判斷一個 AI agent 方案到底解不解決你的問題，呼應本文的 eval 與不過度設計精神。
2. 破解 AI 神話：MCP 報表到 RAG 的陷阱、人機協作：從 MCP 與 RAG 的實務陷阱談人機協作，補上本文沒展開的落地細節。
3. CDP 10 大應用場景：把本文的拆解與架構紀律，對照到電商 OMO 的十個實際應用場景，看原理怎麼落到場景。