Tech

Single-Agent First：當 AI 架構辯論重演了微服務的歷史

Kevin

在 Friday 昨天的文章中，分析了一篇讓 AI 工程師不太舒服的論文：等量推理預算下，單一 Agent 在多跳推理任務上系統性地勝過多 Agent 架構。資訊理論提供了機制解釋——Agent 之間的每一次訊息傳遞，都是一次不可逆的高維資訊壓縮。

但這篇論文讓我想到的，不只是 KV cache 和 mutual information。

這場 Single-Agent 與 Multi-Agent 的辯論，我在軟體工程界見過。幾乎是逐幀重播。

技術拓撲的高度重疊

把兩者的架構對應起來，相似度高得有點荒謬：

Single-Agent ＝ 單體架構（Monolithic）：所有推理邏輯與上下文都在同一個處理程序——即 Context Window——內完成。沒有跨程序通訊，沒有序列化，注意力機制可以自由存取全部的中間狀態。

Multi-Agent ＝ 微服務（Microservices）：任務解耦，交給不同模組，透過約定的介面——Prompt 或 JSON 訊息——進行通訊。每個 Agent 是一個獨立的「服務節點」，只能看到傳遞過來的部分資訊。

這不是比喻上的相似，而是在工程維度上的結構性重疊。

四個踩坑維度

1. 通訊成本與序列化損耗

在軟體工程：兩個微服務要溝通，必須把記憶體裡的物件序列化成 JSON，透過 HTTP 或 gRPC 打到另一個節點，對方再反序列化。網路延遲加上 CPU 序列化開銷，每一次跨服務呼叫都有真實的成本。

在 AI 工程：就像那篇論文指出的，Agent A 在推理過程中建立的，是 KV cache 裡豐富的高維向量狀態。要把這份「理解」傳給 Agent B，必須強制降維——壓縮成人類可讀的文字，讓 Agent B 重新 tokenize 與運算。

這不只是 AI 界的「網路延遲」，更是嚴重的資訊不可逆損耗，同時讓 token 成本直接翻倍。跳數越多，多 Agent 系統的累積損耗越大，差距越顯著。

2. 狀態管理的地獄

在軟體工程：單體架構有共享記憶體，除錯直觀——設斷點，直接看全部的中間狀態。微服務則要面對分散式交易（Distributed Transactions）與資料一致性問題。兩個服務之間的狀態同步，永遠比你想像的複雜。

在 AI 工程：單一 Agent 在同一個 Context Window 裡，前因後果隨手可得，注意力機制讓「理解前置條件」這件事近乎免費。而在多 Agent 系統中，如果沒有建立極度精密的全局記憶體機制，常常會發生 Agent B 在瞎子摸象，完全不知道 Agent A 剛剛已經驗證過某個前提——然後重複同樣的工作，或者做出相互矛盾的假設。

3. 過度工程與編排災難

在軟體工程：這個場景每隔幾年就會重演一次。有人寫了個簡單的 CRUD 服務，因為「微服務是最佳實踐」，急著切成一堆 Kubernetes Pods，搭起 Istio 服務網格，接上分散式追蹤（Tracing）。業務流量根本沒起來，工程師的時間全花在搞基礎設施了。

在 AI 工程：版本幾乎一樣。很多任務明明在 200K context 內，一個結構清晰的 Prompt 就能解決，偏偏要套 LangGraph 或 AutoGen 切成五個節點。時間沒花在優化業務邏輯，全耗在處理 Agent 之間的「幻覺死結」、無窮迴圈，以及除錯 Routing 邏輯——這些開銷，在單一 Agent 架構裡根本不存在。

4. 什麼時候才真的需要拆分？

在軟體工程：當單體架構龐大到無法部署、模組耦合嚴重，或者不同服務需要獨立擴展（Scale-out）時，才是真正需要拆的時機。

在 AI 工程，我認為真正需要多 Agent 的場景有三類：

一、任務長度打爆了 Context Window。這不是效率問題，而是可行性問題——沒有單一 Agent 能在有限的 context 內完整處理超大型代碼庫或跨越數萬筆文件的資訊整合。此時多 Agent 是唯一選項，論文的比較框架就不適用。

二、大量並行 I/O 呼叫。同時搜尋多個資料來源、平行呼叫多個外部工具——這裡多 Agent 的優勢是時間效率，而非推理準確性，兩者的比較維度本就不同。

三、安全隔離需求。這個場景最容易被忽略。在構建自動化紅隊測試工具時，負責「生成惡意 Payload」的 Agent 和負責「評判攻擊是否成功」的 Agent，必須在實體上隔離——否則模型的 Context 會被自己的攻擊字串污染，產生防禦幻覺，讓整個評估失去意義。這種場景下，多 Agent 的隔離邊界是架構上的必要性，不是風格選擇。

歷史給出的答案：MonolithFirst

架構師 Martin Fowler 提倡過一個概念叫「MonolithFirst」：除非系統複雜度已經逼迫你不得不拆，否則永遠從單體架構開始。這個建議在當年也是反直覺的——微服務明明更現代、更可擴展，為什麼要從單體開始？

因為過早的拆分，會讓你在邊界還不清晰的時候固化了錯誤的介面設計。拆容易，合難。

AI 開發界經歷了過去一年的「Agent 網格幻覺」之後，也正在走向同樣的成熟期。先用一個能力極強的單體 Agent（配合良好的 Tool Use）把流程跑通，直到撞上真正的物理邊界——context 上限、並行瓶頸、或安全隔離需求——再把特定功能抽離成獨立 Agent。

Single-Agent First。不是因為懶，而是因為你還不知道邊界在哪裡。

參考來源