網路世界正在演進。我們正從一個為人類網頁瀏覽設計的網路，轉向一個支援跨系統自主代理協作的基礎設施。這種新的範式需要一個根本不同的堆疊，一個建立在開放元件之上，促進無縫通訊、工具利用和即時處理的堆疊。
在這個新興堆疊的核心是四個關鍵技術：
- Agent2Agent (A2A)：由 Google 開發，A2A 是一種協定，使代理能夠相互發現和通訊。它為代理提供了一種標準化的方式來宣告它們的能力、交換任務和串流更新。
- Model Context Protocol (MCP)：由 Anthropic 開創，MCP 是一種工具使用和外部上下文的標準。它定義了代理如何訪問和利用外部 API 和工具，使它們能夠與真實世界互動。
- Apache Kafka：一個分散式事件串流平台，充當代理通訊的中央神經系統。 Kafka 提供了一種可靠且可擴展的方式來協調代理之間的互動。
- Apache Flink：一個即時處理引擎，用於豐富、監視和處理代理活動串流。 Flink 使代理能夠即時對事件做出反應、做出決策並協調複雜的工作流程。
零散的代理生態系統所帶來的挑戰
目前，AI 代理的開發面臨著與碎片化和缺乏互通性相關的重大挑戰。這些挑戰阻礙了穩健且可擴展的 AI 系統的創建：
- 孤立的代理：代理通常在孤島中運作，無法通訊或共享資訊。例如，CRM 代理可能不知道資料倉儲代理發現的洞察，從而導致錯失機會和效率低下。
- 脆弱的工具使用：如果沒有調用工具和 API 的標準化協定，代理將依賴於難以維護和重用的硬編碼整合。這限制了它們適應不斷變化的環境和與新系統整合的能力。
- 不一致的框架：不同的代理運行時採用不同的模型，將代理視為聊天機器人、有向無環圖 (DAG) 或遞迴規劃器。這種缺乏一致性使得創建可移植和可互操作的代理變得困難。
- 以原型為中心的開發：許多代理被設計為一次性原型，缺乏實際部署所需的穩健性和可擴展性。它們通常無法解決重試、故障、協調、日誌記錄和擴展等關鍵問題。
- 缺乏協作骨幹：缺少中央事件匯流排、共享記憶體或代理操作的可追蹤歷史記錄會阻礙協作和協調。資訊通常被困在直接 HTTP 調用中或埋在日誌中，從而難以理解和除錯代理行為。
解決方案不在於將所有代理整合到一個單體平台中，而是建立在基於開放協定、事件驅動架構和即時處理的共享堆疊之上。 這種方法促進了互通性、可擴展性和彈性。
Agent2Agent：標準化代理通訊
Google 的 A2A 協定是解決代理互通性問題的重要一步。它提供了一種通用的協定來連接代理，無論它們的來源或運行時環境如何。透過定義代理的共享語言，A2A 使它們能夠：
- 宣傳能力：代理可以透過
AgentCard宣告它們的能力，AgentCard是一個 JSON 描述符，指定代理可以做什麼以及如何與其互動。這允許其他代理發現和利用它們的服務。 - 交換任務：A2A 透過 JSON-RPC 促進代理之間的結構化互動，其中一個代理請求另一個代理的幫助，並收到回應的結果或工件。這使代理能夠協作完成複雜的任務。
- 串流更新：代理可以在長時間運行或協作任務期間使用伺服器發送事件 (SSE) 串流即時回饋。這提供了透明度，並允許代理監視進度和對變更做出反應。
- 交換豐富的內容：A2A 支援交換檔案、結構化資料和表單，而不僅僅是純文字。這使代理能夠共享複雜的資訊並協作處理更廣泛的任務。
- 確保安全性：A2A 包含對 HTTPS、身份驗證和權限的內建支援，確保代理之間的安全通訊。這對於保護敏感資料和防止未經授權的訪問至關重要。
Model Context Protocol：實現工具使用和上下文意識
Anthropic 的 MCP 透過標準化代理如何使用工具和訪問外部上下文來補充 A2A。它定義了代理如何調用 API、調用函數以及與外部系統整合，使它們能夠與真實世界互動。
雖然 A2A 側重於代理如何相互通訊，但 MCP 側重於代理如何與其環境互動。這兩個協定共同提供了一個連接代理生態系統的綜合藍圖：
- MCP 透過提供對工具和資訊的訪問來增強個別代理智慧。
- A2A 透過促進代理之間的通訊和協作來實現集體智慧。
對穩健的通訊基礎設施的需求
想像一下一家公司，員工只能透過直接的一對一訊息進行通訊。共享更新需要單獨向每個人發送訊息，而跨多個團隊協調專案將涉及手動在群組之間傳遞資訊。隨著公司的發展，這種方法變得越來越混亂且不可持續。
同樣，建立在直接連接之上的代理生態系統變得脆弱且難以擴展。每個代理都必須知道與誰交談、如何聯繫他們以及他們何時可用。隨著代理數量的增加，所需連接的數量呈指數級增長，使得系統難以管理。
A2A 和 MCP 為代理提供了通訊和行動的語言和結構，但僅有語言是不夠的。為了協調整個企業中的大量代理，需要一個穩健的基礎設施來管理訊息流和代理反應。
Apache Kafka 和 Apache Flink：代理協調的骨幹
Apache Kafka 和 Apache Flink 提供了支援可擴展代理通訊和計算所需的基础设施。 Kafka 充當分散式事件串流平台，而 Flink 是一個即時串流處理引擎。
Kafka 最初在 LinkedIn 開發，它充當一個持久、高吞吐量的訊息匯流排，允許系統即時發布和訂閱事件串流。它將生產者與消費者分離，並確保資料持久、可重播且可擴展。 Kafka 廣泛應用於各種應用程式中，從金融系統到欺詐檢測再到遙測管道。
Flink 也是一個 Apache 專案，專為有狀態、高吞吐量、低延遲的事件處理而設計。雖然 Kafka 處理資料的移動，但 Flink 處理資料在系統中流動時的轉換、豐富、監視和協調。
Kafka 和 Flink 共同形成了一個強大的組合：Kafka 是血液，而 Flink 是反射系統。它們為建立可擴展且有彈性的代理生態系統提供了基礎。
正如 A2A 正在成為代理世界的 HTTP 一樣，Kafka 和 Flink 形成了可以支援可擴展代理通訊和計算的事件驅動基礎。它們解決了直接的點對點通訊無法解決的問題：
- 解耦：使用 Kafka，代理不需要知道誰將使用它們的輸出。它們將事件（例如，
"TaskCompleted"、"InsightGenerated"）發布到主題，任何感興趣的代理或系統都可以訂閱。 - 可觀察性和可重播性：Kafka 維護每個事件的持久、按時間順序排列的日誌，使代理行為完全可追蹤、可稽核且可重播。
- 即時決策：Flink 使代理能夠即時對事件串流做出反應，根據動態條件過濾、豐富、連接或觸發操作。
- 彈性和擴展：Flink 作業可以獨立擴展、從故障中恢復並跨長時間運行的工作流程保持狀態。這對於執行複雜、多步驟任務的代理至關重要。
- 串流原生協調：代理可以透過事件串流進行協調，發布更新、訂閱工作流程並協同推進狀態，而不是等待同步回應。
總結：
- A2A 定義了代理如何說話。
- MCP 定義了它們如何對外部工具採取行動。
- Kafka 定義了它們的訊息如何流動。
- Flink 定義了如何處理、轉換這些流並將其轉化為決策。
企業級 AI 代理的四層堆疊
像 A2A 和 MCP 這樣的協定對於標準化代理行為和通訊至關重要。然而，如果沒有像 Kafka 這樣的事件驅動子層和像 Flink 這樣的串流原生運行時，這些代理仍然是孤立的，無法靈活地協調、優雅地擴展或隨著時間的推移進行推理。
為了充分實現企業級、可互操作的 AI 代理的願景，我們需要一個四層堆疊：
- 協定：A2A 和 MCP 定義了代理通訊和工具使用的內容。
- 框架：LangGraph、CrewAI 和 ADK 定義了代理實施和工作流程管理的方式。
- 訊息傳遞基礎設施：Apache Kafka 支援代理之間訊息和事件的流動。
- 即時計算：Apache Flink 支援透過即時處理和轉換資料串流來進行思考。
這個四層堆疊代表了 AI 代理的新網路堆疊，為構建不僅智慧，而且協作、可觀察和可生產的系統提供了基礎。
朝著連接的代理生態系統邁進
我們正處於軟體發展的關鍵時刻。正如最初的網路堆疊開啟了全球連接的新時代一樣，AI 代理的新堆疊正在興起。此堆疊專為協同工作以推理、決策和行動的自主系統而構建。
A2A 和 MCP 提供了代理通訊和工具使用的協定，而 Kafka 和 Flink 提供了即時協調、可觀察性和彈性的基礎設施。它們共同使得從斷開連接的代理演示到可擴展、智慧的生產級生態系統的轉變成為可能。
這不僅僅是解決工程挑戰；而是關於啟用一種新型軟體，其中代理跨邊界協作，即時提供洞察力和行動流程，並允許智慧成為分散式系統。
為了實現這一願景，我們需要以開放、可互操作的方式，並牢記上次網路革命的經驗來進行構建。下次您構建代理時，不要只問它能做什麼。問問它如何適應更大的系統：
- 它可以與其他代理通訊嗎？
- 它可以與其他人協調其行動嗎？
- 它可以進化並適應不斷變化的環境嗎？
未來不僅僅是代理驅動的；而是代理連接的。