ACP协议详解：标准化IDE与编程代理通信的开源新协议

为什么我们需要ACP协议？

当下，每家大型科技公司都在发布自己的CLI编程代理——Claude Code、Gemini CLI、OpenAI Codex等。这些工具虽然强大，但与代码编辑器的集成却充满了"hack"式的临时方案。Anthropic要为Cursor做适配，Google要为VS Code做适配，每一个新的"代理×编辑器"组合都需要大量定制工作。

这正是ACP（Agent-Client Protocol）协议试图解决的问题。它由Zed Industries（开源编辑器Zed的开发团队）联合Google Gemini团队共同创建，目标是标准化代码编辑器与编程代理之间的通信协议，就像MCP标准化了AI代理与工具之间的通信一样。

值得一提的是，Zed编辑器本身是由Atom编辑器和Tree-sitter的原创者打造的新一代编辑器，完全基于Rust语言构建，以极致性能和低延迟著称。Zed从设计之初就将协作编辑和AI集成作为核心特性，而非事后添加的插件——这也使其成为推动ACP协议落地的天然先行者。其Rust技术栈在处理高频UI更新（如实时diff渲染）时具有显著的性能优势。

ACP协议的实际体验

在支持ACP的Zed编辑器中，你可以直接选择不同的编程代理（目前支持Gemini CLI和Claude Code），体验与原生IDE编程助手几乎无异。

例如，选择Gemini CLI后，输入"创建一个实现A*搜索算法的Python文件"，整个交互过程就像在Cursor中使用内置AI一样流畅——你不会看到任何CLI界面，一切都在IDE内完成。

更关键的是，ACP支持实时diff预览。代理生成的代码修改会以diff视图直接展示在编辑器中，你可以逐一审查并决定是否接受。这不是某个特定编辑器的专属功能，而是协议层面的标准能力。

无缝切换编程代理

ACP协议最令人兴奋的特性之一是代理无关性。假设你用Gemini CLI生成了一个文件，接下来想用Claude Code为其添加注释——只需点击切换到Claude Code，在同一个IDE中创建新的对话线程，即可继续工作。Claude Code同样能通过ACP协议读取文件、提出修改、展示diff，整个流程完全一致。

这意味着开发者不再被锁定在某个特定的代理-编辑器组合中。选择编程代理不再意味着必须接受它所支持的有限编辑器界面。

ACP协议的技术架构

协议本质：基于JSON-RPC的标准化通信

ACP本质上是一个JSON-RPC协议，让任何代码编辑器能够与任何编程代理进行标准化通信。它采用传输无关的设计，通常通过标准输入/输出（stdio）与子进程通信。

JSON-RPC是一种轻量级的远程过程调用协议，使用JSON作为数据格式，允许客户端向服务器发送请求并接收响应，同时支持批量请求和通知（无需响应的单向消息）。相比REST API，JSON-RPC更适合需要频繁双向通信的场景——协议开销极小，且天然支持异步调用模式。这一特性对于编辑器与代理之间需要实时同步代码变更、持续传递用户操作的场景尤为关键。ACP选择JSON-RPC而非WebSocket或gRPC，也体现了其对轻量性和易实现性的优先考量。

具体流程如下：

1. 编辑器启动代理：作为子进程运行
2. 交换结构化请求和响应：基于JSON-RPC格式
3. 代理提出操作：包括导航（navigate）、编辑（edit）、运行（run）、调用工具（tool）等
4. 编辑器执行操作：在获得用户许可后，将变更应用到UI中

自定义代理接入ACP

除了开箱即用的Gemini CLI和Claude Code，ACP还支持接入任何自定义代理。你只需创建一个JSON配置文件，指定代理服务器信息、启动命令以及入口文件（如index.js），即可将自己的代理接入支持ACP的编辑器。

ACP与MCP的区别：互补而非竞争

很多人第一反应会问：ACP和MCP有什么区别？答案是——它们解决的是完全不同层面的问题，且天然互补。

要理解这一点，需要先了解MCP的定位。MCP（Model Context Protocol）是Anthropic于2024年底推出的开放标准，旨在解决AI模型与外部工具、数据源之间的集成问题。在MCP出现之前，每个AI应用都需要为每个工具单独编写集成代码，形成"M×N"的集成矩阵。MCP通过定义统一的工具调用接口，让AI代理能够以标准化方式访问文件系统、数据库、API等各类资源——它解决的是"代理能做什么"的问题。而ACP解决的则是"代理如何与编辑器对话"的问题，两者工作在完全不同的抽象层次上。

维度	ACP	MCP
通信对象	编辑器 ↔ 编程代理	代理 ↔ 工具/上下文
控制内容	UI组件（diff、导航、编辑）	工具调用、数据源访问
核心价值	标准化IDE集成体验	标准化工具生态接入

简单来说：MCP让代理能调用各种工具，ACP让代理能控制编辑器界面。一个支持ACP的编辑器完全可以让ACP代理在编辑器权限管控下使用MCP服务器，两者不存在任何冲突。

ACP协议的当前局限与未来展望

需要关注的问题

安全与认证：这是ACP目前最大的短板。MCP在安全认证方面至今仍在完善，而ACP在这方面的规范更是几乎空白。随着协议的推广，这将是必须优先解决的问题。值得注意的是，MCP社区在安全方面走过的弯路——如早期的工具注入攻击和权限滥用问题——为ACP提供了重要的前车之鉴。

生态覆盖：目前ACP仅在Zed编辑器中可用，整个Zed IDE基于Rust编写。VS Code、JetBrains等主流编辑器是否会采纳这一协议，仍是未知数。协议的成功很大程度上取决于生态参与者的广度。

规范成熟度：ACP目前还处于早期规范阶段，API会持续变化，后续将引入版本管理机制。

为什么ACP值得关注

尽管存在诸多不确定性，ACP解决的是一个真实且迫切的痛点。随着编程代理数量的爆发式增长，"N个代理 × M个编辑器"的集成矩阵将变得不可维护。ACP提供了一个优雅的解耦方案：代理开发者只需实现一次ACP协议，编辑器开发者也只需支持一次ACP协议，即可实现任意组合的即插即用。

这与MCP的成功逻辑如出一辙——标准化带来网络效应。MCP从发布到被主流AI工具广泛采纳仅用了数月时间，核心原因正是它将"M×N的集成工作量"压缩为"M+N"。如果ACP能复制这一路径，获得足够多的编辑器和代理厂商支持，它完全有潜力成为编程AI领域的下一个基础协议。

对于开发者而言，现在至少值得花时间了解ACP的设计理念和技术细节。即使最终胜出的不是ACP本身，编辑器与代理之间的标准化通信协议，一定会以某种形式到来。

核心要点

• ACP（Agent-Client Protocol）是由Zed Industries联合Google Gemini团队推出的开源协议，旨在标准化代码编辑器与编程代理之间的通信
• ACP与MCP互补而非竞争：MCP解决代理与工具的通信，ACP解决编辑器与代理的通信，两者可协同工作
• ACP采用JSON-RPC协议和标准IO通信，实现编辑器和代理的双向无关性，支持实时diff预览、导航、编辑等UI级别的深度集成
• 目前ACP仅在Zed编辑器中可用，支持Gemini CLI和Claude Code，安全认证机制尚不完善，规范仍在早期演进阶段
• ACP解决了'N个代理×M个编辑器'的集成复杂度问题，如果获得广泛采纳，有潜力成为编程AI领域的基础协议