A2A vs ACP 协议对比分析

作者: Phodal Huang 2026年2月9日 11:02

本文档对比分析 A2A (Agent-to-Agent Protocol) 和 ACP (Agent Client Protocol) 两个协议的核心差异、设计理念和适用场景。

执行摘要

维度	A2A	ACP
核心定位	Agent 与 Agent 之间的互操作协议	IDE/编辑器与 AI Coding Agent 之间的通信协议
一句话概括	"Agent 间的 HTTP" — 分布式 Agent 互操作标准	"AI Agent 的 LSP" — IDE 与编码 Agent 的通信标准
设计目标	跨组织、跨厂商的 Agent 互联互通	编辑器内嵌 AI 编码助手的标准化接口
通信关系	对等通信 (Agent ↔ Agent)	主从通信 (Client/IDE → Agent 子进程)
网络模型	分布式网络通信，支持远程调用	本地进程间通信 (stdio)
关系	互补而非竞争 — 可在同一系统中共存使用

一、Schema 定义方式对比

A2A

规范源: Protobuf (specification/a2a.proto)
衍生格式: 从 Proto 自动生成 JSON Schema (非规范文档)
序列化: ProtoJSON (枚举值使用 SCREAMING_SNAKE_CASE)
优势: 类型安全、跨语言支持、自动代码生成

ACP

规范源: JSON Schema (schema/schema.json, ~140KB)
衍生格式: 从 JSON Schema 生成 Rust 类型定义
序列化: 标准 JSON
方法索引: meta.json 提供方法名映射表
优势: Web 生态友好、易于手写和调试

二、传输层 (Transport Layer)

A2A — 多协议、网络分布式

传输方式	说明
JSON-RPC 2.0 over HTTP(S)	主要协议绑定
gRPC	完整 gRPC 服务定义
HTTP+JSON/REST	RESTful 端点映射
流式传输	Server-Sent Events (SSE)
推送通知	Webhook (支持离线场景)
服务发现	`/.well-known/agent-card.json`

传输示例 (JSON-RPC):

{
  "jsonrpc": "2.0",
  "id": "req-001",
  "method": "SendMessage",
  "params": {
    "message": {
      "role": "ROLE_USER",
      "parts": [{"text": "Hello"}]
    }
  }
}

ACP — 本地进程通信

传输方式	说明
stdio	Client 启动 Agent 子进程，通过 stdin/stdout 通信
消息格式	换行分隔的 JSON-RPC 消息
流式传输	JSON-RPC Notification 流
推送通知	无需 (进程内实时通知)
服务发现	无需 (Client 直接启动 Agent)

传输示例:

{"jsonrpc":"2.0","method":"initialize","params":{...},"id":1}\n
{"jsonrpc":"2.0","method":"session/update","params":{...}}\n

关键差异: A2A 设计用于跨网络、跨组织的 Agent 通信；ACP 设计用于编辑器与本地 Agent 进程的紧密集成。

三、核心数据模型对比

3.1 Agent 描述

A2A: `AgentCard` — 完整的自描述清单

message AgentCard {
  string name = 1;
  string description = 2;
  string version = 5;
  repeated AgentInterface supported_interfaces = 19;  // 网络接口
  AgentProvider provider = 4;
  AgentCapabilities capabilities = 7;
  repeated AgentSkill skills = 12;                    // 技能声明
  map<string, SecurityScheme> security_schemes = 8;   // 安全方案
  repeated SecurityRequirement security_requirements = 13;
  string icon_url = 18;
}

特点: - 包含完整的网络接口信息 (URL + 协议绑定) - 详细的技能声明 (带 tags、examples) - 企业级安全配置 (OAuth2, OIDC, mTLS) - Provider 信息和图标

ACP: `AgentInfo` + 能力协商

{
  "name": "MyAgent",
  "version": "1.0.0",
  "agentCapabilities": {
    "loadSession": true,
    "promptCapabilities": {
      "image": true,
      "audio": true,
      "embeddedContext": true
    },
    "mcpCapabilities": {...}
  },
  "authMethods": [
    {"id": "github", "name": "GitHub OAuth"}
  ]
}

特点: - 轻量级 (无需网络接口信息) - 双向能力协商 (类似 LSP) - 简化的认证方式 - 专注于编码能力声明

3.2 任务/会话模型

A2A: `Task` — 不可变的任务单元

message Task {
  string id = 1;
  string context_id = 2;          // 关联多个任务
  TaskStatus status = 3;
  repeated Artifact artifacts = 4; // 命名的输出物
  repeated Message history = 5;    // 完整对话历史
  google.protobuf.Struct metadata = 6;
}

状态机 (8 个状态):

SUBMITTED → WORKING → {
  COMPLETED (终态)
  FAILED (终态)
  CANCELED (终态)
  REJECTED (终态)
  INPUT_REQUIRED (中断态)
  AUTH_REQUIRED (中断态)
}

特点: - 任务不可变性: Terminal 状态后不可重启 - 任务引用: 通过 reference_task_ids 实现任务链 - 上下文分组: context_id 关联相关任务 - Artifact: 命名的结构化输出

ACP: `Session` + `PromptTurn` — 持久会话

{
  "sessionId": "session-123",
  "cwd": "/path/to/project",
  "modes": ["ask", "code", "architect"]
}

PromptTurn 生命周期:

session/prompt →
  session/update (plan) →
  session/update (agent_message_chunk) →
  session/update (tool_call) →
  [session/request_permission] →
  session/update (tool_call_update: completed) →
session/prompt response (stopReason)

停止原因 (5 种): - end_turn — 正常结束 - max_tokens — 达到 token 上限 - max_turn_requests — 达到请求上限 - refusal — 拒绝执行 - cancelled — 用户取消

特点: - 会话持久化: 可 load/resume - 多模式: ask/code/architect 等 - 配置化: 可动态调整 session config - 无独立 Artifact: 输出通过 tool_call 体现

3.3 消息与内容

A2A: `Message` + `Part`

message Message {
  string message_id = 1;
  Role role = 4;  // ROLE_USER / ROLE_AGENT
  repeated Part parts = 5;
  repeated string reference_task_ids = 8;
}

message Part {
  oneof content {
    string text = 1;
    bytes raw = 2;
    string url = 3;
    google.protobuf.Value data = 4;  // 任意 JSON
  }
  string media_type = 7;
  string filename = 6;
}

ACP: `ContentBlock`

{
  "type": "text",
  "text": "Hello"
}
// 或
{
  "type": "image",
  "data": "base64...",
  "mimeType": "image/png"
}
// 或
{
  "type": "resource",
  "uri": "file:///path/to/file",
  "text": "content",
  "mimeType": "text/plain"
}

支持类型: - Text — 纯文本/Markdown - Image — Base64 图片 (需 image 能力) - Audio — Base64 音频 (需 audio 能力) - ResourceLink — 资源引用 - Resource — 嵌入式资源 (需 embeddedContext 能力)

关键差异: A2A 的 Part.data 支持任意 JSON 结构化数据；ACP 专注于编辑器场景的内容类型。

3.4 工具调用 — 核心设计差异

A2A: 无工具调用概念

A2A 刻意保持 Agent 内部实现的不透明性 (Opacity): - Agent 内部如何使用工具是实现细节 - 对外仅暴露 Task 状态和 Artifact - 工具调用不出现在协议层面

设计理念: Agent 作为黑盒，Client 只关心"任务完成了吗"，不关心"用了什么工具"。

ACP: 工具调用为一等公民

{
  "type": "tool_call",
  "toolCall": {
    "toolCallId": "call-001",
    "title": "Read file: main.py",
    "kind": "read",
    "status": "in_progress",
    "content": [
      {
        "type": "text",
        "text": "Reading file..."
      }
    ],
    "locations": [
      {
        "path": "/path/to/main.py",
        "range": {"start": {"line": 0, "character": 0}, "end": {...}}
      }
    ]
  }
}

工具元数据: - kind: read / edit / delete / move / search / execute / think / fetch / other - status: pending → in_progress → completed / failed - content: 工具输出 (text / diff / terminal) - locations: 影响的文件位置

权限控制:

{
  "method": "session/request_permission",
  "params": {
    "sessionId": "session-123",
    "permission": {
      "type": "fs_write",
      "path": "/path/to/file.txt"
    }
  }
}

设计理念: IDE 需要完全掌控 Agent 的每一步操作，以便展示、审核、回滚。

为什么如此不同？

场景	A2A	ACP
跨组织 Agent 协作	✅ 不暴露内部工具，保护商业机密	❌ 不适用
IDE 内编码助手	❌ 缺少细粒度控制	✅ 每步可见、可控、可审核

四、实时更新机制

A2A: `StreamResponse` (SSE)

Content-Type: text/event-stream

data: {"task":{"id":"task-1","status":"TASK_STATE_WORKING"}}

data: {"message":{"parts":[{"text":"Processing..."}]}}

data: {"task":{"id":"task-1","status":"TASK_STATE_COMPLETED","artifacts":[...]}}

推送通知 (Webhook):

{
  "url": "https://client.example.com/webhook",
  "token": "secret-token",
  "authentication": {
    "type": "JWT",
    "signingKey": "..."
  }
}

特点: - 支持长时间离线场景 - 适合异步、分布式任务 - Push 通知支持加密签名、防重放攻击

ACP: `SessionUpdate` (JSON-RPC Notification)

{"jsonrpc":"2.0","method":"session/update","params":{"type":"plan","plan":{...}}}\n
{"jsonrpc":"2.0","method":"session/update","params":{"type":"agent_message_chunk","text":"Let me"}}\n
{"jsonrpc":"2.0","method":"session/update","params":{"type":"tool_call","toolCall":{...}}}\n
{"jsonrpc":"2.0","method":"session/update","params":{"type":"tool_call_update","toolCallId":"call-1","status":"completed"}}\n

SessionUpdate 类型 (10+ 种): - plan — 执行计划 - agent_message_chunk — Agent 消息流 - agent_thought_chunk — Agent 内部思考 - tool_call — 新工具调用 - tool_call_update — 工具进度更新 - current_mode_update — 模式切换 - config_option_update — 配置变更 - available_commands_update — 可用命令

特点: - 实时、细粒度更新 - 暴露 Agent 思考过程 (agent_thought_chunk) - 支持 Diff 展示 (ToolCallContent.diff)

五、安全与认证

A2A — 企业级安全

支持的认证方式:

OAuth2 protobuf message OAuth2SecurityScheme { repeated string flows = 2; // authorization_code, client_credentials, device_code string metadata_url = 3; // RFC 8414 bool pkce_required = 4; }
OpenID Connect protobuf message OpenIDConnectSecurityScheme { string discovery_url = 2; }
API Key protobuf message APIKeySecurityScheme { string location = 2; // query, header, cookie string name = 3; }
HTTP Auth protobuf message HTTPAuthSecurityScheme { string scheme = 2; // Bearer, Basic string bearer_format = 3; }
Mutual TLS (mTLS)

认证流程:

1. Client 获取 AgentCard (/.well-known/agent-card.json)
2. 解析 security_schemes 和 security_requirements
3. Out-of-band 获取凭证 (OAuth 流程、API Key 分发等)
4. HTTP Header 传输: Authorization: Bearer <TOKEN>
5. Server 验证每个请求

企业安全特性: - TLS 1.2+ 强制 (生产环境) - 审计日志 (Audit Logging) - 数据合规 (GDPR, CCPA, HIPAA) - 分布式追踪 (OpenTelemetry) - Push 通知安全 (JWT 签名、HMAC、防重放)

ACP — 简化认证

{
  "authMethods": [
    {
      "id": "github-oauth",
      "name": "GitHub OAuth",
      "description": "Authenticate via GitHub"
    }
  ]
}

认证流程:

1. Agent 在 initialize 响应中声明 authMethods
2. Client 调用 authenticate(methodId)
3. 完成认证

权限模型:

{
  "method": "session/request_permission",
  "params": {
    "permission": {
      "type": "fs_write",
      "path": "/absolute/path/to/file.txt"
    }
  }
}

安全约束: - 文件路径必须为绝对路径 - Client 完全控制资源访问 - 操作级权限请求

关键差异: A2A 面向零信任网络环境，需要完整的企业级安全；ACP 在可信本地环境中运行，侧重操作级权限控制。

六、能力协商 (Capability Negotiation)

A2A — 单向声明

message AgentCapabilities {
  bool streaming = 1;
  bool push_notifications = 2;
  repeated string extensions = 3;
}

Agent 在 AgentCard 中静态声明能力
Client 读取并适配
无双向协商过程

ACP — 双向协商 (类似 LSP)

Client 发送:

{
  "method": "initialize",
  "params": {
    "protocolVersion": "1.0",
    "clientCapabilities": {
      "fs": {
        "readTextFile": true,
        "writeTextFile": true
      },
      "terminal": true
    }
  }
}

Agent 响应:

{
  "result": {
    "protocolVersion": "1.0",
    "agentCapabilities": {
      "loadSession": true,
      "promptCapabilities": {
        "image": true,
        "audio": false,
        "embeddedContext": true
      },
      "mcpCapabilities": {
        "http": true,
        "sse": true
      }
    }
  }
}

优势: - 版本协商 (避免不兼容) - 双方都知道对方能力 - 动态特性启用/禁用

七、扩展性机制

A2A

扩展标识: URI

message AgentCapabilities {
  repeated string extensions = 3;  // e.g., "https://example.com/a2a/extensions/voice"
}

激活扩展:

A2A-Extensions: https://example.com/a2a/extensions/voice, https://example.com/a2a/extensions/vision

扩展类型: - Data-only: 新增 metadata 字段 - Profile: 预定义能力组合 - RPC: 新增 RPC 方法 - State Machine: 新增 Task 状态

ACP

自定义方法: _ 前缀

{
  "method": "_custom/my_feature",
  "params": {...}
}

元数据: _meta 字段

{
  "sessionId": "session-123",
  "_meta": {
    "customField": "value"
  }
}

MCP 集成: 原生支持

{
  "mcpServers": {
    "server1": {
      "type": "stdio",
      "command": "node",
      "args": ["server.js"]
    }
  }
}

八、独有特性对比

仅 A2A 支持

特性	说明
Agent 发现	`/.well-known/agent-card.json` 标准
Artifact	命名的结构化输出物
Push Notification	Webhook 推送 (离线场景)
多租户支持	`/{tenant}/...` 路径参数
AgentCard 签名	可信 Agent 验证
gRPC 原生支持	完整 gRPC 服务定义
AgentSkill	带 examples 和 tags 的技能声明
任务引用	`reference_task_ids` 实现任务链
企业级安全	OAuth2, OIDC, mTLS, 审计日志

仅 ACP 支持

特性	说明
文件系统操作	`fs/read_text_file`, `fs/write_text_file`
终端集成	`terminal/execute`, 实时输出
Agent Plan	多步执行计划展示
Session Modes	ask / architect / code 等模式
Session Config	动态配置选项
权限请求	`session/request_permission` 细粒度授权
Agent Thought	内部思考过程暴露
Diff 展示	`ToolCallContent.diff` 代码变更对比
MCP 集成	原生支持 MCP Server (stdio/HTTP/SSE)
Session 持久化	`session/load`, `session/resume`

九、适用场景对比

A2A 适用场景

✅ 多 Agent 编排

研究 Agent → 数据收集 Agent → 分析 Agent → 报告生成 Agent

✅ 跨平台 Agent 协作

Slack Agent ← → Jira Agent ← → GitHub Agent

✅ 企业级 Agent 网络

                 认证网关
                    ↓
        ┌──────────┼──────────┐
        ↓          ↓          ↓
    HR Agent   IT Agent   财务 Agent

✅ Agent Marketplace

开发者发布 Agent → AgentCard 注册 → 用户发现和调用

✅ 长时间异步任务

Client 提交任务 → 断开连接 → Agent 处理 (数小时) → Webhook 通知完成

ACP 适用场景

✅ IDE 内 AI 编码助手

VS Code / Cursor / JetBrains + AI Agent (本地或远程)

✅ 代码生成/重构

用户: "将这个函数重构为 async/await"
Agent: [tool_call: read] → [tool_call: edit] → [展示 diff]

✅ 多模态代码理解

用户: [上传截图] "实现这个 UI"
Agent: [image 能力] → 生成代码

✅ 交互式调试

Agent: [terminal/execute: pytest]
Agent: [tool_call: edit 修复 bug]
Agent: [terminal/execute: pytest] ✅

✅ Session 持久化

早上: 开始重构任务 (session-1)
下午: 切换到 bug 修复 (session-2)
第二天: 恢复重构任务 (session/load: session-1)

十、协同使用示例

A2A 和 ACP 不是竞争关系，而是互补关系。以下是协同使用场景:

场景: 企业级 AI 开发平台

┌─────────────────────────────────────────────────────┐
│                   VS Code (IDE)                     │
│  ┌───────────────────────────────────────────────┐  │
│  │   ACP Client                                  │  │
│  │      ↕ (stdio)                                │  │
│  │   Local Coding Agent (ACP Agent)              │  │
│  │      ↓                                        │  │
│  │   [需要调用远程 Agent]                         │  │
│  │      ↓                                        │  │
│  │   A2A Client (内嵌)                           │  │
│  └───────┼──────────────────────────────────────┘  │
│          │                                          │
└──────────┼──────────────────────────────────────────┘
           │ (HTTPS + JSON-RPC)
           ↓
┌──────────────────────────────────────────────────────┐
│              企业 Agent 网关 (A2A)                    │
│  ┌────────────┐  ┌────────────┐  ┌────────────┐     │
│  │ Code Review│  │ Security   │  │ Test Gen   │     │
│  │   Agent    │  │   Agent    │  │   Agent    │     │
│  └────────────┘  └────────────┘  └────────────┘     │
└──────────────────────────────────────────────────────┘

流程: 1. 开发者在 VS Code 中发起请求 2. ACP: IDE → Local Coding Agent 3. Coding Agent 判断需要调用远程 Security Agent 4. A2A: Coding Agent → 企业 Agent 网关 → Security Agent 5. A2A: Security Agent 返回分析结果 6. ACP: Coding Agent → IDE (展示结果和 tool_calls)

十一、设计哲学差异

维度	A2A	ACP
透明度	不透明 (Opaque) — Agent 内部是黑盒	透明 (Transparent) — Agent 每步可见
信任模型	零信任 — 跨组织网络通信	可信环境 — 本地进程或受控网络
控制权	Agent 主导 — 自主决策和执行	Client 主导 — IDE 控制每步操作
协议复杂度	中等 (聚焦消息和任务)	高 (深度集成 IDE 功能)
版本演进	Protobuf 向后兼容	JSON Schema + 版本协商
可观测性	Task 状态 + Artifact	完整 tool_call trace

十二、总结

关键要点

不同的问题域
A2A 解决: "Agent 如何与其他 Agent 通信"
ACP 解决: "IDE 如何驱动一个 AI Agent"
互补而非竞争
一个完整的 AI 开发环境可以同时使用两者
A2A 管 Agent 间通信，ACP 管 Agent 与 IDE 通信
设计权衡
A2A: 标准化、互操作性、企业级安全
ACP: IDE 深度集成、细粒度控制、实时反馈

选型建议

选择 A2A 当: - 需要跨组织 Agent 协作 - 构建 Agent Marketplace - 处理长时间异步任务 - 需要企业级安全和审计

选择 ACP 当: - 构建 IDE 内 AI 编码助手 - 需要展示 Agent 每步操作 - 需要用户权限审批 - 需要 Session 持久化和模式切换

同时使用当: - 构建企业级 AI 开发平台 - IDE 内 Agent 需要调用远程专业 Agent - 需要本地快速反馈 + 云端强大能力

附录: 快速对照表

特性	A2A	ACP
Schema	Protobuf	JSON Schema
传输	HTTP(S)/gRPC	stdio
网络模型	分布式	本地进程
服务发现	✅	❌
工具调用	❌ (不透明)	✅ (一等公民)
文件操作	❌	✅
终端集成	❌	✅
权限请求	❌	✅
Session 持久化	❌	✅
Artifact	✅	❌
Push Notification	✅	❌
OAuth2/OIDC	✅	❌
mTLS	✅	❌
Agent Plan	❌	✅
Diff 展示	❌	✅
MCP 集成	❌	✅
多租户	✅	❌
gRPC	✅	❌

文档版本: 1.0
最后更新: 2026-02-09
贡献: 欢迎通过 PR 补充和修正

或许您还需要下面的文章: