AI Agent 將通過自主問題解決、自適應工作流和可擴展性，徹底改變企業運營。但真正的挑戰并不在于構建更好的模型。

Agent 需要訪問數據、工具，并具備跨系統共享信息的能力，使其輸出可供多個服務（包括其他 Agent）使用。這不是一個 AI 問題，而是基礎設施和數據互操作性的問題。它不僅僅是簡單地拼接指令鏈，而是需要一種基于數據流的事件驅動架構（Event-Driven Architecture，EDA）。

正如 HubSpot（是一家總部位于美國的集客營銷、銷售和客戶服務軟件產品開發商和營銷商） CTO Dharmesh Shah 所說：“Agent 是新的應用程序。” 要實現這一潛力，必須從一開始就投資于正確的設計模式。

本文探討了為什么 EDA 是擴展 Agent 并在現代企業系統中釋放其全部潛力的關鍵。

要深入理解 EDA 為什么對 AI 的下一波發展至關重要，我們首先需要回顧 AI 發展至今的歷程。

AI 的演進

AI 經過了兩個不同的發展階段，并正步入第三階段。前兩次浪潮帶來了新的可能性，但也存在關鍵的局限性。

第一波 AI：預測模型

第一波 AI 以傳統機器學習為核心，專注于針對特定任務的預測能力。

構建這些模型需要深厚的專業知識，因為它們是針對特定的使用場景精心設計的。這些模型具有領域專屬性，而這種專屬性被嵌入到訓練數據中，使得它們非常僵化，難以重新利用。如果想要將一個模型適配到新的領域，往往需要從頭開始訓練——這種方法缺乏可擴展性，并且大大降低了 AI 的推廣速度。

第二波 AI：生成式模型

生成式 AI 由深度學習驅動，標志著 AI 發展的一個轉折點。

與第一波 AI 受限于單一領域不同，生成式模型是在海量、多樣化的數據集上進行訓練的，因此具備了跨不同場景泛化的能力。它們可以生成文本、圖像，甚至視頻，為 AI 的應用開辟了全新的可能性。然而，這一波 AI 也帶來了新的挑戰。

生成式模型是“靜態”的——它們無法動態地整合新的信息，也難以進行快速適配。雖然可以通過微調（fine-tuning）來滿足特定領域的需求，但這種方式成本高昂且容易出錯。微調需要龐大的數據集、強大的計算資源以及深厚的機器學習專業知識，這使得它在許多情況下難以實際應用。此外，由于 LLM（大語言模型）主要基于公開數據訓練，它們無法直接訪問專有的行業數據，因此在回答需要具體上下文的信息時往往顯得力不從心。

例如，如果你要求一個生成式模型推薦一份符合用戶個人健康狀況、所在地區和財務目標的保險方案……

在這個場景中，你向 LLM 提供提示詞，它隨后生成一個回復。然而，由于模型無法訪問相關的用戶數據，因此它無法提供準確的推薦。缺少這些數據，模型的回答要么是泛泛而談，要么完全錯誤。

復合 AI 彌合這一鴻溝

為了克服這些局限性，復合 AI（Compound AI）系統將生成式模型與編程邏輯、數據檢索機制和驗證層等組件集成在一起。這種模塊化設計使 AI 能夠靈活調用工具、獲取相關數據，并根據具體情況定制輸出——這正是靜態模型所無法做到的。

以保險推薦為例：

1. 數據檢索機制，從安全數據庫中提取用戶的健康和財務數據。

2. 這些數據被添加到 LLM 提示詞的上下文中，以確保模型能夠基于完整信息進行推理。

3. LLM：結合組裝后的提示詞生成精準的推薦結果。

這一過程被稱為檢索增強生成（RAG），它通過在模型的工作流中動態引入相關數據，彌合了靜態 AI 與現實需求之間的鴻溝。

雖然 RAG 在處理這類任務時表現良好，但它依賴于固定的工作流，這意味著每一次交互和執行路徑都必須預先定義。這種剛性限制了 RAG 在應對更加復雜或動態任務時的能力，因為這些任務的所有執行路徑無法被窮盡式地編碼。手動定義所有可能的執行路徑不僅勞動密集型，而且最終會成為 AI 發展的瓶頸。

固定流程架構的局限性，催生了 AI 的第三波浪潮：Agentic 系統。

Agentic AI 的崛起

盡管 AI 取得了長足進步，但固定系統甚至 LLM 本身的局限性已逐漸顯現。

據報道，Google 的 Gemini 在訓練了更大規模的數據集后，仍未能達到內部預期。OpenAI 的下一代 Orion 模型也傳出了類似的結果。

Salesforce CEO Marc Benioff 在《華爾街日報》的 Future of Everything 播客中表示，我們已經接近 LLM 能力的上限。他認為，未來屬于自主 Agent——即能夠自主思考、適應并獨立行動的系統，而不是 GPT-4 這樣的模型。

Agent 帶來了全新的能力：動態、基于上下文的工作流。不同于固定流程，Agentic 系統能夠即時決定下一步行動，根據當前環境自適應調整。這使得它們特別適用于當今企業面臨的不可預測、相互關聯的問題。

Agent 顛覆了傳統的控制邏輯。

傳統系統依賴剛性程序來規定每一個操作步驟，而 Agent 則利用 LLM 來驅動決策。它們可以推理、調用工具、訪問記憶——且一切都能動態進行。

這種靈活性使得工作流能夠實時演變，讓 Agent 遠比基于固定邏輯的系統更加強大。

設計模式如何塑造更智能的 Agent

AI Agent 的強大不僅來源于其核心能力，還取決于設計模式對其工作流和交互方式的結構化管理。這些模式使 Agent 能夠解決復雜問題、適應變化的環境，并高效協作。

下面介紹幾種常見的設計模式，它們能夠提升 Agent 的智能性和執行能力。

反思（Reflection）：通過自我評估不斷優化

反思能力使 Agent 能夠在執行操作或生成最終回復之前評估自己的決策并改進輸出。

這種機制讓 Agent 能夠發現并修正錯誤，優化推理過程，并確保更高質量的結果。

工具使用擴展 Agent 能力

與外部工具的接口擴展了 Agent 的功能，使其能夠執行如數據檢索、過程自動化或執行確定性工作流等任務。這對于要求嚴格精確性的操作尤為重要，例如數學計算或數據庫查詢，其中精度是不可妥協的。

工具的使用彌合了靈活決策與可預測、可靠執行之間的鴻溝。

規劃將目標轉化為行動

具備規劃能力的 Agent 可以將高層次的目標分解為可執行的步驟，并以邏輯順序組織任務。這個設計模式對于解決多步驟問題或管理具有依賴關系的工作流至關重要。

多智能體協作：模塊化思維

多智能體系統通過將特定任務分配給專門的 Agent 來采取模塊化的解決方案。這種方法具有靈活性：你可以使用較小的語言模型（SLM）為任務特定的 Agent 提高效率，并簡化記憶管理。模塊化設計通過將每個 Agent 的上下文集中在其特定任務上，從而減少了單個 Agent 的復雜性。

一種相關的技術是專家混合（Mixture-of-Experts，MoE），它在單一框架內使用專門的子模型或“專家”。像多智能體協作一樣，MoE 動態地將任務分配給最相關的專家，優化計算資源并提高性能。這兩種方法都強調模塊化和專業化——無論是通過多個 Agent 獨立工作，還是通過在統一模型中進行任務特定的路由。

正如傳統系統設計中所做的那樣，將問題拆分為模塊化組件使其更容易維護、擴展和適應。通過協作，這些專業化的 Agent 可以共享信息、分擔責任，并協調行動，以更高效地解決復雜挑戰。

簡而言之，Agent 不僅僅執行工作流；它們重新定義了我們對工作流的理解。它們是構建可擴展、適應性強的 AI 系統的下一步——突破了傳統架構的限制以及當前 LLM 的局限性。

Agentic RAG：自適應和上下文感知的檢索

Agentic RAG 通過使其更加動態和基于上下文驅動，從而發展了傳統的 RAG。與依賴固定工作流不同，Agent 可以實時決定它們需要哪些數據、在哪里找到這些數據，并根據當前任務如何優化查詢。這種靈活性使得 Agentic RAG 特別適用于處理需要響應能力和適應性的復雜多步驟工作流。

例如，一個創建營銷策略的 Agent 可能首先從 CRM 中提取客戶數據，使用 API 收集市場趨勢，并在新信息出現時不斷調整策略。通過通過記憶保留上下文并迭代查詢，Agent 能夠生成更準確、更相關的輸出。Agentic RAG 將檢索、推理和行動結合在一起。

擴展智能 Agent 面臨的挑戰

擴展 Agent —— 無論是單個 Agent 還是協作系統 —— 取決于它們輕松訪問和共享數據的能力。Agent 需要從多個來源收集信息，包括其他 Agent、工具和外部系統，以便做出決策并采取行動。

將 Agent 連接到它們所需的工具和數據，從根本上講是一個分布式系統問題。這種復雜性與設計微服務時面臨的挑戰相似，因為在微服務中，各個組件必須高效地進行通信，而不產生瓶頸或僵化的依賴關系。

像微服務一樣，Agent 必須高效通信，并確保其輸出在更廣泛的系統中具有實用性。就像任何服務一樣，它們的輸出不僅僅應該回流到 AI 應用程序中——它們還應該流入其他關鍵系統，如數據倉庫、CRM、CDP 和客戶成功平臺。

當然，你可以通過 RPC 和 API 將 Agent 與工具連接起來，但這會導致系統的緊耦合。緊耦合使得擴展、適應或支持多個數據消費者變得更加困難。Agent 需要靈活性。它們的輸出必須無縫地流入其他 Agent、服務和平臺，而不將所有內容鎖定在僵化的依賴關系中。

解決方案是什么？

通過事件驅動架構（EDA）實現松耦合。它是允許 Agent 共享信息、實時行動并與更廣泛生態系統集成的支柱——無需緊耦合帶來的頭痛問題。

EDA

在早期，軟件系統是單體的。一切都存在于一個單一、緊密集成的代碼庫中。盡管單體應用簡單易構建，但隨著系統的增長，它們變得極其復雜且難以維護。

擴展就像一把鈍器：你必須擴展整個應用程序，即使只有其中的一部分需要擴展。這種低效導致了系統膨脹和脆弱架構，無法應對增長的需求。

微服務改變了這一局面。

通過將應用程序拆分成更小的、可獨立部署的組件，團隊可以擴展和更新特定部分，而不必觸及整個系統。但這也帶來了一個新問題：這些更小的服務如何高效通信？

如果我們通過直接的 RPC 或 API 調用來連接服務，就會產生大量的相互依賴關系。如果其中一個服務出現故障，它將影響整個連接路徑上的所有節點。

EDA 解決了這個問題。

與緊耦合的同步通信不同，事件驅動架構（EDA）使得組件能夠通過事件進行異步通信。服務之間不再互相等待——它們實時響應正在發生的事情。

這一方法使得系統更加具有彈性和適應性，能夠處理現代工作流的復雜性。這不僅是一個技術突破；它還是在壓力下系統生存的策略。

早期社交巨頭的興衰

早期社交網絡如 Friendster 的興衰強調了可擴展架構的重要性。Friendster 在早期吸引了大量用戶，但他們的系統無法處理如此龐大的需求。性能問題使用戶流失，平臺最終失敗。

相反，Facebook 的成功不僅因為其功能，還因為它投資了可擴展的基礎設施。它沒有在成功的重量下崩潰——反而挺立并最終主導了市場。

今天，我們也面臨著一個類似的挑戰——AI Agent 的興起和發展。

與早期社交網絡類似，代理將經歷快速增長和廣泛采用。構建代理本身并不足夠，真正的問題在于你的架構是否能處理分布式數據、工具集成和多代理協作的復雜性。如果沒有正確的基礎，您的代理系統可能會像早期的社交媒體失敗者一樣崩潰。

未來是事件驅動的 Agent

AI 的未來不僅僅是構建更智能的 Agent——更重要的是創建能夠隨著技術進步而進化和擴展的系統。隨著 AI 堆棧和基礎模型的快速變化，僵化的設計很快就會成為創新的障礙。為了跟上技術發展的步伐，我們需要優先考慮靈活性、適應性和無縫集成的架構。事件驅動架構（EDA）是這一未來的基礎，它使得 Agent 能夠在動態環境中蓬勃發展，同時保持彈性和可擴展性。

Agent 作為具有信息依賴的微服務

Agent 類似于微服務：它們是自主的、解耦的，并能夠獨立處理任務。但代理更進一步。

雖然微服務通常處理離散的操作，但代理依賴于共享的、富有上下文的信息來進行推理、決策和協作。這就對管理依賴關系和確保實時數據流動提出了獨特的要求。

例如，一個 Agent 可能從 CRM 中提取客戶數據，分析實時分析數據，并使用外部工具——同時與其他 Agent 共享更新。這些交互需要一個系統，在該系統中，Agent 可以獨立工作，但仍能流暢地交換關鍵信息。

EDA 通過充當“中央神經系統”來解決這一挑戰。它允許 Agent 異步廣播事件，確保信息動態流動而不會產生僵化的依賴關系。這種解耦讓 Agent 能夠自主操作，同時無縫集成到更廣泛的工作流和系統中。

解耦同時保持上下文完整

構建靈活的系統并不意味著要犧牲上下文。傳統的緊密耦合設計通常將工作流綁定到特定的管道或技術上，迫使團隊在瓶頸和依賴關系之間進行調整。一部分堆棧的變化會波及整個系統，減緩創新和擴展的步伐。

EDA 消除了這些限制。通過解耦工作流并啟用異步通信，EDA 允許堆棧的不同部分——Agent、數據源、工具和應用層——獨立運作。

以今天的 AI 堆棧為例。MLOps 團隊管理像 RAG 這樣的工作流，數據科學家選擇模型，應用開發人員構建界面和后端。緊密耦合的設計迫使這些團隊相互依賴，減緩交付并使適應新工具和技術變得更加困難。

相比之下，事件驅動的系統確保工作流保持松散耦合，使每個團隊能夠獨立創新。

應用層不需要了解 AI 的內部細節——它們只在需要時消費結果。這種解耦還確保了 AI 的洞察不會被孤立。代理的輸出可以無縫集成到 CRM、CDP、分析工具等中，創建一個統一的、可適應的生態系統。

通過事件驅動架構擴展 Agent

EDA 是向 Agent 系統過渡的支柱。

它能夠在解耦工作流的同時啟用實時通信，確保代理能夠在大規模下高效運作。如本文所討論，像 Kafka 這樣的平臺展示了 EDA 在 Agent 驅動系統中的優勢：

橫向擴展性：Kafka 的分布式設計支持添加新的 Agent 或消費者而不產生瓶頸，確保系統輕松擴展。

低延遲：實時事件處理使 Agent 能夠即時響應變化，確保快速和可靠的工作流。

松散耦合：通過 Kafka 主題進行通信，而不是直接依賴，使 Agent 保持獨立且可擴展。

事件持久化：持久化消息存儲確保在傳輸過程中不會丟失數據，這對高可靠性工作流至關重要。

數據流使得數據能夠在整個業務中持續流動。

一個中央神經系統充當實時數據流的統一支柱，輕松連接不同的系統、應用程序和數據源，確保高效的 Agent 通信和決策制定。

這種架構與像 Anthropic 的 Model Context Protocol (MCP) 這樣的框架自然契合。

MCP 提供了一個通用標準，用于將 AI 系統與外部工具、數據源和應用程序集成，確保安全且無縫地訪問最新信息。通過簡化這些連接，MCP 降低了開發工作量，同時啟用了基于上下文的決策制定。

EDA 解決了許多 MCP 旨在解決的挑戰。MCP 需要無縫訪問多樣的數據源、實時響應能力，并且能夠擴展以支持復雜的多 Agent 工作流。通過解耦系統并啟用異步通信，EDA 簡化了集成，確保 Agent 能夠在沒有嚴格依賴關系的情況下消費和生成事件。

EDA 將定義 AI 的未來

AI 領域正在迅速發展，架構必須與之同步演變。

企業也已經準備好。Forum Ventures 的一項調查顯示，48% 的 IT 高級領導者已準備好將 AI Agent 集成到運營中，其中 33% 表示他們非常準備好。這表明市場對于能夠擴展并處理復雜性的系統有明顯需求。

EDA 是構建靈活、韌性強、可擴展的代理系統的關鍵。它解耦組件，啟用實時工作流，并確保 Agent 能夠無縫地集成到更廣泛的生態系統中。

那些采用 EDA 的企業不僅能生存下來——他們將在這波 AI 創新浪潮中獲得競爭優勢。而其余的企業，則有可能被拋在后面，成為因無法擴展而遭遇失敗的犧牲品。?

來源 | PyTorch研習社（ID：pytorchlab）

作者 | 南七無名式 ; 編輯 | 呼呼大睡

內容僅代表作者獨立觀點，不代表早讀課立場