早期的编辑器 AI 只做一件事：把代码发给模型，再显示返回的文本

编码智能体会搜索仓库、修改文件、运行测试、启动开发服务器，也会等待用户审批，一个任务可能持续十几分钟

编辑器面对的已经是一个有状态、能执行操作的外部程序，十种编辑器连接十种智能体，不应产生一百套专用集成

Agent Client Protocol，简称 ACP，为客户端和编码智能体定义了一套开放接口，智能体实现一次协议，便可进入多个兼容客户端，编辑器支持一次协议，也能连接不同智能体

ACP 把编码智能体与承载它的用户界面拆成两个可以独立选择的部分

1. ACP 是什么

同名协议

本文讨论的是 Agent Client Protocol，官网是 agentclientprotocol.com，项目由 Zed 发起，目前由 Zed 与 JetBrains 共同治理

IBM Research 和 BeeAI 曾推出另一个 ACP，全称 Agent Communication Protocol，那个协议面向智能体之间的通信，并已在 2025 年并入 A2A

两个项目只是重名，本文后续出现的 ACP 均指 Agent Client Protocol

与 LSP 的关系

可以把 ACP 理解为编码智能体领域的 Language Server Protocol，也就是 LSP

在 LSP 出现以前，每个编辑器都要分别集成 TypeScript、Python、Rust 等语言工具，LSP 在编辑器和语言服务器之间定义统一接口，把多对多适配改成双方各自实现一次协议

ACP 想对编码智能体做同样的事：

ACP 官方介绍也采用了这个类比，但 ACP 需要处理的问题比代码导航和诊断更多

语言服务器通常回答“这个符号在哪里定义”“这里有什么诊断”等相对确定的问题，智能体则会连续调用模型与工具、修改文件并产生中间状态，部分操作还需要用户决定

ACP 因此包含流式消息、执行计划、工具状态、权限请求、取消和会话恢复等语义

LSP 主要标准化语言能力，ACP 主要标准化智能体交互体验

2. 两端角色

ACP 的两端叫 Client 和 Agent

Client

Client 通常是编辑器或 IDE，也可以是桌面应用、终端 UI、网页工作台或聊天工具，它负责：

• 接收用户输入并展示智能体输出
• 渲染计划、工具调用、代码 diff 和终端输出
• 管理会话、模式和配置选项
• 向用户展示权限请求并返回选择
• 在声明支持时，向智能体提供文件系统或终端能力

Client 掌握用户体验和本地环境

Agent

Agent 是编码智能体程序，它调用模型、组织上下文、执行工具、修改代码，并把进度报告给 Client

Agent 可以原生支持 ACP，也可以通过 adapter 把已有 CLI 或 Agent SDK 包装成 ACP Agent，官网列出的兼容项目包括 Codex、Claude Agent、Gemini CLI、GitHub Copilot、Junie、OpenCode 和 Goose 等实现或适配器，ACP Agents 列表持续更新这些信息

ACP 使用双向通信

Client 调用 Agent 发送用户提示，Agent 也能反向调用 Client，请求权限、读取编辑器中的未保存文件，或者创建一个可实时展示的终端，普通聊天 API 没有这套双向语义

3. 请求流程

下面以“请修复登录接口的失败测试”为例

3.1 启动

在 ACP v1 的本地场景中，编辑器把 Agent 作为子进程启动，双方通过标准输入和标准输出传递 UTF-8 编码的 JSON-RPC 2.0 消息，一行一条

日志只能写到 stderr，不能混入协议使用的 stdout，ACP v1 传输规范对此有明确要求

一个连接可以承载多个 Session，所以用户可以在同一个 Agent 进程中同时进行多个相互独立的任务

3.2 协商

建立连接后，Client 调用 initialize 完成版本与能力协商

{
  "jsonrpc": "2.0",
  "id": 0,
  "method": "initialize",
  "params": {
    "protocolVersion": 1,
    "clientCapabilities": {
      "fs": {
        "readTextFile": true,
        "writeTextFile": true
      },
      "terminal": true
    },
    "clientInfo": {
      "name": "my-editor",
      "version": "1.0.0"
    }
  }
}

Agent 返回所选协议版本、输入类型、会话能力、MCP 能力和认证方式，双方只能使用协商后确认支持的功能

例如 Client 没有声明 terminal，Agent 就不能调用 terminal/* 方法，ACP 初始化规范给出了完整的协商规则

能力协商允许实现渐进增加功能，只支持文字和基本会话的 Client 仍能连接，支持图片、音频、嵌入资源、会话恢复和终端的 Client 可以提供更多交互

3.3 会话

初始化和必要的认证完成后，Client 通过 session/new 创建会话，也可以在 Agent 支持时加载已有会话

Session 保存持续工作的上下文，其中可以包含当前项目目录、MCP Server 配置、可选模式和多轮 Prompt Turn，会话历史与执行上下文的恢复也围绕 Session 展开

3.4 请求

用户点击发送后，Client 调用 session/prompt：

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "session/prompt",
  "params": {
    "sessionId": "sess_login_fix",
    "prompt": [
      {
        "type": "text",
        "text": "修复登录接口的失败测试"
      }
    ]
  }
}

prompt 使用 ContentBlock 数组，可以包含文本、图片、音频、嵌入资源和资源链接，ACP 复用了 MCP 的 ContentBlock 结构，MCP 工具返回的内容因而更容易进入 ACP 界面，ACP Content 文档列出了所有类型

例如，用户在编辑器里 @ 一个尚未保存的文件时，Client 可以直接把当前内存中的文件内容作为 embedded resource 发送给 Agent，而不必要求 Agent 自己从磁盘读取一个已经过时的版本

3.5 进度

编码智能体可能需要搜索代码、阅读配置、修改文件再运行测试，如果界面始终只有一个转圈动画，用户无法判断执行进度和方向

ACP 使用 session/update 通知传递中间状态，Agent 可以发送：

• 流式文字消息
• 任务计划及每一步的状态
• 工具调用的创建、进度和结果
• 受影响的文件和代码位置
• 当前上下文用量和累计成本
• 可用命令、模式或会话信息的变化

例如，Agent 准备运行测试时，可以先报告一个工具调用：

{
  "jsonrpc": "2.0",
  "method": "session/update",
  "params": {
    "sessionId": "sess_login_fix",
    "update": {
      "sessionUpdate": "tool_call",
      "toolCallId": "call_test_01",
      "title": "运行登录模块测试",
      "kind": "execute",
      "status": "pending"
    }
  }
}

Agent 随后把状态更新为 in_progress、completed 或 failed，Client 无需理解 Agent 内部使用的模型或框架，只需按照协议把调用渲染成可追踪的操作卡片

3.6 权限

执行敏感工具前，Agent 可以反向调用 Client 的 session/request_permission，并给出“仅允许一次”“始终允许”“拒绝一次”“始终拒绝”等选项，Client 展示选项并把用户决定返回给 Agent，ACP Tool Calls 文档定义了这套流程

Client 可以把权限请求渲染为原生交互，无需依赖 CLI 打印 Continue? [y/N]

ACP 的权限请求不等于操作系统沙箱

协议规定 Agent 怎样询问、Client 怎样回答，但不会自动拦截 Agent 已经拥有的文件、网络或进程权限，隔离范围与审批规则仍取决于运行方式、工具实现和宿主系统

3.7 本地能力

在 v1 中，如果 Client 在初始化时声明支持，Agent 可以调用：

• fs/read_text_file：读取文件，包括编辑器中尚未保存的内容
• fs/write_text_file：通过 Client 写入文件，让编辑器跟踪变化
• terminal/create：在 Client 环境中运行命令
• terminal/output、terminal/wait_for_exit、terminal/kill 等：读取和控制进程

Client 由此可以实时展示命令输出、保留终端记录，并把代码修改渲染成 diff，工具调用还能附带文件路径和行号，让编辑器跟随 Agent 当前查看或修改的位置

相关方法见 ACP 文件系统与终端规范

3.8 结束与取消

在 ACP v1 中，一次 Prompt Turn 最终由原始 session/prompt 请求的响应结束，并带有 end_turn、max_tokens、refusal、cancelled 等 Stop Reason

如果用户中途发现方向不对，Client 可以发送 session/cancel，Agent 应尽快停止模型请求和工具调用，处理尚未完成的权限请求，并以 cancelled 结束当前回合，ACP Prompt Turn 生命周期规定了取消后的收尾行为

ACP 标准化了从用户发送请求、查看计划、批准命令、审阅 diff，到取消或完成的整条交互链路

4. 协议对象

JSON-RPC over stdio 只解决消息怎样传输，自定义几个 prompt 和 cancel 方法无法换来互操作

ACP 让不同 Client 和 Agent 对以下概念达成一致：

概念	解决的问题
Initialize / Capabilities	双方版本和功能不同，如何安全降级
Session	多轮上下文、并发任务和历史如何组织
Prompt Turn	一次用户请求从开始到停止如何界定
ContentBlock	文本、图片、音频和资源怎样统一表达
Session Update	消息、计划和工具进度怎样实时呈现
Tool Call	不同工具怎样拥有统一的状态和结果结构
Permission	Agent 怎样把关键决定交回用户
Diff / Terminal / Location	编码动作怎样变成 IDE 原生体验
Cancellation	用户停止后，各类未完成操作怎样收尾

协议减少的是交互语义的重复设计与适配，序列化只是其中一小部分

5. 能力边界

Agent SDK

Agent SDK 解决的是“怎样构建一个智能体”：如何调用模型、定义工具、维护记忆、编排步骤

ACP 解决“怎样让这个智能体被不同客户端使用”，它不规定 Agent 内部采用哪种模型、框架或规划方式，一个 Agent 可以使用自研循环，也可以基于某种 Agent SDK，只要在边界上实现 ACP，Client 就能以统一方式与它交互

ACP 是运行时适配边界，不承担 Agent 框架或模型 API 的职责

MCP 与 A2A

这三个协议经常被放在一起讨论，但它们连接的是不同对象：

ACP

ACP 处理用户如何在某个界面中使用、观察和控制智能体

MCP

MCP 处理模型或智能体如何发现并调用工具、读取资源，ACP 复用 MCP 的内容类型，也允许 Client 把用户配置的 MCP Server 信息交给 Agent，ACP 架构说明解释了两者的连接方式

A2A

A2A 处理独立智能体之间的能力发现、任务委派和成果交换

一个系统可以同时使用三个协议，例如开发者通过 ACP 在 IDE 中指挥主编码智能体，主智能体通过 MCP 查询 GitHub 和数据库，再通过 A2A 把安全审计委派给远端专业智能体

Agent 间调用

按协议语义划分，Agent Client Protocol 不是 Agent 之间的协作协议

ACP 的发起方是 Client，接收方是 Agent，协议围绕 Session、Prompt Turn、界面更新、工具状态、权限请求和用户取消来设计，这些对象解决的是 Agent 如何进入用户工作台

技术上，一个 Agent 或编排器可以实现 ACP Client，再用 ACP 驱动另一个 Agent，这种做法在多 Agent 工作台中确实存在，但它只是复用了 Client 角色

ACP 没有把 Agent Card、远程能力发现、跨组织认证、任务委派和 Artifact 交付纳入协议主模型，两个独立 Agent 需要这些语义时，A2A 更合适

同名的 IBM Agent Communication Protocol 曾面向 Agent 间通信，那个项目已经并入 A2A，与本文讨论的 Agent Client Protocol 无关

6. v1 与 v2

ACP 仍在快速演进，以当前官方文档为准，v1 标记为 Latest，v2 的整体协议面仍标记为 Draft

v2 草案移除了 v1 的 Client 文件系统、终端执行和 Session Mode API，Agent 需要 Client 侧工具时，优先通过 Client 提供的 MCP Server 获取，ACP 自身更聚焦 Agent 与界面之间的会话、状态和展示，ACP v2 迁移说明列出了具体变化

这次调整重新划分了协议边界：

• ACP 负责“怎样交互与展示”
• MCP 负责“怎样暴露和调用工具”
• Agent 自己负责推理与执行逻辑

v2 尚未整体稳定，官方建议实现者通过版本协商同时保留 v1，并把 v2 支持放在显式开关之后，现阶段不能假设所有 Client 和 Agent 都已支持 v2

7. Registry

协议只规定安装后的通信方式，用户还需要找到 Agent、选择安装包并配置启动命令

ACP Registry为兼容 Agent 提供统一的分发元数据，Client 可以读取 Registry，展示可安装 Agent，并根据包、版本和启动信息完成安装配置

Registry 接近编辑器扩展市场与包索引的结合，Agent 实现 ACP 解决安装后的通信，Registry 解决查找与安装

8. 产品影响

协议把 Client、Agent 与模型提供商拆成可以独立演进的产品层

用户

用户可以保留熟悉的编辑器，同时更换 Agent 或模型提供商

Agent 开发者

Agent 团队可以把代码浏览、diff、终端渲染和权限弹窗交给 Client，把开发时间投入上下文管理、工具执行和任务完成质量，实现一次协议即可接入多个兼容工作台

Client 开发者

Client 无需为每个 Agent 解析专有日志、模拟终端输入，或猜测某行输出是否属于工具调用，对方提供结构化计划、状态、diff 和权限请求后，Client 可以按统一组件呈现

市场

Client 与 Agent 可以自由组合后，编辑器依靠交互体验竞争，Agent 依靠任务完成质量竞争，模型和工具也回到各自的能力比较

9. 现有限制

开放协议不代表所有实现已经具备相同能力

• 不同实现支持的 capabilities 不同，有的只有文本和基本工具状态，有的支持会话恢复、图片输入、配置切换和完整终端体验
• adapter 只能翻译底层已有能力，底层 Agent 缺少结构化计划或可靠取消时，适配器无法补齐这些行为
• ACP v1 当前最明确的标准传输仍是 stdio，Streamable HTTP 等远程传输仍在推进，跨网络部署需要核对 Client、Agent 与传输扩展的兼容情况
• 协议不负责进程权限、凭证存储、MCP Server 信任、命令隔离、网络访问和审计，这些控制仍需产品自行实现

评估 ACP 集成时，需要检查版本、capabilities、取消行为、权限模型和异常路径，单独一项“支持 ACP”不足以说明体验质量

10. 接入建议

如果你在开发 Agent，可以从最小闭环开始：

1. 正确实现 stdio framing，确保 stdout 只输出协议消息
2. 完成 initialize、版本协商和 capability 检查
3. 支持 session/new 与 session/prompt
4. 用结构化 session/update 报告消息和工具状态
5. 正确处理权限请求、取消和 Stop Reason
6. 再逐步增加会话恢复、计划、配置选项和 Registry 分发

开发 Client 时，应先做好能力协商、执行展示、权限控制和进程边界

Agent 修改十个文件、并发运行命令、请求批准又被用户中途取消时，界面仍需保持清楚、可控，一个漂亮的聊天框无法替代这些基础能力

11. 连接契约

编码智能体已经从编辑器里的附加功能变成可以独立演进的执行系统，Agent 与 UI 分离后，双方需要一份稳定契约

Agent Client Protocol 把这份契约公开化，Client 负责用户环境和交互，Agent 负责推理与执行，双方通过统一的会话、更新、工具和权限语义协作

协议不会让每个 Agent 表现一致，也不会自动解决安全和兼容问题，它提供的是可替换的连接边界

这条边界允许用户保留熟悉的编辑器，再为具体任务选择合适的 Agent，无需接受不可拆分的产品组合