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

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

這種情況正在改變。

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

我們稱之為 KAMF Stack：

?Apache Kafka — 用于可靠、解耦協(xié)調(diào)的事件驅(qū)動(dòng)通信結(jié)構(gòu)?Anthropic’s Model Context Protocol (MCP) — 用于工具使用和外部上下文的標(biāo)準(zhǔn)?Google’s Agent2Agent (A2A) — 代理發(fā)現(xiàn)和通信的協(xié)議?Apache Flink — 實(shí)時(shí)處理引擎，用于豐富、監(jiān)控和處理代理活動(dòng)流

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

如果您喜歡請關(guān)注公眾號：

問題：碎片化的代理，脆弱的基礎(chǔ)設(shè)施

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

但今天的工具尚未為這一未來做好準(zhǔn)備。

代理孤島

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

?代理之間不溝通：每個(gè)代理運(yùn)行在自己的沙箱中。CRM 代理不知道數(shù)據(jù)倉庫代理剛發(fā)現(xiàn)的內(nèi)容。支持代理無法響應(yīng)監(jiān)控代理剛標(biāo)記的異常。?工具使用脆弱且定制化：沒有調(diào)用工具或外部 API 的標(biāo)準(zhǔn)，代理最終依賴硬編碼集成和不可重用的邏輯。?框架缺乏一致性：不同的代理運(yùn)行時(shí)使用不同的模型——有些將代理視為聊天機(jī)器人，有些視為 DAGs，還有些視為遞歸規(guī)劃器。沒有可移植的執(zhí)行層或共享狀態(tài)。?我們像在筆記本中構(gòu)建代理：如今的大多數(shù)代理被設(shè)計(jì)成一次性原型——線性、同步且短暫。但真實(shí)系統(tǒng)不是筆記本。它們需要處理重試、失敗、協(xié)調(diào)、日志記錄和擴(kuò)展。這需要基礎(chǔ)設(shè)施。?缺乏協(xié)作支柱：沒有事件總線，沒有共享內(nèi)存，沒有可追溯的代理行為歷史記錄。一切都被鎖定在直接 HTTP 調(diào)用中或埋藏在日志里。

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

結(jié)果呢？孤島。重復(fù)。脆弱。

解決方案不是將所有代理塞進(jìn)一個(gè)單一平臺(tái)，而是構(gòu)建一個(gè)共享?xiàng)?，一個(gè)基于開放協(xié)議、事件驅(qū)動(dòng)架構(gòu)和實(shí)時(shí)處理的新基礎(chǔ)。

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

代理如何溝通和行動(dòng)：A2A 和 MCP 的作用

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

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

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

?通過 AgentCard（一個(gè) JSON 描述符，聲明代理的功能和交互方式）宣布能力。?通過結(jié)構(gòu)化交互（使用 JSON-RPC）發(fā)送和接收任務(wù)，一個(gè)代理請求幫助，另一個(gè)以結(jié)果或“Artifacts”響應(yīng)。?通過 Server-Sent Events (SSE) 流式傳輸更新，支持長時(shí)間運(yùn)行或協(xié)作任務(wù)的實(shí)時(shí)反饋。?交換豐富內(nèi)容，不僅限于純文本，文件、結(jié)構(gòu)化數(shù)據(jù)和表單都是 A2A 消息的首要部分。?默認(rèn)保持安全，憑借內(nèi)置對 HTTPS、身份驗(yàn)證和權(quán)限的支持。

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

但 A2A 只是問題的一半。

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

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

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

?MCP 賦予單個(gè)代理智能。?A2A 實(shí)現(xiàn)集體智能。

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

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

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

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

現(xiàn)在想象將這種方式擴(kuò)展到數(shù)百名員工?；靵y不堪。

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

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

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

Kafka 和 Flink 簡介

Apache Kafka 是一個(gè)分布式事件流平臺(tái)，最初由 LinkedIn 開發(fā)，現(xiàn)為 Apache Software Foundation 的一部分。它作為一個(gè)持久的、高吞吐量消息總線，允許系統(tǒng)實(shí)時(shí)發(fā)布和訂閱事件流。Kafka 被廣泛應(yīng)用于金融系統(tǒng)、欺詐檢測、遙測管道等領(lǐng)域，因?yàn)樗怦盍松a(chǎn)者和消費(fèi)者，并確保數(shù)據(jù)持久、可重放和可擴(kuò)展。

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

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

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

正如 A2A 成為代理世界的 HTTP，Kafka 和 Flink 構(gòu)成了支持可擴(kuò)展代理通信和計(jì)算的事件驅(qū)動(dòng)基礎(chǔ)。它們解決了直接點(diǎn)對點(diǎn)通信無法解決的問題：

?解耦：通過 Kafka，代理無需知道誰將消費(fèi)它們的輸出。它們將事件（例如“TaskCompleted”、“InsightGenerated”）發(fā)布到主題，任何感興趣的代理或系統(tǒng)都可以訂閱。?可觀察性和可重放性：Kafka 維護(hù)每個(gè)事件的持久、時(shí)間有序日志，使代理行為完全可追溯、可審計(jì)和可重放。?實(shí)時(shí)決策：Flink 使代理能夠?qū)崟r(shí)響應(yīng)事件流，基于動(dòng)態(tài)條件進(jìn)行過濾、豐富、連接或觸發(fā)操作。?彈性和擴(kuò)展：Flink 作業(yè)可以獨(dú)立擴(kuò)展，從失敗中恢復(fù)，并在長時(shí)間運(yùn)行的工作流中保持狀態(tài)。這對于執(zhí)行復(fù)雜、多步驟任務(wù)的代理至關(guān)重要。?流原生協(xié)調(diào)：代理無需等待同步響應(yīng)，可以通過事件流協(xié)調(diào)，發(fā)布更新、訂閱工作流并協(xié)作推進(jìn)狀態(tài)。

簡而言之：

?A2A 定義代理如何溝通。?MCP 定義它們?nèi)绾尾僮魍獠抗ぞ摺?Kafka 定義消息如何流動(dòng)。?Flink 定義這些流動(dòng)如何被處理、轉(zhuǎn)換并轉(zhuǎn)化為決策。

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

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

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

?協(xié)議 — A2A、MCP — 定義“是什么”?框架 — LangGraph、CrewAI、ADK — 定義“如何做”?消息基礎(chǔ)設(shè)施 — Apache Kafka — 支持流動(dòng)?實(shí)時(shí)計(jì)算 — Apache Flink — 支持思考

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

前路：為集體智能而建

我們正處于軟件演變的關(guān)鍵時(shí)刻。

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

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

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

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

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

因?yàn)槲磥聿粌H是代理驅(qū)動(dòng)的。

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

本文轉(zhuǎn)載自??PyTorch研習(xí)社??，作者：PyTorch研習(xí)社