Agent Client Protocol（ACP）：AI 编码时代的"通用语言"
就像 USB 统一了外设接口，ACP 正在统一 AI 编码助手与代码编辑器之间的通信方式。
背景：一个正在爆炸的生态系统
过去两年，AI 编码助手迎来了爆发式增长。GitHub Copilot、Cursor、Claude Agent、Gemini CLI、Cline、OpenHands……每隔几个月就有新玩家入场。对于开发者来说，这是好事——选择更多，能力更强。
但对于编辑器开发者和Agent 开发者来说，这带来了一个令人头疼的问题：
每一个新的 Agent，都要为每一个编辑器单独写一套集成代码。每一个新编辑器，也要为每一个 Agent 单独适配。
这就是业内俗称的 M × N 问题——M 个 Agent 乘以 N 个编辑器，等于海量的重复工作和维护成本。
ACP 是什么？
Agent Client Protocol（ACP） 是一个开放协议，专门用于标准化 AI 编码 Agent 与**代码编辑器（IDE）**之间的通信。
它的目标很简单：让任何实现了 ACP 的 Agent，都能直接在任何支持 ACP 的编辑器中运行，无需额外的定制集成。
这个思路并不新鲜。熟悉 VS Code 生态的开发者应该会想到一个先例——Language Server Protocol（LSP）。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 Protocol（MCP），而是与它协同工作。编辑器通常已经配置了若干 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
为什么需要 ACP？
1. 消除重复集成成本
没有 ACP 之前，每个 Agent 都要为 Zed、VS Code、JetBrains 等编辑器分别开发插件；每个编辑器也要为 Copilot、Cursor、Claude Agent 等分别写适配层。这是一场无止境的"轮子大战"。
ACP 将这个问题从 M×N 降低为 M+N——Agent 只需实现一次协议，编辑器只需支持一次协议，双方便可自由组合。
2. 打破工具链锁定
选择某个 AI Agent，不应该意味着你必须使用某个特定的编辑器。ACP 让开发者可以自由组合最适合自己的工具，而不是被供应商绑定。
3. 专注 UX，而非底层适配
ACP 不仅仅是通信协议，它还定义了针对编码场景的 UX 原语，比如展示代码 diff、执行计划（Agent Plan）、会话模式切换、斜杠命令等。这些都是纯 MCP 无法直接表达的交互元素。
4. 开放生态，独立演进
协议的开放性让 Agent 开发者和编辑器开发者可以各自创新，互不阻塞。Agent 可以专注于提升推理能力，编辑器可以专注于优化用户体验，两者通过协议解耦。
谁在使用 ACP？
目前已有相当多的主流工具宣布支持 ACP，涵盖 Agent 端和编辑器端：
Agent 端（部分）：
-
• Claude Agent（Anthropic） -
• GitHub Copilot（已进入公开预览） -
• Cursor -
• Gemini CLI（Google） -
• Cline -
• OpenHands -
• Junie（JetBrains） -
• Codex CLI（OpenAI） -
• Qwen Code（阿里云）
编辑器/客户端端：
-
• Zed（ACP 的主要发起者之一） -
• JetBrains 系列 IDE
多语言 SDK 也已就绪，支持 TypeScript、Python、Rust、Kotlin、Java。
什么时候应该使用 ACP？
适合使用 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 之于 Web，LSP 之于语言工具链。
对于开发者来说，关注 ACP 的意义在于：
-
1. 选工具更自由：不被单一供应商锁定 -
2. 集成更省力：标准协议大幅降低接入成本 -
3. 生态更健康：开放标准推动整个 AI 编码生态的良性竞争
随着 Zed、JetBrains、Cursor、Copilot 等主流工具纷纷入场，ACP 正在快速成为 AI 编码领域的事实标准。如果你正在构建下一代开发工具，现在是了解和拥抱 ACP 的好时机。
参考资料：agentclientprotocol.com[1]
引用链接
[1] agentclientprotocol.com: https://agentclientprotocol.com