編譯 | 云昭

出品 | 51CTO技術棧（微信號：blog51cto）

智能體（Agent）是個不可逆的趨勢。但今天的AI 智能體似乎還處于一個“前標準化”階段。

這些雨后春筍般的智能體越來越多，性能強大、增長迅速，但彼此之間卻無法協作——有的智能體用來分析數據，有的用來編寫代碼，有的用來自動化客戶關系管理（CRM）工作流，但它們彼此孤立，互不往來。

這就好比幾十年前的互聯網：在萬維網出現HTTP協議之前，在電子郵件擁有SMTP協議之前，我們曾陷于定制集成、系統碎片化和脆弱工作流的困境中。

直到開放協議與共享基礎設施的出現，互聯網才真正實現了規模化，催生了現代網絡、全球通信和全新經濟體。

不過，這種狀況正在發生改變。

一個新的技術棧正在形成，它支撐著下一代“互聯網”的發展——這次不是為了人類瀏覽網頁，而是為了自治的智能體在系統之間協作。核心由四個開放組件組成：

• Google 的 Agent2Agent（A2A）：一種智能體發現和通信協議
• Anthropic 的 Model Context Protocol（MCP）：用于工具使用與外部上下文訪問的標準
• Apache Kafka：一個事件驅動的通信結構，提供可靠、解耦的協調機制
• Apache Flink：一個實時處理引擎，用于豐富、監控并響應智能體活動流

本文中，我們將探討這些技術如何協同工作，為何僅靠協議還不夠，以及這個新棧如何提供從孤立機器人走向動態、智能協作生態所需的基礎設施。

1.問題：碎片化的智能體，脆弱的基礎設施

至少現在看來，智能體看起來是一個不可逆的趨勢。而且，大多數公司將不僅部署一個AI智能體，而是幾十個。這些智能體將編寫代碼、分類支持工單、分析客戶數據、管理員工入職、監控基礎設施等等。

但當下的工具鏈尚未為這一未來做好準備。

Agent孤島 （圖源：confluent）

那么，問題來了：

• 智能體彼此無法通信：每個智能體運行在自己的“沙盒”中，CRM 智能體不知道數據倉庫智能體剛發現了什么，客服智能體無法響應監控智能體剛剛標記的異常。
• 工具使用方式脆弱且定制化嚴重：沒有統一的方式來調用工具或 API，結果就是集成方式硬編碼、邏輯不可重用。
• 框架不一致：不同的運行時以不同方式構建智能體——有的像聊天機器人，有的像DAG（有向無環圖），有的像遞歸規劃器。沒有可移植的執行層，也沒有共享狀態。
• 智能體被當作一次性腳本開發：它們通常是線性、同步、短暫的原型，但現實系統需要處理重試、失敗、協調、日志和擴展能力，這些都需要基礎設施。
• 缺乏協作主干：沒有事件總線、共享內存或可追蹤的行為歷史。一切都鎖定在直接的HTTP調用中，或者深埋于日志中。

結果就是：信息孤島、重復建設、系統脆弱。那該怎么辦？

解決方案不是打造一個巨型平臺，而是構建一個開放協議、事件驅動架構與實時處理組成的共享技術棧。

2.A2A與MCP：智能體如何“對話”與“行動”

今天的智能體生態就像早期互聯網：每個系統都能完成有用的工作，但彼此孤立、不兼容。就像沒有HTTP的瀏覽器無法與服務器交流一樣，AI智能體也無法輕松發現彼此或協作。

Google 的 A2A 協議試圖改變這一點：它不是另一個智能體框架，而是一個通用協議，無論由誰構建、運行在哪，任何智能體都能連接。

A2A 就像 HTTP 一樣，為智能體定義了一種共享語言，讓它們可以：

• 通過 AgentCard（JSON 格式）宣布自身能力和交互方式；
• 使用結構化交互（基于 JSON-RPC）發送任務請求，并接收結果或產出；
• 利用 SSE（Server-Sent Events）推送任務狀態，實現實時反饋；
• 交換富內容（文件、結構化數據、表單等）；
• 通過 HTTPS、安全認證與權限控制，確保默認安全。

A2A 的優勢在于：它并不重造輪子，而是復用 HTTP、SMTP 等標準的成熟經驗，易于集成和推廣。但這只是其中一半。

Anthropic 的 MCP 解決的是智能體如何使用工具、調用 API 和訪問上下文的問題，也就是智能體如何“行動”。它標準化了函數調用、外部集成、上下文注入等行為。

可以理解為：

• MCP 是智能體的“工具箱”；
• A2A 是智能體的“對話協議”。

二者結合，構建出智能體網絡的藍圖：

• MCP 提供單體智能（individual intelligence）；
• A2A 激發群體智能（collective intelligence）。

但光有協議還不夠。要在企業環境中支撐成百上千個智能體協作，還需要強大的通信基礎設施。

3.除了協議，誰來當事件驅動的主干？

想象一下，如果一家公司所有員工只能通過私聊來溝通，一個個單獨發消息來協調項目，信息同步將變得混亂不堪，無法擴展。

這正是智能體生態系統在缺乏消息主干時的困境。

每個智能體都要手動知道對方是誰、在哪、是否在線——這會迅速變得難以管理。

這時，Apache Kafka 和 Apache Flink 就登場了。眾所周知，Kafka是一個高吞吐、持久化的分布式事件流平臺，用于發布/訂閱實時事件流，具有解耦生產者與消費者、可重放、易擴展等特點。而Flink作為實時流式計算引擎，支持狀態管理、高吞吐、低延遲的事件處理，可對流進行過濾、聚合、觸發動作等。

二者搭配起來，非常如魚得水——Kafka 好比血液循環系統；Flink則是神經反射系統。Kafka 加上 Flink就會為智能體生態提供基礎設施。

Kafka 和 Flink 提供了解決協議通信難題的“基礎支撐”：

• 解耦通信：智能體發布事件（如“任務完成”、“發現洞察”）到 Kafka 主題，訂閱者無需提前知道發送者是誰。
• 可觀測性與可重放性：Kafka 日志是時間有序、可追蹤、可重放的。
• 實時決策：Flink 可實時響應流事件，動態過濾、聚合、觸發下一步操作。
• 容錯與擴展：Flink 可橫向擴展，保持狀態，支持長任務的中斷恢復。
• 流原生協作：智能體通過事件流異步協作，不必同步阻塞。

A2A, MCP, Kafka,Flink 協作一覽（圖源：confluent）

總結如下：

4.未來：構建智能體互聯網

我們正站在軟件演化的關鍵節點。

正如互聯網協議（如HTTP、SMTP）與基礎設施（如TCP/IP）曾開啟全球互聯的新時代，如今的A2A、MCP、Kafka、Flink，也在構建一個全新的“智能體互聯網”。

這個新技術棧不再為人類瀏覽頁面而設計，而是為自治系統之間的推理、決策與行動而生。

• A2A與MCP 提供通信與工具標準；
• Kafka與Flink 提供實時協調、觀測與彈性基礎；
• 框架如 LangGraph、CrewAI、ADK 則實現“如何構建”的標準化。

未來不是單一智能體的堆砌，而是智能體之間的連接、協作與演化。

下次你在構建智能體時，不僅要問：它能做什么？更要問：它能否溝通？能否協調？能否進化？

因為未來不是“智能體驅動”，而是“智能體協同”。

參考鏈接： ?? https://thenewstack.io/a2a-mcp-kafka-and-flink-the-new-stack-for-ai-agents/??

?本文轉載自??51CTO技術棧??，作者：云昭