AI 智能體應用在企業實際落地越來越多，一個完整的 AI 智能體應用系統通常包含三個主要角色：用戶、AI 智能體和外部工具。AI 智能體架構設計的核心任務之一，就是解決這三個角色之間的溝通問題。

這三個角色的溝通，涉及到：MCP 協議、A2A 協議和 AG-UI 協議。其中，MCP 協議解決 AI  智能體和外部工具的標準化交互問題；A2A 協議解決 AI 智能體間的標準通信問題；AG-UI 解決前端應用（比如：APP）和 AI 智能體間的標準交互的問題。

下文詳細剖析之。

一、MCP 協議架構設計

MCP（模型上下文協議）是由 Anthropic 定義的一個開放協議，標準化應用程序如何為大語言模型（LLM）提供上下文。更具體地說，它試圖標準化基于 LLM 的應用程序與其他環境集成的協議。

在 AI Agent 系統（Agentic Systems）中，上下文可以通過多種方式提供：

1、外部數據：這是長期記憶的一部分。

2、工具：系統與環境交互的能力。

3、動態提示詞：可以作為系統提示詞（System Prompt）的一部分注入。

第一、為什么要標準化？

目前，AI Agent 應用的開發流程很混亂：

    1、有許多 AI 智能體框架存在細微差異。雖然看到生態系統蓬勃發展令人鼓舞，但這些細微差異很少能帶來足夠的價值，但可能會顯著改變你的代碼編寫方式。

    2、與外部數據源的集成通常是臨時實現的，并且使用不同的協議，即使在組織內部也是如此。對于不同公司來說，這顯然是如此。

    2、工具在代碼庫中以略微不同的方式定義。如何將工具附加到增強型 LLM 上也是不同的。

目標是提高我們創新 AI 智能體應用的速度、安全性以及將相關數據帶入上下文的便利性。

第二、MCP 協議架構設計

    1、MCP Host：使用 LLM 為核心并希望通過 MCP 訪問數據的程序。

    2、MCP Client：與 MCP Server 保持1:1連接的客戶端。

    3、MCP Server：每個 MCP Server 都通過標準化的模型上下文協議公開特定功能的輕量級程序。

    4、Local Data Sources：你計算機上的文件、數據庫和服務，MCP Server 可以安全訪問。

    5、Remote Data Sources：通過互聯網可用的外部系統（比如：通過 API），MCP Server 可以連接到這些系統。

第三、通過 MCP 分離控制責任

MCP Server 公開三個主要元素（Prompts、Resoures、Tools），這些元素是有意設計的，以幫助實現特定的控制分離。

1、Prompts 提示詞被設計為用戶控制的。后端的程序員可以公開特定的提示詞（適用于與后端服務公開的數據交互），這些提示詞可以注入到使用 LLM 的應用程序中，并暴露給給定應用程序的用戶。

2、Resoures 資源被設計為應用程序控制的。Resources 資源是任何可以被利用 LLM 構建的應用程序使用的數據（文本或二進制）。應用程序的程序員（通常是 AI 應用開發工程師）負責將這些信息編碼到應用程序中。通常，這里沒有自動化，LLM 不參與此選擇。

3、Tools 工具被設計為大模型控制的。如果我們賦予應用程序如何與環境交互的代理權，我們使用 Tools 工具來實現這一點。MCP Server 公開一個端點，可以列出所有可用 Tools 工具及其描述和所需參數，應用程序可以將此列表傳遞給 LLM，以便它決定哪些 Tools 工具適用于手頭的任務以及如何調用它們。

二、A2A 協議架構設計

第一、為什么會有 A2A？

現在越來越清楚，未來的 AI 智能體系統（Agentic Systems）將是多 AI 智能體的。而且，這些 AI 智能體會在彼此之間遠程協作，每個 AI 智能體都可能使用不同的 AI 智能體框架（比如：LangGraph、AutoGen、CrewAI、Agent Development Kit 等）來實現。

這里面有3個固有的問題：

    1、不同框架實現的 AI 智能體系統之間，不支持系統狀態的轉移和交換。

    2、遠程 AI 智能體之間也無法轉移系統狀態。

    3、離線的 AI 智能體不共享工具、上下文和內存（包括系統狀態）。

第二、A2A 解決方案

A2A 是一個開放協議，它為 AI 智能體之間提供了一種標準方式，無論底層開發框架或供應商如何，都可以進行協作。

根據谷歌的官方文檔： A2A 協議促進了“客戶端”和“遠程” AI 智能體之間的通信。

簡單來說，“客戶端” AI 智能體創建任務并與“遠程” AI 智能體溝通，期望執行某些工作或返回數據。

第三、A2A 架構設計

    1、能力發現：所有實現 A2A 的 AI 智能體都通過“Agent Card”公開其能力目錄。這有助于其他 AI 智能體發現給定 AI 智能體實現的潛在有用功能。

    2、任務管理：通信協議，使得短期和長期任務變得更容易。它幫助通信中的 AI 智能體保持同步，直到請求的任務完成并返回答案。這很重要，因為有些 AI 智能體可能需要很長時間來執行工作，而且目前沒有統一標準如何等待這種情況發生。

    3、協作：AI 智能體可以相互發送消息以傳達上下文、回復、工件或用戶指令。

    4、用戶體驗協商：這是一個很有趣的功能。它允許協商數據返回的格式，以符合用戶界面的期望（比如：圖像、視頻、文本等）。

通過 A2A 公開的 AI 智能體的發現是一個重要話題。谷歌建議使用統一的位置來存儲組織的“Agent Card”。

比如：

https://<DOMAIN>/<agreed-path>/agent.json

這并不意外，因為谷歌將處于最佳位置，能夠索引全球所有可用的 AI 智能體，可能創建一個類似于當前搜索引擎索引的全球 AI 智能體目錄。

我喜歡 A2A 強調無需重新發明輪子，并且建立在現有標準之上：

    1、該協議建立在現有、流行的標準之上，包括：HTTP、SSE、JSON-RPC，這意味著它更容易與企業日常使用的現有 IT 堆棧集成。

    2、默認安全 - A2A 旨在支持企業級身份驗證和授權，與 OpenAPI 的身份驗證方案相當。

三、AG-UI 協議架構設計

第一、為什么需要 AG-UI？

每個 AI 智能體后端都有自己的工具調用、ReAct 樣式規劃、狀態差異和輸出格式機制。

如果你使用 LangGraph，前端將實現自定義的 WebSocket 邏輯、雜亂的 JSON 格式和特定于 LangGraph 的 UI 適配器。

但要遷移到 CrewAI/Dify 等，一切都必須進行調整，這樣工作量大大增加。

第二、AG-UI 架構設計

AG-UI 使用一個輕量級、事件驅動的協議來連接 AI Agents 和前端應用程序，架構設計如圖所示：

• Front-end：通過 AG-UI 進行通信的應用（聊天或任何啟用 AI 應用） ；
• AI Agent A：前端可以直接連接的 AI Agent，無需通過代理；
• Secure Proxy：一個中介代理，安全地將前端的請求路由到多個 AI Agents；
• AI Agent B 和 C：由代理服務管理的 AI Agents。

第三、AG-UI 工作機制

AG-UI 的核心工作機制非常簡潔而優雅，如下圖所示：

• 客戶端通過 POST 請求啟動一次 AI Agent 會話；
• 隨后建立一個 HTTP 流（可通過 SSE/WebSocket 等傳輸協議）用于實時監聽事件；
• 每條事件都有類型和元信息（Metadata）；
• AI Agent 持續將事件流式推送給 UI；
• UI 端根據每條事件實時更新界面；
• 與此同時，UI 也可反向發送事件、上下文信息，供 AI Agent 使用。
  

AG-UI 不再是單向的信息流，而是一種真正的雙向“心跳式”交互機制。AG-UI 就像 REST 是客戶端到服務器請求的標準一樣，AG-UI 將實時 AI Agent 更新流式傳輸回 UI 的標準。從技術上講，AG-UI 使用服務器發送事件（SSE）將結構化 JSON 事件流式傳輸到前端。

每個事件都有一個顯式的有效負載（比如：Python 字典中的 keys）：

• TEXT_MESSAGE_CONTENT 用于令牌流式處理；
• TOOL_CALL_START 以顯示工具執行情況；
• STATE_DELTA 更新共享狀態（代碼、數據等）；
• AGENT_HANDOFF 在 AI Agent 之間順利傳遞控制權。

并且 AG-UI 帶有 TypeScript 和 Python 的 SDK，即插即用適用于任何技術棧，如下圖所示：

在上圖中，來自 AI Agent 的響應并不特定于任何工具包。這是一個標準化的 AG-UI 響應。

AG-UI 提供了前端 TypeScript 和后端 Python 的 SDK，可無縫接入到現有 AI Agent 代碼中，核心模塊包括：

• RunAgentInput：運行 AI Agent 的輸入參數；
• Message：用戶助手通信和工具使用；
• Context：提供給 AI Agent 的上下文信息；
• Tool：定義 AI Agent 可以調用的函數；
• State：AI Agent 狀態管理。

1、前端接入

npm install @ag-ui/core
npm install @ag-ui/client

2、后端 Python 端接入

from ag_ui.core import TextMessageContentEvent, EventType
from ag_ui.encoder import EventEncoder
# Create an event
event = TextMessageContentEvent(
    type=EventType.TEXT_MESSAGE_CONTENT,
    message_id="msg_123",
    delta="Hello, world!"
)
# Initialize the encoder
encoder = EventEncoder()
# Encode the event
encoded_event = encoder.encode(event)
print(encoded_event)
# Output: data: {"type":"TEXT_MESSAGE_CONTENT","messageId":"msg_123","delta":"Hello, world!"}\n\n

第四、AG-UI 關鍵特性

• ?? 輕量級：設計簡單，易于理解與擴展；
• ?? 支持多種傳輸協議：Server-Sent Events（SSE）、WebSocket、Webhook 任你選擇；
• ?? 真正雙向同步：支持實時對話、工具調用、上下文更新等；
• ?? 框架無關：LangGraph、CrewAI、Mastra 等框架均可無縫對接；
• ??? 寬松的 Schema 匹配策略：低耦合、高兼容，降低開發門檻；
• ?? 即插即用：開源協議，前端（比如：React/Vue）快速集成無門檻。

第五、AG-UI、A2A、MCP 協議對比

AG-UI 明確且專門針對 AI 智能體-用戶交互層。它不與諸如 A2A（AI Agent 到 AI Agent 協議）和 MCP（模型上下文協議）等協議競爭。

比如：同一個 AI 智能體可能通過 A2A 與另一個 AI 智能體通信，同時通過 AG-UI 與用戶通信，同時調用由 MCP Server 提供的工具。

這些協議在 AI 智能體生態系統中起到互補的作用：

• AG-UI：處理人在循環中的交互和流式 UI 更新；
• A2A：促進 AI 智能體到 AI 智能體之間的通信和協作；
• MCP：在不同模型之間標準化工具調用和上下文處理。

四、AI 智能體協議架構設計總結

AI 智能體協議三部曲的對比如下：

AI 智能體架構設計中的這三個協議共同構成了 AI 智能體應用系統架構設計的基礎設施。它們讓 AI 智能體能夠“長出手腳”（通過 MCP 實現操作能力）、擁有協作伙伴（通過 A2A 實現 AI 智能體之間的協作），并且能夠通過 AG-UI 與用戶直接交互，實現落地應用。

這三個協議推動了 AI 智能體應用系統從單一 AI 智能體向多 AI 智能體 的進化，不僅提升了底層能力，還優化了上層的用戶體驗。同時，它們的開放性和兼容性也為更多 AI 創新應用和跨領域協作提供了可能。

本文轉載自???玄姐聊AGI??  作者：玄姐