2025 iThome 鐵人賽

DAY 15

DevOps

初探 LLM 可觀測性：打造可持續擴展的 AI 系統系列第 15 篇

【Day 15】大規模 AI Agent 應用的維運與架構設計挑戰

17th鐵人賽 ai agent observability llm

mikehsu0618

2025-09-29 20:44:00

72 瀏覽

分享至

一個響亮的聲音正在科技圈迴盪：「LLM Agent 時代來臨，人類不再需要學習軟體工程了！」這個論點極具誘惑力：當一個全能的 AI 助理可以根據你的自然語言需求，自動規劃、編寫、甚至執行程式碼時，我們何必還要去鑽研那些複雜的系統設計、演算法與資料結構呢？

然而，一個有趣且反直覺的現實正在浮現：當這些聰明的 Agent 真正進入大規模、生產級別的應用場景時，它們不僅沒有讓軟體工程變得多餘，反而讓那些最經典、最核心的工程原則變得前所未有的重要。

事實證明，AI Agent 並沒有消除複雜性，它只是將複雜性從「編寫確定性程式碼」轉移到了「管理和編排大量、具備自主性的非確定性組件」。而要駕馭這場由數百、數千個 AI Agent 共同上演的「混沌交響樂」，我們需要的恰恰是那些身經百戰的軟體架構師與工程師，以及他們工具箱裡那些永恆的設計原則：分散式系統、事件驅動架構、資料一致性、高內聚低耦合，以及對 CAP 定理的深刻理解。

這篇文章將帶你走過一段從單一 Agent 到大規模 Multi-Agent 系統的演進之旅，揭示為何那些看似「傳統」的軟體工程智慧，正是支撐起未來 AI 應用的基石。

從單體 Agent 到水平擴展的挑戰演進

想像一個獨立的 Agent，它就像一個全能的個人助理。你可以給它一個目標，比如「幫我規劃一趟為期五天的東京旅遊」，它會自主上網搜尋資料、比較價格、安排行程，最後給你一份完整的計畫。

單體 Agent 的侷限：只能應付小規模場景

在單體（Monolithic）模式下，這個 Agent 的運作相對簡單：

狀態管理：所有的對話歷史、中間思考過程（Memory）都儲存在本地或單一的資料庫中。
執行流程：任務是循序漸進的，一步一步完成，就像一個腳本。
可靠性：如果它失敗了，整個任務就失敗了，重試可能需要從頭再來。

這就像一個傳統的單體應用程式。它在初期功能強大、易於開發和理解。但當需求增加時，問題很快就暴露出來：

擴展性瓶頸：如果同時有一萬個人請它規劃旅遊，這個單體 Agent 就會不堪重負。
單點故障：任何一個小環節出錯，都可能導致整個任務鏈的中斷。
功能耦合：搜尋、預訂、翻譯等所有功能都耦合在一起，難以獨立升級或維護。

水平擴展 Agent ：一個不行就多來幾個

以上是 Langgraph 的架構設計，也可以看出他們一開始的目標從不只滿足於僅僅一個 Agent。

為了解決負載問題，最直觀的方案就是「水平擴展」，運行數百個一模一樣的旅遊規劃 Agent。這立刻引入了分散式系統的第一個經典挑戰：狀態管理。

每個 Agent 都需要存取對話歷史和用戶偏好。如果狀態儲存在各自的記憶體中，那麼用戶的下一個請求可能會被分配到一個完全「失憶」的 Agent 實例上。因此，我們必須將狀態外部化，使用像 Redis 或 Postgres 這樣的共享儲存。這正是傳統無狀態（Stateless）服務設計的核心思想。

此外，還需要一個負載均衡器（Load Balancer） 來有效地將請求分發到不同的 Agent 實例。看，才走了第二步，我們就已經踏入了傳統軟體架構的領域。

從 Agent 到多 Agent 協作的混沌秩序

當一個 Agent 不足以應付複雜任務

當任務變得極其複雜，例如「分析 IT S&P 500 成分股公司的所有董事會成員，並總結他們的背景與關聯」，僅僅增加 Agent 的數量是不夠的。這時，我們需要的是一支由不同專家組成的 Multi-Agent 團隊，這在概念上與微服務架構如出一轍。

在這個新架構下，我們可能會有：

一個總指揮 Agent (Orchestrator)：負責分解複雜任務，並將子任務分配給專門的部下。
多個並行的研究員 Agent (Worker)：每個 Agent 負責研究一家或幾家公司。
一個報告生成 Agent：負責將所有發現匯總成最終報告。
一個引用標註 Agent：確保報告的準確性和可追溯性。

這種架構的優勢是巨大的：透過並行化，研究時間可以從數小時縮短到幾分鐘。然而，我們也親手打開了分散式系統的「潘朵拉的盒子」。

混亂的通訊 vs. 事件驅動架構 (Event-Driven Architecture)

如果總指揮 Agent 直接透過 Reustful API 呼叫每一個研究員 Agent，並同步等待結果，系統將會變得極其脆弱和低效。這種緊耦合（Tight Coupling） 設計會導致任何一個研究員的延遲或失敗，都會阻塞整個流程，引發級聯故障。

協議	主要特點	優點	缺點	理想使用場景
RESTful APIs	基於 HTTP，文本格式 (JSON)，無狀態，同步。	簡單，廣泛採用，人類可讀，與語言無關，適合公開的 API。	在高吞吐量下會有效能瓶頸，同步的特性不適合需要解耦的工作流程。	Web 應用程式，外部 API，簡單的請求回應互動。
gRPC	RPC 框架，二進位格式 (Protocol Buffers)，HTTP/2，強型別，雙向串流。	高效能，高效率的序列化，強大的 API 契約，低延遲。	更複雜，人類可讀性較差，瀏覽器支援有限，學習曲線更陡峭。	內部服務之間的通訊，即時服務，行動應用程式。
Message Queues	非同步，訊息代理 (例如 AMQP)，解耦的通訊。	卓越的解耦能力，更好的故障隔離，內建重試邏輯，高擴充性。	增加了事件模型的複雜性，需要額外的管理工具。	事件驅動架構，長時間執行的程序，背景任務，高彈性需求的關鍵系統。

利用事件驅動與訊息佇列實現「高內聚低耦合」。

一個更優雅的設計是讓 Agent 之間透過非同步訊息進行溝通。

總指揮 Agent 將子任務（例如，「研究 A 公司」）作為一個「事件」發布到像 RabbitMQ 或 AWS SQS 這樣的訊息佇列中。
研究員 Agent 群體則去訂閱這個佇列。任何一個空閒的研究員都可以領取任務並開始工作。
完成後，研究員 Agent 將結果作為另一個事件發布到另一個主題上，供下游 Agent 使用。

這種設計實現了完美的關注點分離。總指揮無需關心任務由誰執行、有多少執行者，它只負責發布任務。研究員也無需知道是誰發布的任務，它只專注於完成工作。這不僅提升了系統的彈性與韌性，也讓獨立擴展不同類型的 Agent 成為可能。

資料不一致與最終一致性

現在，想像一個電商場景的 Multi-Agent 系統：訂單 Agent、庫存 Agent、支付 Agent 和物流 Agent 協同工作。如果庫存 Agent 成功鎖定了庫存，但支付 Agent 卻失敗了，我們該怎麼辦？這就是經典的分散式事務問題。

傳統的解決方案如 二階段提交（Two-Phase Commit）因其同步阻塞特性，在這種大規模、高延遲的系統中難以適用。另一種常見的方式為 Saga 模式 將一個長流程分解為一系列由不同 Agent 完成的本地事務，並在失敗時執行對應的補償事務（Compensating Transaction） 來撤銷影響。

LangGraph 如何解決這個問題？

與傳統 Saga 模式依賴於複雜的事件監聽不同，LangGraph 透過其有狀態圖 (Stateful Graph) 的架構，將這個複雜的補償流程變得極為直觀和可靠：

集中化的流程定義：整個訂單流程，包括「快樂路徑」（預訂庫存 -> 支付 -> 安排物流）和所有可能的「補償路徑」（支付失敗 -> 釋放庫存），都被清晰地定義在一個 LangGraph 圖中。您不再需要讓庫存 Agent 去 "監聽" 支付 Agent 是否失敗。
狀態驅動的決策：圖中的中央狀態物件會追蹤每一步的結果。例如，state['inventory_status'] = 'LOCKED' 和 state['payment_status'] = 'FAILED'。
條件邊作為協調器：在支付 Agent 節點執行後，一個條件邊 (Conditional Edge) 會檢查狀態。如果 payment_status 是 FAILED，它會自動將流程導向「釋放庫存」這個補償節點，而不是繼續往下走到物流節點。
自動容錯：最關鍵的是，LangGraph 的檢查點機制會持久化每一步成功的狀態。如果系統在支付失敗後、執行補償操作前崩潰，重啟時 LangGraph 會從持久化存儲中讀取到狀態，準確地知道需要執行「釋放庫存」的操作，從而確保流程最終會達到一個一致的狀態。

透過這種方式，LangGraph 將 Saga 模式的複雜協調邏輯轉化為一個易於理解和維護的視覺化流程圖，同時提供了內建的容錯能力，確保了系統的最終一致性。這是對 CAP 定理（在網路分區的場景下，一致性、可用性、分區容忍性三者最多只能滿足其二）在現實業務中的深刻應用。

多 Agent 的可觀成本

在我們讚嘆 Multi-Agent 架構的彈性與強大能力時，一個冰冷而現實的挑戰浮上水面：總營運成本 (TCO)。如果設計不當，一個看似高效的系統，其運營成本可能會失控，使其在商業上變得不可行。要理解這一點，我們必須先剖析成本的構成。

剖析總營運成本 (TCO)：為何成本會失控？

Multi-Agent 系統的總營運成本是多個組成部分的總和，並因智能體互動的分散特性而被放大：

LLM API 呼叫：這是最直接也最主要的成本來源。每個 Agent 對 LLM 服務的每一次呼叫都會產生費用，其成本取決於：
- 模型等級：能力更強的模型的單價遠高於輕量級模型。
- 令牌數量：輸入的提示長度、上下文和輸出的生成長度，都直接計入成本。冗長的對話或詳細的思考鏈會迅速增加開銷。
- 呼叫頻率 ：Agent 呼叫 LLM 的總次數。在 Multi-Agent 協作中，這會被顯著放大。
Agent 間通訊開銷：這是 Multi-Agent 系統中隱藏的成本陷阱。如果 Agent 之間透過自然語言訊息進行溝通，那麼每一次訊息交換都可能變成一次新的 LLM 呼叫，因為接收方 Agent 需要調用 LLM 來理解和處理傳入的訊息。
工具使用成本：配備工具的 Agent 可能會與外部 API（如搜尋引擎、專業資料庫、程式碼解釋器）互動。這些外部服務通常有自己的定價模式，會疊加在 LLM 成本之上。
基礎設施與資料成本：如果選擇自架開源模型或運行複雜的編排邏輯，底層的運算資源（CPU, GPU, 記憶體）和儲存成本也會成為開銷的一部分。同樣，對於處理大量資料的 RAG 系統，資料的傳輸和儲存成本也不容忽視。

在 Multi-Agent 系統中，這些因素會疊加放大。一個來自用戶的簡單請求，可能會觸發多個 Agent 之間的一連串 LLM 調用。每個 Agent 都在處理資訊、做出決策或為鏈中的下一個 Agent 重新組織資料。如果設計不夠仔細，一個中等複雜度的工作流程就可能因這种級聯效應而變得極其昂貴。

因此，設計一個具備成本效益的 Multi-Agent 系統，其核心不在於無限制地堆疊 Agent，而在於智能調度與分級處理。以下是一些關鍵的最佳實踐：

提早分類與守門員機制

並非所有用戶請求都需要動用昂貴的專家 Agent 團隊。在系統入口處簡單的用 if-else 實作一個輕量級的規則引擎（Rule-Based Engine） 或引入一個小模型（例如 Claude Haiku、Llama 3 8B）作為「守門員 Agent」 是至關重要的第一道防線。

職責：這個守門員的任務是進行初步的意圖識別和複雜度評估。
實踐：
- 規則過濾：透過關鍵字或請求格式，將明確的、簡單的查詢（如「查詢我的訂單狀態」）直接路由到單一、功能受限的 Agent。
- 小模型評估：對於更模糊的請求，由小模型判斷其商業價值和執行複雜度，從而有效過濾掉無效或低價值的請求，提早阻止後續昂貴的費用產生。

提早判斷任務複雜度

守門員 Agent 的另一個關鍵職責是選擇最經濟的執行路徑。一個重要的最佳實踐是：提早判斷任務複雜度，並動態匹配對應的執行器。

簡單任務：應調度一個單體 Agent，並將其工具集（Tools）嚴格限制在 3-10 個高度相關的工具內。這能以最小的 Token 消耗有效完成任務。
複雜任務：只有在確認任務需要多領域協作時，才喚醒由 2-4 個專家 Agent 組成的 Multi-Agent團隊。即使它們各自擁有多達 10-15 個工具，這種成本投入也是有價值的，因為它解決了單體 Agent 無法處理的問題。

這種動態調度策略，避免了用「牛刀殺雞」，確保了計算資源的精準投放。

成本驅動的 Agent 設計

在多 Agent 團隊內部，也應貫徹成本效益原則。並非所有 Agent 都需要使用最強大、最昂貴的模型（如 GPT-5 或 Claude 4 sonnet）。

模型分層：可以為執行特定、重複性任務的 Worker Agent 選擇更小、更具成本效益的模型，而僅將最強大的模型保留給負責複雜規劃、反思和最終決策的「總指揮 Agent」（Orchestrator Agent）。

在 AI 的浪潮下擁抱非確定性

到目前為止，我們討論的挑戰在傳統微服務中也存在。但 LLM Agent 帶來了一個獨有的、更棘手的問題：非確定性（Non-determinism）。

傳統軟體是確定性的：給定相同的輸入，總是產生相同的輸出。而 LLM Agent 的核心是概率性的。同樣的任務，它這次可能完美完成，下次可能產生幻覺或陷入無限循環。這對系統的穩定性和可靠性提出了前所未有的挑戰。

經典解法在新時代的演化：

強大的可觀測性 (Observability)：如果無法預測 Agent 的行為，那麼唯一的辦法就是精確記錄它的一舉一動。我們需要記錄每個 Agent 完整的思考鏈（Chain of Thought）、工具呼叫、輸入與輸出，以便在出錯時能夠追溯和除錯。
AI 原生的容錯模式：傳統的重試、超時和斷路器模式依然有效。但我們還需要新的模式，例如引入一個反思 Agent (Reflection Agent)，當一個 Agent 的輸出不符合預期時，反思 Agent 可以介入，分析失敗的原因並指導其進行修正。或者設計冗餘機制，讓多個 Agent 獨立完成同一個任務，再由一個投票 Agent 來決定最佳結果。