什么是 ACP（Agent Client Protocol）
如果你正在使用 AI 编码助手，可能会发现一个问题：换个编辑器，你熟悉的 AI 助手就用不了了；想试试新的 AI 代理，却发现它不支持你的 IDE。这种"绑定"让开发者很被动。ACP（Agent Client Protocol）就是为了解决这个问题而生的。
AI 编码工具的集成困境
想象一下这个场景：市面上有 10 个主流代码编辑器，20 个 AI 编码代理。如果每个代理都要和每个编辑器单独对接，那就需要开发 200 个集成方案。这不仅工作量巨大，还会带来三个核心问题：
集成开销高：每增加一个新的代理-编辑器组合，都需要从头开发定制化的集成代码。团队的精力被消耗在重复的适配工作上，而不是产品创新。
兼容性受限：AI 代理只能在少数几个编辑器中使用，开发者想尝试新工具时，发现自己常用的编辑器根本不在支持列表里。
工具链锁定：选择了某个 AI 代理，就意味着你只能用它支持的那几个编辑器；反过来，选择了某个编辑器，也只能用它集成的那几个代理。开发者失去了自由选择的权利。
这就像早期每个浏览器都有自己的 JavaScript 实现方式，开发者需要为不同浏览器写不同的代码。直到 Web 标准出现，这个问题才得到解决。
ACP 是什么
Agent Client Protocol（ACP）是一个标准化的通信协议，专门用于代码编辑器（或 IDE）与 AI 编码代理之间的通信。
你可以把它理解为编辑器和 AI 代理之间的"共同语言"。就像 Language Server Protocol（LSP）让各种编程语言的智能提示功能可以在任何编辑器中使用一样，ACP 让任何 AI 代理都能在任何编辑器中工作。
实现 ACP 的代理可以在任何兼容的编辑器中运行，支持 ACP 的编辑器可以接入整个 ACP 生态的所有代理。这种解耦让双方都能独立创新，开发者也获得了选择最佳工具的自由。
ACP 的工作原理
ACP 基于 JSON-RPC 2.0 规范构建，这是一个成熟的远程过程调用协议。它定义了两种消息类型：
方法（Methods）：请求-响应模式，发送方期待得到结果或错误信息。比如编辑器向代理发送 initialize 请求建立连接，代理会返回它支持的功能列表。
通知（Notifications）：单向消息，发送方不期待响应。比如代理在处理任务时，会持续发送 session/update 通知告知编辑器当前进度，编辑器接收后更新界面即可，无需回复。
典型的交互流程
当你在编辑器中使用 AI 代理时，背后发生的交互大致是这样的：
1. 初始化阶段
- 编辑器向代理发送
initialize方法，协商协议版本并交换能力信息 - 如果代理需要认证，编辑器会调用
authenticate方法完成身份验证
2. 会话设置
- 编辑器调用
session/new创建新的对话会话 - 或者调用
session/load恢复之前的会话（如果代理支持）
3. 提示轮次（这是核心工作流程）
- 编辑器发送
session/prompt将你的消息传递给代理 - 代理开始处理，通过
session/update通知持续报告进度 - 代理可能会请求文件操作权限或其他资源访问
- 如果你想中断，编辑器可以发送
session/cancel通知 - 处理完成后，代理返回
session/prompt的响应结果
这个流程看起来很技术化，但实际体验是流畅的。你在编辑器里输入需求，AI 代理实时显示它在做什么，需要权限时会弹窗询问，完成后直接呈现结果。
ACP 的核心组件
ACP 定义了两个核心角色：
Agent（代理）
代理是使用生成式 AI 自主修改代码的程序，通常作为编辑器的子进程运行。它需要实现以下能力：
必需方法：
initialize：协商版本和交换能力authenticate：身份认证（如果需要）session/new：创建新会话session/prompt：接收用户提示并处理
可选方法：
session/load：加载已有会话session/set_mode：切换代理工作模式
Client（客户端）
客户端通常是代码编辑器或 IDE，负责提供用户界面、管理环境、控制资源访问。它需要实现：
必需方法：
session/request_permission：请求用户授权工具调用
可选方法：
fs/read_text_file和fs/write_text_file：文件读写terminal/create、terminal/output等：终端操作
客户端还会接收代理发送的 session/update 通知，用于更新界面显示代理的工作进度、消息内容、工具调用等信息。
ACP 的部署方式
ACP 设计时就考虑了不同的使用场景，支持本地和远程两种部署方式：
本地代理
本地代理作为编辑器的子进程运行，通过 stdio（标准输入输出）进行 JSON-RPC 通信。这种方式的优势是：
- 响应速度快，没有网络延迟
- 数据不离开本地，隐私性好
- 不依赖网络连接，离线也能工作
这是目前最常见的部署方式，适合个人开发者和对数据安全有严格要求的团队。
远程代理
远程代理可以部署在云端或独立的基础设施上，通过 HTTP 或 WebSocket 与编辑器通信。这种方式适合：
- 需要强大算力的场景（云端可以使用更大的模型）
- 团队协作（多人共享同一个代理实例）
- 企业级部署（统一管理和监控）
需要注意的是，远程代理的完整支持目前还在开发中。ACP 团队正在与多个代理平台合作，确保协议能满足云端部署的各种需求。
ACP 的技术细节
数据格式要求
ACP 对数据格式有明确的规范：
- 文件路径：协议中所有文件路径必须是绝对路径，不能使用相对路径
- 行号：行号从 1 开始计数（不是从 0 开始）
- 文本格式：用户可读的文本默认使用 Markdown 格式
这些规范看似简单，但能避免很多潜在的兼容性问题。
错误处理
ACP 遵循 JSON-RPC 2.0 的标准错误处理机制：
- 成功的响应包含
result字段 - 错误响应包含
error对象，其中有code和message - 通知永远不会收到响应（无论成功还是失败）
这种统一的错误处理方式让开发者能够用一致的方式处理各种异常情况。
扩展性设计
ACP 提供了灵活的扩展机制，让开发者可以在不破坏兼容性的前提下添加自定义功能：
- 自定义字段：使用
_meta字段添加额外数据 - 自定义方法：方法名以下划线（
_）开头即可 - 能力声明：在初始化时声明自定义能力
比如，某个代理可能支持代码审查功能，它可以定义一个 _code_review 方法，并在初始化时声明 codeReview 能力。支持这个功能的编辑器可以调用它，不支持的编辑器则忽略即可。
ACP 与 MCP 的关系
如果你了解 Model Context Protocol（MCP），会发现 ACP 在某些地方复用了 MCP 的 JSON 表示方式。但 ACP 也包含了专门为代码编辑场景设计的类型，比如用于显示代码差异（diff）的格式。
可以说，ACP 是在 MCP 的基础上，针对编辑器和代理的交互场景做了专门的优化和扩展。
ACP 带来的价值
ACP 的出现，对整个 AI 编码工具生态都有积极影响：
对开发者：你可以自由选择最喜欢的编辑器和最好用的 AI 代理，不再被工具链绑定。想换编辑器？你的 AI 助手还能继续用。想试试新的代理？在现有编辑器里就能接入。
对编辑器厂商：不需要为每个 AI 代理单独开发集成方案，只要实现 ACP 协议，就能支持所有兼容的代理。可以把精力集中在提升编辑器本身的体验上。
对代理开发者：不用担心覆盖面的问题，实现 ACP 就能在所有支持的编辑器中运行。可以专注于提升 AI 能力，而不是适配各种编辑器接口。
对整个生态：编辑器和代理可以独立创新，互不制约。新的编辑器能立即接入现有的代理生态，新的代理也能立即被所有编辑器使用。这种良性循环会加速整个领域的发展。
总结
ACP 做的事情其实很简单：定义一套标准，让编辑器和 AI 代理能够顺畅对话。但这个简单的标准，解决的是一个关键问题——让开发者重新获得选择的自由。
就像 LSP 让语言服务器不再与特定编辑器绑定一样，ACP 正在让 AI 编码助手成为一个开放的生态。你不需要因为想用某个 AI 代理而被迫换编辑器，也不需要因为喜欢某个编辑器而放弃更好的 AI 工具。
这才是工具应该有的样子：服务于你的工作流程，而不是限制你的选择。