AI Agent 协议全景指南：MCP、A2A、UCP 等六大协议一次讲清楚

原文来源：Google Developers Blog — AI Agent 开发现场正在被五花八门的协议碎片化成孤岛，Google 用一篇指南把 MCP、A2A、UCP、AP2、A2UI 和 AG-UI 串到一起，讲清楚它们各自解决什么、怎么协作。

如果你在过去半年里关注过 AI Agent 开发，一定被 MCP、A2A、UCP、AP2、A2UI 这些协议缩写搞得头晕过。它们每个单独看都能说清"是什么"，但放到一起就变成了一堵字母墙——"等等，MCP 和 A2A 不是竞争关系吗？UCP 又是干嘛的？"

这篇指南来自 Google 开发者博客（2026 年 3 月发布），作者是 Google ADK 团队的 Shubham Saboo 和 Kristopher Overholt。它用一个贯穿始终的故事——帮一家餐厅的厨房构建智能管理系统——把六大协议串了起来。读完你会清晰地知道：每个协议解决什么问题，它们在什么层面协作，以及在实际项目中怎么选型。

问题：一个没有协议的世界

在讲协议之前，先想象一下你是一家餐厅的厨房主管。你手上有几个 AI 助手：

• 厨房主管 Agent：负责食材订购、库存管理、菜品调度
• 供应商 Agent：管理批发价格、库存和配送
• 财务 Agent：审批采购、管理预算
• 点餐 Agent：处理客户订单和特殊要求

如果没有标准化协议，每个 Agent 之间的通信都需要你手写定制的 API 对接代码。连接一个供应商写一套，连接财务系统又写一套——每一套都是不可复用的胶水代码。当系统扩展到 20 个 Agent 时，维护成本会爆炸。

这就是协议存在的意义：把点对点的定制集成，变成即插即用的标准化连接。

MCP：让 Agent 能用工具

**Model Context Protocol（MCP）**是 Anthropic 推动的开放协议，它解决的首要问题是：Agent 怎么接入外部工具和数据源？

在 MCP 出现之前，让一个 LLM 读取数据库、发送邮件或调用 API，需要针对每个服务写专门的 Tool Calling 代码。服务方每改一次 API，集成方就得跟着改。MCP 把角色拆成了三层：

• MCP Host：运行 LLM 的应用（比如 Google ADK、Claude Desktop）
• MCP Client：内嵌在 Host 中，负责与 Server 建立一对一连接
• MCP Server：暴露具体工具和数据（数据库查询、文件读取、邮件发送等）

回到餐厅场景。厨房主管 Agent 接入了三个 MCP Server：

• PostgreSQL MCP Server：直接查询库存数据库，检查食材余量
• Notion MCP Server：读取菜品配方和操作 SOP
• Mailgun MCP Server：发送采购邮件给供应商

在 ADK 中，用 McpToolset 几行代码就能注册这些工具：

from google.adk.tools import McpToolset
 
# 自动发现并注册 MCP Server 提供的所有工具
toolset = McpToolset()
agent = Agent(
    name="kitchen_manager",
    model="gemini-2.5-pro",
    tools=toolset.get_tools()
)

MCP 的关键设计原则是服务提供方写一次 Server，所有 Host 都能复用。数据库团队维护一个 PostgreSQL MCP Server，Claude、Gemini、VS Code 等所有支持 MCP 的应用都能直接使用，不需要为每个应用写不同的集成。

截至目前，MCP 生态已经覆盖了数百种服务——从数据库（PostgreSQL、SQLite）到开发工具（GitHub、GitLab）到办公套件（Google Workspace、Notion）。详见 ADK 的 MCP 集成目录。

A2A：让 Agent 之间能对话

MCP 解决了 Agent 用工具的问题，但 Agent 和 Agent 之间的通信呢？如果你的厨房主管需要查询供应商的实时报价，而供应商是一个独立运行的 Agent（可能基于不同的框架、跑在不同的服务器上），就需要一个 Agent 到 Agent 的通信协议。

**Agent2Agent Protocol（A2A）**由 Google 推动，它的核心概念是 Agent Card。每个 A2A 兼容的 Agent 在 /.well-known/agent-card.json 发布自己的能力说明：

{
  "name": "Seafood Supplier Agent",
  "description": "海鲜供应商的报价和库存查询",
  "capabilities": [
    "price_query",
    "inventory_check",
    "order_placement"
  ],
  "endpoint": "https://supplier-api.example.com/a2a"
}

厨房主管 Agent 通过发现 Agent Card，就能知道如何与供应商 Agent 通信、它能做什么、调用什么接口。这类似于 Web 开发中的 OpenAPI Specification——接口即文档，文档即代码。

在 ADK 中，通过 RemoteA2aAgent 注册远程 Agent：

from google.adk.agents import RemoteA2aAgent
 
supplier_agent = RemoteA2aAgent(
    name="seafood_supplier",
    agent_card_url="https://supplier-api.example.com/.well-known/agent-card.json"
)

A2A 的核心价值在于解耦——每个 Agent 独立部署、独立演进，只需要遵守 Agent Card 契约。添加新的供应商 Agent 只需要添加一个新的 URL，不需要修改任何代码。

A2A 的详细规范和示例代码见 a2a-samples GitHub 仓库。

UCP：让供应链标准化

当厨房主管 Agent 开始实际采购时，问题来了：每个供应商的报价格式不同、订单流程不同、支付方式不同。供应商 A 用 CSV 报价单，供应商 B 用 JSON API，供应商 C 只能发邮件。

**Universal Commerce Protocol（UCP）**就是要解决这个问题。它把电商采购的全生命周期标准化：

• 商品目录：统一格式的产品列表（品名、规格、单价、库存）
• 购物车：标准化的选品和数量提交
• 结账：统一的订单确认和支付流程
• 履约：标准化的配送状态追踪

UCP 同样使用 /.well-known/ucp 发现端点，兼容 REST、MCP、A2A 等多种传输方式。这就意味着厨房主管 Agent 可以用同一套代码向所有供应商发送采购请求，不需要为每个供应商适配不同的接口。

AP2：让 Agent 花钱有据可查

Agent 能采购了，但谁批准这笔钱？总不能让 Agent 无限刷信用卡吧。

**Agent Payments Protocol（AP2）**在 UCP 的基础上增加了支付授权层。它定义了三类核心数据结构：

• IntentMandate（授权意向）：用户或管理者授权 Agent 在什么范围花钱——比如"每月采购预算不超过 5000 美元，仅限食材供应商"
• PaymentMandate（支付授权）：绑定到具体购物车和金额，如果超限则无法签署
• PaymentReceipt（支付凭证）：完成支付的审计记录

AP2 目前是 v0.1 版本，作为一个独立包提供（尚未内置于 ADK 核心）。它的设计理念是非否认性——Agent 下达的每一笔采购都有完整的授权链可追溯，不是黑箱操作。

A2UI：让 Agent 能画界面

最后还有一个很实际的问题：Agent 处理完数据后，怎么展示给用户？每家客户都要不同的报表、仪表盘、订单确认页面，总不能每次都写一个前端组件吧？

Agent-to-User Interface Protocol（A2UI）的思路很有意思：它不让 Agent 自由生成任意 UI（那样太危险，可能被注入恶意组件），而是给 Agent 一个固定的组件库，包含 18 种安全组件原语：

• 布局组件：Row、Column、ScrollView
• 输入组件：TextField、Checkbox、Dropdown
• 展示组件：Card、Image、Table、Chart
• 操作组件：Button、Link

Agent 发送一个扁平化的组件列表 + 数据负载，客户端渲染器把 JSON 转换成原生 UI。Agent 不需要写 HTML、CSS 或 JSX，只要声明"我需要一个包含表格和按钮的布局"，剩下的由客户端完成。

在 ADK 开发模式下，adk web 命令就能原生渲染 A2UI —— 不需要另写前端代码。

协议全景：它们不打架，各管各的

到这里，你可能有点混乱：MCP 和 A2A 是什么关系？UCP 和 AP2 又是怎么搭配的？

它们在协作而不是竞争。这张图能帮你理清脉络：

用户 ↔ [A2UI：交互界面]
       ↓
   [Master Agent] ← A2A → [Supplier Agent]
       ↓ MCP                    ↓ MCP
   [数据库] [邮件] [GIS]    [库存系统] [报价系统]
       ↓ UCP + AP2
   [支付网关 → 采购订单]

• MCP：Agent → 工具/数据（垂直集成）
• A2A：Agent ↔ Agent（水平协作）
• UCP：标准化商业交易流
• AP2：支付授权和审计（UCP 的扩展）
• A2UI：Agent 生成动态 UI

或者更简单地说：MCP 让 Agent 能干事务，A2A 让 Agent 能聊业务，UCP 让生意有章法，AP2 让花钱有规矩，A2UI 让结果看得见。

在 ADK 中整合使用

Google 的 Agent Development Kit（ADK）是目前整合这些协议最完整的框架。官方提供了一套名为 ADK Kitchen Manager 的示例应用，演示了如何组合使用上述所有协议：

from google.adk import Agent
from google.adk.tools import McpToolset
from google.adk.agents import RemoteA2aAgent
 
# 1. 注册 MCP 工具（数据库、邮件等）
toolset = McpToolset()
 
# 2. 注册 A2A 远程 Agent（供应商）
supplier = RemoteA2aAgent(agent_card_url="...")
 
# 3. 注册 UCP 服务（采购）
from ucp import UCPCart, UCPCheckout
 
# 4. 注册 A2UI（动态界面）
from a2ui import A2UIRenderer
 
kitchen_manager = Agent(
    name="kitchen_manager",
    model="gemini-2.5-pro",
    tools=[
        *toolset.get_tools(),
        supplier,
        UCPCart(),
        UCPCheckout(),
        A2UIRenderer()
    ]
)

这个应用完整演示了一个从库存检查 → 供应商比价 → 下单采购 → 授权支付 → 生成报表的全流程自动化。

选型建议：你需要哪些协议？

面对这么多协议，一个务实的问法是：我的项目现在需要什么？

• 单个 Agent + 外部工具：只需要 MCP。接入数据库、API、文件系统，MCP 足够
• 多 Agent 协作：考虑 A2A。如果你有多个独立运行的 Agent 需要通信
• 涉及交易和支付：加 UCP + AP2。特别是 Agent 代表用户执行采购的场景
• 需要动态界面：加 A2UI。Agent 生成的报表、仪表盘、订单确认页

不用一开始就追求协议全家桶。大部分项目从 MCP 开始就够了，多了再按需加入。

写在最后

AI Agent 协议正在经历类似 HTTP 和 REST 在 2000 年代初期的标准化过程。当时也是各种方案满天飞，最后沉淀下来的几个协议定义了现代 Web 的骨架。今天 AI Agent 领域正在经历同样的时刻——Google 的这篇指南是一个难得的全局视角，把这团乱麻理清了层次和脉络。

如果你正在构建 Agent 系统，值得花时间看懂每个协议的定位，然后问自己：当前的问题在哪里？用哪个协议解决最直接？ 不需要一次性上全，但知道全景图，能让你在需要的时候选对工具。

本文内容基于 Google Developers Blog 文章 整理，协议的具体实现和最新状态请参考各协议官方文档。