Edit: Agent Client Protocol (ACP) 万字全景解析：AI 编程

编辑文章

标题 *

URL 别名 *

内容 * (支持 Markdown 格式)

# Agent Client Protocol (ACP) 万字全景解析：AI 编程智能体的“LSP 时刻”

2025年9月，代码编辑器 Zed 的团队发布了一个名为 Agent Client Protocol（ACP）的新协议。它的目标很宏大——成为 AI 编程智能体领域的“LSP”。不到半年，Claude Code、Gemini CLI、OpenCode、Codex CLI 等主流 AI Agent 纷纷宣布支持，JetBrains 全家桶、Neovim、Emacs 等编辑器也已全面接入。

如果你曾好奇：为什么 Claude Code 能在 Zed 里运行，也能在 JetBrains 里运行，而且切换 Agent 就像切换字体一样简单？答案就藏在这个协议里。

然而，ACP 的发展并非一帆风顺。从诞生之日起，它就在争议中前行——有开发者质疑“又一个新协议”的必要性，有人担忧 JSON-RPC 的性能开销，有人怀疑缺乏 VS Code 支持的协议能否真正成功。本文将全面、深入地解析 ACP 的一切：它的诞生背景、技术架构、核心能力、生态现状、争议与批评、未来演进，以及与 MCP、A2A 等协议的对比。

## 一、前传：为什么我们需要 ACP？

### 1.1 历史参照系：LSP 如何改变了编程工具生态

十年前，编程语言的智能提示功能面临和今天 AI Agent 一模一样的困境。

当时，Visual Studio Code、Sublime Text、Atom、Vim、Emacs……每个编辑器都需要为每种编程语言单独实现代码补全、语法检查、跳转定义等功能。这意味着：

- 编辑器开发者要为 Python、JavaScript、Rust 等几十种语言分别编写支持代码
- 语言工具开发者要为每个编辑器维护独立的插件

这是一个典型的 **M × N 集成困境**：M 个编辑器 × N 个语言 = M×N 个集成工作。

2016年，微软发布了 **Language Server Protocol（LSP）**，定义了一套标准化的 JSON-RPC 协议，让编辑器与语言服务器能够以统一的方式通信。语言服务器实现一次，就能在所有支持 LSP 的编辑器中运行；编辑器实现一次 LSP 客户端，就能支持所有 LSP 语言服务器。

LSP 彻底改变了编程工具生态。今天，几乎所有主流编辑器都支持 LSP，几乎所有主流编程语言都有对应的 LSP 实现。这就是协议的力量——它不创造功能，但它让功能可以自由流动。

### 1.2 今日困境：AI Agent 的“巴别塔”

时间快进到 2024-2025 年，AI 编码智能体迎来了爆发期。Claude Code、Gemini CLI、GitHub Copilot、Codex、OpenCode、Goose、Qwen Code……各种 Agent 层出不穷，每个都有独特的优势和设计理念。

但问题也随之而来。在 ACP 出现之前，这些 Agent 与编辑器的集成方式是这样的：

- VS Code 需要为 Claude Code 写一套集成代码
- JetBrains 需要为 Gemini CLI 写一套集成代码
- Neovim 需要为 OpenCode 写一套集成代码
- 以此类推……

每个 Agent 都有自己的 API 设计，每个编辑器都要重复实现相同的功能（文件读写、终端控制、权限管理）。Agent 开发者被锁定在特定编辑器生态里，编辑器开发者也疲于为层出不穷的新 Agent 写适配层。

这正是十年前 LSP 所解决的 M×N 困境——只是这一次，主角从“编程语言”变成了“AI 编程智能体”。

### 1.3 ACP 的诞生：从终端 hack 到开放标准

ACP 的诞生源于一个非常实际的问题。

2025年初，Zed 团队正在开发实验性的“智能体编辑”（agentic editing）功能——让 AI 助手能够自主执行多步代码修改。当时 Google 带着 Gemini CLI 找到 Zed 团队，双方都希望实现比“在终端里运行 CLI”更深度的集成。

Zed 的开发者回忆道：“我们已经在嵌入式终端里运行 Gemini CLI……但我们需要一种比 ANSI 转义码更结构化的通信方式。”他们的解决方案是定义一套最小的 JSON-RPC 端点集合，用于传递用户请求和渲染 Agent 响应。这个实用主义的方案——源于即时需求而非委员会设计——后来成为了 ACP 的基石。

2025年8月，Zed 以 Apache 许可证正式发布了 ACP 作为开放标准，Google 的 Gemini CLI 成为首个参考实现。Zed 的 CEO Nathan Sobo 指出，该协议可能产生类似于 LSP 的行业影响，但专注于 AI Agent 领域。

ACP 的核心设计理念是：用户主要在代码编辑器中工作，希望能够随时调用智能体来协助完成特定任务。它同时支持本地和远程两种部署场景——本地智能体作为代码编辑器的子进程运行，通过 stdio 使用 JSON-RPC 通信；远程智能体可部署在云端或独立基础设施上，通过 HTTP 或 WebSocket 通信。

到了2025年10月，JetBrains 正式宣布支持 ACP，并与 Zed 联合推进协议的发展。JetBrains 强调，ACP 的最大好处是“没有厂商锁定”——开发者可以在任何支持该协议的 IDE 中使用他们偏好的编程助手。

## 二、技术内核：ACP 究竟如何工作？

### 2.1 通信模型：JSON-RPC 2.0 的双向对话

ACP 的通信模型基于 **JSON-RPC 2.0** 规范，支持两种类型的消息：

- **请求（Request）**：需要响应的请求-响应对，包含 `id` 字段
- **通知（Notification）**：单向消息，不需要响应，不包含 `id` 字段

这种双向通信设计是 ACP 区别于 LSP 的关键特征。LSP 是编辑器主动、语言服务器被动响应；而 ACP 中，Agent 可以主动向 Client 发起请求——例如请求读取文件内容、请求执行终端命令、请求用户授权等。

ACP 默认使用 **stdio** 作为传输通道，Agent 作为 Client 的子进程运行，通过标准输入输出进行 JSON-RPC 通信。这种方式简洁高效、安全可靠——Agent 的生命周期由编辑器管理，通信过程不涉及网络层，天然隔离。

### 2.2 协议架构：三个核心组件

ACP 的架构包含三个核心组件：

1. **Client（客户端）**：通常是代码编辑器或 IDE，负责提供用户界面、管理环境、控制资源访问。Client 向 Agent 发送用户提示，并处理 Agent 发出的文件操作、终端命令、权限请求等。

2. **Agent（智能体）**：使用生成式 AI 自主修改代码的程序，通常作为 Client 的子进程运行。Agent 接收用户指令，自主规划并执行代码修改任务，期间可以向 Client 请求所需的资源和操作。

3. **Proxy（代理）**：可选组件，位于 Client 与 Agent 之间，可拦截并转换消息，实现提示注入、日志记录、安全审计等高级功能。

此外，ACP 还定义了 **Conductor** 这一可选的中心化组件，负责在代理链（Proxy Chains）中协调消息流。

### 2.3 通信生命周期：从握手到完成

一个完整的 ACP 交互遵循三个阶段：

**阶段一：初始化（Initialization）**

Client 向 Agent 发送 `initialize` 请求，协商协议版本并交换能力信息。如果 Agent 需要认证，Client 还需要发送 `authenticate` 请求。

```json
// Client → Agent: 初始化请求
{
  "jsonrpc": "2.0",
  "method": "initialize",
  "params": {
    "protocolVersion": "0.1",
    "clientInfo": { "name": "Zed", "version": "0.162.0" },
    "capabilities": {
      "fs": { "read": true, "write": true },
      "terminal": true,
      "permissions": { "request": true }
    }
  },
  "id": 1
}
```

**阶段二：会话创建（Session Setup）**

Client 通过 `session/new` 创建新会话（或通过 `session/load` 恢复已有会话），指定工作目录和可用的 MCP 服务器。

```json
// Client → Agent: 创建会话
{
  "jsonrpc": "2.0",
  "method": "session/new",
  "params": {
    "cwd": "/home/user/myproject",
    "mcpServers": [
      { "name": "filesystem", "command": "mcp-server-filesystem", "args": ["/home/user"] }
    ]
  },
  "id": 2
}
```

**阶段三：提示回合（Prompt Turn）**

这是核心交互阶段：

1. Client 通过 `session/prompt` 发送用户消息
2. Agent 通过 `session/update` 通知流式推送进度更新
3. Agent 根据需要发起文件操作或权限请求
4. Client 可以随时发送 `session/cancel` 中断处理
5. 回合结束时，Agent 发送 `session/prompt` 的响应，包含停止原因

### 2.4 核心能力：Agent 的“手”与“脚”

ACP 为 Agent 定义了几类核心能力，让 Agent 真正成为一个“有手有脚”的助手：

**文件系统操作**

Agent 可以读写文件，但路径必须是绝对路径，且受会话的工作目录约束：

```json
{
  "jsonrpc": "2.0",
  "method": "fs/read_text_file",
  "params": { "sessionId": "sess_abc123", "path": "/home/user/project/src/main.rs" },
  "id": 4
}
```

**终端控制**

Agent 可以创建终端、执行命令、获取输出、等待退出。这让 Agent 能够真正“动手”——运行测试、构建项目、安装依赖：

```json
{
  "jsonrpc": "2.0",
  "method": "terminal/create",
  "params": { "sessionId": "sess_abc123", "cwd": "/home/user/myproject", "command": "cargo build" },
  "id": 6
}
```

**权限请求**

当 Agent 要执行敏感操作时，必须先请求用户授权：

```json
{
  "jsonrpc": "2.0",
  "method": "session/request_permission",
  "params": {
    "sessionId": "sess_abc123",
    "toolCall": { "name": "delete_file", "arguments": { "path": "/home/user/project/config.yaml" } },
    "options": ["allow", "deny", "allow_all"]
  },
  "id": 7
}
```

用户可以选择允许、拒绝，或者允许所有同类操作。这是 ACP 信任模型的核心——Agent 有能力，但用户有最终控制权。

**流式响应**

Agent 可以流式推送响应内容，实现逐字输出效果：

```json
{
  "jsonrpc": "2.0",
  "method": "session/update",
  "params": {
    "sessionId": "sess_abc123",
    "response": { "delta": { "text": "正在分析代码..." } }
  }
}
```

### 2.5 设计原则：三个核心理念

ACP 的设计遵循三个核心原则：

1. **MCP 友好**：ACP 基于 JSON-RPC 构建，并尽可能复用 MCP（Model Context Protocol）中已定义的数据类型。这样，集成方无需为常见数据类型重新设计另一套表示方式，显著降低了集成成本。

2. **UX 优先**：协议专注于解决与 AI Agent 交互时的用户体验挑战。它提供了足够的灵活性，能够清晰地呈现 Agent 的意图和操作过程，同时避免引入不必要的抽象复杂度。用户可读文本的默认格式为 Markdown。

3. **可信赖**：ACP 适用于用户在代码编辑器中与自己信任的 AI 模型进行交互的场景。用户仍可完全控制 Agent 的工具调用，而代码编辑器则负责为 Agent 提供对本地文件和 MCP 服务器的安全访问权限。

## 三、ACP 与 MCP：互补而非竞争

在理解 ACP 时，最容易被问到的问题是：**ACP 和 MCP 有什么区别？它们会竞争吗？**

答案是：**它们互补，而非竞争**。

### 3.1 MCP：Agent 的“工具箱”

MCP（Model Context Protocol）由 Anthropic 于 2024 年底推出，它解决的核心问题是：AI 模型如何标准化地访问外部工具和数据源。

MCP 提供了标准化的工具调用接口，让 Agent 可以查询数据库、调用 API、访问文件系统、执行本地脚本等。它本质上拓宽了模型的“感知与行动边界”。

### 3.2 ACP：Agent 的“工作台”

ACP 解决的是完全不同的问题：编辑器（或更广泛的客户端）如何与 AI Agent 通信。

ACP 定义了 Agent 如何接收用户指令、如何向编辑器请求文件内容、如何请求执行终端命令、如何请求用户授权、如何展示代码 diff。它本质上定义了 Agent 在编辑器中的“存在方式”。

### 3.3 三者关系：工作台、工具箱与通讯录

用一个比喻来理解三个主要 Agent 协议的关系：

- **ACP（Agent Client Protocol）** 是 Agent 的 **“工作台”** ——定义 Agent 在哪里工作、如何与用户交互
- **MCP（Model Context Protocol）** 是 Agent 的 **“工具箱”** ——定义 Agent 能用什么工具
- **A2A（Agent-to-Agent Protocol）** 是 Agent 的 **“通讯录”** ——定义 Agent 之间如何协作

在 ACP 的设计中，编辑器可以把用户配置的 MCP 服务器信息传递给 Agent：

```json
{
  "method": "session/new",
  "params": {
    "cwd": "/home/user/project",
    "mcpServers": [
      { "name": "filesystem", "command": "/path/to/mcp-server", "args": ["--stdio"] }
    ]
  }
}
```

Agent 收到后，直接连接这些 MCP 服务器，获取工具能力。这种设计的好处是：编辑器不需要知道 Agent 内部如何使用工具，Agent 也不需要关心 MCP 服务器是谁配置的。

## 四、生态现状：从星星之火到燎原之势

截至2026年初，ACP 已经从 Zed 一家的实验性协议，发展为拥有繁荣生态的开放标准。

### 4.1 ACP Registry：生态的“应用商店”

2026年1月，JetBrains 与 Zed 联合发布了 **ACP Registry**——一个集中的 Agent 注册表，让开发者可以在 IDE 内一键浏览、安装兼容的 AI Agent。

ACP Registry 解决了 Agent 分发碎片化的问题。此前，Agent 必须作为每个客户端的扩展单独发布，或由用户手动安装。有了 Registry，开发者只需注册一次 Agent，就能在所有 ACP 兼容的客户端中可用。

目前，ACP Registry 中已收录了九个经过审核的 Agent：

- **Auggie CLI**（Augment，专注大规模代码重构）
- **Claude Code**（Anthropic）
- **Codex CLI**（OpenAI）
- **Factory Droid**（自动化代码生成工作流）
- **Gemini CLI**（Google，ACP 的首个参考实现）
- **GitHub Copilot**（Microsoft）
- **Mistral Vibe**（Mistral AI，轻量级快速 Agent）
- **OpenCode**（社区驱动的开源 Agent）
- **Qwen Code**（Alibaba，多语言支持）

在 JetBrains IDE（从版本 2025.3.2 起）中，开发者可以在 Agent Picker 菜单中点击“Install From ACP Registry”，直接选择和安装这些 Agent。

### 4.2 客户端支持：从 Zed 到全平台

ACP 的客户端生态已经从 Zed 一家扩展到几乎所有主流编辑器：

| 客户端类型 | 代表产品 | 支持方式 |
|:---|:---|:---|
| **原生支持** | Zed | 深度集成，ACP 的诞生地 |
| **IDE 平台** | JetBrains 全家桶（IntelliJ IDEA、PyCharm、GoLand 等） | 从 2025.3 版本起原生支持 |
| **插件方式** | VS Code、Cursor | 通过 ACP Client 扩展 |
| **经典编辑器** | Neovim、Emacs | 通过 CodeCompanion、agent-shell 等插件 |
| **笔记软件** | Obsidian | 通过 Agent Client 插件 |
| **浏览器** | Chrome | 通过 Chrome ACP 扩展/PWA |
| **游戏引擎** | Unity | 通过 Unity Agent Client |
| **数据工具** | Jupyter Notebooks、DuckDB | 通过扩展 |
| **即时通讯** | Discord、Slack、Telegram、WeChat | 通过各类桥接工具 |

### 4.3 社区 SDK：多语言支持

ACP 官方提供了五种语言的 SDK：

- **TypeScript/JavaScript**：`@agentclientprotocol/sdk`
- **Rust**：`agent-client-protocol`
- **Kotlin**：用于 JetBrains 集成
- **Python**：用于 Agent 开发
- **Java**：企业级集成

此外，社区贡献了 Dart、.NET、Go、Swift 等语言的实现，极大丰富了开发者的选择。

### 4.4 关键里程碑时间线

- **2025年初**：Zed 团队开始实验“agentic editing”功能
- **2025年8月**：Zed 正式发布 ACP 开放标准，Gemini CLI 成为首个参考实现
- **2025年9月**：Codex 通过 ACP 在 Zed 中可用
- **2025年10月**：JetBrains 宣布正式支持 ACP，与 Zed 联合推进协议发展
- **2025年12月**：JetBrains IDE 2025.3 版本正式支持 ACP
- **2026年1月**：JetBrains 与 Zed 联合发布 ACP Registry

## 五、争议与挑战：ACP 的“成人礼”

ACP 的发展并非一片坦途。从诞生之日起，它就面临着来自社区的多种质疑和批评。这些争议不仅是对 ACP 的考验，也是任何新标准走向成熟必须经历的“成人礼”。

### 5.1 “又一个新协议？”——协议碎片化的担忧

开发者社区最尖锐的批评是：在 ACP 出现之前，已经存在 AG-UI、A2A、ANP 等多个与 Agent 通信相关的协议。ACP 是在解决问题，还是在制造新的碎片化？

一些开发者认为，AI 编码智能体领域本身还不够成熟，此时进行标准化为时尚早。他们担心“过早标准化”——在底层技术还未稳定之前急于制定协议，可能导致标准与实际情况脱节，反而增加迁移成本。

支持者的回应是：ACP 解决的是一个具体且紧迫的问题——编辑器和 Agent 之间的集成。与 AG-UI 等通用 Agent UI 协议不同，ACP 专注于编码场景，深度考虑了文件操作、终端控制、代码 diff 展示等编程特有的需求。它不是“又一个协议”，而是填补了协议生态中的特定空白。

### 5.2 “为什么不直接扩展 LSP？”

另一个常见质疑是：既然 LSP 已经在编辑器生态中取得了巨大成功，为什么不直接在 LSP 之上扩展 AI Agent 能力，而要创建一个全新的协议？

这个质疑触及了 ACP 存在的核心理由。LSP 和 ACP 在范式上存在根本差异：

- **LSP 是同步的请求-响应模型**：编辑器请求，语言服务器返回结果。这是一种被动响应型协议，语言服务器不会主动发起操作。

- **ACP 是异步的双向通信模型**：Agent 可以主动向编辑器发起请求（读文件、执行命令、请求权限）。这是一种主动协作型协议，Agent 有自主行动能力。

正如一篇分析所指出的：“语言服务器报告代码；而 AI Agent 修改代码，可能需要跨文件编排工作、显示 diff、获得用户批准并管理复杂工作流。若勉强塞进 LSP，会失去重点。”

此外，LSP 缺乏对用户交互（如确认应用更改）、多步对话、复杂操作序列的支持，这些都是 AI Agent 场景的核心需求。ACP 针对这些需求做了专项设计——支持会话模式下的多轮 Prompt 交互、让 Agent 自主提出“计划”并逐步执行、在完成后提供统一的更改 diff 供用户审核。

### 5.3 JSON-RPC 的性能争议

ACP 选择 JSON-RPC over stdio 作为通信方式，也引发了性能方面的讨论。部分性能敏感的开发者认为，JSON-RPC 的文本序列化和反序列化会带来不必要的开销，尤其是在高频交互场景下。

支持者的观点是：JSON-RPC 的优势在于简单、可读、跨语言兼容，这正是标准协议所需要的特性。而且 ACP 的通信频率远低于 LSP（LSP 需要在每次按键时发送请求），JSON-RPC 的性能开销在实际使用中几乎不可感知。

此外，ACP 的传输层是解耦的——虽然默认使用 stdio，但协议本身不绑定任何特定传输方式，未来可以支持更高效的二进制协议。

### 5.4 “我宁愿把 AI 当人类开发者”——替代方案的挑战

社区中还有一种务实的声音：与其追求深度集成，不如采用更简单的方法——把 AI Agent 当作人类开发者对待。开发者通过 prompt 让 AI 编写代码，AI 通过版本控制系统提交更改，开发者 review 后合并。

这种“prompt coding”方式的拥护者认为，它保持了清晰的边界，不需要复杂的编辑器集成协议。如果 commit 不满意，就 `git reset --hard`，优化 prompt 后再来一次。

这个观点很有力，但忽略了两个关键场景：

1. **复杂任务需要实时反馈**：修改多个文件、运行测试、修复错误——这些操作如果完全脱离编辑器进行，反馈循环会很长。ACP 让 Agent 在编辑器内实时展示进度、diff 和状态，极大缩短了迭代周期。

2. **Agent 需要“看到”编辑器状态**：光标位置、当前打开的文件、最近的编辑历史——这些上下文信息对 Agent 做出准确判断至关重要。没有深度集成，Agent 只能“盲写”代码。

### 5.5 最大的悬念：VS Code 会支持吗？

ACP 面临的最大市场挑战，或许是 **VS Code 的态度**。

VS Code 占据了超过 75% 的开发者市场份额，其扩展市场拥有超过 80,000 个扩展。相比之下，JetBrains 的扩展市场约 10,000 个，Open VSX Registry 不到 7,000 个。

目前，VS Code 团队对 ACP 的态度是“观望”。在 VS Code 的 GitHub issue 中，微软工程师 Rob Lourens 表示“这很有趣，但我不打算马上实现”。

VS Code 的缺席是 ACP 生态的最大不确定性。如果 VS Code 最终选择支持 ACP，协议将获得决定性的市场推力；如果 VS Code 推出自己的竞争协议，生态可能面临分裂。不过，JetBrains 等 IDE 厂商的支持已经为 ACP 提供了足够大的初始用户基础。

### 5.6 安全性挑战

随着 ACP 的采用范围扩大，安全性问题也开始受到关注。

一篇安全研究文章指出，当 ACP 被扩展到 OpenClaw 这样的多 Agent 编排网关时，其暴露面会显著扩大。传统的 ACP 是本地进程通信，安全性主要依赖操作系统的进程隔离；但当 ACP 通过 WebSocket 暴露为远程服务时，攻击者可能通过协议语义指纹进行暴露面探测。

此外，Agent 的文件系统和终端访问能力如果被滥用，可能造成数据泄露或系统破坏。ACP 的权限请求机制在理论上解决了这个问题，但实际效果依赖于实现质量——如果权限请求过于频繁会导致“点击疲劳”，如果过于宽松则形同虚设。

这些安全挑战是协议走向成熟必须解决的问题，也是 ACP 社区当前重点投入的方向之一。

## 六、未来演进：ACP 的路线图

ACP 仍在积极开发中，GitHub 上标记为“still under heavy development”。从官方的 RFD（Request for Discussion）列表可以看到几个重要的演进方向。

### 6.1 会话增强

当前 ACP 的会话管理相对简单。未来版本将引入更丰富的会话操作：

- `session/fork`：从某个历史点分叉出新会话，用于探索不同的解决方案分支
- `session/resume`：恢复中断的会话，支持长时任务
- `session/list`：列出所有可用会话，支持会话管理
- 会话持久化：支持将会话状态保存到磁盘，跨编辑器会话恢复

这些增强将使 ACP 能够支持更复杂的多轮、多分支交互场景，让 Agent 真正成为一个“长期工作伙伴”而非“一次性问答工具”。

### 6.2 代理链（Proxy Chains）

Proxy Chains 是 ACP 最具想象力的演进方向之一。它允许多个代理（Proxy）串联在 Client 和 Agent 之间，每个代理可以拦截、转换、增强消息流。

典型应用场景包括：

- **提示注入**：在用户消息前自动添加系统指令
- **日志记录**：记录所有通信内容用于调试和审计
- **安全审计**：检查 Agent 的敏感操作是否符合安全策略
- **性能监控**：统计 Agent 的响应时间和工具调用频率
- **多 Agent 协作**：一个 Agent 的输出作为另一个 Agent 的输入

### 6.3 Telemetry 导出

标准化 Agent 的性能和使用数据导出方式是 ACP 的重要方向。这包括：

- 工具调用次数和耗时
- 文件操作的类型和频率
- 会话时长和 token 消耗
- 错误率和失败原因

标准化的 Telemetry 将为 Agent 开发者提供宝贵的性能洞察，也为用户提供选择 Agent 的客观依据。

### 6.4 远程 Agent 的完整支持

目前 ACP 主要面向本地 Agent（作为编辑器的子进程运行）。对远程 Agent 的完整支持仍在积极开发中，ACP 团队正在与多家 Agent 平台密切合作，以确保协议能够满足云托管和远程部署场景的特定需求。

远程 Agent 支持将带来新的可能性：团队共享同一个 Agent 实例、使用云端 GPU 加速推理、Agent 7×24 小时运行处理长时任务等。

### 6.5 标准化 IDE 能力

ACP 正在探索通过 Proxy 将 IDE 的更多原生能力标准化并暴露给 Agent。例如：

- 诊断信息（Diagnostics）：将 LSP 产生的错误和警告传递给 Agent
- 代码导航：让 Agent 能够跳转到定义、查找引用
- 重构操作：标准化重命名、提取函数等重构操作
- 测试运行：集成测试框架的结果

这将让 Agent 真正“理解”代码库的状态，做出更智能的决策。

## 七、四协议横向对比：ACP 在协议生态中的位置

在 Agentic AI 协议生态中，ACP 并非孤立的协议。它与 MCP、A2A、ANP 共同构成了多 Agent 系统的通信基础设施。理解它们的关系，有助于正确选型。

### 7.1 四协议定位对比

| 维度 | **ACP（Agent Client Protocol）** | **MCP（Model Context Protocol）** | **A2A（Agent-to-Agent）** | **ANP（Agent Network Protocol）** |
|:---|:---|:---|:---|:---|
| **核心定位** | Agent 的“工作台” | Agent 的“工具箱” | Agent 的“通讯录” | Agent 的“社交网络” |
| **通信双方** | 客户端（编辑器）↔ Agent | Agent ↔ 工具/数据源 | Agent ↔ Agent | Agent ↔ Agent（去中心化） |
| **传输层** | JSON-RPC over stdio/HTTP/WebSocket | JSON-RPC over stdio/HTTP | HTTPS | P2P |
| **发现机制** | ACP Registry | 工具注册表 | Agent Card | DID 分布式身份 |
| **典型场景** | 在 IDE 中调用 AI 编程助手 | 模型查询数据库、调用 API、读写文件 | 企业工作流中的多 Agent 协作 | 跨组织 Agent 市场、去中心化协作 |
| **安全方案** | 权限请求 + 进程隔离 | OAuth 2.0 | 企业级签名 | 加密签名 + DID |
| **提出者** | Zed Industries + Google | Anthropic | Google + 多家企业 | BeeAI + IBM |

### 7.2 三协议协作示例

假设你使用 Zed 编辑器，通过 ACP 连接了 Claude Code Agent，并让 Agent 完成一个任务。整个协作流程如下：

1. **ACP 阶段**：Zed（Client）通过 ACP 向 Claude Code（Agent）发送用户指令
2. **MCP 阶段**：Claude Code 需要查询数据库，通过 MCP 连接数据库服务器获取数据
3. **A2A 阶段**：Claude Code 发现自己不擅长前端开发，通过 A2A 协议委托一个专门的前端 Agent 处理 UI 代码
4. **ACP 阶段**：所有 Agent 的输出最终通过 ACP 流式返回到 Zed 编辑器，展示给用户

这三个协议各司其职，共同构成完整的 Agentic AI 协议栈。

### 7.3 ACP 与 LSP 的本质差异

作为结语，有必要再次强调 ACP 与 LSP 的本质差异——这不仅是技术上的，也是范式上的。

| 维度 | **LSP** | **ACP** |
|:---|:---|:---|
| **通信模式** | 同步请求-响应（编辑器主动） | 异步双向通信（双方均可主动） |
| **核心功能** | 报告代码信息（补全、诊断、跳转） | 修改代码（读写文件、执行命令、展示 diff） |
| **操作范围** | 单文件为主 | 跨文件编排 |
| **用户交互** | 几乎不需要（被动提示） | 需要（确认更改、授权敏感操作） |
| **会话状态** | 无状态或轻状态 | 有状态的多轮会话 |
| **输出形式** | 结构化数据（补全列表、诊断数组） | 流式文本 + diff + 工具调用 |

LSP 让编辑器“看懂”代码；ACP 让编辑器“操控”代码。二者不是替代关系，而是不同层次的协议。

## 八、总结：协议的价值

回到本文开篇的问题：**为什么需要 ACP？**

答案是**标准化带来的网络效应**。

LSP 让任何语言都能在任何编辑器里获得智能提示。ACP 的目标是让任何 AI Agent 都能在任何客户端里工作。

对于 **Agent 开发者**：实现一次 ACP，就能在所有支持 ACP 的客户端里运行——不管是编辑器、笔记软件还是自动化工具。

对于 **客户端开发者**：实现一次 ACP Client，就能支持所有 ACP Agent。

对于 **最终用户**：可以自由选择喜欢的工具和 Agent 组合，不被锁定在特定生态里。今天用 Claude Code，明天换 Gemini CLI，后天试试 OpenCode——无需更换编辑器，一键切换。

ACP 的愿景不止于代码编辑器。任何需要 AI Agent 能力的应用——Obsidian 这样的笔记软件、Figma 这样的设计工具、甚至企业内部的自动化平台——都可以通过实现 ACP 来接入整个 Agent 生态。

协议的边界，决定了生态的边界。

**参考链接**

- [1] Agent Client Protocol 官网: https://agentclientprotocol.com/
- [2] ACP GitHub 仓库: https://github.com/agentclientprotocol/agent-client-protocol
- [3] Model Context Protocol: https://modelcontextprotocol.io/
- [4] A2A Protocol: https://a2a-protocol.org/
- [5] JetBrains ACP 公告: https://blog.jetbrains.com/ai/2025/10/jetbrains-zed-open-interoperability-for-ai-coding-agents-in-your-ide/
- [6] Zed Codex ACP 集成: https://zed.dev/blog/codex-is-live-in-zed
- [7] PromptLayer ACP 深度分析: https://blog.promptlayer.com/agent-client-protocol-the-lsp-for-ai-coding-agents/
- [8] The Register: JetBrains backs ACP: https://www.theregister.com/2025/10/07/jetbrains_acp_vs_code/

配图 (可多选)

选择新图片文件或拖拽到此处

标签