Google 出了一份 AI Agent 协议实战指南 一个案例讲清楚六个 Agent 协议到底怎么配合

先说核心结论

6 个协议，各管一件事，不冲突：

• MCP：Agent 怎么连工具和数据
• A2A：Agent 之间怎么互相沟通
• UCP：Agent 怎么统一处理商业交易
• AP2：Agent 怎么安全完成支付授权
• A2UI：Agent 怎么把结果变成可交互的界面
• AG-UI：Agent 怎么把过程实时推送到前端

记住这张表，后面的内容就好理解了。

用了一个什么案例

他们用 Google 的 Agent Development Kit（ADK）搭了一个餐厅供应链 Agent。

为什么选这个场景？因为餐厅采购这件事，刚好把 6 个协议全用上了：要查库存（连数据库），要询价（跟其他 Agent 通讯），要下单（商业交易），要付款（支付授权），要给用户展示结果（前端渲染），还要实时更新进度（流式推送）。

起点是一个裸的大模型，你问它库存多少，它瞎编一个数字给你。然后每加一个协议，就解决一个实际问题，直到最后变成一个能查真实库存、拿真实报价、下真实订单的完整 Agent。

逐个加协议，每个解决什么问题

第一个加的：MCP → 连上真实数据

没有 MCP 之前，你问 Agent "三文鱼还有多少"，它只能瞎猜。

加了 MCP 之后，Agent 连上了餐厅的库存数据库，查到的是真实数据：三文鱼库存不够了。

MCP 是 Anthropic 做的，解决的是"Agent 怎么连接外部工具和数据"。你可以把它理解成一个标准化的插头，不管你要连数据库、连 API、连浏览器、连文件系统，都用同一套接口。

到现在，MCP 的 SDK 月下载量已经超过 9700 万次，Anthropic、OpenAI、Google、微软、亚马逊全都接入了。已经是事实标准了。

第二个加的：A2A → 跟其他 Agent 沟通

库存不够，需要采购。但供应商有好几家，价格、品质、配送时间都不一样。

这些信息不在你的数据库里，而是在供应商自己的系统里。以前你得给每家供应商写一套对接代码。

加了 A2A 之后，Agent 可以自动发现远程的供应商 Agent。每个供应商 Agent 都有一张"名片"（Agent Card），上面写着自己能做什么、怎么联系。你的采购 Agent 找到合适的供应商，发消息询价，拿到报价。

A2A 是 Google 做的，解决的是"Agent 之间怎么互相发现和协作"。MCP 让 Agent 能用工具，A2A 让 Agent 能找到彼此。两个协议互补，不冲突。

第三个加的：UCP → 统一下单流程

价格合适，准备下单。但问题来了：五家供应商，五套不同的下单 API。

UCP（Universal Commerce Protocol）统一了购物流程。不管底层走的是 REST、MCP 还是 A2A，Agent 跟所有供应商交互的方式都是一样的。从发现商品目录到完成结账，一套标准搞定。

这个协议是 Google 联合 Shopify、Etsy、Target、Walmart 等一起做的，支付侧有 Visa、Mastercard、Stripe、American Express 等参与。阵容很豪华。

第四个加的：AP2 → 支付授权

订单下了，谁来批准付款？总不能让 Agent 拿着公司的钱无限制地花吧。

AP2 协议给每笔交易加了授权层。你可以设定规则，比如"单笔不超过 5000 美元可以自动批准"，Agent 在这个范围内自主操作，超出了再找人审批。每笔授权都有加密的审计记录，不可抵赖。

UCP 管"买什么、跟谁买"，AP2 管"谁批准的、有没有审计记录"。两个协议配合使用。

第五个加的：A2UI → 生成可交互界面

采购完成了，需要告诉用户发生了什么。

如果只是返回一段文字"已采购三文鱼 50 斤，花费 3200 元"，信息量太少。用户想看的是一个仪表盘：订了什么、多少钱、哪家供应商、预计什么时候到。

A2UI 让 Agent 用一套声明式的 JSON 格式描述界面结构，客户端拿到后用自己的原生组件渲染。Agent 发出去的是一份"界面蓝图"，前端自己决定长什么样。

一共只有 18 个基础组件（行、列、文本、按钮、卡片等），但 Agent 可以用这 18 个组件组合出完全不同的界面。同一个 Agent，问它库存就出 checklist，问它下单就出表单，问它比价就出对比卡片。

第六个加的：AG-UI → 实时流式推送

最后一个问题：整个过程要实时推送进度，不能等全干完了才告诉你。

AG-UI 协议把 Agent 的每一步操作（工具调用、文本响应、界面更新）实时流式推送到前端。你能看到 Agent 正在查库存、正在询价、正在下单，而不是对着一个加载圈干等。

AG-UI 是 CopilotKit 做的开源协议，充当 Agent 框架和前端之间的中间件，把不同框架的事件格式翻译成统一的 SSE 流。

这些协议谁做的

梳理一下背后的力量：

MCP：Anthropic 做的，2024 年底开源，2025 年底捐给了 Linux 基金会。Agent 连接工具的事实标准。

A2A：Google 做的，2025 年 4 月发布，同年捐给 Linux 基金会。IBM 的 ACP 协议后来合并进了 A2A。Agent 间通讯的主要标准。

UCP + AP2：Google 联合零售和支付巨头一起做的，针对商业交易和支付授权。

A2UI：Google 做的，声明式 Agent UI 协议。

AG-UI：CopilotKit 做的，Agent 到前端的实时通讯协议。

一个明显的趋势：核心协议都在往开放标准靠拢，都捐给了 Linux 基金会。没有哪家想把协议锁死在自己的生态里。

对开发者最实用的建议

Google 在文章最后给了几条很实在的建议：

不用一次全学。 大部分 Agent 从 MCP 开始就够了。随着需求增长，需要多 Agent 协作就加 A2A，需要交易就加 UCP，需要富 UI 就加 A2UI，按需引入。

别从零造轮子。 用任何协议之前，先查有没有 ADK 集成、官方 SDK 和示例代码。这些协议迭代很快，官方工具处理了很多你不想自己实现的细节。

保持模块化。 优先选有明确 schema、清晰权限、可替换组件的协议，避免把 Agent 绑死在某个特定厂商或运行时上。

AI Agent 的"协议栈"正在成型

AI Agent 的协议生态，正在从"一片混沌"走向"各司其职"。

一年前大家还在争论"MCP 和 A2A 到底谁会赢"，现在答案已经很清楚了：它们解决的根本不是同一个问题。MCP 管工具连接，A2A 管 Agent 通讯，UCP 管商业交易，A2UI 管界面生成，AG-UI 管实时推送，AP2 管支付授权。各管各的，组合使用。

这跟互联网协议的发展历程很像。HTTP、TCP/IP、DNS、SSL，当年也是一堆缩写让人头大，但最终每个协议找到了自己的位置，组合成了我们今天用的互联网。

AI Agent 的"协议栈"，正在以类似的方式成型。

Google 这篇文章的价值就在于，第一次用一个完整案例把这个协议栈的全貌展示出来了。对开发者来说，现在最值得投入的两个协议是 MCP 和 A2A。前者已经是事实标准，后者正在快速成为标准。把这两个搞明白，其他的按需学习就行。

来源：Google Developers Blog | Google for Developers 推文

附录：Developer's Guide to AI Agent Protocols 全文翻译

原文：https://developers.googleblog.com/developers-guide-to-ai-agent-protocols/ 作者：Shubham Saboo, Kristopher Overholt | 发布日期：2026-03-18

AI 智能体协议开发者指南

2026 年 3 月 18 日

Shubham Saboo 高级 AI 产品经理

Kristopher Overholt 开发者关系工程师

AI 智能体（AI Agent）开发的版图正在快速扩张，各种缩写满天飞：MCP、A2A、UCP、AP2、A2UI、AG-UI……这还只是其中几个。如果你看着这堆协议名称，感觉像是在盯着一面"竞争性标准"的墙，放心，你不是一个人。为了帮你搞清楚它们的价值，我们会逐一展示每个协议到底能帮你省掉多少活——具体来说，就是那些你原本需要为智能体接触的每个工具、API 和前端组件手写的集成代码。

我们会用 Agent Development Kit（ADK，智能体开发工具包）来实际操练这些协议，搭建一个餐厅供应链的多步骤智能体。选这个场景是有原因的：批发采购食材需要查库存数据库、跟远程供应商智能体沟通、执行安全交易、还要渲染交互式仪表盘——刚好覆盖了所有协议的使用场景。

我们的起点是一个什么都靠"编"的裸大模型（bare LLM），然后一个个加协议，直到它能查真实库存、获取专业报价、下单、授权付款、还能渲染实时交互式仪表盘。

1. 模型上下文协议（MCP，Model Context Protocol）

搭智能体时你碰到的第一个坎：怎么把它连到你的系统和数据上。比如你的厨房管理智能体需要查库存或者给供应商发邮件，正常做法是为那个特定的 API 写一套定制集成代码。如果一个服务有十几个接口，你就得写十几个定制工具来对接，而且还得持续维护。

模型上下文协议（MCP） 直接干掉了这些重复劳动。它给你一个统一的标准连接模式，对接几百个服务器。服务器自己声明有哪些工具，你的智能体自动发现。而且因为 MCP 服务器是由构建这些系统的团队自己维护的，你的智能体随时都能拿到最新的工具定义，不用你写或更新任何集成代码。

ADK 通过 McpToolset 提供了对 MCP 的原生支持。不用从零开始写一堆 API 请求，我们的厨房管理员现在可以用 MCP Toolbox for Databases 从真实的 PostgreSQL 数据库读数据，通过 Notion MCP 查食谱，还能用 Mailgun MCP 给供应商发邮件。

from google.adk.agents import Agent
from google.adk.tools.mcp_tool import McpToolset
from google.adk.tools.mcp_tool.mcp_session_manager import StdioConnectionParams
from google.adk.tools.toolbox_toolset import ToolboxToolset
from mcp import StdioServerParameters

# 1. 库存数据库 - MCP Toolbox for Databases（支持 PostgreSQL、SQLite、BigQuery 等）
inventory_tools = ToolboxToolset(server_url=TOOLBOX_URL)

# 2. 厨房操作手册和食谱 - Notion MCP（读取菜单、食材清单、供应商联系方式）
notion_tools = McpToolset(connection_params=StdioConnectionParams(
    server_params=StdioServerParameters(
        command="npx", args=["-y", "@notionhq/notion-mcp-server"],
        env={"NOTION_TOKEN": NOTION_TOKEN}),
    timeout=30))

# 3. 给供应商发邮件 - Mailgun MCP（发送确认函、跟踪配送）
mailgun_tools = McpToolset(connection_params=StdioConnectionParams(
    server_params=StdioServerParameters(
        command="npx", args=["-y", "@mailgun/mcp-server"],
        env={"MAILGUN_API_KEY": MAILGUN_API_KEY}),
    timeout=30))

kitchen_agent = Agent(
    model="gemini-3-flash-preview",
    name="kitchen_manager",
    instruction="You manage a restaurant kitchen. Check inventory, look up recipes, email suppliers.",
    tools=[inventory_tools, notion_tools, mailgun_tools],
)

你可以浏览 ADK 中的 MCP 集成完整生态，看看有哪些现成可用的工具。

2. 智能体间通信协议（A2A，Agent2Agent Protocol）

MCP 搞定了数据访问，下一个挑战是专业知识。你的厨房管理员能查库存了，但它不知道今天的批发价、供应商质量评级、送货时间窗口。这些知识分散在不同的远程智能体那里——可能是不同团队构建的、用不同框架写的、跑在不同服务器上的。有些情况下，原始数据压根不会通过 API 暴露出来，但可以通过一个智能体接口来获取。没有标准协议的话，你得为每一个远程智能体写定制集成代码，而且每次对方一更新你就得重新部署。

Agent2Agent（A2A）协议 把智能体之间的发现和通信做了标准化。每个 A2A 智能体在一个固定 URL（/.well-known/agent-card.json）发布一张智能体名片（Agent Card），描述自己的名字、能力和接口地址。完整规范参见 A2A 协议文档。

我们的厨房管理智能体获取这些名片就能了解每个远程智能体的功能，然后在运行时把请求路由到对的那个。新增一个远程智能体就是加一个 URL 的事，不用改代码，不用重新部署。

ADK 的 RemoteA2aAgent 每轮只路由到一个远程智能体。当一个请求涉及多个远程智能体时——比如同时要查价格、质量和配送时间——你可以直接用 a2a-sdk，我们这里就是这么做的。

# 一个 A2A 智能体在 /.well-known/agent-card.json 提供它的名片：
# {
#   "name": "pricing_agent",
#   "description": "Checks today's wholesale market prices for food items.",
#   "skills": [{"id": "pricing", "name": "Price Check",
#               "description": "Check current wholesale market prices"}],
#   "url": "http://pricing-agent:8001/",
#   "version": "1.0.0"
# }

# 发布：把任何 ADK 智能体变成 A2A 服务
from google.adk.a2a.utils.agent_to_a2a import to_a2a
app = to_a2a(pricing_agent, port=8001)

# 发现：解析智能体名片并创建客户端——只需要一个 URL
from a2a.client.client_factory import ClientFactory
client = await ClientFactory.connect("http://pricing-agent:8001")
card = await client.get_card()
print(f"{card.name} - {card.description}")
# -> "pricing_agent - Checks today's wholesale market prices for food items."

# 调用：通过 A2A 协议发送消息
from a2a.client.helpers import create_text_message_object
msg = create_text_message_object(content="What's today's wholesale price for salmon?")
async for response in client.send_message(msg):
    ...  # response 是一个 Task（带 artifacts）或者直接的 Message

试试 A2A 示例，实际体验发现和通信的模式。

3. 通用商务协议（UCP，Universal Commerce Protocol）

现在你的智能体能发现供应商、拿到报价了。但真要下单的时候，每个供应商的 API 都不一样。如果你的智能体需要从五个批发商那里采购食材，你就得对接五套不同的结账流程。

通用商务协议（UCP） 把整个购物生命周期标准化了，通过强类型的请求和响应模式（Schema）将其拆分为模块化的功能。这些模式在任何底层传输方式上都保持一致。不用为每个供应商做定制集成，你的智能体通过统一的模式跟它们交��。不管底层连接走的是 REST、MCP、A2A 还是用于浏览器场景的嵌入式协议（EP），都一样。

我们的厨房管理智能体可以用跟 A2A 一样的固定 URL 模式（/.well-known/ucp）发现供应商目录，然后构造一个类型化的结账请求来完成订单。因为 UCP 也支持标准 REST API，它可以跟你项目里已有的任何 HTTP 客户端配合使用。不需要专有 SDK。

import httpx, uuid
from ucp_sdk.models.discovery.profile_schema import UcpDiscoveryProfile
from ucp_sdk.models.schemas.shopping.checkout_create_req import CheckoutCreateRequest
from ucp_sdk.models.schemas.shopping.types.line_item_create_req import LineItemCreateRequest
from ucp_sdk.models.schemas.shopping.types.item_create_req import ItemCreateRequest
from ucp_sdk.models.schemas.shopping.payment_create_req import PaymentCreateRequest

# 发现：解析供应商的 UCP 配置文件
async with httpx.AsyncClient() as c:
    profile = UcpDiscoveryProfile.model_validate(
        (await c.get("http://example-wholesale:8182/.well-known/ucp")).json())

# 下单：构建类型化的结账请求
checkout_req = CheckoutCreateRequest(
    currency="USD",
    line_items=[
        LineItemCreateRequest(quantity=10, item=ItemCreateRequest(id="salmon")),
        LineItemCreateRequest(quantity=3,  item=ItemCreateRequest(id="olive_oil")),
    ],
    payment=PaymentCreateRequest(),
)

# 发送：创建结账会话并完成订单（带必需的 UCP 请求头）
# UCP-Agent 请求头应该指向你的智能体能力配置
headers = {"UCP-Agent": 'profile="https://kitchen.example/agent"',
           "Idempotency-Key": str(uuid.uuid4()), "Request-Id": str(uuid.uuid4())}
async with httpx.AsyncClient() as c:
    checkout = (await c.post("http://example-wholesale:8182/checkout-sessions",
        json=checkout_req.model_dump(mode="json", by_alias=True, exclude_none=True),
        headers=headers)).json()
    headers["Idempotency-Key"] = str(uuid.uuid4())  # 每个操作用新的幂等键
    order = (await c.post(
        f"http://example-wholesale:8182/checkout-sessions/{checkout['id']}/complete",
        headers=headers)).json()

UCP 示例仓库里有一个基于 AI 的购物助手，用 ADK 构建，把 UCP 和 A2A 结合起来实现端到端的购物流程。

4. 智能体支付协议（AP2，Agent Payments Protocol）

上一节里，我们的厨房管理员学会了向供应商下单。但是——谁授权这笔开销的？没有任何记录说明设了什么限额、批准了哪些商家、授权什么时候过期。

智能体支付协议（AP2） 补上了这个缺失的环节。它使用类型化的授权书（Mandate），提供不可抵赖的意图证明，并对每笔交易实施可配置的护栏规则。UCP 管的是你订什么、从谁那订，AP2 管的是谁批准了这笔采购，并提供审计追踪。它们协同工作：AP2 作为扩展插入 UCP，在结账流程中加入密码学授权证明。

与其让交易不受控制地执行，不如给智能体配置好护栏。你先定义一个 IntentMandate（意图授权）来指定允许的商家并设置自动审批的消费上限。然后智能体生成一个 PaymentMandate（支付授权），绑定到特定的购物车和金额。如果订单超过上限，授权书保持未签名状态，直到管理员明确批准。最后一个 PaymentReceipt（支付回执）闭合整个审计链条。

下面的代码用 AP2 官方仓库中的真实类型，展示了从意图到签名授权再到回执的完整授权流程。

from ap2.types.mandate import IntentMandate, PaymentMandate, PaymentMandateContents
from ap2.types.payment_request import PaymentCurrencyAmount, PaymentItem, PaymentResponse
from ap2.types.payment_receipt import PaymentReceipt, Success

# 餐厅老板配置护栏规则
intent = IntentMandate(
    natural_language_description="10 lbs salmon, 3 bottles olive oil",
    merchants=["Example Wholesale"],    # 只允许这些供应商
    requires_refundability=True,            # 必须可退款
    user_cart_confirmation_required=False,  # 限额内自动审批
    intent_expiry="2026-02-23T20:00:00Z",   # 1 小时后过期
)

# 智能体创建 PaymentMandate，将支付绑定到意图
mandate = PaymentMandate(payment_mandate_contents=PaymentMandateContents(
    payment_mandate_id="abc123",
    payment_details_id="order-001",
    payment_details_total=PaymentItem(
        label="10 lbs salmon + 3 bottles olive oil",
        amount=PaymentCurrencyAmount(currency="USD", value=294.00)),
    payment_response=PaymentResponse(request_id="order-001", method_name="CARD"),
    merchant_agent="Example Wholesale",
))

# 管理员签名（模拟 - 真实 AP2 在安全设备上使用 JWT/生物识别）
mandate.user_authorization = "signed_hash_abc123"

# PaymentReceipt 闭合审计链条
receipt = PaymentReceipt(
    payment_mandate_id="abc123", payment_id="PAY-001",
    amount=PaymentCurrencyAmount(currency="USD", value=294.00),
    payment_status=Success(merchant_confirmation_id="ORD-A1B2C3"),
)
# IntentMandate -> PaymentMandate（已签名）-> PaymentReceipt
# 完整审计链：意图了什么、授权了什么、付了什么

AP2 目前是 v0.1 版本，其类型作为独立包提供，尚未内置到 ADK 核心中。可以在 AP2 仓库中探索协议和参考实现。

5. 智能体到用户界面协议（A2UI，Agent-to-User Interface Protocol）

到这一步，我们的厨房管理员已经能查库存、拿报价、下单、授权付款了。但所有结果都以纯文本形式返回——有时候光靠文字不够用。当你的智能体需要展示一个库存仪表盘、一个订单表单、或者一个供应商对比表时，你通常得为每一种场景单独写前端组件。每多一个 UI 需求，就多一堆前端代码要写和维护。

智能体到用户界面协议（A2UI） 解决了这个问题：它让智能体从一个固定的组件目录中动态组合出全新的布局。它使用声明式的 JSON 格式，只由 18 个安全的基础组件（Primitive）构成，比如行、列、文本框等。

A2UI 把 UI 结构和底层数据分离开了。智能体发送一个扁平的组件列表，组件之间通过 ID 互相引用，然后单独发送数据负载。客户端的渲染器用 Lit、Flutter 或 Angular 等框架把这段 JSON 转化成原生界面。

# 这就是智能体发送的内容。渲染器（Lit、Flutter、Angular）把它变成原生 UI。

a2ui_messages = [
    # 1. 创建一个渲染表面
    {"beginRendering": {"surfaceId": "default", "root": "card"}},

    # 2. 发送组件树（扁平列表，ID 引用——不是嵌套的）
    {"surfaceUpdate": {"surfaceId": "default", "components": [
        {"id": "card", "component": {"Card": {"child": "col"}}},
        {"id": "col", "component": {"Column": {"children": {"explicitList": ["title", "price", "buy"]}}}},
        {"id": "title", "component": {"Text": {"usageHint": "h3", "text": {"path": "name"}}}},
        {"id": "price", "component": {"Text": {"text": {"path": "price"}}}},
        {"id": "buy", "component": {"Button": {"child": "btn-label", "action": {"name": "purchase",
            "context": [{"key": "item", "value": {"path": "name"}}]}}}},
        {"id": "btn-label", "component": {"Text": {"text": {"literalString": "Buy Now"}}}},
    ]}},

    # 3. 发送数据（跟结构分离——更新数据时不用重新发送组件）
    {"dataModelUpdate": {"surfaceId": "default", "contents": [
        {"key": "name",  "valueString": "Fresh Atlantic Salmon"},
        {"key": "price", "valueString": "$24.00/lb"},
    ]}},
]

现在，同一个智能体可以根据不同的请求，用同样的 18 个基础组件组合出完全不同的界面。下面这个例子中，对同一个智能体的三个不同提示分别生成了库存清单、订单表单和供应商对比——全都用 CheckBox、TextField、DateTimeInput 和 Card 等组件搭建，不需要写额外的前端代码。

开发过程中，ADK 的 Web 界面（adk web）可以原生渲染 A2UI 组件，让你不用搭建自定义渲染器就能测试智能体的 UI 输出。

到 A2UI 示例中查看更多组件模式，或者试试 A2UI Widget Builder 交互式地组合布局。

6. 智能体-用户交互协议（AG-UI，Agent-User Interaction Protocol）

传统的 REST API 返回响应就完事了。智能体不一样。它们逐步流式输出文本，在响应过程中调用工具，有时还会暂停等待人类输入。这让智能体连接前端比标准 API 调用复杂得多。

你当然可以自己处理这些。ADK 提供了原生的 /run_sse 端点来直接流式传输事件，几十行前端代码就够解析事件流和渲染工具调用了。但这些解析代码都是样板代码，而且每次事件格式一变就得跟着改。

智能体-用户交互协议（AG-UI） 消除了这些样板代码。它充当中间件，把各框架的原始事件翻译成标准化的 SSE（Server-Sent Events）流。你的前端只需要监听类型化的事件，比如 TEXT_MESSAGE_CONTENT 或 TOOL_CALL_START，完全不用关心是哪个智能体框架产生的。

要把我们的厨房管理智能体变成 AG-UI 流式端点，只需要用 ag_ui_adk 包装一下，然后挂载到 FastAPI 应用上：

from ag_ui_adk import ADKAgent, add_adk_fastapi_endpoint
from fastapi import FastAPI

# 包装智能体、创建应用、挂载端点
ag_ui_agent = ADKAgent(adk_agent=kitchen_mgr, app_name="kitchen", user_id="chef")
app = FastAPI()
add_adk_fastapi_endpoint(app, ag_ui_agent, path="/")
# 运行：uvicorn module:app

# SSE 流发出类型化的事件：
#   RUN_STARTED
#   TOOL_CALL_START    toolCallName="check_inventory"
#   TOOL_CALL_RESULT   content="3 lbs in stock, REORDER NEEDED"
#   TOOL_CALL_END
#   TEXT_MESSAGE_CONTENT  delta="Based on "
#   TEXT_MESSAGE_CONTENT  delta="current inventory..."
#   RUN_FINISHED

到 AG-UI 示例中查看更多流式交互模式。

全部串起来：智能体实战

六个协议全部就位后，我们一开始那个什么都靠编的裸大模型，已经变成了一个相当能打的智能体——能查真实库存、发现供应商、下单、授权付款、还能流式推送交互式仪表盘。来看看当用户发送一个触发所有功能的请求时，会发生什么：

"查一下我们的鲑鱼库存，拿到今天的批发价和质量等级，如果库存不足就从 Example Wholesale 订 10 磅，授权付款。"

智能体用不同的协议处理请求的每个阶段：

阶段 1：收集信息

• 先查库存里有什么。MCP 查询库存数据库中的鲑鱼数据（check_inventory）。
• 库存不够了。现在行情价多少？A2A 查询远程定价智能体和质量评级智能体（ask_agent）。

阶段 2：完成交易

• 价格合适，下单。UCP 向 Example Wholesale 发送结账请求（place_order）。
• 但谁批准的？AP2 在配置好的护栏规则内用支付授权来保障订单（authorize_payment）。

阶段 3：展示结果

• 把发生了什么展示给用户。A2UI 从结果中组合交互式组件。
• 把一切实时推送到前端。AG-UI 实时传递工具调用和文本响应。

Kitchen-Manager-Agent.mp4

六个协议，各自解决一个问题，全部通过一个智能体协同工作。

使用这些协议的实用建议

搞清楚每个协议解决什么问题： MCP 把智能体连到工具和数据。A2A 把智能体连到其他智能体。UCP 标准化商务流程。AP2 处理支付授权。A2UI 定义渲染什么。AG-UI 定义怎么流式传输。理解这些边界，你的架构才会干净。

按需添加协议： 不用第一天就把六个都上。大多数智能体从 MCP 开始，先搞定数据访问。随着需求增长（多智能体通信、商务、支付、富 UI、流式传输），再引入解决特定问题的协议。

别从零开始造轮子： 用某个协议之前，先查查有没有 ADK 集成、官方 SDK 和示例代码。这些协议迭代很快，官方工具已经处理好了你不想自己重新实现的细节。

尽早采用标准： 这些协议还在成熟过程中，但它们建立的模式——通过固定 URL 发现、类型化的请求/响应模式、标准化的事件流——会让你的智能体跟越来越多的工具、服务和其他智能体兼容。

现在就开始

这篇文章中的每个代码示例都使用了 ADK。搭建你的第一个智能体，连接一个 MCP 服务器，然后从那里开始逐步添加协议。浏览 ADK 集成看看哪些工具和服务已经可以直接用了。每个协议的文档和示例链接都在这篇指南中。

我们迫不及待想看到你用它们构建出什么。