---
author: QinIndexCode
title: MCP 与 A2A：AI Agent 互操作的协议边界、可信边界与工程落地
date: 2026-07-22
tags: AI, Agent, MCP, A2A, 协议, 互操作性, 安全, 架构设计
---

## 2026-07-22 MCP 与 A2A：AI Agent 互操作的协议边界、可信边界与工程落地

过去一年，Agent 系统的讨论很容易被简化成一个问题：要不要接入 MCP，或者要不要采用 A2A。这个问法本身就容易把架构带偏，因为两者解决的并不是同一层的问题。

截至本文写作时，Model Context Protocol（MCP）已经形成了较完整的客户端、服务端和授权规范；Agent2Agent（A2A）则在 2026 年发布了 1.0 版本，试图为跨框架、跨组织的 Agent 协作提供统一通信层。前者回答“Agent 如何安全地使用工具和数据”，后者回答“一个 Agent 如何把任务交给另一个 Agent”。

真正需要解决的问题不是在二者之间二选一，而是划清协议边界、可信边界和职责边界。

---

## 一、先区分两个完全不同的问题

一个实际的 Agent 系统通常至少有三类参与者：用户、负责决策的 Agent、提供能力的外部系统。外部系统可能是 GitHub、数据库、浏览器、企业内部 API，也可能是一个由另一个团队维护的专业 Agent。

MCP 的核心模型是 Host、Client、Server：

- **Host** 是承载 LLM 的应用，例如 IDE、桌面客户端或自建 Agent Runtime。
- **Client** 是 Host 内部连接某个 MCP Server 的协议端。
- **Server** 暴露资源、提示词模板和工具。

它的重点是把“模型需要的信息”和“模型可以调用的函数”标准化。协议以 JSON-RPC 2.0 为基础，要求能力协商，并把 Resources、Prompts、Tools 作为主要服务端能力。

A2A 则将通信对象提升为独立 Agent。一个远端 Agent 可以公开自己的能力描述，通过 Agent Card 被发现，接收任务、流式返回进度、异步完成长任务，并且不必暴露其内部模型、记忆、工具链或私有实现。

因此可以用一句简单的话概括：

> MCP 解决 Agent 到能力的连接；A2A 解决 Agent 到 Agent 的协作。

把数据库查询封装成 A2A Agent 并非绝对错误，但通常会平白引入任务管理、状态同步和远端调度复杂度；反过来，把一个拥有独立目标、独立权限和长时间任务生命周期的专业 Agent 伪装成 MCP Tool，也会丢失协作语义。

---

## 二、协议层不等于信任层

MCP 和 A2A 都能让系统“连通”，但连通不等于可信。协议描述消息如何传输、能力如何发现、任务如何流转；授权策略、数据最小化和审计责任仍然属于应用架构。

以 MCP 为例，官方规范明确提醒：Tool 代表任意代码执行路径；工具描述和注解在不可信服务器的场景下也应视为不可信输入。Host 应当在调用工具前取得用户明确授权，并使用户理解该操作会造成什么影响。

这带来三个工程结论。

### 1. 不要把 Tool 名称当成安全证明

一个名为 `read_file` 的工具未必只读文件；一个名为 `deploy_preview` 的工具也可能提交代码、上传环境变量或触发外部工作流。模型看到的名字、描述和 JSON Schema 都是决策线索，不是安全边界。

真正的安全边界应位于工具执行端：

- 依据身份和租户做服务端鉴权。
- 使用最小权限令牌，而不是共享高权限密钥。
- 对路径、SQL、URL、命令参数做服务端验证。
- 对高风险动作设置显式审批和可撤销的授权。
- 记录调用主体、参数摘要、资源范围、结果与失败原因。

### 2. 不要让远端 Agent 继承本地 Agent 的全部权限

在 A2A 场景中，调用方 Agent 不应将自己的长期凭据、完整上下文或无范围访问权直接转交给被调用方。远端 Agent 是一个独立的信任主体，即使它由合作团队维护，也可能发生提示词注入、依赖投毒、配置漂移或权限扩张。

更稳妥的做法是为每次任务签发范围明确、有效期短、可审计的委托凭据。委托内容至少需要限定：允许访问的资源、允许执行的动作、任务截止时间、最大调用次数与预算。

### 3. “用户已确认”不是一次性的布尔值

读取公开文档、读取私有仓库、创建 issue、执行迁移、生产发布属于不同风险等级。将它们压缩成一个“允许 Agent 操作”的开关，会让确认流程失去意义。

更合理的模型是基于动作和资源的分级策略。例如，`read:repository` 可以在任务范围内持续有效；`write:repository` 需要变更摘要确认；`deploy:production` 需要展示目标环境、版本、回滚方式与影响范围后再次确认。

---

## 三、为什么 A2A 不能简单替代 MCP

A2A 的价值在于处理“黑盒 Agent 协作”。它允许两个 Agent 在不共享内部记忆、提示词、模型提供商和工具实现的前提下协作。这对于跨组织系统尤其重要。

但它并不规定一个 Agent 内部如何调用子 Agent，也不定义工具调用细节。A2A 官方文档也明确将其定位为 Agent 间通信协议，而不是 Agent 开发框架、子 Agent 协议或 MCP 的替代品。

可以把一个典型系统分为三层：

```text
用户 / 产品界面
        |
编排 Agent：规划、授权、预算、审计
        |
  +-----+------------------+
  |                        |
MCP                     A2A
  |                        |
工具、资源、企业 API       独立的专业 Agent
```

其中，编排 Agent 负责对用户意图进行拆解，并对每个动作作出授权与预算判断。

- 需要读取仓库、查询数据库、创建工单时，调用 MCP Server 提供的具体工具。
- 需要委托法律审查 Agent、财务分析 Agent、代码迁移 Agent 或另一个组织的工作流 Agent 时，使用 A2A 发送任务。
- 被委托的远端 Agent 内部仍可以使用 MCP 连接它自己的工具和资源。

这种分层避免了两个常见问题：把低层工具包装成“假 Agent”，以及让中心编排器直接持有所有系统的高权限凭据。

---

## 四、把任务生命周期设计为可恢复的状态机

传统 RPC 往往假设请求会在短时间内完成，但 Agent 任务并不符合这个假设。一个任务可能需要等待人工补充信息、轮询第三方系统、执行多步验证，甚至因预算耗尽而暂停。

因此，跨 Agent 协作至少应具有以下状态：

```text
submitted -> working -> input-required -> completed
                     \-> failed
                     \-> canceled
```

工程上最重要的是：状态必须由服务端持久化，而不是只存在某次模型上下文中。调用方应保存稳定的任务标识，支持查询、取消、重试和恢复；被调用方应将中间产物、最终产物、错误码和可重试性清晰区分。

例如，一个“升级依赖并提交 Pull Request”的远端代码 Agent，不应只返回自然语言结论。至少应返回结构化产物：

```json
{
  "taskId": "task_7d91",
  "status": "completed",
  "artifacts": [
    { "type": "pull_request", "url": "https://example.com/pull/42" },
    { "type": "report", "content": "已升级 12 个依赖，测试通过 86/88。" }
  ],
  "warnings": ["两个快照测试需要人工确认"]
}
```

自然语言仍然适合解释，但它不应是自动化链路唯一的契约。调用方需要能够基于状态和产物编排后续动作，而不是依赖模型再去猜一段文本的含义。

---

## 五、能力发现应当是“可验证的声明”

无论是 MCP 的能力协商，还是 A2A 的 Agent Card，能力发现都不应被误解为可信注册。一个 Agent 声称自己“可以处理支付审批”，不代表它真的拥有该权限，也不代表它的输出满足组织合规要求。

生产环境建议为能力描述增加以下控制：

1. **来源验证**：只接受经过签名、受信任注册表或明确 allowlist 中的服务。
2. **版本固定**：记录协议版本、Agent 版本、工具版本和 Schema 版本，避免能力在运行中静默变化。
3. **策略映射**：把声明的能力映射到组织策略，例如只有经过审批的 `code-review` Agent 可以接触特定仓库。
4. **运行时校验**：服务端再次验证调用者身份、任务范围和参数，而不是只依赖发现阶段信息。
5. **可观测性**：对发现、协商、授权、调用、重试和取消建立同一条 trace。

这里的关键原则是：能力描述用于路由，策略系统用于授权，执行端用于强制。

---

## 六、MCP Server 的安全设计比“接入数量”更重要

随着 MCP Server 增多，风险往往不是某个工具过于危险，而是多个低风险能力组合后形成了高风险路径。

例如：一个工具可以读取 issue，另一个工具可以读取环境变量，第三个工具可以向外部 URL 发送请求。它们单独看都可能通过审查，组合起来却可能造成数据外泄。

因此，MCP Server 的评审不应只看单个 Tool，还应评估调用图：

- 哪些资源能够进入模型上下文？
- 哪些内容可能被模型转发给其他工具？
- 哪些工具可访问网络或持久化存储？
- 是否存在从“读取敏感信息”到“外发信息”的可达路径？
- 用户确认发生在链路的哪个节点？

在实现上，建议把工具按副作用分为 `read`、`write`、`execute`、`external-egress` 四类，并默认禁止跨类自动串联。尤其是 `external-egress`，即向外部网络、第三方服务或不可逆系统发送数据的操作，应获得单独策略控制。

---

## 七、一个可落地的最小架构

对于刚开始建设 Agent 平台的团队，不必一开始就实现复杂的去中心化协作网络。可以从以下最小架构开始：

1. 建立一个编排层，负责身份、会话、预算、审批和审计。
2. 将内部数据源和确定性操作封装为 MCP Server。
3. 为每个 Tool 定义输入 Schema、输出 Schema、副作用级别与资源范围。
4. 对耗时或跨团队任务引入 A2A Agent，并要求其返回结构化任务状态和产物。
5. 使用统一 traceId 贯穿用户请求、模型调用、MCP 调用和 A2A 任务。
6. 将策略判断放在模型之外，使模型只能提出调用意图，不能绕过执行端授权。

一个健康的系统应当允许替换模型、替换工具实现、替换远端 Agent，而不改变授权和审计的基本机制。协议的价值就在于降低这种替换成本；但只有将安全、状态和可观测性设计在协议之外，替换才不会演变成失控。

---

## 结语

MCP 和 A2A 的出现说明 Agent 工程正在从“单模型调用”进入“协议化系统集成”阶段。前者让工具和数据连接更标准，后者让独立 Agent 的协作开始有共同语言。

但协议不是自治系统的安全证明。一个可靠的 Agent 平台，必须同时回答四个问题：谁可以调用、可以访问什么、何时需要确认、出了问题如何追溯。把这些问题交给模型自行判断，或者寄希望于某个协议名称，本质上都是把架构责任推迟到事故发生之后。

真正值得投入的，不是接入更多协议，而是在清晰边界内让协议发挥作用。

---

## 参考资料

1. [Model Context Protocol Specification, 2025-11-25](https://modelcontextprotocol.io/specification/2025-11-25/)
2. [MCP Architecture](https://modelcontextprotocol.io/specification/2025-11-25/architecture/)
3. [MCP Authorization](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization/)
4. [Introducing the Model Context Protocol, Anthropic, 2024-11-25](https://www.anthropic.com/news/model-context-protocol)
5. [A2A Protocol Documentation](https://a2a-protocol.org/latest/)
6. [Agent2Agent Protocol Repository](https://github.com/a2aproject/A2A)