目录背景一个正在爆炸的生态系统ACP 是什么核心架构它是如何工作的通信基础JSON-RPC 双向通道两种部署模式一次连接多个会话与 MCP 的协同典型的消息流为什么需要 ACP1. 消除重复集成成本2. 打破工具链锁定3. 专注 UX而非底层适配4. 开放生态独立演进谁在使用 ACP什么时候应该使用 ACP适合使用 ACP 的场景暂时不适合的场景ACP 与 MCP 的关系互补而非竞争总结引用链接就像 USB 统一了外设接口ACP 正在统一 AI 编码助手与代码编辑器之间的通信方式。背景一个正在爆炸的生态系统过去两年AI 编码助手迎来了爆发式增长。GitHub Copilot、Cursor、Claude Agent、Gemini CLI、Cline、OpenHands……每隔几个月就有新玩家入场。对于开发者来说这是好事——选择更多能力更强。但对于编辑器开发者和Agent 开发者来说这带来了一个令人头疼的问题每一个新的 Agent都要为每一个编辑器单独写一套集成代码。每一个新编辑器也要为每一个 Agent 单独适配。这就是业内俗称的M × N 问题——M 个 Agent 乘以 N 个编辑器等于海量的重复工作和维护成本。ACP 是什么Agent Client ProtocolACP是一个开放协议专门用于标准化AI 编码 Agent与**代码编辑器IDE**之间的通信。它的目标很简单让任何实现了 ACP 的 Agent都能直接在任何支持 ACP 的编辑器中运行无需额外的定制集成。这个思路并不新鲜。熟悉 VS Code 生态的开发者应该会想到一个先例——Language Server ProtocolLSP。LSP 在 2016 年由微软提出统一了代码补全、跳转定义、错误提示等语言服务的接入方式让语言工具从此不再需要为每个编辑器单独适配。ACP 希望在 AI Agent 领域做同样的事情。核心架构它是如何工作的通信基础JSON-RPC 双向通道ACP 基于JSON-RPC 2.0规范构建支持两种消息类型•方法调用Methods请求-响应对期待返回结果或错误•通知Notifications单向消息不需要响应这种双向通道让 Agent 可以实时将执行进度推送给编辑器 UI同时也可以向编辑器请求权限比如请求读写某个文件。两种部署模式ACP 同时支持本地和远程两种场景•本地 Agent作为编辑器的子进程运行通过 stdin/stdout 进行 JSON-RPC 通信。这是最常见的形态。•远程 Agent托管在云端或独立服务器上通过 HTTP 或 WebSocket 通信该模式仍在完善中。一次连接多个会话一个 ACP 连接可以支持多个并发会话这意味着你可以同时进行多条思路的开发——就像在同一个终端里打开多个 tmux 窗口。与 MCP 的协同ACP 并非要取代Model Context ProtocolMCP而是与它协同工作。编辑器通常已经配置了若干 MCP 服务器如数据库查询工具、文档检索工具等。当用户发起提示时编辑器会将这些 MCP 配置一并传给 Agent让 Agent 直接连接和使用这些工具。这种设计让 ACP 的能力可以随着 MCP 生态的扩展而自然延伸。典型的消息流1. 初始化阶段 Client → Agent: initialize协商版本与能力 Client → Agent: authenticate如需认证 2. 会话建立 Client → Agent: session/new创建新会话 或 session/load恢复已有会话 3. 提示轮次 Client → Agent: session/prompt发送用户消息 Agent → Client: session/update流式进度推送 Agent → Client: session/request_permission请求工具调用权限 Agent → Client: 返回最终结果带 stop reason为什么需要 ACP1. 消除重复集成成本没有 ACP 之前每个 Agent 都要为 Zed、VS Code、JetBrains 等编辑器分别开发插件每个编辑器也要为 Copilot、Cursor、Claude Agent 等分别写适配层。这是一场无止境的轮子大战。ACP 将这个问题从 M×N 降低为 MN——Agent 只需实现一次协议编辑器只需支持一次协议双方便可自由组合。2. 打破工具链锁定选择某个 AI Agent不应该意味着你必须使用某个特定的编辑器。ACP 让开发者可以自由组合最适合自己的工具而不是被供应商绑定。3. 专注 UX而非底层适配ACP 不仅仅是通信协议它还定义了针对编码场景的 UX 原语比如展示代码 diff、执行计划Agent Plan、会话模式切换、斜杠命令等。这些都是纯 MCP 无法直接表达的交互元素。4. 开放生态独立演进协议的开放性让 Agent 开发者和编辑器开发者可以各自创新互不阻塞。Agent 可以专注于提升推理能力编辑器可以专注于优化用户体验两者通过协议解耦。谁在使用 ACP目前已有相当多的主流工具宣布支持 ACP涵盖 Agent 端和编辑器端Agent 端部分• Claude AgentAnthropic• GitHub Copilot已进入公开预览• Cursor• Gemini CLIGoogle• Cline• OpenHands• JunieJetBrains• Codex CLIOpenAI• Qwen Code阿里云编辑器/客户端端• ZedACP 的主要发起者之一• JetBrains 系列 IDE多语言 SDK 也已就绪支持TypeScript、Python、Rust、Kotlin、Java。什么时候应该使用 ACP适合使用 ACP 的场景场景说明你在开发一个 AI 编码 Agent通过实现 ACP你的 Agent 可以立即接入所有支持 ACP 的编辑器大幅降低分发成本你在开发一个代码编辑器或 IDE通过支持 ACP你的编辑器可以立即兼容整个 ACP Agent 生态无需逐一对接你希望在编辑器中使用多个不同的 AgentACP 让你可以按任务切换最合适的 Agent而无需换编辑器你需要构建企业内部的 AI 编码工具链ACP 提供了标准化接口便于内部系统集成和统一管理暂时不适合的场景• 你只需要简单的代码补全功能普通 LSP 或 Copilot 插件已经足够• 你的场景完全不涉及代码编辑器比如纯后端 Agent 流水线MCP 更合适• 你需要远程部署的 Agent远程传输支持仍在开发中ACP 与 MCP 的关系互补而非竞争很多人会问ACP 和 MCP 有什么区别简单来说•MCP解决的是Agent 如何调用外部工具和资源的问题工具层•ACP解决的是Agent 如何与代码编辑器交互的问题交互层两者在设计上高度兼容——ACP 复用了 MCP 的 JSON 类型并通过 MCP 服务器配置转发机制实现协同工作。可以把 ACP 理解为专门面向编码场景的、建立在 MCP 之上的上层协议。总结Agent Client Protocol 是 AI 编码工具生态走向成熟的一个重要信号。它不是一个革命性的新技术而是一个务实的基础设施标准——就像 HTTP 之于 WebLSP 之于语言工具链。对于开发者来说关注 ACP 的意义在于1.选工具更自由不被单一供应商锁定2.集成更省力标准协议大幅降低接入成本3.生态更健康开放标准推动整个 AI 编码生态的良性竞争随着 Zed、JetBrains、Cursor、Copilot 等主流工具纷纷入场ACP 正在快速成为 AI 编码领域的事实标准。如果你正在构建下一代开发工具现在是了解和拥抱 ACP 的好时机。参考资料agentclientprotocol.com[1]引用链接[1]agentclientprotocol.com:https://agentclientprotocol.com引入地址