Architecture Journal

Monolithic Agent vs Multi-Agent：先看 Context Isolation，再看 Context Cost

在比較 monolithic agent 和 multi-agent 時，真正最先出現的問題，通常不是成本。

更前面的問題是：agent 能不能先把任務做對。

當上下文太雜、太長、太互相干擾時，模型常見的失敗不是單純「變貴」，而是：

  1. 抓錯限制條件
  2. 把不相關資訊當成關鍵訊號
  3. 工具使用判斷漂移
  4. 在長流程裡累積狀態污染

也就是說，開發者一開始在意的，通常不是 token 單價，而是：

資訊過多時，agent 會不會開始 hallucinate、判斷錯誤，或把任務越做越偏。

這也是為什麼在成本之前，真正需要先回答的是：

這個任務更需要 context sharing，還是 context isolation？

因為這會先決定 agent 的任務品質，再進一步決定成本形狀。

這篇想講的核心可以濃縮成三句話：

Multi-agent 一階上通常在解 context pollution。
Monolithic agent 一階上通常在保留 context continuity。
cost 是這兩種選擇帶出的二階效果。

換句話說，這不是「哪個比較高級」的問題，也不是「哪個先天比較省」的問題，而是：

哪種上下文形狀，能先讓 agent 比較穩定地把任務做對。

然後才是：

這種做法的成本關係會長什麼樣子。

先把問題問對

monolithic agent 和 multi-agent 當然都和模組化、專精化、可維護性有關，但如果從實際設計順序來看，至少要把問題拆成兩層。

第一層是：

  1. 這個任務怎樣比較容易做對？
  2. 在這個前提下，整體 context cost shape 會長什麼樣子？

而第一層如果再拆開，通常問的就是：

  1. 這個任務更需要 context isolation，還是 context sharing？
  2. 哪種 context arrangement 比較能降低 hallucination、tool interference 與 state pollution？

順序很重要。因為 topology 改變之後，不只是 prompt 長短不同，而是整個 runtime 行為都會變。

更實際的成本模型通常比較像：

Per-task cost
= sum(每一次 model call 的 local context)
+ routing / handoff overhead
+ repeated prefix cost
+ final synthesis cost

所以真正該問的不是：

multi-agent 是不是天然比較便宜？

而是：

在我的任務分布下，哪一種 topology 能先維持較乾淨的上下文，讓 agent 比較穩定地完成任務？

然後才再問：

在這個前提下，哪一種 topology 的總成本更低？

Monolithic agent 的優勢，不只是比較少 call

monolithic agent 的核心價值，不是「系統比較原始」，而是它天然保留 shared context continuity。

如果一個任務反覆依賴同一份背景，例如同一個 repo、同一組 coding rules、同一批工具、同一段 session history，那 monolithic agent 通常比較自然。因為這些背景不需要一直在不同 agent 之間搬運。

它的優勢通常有三個。

  1. 共享背景比較完整
    同一份架構摘要、repo state、工具使用脈絡，都能持續留在同一條推理鏈上。

  2. stable prefix 比較容易重用
    如果 system prompt、tool schema、repo policies 都很穩定，cache reuse 通常也比較直接。

  3. model call 通常比較少
    你少了 router、specialist invocation、final synthesis 這些額外步驟。

但 monolithic agent 的問題也很明顯。它常常會把不需要一起出現的東西，全都塞進同一個 decision surface。

典型情況像是：

  1. 不同 domain knowledge 一起進 prompt
  2. 長 session 的中間狀態殘留
  3. 多種 guardrails 和 tools 互相干擾
  4. 舊的 retrieval 片段持續佔位

這時候你先承擔的不是 token，而是任務品質風險。也就是 context competition、state inconsistency，以及由此帶出的判斷漂移。

成本通常是接著才浮現的 downstream effect。monolithic agent 的主要成本壓力，往往不在 routing，而在這些地方：

  1. session history 持續膨脹
  2. compaction 壓力越來越高
  3. tool traces 越堆越長
  4. retrieval snippets 不斷疊加

換句話說，monolithic agent 更依賴的是 cache discipline 和 compaction discipline。

Multi-agent 的核心價值，不是自動變便宜

multi-agent 真正吸引人的地方，不是把大 prompt 自動切成便宜的小 prompt，而是把一個容易互相污染的大問題，拆成幾個上下文邊界較乾淨的局部問題。

它通常在解的是：

context isolation

也就是把不應該一起競爭注意力的東西拆開，例如：

  1. 不同角色的 objective
  2. 不同 specialist 的知識域
  3. 不同工具的操作脈絡
  4. 不同階段的中間狀態

這樣做的好處很直接。每個 agent 只需要帶：

  1. 自己的 instructions
  2. 自己的 tools
  3. 自己需要的少量背景

但它的代價也很直接。當你先用隔離邊界換到比較乾淨的局部判斷之後，system-level cost 不再是一個大 prompt，而是很多 local prompt 的總和。

典型成本來源包括：

  1. routing call
  2. handoff summary
  3. duplicated prefix
  4. repeated retrieval
  5. final synthesis

其中最常被低估的是 handoff summary。

子 agent 不會憑空知道前面發生了什麼。你通常還是要把任務目標、限制條件、目前狀態、上一階段輸出重新整理後送進去。handoff 做得不好時，multi-agent 很容易退化成：

同一批事實，被不同 agent 用不同 wording 重講很多次。

所以 multi-agent 更依賴的是 routing discipline 和 handoff discipline。

真正改變成本模型的，常常是 execution mode

很多討論把 monolithic 與 multi-agent 當成固定成本模型，但實際上，execution mode 常常比「有幾個 agent」更影響成本。

關鍵差別在於：子 agent 是從 fresh context 開始，還是能繼承父 agent 的上下文、狀態，甚至 prompt cache。

如果每個 worker 都從 fresh context 開始，通常會看到三種成本一起上升：

  1. handoff summary 變長
  2. shared prefix 被重送
  3. 相同背景被重複 retrieval

反過來說，如果 runtime 支援 inherited context、shared state 或 shared cache，很多 coordination cost 都會下降。這時 multi-agent 的問題就不再是「重複付共享背景的錢」，而比較像是在共享背景上切出幾條工作支線。

這也是為什麼同樣叫 subagent，成本可能差很多。

以 Claude Code 的公開設計為例：

  1. named subagent 會從新的 context 開始，使用自己的 system prompt，快取也與主對話分開
  2. forked subagent 會繼承父對話的上下文、system prompt 與 tools，第一個 request 還能重用 parent prompt cache

這裡重要的不是哪個產品比較好，而是它提醒我們：

agent topology 不是純粹的模組化問題，它本身就是 runtime-level 的 context architecture。

兩個例子，比抽象原則更好理解

單領域請求：multi-agent 可能更合理

假設你的系統有四種 specialist：billing、support、compliance、analytics。

如果 monolithic agent 每次都要帶著四組 domain instructions 和 tools，那即使使用者只問 billing 問題，你仍然可能在每一輪都把大量不相關知識一起送進去。

這時 router 加 billing specialist 的架構常常更合理。因為它省下來的不只是 token，而是：

不相關的領域根本不需要進 context

這通常同時改善兩件事：

  1. local context 更小
  2. context pollution 更低

高共享長任務：monolithic agent 可能更合理

另一種情況是 coding agent。

如果 planner、coder、reviewer 都必須反覆讀同一份 repo summary、同一組 coding rules、同一批 tools、同一段逐步累積的 history，那拆成多 agent 之後，你很可能只是把共享背景重複付費。

這時候你付的通常不是「三個小 prompt」，而是：

  1. planner 讀一次
  2. coder 再讀一次
  3. reviewer 又讀一次
  4. 中間再加 handoff summary

如果 execution mode 還是 fresh spawn，總和甚至可能比單一 agent 更高。

所以在高共享、長連續任務裡，monolithic agent 常常不是比較笨，而是更符合成本形狀。

什麼情況值得拆，什麼情況不值得

multi-agent 比較值得拆，通常不是因為它看起來比較進階，而是因為隔離邊界真的有價值。

通常會同時滿足幾個條件：

  1. 不同 specialist 的知識域差異很大
  2. 一次任務只會啟用少數 specialists
  3. handoff 可以壓成小而穩定的 structured payload
  4. routing 準確率夠高
  5. execution mode 能共享部分背景或快取

反過來說，monolithic agent 較合理的情況通常是：

  1. 大多數步驟都依賴同一份背景
  2. 任務雖短，但互動連續
  3. tool surface 雖大，但實際使用模式高度重疊
  4. handoff 很難被壓縮

這也是為什麼真正該量的，不是單次 prompt 長短，而是整個 task-level 行為。例如：

  1. model calls per task
  2. total input tokens per task
  3. duplicated stable prefix ratio
  4. handoff summary tokens per task
  5. cache hit rate
  6. specialist activation rate
  7. final synthesis cost

這些指標比單看「某次 specialist prompt 比較短」更有判斷力。

結論

monolithic agent 和 multi-agent 最容易被誤解成「簡單架構」與「進階架構」的差別，但我覺得更準確的說法是：

Monolithic agent 優先保留 shared context continuity。
Multi-agent 優先建立 context isolation。
context cost shape 是這兩種設計的後果。

所以 monolithic agent 的典型問題是：

一個大腦背了太多共享上下文

multi-agent 的典型問題則是：

很多小腦在反覆協調與轉譯上下文

如果每個 worker 都從 fresh context 開始，後者的成本會特別高。
如果 runtime 支援 inherited context、shared state 或 shared cache，multi-agent 的成本曲線又會換一個樣子。

最後真正成熟的判準，不是 agent 數量，也不是單輪 prompt 長短，而是這三件事能不能對齊：

  1. 任務形狀
  2. 上下文形狀
  3. 成本形狀

從這個角度看，agent topology 不是單純的軟體模組化問題，也不是單純的成本問題。

它其實是 context architecture 的一部分。

參考資料