别再混淆 ACP 和 MCP：一文看懂 AI 编程的协议分工
ACP 和 MCP 经常被放在一起讨论，却解决不同层的问题。本文从角色、任务流和协议边界三个角度，讲清 AI 编程场景中的协议分工。
摘要：当编程智能体越来越多，编辑器如果要为每个智能体单独做一套接入，生态很快就会碎片化。ACP 试图用一套开放协议统一客户端与编程智能体之间的通信，让会话、进度、工具调用、权限确认和代码变更都能以一致方式呈现。
资料核验时间：2026 年 7 月 29 日。当前稳定协议版本为 v1，v2 仍处于草案阶段。
打开代码编辑器，输入一句“帮我修复这个测试”，智能体开始读文件、列计划、运行命令、修改代码，并不断把进度显示在界面里。
这个体验看起来像一次自然对话，背后却需要编辑器与智能体交换大量结构化信息：工作目录在哪里？支持哪些能力？当前执行到哪一步？能不能运行这个命令？哪些文件发生了变化？用户中途取消又该怎么办？
**ACP，Agent Client Protocol，即智能体客户端协议，解决的正是这层连接问题。**它不是新的大模型，也不是新的工具平台，而是一套让代码编辑器或其他客户端与编程智能体互相通信的开放协议。官方把它类比为智能体时代的 LSP：LSP 让编辑器更容易接入不同语言服务器，ACP 则希望让客户端更容易接入不同编程智能体。ACP 官方介绍
这篇文章不展开 SDK 代码，而是回答三个更基础的问题：ACP 连接谁、一次任务如何流动，以及它和 MCP 到底是什么关系。
ACP 要解决的是“每一对产品都要单独适配”
没有通用协议时，一个编辑器想接入多个智能体，往往要分别理解它们的启动方式、消息格式、会话状态、权限模型和进度事件。智能体想进入多个编辑器，也要反过来适配各家的接口。
随着产品增多，这种点对点集成会迅速变成一张难以维护的网：
- 编辑器新增一个智能体，需要再写一套适配；
- 智能体进入一个新客户端，也要再实现一套接口；
- 用户更换界面或智能体时，已有工作流很难平滑迁移；
- 计划、差异、终端和权限弹窗的体验容易各自为政。
ACP 在两者之间定义一条公共边界。只要双方都正确实现协议，就能围绕同一套消息和生命周期协作。
这里要注意一个限定：ACP 当前首先解决的是代码编辑器、IDE 等客户端与编程智能体之间的互操作，而不是所有类型智能体之间的通用通信。
一条协议连接两个角色
ACP 里的 Client 和 Agent 分工并不相同。
客户端负责界面、环境与用户控制
客户端通常是代码编辑器、IDE，也可以是其他面向用户的智能体界面。它更接近“驾驶舱”：
- 接收用户输入，展示智能体回复；
- 呈现计划、工具调用状态、代码差异和终端输出；
- 提供工作目录、文件系统和终端等环境能力；
- 在敏感操作前向用户请求许可；
- 允许用户取消正在进行的任务。
客户端不一定亲自完成编程任务，但它掌握用户交互和本地环境的入口。协议中的能力协商也让客户端可以明确告诉智能体：“我支持读文件，但不支持终端”，或“我可以展示图片，也能处理权限请求”。ACP 初始化与能力协商
智能体负责理解、规划与执行
智能体接收用户目标，调用模型，决定是否读取文件、搜索信息、执行命令或修改代码，再把过程持续汇报给客户端。
它更像“施工队”：不仅给出最终回答，还可能经历多轮模型推理和工具执行。ACP 不规定智能体内部必须使用哪一种模型、提示词或规划算法，它只规定双方需要交换的关键语义。
官方架构中，本地智能体通常由客户端按需启动为子进程，通过标准输入和标准输出交换 JSON-RPC 消息。一条连接还可以承载多个彼此独立的会话。ACP 架构说明
一次任务会经历四个关键阶段
从用户发出请求到智能体完成任务，可以把 ACP 的核心流程理解成四个阶段。
先协商版本和能力
连接建立后，客户端先发送 initialize。双方确认协议版本、各自支持的能力以及可用的认证方式。
这一步很像见面先交换一张“能力清单”。新能力通常通过 capability 增量引入；没有声明的能力，应当视为不支持。这样，客户端就不会向只支持文本的智能体发送图片，也不会让智能体调用客户端没有开放的终端能力。
再创建一个有边界的会话
客户端通过 session/new 创建会话，并提供工作目录；必要时还会附上智能体可以连接的 MCP 服务器配置。智能体返回唯一的会话 ID，后续提示、进度、取消和恢复都围绕这个会话进行。ACP 会话设置
工作目录不是无关紧要的参数。它决定任务的主要文件系统上下文，也是工具操作应遵守的重要边界。支持额外工作区根目录时，双方同样要先通过能力协商确认。
任务执行时持续流式更新
用户消息通过 session/prompt 发给智能体。智能体处理期间，用 session/update 持续报告文本、计划、工具调用、上下文用量等信息。
这就是为什么兼容 ACP 的客户端不必一直显示一个“正在思考”的黑盒。它可以把智能体当前要做什么、正在运行什么工具、修改了哪些位置，以及执行是否成功，逐步呈现给用户。ACP 提示轮次
高风险动作交还给用户决定
当智能体准备执行工具调用时，可以通过客户端请求权限。客户端既可以把“仅本次允许”“始终允许”“本次拒绝”等选项展示给用户，也可以按照用户设置自动处理。
工具调用还能携带状态、结果、受影响文件位置、代码差异或关联终端，让客户端做出更清晰的进度展示。ACP 工具调用
因此，ACP 提供的是可见性和控制接口，而不是自动保证安全。真正的风险边界仍取决于客户端实现、沙箱、权限策略，以及用户是否信任所连接的智能体和工具。
ACP 和 MCP 不是竞争关系
这是最常见的误解。
可以用一句话区分：
ACP 站在智能体前面，连接用户界面与智能体；MCP 站在智能体后面，连接智能体与工具、数据源。
具体来看：
| 问题 | ACP | MCP |
|---|---|---|
| 连接谁 | 客户端与编程智能体 | AI 应用或智能体与工具、数据源 |
| 关注什么 | 会话、消息、计划、进度、权限、差异 | 工具、资源、提示模板及其调用 |
| 用户看到什么 | 对话与执行过程 | 通常是智能体可用能力的来源 |
| 类比 | 驾驶舱与施工队的对讲系统 | 施工队连接的工具箱与资料库 |
两者还可以直接配合。客户端创建 ACP 会话时，可以把 MCP 服务器配置交给智能体；智能体再通过 MCP 使用这些外部工具和数据。ACP 官方的表述也很直接：两者解决的是与智能体交互链路中的不同部分。ACP 与 MCP 架构说明
再加上 LSP，三者的定位就更清楚了：
- LSP：编辑器与语言服务器之间的协议，重点是补全、诊断、跳转等语言能力；
- ACP：客户端与编程智能体之间的协议，重点是会话和执行体验；
- MCP：智能体或 AI 应用与外部工具、数据之间的协议，重点是能力接入。
ACP 真正带来的价值，是让两端可以独立演进
对客户端开发者来说，实现一套协议，就有机会接入更多兼容智能体，而不必为每个产品重新设计完整交互。
对智能体开发者来说，实现一套协议，就有机会进入更多兼容客户端，把主要精力放回模型、规划、工具和任务质量。
对普通用户来说，最直接的变化不是“智能体突然更聪明”，而是选择权增加了：有望在熟悉的编辑器里切换不同智能体，同时保留统一的会话、权限和进度体验。
协议也为更细腻的产品体验提供了共同语义，例如：
- 实时展示计划和工具执行状态；
- 把代码修改渲染为可审查的差异；
- 展示终端实时输出并控制进程；
- 在智能体访问本地资源前进行权限确认；
- 取消进行中的请求，或恢复已有会话。
这些能力是否可用，仍取决于双方在初始化阶段声明的 capability，不能仅凭“支持 ACP”四个字推断所有功能都存在。
现阶段还要看清四个边界
第一，协议兼容不等于效果相同。模型质量、上下文管理、工具实现和系统提示仍由各智能体决定。
第二，协议提供权限交互，不等于提供完整安全沙箱。能否限制文件范围、命令权限和网络访问，要继续看客户端与运行环境。
第三，可选能力会造成体验差异。有的组合支持图片、会话恢复和终端，有的可能只有基础文本对话。接入时必须做能力协商，产品介绍也应写清支持范围。
第四，版本仍在演进。截至 2026 年 7 月 29 日，官方仓库标明稳定线为 v1；2026 年 7 月 20 日发布的 v2 仍是草案，官方明确提醒实现者用版本协商和功能开关隔离，不要默认用于生产，并继续兼容 v1。官方仓库的版本说明 · ACP v2 草案公告
传输层也要避免过度承诺。v1 明确定义并建议支持本地 stdio；Streamable HTTP 仍标为讨论中的草案，同时允许实现自定义双向传输。因此，“支持远程场景”不等于“所有实现已经共享一套稳定的远程传输方案”。ACP v1 传输规范
读懂 ACP，只需记住三句话
**第一，ACP 是客户端与编程智能体之间的通信协议。**它标准化的不是模型能力，而是会话、消息、执行过程和用户控制。
**第二，ACP 与 MCP 分工互补。**前者管理智能体“前台”的交互，后者连接智能体“后台”的工具与数据。
**第三，ACP 的价值是降低重复集成，让编辑器和智能体可以独立演进。**但真正的功能、安全和体验，仍取决于版本、能力协商和具体实现。
如果你是使用者，下次看到某个编辑器或编程智能体写着“支持 ACP”，可以继续追问：它支持哪个协议版本？开放了哪些能力？如何处理工具权限？是否支持会话恢复？
如果你是开发者，最值得先理解的不是所有 Schema，而是最小主链路：initialize → session/new → session/prompt → session/update。先跑通这条链路，再逐步加入文件、终端、权限和会话恢复，往往更容易得到一个可验证的实现。