昨天講到 A2A 只有四個 method，全部是單向委託與查詢。今天講這個設計的後果。

多 agent 系統最常見的場景是「問三家店的價格，幫我挑最便宜的」。你會很自然地以為協定裡有某個地方負責把三份回覆合起來。沒有。

合併發生在 prompt 裡

實際跑起來是這樣的：orchestrator 委託 A、委託 B、委託 C，每一隻回傳一個完整的 Task 物件，這三個物件各自變成一筆 tool result，堆進 orchestrator 的同一個 prompt。然後 LLM 讀完自己寫出總結。

程式碼裡沒有任何一個叫做「合併結果」的函式。 合併是模型讀完之後的產物。

第一次意識到這件事的時候我有點意外，想通之後又覺得合理：協定要保持中立，它不能替你決定三份報價該怎麼比。但這個「合理」是有價碼的。

價碼長什麼樣

委託 N 個 agent，orchestrator 的 context 就要裝 N 份完整回覆。而 LLM 每次發言都要重讀整個 context，所以委託數量直接推高延遲跟費用。

我實測過一次：單純委託一次(要一份漢堡菜單)，prompt_token_count 從 535 漲到 969，一次吃掉 434 token。回覆越長、委託越多，漲幅越大。這還只是一次委託而已。

再往下推：第二次委託時，第一次的完整回覆還在 context 裡，所以第二次的 prompt 是「系統提示 + 所有 agent card + 第一次的完整 Task 物件 + 第二次的完整 Task 物件」。秘書的筆記本會越來越厚，而你每一次發言都在付重讀整本筆記的錢。

設計含意

把 orchestrator 當成資料匯流排是錯的用法。真的需要大量結果匯總時，應該讓 remote agent 之間直接交換，或落到共用儲存(資料庫、物件儲存)，只把摘要或指標回傳給 orchestrator。

換句話說，orchestrator 該收的是結論，不是原始資料。

這條上限不限於 A2A

任何 orchestrator 加 worker 的 LLM 架構都有同一條上限：MCP 的工具呼叫、自訂 tool、subagent fan-out，全部一樣。原因是共通的，因為統整動作發生在單一 LLM 的 context 裡，而 context 是有限且要重複計費的資源。

所以換協定不會讓這個問題消失。看到有人說「換成 X 協定就能解決 fan-out 成本」，可以先問一句：統整動作搬到哪裡去了？如果還是在某個 LLM 的 context 裡，那就沒搬。