AI智能体六大协议详解：MCP、A2A、UCP、AP2、A2UI、AGUI

引言：为什么AI智能体需要协议？

AI智能体本身的能力其实相当有限。给它一组简单的指令和几个工具，它能回答问题、调用一两个工具，但当你需要它与其他系统协作、处理支付、或实时流式传输结果时，它就会碰壁。

传统API假设另一端是人类用户——人可以点击"购买"按钮，可以浏览商品目录，可以阅读表单。但AI智能体不知道如何结账，没有商品目录可浏览，它只能生成文本。Google Cloud的开发者关系工程师Chris Overholt在最新的技术分享中，系统梳理了六大协议如何逐一解决这些问题。

本文将以一个厨房管理智能体（为餐厅从批发商订购食材）为例，使用Google开源的Agent Development Kit（ADK）框架，逐步添加协议，让智能体从"编造数据"进化为能够查询真实库存、下单、授权支付并实时展示交互式仪表盘的完整系统。

MCP：模型上下文协议——让智能体连接工具与数据

MCP解决的核心问题

智能体需要使用外部工具，但如果每个API端点都需要自定义工具定义，几个服务下来你就要管理数十个工具，这对开发者和智能体都不可扩展。

MCP的工作原理

MCP（Model Context Protocol）让智能体连接到MCP服务器，服务器在运行时动态暴露可用工具。你不需要硬编码工具定义，只需指向MCP服务器，智能体就能自动发现可用能力。

背景知识：MCP的标准化之路 MCP由Anthropic于2024年11月正式开源，迅速成为AI工具集成领域的事实标准。其设计灵感来源于语言服务器协议（LSP，Language Server Protocol）——LSP由微软提出，统一了VS Code等代码编辑器与各类语言工具（如代码补全、语法检查）之间的通信方式，使得一个语言插件可以服务于所有支持LSP的编辑器，而无需为每个编辑器单独开发。MCP采用完全相同的思路：定义一套标准化的客户端-服务器通信规范，让任何AI模型都能以统一方式调用任何外部工具或数据源，彻底解耦模型与工具的绑定关系。在MCP出现之前，每个AI应用都需要为每个外部服务编写专属的"工具定义"代码，维护成本随工具数量线性增长；MCP之后，工具开发者只需发布一个MCP服务器，所有兼容模型即可自动接入。

对于厨房管理智能体，这意味着连接三个MCP服务器：库存数据库、食谱与操作流程、供应商邮件。在ADK中，每个服务器只需三行代码，使用MCP Toolset即可，无需编写任何API调用。

MCP的核心价值在于原型开发阶段——当你还在探索智能体能做什么时，MCP让你快速接入新数据源，观察智能体如何利用它们，然后再进行优化。

A2A：智能体间协议——实现跨团队专业知识协作

A2A解决的核心问题

厨房管理智能体能查库存，但不了解当日批发价格、供应商质量等级或配送时间窗口。这些知识分散在不同团队、不同框架构建的不同智能体中。

A2A的工作原理

A2A（Agent-to-Agent Protocol）通过标准化的智能体发现机制解决这个问题。每个智能体在一个已知URL上提供"智能体卡片"（Agent Card），描述其能力。你的智能体获取这些卡片，发现每个专家能做什么，然后通过send message进行通信。

背景知识：A2A与微服务架构的渊源 A2A由Google于2025年4月发布，是专为多智能体系统设计的通信标准。理解A2A最好的类比是微服务架构中的**服务注册与发现（Service Registry & Discovery）**机制——在微服务体系中，每个服务启动时会向注册中心（如Consul、Eureka）登记自己的地址和能力，其他服务通过查询注册中心来找到所需的协作方，而无需硬编码对方的地址。A2A的"智能体卡片"扮演的正是这个角色，但专为AI智能体设计：卡片不仅描述服务地址，还用自然语言描述智能体的专业领域、支持的任务类型和交互模式。A2A基于HTTP/JSON-RPC构建，支持同步请求、异步任务和流式响应三种通信模式，并内置身份验证机制，确保跨组织、跨框架的智能体协作安全可靠。这意味着一个用LangChain构建的定价智能体和一个用ADK构建的物流智能体，可以通过A2A无缝协作，无需任何框架层面的适配工作。

在ADK中，用to_a2a方法一行代码就能将任何智能体暴露为A2A服务。在发现端，指向远程智能体URL、获取卡片、发送消息即可。智能体无需知道远程智能体是如何构建的，甚至不需要知道它运行在什么框架上。

实际效果：当你问"三文鱼什么价？质量等级如何？今天5点前能送到吗？"智能体会自动将每个问题路由到正确的专家（定价、质量、物流），而无需了解它们的实现细节。

UCP：通用商务协议——结构化的商业交易

UCP解决的核心问题

智能体需要下订单，但人类可以浏览店面，智能体需要的是机器可读的商家信息和产品发现能力。

UCP的工作原理

UCP（Universal Commerce Protocol）标准化了商家发现、下单和订单跟踪的流程。它通过/.well-known/ucp端点提供结构化的商品目录，智能体可以发送包含商品明细、数量和支付信息的结构化结账请求。

背景知识：.well-known端点的设计惯例 UCP采用的/.well-known/路径是互联网工程任务组（IETF）在RFC 5785中定义的标准惯例，专门用于存放"众所周知"的元数据文件。你可能已经熟悉这一模式：/.well-known/openid-configuration用于OAuth身份验证发现，/.well-known/security.txt用于安全漏洞披露。UCP沿用这一惯例，意味着任何支持UCP的商家只需在其域名下部署一个标准JSON文件，AI智能体就能自动发现其商品目录和交易规则，无需任何额外的集成工作。这种"约定优于配置"的设计哲学，使得UCP的接入成本极低，同时保持了高度的互操作性。

**不需要浏览网站，不需要解析HTML，不需要猜测结账流程。**所有操作都是标准HTTP请求，遵循UCP规范。类型化的请求格式意味着智能体不必猜测结账请求应该长什么样。

AP2：智能体支付协议——授权与审计

AP2解决的核心问题

UCP让智能体能下单，但谁授权了这笔支出？没有审计追踪，没有消费限额，没有批准的商家列表。

AP2的工作原理

AP2（Agent Payments Protocol）引入了类型化的"授权委托"（Mandates）：

• 结账委托（Checkout Mandate）：定义护栏，如哪些商家被批准、可以购买什么
• 支付委托（Payment Mandate）：强制执行消费限额、指定批准的支付方式、记录用户授权
• 签名收据（Signed Receipts）：创建完整的审计追踪

背景知识：从"提示词约束"到"密码学合约"的信任升级 AP2的设计哲学源于金融领域的最小权限原则（Principle of Least Privilege），并借鉴了两个成熟的技术范式：其一是OAuth 2.0的授权委托模型——用户不直接把密码交给第三方应用，而是颁发一个权限受限的"令牌"，精确定义该应用能做什么、不能做什么；其二是银行业的**支付指令（Standing Order）**概念，即预先设定的自动付款规则，银行系统强制执行，而非依赖付款人每次自觉遵守。AP2将这两种思路融合，将消费规则从"提示词中的自然语言约束"（例如"你不应该花超过500美元"）提升为"密码学可验证的类型化合约"。前者依赖模型的"理解"和"遵从"，存在被绕过或误解的风险；后者在协议层面强制执行，任何违规交易在技术上无法完成。签名收据则引入了不可否认性（Non-repudiation）——每笔交易都有完整的授权链证明，满足企业级合规审计的要求。

实际配置示例：餐厅老板可以设定"只从这些批准的供应商购买"、"公司卡上500美元以下的订单自动批准"、"超过500美元需要经理签字"。当智能体试图从未授权供应商购买时，委托会拒绝；当它下达合法订单时，会获得包含完整授权链的签名收据。

关键区别：与其在指令中告诉智能体"不要花超过500美元