📖 本文已同步发布到公众号《浪浪山客栈》
https://mp.weixin.qq.com/s/-VfuWtXcVnwNA4iJmjBAZg
随着 AI Agent 的快速普及，一个现实问题浮出水面：Agent 越来越多，但它们彼此说不上话。
不同框架、不同公司构建的 Agent，各有各的接口、各有各的数据格式。想让它们协作，开发者必须手写大量胶水代码。三个协议的出现，正是为了解决这个问题——但它们解决的，是三个层次完全不同的问题。
MCP：Agent 的 USB-C 接口
MCP（Model Context Protocol） 由 Anthropic 于 2024 年底推出，解决的是 Agent 与外部工具/数据之间的连接问题。
在 MCP 出现之前，行业面临"N×M 集成灾难"：N 个 AI 框架对接 M 个数据源，就需要写 N×M 套定制代码。MCP 把这个问题变成了 N+M——数据提供方只需实现一个 MCP Server，任何 Agent 都能即插即用。
传输层：两种运行模式
MCP 支持两种传输方式，这决定了它的部署形态：
- stdio 模式：Client 以子进程方式启动 Server，通过标准输入/输出通信。企业私有数据库、本地代码库不需要暴露到公网，整个调用链在本地闭合。这是 MCP 最被低估的安全价值。
- HTTP + SSE 模式：Server 作为独立服务部署，Client 通过 HTTP 发送请求，Server 通过 Server-Sent Events 推送响应流。适合跨网络调用远程工具。
协议层：JSON-RPC 2.0
MCP 的消息格式基于 JSON-RPC 2.0。一次完整的工具调用分两步：
第一步：能力发现（tools/list）
Agent 启动时向 Server 查询它提供哪些工具：
// Request
{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }
// Response
{
"tools": [{
"name": "query_database",
"description": "执行 SQL 查询并返回结果",
"inputSchema": {
"type": "object",
"properties": {
"sql": { "type": "string" }
},
"required": ["sql"]
}
}]
}第二步：工具调用（tools/call）
Agent 构造请求，Server 执行并返回结果：
// Request
{
"jsonrpc": "2.0", "id": 2,
"method": "tools/call",
"params": {
"name": "query_database",
"arguments": { "sql": "SELECT * FROM orders WHERE status='pending' LIMIT 10" }
}
}
// Response
{
"content": [{ "type": "text", "text": "[{\"id\": 1, \"amount\": 299.00}, ...]" }],
"isError": false
}这个设计的精妙之处在于：Agent 从来不需要知道数据库是 MySQL 还是 PostgreSQL，它只需要会说 JSON-RPC。
核心局限：MCP 只解决了"Agent ↔ 工具"的垂直方向。两个具备独立决策能力的 Agent 之间如何对话？MCP 管不了。
A2A：Agent 之间的通用商业语言
A2A（Agent-to-Agent Protocol） 由 Google Cloud 于 2025 年 4 月联合 50 多家科技巨头推出，解决的是 Agent 与 Agent 之间的协作问题。
A2A 的关键设计哲学是黑盒协作：企业之间的 Agent 协作不需要暴露底层模型、内部 Prompt 或私有工具链，只通过标准接口完成任务委托。这让跨公司、跨平台的 Agent 协作在商业上成为可能。
Agent Card：服务发现的基础
每个兼容 A2A 的 Agent 在固定路径（/.well-known/agent.json）发布一份元数据文件，描述自己的能力边界和接入方式：
{
"name": "供应链订单 Agent",
"description": "处理采购订单、库存查询和物流协调",
"url": "https://supply.example.com/agent",
"version": "1.0.0",
"capabilities": {
"streaming": true,
"pushNotifications": true
},
"skills": [{
"id": "create_purchase_order",
"name": "创建采购订单",
"description": "根据物料编号和数量生成采购订单",
"inputModes": ["text", "application/json"]
}],
"authentication": {
"schemes": ["OAuth2"]
}
}Client Agent 读取这张"名片"，就知道如何与远程 Agent 建立连接、具备什么能力、需要什么认证。
任务生命周期
A2A 将每次协作封装为一个 Task，任务状态流转如下：
submitted → working → [input-required] → working → completed
↘ failed
↘ canceledinput-required 是关键状态——当远程 Agent 需要额外信息（如人工审批）时，会暂停并通知 Client，而不是盲目执行或超时失败。对于耗时任务，Server 通过 SSE 持续推送进度，Client 无需轮询。
这套状态机让"长时间、多轮次、需人工介入"的复杂任务变得可管理。
核心局限：A2A 解决了通信通道问题，但无法解决语义分歧——两个 Agent 的底层模型对"紧急"这个词理解不同，完美的协议也救不了错误的执行。黑盒通信同样让跨 Agent 的 Debug 极其困难。
ANP：Agent 的谈判协议
ANP（Agent Negotiation Protocol） 由开源社区维护，目前仍处于早期阶段，解决的是 Agent 之间复杂协商的问题。
如果说 A2A 是"你委托我去做这件事"，ANP 处理的是"我们双方就这件事的条件来回谈"。在供应链、资源调度、智能电网等场景，Agent 需要针对价格、数量、时间、优先级等多个维度反复提案、反驳、妥协。
谈判消息结构
ANP 的核心是一套结构化消息类型。一次典型的双边谈判报文如下：
// 采购 Agent 发起提案（第 1 轮）
{
"type": "Proposal",
"negotiation_id": "neg-20260427-001",
"round": 1,
"from": "procurement-agent",
"to": "supplier-agent",
"content": {
"item": "CPU-X100",
"quantity": 500,
"unit_price": 120.00,
"delivery_days": 7
}
}
// 供应商 Agent 反提案，附带论证（第 2 轮）
{
"type": "CounterProposal",
"negotiation_id": "neg-20260427-001",
"round": 2,
"content": {
"quantity": 500,
"unit_price": 135.00,
"delivery_days": 5
},
"justification": "当前原材料成本上涨 12%，但可优先排产，提前交货"
}谈判状态从 PENDING → ACTIVE，最终走向 ACCEPTED 或 TERMINATED。所有消息结构化存档，完整还原谈判过程，可供审计。
ANP 与 A2A 的本质区别
A2A 是单向委托（Client 发任务，Server 执行），ANP 是多轮博弈（双方反复提案直到共识）。两者可以叠加使用——ANP 谈妥条件后，由 A2A 负责执行具体任务。
核心局限：ANP 只是谈判的骨架，协议再完善，模型推理能力不足照样谈崩。更危险的是，恶意设计的 Agent 可以利用协议灵活性拖延或欺骗——信任机制的构建仍是未解难题。
三层协议的关系
![[Pasted image 20260427164354.png]]
这三个协议不是竞争关系，而是互补的三个层次：
ANP ───── Agent 之间如何协商和博弈（深度决策层）
A2A ───── Agent 之间如何对话和委托任务（水平协作层）
MCP ───── Agent 如何连接工具和数据（垂直接入层）一个成熟的多 Agent 系统，三层都需要。MCP 让每个 Agent 能够访问外部世界，A2A 让 Agent 之间能够协作分工，ANP 让 Agent 在利益冲突时能够自主谈判。
目前，MCP 已经有成熟生态（Cursor、Zed 等已广泛支持），A2A 正在快速成为行业标准，ANP 仍在早期探索阶段。Agent 的互联互通，才刚刚开始。