Agent Client Protocol：AI 编程 Agent 与编辑器的标准

AI 编程 Agent 发展很快，IDE 侧的集成方式还没有收敛。

Claude Code、Codex CLI、Gemini CLI、OpenHands、OpenClaw 这些 Agent 各有自己的运行方式；Zed、JetBrains、VS Code、Neovim 这些 IDE 也各有自己的集成模型。结果就是： 每多一个 Agent，IDE 要再做一轮接入；每多一个 IDE，Agent 也要再适配一轮。

ACP 要处理的就是这件事。

它的目标很直接：给编程 Agent 和 IDE 之间的通信定义一层标准接口。

一、ACP 要解决什么问题

ACP 官网对问题的描述很清楚： AI coding agents 和 IDE 本来就高度耦合，但互操作性还没有成为默认条件。

这种现状会带来三个直接后果：

• 集成成本高：每个 Agent 和每个 IDE 都要单独做一轮接入

• 兼容面有限：Agent 往往只能在少数 IDE 里工作

• 开发者被锁定：选了某个 Agent，通常也要接受它能用的那几个界面

这就是一个典型的 N × M 问题。

ACP 想把它收成 N + M：

• Agent 实现一次 ACP，就能被任何 ACP Client 调用

• IDE 实现一次 ACP Client，就能接入整个 ACP Agent 生态

这件事和 LSP 很像。 LSP 把“IDE 怎么接语言服务器”标准化了，ACP 要标准化的是“IDE 怎么接 AI 编程 Agent”。

二、ACP 到底标准化了什么

按 ACP 官方介绍，它标准化的是：

• code editor / IDE 和 coding agent 之间的通信

• 既支持本地场景，也面向远程场景

• 协议底层使用 JSON-RPC 2.0

官方文档还强调了三点设计取向：

• MCP-friendly：尽量复用 MCP 里已经存在的数据表示

• UX-first：围绕 IDE 里真实的 Agent 交互体验来设计

• Trusted：默认前提是用户在一个可信 IDE 里与 Agent 协作，但依然保留权限控制

还有一个很实用的细节： ACP 默认把 Markdown 当作面向用户的富文本格式，不要求 IDE 直接渲染 HTML。

这意味着协议没有把展示层绑死在某一种 UI 技术上。

三、用三个角色理解 ACP

理解 ACP，不需要先背消息表。先把三个角色分清楚就够了：

1. Client

Client 就是 IDE。

它负责：

• 承载用户交互

• 提供当前工作目录和本地环境

• 暴露文件系统、终端等可选能力

• 决定哪些工具调用需要用户确认

2. Agent

Agent 是那个真正调用模型、推进任务、发起工具调用的程序。

它通常由 IDE 拉起，也可以跑在远程环境里。

Agent 负责：

• 处理用户提示

• 调用模型

• 维护会话状态

• 报告计划、文本输出、工具调用进度

3. MCP 服务器

ACP 不取代 MCP。

MCP 仍然负责 Agent 和外部工具/数据源的连接；ACP 负责的是 Agent 和 IDE 的连接。

把这三层放在一起看，关系就很清楚：

• ACP：Client ↔ Agent

• MCP：Agent ↔ Tools / Data

四、ACP 的最小心智模型

官方协议文档里，先看这条最小流程就够了：

1. 初始化连接

2. 创建或恢复会话

3. 发送一轮 prompt

4. 用流式 update 报告 Agent 输出

5. 按需请求权限

6. 执行工具

7. 返回 stop reason

只要把这条线跑通，一个 IDE 就已经能和外部 Agent 建立完整协作。

初始化：先协商版本和能力

任何会话开始之前，Client 都必须先调用 initialize。

这一阶段主要协商三类信息：

• 协议版本

• Client 能力

• Agent 能力

例如 Client 可以声明自己是否支持：

• fs/read_text_file

• fs/write_text_file

• terminal/*

Agent 则可以声明自己是否支持：

• session/load

• 图片 / 音频 / embedded context 这类 prompt 内容

• 通过 HTTP 或 SSE 连接 MCP 服务器

官方文档还给了一个很重要的基线要求：

所有 Agent 至少必须支持 session/new、session/prompt、session/cancel、session/update

这四个方法，基本就是 ACP 的最小可用面。

会话：ACP 把上下文明确建模成 Session

ACP 超出了“发一条消息，收一条消息”的模型。 它把一段独立对话建模成 session。

每个 session 都维护自己的：

• 上下文

• 对话历史

• 状态

这也是 ACP 很适合 IDE 场景的地方。 IDE 天然就有多线程工作流：一个任务改代码，一个任务读日志，一个任务查文档。ACP 允许同一个连接下挂多个并发 session。

创建新会话时，Client 通常会传两类关键参数：

• cwd

• mcpServers

一个最小的 session/new 大概长这样：

{

"jsonrpc": "2.0",

"id": 1,

"method": "session/new",

"params": {

"cwd": "/home/user/project",

"mcpServers": [

{

"name": "filesystem",

"command": "/path/to/mcp-server",

"args": ["--stdio"],

"env": []

}

]

}

}

Agent 返回 sessionId 之后，后面的 prompt turn 就都挂在这条会话上。

提示轮次：一轮对话怎么跑完

ACP 把一次完整交互定义成 prompt turn。

这一轮从 session/prompt 开始，到 Agent 用 stop reason 明确结束为止。

中间通常会经过这些环节：

1. Client 用 session/prompt 发送内容块

2. Agent 把请求送给模型

3. Agent 用 session/update 流式汇报文本、计划、工具调用

4. 如果要动工具，先看是否要走权限确认

5. 工具执行期间继续上报状态

6. 本轮结束时，Agent 返回 stop reason

这也是 ACP 和传统“IDE 插件调用某个 AI 接口”的主要差别。 它从协议层就考虑了流式更新、计划展示、工具状态和权限模型。

五、为什么 session/update 很关键

如果没有 session/update，IDE 里的 Agent 体验就会退化成一个黑箱：

• 用户只知道它“在想”

• 不知道它目前在做什么

• 也不知道工具有没有开始跑、跑到哪一步

ACP 把这块直接放进协议主路径里。

session/update 可以携带多类信息，例如：

• Agent 文本输出

• 计划更新

• 工具调用开始

• 工具调用状态变化

• 工具执行结果

对 IDE 来说，这意味着 UI 可以持续渲染过程，不必一直等最终答案。

六、权限模型本身就是协议的一部分

ACP 还把权限请求做成了正式方法，不把它留在实现细节里。

当 Agent 要跑某个可能有副作用的工具时，可以调用：

session/request_permission

官方文档里的结构包含三部分：

• sessionId

• 当前 toolCall

• 可供用户选择的 options

一个简化后的权限请求大概是这样：

{

"jsonrpc": "2.0",

"id": 5,

"method": "session/request_permission",

"params": {

"sessionId": "sess_abc123def456",

"toolCall": {

"toolCallId": "call_001"

},

"options": [

{

"optionId": "allow-once",

"name": "Allow once",

"kind": "allow_once"

},

{

"optionId": "reject-once",

"name": "Reject",

"kind": "reject_once"

}

]

}

}

这套设计的意义很直接：

• Agent 可以请求权限

• Client 可以按用户设置自动放行或拦截

• 用户可以一次性允许，也可以长期允许或拒绝

这让“Agent 能做什么”从某个产品的 UI 约定，变成了一个可互操作的协议动作。

七、ACP 和 MCP、LSP 的边界

把三者放在一起看，最容易理解：

ACP

处理的是：

• Agent 和 IDE 之间怎么通话

• 会话怎么管理

• prompt turn 怎么推进

• 权限怎么请求

• 进度怎么流式上报

MCP

处理的是：

• Agent 和工具 / 数据源之间怎么连接

• 外部能力怎么暴露给 Agent

LSP

处理的是：

• IDE 和语言服务器之间怎么协作

• 补全、诊断、跳转、符号查询这类传统语言能力

一句话说：

• LSP 管语言能力

• MCP 管工具能力

• ACP 管 Agent 能力

八、ACP 现在发展到什么程度了

从 ACP 官网当前公开的信息看，它已经进入实际落地阶段。

IDE / Client 侧

官方 Clients 页面列出的 IDE 和客户端已经包括：

• Zed

• JetBrains

• Visual Studio Code（ACP Client extension）

• Neovim（通过多个插件）

• Obsidian

• Unity editor

• 还有 CLI / mobile / messaging 侧的一些客户端

Agent 侧

官方 Agents 页面列出的可用 Agent 已经覆盖了相当多知名项目，例如：

• Gemini CLI

• Codex CLI（通过 adapter）

• Claude Agent（通过 adapter）

• Cursor

• Cline

• GitHub Copilot（public preview）

• OpenClaw

• OpenHands

• Junie

这说明 ACP 讨论的重点已经转到“生态怎么继续收敛”。

官方 SDK

ACP GitHub 仓库和官网目前都已经列出了官方库：

• TypeScript

• Python

• Rust

• Kotlin

• Java

这点很重要。 协议只有 schema 不够，得有开发者能直接拿来做连接层和消息模型的 SDK，生态才会起得来。

九、ACP 现在的边界也很明确

ACP 还没有完全定型。

官方文档里至少有三处边界写得比较明确：

1. 远程 Agent 还在继续完善

官网明确写了：

• 本地 Agent 是主路径，走 JSON-RPC over stdio

• 远程 Agent 支持面向 HTTP / WebSocket

• 完整远程支持还在推进中

这意味着 ACP 今天最成熟的落点还是“IDE 拉起本地或近端 Agent 进程”的场景。

2. 某些传输能力带有过渡性质

例如初始化阶段里，Agent 可以声明 MCP 连接能力：

• http

• sse

但官方文档同时注明： SSE 已经被 MCP 规范弃用。

这类信息很重要，因为它关系到实现时该押哪条线。

3. 一些能力位还在未来统一

例如初始化文档里提到：

• session/load 目前还是通过顶层能力来声明

• 未来会统一到 session 能力体系里

这说明 ACP 的方向已经清楚，但实现细节仍在继续收口。

十、为什么这层协议很关键

ACP 值得持续关注，因为它碰到的是 AI 编程生态里最现实的一层摩擦：

• Agent 越来越多

• IDE 入口越来越多

• 工具调用越来越重

• 权限和状态展示越来越复杂

如果没有一层标准协议，每个 Agent 和每个 IDE 都会重复造一遍自己的连接层、权限模型和 UI 事件流。

ACP 要做的，就是把这层重复建设收掉。

对不同角色来说，它的价值也不一样：

对 Agent 开发者

一次实现 ACP，理论上就能进入更多 IDE 和客户端环境。

对 IDE 开发者

只要支持 ACP，就不需要为每个 Agent 单独设计一套 API。

对用户

工具组合的自由度会更高。 你可以更容易地把喜欢的 IDE 和喜欢的 Agent 拼在一起，减少被单个产品绑定的概率。

总结

ACP 讨论的是“Agent 怎么以一种可互操作的方式进入 IDE”。

这层问题过去常常被藏在产品实现里，现在开始被单独抽出来做标准。

从今天公开的文档看，ACP 已经具备了几项很清晰的骨架：

• JSON-RPC 2.0 通信模型

• 会话机制

• prompt turn 生命周期

• session/update 流式更新

• session/request_permission 权限请求

• 和 MCP 的清晰分层

如果你在做 IDE 插件、AI 编程 Agent、IDE 集成，或者只是想理解未来这类工具为什么会越来越能互相替换，ACP 值得持续跟进。

它很可能会成为编程 Agent 时代里，IDE 侧最关键的一层公共接口。

Sources

• ACP Introduction: https://agentclientprotocol.com/get-started/introduction

• ACP Architecture: https://agentclientprotocol.com/get-started/architecture

• ACP Protocol Overview: https://agentclientprotocol.com/protocol/overview

• ACP Initialization: https://agentclientprotocol.com/protocol/initialization

• ACP Session Setup: https://agentclientprotocol.com/protocol/session-setup

• ACP Prompt Turn: https://agentclientprotocol.com/protocol/prompt-turn

• ACP Tool Calls: https://agentclientprotocol.com/protocol/tool-calls

• ACP Clients: https://agentclientprotocol.com/get-started/clients

• ACP Agents: https://agentclientprotocol.com/get-started/agents

• ACP GitHub Repo: https://github.com/agentclientprotocol/agent-client-protocol