核心要点
ACP 是一个被两个不同协议共用的缩写，回答前要先问清对方指哪一个
含义①：Agent Communication Protocol——IBM BeeAI 提出、后捐入 Linux 基金会，基于标准 REST/HTTP，解决"Agent↔Agent"跨框架通信与互操作，和 Google A2A 同类
含义②：Agent Client Protocol——Zed 提出，标准化"代码编辑器/IDE↔编程 Agent"之间的通信（类比 LSP 之于语言服务），基于 JSON-RPC、通常走 stdio
层次对照：含义①是横向 Agent↔Agent；MCP 是纵向 Agent↔工具/数据；含义②是编辑器↔Agent，三者方向各不相同
标准回答
先讲清名称歧义
面试里被问 ACP，最稳的开场是先点明"这个缩写有歧义"——它被两个完全不同的协议共用，回答前最好确认对方问的是哪一个：
含义①：Agent Communication Protocol：由 IBM 旗下 BeeAI 项目提出，后被捐赠/归入 Linux 基金会 托管。它解决的是 Agent↔Agent 的通信与互操作——让不同公司、不同框架做出来的 Agent 互相发现、对话、委派任务。设计取向是基于标准 REST/HTTP，强调"本地优先"（local-first，能在本机/内网先跑起来）与"简单集成"——不引入复杂的新传输层，用熟悉的 HTTP 就能把一个 Agent 暴露成可被调用的服务。它和 Google 的 A2A 属于同一类（横向 Agent 协作协议）。
含义②：Agent Client Protocol：由 Zed（代码编辑器厂商）提出，解决的是完全不同的方向——标准化"代码编辑器 / IDE ↔ 编程 Agent"之间的通信。它的类比是 LSP 之于语言服务、MCP 之于工具：让任意编辑器都能用统一协议接入任意编程 Agent，而不必为每个 Agent 单独适配。技术上基于 JSON-RPC，通常通过 stdio 在编辑器与本地 Agent 进程间通信。
注意这两者除了缩写相同，目标、通信对象、技术栈都不一样，别混为一谈。
含义①与 A2A 的关系
Agent Communication Protocol 和 A2A 的定位高度重叠：都是"横向"的 Agent↔Agent 协作协议，都倾向架在成熟 Web 标准（HTTP）之上，都要解决跨框架互操作。差异更多在出身与侧重——ACP（BeeAI 线）强调本地优先与 REST 风格的极简集成，A2A 由 Google 主导、围绕 AgentCard/Task 等对象建模长任务协作。正因为定位太近，2025 年后社区出现明显的整合趋势：与其让生态分裂成多个互不相通的"Agent 互操作标准"，不如向统一方案收敛，因此相关项目陆续归入 Linux 基金会等中立组织并讨论彼此对齐。
三者的层次差异
把三个协议放在一起最清楚：MCP（Model Context Protocol）是"纵向"的——把工具、数据、上下文接给单个 Agent，方向是 Agent↔工具；Agent Communication Protocol / A2A 是"横向"的——一个 Agent 去找另一个 Agent 协作，方向是 Agent↔Agent；Agent Client Protocol 则是"接入层"的——把编程 Agent 接进编辑器，方向是 编辑器↔Agent。
怎样作答最稳
先说"ACP 这个缩写有歧义，对应两个不同协议"，再分别交代 BeeAI/Linux 基金会的 Agent Communication Protocol（Agent↔Agent，类比 A2A）和 Zed 的 Agent Client Protocol（编辑器↔编程 Agent，类比 LSP），最后用 MCP 做层次对照收尾。
常见误区
⚠️ 常见踩坑
最大的坑是把 ACP 当成一个唯一、无歧义的协议直接背定义——它其实是两个不同协议共用的缩写：BeeAI 的 Agent Communication Protocol（Agent↔Agent）和 Zed 的 Agent Client Protocol（编辑器↔编程 Agent），面试官一追问"你说的是哪个 ACP"就容易露怯。另一个误区是把 Agent Communication Protocol 和 MCP 混为一谈：它们解决的是正交问题（Agent↔Agent 协作 vs Agent↔工具取能力）。还要注意别把它和 A2A 说成你死我活的竞争对手——二者定位相近，趋势是整合而非互斥。
追问
追问 1：BeeAI 线的 ACP 强调"本地优先"和"基于 REST"，这两个取向各自带来什么好处？
本地优先（local-first）意味着一个 Agent 可以先在本机或内网以最小依赖跑起来、被发现和调用，不强制先接入某个云端注册中心或专有消息总线。好处是上手门槛低、便于私有化与离线/内网场景，也利于开发期快速联调。
基于 REST/HTTP 的好处是复用成熟生态：开发者用熟悉的 HTTP 动词、状态码、鉴权（如 Bearer Token）和现成的网关、负载均衡、可观测工具就能把 Agent 暴露成普通 Web 服务，几乎零学习成本，集成简单。代价是 REST 的请求-响应范式对"有状态长任务、流式中间进度"这类需求需要额外约定（如轮询或 SSE）来补齐，这也是它和强调长任务建模的 A2A 在细节上的侧重差异之一。
追问 2：既然 ACP 和 A2A 定位这么接近，为什么会出现整合趋势？整合对开发者意味着什么？
因为"Agent 互操作"这件事的价值恰恰来自网络效应——标准越统一，能互相协作的 Agent 越多，生态越值钱；反过来，如果分裂成 ACP、A2A 等多个互不相通的标准，每个 Agent 都要适配多套协议，等于把碎片化成本转嫁给开发者，违背了"互操作"的初衷。所以社区更倾向于向中立组织（如 Linux 基金会）托管并彼此对齐、收敛。
对开发者来说，整合意味着可以减少"押错标准"的风险：短期内做技术选型时，应优先看协议是否归入中立基金会、是否有跨厂商支持，并尽量把协议适配层与业务逻辑解耦，这样即便未来标准合并或演进，也只需替换适配层而不必重写 Agent 本身。
追问 3：如果让你判断一个项目里到底该用 MCP 还是 ACP/A2A，你的依据是什么？
关键看协作方向。如果需求是"让我的 Agent 用上某个工具、数据库、外部 API 或上下文"——即给单个 Agent 接能力，方向是 Agent↔工具，那就用 MCP。如果需求是"让我的 Agent 去找另一个独立的 Agent（可能是别的团队、别的厂商做的）帮忙完成一部分任务并拿回结果"——即 Agent 之间组队，方向是 Agent↔Agent，那就用 ACP/A2A 这类互操作协议。
实践中两者常常同时出现：一个主 Agent 内部用 MCP 调本地工具，对外用 ACP/A2A 把子任务委派给专业同行 Agent。所以这不是二选一，而是按"取能力还是找帮手"分层选用；选 ACP/A2A 时再结合前面说的整合趋势，优先挑生态收敛度高、由中立组织托管的那一支。
🔗 相似问题
同一考点的不同问法，面试官可能换着问，一起刷更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习