Agent Client Protocol（ACP）是一种开放协议，用来规范面向用户的客户端（Client）与 Coding Agent 之间的通信。这个客户端可以是代码编辑器或 IDE。ACP 让双方用同一种方式建立 Session、发送 Prompt、流式展示工作过程、呈现工具活动和请求权限。
ACP 不是 Agent、模型、编辑器或工具目录，而是客户端与 Agent 之间的通信合同。这个区别很重要：某个产品出现在 ACP 目录里，只能说明它存在一条接入路径，不能说明背后运行什么模型、接入是不是原生实现，也不能说明所有功能在每个客户端里都能使用。
用一句话解释 ACP
ACP 统一了客户端操作和展示 Coding Agent 的方式，不再需要为每一组客户端与 Agent 单独设计协议。官方的 ACP 介绍把它定义为代码编辑器、IDE 和其他面向用户应用之间的互操作层。
如果你仍然容易把“Agent”和“模型”当成同一件事，可以先看 Agent harness 和模型的区别。Agent harness 是包在模型外面的执行入口，可以管理工具、文件、状态和审批；模型则可以单独选择。
为什么需要 ACP
没有统一协议时，每个客户端都要为每个 Coding Agent 单独做集成。每增加一个编辑器或 Agent，都可能多出一批需要设计、实现、测试和维护的适配器。ACP 架构说明把它概括为 N×M 集成矩阵，并把 ACP 想要达到的互操作效果与 Language Server Protocol 作了类比。
有了 ACP，客户端可以实现一次共同协议，Agent 也能向多个客户端暴露同一套通信合同。这样能减少重复集成工作，并为 Session、Prompt 内容、流式更新、工具调用和权限提供共同语言。
但统一协议不等于所有实现完全相同。ACP 会协商能力，因为不同 Agent 和客户端可能支持不同的可选功能。共同的传输协议让连接成为可能；具体行为仍然取决于两端的实现和配置。
一次 ACP Session 怎样运行
ACP v1 使用 JSON-RPC 2.0 method 和 notification。在典型的本地场景中，客户端会把 Agent 启动为子进程，双方通过标准输入与标准输出交换按换行分隔的 JSON-RPC 消息。这个流程来自官方 v1 Overview和 Transport 规范。
把细节简化后，一次 Session 大致经过以下步骤：
- 连接并初始化。 客户端启动或连接 Agent，双方交换协议版本和能力；Agent 还可以声明认证方式。
- 新建或恢复 Session。 客户端为项目或工作目录打开工作 Session，并且只使用双方都支持的生命周期操作。
- 发送 Prompt。 用户文字和双方支持的内容块从客户端传给 Agent。
- 流式展示工作过程。 Agent 持续发送 Session update，客户端可以在任务进行时展示消息、计划、工具调用、工具结果和代码修改。
- 处理交互。 Agent 可以请求客户端让用户决定是否授权。可选的客户端能力也可以让 Agent 与客户端提供的文件系统或终端服务协作。
- 完成或取消。 Agent 返回停止原因，或者客户端请求取消正在进行的工作。
协议规定了这些消息及其顺序，但不规定 Agent 内部怎样推理、使用哪家模型、代码在哪里执行，也不负责产品如何在 Session 外保存持久工作区。
ACP 规范了什么，又没有规范什么
ACP 覆盖了构建 Coding Agent 界面所需的一组重要能力，但它有意停在通信边界。
ACP 可以规范：
- 初始化和能力协商；
- Session 新建与双方支持的恢复操作；
- Prompt 和流式 Session update；
- 客户端展示的计划、工具调用状态、内容和 Diff；
- 权限请求与回应；
- 与客户端提供的文件和终端进行可选协作。
只靠 ACP 不能保证：
- 使用某个特定 Coding Agent、模型或 Provider；
- 不同客户端和 Agent 拥有完全相同的功能；
- 自动获得沙箱、授权体系或安全的权限策略；
- 生成代码或工具决策的质量；
- 获得持久化远程工作区或可直接用于生产的远程 Transport；
- 目录里每个产品的所有版本都彼此兼容。
换句话说，ACP 可以传递一项权限请求，但最终给用户展示什么、允许什么，以及操作在哪里执行，仍由客户端和执行环境决定。
ACP 和 MCP 解决的是不同层级
ACP 与 Model Context Protocol（MCP）是可以配合使用的协议，不是互相替代的竞争关系。
ACP 对 MCP 友好，会在合适的地方复用兼容的 MCP 类型，同时增加 Coding Agent 体验需要的结构，例如 Diff。ACP 架构也允许客户端把配置好的 MCP Server 交给 Agent，再由 Agent 直接连接这些 Server。但不应该在同一个 socket 上混合传输 ACP 和 MCP。
这个边界来自官方的 ACP 架构说明和 MCP 架构说明。如果需要产品例子和选择表，可以继续看完整的 ACP 与 MCP 对比。
哪些 Agent 与 ACP 兼容
官方 ACP Agents 页面是当前最合适的发现入口，但它是一份持续变化的目录，不是永久不变的兼容矩阵。2026 年 9 月 1 日的快照中可以看到 Claude Agent、Codex CLI、Cursor、Gemini CLI、GitHub Copilot、OpenCode、OpenHands、Pi 和 Qwen Code 等例子。
这里的“被列出”需要谨慎理解：
- Codex CLI 通过适配器接入。 当前的 Codex ACP 仓库说明，这个 ACP Server 会启动 Codex App Server，并在两种接口之间做转换。旧的 Zed 仓库已经归档；当前 README 给出的安装入口是
npx -y @agentclientprotocol/codex-acp。这不能证明 Codex CLI 原生实现了 ACP。 - Claude Agent 也通过适配器提供 ACP 接口。 当前的 ACP 适配器仓库在 ACP 接口背后使用 Claude Agent SDK。
- Pi 通过
pi-acp被列出。 这同样是一条适配器路径，不能因此把底层所有能力统称为“原生 ACP”。 - GitHub Copilot 的 ACP 支持在本次核验时仍是 public preview，状态来自 GitHub 的官方更新日志。
其他条目可能直接暴露 ACP，也可能提供自己的启动模式、Package 或 Bridge。官方目录没有提供覆盖所有 Client—Agent 组合的统一功能矩阵。真正选用前，应该重新检查当前项目链接、安装说明、支持的协议版本、认证流程、Session 能力，以及你确实需要的功能。
对 Codex 来说，ACP 也不是 SDK、app-server 和 codex exec 三种接口选择的同义词；Codex 集成接口对比单独解释了这些层级。
Agents 页面和 Registry 不是同一份名单
ACP 还维护官方 Registry，但它与面向人阅读的 Agents 页面用途不同。
2026 年 9 月 1 日的快照能直接看出差异：Agents 页面与在线 Registry JSON并不是同一组条目。Registry 仓库说明 Agent 版本会每小时自动更新，因此名称、版本、Package 和可用状态都可能很快变化。
Registry 的验证有价值，但范围有限。检查内容包括启动条目，并确认 ACP 握手返回有效的 authMethods。这不等于对安全、代码质量、功能覆盖，或与所有客户端的兼容性进行完整认证。应该把两个来源都当成起点，再测试计划使用的具体组合和版本。
需要留意的版本与 Transport 边界
截至 2026 年 9 月 1 日，ACP v1 是当前稳定协议。ACP v2 仍是 Draft，设计和迁移细节仍可能变化。
描述 Transport 成熟度时也要准确。ACP 介绍会同时讨论本地和远程 Agent，但 v1 Transport 文档说明，完整远程支持仍在开发，Streamable HTTP 也还是 Draft Proposal。本地子进程通过 stdio 通信，是已经明确的 v1 路径；不能只看到“兼容 ACP”，就推断它已经具备可用于生产的远程部署、认证、重连或隔离能力。
这些信息变化很快。真正开始实现前，应再次检查协议版本、Transport 状态、目录条目、适配器仓库和安装命令。
ACP 对 Agent.Space 用户意味着什么
ACP 可以帮助我们理解 Coding Agent 的集成边界放在哪里，但它不会把客户端、Agent harness、模型、Provider、Workspace、权限和部署环境这些独立选择合并成一件事。
截至 2026 年 9 月 1 日，Agent.Space 尚未公开承诺支持 ACP。本文不是 ACP 集成或路线图公告。即使同一个 Agent 同时出现在 Agent.Space 和 ACP 官方目录里，也不能证明 Agent.Space 通过 ACP 与它连接。
请以当前产品界面和正式发布信息为准。如果你现在要做的是运行可用的执行入口，而不是实现一套协议，可以打开 Agent.Space，用一个边界任务验证产品实际显示的选项，而不是只看它是否出现在某个目录里。