ACP协议：AI编程工具的「LSP时刻」，终结Agent锁定时代

编程工具的「巴别塔」问题

2026年的开发者面临一个奇怪的困境：AI编程工具前所未有地强大，但它们各自为政。

你在Cursor里写代码，想调Claude Code来做一次跨文件重构——做不到。你在终端里用Aider，想把结果同步回IDE里让Copilot继续——也不行。每个工具都是一个孤岛。Agent和编辑器之间的接口是私有协议，每个组合都需要定制集成。

这和2015年之前的编程语言工具生态如出一辙。那时每个编辑器都要为每种语言单独实现自动补全、跳转定义、查找引用——直到Language Server Protocol（LSP）出现，用一个标准协议解耦了编辑器和服务端。今天你可以用VS Code写Rust，用Vim写TypeScript，用Emacs写Python，都享受同等级别的语言智能。

ACP（Agent Client Protocol）想做AI编程时代的LSP。

ACP是什么

ACP全称Agent Client Protocol，是一套标准化的Agent-编辑器通信协议。它在2026年6月随着Devin Desktop的发布正式进入公众视野，目前由Cognition主导并开放给社区。

核心思路很简单：

• Agent一侧：任何实现了ACP的Agent（Claude Code、Devin、Aider等），不需要为每个编辑器单独适配
• 编辑器一侧：任何支持了ACP的编辑器（VS Code、JetBrains、Zed等），可以接入整个ACP Agent生态

类比LSP非常准确。LSP出现之前，N个编辑器 × M种语言 = N×M种集成。LSP之后，一个语言服务器可以被所有编辑器使用。ACP要解决的是：N个编辑器 × M个Agent = N×M种集成 → 一个协议全通。

技术架构

ACP基于JSON-RPC 2.0，复用了MCP（Model Context Protocol）的JSON表示。在本地模式下，Agent作为编辑器的子进程运行，通过stdio通信；远程模式支持HTTP/WebSocket，适用于云端Agent场景。

通信模型围绕三个核心概念：

会话（Session）：用户发起一次Agent交互，编辑器创建一个ACP会话。Agent在会话内拥有文件读写、终端执行、搜索等能力。

工具（Tools）：Agent通过标准化工具接口与编辑器交互——读取文件、写入修改、执行命令、显示diff。编辑器负责渲染diff、确认危险操作、管理权限。

消息（Messages）：用户消息和Agent响应都走统一的消息格式。默认文本格式是Markdown，平衡了富文本表达和跨编辑器兼容。

ACP特别设计了对Agent编码体验的原生支持：diff显示、内联建议、文件列表、进度报告——这些Agent特有的交互模式在协议层就有明确定义，不是靠Markdown hack实现。

为什么ACP比MCP更值得关注

MCP（Model Context Protocol）解决的是「模型如何获取上下文」——编辑器通过MCP把代码库、文档、基础设施信息暴露给模型。MCP很成功，Anthropic主导，生态已经相当成熟。

但MCP有一条边界它不跨：它只管编辑器→模型的信息流，不管Agent→编辑器的操作流。你用Claude Code做完了一次重构，想把diff发回编辑器中审查——这不是MCP的范畴。

ACP填补的正是这个空白。它管的是Agent→编辑器的操作通道：Agent做出的修改如何展示、如何确认、如何合并。换句话说：

• MCP = 模型看到了什么
• ACP = Agent能做什么、做了之后如何呈现

两者互补而非竞争。一个完整的AI编程协议栈，应该是MCP + ACP一起用。

生态现状

虽然ACP还很年轻，但采纳速度超出了预期。目前已公开支持或正在集成的包括：

• 编辑器：JetBrains全系、Google Antigravity（Google的AI原生IDE）、GitHub（用于Copilot集成）、Zed
• Agent：Devin Local（ACP原生支持）、Claude Agent（通过Devin Desktop的ACP桥接）、Aider（社区适配中）

Devin Desktop是ACP的首个完整落地产品。它的Agent Command Center可以让你在同一个编辑器中同时管理和运行多个ACP兼容的Agent——你在编辑器里发起任务，Agent在后台执行，结果以diff形式返回编辑器。

这标志着AI编程工具从「比拼谁的Agent更强」开始转向「比拼谁的Agent编排能力更强」。单一Agent的能力上限正在被模型能力拉平，而如何让多个Agent协同工作，正在成为新的差异化战场。

对开发者的实际影响

对普通开发者来说，ACP最直接的好处是：你不用再被锁定在某个工具的生态里。

今天如果你深度使用Cursor的Agent模式，你的工作流就和Cursor绑定了——换到其他编辑器的成本很高。同样，如果你依赖Claude Code的终端工作流，要迁移到IDE里也不容易。

ACP成熟之后，你可以：

• 在VS Code里发起任务，选择不同的Agent来处理——重构用Claude Code、代码审查用Copilot、文档生成用Aider
• 在JetBrains里写代码，但调用Cursor的Composer Agent来做UI层改动
• 把一个Agent在终端里产出的diff，无缝拉回编辑器中审查和合并

编辑器回归编辑器的角色，Agent回归Agent的角色。开发者自由选择每个环节的最佳工具。

潜在风险和挑战

ACP不是没有隐忧。

首先是标准控制权。ACP目前由Cognition主导，虽然名义上开放，但事实标准如果被单一商业公司控制，生态健康会打折扣。LSP的成功很大程度上得益于微软的开放姿态——ACP需要证明自己能做到同样的开放。

其次是协议稳定性和碎片化风险。ACP还处于早期，API变更频繁。如果不同实现之间出现兼容性分歧，碎片化的ACP可能比没有标准更糟糕。

最后是安全边界。ACP给了Agent更广泛的编辑器操作权限。标准化的权限模型必须有足够细的粒度——不能让一个Agent在假装做代码审查时悄悄地删除了文件。

写在最后

ACP正在做一件重要的事：为AI编程工具的互操作建立一个公共层。

回顾LSP的历史很有启发。2016年LSP刚推出时，很多人觉得「不就是个协议吗」。但十年后回头看，LSP可能是过去十年对开发者日常体验影响最深的技术基础设施之一——它让编辑器选择从「被迫选择」变成了「自由选择」。

ACP有机会在AI编程工具领域扮演同样的角色。如果它成功，2028年的开发者可能会忘记曾经有过「Cursor还是Copilot」这种非此即彼的争论——因为他们可以在任何编辑器里调用任何Agent。

这才是工具该有的样子。