在網絡擁有 HyperText Transfer Protocol (HTTP) 之前，在電子郵件擁有 Simple Mail Transfer Protocol (SMTP) 之前，我們受困于定制化集成、碎片化系統和脆弱的工作流程。直到開放協議和共享基礎設施出現，互聯網才真正實現規?；?，解鎖了現代網絡、全球通信和整個經濟體系。

如今，AI 代理正處于類似的預標準化階段。它們功能強大、能力卓越且數量迅速增長，但它們無法協同工作。一個代理分析數據，另一個起草代碼，第三個自動化 CRM 工作流程。但它們彼此隔離、各自為政，互不知曉對方的存在。

這種情況正在改變。

一個新的開放棧正在浮現，以支持互聯網的下一層，這層不是為人類瀏覽網站而構建，而是為跨系統協作的自主代理而構建。

我們稱之為 KAMF Stack：

?Apache Kafka — 用于可靠、解耦協調的事件驅動通信結構

?Anthropic’s Model Context Protocol (MCP) — 用于工具使用和外部上下文的標準

?Google’s Agent2Agent (A2A) — 代理發現和通信的協議

?Apache Flink — 實時處理引擎，用于豐富、監控和處理代理活動流

KAMF Stack 共同提供了從孤立機器人到動態、智能化代理生態系統的必要基礎設施。

問題：碎片化的代理，脆弱的基礎設施

如果炒作屬實（現在看來更像是必然而非猜測），大多數公司不會只部署一個 AI 代理，而是會部署數十個。這些代理將編寫代碼、處理支持工單、分析客戶數據、管理入職、監控基礎設施等等。

但今天的工具尚未為這一未來做好準備。

圖片

代理孤島

我們不僅面臨“代理孤島”問題，即代理各自在孤立環境中運行，無法通信，還面臨更廣泛的生態系統碎片化問題：

?代理之間不溝通：每個代理運行在自己的沙箱中。CRM 代理不知道數據倉庫代理剛發現的內容。支持代理無法響應監控代理剛標記的異常。

?工具使用脆弱且定制化：沒有調用工具或外部 API 的標準，代理最終依賴硬編碼集成和不可重用的邏輯。

?框架缺乏一致性：不同的代理運行時使用不同的模型——有些將代理視為聊天機器人，有些視為 DAGs，還有些視為遞歸規劃器。沒有可移植的執行層或共享狀態。

?我們像在筆記本中構建代理：如今的大多數代理被設計成一次性原型——線性、同步且短暫。但真實系統不是筆記本。它們需要處理重試、失敗、協調、日志記錄和擴展。這需要基礎設施。

?缺乏協作支柱：沒有事件總線，沒有共享內存，沒有可追溯的代理行為歷史記錄。一切都被鎖定在直接 HTTP 調用中或埋藏在日志里。

正如 12-Factor Agents 項目所論述，代理需要遵循云原生原則：它們必須是可觀察的、松耦合的、可重現的和基礎設施感知的。但今天，大多數代理被構建為脆弱的腳本，手工拼接，假設在隔離環境中運行。

結果呢？孤島。重復。脆弱。

解決方案不是將所有代理塞進一個單一平臺，而是構建一個共享棧，一個基于開放協議、事件驅動架構和實時處理的新基礎。

Agent2Agent 通過為代理提供發現和通信的通用協議，部分解決了這個問題。但要超越玩具演示，達到生產系統所需的規模和可靠性，我們需要的不僅是協議，還需要基礎設施。

代理如何溝通和行動：A2A 和 MCP 的作用

如前所述，今天的代理生態系統很像早期的網絡：功能強大的系統各自完成有用的工作，但彼此隔離且不兼容。就像瀏覽器曾經難以在沒有標準協議的情況下與服務器通信一樣，今天的 AI 代理無法輕松發現、通信或協作。

Google’s A2A 協議是大膽的嘗試，旨在解決這一問題。它不是另一個代理框架，而是一個通用的協議，旨在連接任何代理，無論由誰構建或在何處運行。

就像 HTTP 標準化了網站通信方式一樣，A2A 為代理定義了共享語言，使它們能夠：

?通過 AgentCard（一個 JSON 描述符，聲明代理的功能和交互方式）宣布能力。

?通過結構化交互（使用 JSON-RPC）發送和接收任務，一個代理請求幫助，另一個以結果或“Artifacts”響應。

?通過 Server-Sent Events (SSE) 流式傳輸更新，支持長時間運行或協作任務的實時反饋。

?交換豐富內容，不僅限于純文本，文件、結構化數據和表單都是 A2A 消息的首要部分。

?默認保持安全，憑借內置對 HTTPS、身份驗證和權限的支持。

A2A 的前景在于它沒有試圖重新發明輪子。它建立在數十年的互聯網協議歷史之上，就像 HTTP 和 SMTP 一樣，利用熟悉的、經過實戰檢驗的網絡標準。這使得采用更容易，集成更快。

但 A2A 只是問題的一半。

Anthropic’s MCP 解決了另一半：代理如何使用工具和訪問上下文。MCP 標準化了代理調用 API、調用函數和與外部系統集成的過程，實質上是它們如何在世界中思考和行動。另一方面，A2A 定義了代理如何相互溝通。

如果說 MCP 是為代理提供工具訪問的能力，那么 A2A 則是為它們提供彼此訪問的能力。

這兩個協議共同為連接的代理生態系統提供了一個藍圖：

?MCP 賦予單個代理智能。

?A2A 實現集體智能。

就像 HTTP 和 SMTP 并非孤立成功一樣，它們需要采用、基礎設施和開發者工具。A2A 和 MCP 也需要一個生態系統來實現其潛力。

但即使有了 A2A 和 MCP 這樣的標準化，一個根本問題依然存在：這些代理通信如何在復雜、動態的企業環境中有效擴展？僅依賴這些協議定義的直接點對點連接會帶來一系列挑戰，特別是在可擴展性、彈性和可觀察性方面。這讓我們需要考慮一個強大的底層通信基礎設施。

為什么協議不夠：事件驅動支柱的需要

想象一下，運營一家公司，每個員工只能通過一對一的直接消息進行溝通。需要分享更新？必須逐一發送消息給每個人。想協調五個團隊的項目？你得手動在每個團隊間傳遞信息。

現在想象將這種方式擴展到數百名員工。混亂不堪。

這正是基于直接連接的代理生態系統所發生的情況。每個代理必須知道與誰溝通、如何聯系以及對方何時可用。隨著代理數量增加，所需連接數量呈指數級增長。系統變得脆弱、難以管理，幾乎無法擴展。

A2A 和 MCP 為代理提供了溝通和行動的語言和結構——但僅語言是不夠的。要在企業中協調數十或數百個代理，你還需要基礎設施來管理這些消息的流動以及代理對它們的反應。

這就是 Apache Kafka 和 Apache Flink 的用武之地。

Kafka 和 Flink 簡介

Apache Kafka 是一個分布式事件流平臺，最初由 LinkedIn 開發，現為 Apache Software Foundation 的一部分。它作為一個持久的、高吞吐量消息總線，允許系統實時發布和訂閱事件流。Kafka 被廣泛應用于金融系統、欺詐檢測、遙測管道等領域，因為它解耦了生產者和消費者，并確保數據持久、可重放和可擴展。

Apache 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 如何協同工作

像 A2A 和 MCP 這樣的協議對于標準化代理行為和通信至關重要。但沒有像 Kafka 這樣的事件驅動基底和像 Flink 這樣的流原生運行時，這些代理仍將局限于孤立交互，無法靈活協調、優雅擴展或隨時間推理。

要完全實現企業級、可互操作 AI 代理的愿景，我們需要四層：

?協議 — A2A、MCP — 定義“是什么”

?框架 — LangGraph、CrewAI、ADK — 定義“如何做”

?消息基礎設施 — Apache Kafka — 支持流動

?實時計算 — Apache Flink — 支持思考

這些共同構成了 AI Agent的新互聯網棧，一個不僅智能，而且協作、可觀察且生產就緒的系統基礎。

圖片

前路：為集體智能而建

我們正處于軟件演變的關鍵時刻。

正如原始互聯網棧、HTTP 和 SMTP 等協議以及 TCP/IP 等基礎設施開啟了全球連接的新時代，一個新的 AI 代理棧正在浮現。但這個棧不是為人類導航頁面或發送電子郵件而構建，而是為自主系統協作推理、決策和行動而構建。

A2A 和 MCP 提供了代理通信和工具使用的協議。Kafka 和 Flink 提供了實時協調、可觀察性和彈性的基礎設施。它們共同使我們從孤立的代理演示轉向可擴展、智能、生產級的生態系統成為可能。

這不僅是解決工程挑戰，而是啟用一種新型軟件，代理跨越邊界協作，洞察和行動實時流動，智能成為分布式系統。

但這一愿景不會自己實現。我們需要以開放、互操作的方式構建它，并銘記上一次互聯網革命的經驗教訓。

所以，下次你構建代理時，不要只問它能做什么。問它如何融入更大系統。它能溝通嗎？能協調嗎？能進化嗎？

因為未來不僅是代理驅動的。

而是Agent互聯的。