退款 Agent 上線後，很快遇到一個看似合理的問題。

客服要理解使用者的需求，政策要判斷退款資格，付款系統則要真的把錢退回去。既然工作本來就分成三種，何不乾脆拆成三個 Agent？

• 客服 Agent 負責對話。
• 政策 Agent 負責查規則。
• 付款 Agent 負責執行退款。

架構圖瞬間變得很完整。每個角色都有自己的 Prompt、Context 與工具，看起來就像一支分工明確的數位團隊。

但第一筆退款真正跑進來後，事情開始不對勁。

客服 Agent 把摘要交給政策 Agent，政策 Agent 判斷可以退款，再把結果交給付款 Agent。付款 Agent 發現缺少交易編號，只好把問題傳回去。等資料補齊，政策版本已經換了，三個 Agent 卻各自保留著不同時間點的 Context。

原本只需要完成一次退款判斷，現在變成三次推理、兩次交接，以及一個沒有人能清楚回答的問題：

如果最後退錯錢，到底是哪一個 Agent 對完整結果負責？

多一個 Agent，也會多一份脈絡、一次交接與一個可能出錯的決策點。

這也是 Multi-agent 最容易讓人誤判的地方。當工作看起來有多種角色，我們很自然地想替每個角色建立一個 Agent；但組織圖上的分工，不一定等於系統裡的決策邊界。

第一個該被刪掉的，其實是付款 Agent

先看付款 Agent 做了什麼。

收到訂單編號與退款金額，呼叫付款服務然後回傳交易結果。這段工作很重要，卻沒有多少需要自由判斷的地方。輸入應該明確、能做的動作應該受到限制，結果也必須由外部系統確認。如果讓模型在這裡自行思考「下一步要做什麼」，不但沒有增加價值，反而讓最接近真實副作用的地方多了一層不確定性。

所以付款 Agent 不該是 Agent。它更適合是一個受控的退款 Tool。

接著再看政策 Agent。如果它只是依照訂單日期、地區與商品類型，從正式政策庫找出適用條文，那麼它同樣不需要自己的目標與決策迴圈。它需要的是一個可測試的查詢介面。

這時原本的三個 Agent，已經只剩下一個：客服 Agent。

先看誰決定下一步：能用固定介面完成，就不需要額外增加一個決策迴圈。

我會用一個簡單的問題判斷元件邊界：它是否真的需要自己決定下一步？

退款 Tool 接收明確輸入，執行固定能力。如果金額超過門檻，流程必須停下來等待人工核准，這是由規則決定的 Workflow node。只有當一個元件必須面對不完整資訊，自行選擇步驟、工具與停止時機，它才開始像 Agent。

替查詢功能加上一段角色設定，不會讓它變成更專業的 Agent；只會讓原本確定的介面，多繞過一次模型推理。

但如果政策真的沒有標準答案呢？

事情不會永遠這麼簡單。
假設退款同時涉及許多不同國家的法規條款與例外規定，且資料彼此衝突。
此時光查出一個政策也不夠用。Agent 必須搜尋多個來源、確認政策版本、處理資料之間的矛盾，最後提出一份附有證據、可供審查的判斷。

到了這個階段，政策工作才可能值得交給一個獨立的 Agent。

關鍵不在於替它冠上「政策專家」的角色，而是這項工作是否真的形成一個獨立的決策邊界:它可以離開主對話單獨進行，需要自己的資料與 Context，可能使用不同的模型或研究工具，最後還能交付一份可被接受、退回或要求補充的成果。

換句話說，增加一個 Agent 的價值，不是多出一個角色，而是建立一個值得獨立存在的決策邊界。

通常有四種情況值得考慮拆分：

1. 多個子任務可以同時進行，例如平行調查十家供應商。
2. 不同工作需要隔離 Context，避免法規、程式碼與市場資料互相干擾。
3. 子任務需要不同的模型、工具、資料來源或執行環境。
4. 子任務能產生一份獨立且可驗收的交付物。

如果只是因為任務很長，或 Prompt 裡出現了三種角色，通常還不足以構成拆分的理由。

2026 年 6 月一項針對多 Agent 架構的實證研究也支持這個判斷。研究發現，自動產生的多 Agent 架構不但持續落後於採用 self-consistency 的單一 Agent，最高成本甚至達到十倍。只有當任務確實需要平行處理、隔離 Context，或具備明確的分解邊界時，人工設計的多 Agent 架構才展現出優勢。

這不是說 Agent 之間不能互相檢查，而是每增加一個 Agent，都必須回答一個問題：它究竟解決了哪一個無法由 Tool、Workflow 或單一 Agent 妥善處理的結構問題?

任務交出去後，誰還握有最後決定權？

假設政策研究確實值得獨立出來，下一個問題便不是替 Agent 取名字，而是：客服 Agent 把工作交出去後，是否仍對退款結果負責？

這個答案會決定協作方式。

第一種是管理者模式（Manager）。客服 Agent 委託政策 Agent 完成一份研究，收到結果後自行判斷是否採用，最後仍由客服 Agent 整合資訊並回覆使用者。OpenAI Agents SDK 將這種做法稱為 agents as tools，相關差異可參考它的多 Agent 協作說明。

第二種是責任轉交（Handoff）。例如一般客服確認案件屬於保險理賠後，讓理賠 Agent 接手後續對話。這不是請對方提供一份資料，而是使用者接下來真的由另一個 Agent 服務，決策責任也隨之轉移。

第三種是平行展開、集中收斂（Fan-out／Reduce）。若要同時研究十個市場的退款規範，可以把彼此獨立的工作分出去，再由一個負責人依固定格式合併。中國開源專案 ChatDev 2.0 的動態執行設計，也使用 Map 與 Tree 結構處理平行展開與分層歸併。

這種做法之所以成立，是因為十個市場可以各自完成，不必輪流等待。另一項針對 Agent 系統擴展的實證研究也觀察到相同差異：中央協調在可平行分解的金融任務上提升 80.9%，但面對必須逐步銜接的推理，各種多 Agent 設計反而下降 39% 到 70%。拆分能不能帶來收益，關鍵仍是任務之間的依賴關係。

三種模式真正的差別，是最終責任留在原 Agent、轉交出去，或由彙整者重新收斂。

畫法不同不是重點。真正要寫進系統設計的，是每次工作離開一個 Agent 時，誰有權接受結果、誰能要求重做，以及誰仍然對使用者負責。

「幫我查一下政策」還稱不上委派

客服 Agent 若只丟出一句「請幫我研究退款政策」，政策 Agent 仍然不知道該使用哪個版本、涵蓋哪些市場、交付什麼格式，也不知道資料衝突時能不能自行做假設。

這不是委派，只是把一段模糊的 Prompt 傳給下一個 Agent。

一份最小的委派契約，至少需要回答五件事：

契約不需要規定子 Agent 每一步怎麼思考，否則直接使用 Workflow 反而更清楚。它要限制的是任務邊界與交付責任，讓上游能判斷結果可不可以採用。

Google 的 A2A Protocol 解決了不同平台的 Agent 如何發現能力、交換訊息與交接任務；官方的A2A 一週年回顧也呈現了這套生態的發展。但訊息送得到，不代表任務委派得好。若交付物與驗收條件仍然模糊，Agent 之間即使能完美通訊，也只是更有效率地傳遞不確定性。

再畫一次退款流程，答案反而變簡單了

回到一開始那張三個 Agent 的架構圖。

付款工作沒有自由決策的必要，所以降為退款 Tool。一般的政策查詢也能用明確條件完成，因此先保留為查詢 Tool。客服 Agent 掌握完整對話，決定何時查詢、如何解讀結果，並且對使用者與最終退款負責。

只有遇到跨市場、來源衝突、需要形成獨立報告的政策研究，才臨時委派給子 Agent；研究完成後，責任仍回到客服 Agent。

角色分工不必等於 Agent 分工；固定能力留給 Tool，讓一個 Agent 對完整結果負責。

最後留下來的 Baseline 是：

一個對結果負責的客服 Agent，加上政策查詢與退款 Tool。

它看起來沒有三個 Agent 那麼熱鬧，卻更容易測試，也更清楚誰應該為完整結果負責。等到真實資料證明某類政策工作需要獨立 Context、不同能力或可驗收的交付物，再把那一段升級為子 Agent。

驗證升級是否值得時，不能讓 Multi-agent 使用三倍模型呼叫，卻只拿它和一次呼叫的單一 Agent 比。雙方應放在接近的成本與時間預算下，再觀察任務成功率、端到端時間與交接造成的資訊遺失。最直接的測試，是逐一拿掉子 Agent：如果換成 Tool 後效果沒有變差，那個 Agent 原本就不該存在。

因此，下次看到 Multi-agent 提案時，我不會先問需要幾個角色，而會先問三件事：這個子任務是否真的需要自己決定下一步？它能否交付一份可接受或拒絕的成果？新增的決策迴圈，是否在相同成本下勝過單一 Agent？

如果答案仍然模糊，先不要拆。

成熟的 Multi-agent 設計，不是讓每個方塊都有名字，而是知道哪一段決策真的必須獨立，以及工作交出去之後，誰還握有最後責任。

AI 你怎麼看？

工程師：「我組了一支 AI 專家團隊。」AI：「所以原本那個查詢功能，是哪一位專家的專長？」