Agent Client Protocol（ACP，智能体客户端协议）与 Model Context Protocol（MCP，模型上下文协议）互相补充，并不是直接替代关系。ACP 主要规范客户端——通常是代码编辑器或 IDE——与 Coding Agent 之间的通信；MCP 规范 AI 应用或 Agent 如何连接外部工具、资源和数据。
一个 Coding 产品可以在“客户端到 Agent”的边界使用 ACP，在“Agent 到外部能力”的边界使用 MCP。这是一种有用的组合方式，不是协议规定的固定栈。产品可以同时使用两者，也可以只用其中一个，甚至两个都不用。
本文中的“ACP”专指 Agent Client Protocol。这个缩写也被其他无关协议使用，因此判断文档或产品支持状态时，应先确认完整名称。
一分钟看懂 ACP 与 MCP
ACP 官方介绍文档把核心边界定义为代码编辑器或 IDE 与 Coding Agent 之间的通信。MCP 官方介绍文档则把 MCP 定义为连接 AI 应用与外部系统的开放标准。
两个协议都使用 JSON-RPC 的相关概念，ACP 也会在合适的地方复用 MCP 的 JSON 表示。这种共同基础可以减少集成工作，但不会让两者的消息、角色或责任变得可以互换。
Agent Client Protocol 规范的是什么
ACP 处理的是 Coding Agent 与其外围用户界面之间的关系。常见情况下，这个应用就是代码编辑器或 IDE。Client 启动或连接 Agent，在 Session 中发送 Prompt、接收流式更新、呈现 Agent 活动，并处理需要用户批准的请求。
这些交互需要的不只是通用的工具调用 API。Coding Client 可能需要展示增量进度、终端活动、拟议改动、diff 和权限决定，同时把多个 Session 分开管理。ACP 官方架构说明介绍了双向 JSON-RPC、并发 Session、流式通知，以及 Agent 向编辑器发起的权限请求。ACP 还定义了面向 Coding 场景的表示方式，让 Client 能把这些内容组织成连贯的界面。
在常见的本地实现中，编辑器会把 Agent 作为子进程启动，并通过 stdio 通信。ACP 也面向远程 Agent，但官方文档目前仍把完整的远程支持描述为持续推进中的工作。评估具体实现时要留意这条边界：支持协议，并不自动代表本地和远程场景的行为完全相同。
ACP 不替产品选择模型、模型 Provider、工具目录或完整 Runtime 架构，这些仍是独立的产品决策。如果希望进一步了解 ACP 本身，包括角色与 Session 模型，可以阅读这篇 Agent Client Protocol 入门指南。
MCP 规范的是什么
MCP 处理的是另一个边界：AI 应用如何访问外部能力和上下文。MCP Host 是 AI 应用；它会为每个 MCP Server 连接创建一个 MCP Client，Server 则暴露可以被 Host 发现和使用的能力。
当前的 MCP 官方架构文档列出了三种核心 Server primitive（原语，也就是协议定义的基础能力）：
- Tools 是 AI 应用可以调用的可执行函数，例如搜索服务、查询数据库或修改文件。
- Resources 提供上下文数据，例如文件内容、数据库记录或 API 响应。
- Prompts 提供可复用的交互模板。
因此，MCP 并不只服务于 Coding。Coding Agent 可以使用它，普通助手、企业聊天机器人或其他 AI Host 也可以。MCP 定义上下文和能力如何交换；它的架构明确不规定应用如何使用 LLM，也不规定应用如何管理获得的上下文。
所以，在 ACP 与 MCP 的对比中，“Client”这个词容易造成误解。ACP Client 是与 Coding Agent 对话的用户端应用；MCP Client 则是 MCP Host 内部负责维持一条 MCP Server 连接的组件。它们是各自协议中的角色，不是同一个组件的两种叫法。
ACP 与 MCP 如何配合
一种可能的 Coding 产品架构如下：
在这个设计中，ACP 承载 Client 与 Agent 之间的交互式 Coding Session。Coding Agent 同时充当 MCP Host，并管理一条连接到 Server 的 MCP Client 连接；Server 暴露 tools、resources 或 prompts，也可以继续连接其他外部系统。一个请求可以从编辑器发起，由 Agent 处理，再通过 Server 触发 MCP 操作，最后经 ACP Session 把进度和结果返回给用户。
ACP 的设计支持这种组合，但并不强制这样做。ACP 架构描述了一种方式：Client 把已经配置的 MCP Server 信息交给 Agent，让 Agent 建立自己的 MCP 连接。它不会把 ACP 连接变成 MCP transport，也不要求所有 ACP 实现都暴露相同的工具拓扑。
以下几种只出现一个协议的设计同样有效：
- 通过 ACP 连接的 Coding Agent 可以使用内置工具、原生集成或直接 API，而不使用 MCP。
- AI 应用可以作为 MCP Host 连接多个 Server，同时完全不通过 ACP 暴露 Coding Agent。
- 编辑器与 Coding Agent 可以使用另一套集成接口，而 Agent 仍通过 MCP 使用工具和数据。
因此，“ACP 位于 MCP 上层”只是在描述某一种实现，不是两个协议之间的普遍层级关系。
你需要哪个协议
先看你要标准化的边界，而不是先看哪个协议名字更熟悉。
如果你的任务是为 OpenCode 配置工具，那么协议对比不能代替具体实施步骤。请按 OpenCode MCP 配置指南操作，并同时核对产品的最新文档。
ACP 与 MCP 对比中的常见误区
把两者当成争夺同一个位置的竞争协议。 ACP 主要处理 Client 与 Coding Agent 之间的体验，MCP 主要处理工具和上下文访问。用一个替换另一个，会留下不同的通信边界没有解决。
把一张有用的图变成硬性的协议栈。 Client → ACP → Agent → MCP → Tool 是一种有效组合，但不是任何一个协议的定义。两侧都可以使用其他集成方式。
认为“Client”代表同一个角色。 ACP 与 MCP 各自定义参与方。分配实现责任前，先明确写出编辑器、Coding Agent、MCP Host、MCP Client 和 MCP Server。
认为共同的 JSON-RPC 基础意味着可以互换。 Transport 和编码方式相似，并不会消除方法、数据模型、生命周期规则或 UX 责任上的差异。
只根据架构图推断协议支持状态。 兼容性是实现事实。应检查产品当前文档、支持的协议版本、连接方式和功能覆盖，不要因为概念图看起来吻合就假定已经支持。
先看边界的检查清单
在采用 ACP、MCP 或两者之前，先回答五个问题：
- 哪两个组件需要稳定合同？ 直接写出两端名称，不要用“平台”或“集成”含糊带过。
- 这个边界是否承载交互式 Coding Session？ 如果包含 Agent 轮次、流式 Coding 活动、权限和 diff，应评估 ACP。
- 这个边界是否暴露可复用能力或上下文？ 如果多个 AI 应用需要发现 tools、resources 或 prompts，应评估 MCP。
- 谁负责认证、权限和连接生命周期？ 把 Client 到 Agent 的策略与每条 MCP Server 连接分开，不要假定一个协议会替另一个协议完成安全控制。
- 今天到底实现了什么？ 按 Client、Agent、Host 和 Server 各自的当前文档与兼容版本逐项核对。
如果 Agent、模型和 Provider 这几个概念仍混在一起，可以先看清 Agent harness 与模型的区别。每个组件的职责清楚后，协议选择会容易很多。
实际结论
当集成边界是客户端或编辑器 ↔ Coding Agent时，选择 ACP；当边界是 AI 应用或 Agent ↔ 工具、资源和数据时，选择 MCP。如果同一个产品同时存在这两个互操作问题，可以考虑两者都用——但应把它们保留为两份独立合同，而不是硬性的固定协议栈。
边界清楚以后，可以打开 Agent.Space，先从一个权限和结果都容易检查的小而可逆的任务开始。