AI Agent新堆棧來襲！Google的A2A協議、Anthropic的MCP協議，加上Apache Kafka和Apache Flink，構建云原生Agent互聯互通的未來。擺脫Agent孤島，實現實時、可觀測、可擴展的智能生態系統，速來圍觀！

譯自：A2A, MCP, Kafka and Flink: The New Stack for AI Agents[1]

作者：Sean Falconer

在 Web 出現超文本傳輸協議 (HTTP) 之前，在電子郵件出現簡單郵件傳輸協議 (SMTP) 之前，我們一直受困于自定義集成、碎片化系統和脆弱的工作流程。直到開放協議和共享基礎設施出現，互聯網才真正實現了規模化，解鎖了現代 Web、全球通信和整個經濟體。

今天，AI agent[2] 也處于這個預標準化階段。它們功能強大、能力出色且數量快速增長，但它們無法協同工作。一個 agent 分析數據。另一個 agent 起草代碼。第三個 agent 自動化客戶關系管理 (CRM) 工作流程。但它們是孤立的、各自為政的，并且不知道彼此的存在。

這種情況正在開始改變。

一個新的堆棧正在涌現，以支持互聯網的下一層——這一層不是為瀏覽網站的人類而構建，而是為跨系統協作的自主 agent 而構建。其核心是四個開放組件：

• ? 用于 agent 發現和通信的協議。Google 的 Agent2Agent (A2A)[3]
• ? 用于工具使用和外部上下文的標準。Anthropic 的模型上下文協議 (MCP)[4]
• ? 用于可靠、解耦協調的事件驅動通信結構。Apache Kafka[5]
• ? 用于豐富、監控和處理 agent 活動流的實時處理引擎。Apache Flink[6]

讓我們探討一下這些技術如何協同工作，為什么僅靠協議是不夠的，以及這個新堆棧如何提供從斷開連接的機器人到動態、智能 agent 生態系統所需的基礎設施。

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

如果炒作是正確的——而且它看起來更像是不可避免的，而不是猜測——大多數公司不會只部署一個 AI agent；他們會部署幾十個。這些 agent 將編寫代碼、分類支持請求、分析客戶數據、管理入職、監控基礎設施等等。

但今天的工具還沒有為那個未來做好準備。

Agent 孤島 (來源: Confluent)

我們不僅面臨“Agent 孤島”問題[7]，即 agent 在孤島中運行且無法通信；我們還面臨著更廣泛的生態系統碎片化問題：

? Agent 之間不通信：每個 agent 都在自己的沙箱中運行。CRM agent 不知道數據倉庫 agent 剛剛發現了什么。支持 agent 無法響應監控 agent 剛剛標記的相同異常。

? 工具使用是脆弱且定制的：如果沒有調用工具或外部 API 的標準，agent 最終會使用硬編碼的集成和不可重用的邏輯。

? 框架缺乏一致性：不同的 agent 運行時使用不同的模型——有些將 agent 視為聊天機器人，有些將 agent 視為有向無環圖 (DAG)，有些將 agent 視為遞歸規劃器。沒有可移植的執行層或共享狀態。

? 我們構建的方式好像 agent 存在于筆記本中：今天的大多數 agent 都被設計成一次性原型——線性的、同步的和短暫的。但真正的系統不是筆記本。它們需要處理重試、故障、協調、日志記錄和擴展。這需要基礎設施。

? 沒有協作的骨干：沒有事件總線，沒有共享內存，沒有 agent 所做的事情或原因的可追溯歷史。一切都鎖定在直接 HTTP 調用中或埋在日志中。

正如 12-Factor Agents[8] 項目所認為的那樣，agent 需要遵循云原生原則：它們必須是可觀測的、松散耦合的、可重現的和基礎設施感知的。但今天，大多數 agent 都是作為脆弱的腳本構建的，由手工拼接在一起，并假定它們是孤立運行的。

結果是什么？孤島。重復。脆弱性。

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

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

Agent 如何對話和行動：A2A 和 MCP

正如前面提到的，今天的 Agent 生態系統很像早期的 Web：強大的系統，每個都在做有用的工作，但都是孤立且不兼容的。就像瀏覽器曾經在沒有標準協議的情況下難以與服務器通信一樣，今天的 AI Agent 也不能輕易地發現、通信或相互協作。

Google 的 A2A 協議是一項大膽的嘗試，旨在解決這個問題。它不是另一個 Agent 框架：它是一個通用協議，旨在連接任何 Agent，無論誰構建的它或它在哪里運行。

就像 HTTP 標準化了網站的通信方式一樣，A2A 定義了一種 Agent 之間的共享語言。它允許它們：

? 通過AgentCard 宣布功能，這是一個 JSON 描述符，用于聲明 Agent 可以做什么以及如何與之交互。

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

? 使用服務器發送事件 (SSEs) 流式傳輸更新，從而在長時間運行或協作任務期間實現實時反饋。

? 交換富內容。文件、結構化數據和表單——而不僅僅是純文本——都是 A2A 消息的一流組成部分。

? 默認情況下保持安全，這要歸功于對 HTTPS、身份驗證和權限的內置支持。

A2A 的前景在于它沒有試圖重新發明輪子。它借鑒了數十年的互聯網協議歷史，就像 HTTP 和 SMTP 所做的那樣，利用了熟悉的、經過實戰考驗的 Web 標準。這使得采用更容易，集成更快。

但 A2A 只是整個圖景的一半。

Anthropic 的 MCP 解決了另一半：Agent 如何使用工具和訪問上下文。MCP 標準化了 Agent 如何調用 API、調用函數以及與外部系統集成——本質上，它們如何在世界中思考和行動。另一方面，A2A 定義了 Agent 之間如何相互交談。

如果說 MCP 是關于讓 Agent 訪問工具，那么 A2A 就是關于讓他們訪問彼此。

這兩個協議共同為互聯的 Agent 生態系統提供了一個藍圖：

? MCP為單個 Agent 提供智能。

? A2A實現集體智能。

正如 HTTP 和 SMTP 沒有孤立地成功一樣，它們需要采用、基礎設施和開發者工具，A2A 和 MCP 也需要一個生態系統來實現它們的潛力。

但是，即使有了像 A2A 和 MCP 這樣的標準化，一個根本問題仍然存在：這些 Agent 通信如何在復雜、動態的企業環境中有效地擴展？僅僅依靠這些協議定義的直接、點對點連接會帶來自身的一系列挑戰，尤其是在可擴展性、彈性和可觀測性方面。 這使我們認識到需要一個強大的底層通信基礎設施。

我們需要一個事件驅動的骨干，而不僅僅是協議

想象一下，經營一家公司，每個員工只能通過發送直接的、一對一的消息進行溝通。需要分享更新？您必須單獨向每個人發送消息。想要協調五個團隊的項目？您會被困在手動在每個團隊之間傳遞信息。

現在想象一下，嘗試將其擴展到數百名員工。混亂。

這正是構建在直接連接上的 Agent 生態系統中發生的事情。每個 Agent 必須知道與誰交談、如何聯系他們以及他們何時可用。隨著 Agent 數量的增長，所需連接的數量呈指數增長。系統變得脆弱、難以管理且幾乎不可能擴展。

A2A 和 MCP 為 Agent 提供了溝通和行動的語言和結構，但僅有語言是不夠的。為了協調企業中的數十個或數百個 Agent，您還需要基礎設施來支持這些消息的移動方式以及 Agent 如何對它們做出反應。

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

Kafka 和 Flink：快速入門

Apache Kafka[10] 是一個分布式事件流平臺，最初由 LinkedIn 開發，現在是 Apache 軟件基金會的一部分。它充當持久、高吞吐量的消息總線，允許系統實時發布和訂閱事件流。Kafka 被廣泛使用，從金融系統到欺詐檢測再到遙測管道，因為它將生產者與消費者分離，并確保數據[11]是持久的、可重放的和可擴展的。Flink[12], 同樣也是一個 Apache 項目，是一個實時流處理引擎。它從一開始就被設計用于有狀態、高吞吐量、低延遲的事件處理。Kafka 負責數據的移動，而 Flink 負責在數據流經系統時對其進行轉換、豐富、監控和編排。它們共同構成了一個強大的組合：Kafka 是血液，Flink 是反射系統。

Kafka 和 Flink：Agent 生態系統的基礎設施

正如 A2A 正在成為 agent 世界的 HTTP 一樣，Kafka 和 Flink 構成了事件驅動的基礎，可以支持可擴展的 agent 通信和計算。它們解決了直接的點對點通信無法解決的問題：

? 解耦：使用 Kafka，agent 不需要知道誰將消費它們的輸出。它們將事件（例如，"TaskCompleted", "InsightGenerated"）發布到主題；任何感興趣的 agent 或系統都可以訂閱。

? 可觀測性和可重放性：Kafka 維護每個事件的持久、按時間排序的日志，使 agent 行為完全可追溯、可審計和可重放。

? 實時決策：Flink 使 agent 能夠實時響應事件流[13]，根據動態條件過濾、豐富、連接或觸發操作。

? 彈性和擴展：Flink 作業可以獨立擴展、從故障中恢復并在長時間運行的工作流中保持狀態。這對于執行復雜的多步驟任務的 agent 至關重要。

? 流原生協調：agent 可以通過事件流進行協調，發布更新、訂閱工作流并協同推進狀態，而不是等待同步響應。

簡而言之：

? A2A 定義了 agent 如何說話。

? MCP 定義了它們如何對外部工具采取行動。

? Kafka 定義了它們的消息如何流動。

? Flink 定義了這些流如何被處理、轉換并轉化為決策。

A2A、MCP、Kafka 和 Flink 如何協同工作

像 A2A 和 MCP 這樣的協議對于標準化 agent 行為和通信至關重要。但是，如果沒有像 Kafka 這樣的事件驅動底層和像 Flink 這樣的流原生運行時，這些 agent 仍然會陷入孤立的交互中，無法靈活地協調、優雅地擴展或隨著時間的推移進行推理。

為了充分實現企業級、可互操作的 AI agent 的愿景，我們需要四個層次：

? 協議：A2A, MCP – 定義什么。

? 框架：LangGraph, CrewAI, ADK – 定義如何。

? 消息傳遞基礎設施：Apache Kafka – 支持流動。

? 實時計算：Apache Flink – 支持思考。

總而言之，這是 AI agent 的新互聯網堆棧——構建不僅智能，而且協作、可觀測和可用于生產的系統的基礎。

架構圖：A2A、MCP、Kafka 和 Flink 如何協同工作

A2A、MCP、Kafka 和 Flink 如何協同工作。（來源：Confluent）

前進的道路：構建集體智能

我們正處于軟件發展的關鍵時刻。

正如最初的互聯網堆棧——像 HTTP 和 SMTP 這樣的協議，以及像 TCP/IP 這樣的基礎設施——開啟了全球互聯互通的新時代一樣，一個新的堆棧正在為 AI agent 涌現。但與人類瀏覽頁面或發送電子郵件不同，這個堆棧是為自主系統協同工作以進行推理、決策和行動而構建的。

A2A 和 MCP 提供了 agent 通信和工具使用的協議。Kafka 和 Flink 提供了實時協調、可觀測性和彈性的基礎設施。它們共同使得從斷開連接的 agent 演示到可擴展的、智能的生產級生態系統的轉變成為可能。

這不僅僅是解決工程挑戰。這是關于啟用一種新型軟件，其中 agent 跨越邊界進行協作，實時提供洞察和行動流，從而使智能成為一個分布式系統。

但是這個愿景不會自行實現。我們需要構建它：開放地、可互操作地，并牢記上次互聯網革命的教訓。

因此，下次您構建 agent 時，不要只問它能做什么。問問它如何適應更大的系統。它能溝通嗎？它能協調嗎？它能進化嗎？

因為未來不僅僅是 agent 驅動的；它是 agent 連接的。

引用鏈接

[1] A2A, MCP, Kafka and Flink: The New Stack for AI Agents:https://thenewstack.io/a2a-mcp-kafka-and-flink-the-new-stack-for-ai-agents/

[2]AI agent:https://thenewstack.io/ai-agents-a-comprehensive-introduction-for-developers/

[3]Google 的 Agent2Agent (A2A):https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/[4]Anthropic 的模型上下文協議 (MCP):https://thenewstack.io/model-context-protocol-a-primer-for-the-developers/[5]Apache Kafka:https://kafka.apache.org/

[6]Apache Flink:https://flink.apache.org/

[7]“Agent 孤島”問題:https://medium.com/@seanfalconer/the-ai-silo-problem-how-data-streaming-can-unify-enterprise-ai-agents-0a138cf6398c

[8]12-Factor Agents:https://github.com/humanlayer/12-factor-agents

[9]Apache Kafka 和 Apache Flink:https://thenewstack.io/building-a-meal-planning-agent-with-apache-kafka-and-flink

[10]Apache Kafka:https://www.confluent.io/lp/apache-kafka/?utm_medium=sem&utm_source=google&utm_campaign=ch.sem_br.nonbrand_tp.prs_tgt.kafka_mt.xct_rgn.namer_sbrgn.unitedstates_lng.eng_dv.all_con.kafka-what-is_term.what-is-apache-kafka&utm_term=what%20is%20apache%20kafka&creative=&device=c&placement=&gad_source=1&gbraid=0AAAAADRv2c0xMf9u9gysZ9gIjG7xOxO7U&gclid=Cj0KCQjw_JzABhC2ARIsAPe3ynpCOCYZ1DXfQO31ozymoakcUf_1NqNVBaKF0U7DNqQkc2-ZPmFMlpYaAoKmEALw_wcB

[11]確保數據:https://thenewstack.io/how-to-handle-bad-data-in-event-streams/

[12]Flink:https://www.confluent.io/learn/apache-flink/

[13]實時響應事件流:https://thenewstack.io/real-time-ai-apps-using-apache-flink-for-model-inference/