Anthropic 的企業部署文章記錄了一個量化比較：一名客戶測試多代理架構與單一代理迴圈，後者執行時間約快兩倍。同篇文章也提到，一個客服代理配置十多個專業子代理後，品牌口吻難以一致，額外延遲影響使用體驗。這些匿名案例沒有公開完整樣本、測試設計或原始數據，屬供應商的部署觀察，不能直接當作所有企業的答案（Anthropic 企業部署文章）。

但這裡要先問一個更前面的問題：這些工作真的需要不同代理各自持有上下文嗎？AI 代理架構的選擇，應回到任務是否共享資料、能否平行，以及系統需要哪些錯誤隔離。Anthropic 在 2026 年 10 月提出重新檢查子代理配置，並發布遷移工具包；建議是逐步評測，不是宣告多代理已經過時。

一、子代理交接為什麼會增加成本？

成本常出現在代理間的上下文交接、重複處理與協調維護。 如果多個子代理總是接力處理同一批資料，摘要傳遞可能遺漏細節，額外的模型呼叫也會增加延遲。

子代理是擁有獨立上下文、工具與指令的 AI 代理，通常由協調器分派任務。拆開後，每個子代理可以專注一類工作，但主代理必須挑對對象、傳遞必要資訊，再整合回覆。每多一個交接點，就多一個需要測試的介面，也多一處可能失真或失敗的地方。

Anthropic 的匿名客服案例中，十多個專業子代理讓品牌一致性更難維持，且增加延遲。該文另提到，一家客戶比較多代理流程與單一代理迴圈時，後者執行時間約快一倍；不過沒有公開測試設計和原始數據，這只能視為個案觀察，不能推定整併必然更快或更便宜。

一個常見根因，是架構照著部門或職能切分，而非照工作流切分。若客服查詢、訂單狀態與配送資訊總是連續處理，分別交給不同代理可能複製了組織圖，卻沒有替任務增加真正的獨立性。先看代理實際如何被呼叫、共用哪些資料，再決定是否值得保留交接。

「在多個企業部署的比較中，單一代理搭配技能，在品質上常勝過單一提示塞入所有內容與子代理設計。」這是 Anthropic 對其部署比較的描述，並未公開完整樣本與原始數據。

二、哪些工作流適合單一代理，哪些應保留子代理？

任務共享上下文、資料相依或經常一起執行時，可優先測試整併；需要平行探索、獨立上下文或明確權限隔離時，子代理仍有價值。 判斷依據應是工作流表現，不是代理數量本身。

Anthropic 的多代理研究系統提供一個相反方向的量化案例：研究代理可以同時探索不同線索，再把結果交回主代理。Anthropic 表示，在自家內部研究評測中，多代理系統比單一代理高 90.2%；其中一項任務是查找標普 500 資訊科技公司董事會成員，多代理能拆分搜尋並找出正確答案，單一代理則未能完成。這是特定模型與內部評測的結果，適用範圍是可大量平行搜尋的研究問題，不能直接套用到客服或企業流程（Anthropic 多代理研究系統）。

可以逐項看五件事：工作是否能同時進行、每個階段是否需讀取前一步的完整脈絡、同一組代理是否常一起啟動、單一上下文是否出現可量測的退化，以及代理是否必須有不同資料權限。前四項有利於尋找整併機會；最後一項若涉及法規或最小權限，則可能需要保留明確隔離。

微軟的架構指引也建議：若沒有跨越資安或合規邊界、多團隊獨立維護等明確條件，可以先做單一代理測試；只有測試顯示限制無法透過提示、檢索或政策控制改善時，再考慮多代理。這是設計判準，不是所有產品都必須採用的固定規則。

流程圖依工作是否平行、是否共用上下文及是否需要權限隔離，分流至單一代理或多代理
先看任務的相依性與隔離需求，再決定要測試整併或保留子代理。

三、遷移工具包如何比較整併前後？

先建立代表性端到端評測，再一次改動一個子代理，逐次比較整併前後的任務結果。 只有平均分數不足以判斷，還要找出哪些任務改善、哪些任務退步。

Anthropic 發布的 Single Agent Loop Kit 是參考實作，流程分為盤點現有評測、合併經常共同執行的子代理，再逐一把其他代理轉成技能或工具並比較。技能（skills）是按需求載入的專業指令；工具則負責查詢資料或執行固定操作。逐步揭露能力可避免把所有指令一開始就塞進主提示。

工具包的客服示範以 12 項任務、每種配置重跑兩次；整併後曾讓原本能通過的一項配送日期任務失敗，主代理只查訂單，沒有再詢問配送專家。這個個案說明，少數任務的退步可能被整體分數掩蓋；它是測試示範，不是企業正式部署成效（工具包實測紀錄）。README 也說明，真實模型測試由一人在單一模型上執行兩次，合併、維護等部分步驟及其他系統尚未實測；工具包定位為參考實作，不能視為已驗證的通用流程。

評測要涵蓋生產環境中每種常見代理接力，以及不能違反的規則。每次變更後，除了任務完成度，也要記錄延遲、模型呼叫數、成本、工具選擇正確性與失敗案例；對容易波動的任務重跑數次，確認結果不是單次偶然。若缺少完整基準，先整理真實請求與可判定的完成條件，再逐步補齊。

「參考工具包不預設單一迴圈一定勝出；每次變更都要在同一評測中比較，只有替代方案站得住腳才移除子代理。」這是 Anthropic 對遷移流程的說明。

四、整併後如何維持可靠度與責任邊界？

保留明確的回合與成本上限、資料權限、寫入核准、結果驗證及失敗回復。 把邏輯集中到一個代理，不代表把安全控制也交給模型自行決定。

多代理可用獨立上下文分隔任務，或讓不同角色以最小權限存取資料。若整併會使單一代理取得原本分散的權限，應先檢查敏感資料範圍、誰核准寫入、如何追蹤操作，以及出錯時能否撤回。需要雙人覆核或職責分離的流程，不能只為減少呼叫數就抹去控制點。

Anthropic 建議單一代理迴圈仍由系統設定輪數、費用預算和寫入閘門，並可在輸出後加上目標檢查或驗證器。真正的責任應落在可檢查的控制上，例如工具權限、輸出格式驗證、操作日誌與人工核准，而非只依賴提示詞要求模型謹慎。

單一代理流程依序呈現預算設定、權限檢查、人工核准、輸出驗證、操作紀錄與回復路徑
整併代理後，可靠度仍須由可檢查的權限、核准、驗證與回復控制來支撐。

若某個代理仍能提供獨立驗證、平行處理或權限隔離，就保留它，並把它當成工具由主代理呼叫，也可作為漸進遷移的過渡方式。Anthropic 2025 年公開的研究系統仍採用主代理協調多個平行研究代理，顯示同一家公司會依任務保留不同架構。整併是要驗證的選項，不是預設終點。

五、用五項檢查決定是否值得試

盤點交接頻率、資料相依性、平行需求、失敗邊界與評測能力，再挑一組高頻且緊密相連的代理做小規模比較。 只改一項，才能看清效果來自哪裡。

  1. 描出工作流： 記錄每個代理的啟動條件、輸入、輸出與呼叫順序，標出常一起執行的組合。
  2. 找出交接損耗： 查看摘要是否漏掉上下文、是否重複載入相同資料，以及等待時間是否來自串行呼叫。
  3. 標記保留理由： 註明哪些工作真的需要平行探索、獨立上下文、隔離權限或獨立驗證。
  4. 建立基準： 用代表性任務記錄完成度、錯誤、延遲、呼叫數與成本，並重複執行。
  5. 小步整併： 從一組常共同執行的子代理開始，把提示轉成技能、把 API 操作留作工具，再對照每一項退步任務與權限控制。
  • 共享上下文、資料相依且經常接力的工作，較值得先測試整併。
  • 平行探索、上下文隔離、工具衝突或權限邊界，可能構成保留子代理的理由。
  • 遷移前後使用同一批任務評測，逐項比較完成度、延遲、成本與失敗案例。

常見問題

不等於。 專業流程可以整理成按需載入的技能，資料讀取與系統操作則保留為工具；提示只需提供必要規則，不必一次載入所有領域內容。

Q1：沒有端到端評測，可以直接開始整併嗎？

不建議直接改正式工作流。先挑選真實請求，寫下可判定的完成條件，再記錄現有系統的表現。沒有基準就無法分辨整併究竟改善速度，還是讓某些任務變差。

Q2：哪些任務仍適合多代理？

可平行探索不同方向、需要互相獨立的上下文，或必須隔離資料與權限的任務，仍可能適合多代理。是否採用要以實際測試與控制需求判斷。

Q3：整併後只有平均分數變好，是否就該移除子代理？

不一定。逐項檢查退步的案例，尤其是安全規則、權限、配送或其他關鍵步驟；若原本通過的必要任務失敗，應修正設計或保留該子代理，再重跑評測。