AI_概念篇_ACP（Agent Client Protocol）

AI_概念篇_ACP（Agent Client Protocol）

一、ACP 是什么

ACP（Agent Client Protocol，智能体客户端协议） 是由 Zed Industries 主导发起的开放标准，于 2025 年 9 月正式发布。它定义了编辑器（Client）与 AI 编程 Agent（Server）之间的标准通信规范。

理解 ACP 最好的类比是 LSP（Language Server Protocol） 。

LSP 在 2016 年将语言智能（补全、跳转、报错）从 IDE 中解耦，让每个语言工具只需实现一次就能接入所有编辑器。ACP 的目标是在 AI Agent 时代做同样的事：

"就像 LSP 把语言智能从单体 IDE 中解放出来，ACP 的目标是让开发者在不换编辑器的情况下自由切换 Agent。"
—— Zed CEO Nathan Sobo

---

二、ACP 解决的核心问题

2.1 接入层：消除集成爆炸

在 ACP 出现之前，每款编辑器若想集成 AI 能力，必须自行设计一套专属实现：自定义通信协议、自建 Agent Engine、单独维护与各 AI 平台的对接层。

Cursor    → 自建 Agent Engine，专属对接 Claude API
VS Code   → 自建 Agent Engine，专属对接 GitHub Copilot
Zed       → 自建 Agent Engine，专属对接 Gemini API

结果：N 个编辑器 × M 个 AI 平台 = N×M 套独立集成

注意：Claude API、Copilot、Gemini API 在此语境下指的是模型或 AI 平台，并非独立运行的 Agent 进程。Cursor 内置的 Agent Engine 才是真正执行 AI 推理的模块，它调用 Claude API，但与 Claude API 之间没有标准化的 Agent 协议——一切都是 Cursor 的专属实现。

有了 ACP 之后，编辑器和 Agent 各自只需实现一次 ACP 接口，即可任意互连：

任意编辑器 ←—— ACP ——→ 任意 Agent

结果：N 个编辑器 + M 个 Agent = N+M 套实现

2.2 输出层：统一 Agent 输出语义

ACP 不仅解决接入层的集成问题，其更深层的价值在于：将 Agent 的执行过程（推理 + 工具调用 + 副作用）标准化为编辑器可消费的一套统一输出语义。

ACP 规范中定义了标准化的消息类型，包括：

• diff：代码变更块，编辑器可直接渲染为 diff 视图
• stream chunk：流式推理内容，用于实时展示 Agent 思考过程
• tool request：Agent 申请执行工具（读写文件、运行命令等）
• diagnostic：诊断信息，与编辑器的错误提示体系对接

这套统一语义使得任意编辑器都能构建一致的 AI 交互体验——无论底层 Agent 是谁，代码 diff 的渲染方式、推理过程的展示方式、工具执行的授权方式，在用户侧都保持一致。

---

三、ACP 的典型场景：跨进程通信

ACP 的设计动机来自编辑器进程与 Agent 进程分离的场景。两者作为物理上独立的程序，需要一个标准协议来对话。

现实中 AI 编程工具分两类：

━━━━━━━━  场景 A：内置 Agent（ACP 不适用）  ━━━━━━━━

[ Cursor 应用程序进程 ]
├── Editor Core（UI、文件树、代码高亮…）
└── Agent Engine（内置，与 Editor 同进程）
        │ 进程内直接调用（无协议开销）
        ▼
    工具调用层 → 外部工具（文件/GitHub/…）

Editor 和 Agent 在同一进程里，Editor 直接调用 Agent 模块，
无需 ACP。Cursor 进程本身即为 MCP Host（若使用 MCP 作为工具层）。

注意：Zed 虽然也可以启动外部 Agent，但 Agent 始终以独立子进程
运行，Zed 通过 ACP（JSON-RPC over stdio）与其通信，进程边界
始终存在，因此仍属于场景 B，与 Cursor 的内嵌模式有本质区别。


━━━━━━━━  场景 B：外部 Agent（ACP 的核心场景）  ━━━━━━━━

[ Zed 进程 ]              [ Claude Code 进程 ]
Editor Core             Agent Engine
ACP Client    ◄──────►  ACP Server
（发起请求）   ACP 协议   （处理请求，同时兼任 MCP Host）
                              │
                          工具调用层（常为 MCP，也可为其他实现）
                              │
                          外部工具（文件/GitHub/…）

Editor 和 Agent 是两个独立进程，ACP 是它们之间的桥梁。

需要说明的是：ACP 在协议规范层面并不强制要求进程物理分离。理论上，一个内嵌 Agent 的编辑器也可以实现 ACP 接口。进程分离是 ACP 的典型工程场景，是其设计动机，而非硬性约束。

📌 Cursor 是 Agent 吗？ 严格来说不是。Cursor 是一个包含 Agent Engine 的应用程序（IDE） ，Agent Engine 是其内部负责 AI 推理的模块。说"Cursor 是 MCP Host"是准确的（Cursor 进程管理 MCP 连接）；说"Cursor 是 Agent"则是把 IDE 与其内置的 AI 引擎混为一谈了。

---

四、角色模型

4.1 ACP 角色：Client / Server

ACP 使用 Client / Server 模型，命名规则与直觉相反——编辑器是 Client，Agent 是 Server。

这是因为从请求发起方向看，永远是编辑器主动找 Agent（"我有个任务要你做"），Agent 被动响应，符合 Server 监听 / Client 发起的经典模式。

4.2 MCP Host 是什么

MCP Host 是管理 MCP 连接生命周期的宿主程序，职责包括：

• 启动并维护 MCP Server 子进程
• 将工具调用请求转发给对应的 MCP Server
• 汇总工具返回结果，传递给 LLM 继续推理

需要特别说明的是：MCP Host 并不是"LLM 运行的载体" 。LLM 的推理过程几乎总是运行在远端 API（如 Anthropic、Google 的服务器），MCP Host 是本地的连接管理者与协调者，而非模型的运行环境本身。

在场景 B 中，外部 Agent 进程（如 Claude Code）同时扮演两个角色：

• 角色 A：ACP Server —— 响应编辑器发来的任务请求
• 角色 B：MCP Host —— 管理下游 MCP Server 的连接与工具调用

---

五、完整分层架构（场景 B：Zed + 外部 Agent）

┌────────────────────────────────────────────┐
│  进程 1：Zed 编辑器                         │
│  角色：ACP Client                          │
│  · 感知光标位置、打开文件、诊断信息         │
│  · 发起 AI 任务请求，渲染返回的 diff        │
└──────────────────┬─────────────────────────┘
                   │
          ACP 协议（JSON-RPC / stdio）
          统一输出语义：diff · stream · tool request · diagnostic
                   │
┌──────────────────▼─────────────────────────┐
│  进程 2：Claude Code / Gemini CLI           │
│  角色 A：ACP Server（对内，响应编辑器的任务请求） │
│  角色 B：MCP Host（对外，管理工具连接，若使用 MCP）│
│  · 调用远端 LLM API，制定执行计划          │
│  · 通过工具调用层（常为 MCP）执行外部操作   │
└──────────────────┬─────────────────────────┘
                   │
          工具调用协议（常为 MCP，也可为其他实现）
                   │
┌──────────────────▼─────────────────────────┐
│  外部工具 / 数据源                          │
│  ├── 文件系统（read / write / list）        │
│  ├── GitHub API（PR / commit / issue）     │
│  └── 数据库 / 网页爬取 / CI-CD / …        │
└────────────────────────────────────────────┘

---

六、ACP 与 MCP 的关系

ACP 与 MCP 在协议层面相互独立，ACP 不感知也不依赖 MCP。

ACP 规范本身对 Agent 内部使用何种工具调用机制没有要求——Agent 可以使用 MCP、也可以使用原生 API 调用、也可以使用自定义实现。只是当前主流 Agent runtime 恰好以 MCP 作为工具调用层，两者在实践中经常同时出现，但这是工程选择，不是协议约束。

协议	连接方	解决的问题
MCP	Agent ↔ 工具 / 数据源	Agent 如何获取能力（读文件、跑命令、查数据库）
ACP	编辑器 ↔ Agent	编辑器如何与 Agent 对接（发 Prompt、渲染结果、管理 Session）

当两者同时使用时，实际工作流如下：

编辑器 ──[ACP]──► Agent ──[MCP 或其他]──► 工具（文件 / Git / DB）
                     ▲                           │
                     └───────────────────────────┘
                        工具结果 → Agent 整理 → 编辑器渲染 diff

---

七、ACP 核心机制

Session（会话）

ACP 以 Session 为基本单元，支持多轮持续对话。

• 编辑器侧：负责发起 Session、渲染 diff、管理历史记录；Session 存活期间，编辑器状态（打开文件、光标位置、诊断信息）可随时同步给 Agent
• Agent 侧：在 Session 内理解上下文、处理 Prompt、流式返回结果

双向通信（Bidirectional）

ACP 不是单向的"发问 → 回答"，双方都可以主动发起请求：

• 编辑器 → Agent：发送 Prompt，附带当前文件上下文和光标位置
• Agent → 编辑器：申请读写文件、请求执行终端命令、推送流式内容块

传输层

ACP 支持多种传输方式：

• stdio（JSON-RPC over stdin/stdout） ：Agent 作为子进程被编辑器启动，零网络开销，适用于本地场景
• HTTP/SSE：适用于远程部署场景——云端 IDE、浏览器开发环境、远程 Agent 服务

非本地 Agent + 非本地编辑器的远程组合，是 ACP 传输层设计预留的重要方向，也是未来云端开发工具演进的潜在场景。

---

八、ACP Registry（注册中心）

2026 年 1 月上线，解决生态的分发问题——此前 Agent 需要在每款编辑器单独发布扩展。有了 Registry 之后：

• Agent 开发者向 Registry 提交一次实现，即可被所有 ACP 兼容编辑器发现和安装
• 类比 npm 之于 Node 包，Registry 是 Agent 生态的统一分发层

已入驻的 Agent：Claude Code、Codex CLI、Gemini CLI、GitHub Copilot CLI、Cline、OpenCode、Goose 等。

Agent 在各 IDE 中的存在形式

Agent 并非在所有 IDE 中都以"扩展/插件"形式存在，各家形态不同：

IDE	Agent 的存在形式
Zed	独立二进制进程，通过 ACP Registry 安装，不内嵌进 Zed，以子进程方式启动并通过 ACP 通信
JetBrains	仍在落地阶段，方向是 Agent 以独立进程通过 ACP 接入，目前部分 AI 能力仍以 JetBrains 插件形式提供
Neovim	Lua 插件（CodeCompanion / avante.nvim）作为桥接层，实际调用外部 Agent 进程
VS Code	扩展（.vsix），运行在 Extension Host 进程中，Agent 逻辑内嵌于扩展内

Zed 的做法最接近 ACP 的原始设计意图：Agent 是真正独立的进程，编辑器通过标准协议与其通信，两者可以独立升级和替换。

另需注意：市面上大多数 AI 编程插件（如 JetBrains 中的 Trae AI、 Copilot）属于各自实现的私有集成，调用云端模型 API后将结果注入编辑器补全 provider，不经过 ACP，在 ACP 语境下不算标准 Agent。只有实现了 ACP Server 接口的独立进程（如 Claude Code、Gemini CLI、Copilot CLI）才属于 ACP Agent。

---

九、ACP 全局架构总览

结合前文所述的运行场景、MCP 工具调用关系以及 Registry 分发机制，ACP 的完整生态架构如下所示：

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#334155',
    'primaryBorderColor': '#cbd5e1',
    'lineColor': '#94a3b8',
    'fontFamily': 'ui-sans-serif, system-ui, -apple-system, sans-serif',
    'fontSize': '14px'
  },
  'flowchart': { 'nodeSpacing': 50, 'rankSpacing': 60, 'padding': 20 }
}}%%

flowchart TB

  %% 顶部：分发层
  REG["🌐 ACP RegistryAgent 统一分发中心"]

  %% 外层 Wrapper 强制 A 和 B 左右并排
  subgraph WRAPPER [" "]
    direction LR

    subgraph SA["场景 A — 高度集成型（Cursor / Windsurf）"]
      direction TB
      %% 💡 占位符：防止长标题换行后遮挡下方节点
      SA_SPACE[" "]:::transparent

      EC_A["💻 Editor Core光标 · 文件感知 · UI 渲染"]
      LLM_A["🧠 Agent Engine（MCP Host）大模型交互 · 推理 · 规划(进程内模块，无 ACP 角色)"]
      MCPC_A["🔌 工具调用层MCP Client 或内置实现"]

      SA_SPACE ~~~ EC_A
      EC_A <==>|"IPC 进程内通信"| LLM_A
      LLM_A -.->|"内部调用"| MCPC_A
    end

    subgraph SB["场景 B — 彻底解耦型（Zed + 独立 Agent）"]
      direction TB
      %% 💡 占位符：把内部所有的核心逻辑统统往下推
      SB_SPACE[" "]:::transparent

      subgraph EDITOR_PROC["编辑器进程 (Zed)"]
        EC_B["💻 Editor Core角色：ACP Client"]
      end

      subgraph AGENT_PROC["外部 Agent 进程(本地子进程 / 远程服务)"]
        LLM_B["🧠 Agent Logic角色：ACP Server"]
        MCPC_B["🔌 工具调用层角色：MCP Host / Client"]

        LLM_B -.->|"内部调用"| MCPC_B
      end

      SB_SPACE ~~~ EDITOR_PROC
      SB_SPACE ~~~ AGENT_PROC

      EC_B <==>|"ACP 协议(stdio / HTTP+SSE)"| LLM_B
    end
  end

  %% 底部：外部工具层
  subgraph TOOLS["外部工具层 (MCP Servers)"]
    direction LR
    S1["📁 本地文件系统"]
    S2["🐙 GitHub API"]
    S3["🌐 数据库 / 网页"]
  end

  %% 分发层连线
  REG -.->|"发现 / 安装"| EDITOR_PROC
  REG -.->|"注册 / 发布"| AGENT_PROC

  %% 工具层连线
  MCPC_A -->|"标准/私有协议"| TOOLS
  MCPC_B -->|"MCP 工具调用协议"| TOOLS

  %% 架构补充：本地文件系统的特殊回流
  S1 -.->|"文件变更需通过 ACP向 Editor 申请 UI 渲染与授权"| EC_B

  %% 样式美化与圆角定义
  classDef editor fill:#eff6ff,stroke:#3b82f6,stroke-width:2px,color:#1e40af,rx:6,ry:6
  classDef llm fill:#fffbeb,stroke:#f59e0b,stroke-width:2px,color:#92400e,rx:6,ry:6
  classDef mcpC fill:#ecfeff,stroke:#06b6d4,stroke-width:2px,color:#155e75,rx:6,ry:6
  classDef server fill:#faf5ff,stroke:#a855f7,stroke-width:2px,color:#6b21a8,rx:6,ry:6
  classDef registry fill:#f0fdf4,stroke:#22c55e,stroke-width:2px,color:#166534,rx:8,ry:8
  %% 隐形样式：用于撑开空间的节点
  classDef transparent fill:none,stroke:none,color:transparent

  class EC_A,EC_B editor
  class LLM_A,LLM_B llm
  class MCPC_A,MCPC_B mcpC
  class S1,S2,S3 server
  class REG registry
  class WRAPPER transparent

---

十、支持 ACP 的编辑器与 Agent（截至 2026 年初）

编辑器（ACP Client）

编辑器	状态
Zed	✅ 原生支持，协议发起方
JetBrains 全系（IntelliJ、PyCharm 等）	✅ 正式支持
Neovim	✅ 通过 CodeCompanion / avante.nvim
marimo（Python Notebook）	✅ 内置支持
Eclipse	🔧 社区原型

Agent（ACP Server）

Agent	接入方式
Gemini CLI	原生实现，官方参考实现
Claude Code	Zed SDK 适配器（Anthropic 尚未官方实现，Zed 建了桥接层）
Codex CLI	Zed 适配器
GitHub Copilot	原生实现
Cline	原生实现，开源
OpenCode	原生实现，开源
Goose（Square）	原生实现，开源

---

十一、名称辨析：同样缩写 ACP 的另一个协议

"ACP"在不同领域指向不同内容，阅读资料时需先判断语境：

缩写全称	发布方	领域	解决的问题	当前状态
Agent Client Protocol	Zed Industries	AI 编程工具	编辑器 ↔ Agent 标准对接	活跃维护，持续扩张
Agent Communication Protocol	IBM Research	通用 AI / 多智能体系统	Agent ↔ Agent 跨框架通信	已并入 A2A

本文介绍的是前者——Zed 的 Agent Client Protocol。若在技术文章中看到"ACP"，可结合上下文判断：涉及"编辑器集成"、"IDE 接入"、"Zed / JetBrains"时通常指前者；涉及"多智能体"、"IBM BeeAI"、"跨框架 Agent 通信"时通常指后者（已并入 A2A）。