Agent Client Protocol：从设计目标到 2026 年 3 月的最新进展

• 1. ACP 到底在解决什么问题？
• 2. ACP 的设计思路：为什么它看起来像 MCP + JSON-RPC + IDE UX？
  • 2.1 三条核心设计原则
  • 2.2 它的通信模型为什么选 JSON-RPC 2.0
  • 2.3 它是怎么把“智能体能力”落到 IDE 交互里的
  • 2.4 ACP 为什么要深度复用 MCP
• 3. ACP 是怎么发展起来的？
  • 3.1 RFD 机制：先讨论，再落地，再稳定
  • 3.2 治理结构：从 Zed 主导到更明显的多方协作
  • 3.3 生态扩张：从文档规范到真实可接入的 agent / client 列表
• 4. 截至 2026 年 3 月 7 日，ACP 的最新进展有哪些？
  • 4.1 稳定发布已经推进到 v0.11.0
  • 4.2 2026 年的 RFD 重点，已经明显转向“真实产品化问题”
  • 4.3 ACP Registry 已经不只是概念，而是高频更新中的分发基础设施
  • 4.4 生态采用已经出现了平台级信号
• 5. 为什么说 ACP 的路线比很多“AI 协议”更务实？
  • 5.1 聚焦"编辑器 ↔ 智能体"，而非包打天下
  • 5.2 充分借力已有标准，而非重复造轮子
  • 5.3 用户体验是一等公民，而非附加项
  • 5.4 主动补齐"采用链路"，不把脏活留给接入方
• 6. ACP 接下来最值得关注的挑战是什么？
  • 6.1 远程 agent 支持仍在持续完善
  • 6.2 认证和注册表仍是生态扩张的关键瓶颈
  • 6.3 会话生命周期还在补全中
• 7. ACP 现在处在哪个阶段？
• 8. ACP 与 MCP 的协同关系补充
• 9. 参考链接

Agent Client Protocol，简称 ACP，是一个面向代码编辑器 / IDE 与编码智能体之间通信的开放协议。

理解 ACP，最直观的类比来自 LSP（Language Server Protocol）。在 LSP 出现之前，每个编辑器要想支持某种语言，就必须自己实现补全、跳转、重构这些能力；LSP 把这件事抽象为一套标准协议，让"编辑器 × 语言"变成了"编辑器适配一次协议，语言服务器也只做自己那层"。ACP 想对 AI 编码做同样的事：让"任何编辑器连接任何智能体"不再依赖私有适配层，而是有统一协议可循。

本文基于 ACP 官网、GitHub 仓库、RFD 文档、更新页与注册表资料进行整理，重点回答 3 个问题：它为什么这样设计、它是如何发展到今天的、以及截至 2026 年 3 月 7 日它最新走到了哪一步。

参考资料：https://agentclientprotocol.com/、https://agentclientprotocol.com/get-started/introduction、https://agentclientprotocol.com/get-started/architecture、https://agentclientprotocol.com/protocol/overview、https://agentclientprotocol.com/updates、https://agentclientprotocol.com/rfds/about、https://agentclientprotocol.com/registry、https://github.com/agentclientprotocol/agent-client-protocol、https://github.com/agentclientprotocol/registry

1. ACP 到底在解决什么问题？

ACP 的出发点非常明确：今天的 AI 编码体验里，编辑器和智能体往往是强绑定的。一个编辑器想支持多个智能体，需要分别做适配；一个智能体想进入多个编辑器，也要分别实现不同的宿主接口。这种模式会带来 3 个直接问题。

第一，集成成本高。每新增一个“编辑器 × 智能体”组合，就要多做一层专有接入，工程和维护成本都会线性增长。

第二，生态碎片化。用户选择某个智能体时，往往也被迫接受它当前能运行在哪些工具里；反过来，选择某个编辑器时，也会被限制在少量原生支持的智能体上。

第三，创新速度受限。协议不统一时，编辑器团队和智能体团队都要把大量精力花在重复适配，而不是花在用户真正关心的交互体验、执行能力和安全边界上。

用图来看就更直观：没有统一协议时，$M$ 个编辑器与 $N$ 个智能体之间需要 $M \times N$ 条适配路径；有了 ACP 之后，双方只需各自实现一次协议接入。

因此，ACP 的核心定位可以概括为一句话：把编辑器和编码智能体"解耦"，让双方围绕统一协议独立演进，同时保留互操作性。这也是它被称为"AI 编码领域的 LSP"的原因。

2. ACP 的设计思路：为什么它看起来像 MCP + JSON-RPC + IDE UX？

从官方文档看，ACP 的设计并不是从零开始重新发明一套消息系统，而是刻意站在已有生态上做组合式设计。

2.1 三条核心设计原则

官方架构文档给出了 3 条设计哲学：

1. MCP-friendly：协议基于 JSON-RPC，并尽可能复用 MCP 的数据类型，避免集成方再维护一套平行的数据表示。
2. UX-first：协议不是只追求“能调用”，而是优先解决用户在编辑器里与智能体交互时的体验问题，例如流式更新、计划展示、文件变更、工具权限请求等。
3. Trusted：ACP 的默认假设是，用户正在可信编辑器中与可信智能体协作，但重要操作仍应通过权限机制和受控能力暴露来完成。

这 3 条原则决定了它既不像一个纯后端 RPC 协议，也不像一个只描述模型输入输出的接口标准，而更像一套围绕“编码工作流”设计的宿主协议。

2.2 它的通信模型为什么选 JSON-RPC 2.0

ACP 采用 JSON-RPC 2.0，原因并不复杂：这种模型天然适合"请求 - 响应 + 通知"混合场景，而智能体交互恰好同时需要这两类能力：

• 对于 initialize、session/new、session/prompt 这样的动作，协议需要明确返回结果。
• 对于 session/update 这类中间过程，更适合用通知流式推送，让界面实时刷新。
• 当智能体需要向编辑器反向申请权限、访问终端或操作文件时，双向请求模型也更自然。

换句话说，ACP 不是单向聊天协议，而是一个双向、可流式、可中断、可扩展的会话协议。

2.3 它是怎么把“智能体能力”落到 IDE 交互里的

如果只看协议概览，ACP 的主流程其实很清晰：

1. 客户端先通过 initialize 完成版本和能力协商。
2. 如果智能体需要认证，再进入 authenticate。
3. 然后由客户端创建或恢复会话，例如 session/new、session/load。
4. 用户发起一次提示后，通过 session/prompt 进入完整的 prompt turn。
5. 智能体在执行过程中通过 session/update 持续汇报文本输出、计划、工具调用、文件修改和状态变化。
6. 如果需要，客户端还能用 session/cancel 中断当前轮次。

这套设计非常贴近 IDE 场景，因为“和智能体协作写代码”本质上不是一问一答，而是一连串带状态的交互过程。

2.4 ACP 为什么要深度复用 MCP

这一点是 ACP 最值得关注的设计选择之一。

官方文档明确写到，ACP 会尽可能复用 MCP 的类型表示。例如在内容模型上，ACP 直接沿用了 MCP 的 ContentBlock 结构，因此文本、图片、音频、嵌入资源等内容可以在 MCP 和 ACP 之间较低成本流转。

这意味着 ACP 并不是要替代 MCP，二者定位完全不同：

维度	MCP	ACP
解决的问题	智能体如何访问外部工具与上下文	编辑器如何与智能体协作完成任务
通信方向	智能体 → 工具 / 数据源	编辑器 ↔ 智能体（双向）
关注层	能力接入层	宿主交互层
典型场景	调用搜索 API、读取代码库索引	流式展示计划、请求文件修改权限

二者叠加后，形成的是"编辑器负责宿主体验，智能体负责推理与行动，MCP 负责外部能力接入"的分层架构。这也是为什么 ACP 官网架构图会特别强调：编辑器可以把用户配置好的 MCP Server 信息传给智能体，甚至通过代理方式把编辑器自身暴露成一个 MCP Server。

3. ACP 是怎么发展起来的？

从公开资料看，ACP 至少在 2025 年初已经进入公开推进阶段，而到 2025 年下半年，其演进方式已经非常成熟：不是靠私下拍板，而是引入了较完整的 RFD 机制与治理结构。

3.1 RFD 机制：先讨论，再落地，再稳定

ACP 使用 Request for Dialog，也就是 RFD，作为协议演进的正式机制。它大体分成 Draft、Preview、Completed 等阶段：

1. 先通过 PR 提案。
2. 被核心成员认领后进入 Draft。
3. 实现成熟并准备接受更广泛评审时进入 Preview。
4. 最终稳定后进入 Completed。

这种机制的价值在于，协议不是一次性拍脑袋定完，而是能让“讨论 - 实现 - 反馈 - 修订”形成持续闭环。对于一个还在快速变化的开放协议来说，这种做法非常关键。

3.2 治理结构：从 Zed 主导到更明显的多方协作

治理层面，官方资料显示 ACP 当前采用的是由 Zed 团队主导的设计团队模式，核心决策仍由 lead maintainer 把关。但它已经不再只是单一厂商自说自话。

一个很重要的时间点是 2026 年 2 月 18 日：官方更新宣布来自 JetBrains 的 Sergey Ignatov 成为 ACP 的 Lead Maintainer。这说明 ACP 已经进入更明确的跨厂商协同阶段，至少 Zed 与 JetBrains 的合作已经被正式写入治理结构。

对开放协议来说，这类治理信号非常重要。因为它决定了生态外部参与者是否愿意相信：这个协议是“共同建设的基础设施”，而不是某个产品的私有外壳。

3.3 生态扩张：从文档规范到真实可接入的 agent / client 列表

ACP 的发展并没有停留在规范文本层。官方站点已经维护了可公开浏览的 Agents、Clients 和 Registry 页面。

截至 2026 年 3 月，官方列出的 ACP 兼容智能体已经覆盖 Gemini CLI、GitHub Copilot、Junie、Cline、Codex CLI、Qwen Code、Kimi CLI、Mistral Vibe、Goose、OpenCode 等多个阵营；客户端侧则包括 Zed、JetBrains、Visual Studio Code 插件、Neovim 相关插件、Obsidian 插件、marimo、浏览器客户端乃至 iOS 应用。

这说明 ACP 已经跨过了“只有协议，没有落地”的早期阶段，开始进入“协议、实现、分发、目录、生态共建”同时推进的状态。

4. 截至 2026 年 3 月 7 日，ACP 的最新进展有哪些？

如果把“最新进展”拆开看，我认为可以分成 4 个层面：协议版本、RFD 队列、注册表建设、生态接入。

4.1 稳定发布已经推进到 v0.11.0

根据官方仓库发布页，agent-client-protocol 仓库最新正式版本是 2026 年 3 月 4 日发布的 v0.11.0。

这个版本里最值得关注的新增项有 3 个：

1. session/stop 的不稳定实现已经进入代码。
2. message id 对应的 RFD 已有实现。
3. 多种认证方式的初始支持已经落地。

从这个版本可以看出，ACP 的工作重点正在从“基本会话建立”转向“更完整的生产级能力”，尤其是会话控制和认证体系。

4.2 2026 年的 RFD 重点，已经明显转向“真实产品化问题”

官方 Updates 页面显示，2026 年以来进入 Draft 或继续推进的议题集中在"真实产品化问题"上，可以按方向归为 4 类：

会话生命周期管理：

• session/delete：显式删除会话
• session/resume：恢复历史会话
• session/fork：基于现有会话派生新分支
• $/cancelRequest：取消进行中的请求
• Session Usage and Context Status：会话上下文用量感知

认证与安全：

• Authentication Methods：多种认证方式的规范化
• Logout Method：标准退出登录流程

可观测性与扩展性：

• Agent Telemetry Export：智能体行为的遥测导出
• Meta Field Propagation：元数据字段的传播机制
• MCP-over-ACP：通过 ACP 通道传输 MCP 请求

SDK 与工具链：

• Rust SDK based on SACP：基于 SACP 的 Rust 实现

这些议题几乎都不是"协议玩具功能"，而是直接影响真实 IDE / agent 产品可用性的必要能力。可以说，ACP 已经从"能不能通信"阶段，进入了"如何长期可维护地通信"阶段。

4.3 ACP Registry 已经不只是概念，而是高频更新中的分发基础设施

ACP Registry 是 2026 年最值得关注的一条主线。

目前官方站点已经提供注册表页面，仓库也已经独立存在。它的目标不是简单列个名单，而是为 ACP 智能体建立统一的分发与发现格式：

• 每个智能体用 agent.json 描述自己。
• 注册表通过 CI 校验格式、图标、下载地址和认证支持。
• 客户端可以直接拉取统一的 registry.json 聚合文件。
• 分发方式同时支持 binary、npx 和 uvx。

更重要的是，注册表并不是“很久才更新一次”的静态目录。公开资料显示：

• registry 仓库最新正式发布已经到 2026-03-03 的版本。
• 该仓库已有 200 多次发布。
• 主协议仓库中还存在专门的 Sync Registry Docs 自动化工作流，并在 2026 年 3 月 6 日、7 日连续更新注册表文档。

这说明 ACP 团队已经把“协议采用”问题前置到了分发基础设施层，而不是把它留给每个编辑器自己解决。

4.4 生态采用已经出现了平台级信号

从公开列表看，ACP 生态有两个特别值得注意的信号。

第一，主流工具链正在加入。JetBrains 和 Zed 都已经是公开站点与治理层中的核心角色，GitHub Copilot 也已被列入兼容 agent 名单，而且站点明确标注其 Copilot CLI 的 ACP 支持已进入 public preview。

第二，采用方式越来越多样。除了“编辑器内置支持”，还出现了浏览器客户端、VS Code 扩展、Neovim 插件、知识库工具插件、移动端客户端等多种形态，这表明 ACP 的宿主已经不再局限于少数桌面 IDE。

5. 为什么说 ACP 的路线比很多“AI 协议”更务实？

很多 AI 领域的开放标准容易停留在概念层：愿景很好，但实现、治理、兼容、分发都比较空泛。ACP 相对务实，主要体现在 4 个方面。

5.1 聚焦"编辑器 ↔ 智能体"，而非包打天下

ACP 的边界很清楚：它主要处理编辑器 / IDE 与编码智能体之间的通信。它不试图同时定义模型协议、工具协议、智能体之间的协作协议和互联网级发现协议。

这让它比很多“大一统 AI 协议”更容易推进，因为问题范围被收敛到了最有价值、也最容易形成共识的一层。

5.2 充分借力已有标准，而非重复造轮子

ACP 没有重复发明内容块模型，而是复用 MCP；没有自己造消息总线，而是使用 JSON-RPC 2.0；没有把富文本渲染复杂化，而是直接采用 Markdown 作为默认用户可读文本格式。

这意味着它的创新点更集中在"编码智能体工作流"本身，而不是重复造基础轮子。

5.3 用户体验是一等公民，而非附加项

从 session/update、权限请求、文件系统能力、终端能力、计划展示、会话模式、斜杠命令等设计可以看出，ACP 真正关注的是 IDE 里的实际体验，而不是抽象层面的"模型调用成功"。

这也是它比纯 API 协议更有现实吸引力的原因：用户最终感知到的是产品体验，而不是协议优雅性。

5.4 主动补齐"采用链路"，不把脏活留给接入方

协议能否被广泛采用，往往不取决于规范写得多漂亮，而取决于接入、发现、安装、认证、更新这些脏活累活有没有人做。

ACP Registry、认证方法 RFD、自动化同步文档、版本化 schema 发布，这些动作本质上都在补齐协议采用链路。对于开放生态来说，这比再多一个空泛愿景更重要。

6. ACP 接下来最值得关注的挑战是什么？

虽然 ACP 进展很快，但它仍然处在快速演进期。官方资料里至少还有 3 个明显挑战。

6.1 远程 agent 支持仍在持续完善

官方介绍页已经明确写出：ACP 适用于本地与远程场景，但“完整的远程 agent 支持仍在进行中”。这意味着 ACP 当前最成熟的形态仍然是本地子进程或强宿主控制模式。

如果未来要承载更多云端 agent、团队共享 agent、组织级平台代理，那么传输层、安全边界、会话持久化和认证流还需要继续细化。

6.2 认证和注册表仍是生态扩张的关键瓶颈

现在官方注册表强调“仅收录支持用户认证的 agent”，这本身说明认证仍是整个生态里最难也最关键的一环。

原因很简单：如果没有可靠认证，编辑器很难放心地帮用户安装和连接第三方 agent；而没有标准化分发，协议就很难形成真正的网络效应。

6.3 会话生命周期还在补全中

session/list、session_info_update、session/resume、session/fork、session/delete、session/stop 这些能力串起来，才是一个真正成熟的多会话协作系统。

从 RFD 队列看，ACP 已经清楚意识到这个问题，只是还在逐步落地。未来一段时间，这一块很可能仍然是协议迭代的高频区域。

7. ACP 现在处在哪个阶段？

如果要给 ACP 当前状态下一个判断：它已经越过了"概念验证期"，正处在"从开放规范走向实际基础设施"的关键阶段。

它已经具备以下特征：

1. 有清晰的问题定义和协议边界。
2. 有持续更新的官方文档与版本发布。
3. 有正式的 RFD 机制与治理结构。
4. 有不断扩大的 agent / client 兼容列表。
5. 有单独的注册表仓库和自动化分发链路。

但它也还没完全进入“稳定工业标准”阶段，因为远程能力、认证体系、会话生命周期、更多稳定 RFD 仍在持续演进中。

这恰恰意味着：现在是最值得持续跟踪 ACP 的时间点。因为很多核心设计已经成形，而真正决定生态格局的那部分细节，正在这几个月里快速落地。

8. ACP 与 MCP 的协同关系补充

根据最新资料，ACP 与 MCP 的关系可以进一步澄清：

MCP（Model Context Protocol） 由 Anthropic 提出，主要解决 AI 模型如何访问外部工具和数据源的问题。它定义了标准化的工具调用接口，让 AI 能够连接搜索引擎、数据库、文件系统等。

ACP（Agent Client Protocol） 则专注于编辑器与编码智能体之间的通信协议。它复用了 MCP 的内容类型定义，但关注的是更高层次的交互体验——会话管理、权限控制、流式更新等。

两者的关系可以用下图表示：

这种分层架构使得：

• 编辑器只需实现一次 ACP 即可连接多个智能体
• 智能体只需实现一次 MCP 即可使用多种工具
• 整个生态形成标准化、可组合的架构

9. 参考链接

1. https://agentclientprotocol.com/ - 官方首页
2. https://agentclientprotocol.com/get-started/introduction - 协议介绍
3. https://agentclientprotocol.com/get-started/architecture - 架构文档
4. https://agentclientprotocol.com/protocol/overview - 协议概览
5. https://agentclientprotocol.com/updates - 更新日志
6. https://agentclientprotocol.com/rfds/about - RFD 流程
7. https://agentclientprotocol.com/registry - ACP Registry
8. https://github.com/agentclientprotocol/agent-client-protocol - 主仓库
9. https://github.com/agentclientprotocol/agent-client-protocol/releases/tag/v0.11.0 - v0.11.0 发布页
10. https://github.com/agentclientprotocol/registry - Registry 仓库
11. https://www.anthropic.com/news/model-context-protocol - MCP 官方介绍