AI Agent 协议栈:前端开发者必须知道的三层架构

2026年7月，AI Agent协议的格局基本落定了。三个协议各司其职，三层架构撑起整个Agent生态。

搞懂这三层，你会理解：

为什么Claude能读你的文件、查你的数据库

为什么两个Agent能自动协作完成任务

为什么Cursor/Zed里的AI编码助手可以换着用

以及，前端开发者在Agent时代的真正机会在哪

一、Agent怎么和外面的世界说话？

你用Cursor写代码，AI能读你的项目文件——它怎么做到的？

你让一个Agent帮你退款，它自动找到另一个Agent处理账单——它俩怎么认识的？

你在Zed里用Claude Code，换成Gemini CLI也能继续干活——为什么不用改配置？

答案就藏在三个协议里，每个协议解决一个不同层面的问题。

协议栈全景：

三层协议，三个问题：

层级	协议	解决的问题	类比
工具层	MCP	Agent怎么用工具和数据	USB-C接口
协作层	A2A	Agent之间怎么合作	HTTP
交互层	ACP	编辑器/人怎么和Agent对话	LSP

这三个协议不冲突，是互补的。

一个Agent同时使用三层：

向下用MCP接工具（读数据库、调API）

横向用A2A和其他Agent协作（分派任务、交换结果）

向上用ACP接入编辑器（让你在IDE里和它对话）

就像TCP/IP和HTTP不冲突一样——它们在不同层级解决不同问题。

二、第一层：MCP——给Agent装上"手和眼睛"

2.1 MCP是什么

MCP（Model Context Protocol，模型上下文协议）——Anthropic 2024年11月发布，2025年12月捐给Linux Foundation旗下的Agentic AI Foundation。彻底消除了厂商锁定风险，成为行业中立的公共标准。

MCP定义了AI模型怎么和外部工具、数据源标准化交互。

在MCP之前，每个AI应用要接一个数据库，得写定制wrapper。换一个AI框架？重写。换一台IDE？再重写。N个AI应用 × M个工具 = N×M个集成。现在MCP把这变成了N+M。

2.2 技术架构

MCP基于JSON-RPC 2.0，经典客户端-服务器模型：

三种核心能力：

能力	说明	例子
Tools	可执行的动作	发邮件、查数据库、调API
Resources	可读取的上下文数据	文件内容、数据库Schema
Prompts	预定义的任务模板	可重复使用的提示词

2.3 为什么前端开发者要关心

因为你每天都在做工具集成。

MCP Server的本质就是一个"能力提供者"——你写过REST API，你就能写MCP Server。你做过前端组件封装，你就能理解MCP的Tools/Resources抽象。

MCP就是AI世界的USB-C。以前每个设备一根线（HDMI/USB-A/Lightning），现在一根线通吃。MCP让任何AI应用只需实现一次客户端，就能接所有工具。

2.4 截止2026年7月形成的生态

客户端

Claude Desktop、Cursor、Windsurf、VS Code、Zed、JetBrains全系列

服务端

已有数千个MCP Server覆盖数据库、文件系统、CI/CD、设计工具等

标准制定方

Google、OpenAI均采纳，Linux Foundation托管

MCP是目前生态最成熟、采用最广泛的Agent协议。如果你只想学一个，建议先学MCP。

三、第二层：A2A——让Agent自己"交朋友"

3.1 A2A是什么

A2A（Agent-to-Agent Protocol）——Google 2025年6月发起，同月捐给Linux Foundation。创始成员：AWS、Cisco、Microsoft、Salesforce、SAP、ServiceNow。

A2A定义了Agent之间怎么发现彼此、分派任务、交换结果。

MCP解决的是"Agent怎么用工具"。但如果一个任务需要多个Agent协作呢？比如用户说"帮我退款"，如下：

客服Agent理解需求

客服Agent找到风控Agent评估风险

风控Agent返回结果

客服Agent把结果交给账单Agent执行退款

账单Agent通知用户

这中间的"发现、分派、协作"——就是A2A解决的问题。

3.2 Agent Card：智能体的"数字名片"

A2A最核心的创新就是Agent Card。

每个Agent通过一个公开的JSON文件声明自己是谁、能干什么、怎么认证：

// 位于 /.well-known/agent-card.json{ "name": "Billing Agent", "description": "处理退款和账单查询", "url": "https://agents.example.com/a2a", "provider": { "organization": "Example Corp" }, "capabilities": { "streaming": true, "pushNotifications": true }, "skills": [ { "id": "refund", "name": "Issue a refund", "description": "根据交易ID发起退款" } ], "securitySchemes": { "oauth": { "type": "oauth2", "flows": { "clientCredentials": { "tokenUrl": "https://auth.example.com/token", "scopes": { "billing:write": "发起退款" } } } } }}

一个Agent想找人帮忙，流程是：

获取对方Agent Card → 知道它能干什么

发送Task请求 → 分派任务

追踪Task状态 → submitted → working → completed

接收结果（Artifacts）

3.3 Task生命周期

A2A的工作单元是Task，状态流转：

他的关键设计是Agent之间不共享内部状态。一个Agent不需要知道另一个Agent用什么模型、什么工具链——它只关心"你能做什么"和"结果是什么"。

这和HTTP的设计哲学一样，“黑箱协作，接口约定”。

3.4 ACP（Agent Communication Protocol）去哪了？

你可能听说过"三大协议"：MCP、A2A、ACP。ACP已经并入A2A了。

IBM Research 2025年3月推出ACP（Agent Communication Protocol），用于其开源BeeAI平台。和A2A高度重叠。2025年8月，LF AI & Data宣布ACP正式并入A2A——ACP团队停止独立开发，将技术贡献给A2A项目。

所以2026年的现实是，Agent-to-Agent只有一个标准——A2A。

3.5 前端视角的价值

A2A的通信基于HTTP，数据格式是JSON，认证用OAuth 2.0——全是前端开发者熟悉的栈。

写一个A2A客户端，本质上就是：

fetch一个JSON文件（Agent Card）

POST一个JSON请求（创建Task）

监听SSE流（接收实时结果）

这不就是一个典型的REST API + SSE + OAuth的集成任务吗？

四、第三层：ACP (Client)——把Agent"装进"编辑器

4.1 此ACP非彼ACP

注意：这里说的ACP是Agent Client Protocol，不是上面并入A2A的那个Agent Communication Protocol。只是这两个完全不同的协议，缩写正好一样。

协议	全称	解决的问题	状态
ACP (Client)	Agent Client Protocol	编辑器 ↔ Agent	✅ 活跃
ACP (Comm)	Agent Communication Protocol	Agent ↔ Agent	❌ 已并入A2A

Agent Client Protocol (ACP)——Zed Industries 2025年8月创建，Apache 2.0开源。

ACP（Agent Client Protocol）定义了编辑器怎么和AI编码Agent对话。

4.2 为什么需要这个协议

在ACP之前：

Cursor → 只能用自己的AI引擎

Windsurf → 绑定Cascade

Claude Code → 命令行工具，没有IDE集成

每个IDE × 每个Agent = 定制化集成（N×M问题）

ACP之后：

编辑器实现一次ACP客户端 → 支持所有ACP Agent

Agent实现一次ACP服务端 → 接入所有ACP编辑器

N×M 变成 N+M

和LSP（Language Server Protocol）的逻辑一模一样。

4.3 关键技术细节

ACP基于JSON-RPC 2.0，通过stdio（标准输入/输出）通信：

┌──────────────┐ JSON-RPC / stdio ┌──────────────┐│ 编辑器 │ ◄──────────────────────► │ AI Agent ││ (ACP Client)│ 子进程通信 │ (ACP Server)│└──────────────┘ └──────────────┘

三个核心请求：

1. initialize → 协商协议版本 + 能力2. session/new → 创建会话3. session/prompt → 发送用户输入，接收Agent响应

Agent在执行过程中通过session/update通知实时广播进度，遇到危险操作可以通过session/request_permission请求用户确认。

4.4 2026年大事件

2026年6月2日——Cognition把Windsurf改名为Devin Desktop，全面押注ACP。

这不只是改个名字。Devin Desktop的主界面从"代码编辑器"变成了Agent Command Center——一个看板，列出所有Agent的任务状态。

从"编辑器里装了个Agent"→"Agent调度中心里装了个编辑器"

到2026年6月，ACP生态已经包括：

编辑器端

——Zed（参考实现）、JetBrains、Neovim、Emacs、VS Code社区集成

Agent端

——Gemini CLI（原生支持）、Claude Code和Codex（通过适配器）

25+个Agent

——兼容ACP

2026年1月

——ACP Registry上线，Agent可以一键发布到所有兼容编辑器

五、三层协议的关系：一个完整的例子

假设你在Devin Desktop里说："帮我修一下这个数据库迁移的bug"。完整流程如下：

第1步 [ACP]编辑器 → Agent：用户请求修复迁移bug ↓ Devin Desktop通过ACP把请求发给Orchestrator Agent第2步 [A2A]Orchestrator Agent → DB Analyst Agent：帮我分析Schema ↓ Orchestrator通过A2A发现DB Analyst Agent（读取Agent Card） ↓ 发送Task请求，DB Agent开始工作第3步 [MCP]DB Analyst Agent → Postgres MCP Server：查询数据库Schema ↓ DB Agent通过MCP调用本地Postgres工具 ↓ 发现问题：某个字段类型不匹配第4步 [A2A + MCP]DB Analyst Agent → Orchestrator Agent：根因是字段类型不匹配Orchestrator Agent → Developer Agent：修复迁移文件 ↓ Developer Agent通过MCP调用Shell工具执行dry run ↓ 验证通过第5步 [ACP]Developer Agent → Orchestrator → 编辑器：修复完成 ↓ 通过ACP将结果展示给用户

三层协议各司其职，没有一层是多余的：

MCP：Agent怎么调工具

A2A：Agent怎么找其他Agent协作

ACP：编辑器怎么和Agent对话

六、通信拓扑：不只是"协议"那么简单

在Agent系统设计中，除了协议本身，还有一个经常被忽略的维度：拓扑。

轴	回答的问题	可选方案
传输层	消息怎么物理传输？	HTTP, SSE, gRPC, WebSocket, 进程内队列
协议层	消息的格式和约定？	A2A, MCP, ACP, 自定义JSON
拓扑层	谁能和谁对话？	中心调度 / 点对点 / 消息总线

三种通信拓扑

1. 中心调度（Hub-and-Spoke）

Orchestrator统一调度所有Worker Agent

优点：可控、可追踪

缺点：Orchestrator是瓶颈

2. 点对点（Peer-to-Peer）

Agent之间直接通信

优点：低延迟、无瓶颈

缺点：复杂度高、难追踪

3. 消息总线（Publish/Subscribe）

Agent发布事件到总线，订阅者自动接收

优点：松耦合、可扩展

缺点：需要消息中间件

A2A是协议，消息总线是拓扑，HTTP是传输。它们不是替代关系，是不同层级的选择。

七、看看前端开发者的机会在哪，有哪些？

7.1 短期机会定位（当前就能做）

1. MCP Server开发

如果你写过API，你就能写MCP Server。MCP的Tools/Resources/Prompts抽象，和REST API的CRUD思维高度相似。

已有大量开源MCP Server可以参考，前端开发者特别擅长做UI工具链的MCP适配——Figma、Storybook、Chromatic、Vercel等。

2. A2A客户端集成

前端产品里嵌入Agent能力，通过A2A和后端Agent协作。你写的本质上就是一个带OAuth的REST客户端+SSE监听器。

3. Agent的可视化

Agent的Task状态、Agent Card、通信拓扑——都需要可视化。这是纯前端的活。

7.2 中期机会定位（大概6-12个月）

4. ACP Client开发

IDE插件开发一直是前端/桌面端的领域。Electron、Tauri、Web Extension——ACP客户端的实现天然适合前端开发者。

5. Agent工作流编辑器

可视化编排Agent协作流程——拖拽Agent节点、连线定义通信拓扑、配置Task路由。这就是一个高级版的"流程图编辑器"，前端最擅长。

7.3 长期机会定位

Agent时代的"前端"不会被消灭，会被重新定义。

以前前端 = 浏览器里的UI。

以后前端 = 人类和Agent系统之间的所有交互界面。

Agent需要界面来展示状态、需要人工审批的确认框、需要可视化通信拓扑、需要编辑Agent Card的表单、需要监控Agent性能的仪表盘。

以上这些都是前端开发的活儿。

八、协议对比速查表

维度	MCP	A2A	ACP (Client)
全称	Model Context Protocol	Agent-to-Agent Protocol	Agent Client Protocol
发起方	Anthropic	Google	Zed Industries
时间	2024.11	2025.06	2025.08
治理	Linux Foundation	Linux Foundation	Apache 2.0
解决的问题	Agent ↔ 工具	Agent ↔ Agent	编辑器 ↔ Agent
通信协议	JSON-RPC 2.0	HTTP + JSON	JSON-RPC 2.0
传输方式	stdio / SSE	HTTP / SSE	stdio
核心概念	Tools, Resources, Prompts	Agent Card, Task, Artifact	Session, Prompt, Update
类比	USB-C	HTTP	LSP
生态成熟度	★★★★★	★★★☆☆	★★★★☆

这是AI Agent协议栈系列的第一篇。后续有机会将深入每一层请大家持续关注：

动手搭一个MCP Server，从理论到可运行代码

Agent Card设计、Task生命周期、多Agent协作实战

从LSP到ACP，编辑器Agent集成的完整方案

用前端技术搭一个完整的三层Agent系统