數位環境正從以人為本的網頁瀏覽，轉向自主代理跨多樣化系統無縫協作的領域。 這種轉變需要一種新的基礎設施，而一個引人注目的解決方案正在形成，它包含四個關鍵的開放原始碼元件。
- Google 的 Agent2Agent (A2A)：一種旨在促進代理發現和互動的協定。
- Anthropic 的模型上下文協定 (MCP)：一種定義代理如何使用工具和外部上下文資料的標準。
- Apache Kafka：一個強大的、事件驅動的通信骨幹，可實現可靠和解耦的協調。
- Apache Flink：一個即時處理引擎，對於豐富、監控和處理代理活動流至關重要。
本文探討了這些技術之間的協同關係，強調了僅僅依賴協定的局限性，並展示了這種架構如何為從孤立的機器人轉變為動態的、智慧的代理生態系統奠定基礎。
預計組織內 AI 代理的激增表明，大多數公司將部署多個專業代理，而不是單個包羅萬象的代理。 這些代理將自動執行程式碼產生、支援票證管理、客戶資料分析、員工入職和基礎設施監控等任務。
但是，目前的工具不足以支援這樣的未來。
挑戰不僅僅是’代理島嶼’問題，在這種情況下，代理在孤立的環境中運行，缺乏通信能力。 它包含一個更廣泛的生態系統碎片化：
- 缺乏代理間通信：代理通常在隔離的環境中運行。 客戶關係管理 (CRM) 代理不知道資料倉庫代理得出的見解。 支援代理無法回應監控代理檢測到的異常。
- 脆弱且自訂的工具使用：如果沒有用於存取工具或外部應用程式介面 (API) 的標準化方法，代理將依賴硬編碼的整合和不可重用的邏輯。
- 不一致的框架：不同的代理運行時採用不同的模型，將代理視為聊天機器人、有向無環圖 (DAG) 或遞迴規劃器。 這導致缺乏可攜式執行層或共享狀態。
- 專注於筆記本環境的設計：許多代理程式被開發為一次性原型，其特點是線性、同步和短暫的操作。 但是，實際系統需要穩健地處理重試、故障、協調、日誌記錄和擴展，這需要支援基礎設施。
- 缺少協作骨幹：沒有事件匯流排、共享記憶體或代理活動和理由的可追蹤歷史記錄。 資訊僅限於直接 HTTP 調用或埋藏在日誌中。
正如 12-Factor Agents 專案所強調的那樣，代理應遵守雲原生原則，展現可觀察性、鬆散耦合、可重複性和基礎設施意識。 不幸的是，大多數都是作為脆弱的腳本構建的，這些腳本是手動組裝的，並假定可以獨立運行。
這導致效率低下、重複工作和脆弱性。
Agent2Agent 通過為代理提供用於發現和通信的標準化協定，部分解決了此問題。 但是，要超越表面演示，達到生產系統所需的可擴展性和可靠性，僅僅依賴協定是不夠的。 它需要一個全面的基礎設施。
目前的代理生態系統反映了 Web 的早期階段，其特點是強大但孤立且不相容的系統。 就像早期瀏覽器在沒有標準協定的情況下與伺服器通信所面臨的挑戰一樣，今天的 AI 代理在發現、通信和相互協作方面步履維艱。
Google 的 Agent2Agent (A2A)：代理通信的通用協定
Google 的 A2A 協定是解決此問題的一個重要嘗試。 它的獨特之處在於它不是另一個代理框架，而是一個旨在連接任何代理的通用協定，無論其來源或部署環境如何。
類似於 HTTP 如何標準化網站通信，A2A 為代理定義了一種通用語言，使它們能夠：
- 聲明能力：通過
AgentCard，這是一個 JSON 描述符，概述了代理的能力和互動方法。 - 發送和接收任務：通過使用 JSON-RPC 的結構化互動，一個代理請求協助，另一個代理回應結果或’工件’。
- 使用伺服器發送事件 (SSE) 串流更新：在漫長或協作任務期間促進即時回饋。
- 交換豐富的內容：支援交換檔案、結構化資料和表單，而不僅僅是簡單的文字。
- 默認維護安全性：內置對 HTTPS、身份驗證和許可權的支援。
A2A 的優勢在於它避免了重新發明已建立的解決方案。 它利用完善的 Web 標準，類似於 HTTP 和 SMTP，從而促進了更容易的採用和更快的整合。
但是，A2A 僅代表整個解決方案的一個方面。
Anthropic 的模型上下文協定 (MCP)：標準化工具使用和上下文存取
Anthropic 的 MCP 解決了代理如何使用工具和存取上下文資訊的關鍵方面。 MCP 標準化了代理調用 API、調用函數以及與外部系統整合的過程，本質上定義了它們在其環境中的運行方式。 雖然 A2A 管理代理間通信，但 MCP 側重於代理與外部世界的互動。
本質上：
- MCP 增強了單個代理智慧。
- A2A 啟用了集體智慧。
類似於 HTTP 和 SMTP 需要廣泛的採用、基礎設施和開發者工具才能取得廣泛的成功，A2A 和 MCP 將需要一個強大的生態系統才能充分發揮其潛力。
即使採用了 A2A 和 MCP 等標準化工作，仍然存在一個關鍵問題：如何在複雜和動態的企業環境中有效地擴展代理通信？ 僅僅依靠這些協定定義的直接、點對點連接會帶來與可擴展性、彈性和可觀察性相關的挑戰。 這突顯了對強大的底層通信基礎設施的需求。
考慮一家公司，員工只能通過直接的、一對一的消息進行通信。 共享更新需要單獨向每個人發送消息。 跨多個團隊協調一個專案將涉及手動在每個團隊之間轉發資訊。
將這樣的系統擴展到數百名員工將導致混亂。
這種情況反映了基於直接連接構建的代理生態系統所面臨的挑戰。 每個代理都必須知道要聯繫哪些代理、如何聯繫它們以及它們的可用性。 隨著代理數量的增加，所需連接的數量呈指數級增長，從而導致一個脆弱、難以管理且不可擴展的系統。
A2A 和 MCP 為代理提供了通信和操作的語言和結構。 但是，僅僅有語言是不夠的。 為了跨企業協調眾多代理，需要基礎設施來管理消息流和代理回應。
Kafka 和 Flink：可擴展代理協作的骨幹
Apache Kafka 和 Apache Flink 提供了這種關鍵的基礎設施。
Kafka 和 Flink 解釋
Apache Kafka，最初在 LinkedIn 開發，現在是一個 Apache Software Foundation 專案，是一個分散式事件串流平臺。 它充當持久的、高吞吐量的消息匯流排，使系統能夠發佈和訂閱即時事件串流。 Kafka 廣泛用於各種應用，包括金融系統、欺詐檢測和遙測管道，因為它能夠將生產者與消費者分離，並確保資料持久性、可重播性和可擴展性。
Flink，另一個 Apache 專案，是一個即時串流處理引擎，專為有狀態、高吞吐量、低延遲事件處理而設計。 雖然 Kafka 管理資料移動，但 Flink 處理資料在系統中流動時的轉換、豐富、監控和編排。
Kafka 和 Flink 共同構成了一個強大的組合。 Kafka 充當血液，而 Flink 充當反射系統。
類似於 A2A 作為代理世界的 HTTP 的角色，Kafka 和 Flink 為可擴展的代理通信和計算提供了事件驅動的基礎，解決了直接、點對點通信無法解決的挑戰：
- 解耦：使用 Kafka，代理不需要知道其輸出的消費者。 他們將事件（例如，
"TaskCompleted"、"InsightGenerated"）發佈到主題，允許任何感興趣的代理或系統訂閱。 - 可觀察性和可重播性：Kafka 維護所有事件的持久、按時間排序的日誌，確保代理行為完全可追蹤、可審核和可重播。
- 即時決策：Flink 允許代理即時回應事件串流，根據動態條件篩選、豐富、聯接或觸發操作。
- 彈性和擴展：Flink 作業可以獨立擴展、從故障中恢復以及在長時間運行的工作流程中保持狀態，這對於執行複雜、多步驟任務的代理至關重要。
- 串流原生協調：代理程式可以通過事件串流進行協調，而不是等待同步回應，發佈更新、訂閱工作流程以及協作推進狀態。
總而言之：
- A2A 定義了代理如何通信。
- MCP 定義了它們如何與外部工具互動。
- Kafka 定義了它們的消息如何流動。
- Flink 定義了如何處理、轉換這些流以及如何使用它們做出決策。
諸如 A2A 和 MCP 之類的協定對於標準化代理行為和通信至關重要。 但是，如果沒有像 Kafka 這樣的事件驅動底層和像 Flink 這樣的串流原生運行時，代理將保持孤立，無法有效地協調、高效地擴展或隨著時間的推移進行推理。
用於企業級 AI 代理的四層架構
為了充分實現企業級、可互操作的 AI 代理的願景，需要一個四層架構：
- 協定：A2A、MCP – 定義 什麼。
- 框架：LangGraph、CrewAI、ADK – 定義 如何。
- 消息傳遞基礎設施：Apache Kafka – 支援 流。
- 即時計算：Apache Flink – 支援 思考。
這些層共同構成了 AI 代理的新網際網路堆疊，為構建不僅智慧而且協作、可觀察且可以投入生產的系統奠定了基礎。
我們目前正處於軟體發展的關鍵時刻。
正如最初的網際網路堆疊（由 HTTP 和 SMTP 等協定以及 TCP/IP 等基礎設施組成）開創了一個全球連接的時代一樣，AI 代理正在出現一個新的堆疊。 但是，此堆疊不是為人類瀏覽網頁或發送電子郵件而設計的，而是為協作推理、決策和行動的自主系統而設計的。
A2A 和 MCP 提供了代理通信和工具使用的協定，而 Kafka 和 Flink 提供了即時協調、可觀察性和彈性的基礎設施。 它們共同實現了從斷開連接的代理演示到可擴展、智慧、可投入生產的生態系統的轉變。
這種發展不僅僅是為了應對工程挑戰。 它是關於啟用一種新的軟體範例，在這種範例中，代理跨邊界協作，即時提供見解並驅動行動，從而使智慧成為一個分散式系統。
但是，這種願景需要積極的發展，強調開放性、互操作性，並利用從之前的網際網路革命中汲取的經驗教訓。
因此，在開發代理時，務必考慮其在更廣泛系統中的整合。 它可以有效地通信嗎？ 它可以與其他代理協調嗎？ 它可以發展並適應不斷變化的條件嗎？
未來不僅是代理驅動的；它是代理連接的。