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

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

這種情況正在改變。

一個新的開放棧正在浮現(xiàn)，以支持互聯(lián)網(wǎng)的下一層，這層不是為人類瀏覽網(wǎng)站而構建，而是為跨系統(tǒng)協(xié)作的自主代理而構建。

我們稱之為 KAMF Stack：

?Apache Kafka — 用于可靠、解耦協(xié)調(diào)的事件驅(qū)動通信結構

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

?Google’s Agent2Agent (A2A) — 代理發(fā)現(xiàn)和通信的協(xié)議

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

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

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

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

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

圖片

代理孤島

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

?代理之間不溝通：每個代理運行在自己的沙箱中。CRM 代理不知道數(shù)據(jù)倉庫代理剛發(fā)現(xiàn)的內(nèi)容。支持代理無法響應監(jiān)控代理剛標記的異常。

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

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

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

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

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

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

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

Agent2Agent 通過為代理提供發(fā)現(xiàn)和通信的通用協(xié)議，部分解決了這個問題。但要超越玩具演示，達到生產(chǎn)系統(tǒng)所需的規(guī)模和可靠性，我們需要的不僅是協(xié)議，還需要基礎設施。

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

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

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

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

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

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

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

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

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

A2A 的前景在于它沒有試圖重新發(fā)明輪子。它建立在數(shù)十年的互聯(lián)網(wǎng)協(xié)議歷史之上，就像 HTTP 和 SMTP 一樣，利用熟悉的、經(jīng)過實戰(zhàn)檢驗的網(wǎng)絡標準。這使得采用更容易，集成更快。

但 A2A 只是問題的一半。

Anthropic’s MCP 解決了另一半：代理如何使用工具和訪問上下文。MCP 標準化了代理調(diào)用 API、調(diào)用函數(shù)和與外部系統(tǒng)集成的過程，實質(zhì)上是它們?nèi)绾卧谑澜缰兴伎己托袆?。另一方面，A2A 定義了代理如何相互溝通。

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

這兩個協(xié)議共同為連接的代理生態(tài)系統(tǒng)提供了一個藍圖：

?MCP 賦予單個代理智能。

?A2A 實現(xiàn)集體智能。

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

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

為什么協(xié)議不夠：事件驅(qū)動支柱的需要

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

現(xiàn)在想象將這種方式擴展到數(shù)百名員工。混亂不堪。

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

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

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

Kafka 和 Flink 簡介

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

Apache Flink 也是 Apache 項目，是一個實時流處理引擎。它從一開始就為有狀態(tài)、高吞吐量、低延遲的事件處理設計。Kafka 負責數(shù)據(jù)移動，F(xiàn)link 負責數(shù)據(jù)在系統(tǒng)流動時的轉換、豐富、監(jiān)控和編排。

它們一起形成強大的組合：Kafka 是血流，F(xiàn)link 是反射系統(tǒng)。

Kafka 和 Flink：代理生態(tài)系統(tǒng)的基礎設施

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

?解耦：通過 Kafka，代理無需知道誰將消費它們的輸出。它們將事件（例如“TaskCompleted”、“InsightGenerated”）發(fā)布到主題，任何感興趣的代理或系統(tǒng)都可以訂閱。

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

?實時決策：Flink 使代理能夠?qū)崟r響應事件流，基于動態(tài)條件進行過濾、豐富、連接或觸發(fā)操作。

?彈性和擴展：Flink 作業(yè)可以獨立擴展，從失敗中恢復，并在長時間運行的工作流中保持狀態(tài)。這對于執(zhí)行復雜、多步驟任務的代理至關重要。

?流原生協(xié)調(diào)：代理無需等待同步響應，可以通過事件流協(xié)調(diào)，發(fā)布更新、訂閱工作流并協(xié)作推進狀態(tài)。

簡而言之：

?A2A 定義代理如何溝通。

?MCP 定義它們?nèi)绾尾僮魍獠抗ぞ摺?/p>

?Kafka 定義消息如何流動。

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

A2A、MCP、Kafka 和 Flink 如何協(xié)同工作

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

要完全實現(xiàn)企業(yè)級、可互操作 AI 代理的愿景，我們需要四層：

?協(xié)議 — A2A、MCP — 定義“是什么”

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

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

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

這些共同構成了 AI Agent的新互聯(lián)網(wǎng)棧，一個不僅智能，而且協(xié)作、可觀察且生產(chǎn)就緒的系統(tǒng)基礎。

圖片

前路：為集體智能而建

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

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

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

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

但這一愿景不會自己實現(xiàn)。我們需要以開放、互操作的方式構建它，并銘記上一次互聯(lián)網(wǎng)革命的經(jīng)驗教訓。

所以，下次你構建代理時，不要只問它能做什么。問它如何融入更大系統(tǒng)。它能溝通嗎？能協(xié)調(diào)嗎？能進化嗎？

因為未來不僅是代理驅(qū)動的。

而是Agent互聯(lián)的。