在 AI 编程工具快速演进的背景下，开发者生态中开始频繁出现三个协议缩写：LSP、MCP、ACP。它们分别指向不同层级的标准化问题：LSP 解决编辑器与语言分析服务之间的通信，MCP 解决 AI 模型如何调用外部工具与数据，ACP 则尝试规范智能体之间或智能体与编辑器之间的协作方式。
从已有素材看，这三条协议并非相互替代，而是分别对应代码理解、模型扩展和智能体通信三个层面。随着 AI 编程从单点补全走向多智能体协作，下一代开发工具的底层通信结构正在逐渐清晰。
LSP 解决的是代码智能的标准化接入
LSP，即 Language Server Protocol，诞生于 2016 年。当时，微软从 VS Code 中抽离出这套协议，目标是解决编辑器长期重复实现语言智能能力的问题。
在 LSP 出现之前，如果要让不同编辑器支持同一门语言的补全、跳转、诊断等能力，开发者往往需要为每款编辑器分别开发插件。Vim、Emacs、Sublime、Atom、VS Code 等工具各自为政；每新增一门语言，相关编辑器也要重新实现一套能力。
LSP 的做法是将语言理解能力独立为「语言服务器」。编辑器作为客户端，只需实现一次 LSP 协议，就可以对接不同语言服务器。语言服务器则负责处理类型推断、符号跳转、重构分析、错误诊断等代码语义任务。
这套架构基于 JSON-RPC 通信，支持 stdio 和 TCP 等传输方式。素材提到，LSP 定义了数十种标准请求，其中较常用的包括 textDocument/completion、textDocument/definition、textDocument/references、textDocument/hover、textDocument/publishDiagnostics 和 workspace/symbol。
LSP 的意义在于解耦：编辑器专注于界面和交互，语言服务器专注于代码语义。如今，从 Neovim、Zed 到 JetBrains、Cursor，主流编辑器基本都内置了 LSP 支持。素材还提到，2026 年 Laravel 也推出了官方 LSP，用于提供路由、配置、视图路径等更深入的智能提示。
MCP 把「AI 调用工具」变成标准化接口
MCP，即 Model Context Protocol，由 Anthropic 于 2024 年 11 月发布。与 LSP 类似，MCP 也试图解决重复集成问题，只不过对象从「编辑器 × 语言」变成了「AI 应用 × 外部工具」。
素材给出的例子是：如果有 10 个 AI 应用和 100 个外部工具，按传统方式可能需要写 1000 个定制集成；引入 MCP 后，这一数字可以变成 110 个，即 10 个客户端和 100 个服务器。这也是 MCP 常被概括为「N×M 变成 N+M」的原因。
MCP 协议设计者 David Soria Parra 曾提到，MCP 直接借鉴了 LSP 的核心思想。MCP 服务器可以向 AI 客户端暴露三种能力：工具、资源和提示模板。通信同样基于 JSON-RPC，支持本地 stdio 和远程 HTTP 两种传输方式。
从生态进展看，MCP 的采用速度较快。素材称，Claude、ChatGPT、Gemini、Copilot、Cursor、VS Code 均已原生支持 MCP。OpenAI 在 2025 年 3 月宣布支持，Google 在 2025 年 4 月跟进，微软则在 Build 2025 上宣布 Windows 11 原生集成。
到 2026 年，MCP 已经积累了较大规模的使用量，素材提到其月下载量达到 9700 万。同时，MCP 也正在经历一次架构级重构：从有状态会话转向无状态设计。按照素材说法，这意味着 MCP 服务器不再需要「记住」客户端，每个请求可以独立处理，从而提升可扩展性，但现有实现也需要迁移适配。
安全层面的问题也开始显现。素材提到，2026 年 1 月至 4 月间，安全研究者披露了 40 多个 CVE，涉及工具投毒、OAuth 混淆代理攻击等威胁。对于正在进入生产环境的 AI 工具链来说，这类问题值得持续关注。
ACP 指向智能体通信，但仍处于多路线并行阶段
如果说 MCP 解决的是「AI 如何调用工具」，那么 ACP 更关注「AI 如何与 AI 对话」。不过，素材显示，ACP 这个缩写目前对应多条路线，尚未形成单一标准。
第一条路线来自 AgentUnion。2025 年 5 月 9 日，AgentUnion 发布 ACP，即 Agent Communication Protocol，被称为中国首个落地可用的智能体通信协议。素材将其描述为面向智能体互联网基础设施的一套协议，重点覆盖身份、发现、通信、任务与信任等环节。
第二条路线来自 IBM 研究院。该路线同样命名为 Agent Communication Protocol，是 BeeAI 平台的一部分，并归入 Linux Foundation。其目标是让基于 LangChain、CrewAI、Smolagents 等不同框架构建的智能体能够互通。
IBM 路线的 ACP 采用 RESTful 设计，强调异步优先通信、多模态交互、多智能体协作，以及跨框架、跨语言、跨组织协作能力。素材提到，IBM 团队最初曾考虑直接扩展 MCP，但发现 MCP 的设计更偏向模型与工具之间的通信，并不适合多智能体协作场景。
IBM 给出的类比是：MCP 相当于给个人提供更好的工具，例如计算器和参考书；ACP 则相当于支持人们组建团队。换句话说，两者是互补关系，而不是直接竞争关系。
此外，素材还提到，2026 年 Zed 编辑器社区推出了另一个名为 Agent Client Protocol 的 ACP。该协议关注的是 AI 编码智能体与编辑器之间的通信标准化，基于 JSON-RPC 和子进程模型，并兼容 MCP 数据类型。其目标是让不同智能体可以接入支持该协议的编辑器。
目前，已有 30 多个智能体实现了这一协议，素材列举的例子包括 GitHub Copilot、Cursor 和 Kimi CLI。
三协议分别对应开发工具链的三层能力
综合素材信息，可以将三者理解为软件架构中的三层协议：底层是 JSON-RPC、HTTP、stdio 等通信基础；中间层由 LSP 和 MCP 分别承担代码语义分析与模型能力扩展；上层则由 ACP 探索智能体之间或智能体与开发环境之间的协作接口。
- LSP：通信对象是编辑器与语言服务器，核心问题是消除语言与编辑器之间的重复集成。
- MCP：通信对象是 AI 客户端与工具服务器，核心问题是消除模型与工具之间的重复集成。
- ACP：通信对象是智能体之间，或智能体与编辑器之间，核心问题是降低协作壁垒。
素材给出的协同场景是：开发者在 Zed 编辑器中输入 userRepository.findById()，LSP 先提供代码补全和类型信息；MCP 再让 AI 获取数据库结构、项目上下文或相关文档；如果任务更复杂，ACP 可能进一步协调多个智能体完成编码、测试或审查等步骤。
从当前状态看，LSP 已是成熟标准，MCP 生态快速扩张但仍面临架构迁移和安全挑战，ACP 则处于早期探索阶段，存在多条技术路线。对于开发者和工具厂商而言，接下来的关键问题不是在三者之间做单选，而是理解它们各自适配的层级，并在合适的场景中组合使用。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/ai-bian-cheng-gong-ju-lian-zheng-zai-xing-cheng-xin-fen
