2026/9/14 14:46:39
FEATURED · 精选文章 
过去半年我几乎每周都要回答同一个问题MCP、ACP、LSP 到底什么关系哪个是趋势我先学哪个这个问题本身就有迷惑性。三个缩写放在一起看确实像「三国演义」——都是协议都用 JSON-RPC都在 AI 圈里被反复提起。但如果你真去翻源码、跑通一个端到端 demo就会发现它们根本不在同一层MCP 连接的是模型与工具ACP 连接的是编辑器与编程智能体LSP 连接的是编辑器与语言能力。三条赛道各有边界、各有纠缠搞混了就去选型轻则做错架构重则团队内耗半年。这篇文章的目标很直接把三者的定位、工作机制、选型逻辑一次说清楚。适合正在给 AI 应用做工具接入的开发者、想搞懂 Agent 类编辑器插件的客户端工程师以及被各种 MCP Server 刷屏但不知道要不要上的技术决策者。文章不绕弯子不预设你熟悉协议细节但默认你写过代码、见过 JSON。1. 三个协议为什么总被放在一起比它们都在消灭「定制化胶水代码」先说结论这三个协议确实是同一类东西——都是「标准化接口协议」目的都是消灭定制化胶水代码。但它们消灭的是不同场景下的胶水。理解这一点比背任何 API 都重要。1.1 三家协议各自的诞生背景MCPModel Context Protocol由 Anthropic 在 2024 年 11 月发布。起因很朴素Claude 要接外部工具和数据源但每次接入一个数据库、一个 API、一个文件系统都得给那个数据源写一套专属适配器。今天接 Notion 写一套明天接 GitHub 又写一套。MCP 就是把「模型 ↔ 工具」之间的对话方式标准化让工具提供方写一次 Server所有支持 MCP 的模型应用都能直接调用。ACPAgent Client Protocol则要晚一些2025 年 3 月由 Zed 编辑器团队提出背后有 Anthropic 和 OpenAI 参与。它的动机和 MCP 完全不同MCP 解决的是 Agent 怎么调工具ACP 解决的是编辑器怎么调 Agent。当时 Claude Code、Codex CLI、Gemini CLI 这类 agentic 编程工具爆发每个都是命令行工具各有各的交互方式。用户想在 Zed、VS Code、Neovim 里使用这些 Agent就得为每个编辑器 × 每个 Agent 写一遍插件适配。ACP 把「编辑器 ↔ 编程智能体」的通道标准化让编辑器只需要实现一个 ACP 客户端就能对接所有支持 ACP 的 Agent。LSPLanguage Server Protocol是三者里的老前辈2016 年由微软提出最初是为了 VS Code。它要解决的问题是以前每一种编程语言要在编辑器里有补全、跳转、重命名、报错提示都得专门写一个编辑器插件。TypeScript 一个插件、Python 一个插件、Go 一个插件。LSP 出现后语言作者只需要写一个「语言服务器」所有编辑器都能复用。VS Code、Neovim、Emacs、Sublime 都支持 LSP一套语言服务到处用。背景一摆就清楚了MCP 出生在「AI 要连接世界」的需求ACP 出生在「人要换着用 AI」的需求LSP 出生在「编辑器要支持各种语言」的需求。三者的出生原因没有任何重叠只是恰好都在 2024-2025 年的 AI 浪潮里被重新放大。1.2 容易混淆的根本原因都用了 JSON-RPC 2.0一个很多人忽略的细节是这三个协议全部基于 JSON-RPC 2.0。JSON-RPC 2.0 是一个极简的远程调用规范请求是一个 JSON 对象包含jsonrpc: 2.0、method、params、id响应包含result或error。就这么点东西没有复杂的传输层约束stdio、HTTP、WebSocket 都能跑。三个协议选同一个底层规范纯粹是「英雄所见略同」不是谁抄谁。JSON-RPC 2.0 轻量、无状态、跨语言友好特别适合做进程间工具调用。就好比三个国家修铁路不约而同选了同一种轨距但目的地的路线完全不同。这个共性带来的副作用是如果你只看报文会觉得三者长得一模一样——都是 JSON 里套 method、套 params、套 id。所以很多人误以为它们能互相替代。实际上协议栈的分层决定了它们的职责边界JSON-RPC 只是「信封」信封里装的是 MCP 的工具调用语义、ACP 的会话管理语义还是 LSP 的文本同步语义完全不是一回事。1.3 认清层级模型接入、Agent 接入、编辑器接入是三条赛道我习惯用一个「物流公司」的类比来理解三者层级。假设你是一家货运公司LSP 解决的是「仓库内部的货架管理」——东西放在哪、长什么样、怎么分类。编辑器就是仓库LSP 让语言服务器把代码的语义信息符号、类型、引用关系高效地摆上货架编辑器随时可以查。MCP 解决的是「仓库和外部供应商之间的订单对接」——模型需要调工具、取数据MCP 是统一下单接口让卡车工具按统一规格送货上门。ACP 解决的是「客户怎么下单给货运公司」——你的编辑器是客户前台ACP 是让客户可以用同一个下单界面对接不同货运公司Claude Code、Codex CLI、Gemini CLI。可以看出LSP 在最底层做语义理解MCP 在中层做工具执行ACP 在最外层做 Agent 交互。三层可以组合在一起用也可以独立使用但绝对不存在「有了 MCP 就不需要 LSP」这种说法。MCP 不会帮你做代码补全LSP 也不会帮你调外部 APIACP 更不会替你决定用哪个模型。2. MCP给模型开「万能插座」让工具主动找上门MCP 是三个协议里生态扩张最猛的一个已经有大量厂商跟进。这一节讲清楚它的架构、核心概念和一个完整落地案例。2.1 MCP 要解决的问题每次接一个数据源就要写一套适配器没有 MCP 之前AI 应用接工具的痛点是 N×M 问题N 个 AI 应用Claude、IDE 插件、自研 Agent× M 个工具数据库、内部 API、设计软件、安全测试平台每个组合都要写一套适配器。适配器不仅仅是「调个 API」还要处理鉴权、参数格式转换、错误映射、上下文如何注入模型工作量非常大。MCP 的解法是把工具提供方改造成 MCP ServerAI 应用侧只要实现 MCP Client就能发现并调用所有符合规范的 Server。我用 USB-C 类比讲过很多次以前每个设备有专属充电线现在一个 USB-C 口通吃。MCP 就是 AI 世界的 USB-C。2.2 MCP 的架构与核心概念Host、Client、Server 与「工具/资源/提示词」MCP 有三个角色MCP Host运行模型的应用程序比如 Claude Desktop、Cursor、自研 Agent。MCP ClientHost 内部负责与 Server 通信的组件一个 Host 可以挂多个 Client。MCP Server暴露工具、数据、提示词的外部程序通常是一个独立进程。MCP 定义了四类核心原语Tools模型可以主动调用的函数执行需要「动手」的操作比如查天气、写数据库、提交订单。Tool 是 MCP 最核心的部分。Resources只读数据源比如文件内容、数据库查询结果。模型可以把 Resource 作为上下文读取但不能修改。Prompts可复用的提示词模板由 Server 提供Host 可以渲染给用户选用。SamplingServer 反过来请求 Host 调用模型补全内容实现「Server 主动问模型要答案」的双向交互。传输层上MCP 早期主要走 stdio标准输入输出适合本地进程后来加上了 Streamable HTTP方便远程部署。调试时用 stdio 最简单部署到生产环境再切 HTTP。发一个tools/list请求就能看到 Server 暴露了哪些工具这是 MCP 相比传统 SDK 接入最爽的一点——不需要预先知道工具清单运行时动态发现。也就是说你接一个新工具不需要改 Host 代码只要给 Host 配上新的 Server。2.3 实测把自己开发的 REST 接口发布成 MCP Server网上关于 MCP 的教程很多都停留在「给别人配好的 Server」这里我演示一下如何把自研接口发布成 MCP Server。官方 SDK 支持 TypeScript、Python、Java、Kotlin、C# 等语言我用 TypeScript 的modelcontextprotocol/sdk举例import { McpServer } from modelcontextprotocol/sdk/server/mcp.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; import { z } from zod; const server new McpServer({ name: my-rest-api, version: 1.0.0, }); server.tool( get_user, { userId: z.string().describe(用户ID) }, async ({ userId }) { const res await fetch(https://api.example.com/users/${userId}); const data await res.json(); return { content: [{ type: text, text: JSON.stringify(data) }], }; } ); const transport new StdioServerTransport(); await server.connect(transport);把这段代码跑起来再在 Claude Desktop或其他支持 MCP 的客户端里配置{ mcpServers: { my-rest-api: { command: node, args: [path/to/mcp-server.js] } } }重启客户端模型就能发现get_user这个工具并在对话中调用。整个过程不需要改任何业务后端代码REST 接口原封不动MCP Server 只是套了一层「翻译层」。用 Java 栈的话Spring AI 1.0 之后直接支持 MCP Server 的声明式开发加个注解就能把Tool方法暴露成 MCP 工具不用手写 JSON-RPC 解析。这类框架的成熟度已经有明显加速Java 把 REST 接口发布为 MCP 的问题是当前社区问得最多的。2.4 MCP 生态里那些让人眼前一亮的东西MCP 生态已经远远超出「接数据库」这类基础场景。从最新的一批 Server 能明显看出行业渗透的广度设计领域Figma MCP、蓝湖 MCPAI 可以直接读取设计稿结构生成代码或标注。3D 建模Blender MCP让 AI 操作 Blender 生成模型、改材质设计师可以用自然语言做参数化建模。安全测试Burp Suite MCP、Yakit MCP把渗透测试工具的操作接口标准化安全人员可以让 AI 辅助完成扫描和报文分析。工业软件CATIA MCP传统的 CAD/CAE 软件也开始向 AI 开放操作能力。编程工具Chrome DevTools MCP、Codex MCP浏览器调试和 AI 编程工具都在接入。我的判断是MCP 正在成为「AI 操作一切」的事实标准。因为它的设计哲学非常简单——Server 只需要声明自己有什么模型负责决定怎么用。这种模式天然适合工具生态的爆炸式增长。3. ACP把「编程智能体」从 IDE 里解放出来如果说 MCP 是「模型伸手够世界」那 ACP 就是「编辑器伸手接 Agent」。它解决的问题稍晚出现但同样刚需。3.1 ACP 的定位客户端是编辑器服务端是 Agent2025 年最明显的变化是编程范式从「IDE 插件自动补全」转向「Agent 自主编程」。Claude Code、Codex CLI、Gemini CLI 这类工具不再只是补全几行代码而是能端到端地读仓库、改文件、跑测试、提交 PR。问题来了这些 Agent 都是命令行工具用户要么用它们自带的终端 UI要么就得在编辑器里靠厂商提供的专属插件接入。我想在 Zed 里用 Claude Code又在 VS Code 里用 Codex就得装两套插件、维护两套配置。更麻烦的是每个编辑器插件与 Agent 的通信格式都是私有实现换一个 Agent 就得改一遍。ACP 的解法是把「编辑器 ↔ 编程智能体」这一层标准化。编辑器作为 ACP ClientAgent 作为 ACP Server协议统一管理会话创建、消息传送、工具注册、事件通知。Zed 是第一个落地 ACP 的编辑器opencode 等一些 AI 原生编辑器也在跟进。3.2 ACP 的会话模型与工具调用机制ACP 的核心概念是 Session一个 Session 对应编辑器里一次 Agent 交互。大致流程是编辑器向 Agent 发送initialize协商协议版本与能力。编辑器请求session/new创建会话可以附带初始消息比如用户选中的代码片段。会话创建后通过message/append追加用户消息Agent 返回message/request或事件通知。Agent 内部自主规划与执行编辑器实时接收状态更新、工具调用记录、文件变更事件。用户在编辑器中看到的是类似聊天的界面底层走的全部是标准化的 JSON-RPC 消息。ACP 里的 Tool 概念和 MCP 的 Tool 不同。ACP 的 Tool 是「Agent 暴露给编辑器」的能力比如 Agent 可以通知编辑器「我准备读取文件」「我准备运行测试」编辑器可以将这些操作展示给用户审批而 MCP 的 Tool 是「模型能调用的外部功能」。两者层级不同不要混淆。协议里还有一个很有意思的设计是 Attachment——编辑器可以把代码选区、终端输出、图片快照等上下文附加到消息里让 Agent 能拿到编辑器侧的最新状态而不只是聊天文本。3.3 一个高频踩坑现场Failed to initialize ACP session这段时间在社区里看到一个高频报错failed to initialize acp session. error: internal error: already initialize正好可以作为排查案例。我在本地复现了一次。环境是 opencode 配置了 ACP 作为客户端同时装了两个扩展一个用于对接 Claude Code一个用于对接 Codex。启动后出现这个报错。排查链路如下第一步看日志。opencode 有详细日志开关开启后发现两个扩展在启动阶段都往同一个 ACP Server 地址发了initialize请求。第二步抓报文。用代理把 ACP 的 JSON-RPC 流量打印出来确认第二次initialize是重复的。第三步读协议实现。ACP Server 端的状态机设计里initialize只能成功一次初始化完成后再次收到会返回internal error: already initialize。这就是根因——不是 Agent 崩了是客户端重复初始化把状态机搞乱了。解决方式也很直接只保留一个 ACP provider或者给两个扩展配置不同的 Agent 地址。社区里还有一类情况是配置文件里同时写了acp和agent两类配置启动时初始化了两次清理掉冗余配置即可。这类报错的启示是ACP 目前还非常年轻实现方对协议边界的理解有出入。用一个客户端同时连多个 Agent如果这个客户端没有做好 Session 隔离很容易踩重复初始化的坑。建议在实际项目中把 ACP 版本和 Agent 版本固定下来升级前先看 changelog。3.4 ACP 与 MCP 的配合关系很多人的疑问是有了 ACP还用得着 MCP 吗答案是两者配合使用而且链路很长一条IDE ←ACP→ Agent ←MCP→ 外部工具。以 Claude Code 为例如果你在 Zed 里通过 ACP 接入了 Claude Code那么 Claude Code 本身是一个 MCP Host可以挂各种 MCP Server 来调用数据库、浏览器、内部 API。编辑器通过 ACP 与 Claude Code 交互用户看到的只是编辑器界面Claude Code 通过 MCP 去操作外部工具用户能看到工具调用的过程展示。所以 ACP 与 MCP 不是竞争关系而是上下游关系。ACP 管「人 ↔ Agent」的连接MCP 管「Agent ↔ 工具」的连接。而 LSP 管「编辑器 ↔ 代码语义」的连接Agent 在执行任务时也可以借助 LSP 获取代码上下文。三个协议完全可以串成一条完整的 AI 编程链路。4. LSP八年前的老协议在 AI 时代反而焕发第二春聊完两个新协议回到 LSP。很多人以为它只是「老一辈编辑器协议」跟 AI 关系不大这是一个严重的误判。4.1 LSP 的原始设计让每一种语言都有一等一的编辑体验LSP 出现之前编辑器对语言的支持是一个个插件堆出来的。以最典型的 VS Code 为例如果想让编辑器支持 TypeScript需要写补全、诊断、跳转、重命名等几十个功能模块再想支持 Python又要写一遍。每种语言 × 每个编辑器 巨大的重复劳动。LSP 把这个模型彻底改了语言作者只需要实现一个 Language Server通过标准化的 JSON-RPC 与编辑器通信。编辑器实现一套 LSP Client就能获得所有语言服务器的能力。你可以在 VS Code 里用rust-analyzer在 Neovim 里也用rust-analyzer体验几乎一样。这就是「一次实现到处运行」在编程工具领域的落地。4.2 LSP 的工作方式编辑器与语言服务器的「一问一答」LSP 的通信模型是典型的客户端-服务器架构。编辑器是客户端语言服务器是独立进程通信走 stdio 或 TCP内容同样是 JSON-RPC 2.0。生命周期是这样的编辑器启动后发送initialize请求协商能力接着发送initialized通知告知服务器「我已经准备好了」。之后编辑器持续同步文档状态textDocument/didOpen通知服务器「这个文件打开了」textDocument/didChange通知「内容改了」。服务器根据需要返回补全、诊断等信息比如{ jsonrpc: 2.0, id: 3, method: textDocument/completion, params: { textDocument: { uri: file:///workspace/main.py }, position: { line: 10, character: 16 } } }语言服务器收到后返回一个补全列表包含候选标识符、类型、文档说明。整个过程不需要编辑器内置任何语言逻辑它只负责展示。对 AI 编程工具来说这套机制的价值在于LSP 可以提供结构化的语义数据而不是原始的文本。模型拿到「这个变量类型是User」「这个函数签名是createUser(name, email)」这种结构化信息比让它自己从文本里猜精准得多。4.3 AI 编程工具为什么回头拥抱 LSP过去一年AI 编程工具开始大量利用 LSP。opencode 的文档里明确写了如何把 LSP 作为代码上下文采集器编辑器把打开的文档同步给语言服务器获取 hover 信息、定义位置、诊断错误再打包成上下文喂给模型。这就是「opencode 如何使用 LSP」这个搜索量暴涨的原因。LSP 与 AI 编程工具的结合点主要有三个语义级上下文模型看到的不只是代码文本还包括类型信息、引用关系、错误诊断回答更准确。实时诊断反馈Agent 改完代码后通过 LSP 拉取最新的诊断结果相当于拿到了「自测」信号不用等编译或 lint。跨语言能力复用Agent 要支持新语言时不需要重写解析逻辑直接接入对应的 Language Server 即可。LSP 是「读」的协议它替模型把代码语义嚼碎了而 MCP 是「做」的协议它让模型能改文件、跑命令、调 API。没有 LSPAI 编程像蒙眼开车没有 MCPAI 编程像有眼但没手。两者互补不是替代。4.4 LSP 能做的事与不能做的事LSP 能做的补全、定义跳转、查找引用、重命名、hover 文档、诊断错误、代码格式化、代码操作。这些都是「理解代码」层面的能力。LSP 做不了的执行代码、修改文件系统、调用外部 API、访问数据库。虽然 LSP 规范里定义了workspace/executeCommand语言服务器可以通过命令执行一些编辑器动作但它的设计边界始终是「语义服务」不是「执行引擎」。这里有一个很多人踩过的坑试图把业务逻辑塞进 Language Server让 LSP 充当应用后端。LSP 进程通常由编辑器按工作区管理生命周期和编辑器绑定不适合承载长任务、有状态业务或需要外部依赖的服务。业务能力应该通过 MCP 暴露LSP 只负责代码理解。顺带说一句LSP 这个缩写在其他领域另有含义比如通信网络里的标签交换路径。本文讨论的内容只指 Language Server Protocol网上搜资料时注意区分。5. 三足鼎立还是各管一段用一张表划清边界把三个协议放在一张表里对比边界会非常清晰。以下是我在实际项目里总结的对比维度比官方文档的抽象描述更好用。5.1 从「连接对象」看三者分工维度MCPACPLSP连接的双方模型/Agent ↔ 外部工具与数据源编辑器客户端 ↔ 编程智能体编辑器 ↔ 语言服务器典型使用场景AI 调用数据库、API、浏览器、设计软件IDE 内使用 Claude Code、Codex、Gemini CLI编辑器补全、诊断、跳转、重构核心角色Host、Client、ServerClient编辑器、Agent ServerClient编辑器、Language Server消息方向模型主动调工具编辑器与 Agent 双向会话编辑器发查询服务器返回语义传输方式stdio / Streamable HTTPstdio / HTTP实现相关stdio / TCP / WebSocket代表实现Claude Desktop、Spring AI、多语言 SDKZed、opencode、Claude CodeVS Code、Neovim、pyright、rust-analyzer成熟度快速迭代生态爆发早期标准仍在演进非常成熟生态最稳定这张表有一个值得注意的点LSP 的「成熟度」最高因为它在 2024 年前就积累了八年生态MCP 的「发展速度」最快因为 AI 工具接入需求急剧扩张ACP 最年轻应用面目前还集中在编程场景。5.2 从「主动方是谁」看三者定位差异理解一个协议关键是搞清楚「谁主动、谁被动」。MCP 里主动权在模型。模型决定什么时候调用哪个工具、传什么参数、如何组合多个工具完成目标。Server 处于被动响应状态它不知道模型下一步要干什么。ACP 里主动权在编辑器端。用户发消息触发会话流转但会话内部 Agent 有相当高的自主决策权——它可以决定先读哪个文件、要不要运行测试、什么时候结束。ACP 的设计意图本来就是「把 Agent 的自主性封装在标准化通道里」。LSP 里主动权完全在编辑器。编辑器决定什么时候请求补全、什么时候同步文档、什么时候关闭会话。语言服务器不会主动「建议」什么它只对请求做响应。这三个主动方模型决定了它们的应用模式MCP 适合做工具开放平台ACP 适合做 Agent 统一入口LSP 适合做编辑器基础设施。5.3 从「成熟度 vs 发展速度」看未来趋势判断一个协议值不值得投入我习惯同时看两个指标当前成熟度和演进速度。LSP 的成熟度很高但演进速度慢。规范已经稳定社区重心是维护现有实现不会出现破坏性变更。对于要长期维护的工具链选 LSP 最稳妥。MCP 的成熟度中等但演进速度极快。规范本身比较稳定但生态每天都在新增 Server 和 SDK 功能。风险在于社区容易出现「封装过头」的二次标准选型时要紧盯官方 spec避免被厂商私有扩展绑定。ACP 的成熟度最低演进速度也最快。它目前最大的不确定性是「标准化能不能跑赢市场」。如果头部 Agent 厂商决定各自为战ACP 就可能沦为小众协议但目前 Anthropic、OpenAI 都参与了制定说明行业有统一意愿。我的建议是关注但不押注先小范围验证。6. 实战选型与组合架构我该怎么用这三个协议前面讲原理这一节讲落地。我给出一个经过多个项目验证的判断框架和三种典型架构。6.1 判断框架先回答四个问题在决定接哪个协议之前先回答这四个问题你的用户是谁是终端用户用编辑器还是模型直接操作工具用户决定了协议的最终交互面。你的核心能力是「读懂代码」还是「操作外部系统」前者走 LSP后者走 MCP。你希望用户能在一款编辑器里切换多个 Agent 后端吗如果是走 ACP。你的团队能接受新协议的演进风险吗如果做的是内部工具可以激进做商业产品则要控制依赖面。回答完这四个问题多数选型困惑都能解开。6.2 三种典型组合架构第一种IDE LSP MCP给传统编辑器加 AI 能力。编辑器通过 LSP 获取代码语义通过 MCP Server 接入外部知识库或工具。这是目前插件型 AI 编程助手最常用的架构风险和成本都最低。第二种IDE ACP Agent用编辑器承载编程智能体。用户在 VS Code、Zed 或其他编辑器里通过 ACP 连接 Claude Code 或 Codex。这种架构下LSP 通常由 Agent 进程内部使用来理解代码MCP 由 Agent 挂载来执行操作。你可以用编辑器界面享受 Agent 的完整能力同时保留编辑器的快捷键、多光标、插件生态。第三种Agent 原生 MCP不依赖编辑器。直接在终端使用 Claude Code、Codex CLI通过 MCP 挂载内部工具。这是当前 CLI Agent 用户的主流方案轻量、直接、调试方便。三种架构可以互相嵌套。我自己常用的组合是在 VS Code 里写代码LSP 负责语义服务开一个 Zed 通过 ACP 连 Claude Code 跑长任务Claude Code 挂了 5 个 MCP Server 接内网知识库和测试平台。听起来复杂但每条链路都是标准协议没有一条需要写私有适配器。6.3 避坑建议与个人经验最后分享几条从实际项目里踩出来的经验。MCP 的坑主要在权限和安全。MCP Server 暴露给模型的工具相当于把内部系统开放给 AI如果 Server 没有做鉴权任何能调用模型的人都可能间接访问你的数据。我见过有团队把带数据库账号密码的环境变量写进 MCP Server 代码这等于把钥匙放在门垫底下。一定要给每个 MCP Server 做最小权限设计生产环境用 HTTP 传输务必启用身份认证。ACP 的坑主要在版本和兼容性。作为一个新兴协议ACP 的破坏性变更比较频繁。某个 Client 版本支持的 method 映射换一个 Agent 版本可能就不认了。建议把 Client 和 Agent 都锁定版本升级前跑一遍全量回归别在周五下午升级。LSP 的坑主要在性能和资源占用。一个大型 Monorepo 里可能同时挂多个 Language Server每个都要吃掉几百 MB 内存。AI Agent 频繁请求语义上下文时LSP 响应延迟会成为瓶颈。优化办法是只对 Agent 真正关心的文件开 LSP 会话不要全仓库扫描。另外关于「Agent Skill 和 MCP 有什么区别」这类高频问题我的理解是Skill 是 Agent 内部的能力包定义的是「特定任务怎么做」比如某个 Agent 内置的代码评审流程MCP 是跨 Agent 的工具接入标准定义的是「外部工具怎么被调用」。两者不是替代关系Skill 强调流程编排MCP 强调工具互通。如果只让我说一条最重要的经验那就是协议是手段不是目的。MCP、ACP、LSP 都是为了让 AI 生态的连接更标准化而生的你的架构只要遵循「职责分层」原则——LSP 管理解、MCP 管执行、ACP 管交互——就不会在大方向上出错。剩下的事情就是边踩坑、边迭代、边看社区怎么演进。
MCP、ACP、LSP三大协议深度解析：定位、区别与选型指南
过去半年我几乎每周都要回答同一个问题MCP、ACP、LSP 到底什么关系哪个是趋势我先学哪个这个问题本身就有迷惑性。三个缩写放在一起看确实像「三国演义」——都是协议都用 JSON-RPC都在 AI 圈里被反复提起。但如果你真去翻源码、跑通一个端到端 demo就会发现它们根本不在同一层MCP 连接的是模型与工具ACP 连接的是编辑器与编程智能体LSP 连接的是编辑器与语言能力。三条赛道各有边界、各有纠缠搞混了就去选型轻则做错架构重则团队内耗半年。这篇文章的目标很直接把三者的定位、工作机制、选型逻辑一次说清楚。适合正在给 AI 应用做工具接入的开发者、想搞懂 Agent 类编辑器插件的客户端工程师以及被各种 MCP Server 刷屏但不知道要不要上的技术决策者。文章不绕弯子不预设你熟悉协议细节但默认你写过代码、见过 JSON。1. 三个协议为什么总被放在一起比它们都在消灭「定制化胶水代码」先说结论这三个协议确实是同一类东西——都是「标准化接口协议」目的都是消灭定制化胶水代码。但它们消灭的是不同场景下的胶水。理解这一点比背任何 API 都重要。1.1 三家协议各自的诞生背景MCPModel Context Protocol由 Anthropic 在 2024 年 11 月发布。起因很朴素Claude 要接外部工具和数据源但每次接入一个数据库、一个 API、一个文件系统都得给那个数据源写一套专属适配器。今天接 Notion 写一套明天接 GitHub 又写一套。MCP 就是把「模型 ↔ 工具」之间的对话方式标准化让工具提供方写一次 Server所有支持 MCP 的模型应用都能直接调用。ACPAgent Client Protocol则要晚一些2025 年 3 月由 Zed 编辑器团队提出背后有 Anthropic 和 OpenAI 参与。它的动机和 MCP 完全不同MCP 解决的是 Agent 怎么调工具ACP 解决的是编辑器怎么调 Agent。当时 Claude Code、Codex CLI、Gemini CLI 这类 agentic 编程工具爆发每个都是命令行工具各有各的交互方式。用户想在 Zed、VS Code、Neovim 里使用这些 Agent就得为每个编辑器 × 每个 Agent 写一遍插件适配。ACP 把「编辑器 ↔ 编程智能体」的通道标准化让编辑器只需要实现一个 ACP 客户端就能对接所有支持 ACP 的 Agent。LSPLanguage Server Protocol是三者里的老前辈2016 年由微软提出最初是为了 VS Code。它要解决的问题是以前每一种编程语言要在编辑器里有补全、跳转、重命名、报错提示都得专门写一个编辑器插件。TypeScript 一个插件、Python 一个插件、Go 一个插件。LSP 出现后语言作者只需要写一个「语言服务器」所有编辑器都能复用。VS Code、Neovim、Emacs、Sublime 都支持 LSP一套语言服务到处用。背景一摆就清楚了MCP 出生在「AI 要连接世界」的需求ACP 出生在「人要换着用 AI」的需求LSP 出生在「编辑器要支持各种语言」的需求。三者的出生原因没有任何重叠只是恰好都在 2024-2025 年的 AI 浪潮里被重新放大。1.2 容易混淆的根本原因都用了 JSON-RPC 2.0一个很多人忽略的细节是这三个协议全部基于 JSON-RPC 2.0。JSON-RPC 2.0 是一个极简的远程调用规范请求是一个 JSON 对象包含jsonrpc: 2.0、method、params、id响应包含result或error。就这么点东西没有复杂的传输层约束stdio、HTTP、WebSocket 都能跑。三个协议选同一个底层规范纯粹是「英雄所见略同」不是谁抄谁。JSON-RPC 2.0 轻量、无状态、跨语言友好特别适合做进程间工具调用。就好比三个国家修铁路不约而同选了同一种轨距但目的地的路线完全不同。这个共性带来的副作用是如果你只看报文会觉得三者长得一模一样——都是 JSON 里套 method、套 params、套 id。所以很多人误以为它们能互相替代。实际上协议栈的分层决定了它们的职责边界JSON-RPC 只是「信封」信封里装的是 MCP 的工具调用语义、ACP 的会话管理语义还是 LSP 的文本同步语义完全不是一回事。1.3 认清层级模型接入、Agent 接入、编辑器接入是三条赛道我习惯用一个「物流公司」的类比来理解三者层级。假设你是一家货运公司LSP 解决的是「仓库内部的货架管理」——东西放在哪、长什么样、怎么分类。编辑器就是仓库LSP 让语言服务器把代码的语义信息符号、类型、引用关系高效地摆上货架编辑器随时可以查。MCP 解决的是「仓库和外部供应商之间的订单对接」——模型需要调工具、取数据MCP 是统一下单接口让卡车工具按统一规格送货上门。ACP 解决的是「客户怎么下单给货运公司」——你的编辑器是客户前台ACP 是让客户可以用同一个下单界面对接不同货运公司Claude Code、Codex CLI、Gemini CLI。可以看出LSP 在最底层做语义理解MCP 在中层做工具执行ACP 在最外层做 Agent 交互。三层可以组合在一起用也可以独立使用但绝对不存在「有了 MCP 就不需要 LSP」这种说法。MCP 不会帮你做代码补全LSP 也不会帮你调外部 APIACP 更不会替你决定用哪个模型。2. MCP给模型开「万能插座」让工具主动找上门MCP 是三个协议里生态扩张最猛的一个已经有大量厂商跟进。这一节讲清楚它的架构、核心概念和一个完整落地案例。2.1 MCP 要解决的问题每次接一个数据源就要写一套适配器没有 MCP 之前AI 应用接工具的痛点是 N×M 问题N 个 AI 应用Claude、IDE 插件、自研 Agent× M 个工具数据库、内部 API、设计软件、安全测试平台每个组合都要写一套适配器。适配器不仅仅是「调个 API」还要处理鉴权、参数格式转换、错误映射、上下文如何注入模型工作量非常大。MCP 的解法是把工具提供方改造成 MCP ServerAI 应用侧只要实现 MCP Client就能发现并调用所有符合规范的 Server。我用 USB-C 类比讲过很多次以前每个设备有专属充电线现在一个 USB-C 口通吃。MCP 就是 AI 世界的 USB-C。2.2 MCP 的架构与核心概念Host、Client、Server 与「工具/资源/提示词」MCP 有三个角色MCP Host运行模型的应用程序比如 Claude Desktop、Cursor、自研 Agent。MCP ClientHost 内部负责与 Server 通信的组件一个 Host 可以挂多个 Client。MCP Server暴露工具、数据、提示词的外部程序通常是一个独立进程。MCP 定义了四类核心原语Tools模型可以主动调用的函数执行需要「动手」的操作比如查天气、写数据库、提交订单。Tool 是 MCP 最核心的部分。Resources只读数据源比如文件内容、数据库查询结果。模型可以把 Resource 作为上下文读取但不能修改。Prompts可复用的提示词模板由 Server 提供Host 可以渲染给用户选用。SamplingServer 反过来请求 Host 调用模型补全内容实现「Server 主动问模型要答案」的双向交互。传输层上MCP 早期主要走 stdio标准输入输出适合本地进程后来加上了 Streamable HTTP方便远程部署。调试时用 stdio 最简单部署到生产环境再切 HTTP。发一个tools/list请求就能看到 Server 暴露了哪些工具这是 MCP 相比传统 SDK 接入最爽的一点——不需要预先知道工具清单运行时动态发现。也就是说你接一个新工具不需要改 Host 代码只要给 Host 配上新的 Server。2.3 实测把自己开发的 REST 接口发布成 MCP Server网上关于 MCP 的教程很多都停留在「给别人配好的 Server」这里我演示一下如何把自研接口发布成 MCP Server。官方 SDK 支持 TypeScript、Python、Java、Kotlin、C# 等语言我用 TypeScript 的modelcontextprotocol/sdk举例import { McpServer } from modelcontextprotocol/sdk/server/mcp.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; import { z } from zod; const server new McpServer({ name: my-rest-api, version: 1.0.0, }); server.tool( get_user, { userId: z.string().describe(用户ID) }, async ({ userId }) { const res await fetch(https://api.example.com/users/${userId}); const data await res.json(); return { content: [{ type: text, text: JSON.stringify(data) }], }; } ); const transport new StdioServerTransport(); await server.connect(transport);把这段代码跑起来再在 Claude Desktop或其他支持 MCP 的客户端里配置{ mcpServers: { my-rest-api: { command: node, args: [path/to/mcp-server.js] } } }重启客户端模型就能发现get_user这个工具并在对话中调用。整个过程不需要改任何业务后端代码REST 接口原封不动MCP Server 只是套了一层「翻译层」。用 Java 栈的话Spring AI 1.0 之后直接支持 MCP Server 的声明式开发加个注解就能把Tool方法暴露成 MCP 工具不用手写 JSON-RPC 解析。这类框架的成熟度已经有明显加速Java 把 REST 接口发布为 MCP 的问题是当前社区问得最多的。2.4 MCP 生态里那些让人眼前一亮的东西MCP 生态已经远远超出「接数据库」这类基础场景。从最新的一批 Server 能明显看出行业渗透的广度设计领域Figma MCP、蓝湖 MCPAI 可以直接读取设计稿结构生成代码或标注。3D 建模Blender MCP让 AI 操作 Blender 生成模型、改材质设计师可以用自然语言做参数化建模。安全测试Burp Suite MCP、Yakit MCP把渗透测试工具的操作接口标准化安全人员可以让 AI 辅助完成扫描和报文分析。工业软件CATIA MCP传统的 CAD/CAE 软件也开始向 AI 开放操作能力。编程工具Chrome DevTools MCP、Codex MCP浏览器调试和 AI 编程工具都在接入。我的判断是MCP 正在成为「AI 操作一切」的事实标准。因为它的设计哲学非常简单——Server 只需要声明自己有什么模型负责决定怎么用。这种模式天然适合工具生态的爆炸式增长。3. ACP把「编程智能体」从 IDE 里解放出来如果说 MCP 是「模型伸手够世界」那 ACP 就是「编辑器伸手接 Agent」。它解决的问题稍晚出现但同样刚需。3.1 ACP 的定位客户端是编辑器服务端是 Agent2025 年最明显的变化是编程范式从「IDE 插件自动补全」转向「Agent 自主编程」。Claude Code、Codex CLI、Gemini CLI 这类工具不再只是补全几行代码而是能端到端地读仓库、改文件、跑测试、提交 PR。问题来了这些 Agent 都是命令行工具用户要么用它们自带的终端 UI要么就得在编辑器里靠厂商提供的专属插件接入。我想在 Zed 里用 Claude Code又在 VS Code 里用 Codex就得装两套插件、维护两套配置。更麻烦的是每个编辑器插件与 Agent 的通信格式都是私有实现换一个 Agent 就得改一遍。ACP 的解法是把「编辑器 ↔ 编程智能体」这一层标准化。编辑器作为 ACP ClientAgent 作为 ACP Server协议统一管理会话创建、消息传送、工具注册、事件通知。Zed 是第一个落地 ACP 的编辑器opencode 等一些 AI 原生编辑器也在跟进。3.2 ACP 的会话模型与工具调用机制ACP 的核心概念是 Session一个 Session 对应编辑器里一次 Agent 交互。大致流程是编辑器向 Agent 发送initialize协商协议版本与能力。编辑器请求session/new创建会话可以附带初始消息比如用户选中的代码片段。会话创建后通过message/append追加用户消息Agent 返回message/request或事件通知。Agent 内部自主规划与执行编辑器实时接收状态更新、工具调用记录、文件变更事件。用户在编辑器中看到的是类似聊天的界面底层走的全部是标准化的 JSON-RPC 消息。ACP 里的 Tool 概念和 MCP 的 Tool 不同。ACP 的 Tool 是「Agent 暴露给编辑器」的能力比如 Agent 可以通知编辑器「我准备读取文件」「我准备运行测试」编辑器可以将这些操作展示给用户审批而 MCP 的 Tool 是「模型能调用的外部功能」。两者层级不同不要混淆。协议里还有一个很有意思的设计是 Attachment——编辑器可以把代码选区、终端输出、图片快照等上下文附加到消息里让 Agent 能拿到编辑器侧的最新状态而不只是聊天文本。3.3 一个高频踩坑现场Failed to initialize ACP session这段时间在社区里看到一个高频报错failed to initialize acp session. error: internal error: already initialize正好可以作为排查案例。我在本地复现了一次。环境是 opencode 配置了 ACP 作为客户端同时装了两个扩展一个用于对接 Claude Code一个用于对接 Codex。启动后出现这个报错。排查链路如下第一步看日志。opencode 有详细日志开关开启后发现两个扩展在启动阶段都往同一个 ACP Server 地址发了initialize请求。第二步抓报文。用代理把 ACP 的 JSON-RPC 流量打印出来确认第二次initialize是重复的。第三步读协议实现。ACP Server 端的状态机设计里initialize只能成功一次初始化完成后再次收到会返回internal error: already initialize。这就是根因——不是 Agent 崩了是客户端重复初始化把状态机搞乱了。解决方式也很直接只保留一个 ACP provider或者给两个扩展配置不同的 Agent 地址。社区里还有一类情况是配置文件里同时写了acp和agent两类配置启动时初始化了两次清理掉冗余配置即可。这类报错的启示是ACP 目前还非常年轻实现方对协议边界的理解有出入。用一个客户端同时连多个 Agent如果这个客户端没有做好 Session 隔离很容易踩重复初始化的坑。建议在实际项目中把 ACP 版本和 Agent 版本固定下来升级前先看 changelog。3.4 ACP 与 MCP 的配合关系很多人的疑问是有了 ACP还用得着 MCP 吗答案是两者配合使用而且链路很长一条IDE ←ACP→ Agent ←MCP→ 外部工具。以 Claude Code 为例如果你在 Zed 里通过 ACP 接入了 Claude Code那么 Claude Code 本身是一个 MCP Host可以挂各种 MCP Server 来调用数据库、浏览器、内部 API。编辑器通过 ACP 与 Claude Code 交互用户看到的只是编辑器界面Claude Code 通过 MCP 去操作外部工具用户能看到工具调用的过程展示。所以 ACP 与 MCP 不是竞争关系而是上下游关系。ACP 管「人 ↔ Agent」的连接MCP 管「Agent ↔ 工具」的连接。而 LSP 管「编辑器 ↔ 代码语义」的连接Agent 在执行任务时也可以借助 LSP 获取代码上下文。三个协议完全可以串成一条完整的 AI 编程链路。4. LSP八年前的老协议在 AI 时代反而焕发第二春聊完两个新协议回到 LSP。很多人以为它只是「老一辈编辑器协议」跟 AI 关系不大这是一个严重的误判。4.1 LSP 的原始设计让每一种语言都有一等一的编辑体验LSP 出现之前编辑器对语言的支持是一个个插件堆出来的。以最典型的 VS Code 为例如果想让编辑器支持 TypeScript需要写补全、诊断、跳转、重命名等几十个功能模块再想支持 Python又要写一遍。每种语言 × 每个编辑器 巨大的重复劳动。LSP 把这个模型彻底改了语言作者只需要实现一个 Language Server通过标准化的 JSON-RPC 与编辑器通信。编辑器实现一套 LSP Client就能获得所有语言服务器的能力。你可以在 VS Code 里用rust-analyzer在 Neovim 里也用rust-analyzer体验几乎一样。这就是「一次实现到处运行」在编程工具领域的落地。4.2 LSP 的工作方式编辑器与语言服务器的「一问一答」LSP 的通信模型是典型的客户端-服务器架构。编辑器是客户端语言服务器是独立进程通信走 stdio 或 TCP内容同样是 JSON-RPC 2.0。生命周期是这样的编辑器启动后发送initialize请求协商能力接着发送initialized通知告知服务器「我已经准备好了」。之后编辑器持续同步文档状态textDocument/didOpen通知服务器「这个文件打开了」textDocument/didChange通知「内容改了」。服务器根据需要返回补全、诊断等信息比如{ jsonrpc: 2.0, id: 3, method: textDocument/completion, params: { textDocument: { uri: file:///workspace/main.py }, position: { line: 10, character: 16 } } }语言服务器收到后返回一个补全列表包含候选标识符、类型、文档说明。整个过程不需要编辑器内置任何语言逻辑它只负责展示。对 AI 编程工具来说这套机制的价值在于LSP 可以提供结构化的语义数据而不是原始的文本。模型拿到「这个变量类型是User」「这个函数签名是createUser(name, email)」这种结构化信息比让它自己从文本里猜精准得多。4.3 AI 编程工具为什么回头拥抱 LSP过去一年AI 编程工具开始大量利用 LSP。opencode 的文档里明确写了如何把 LSP 作为代码上下文采集器编辑器把打开的文档同步给语言服务器获取 hover 信息、定义位置、诊断错误再打包成上下文喂给模型。这就是「opencode 如何使用 LSP」这个搜索量暴涨的原因。LSP 与 AI 编程工具的结合点主要有三个语义级上下文模型看到的不只是代码文本还包括类型信息、引用关系、错误诊断回答更准确。实时诊断反馈Agent 改完代码后通过 LSP 拉取最新的诊断结果相当于拿到了「自测」信号不用等编译或 lint。跨语言能力复用Agent 要支持新语言时不需要重写解析逻辑直接接入对应的 Language Server 即可。LSP 是「读」的协议它替模型把代码语义嚼碎了而 MCP 是「做」的协议它让模型能改文件、跑命令、调 API。没有 LSPAI 编程像蒙眼开车没有 MCPAI 编程像有眼但没手。两者互补不是替代。4.4 LSP 能做的事与不能做的事LSP 能做的补全、定义跳转、查找引用、重命名、hover 文档、诊断错误、代码格式化、代码操作。这些都是「理解代码」层面的能力。LSP 做不了的执行代码、修改文件系统、调用外部 API、访问数据库。虽然 LSP 规范里定义了workspace/executeCommand语言服务器可以通过命令执行一些编辑器动作但它的设计边界始终是「语义服务」不是「执行引擎」。这里有一个很多人踩过的坑试图把业务逻辑塞进 Language Server让 LSP 充当应用后端。LSP 进程通常由编辑器按工作区管理生命周期和编辑器绑定不适合承载长任务、有状态业务或需要外部依赖的服务。业务能力应该通过 MCP 暴露LSP 只负责代码理解。顺带说一句LSP 这个缩写在其他领域另有含义比如通信网络里的标签交换路径。本文讨论的内容只指 Language Server Protocol网上搜资料时注意区分。5. 三足鼎立还是各管一段用一张表划清边界把三个协议放在一张表里对比边界会非常清晰。以下是我在实际项目里总结的对比维度比官方文档的抽象描述更好用。5.1 从「连接对象」看三者分工维度MCPACPLSP连接的双方模型/Agent ↔ 外部工具与数据源编辑器客户端 ↔ 编程智能体编辑器 ↔ 语言服务器典型使用场景AI 调用数据库、API、浏览器、设计软件IDE 内使用 Claude Code、Codex、Gemini CLI编辑器补全、诊断、跳转、重构核心角色Host、Client、ServerClient编辑器、Agent ServerClient编辑器、Language Server消息方向模型主动调工具编辑器与 Agent 双向会话编辑器发查询服务器返回语义传输方式stdio / Streamable HTTPstdio / HTTP实现相关stdio / TCP / WebSocket代表实现Claude Desktop、Spring AI、多语言 SDKZed、opencode、Claude CodeVS Code、Neovim、pyright、rust-analyzer成熟度快速迭代生态爆发早期标准仍在演进非常成熟生态最稳定这张表有一个值得注意的点LSP 的「成熟度」最高因为它在 2024 年前就积累了八年生态MCP 的「发展速度」最快因为 AI 工具接入需求急剧扩张ACP 最年轻应用面目前还集中在编程场景。5.2 从「主动方是谁」看三者定位差异理解一个协议关键是搞清楚「谁主动、谁被动」。MCP 里主动权在模型。模型决定什么时候调用哪个工具、传什么参数、如何组合多个工具完成目标。Server 处于被动响应状态它不知道模型下一步要干什么。ACP 里主动权在编辑器端。用户发消息触发会话流转但会话内部 Agent 有相当高的自主决策权——它可以决定先读哪个文件、要不要运行测试、什么时候结束。ACP 的设计意图本来就是「把 Agent 的自主性封装在标准化通道里」。LSP 里主动权完全在编辑器。编辑器决定什么时候请求补全、什么时候同步文档、什么时候关闭会话。语言服务器不会主动「建议」什么它只对请求做响应。这三个主动方模型决定了它们的应用模式MCP 适合做工具开放平台ACP 适合做 Agent 统一入口LSP 适合做编辑器基础设施。5.3 从「成熟度 vs 发展速度」看未来趋势判断一个协议值不值得投入我习惯同时看两个指标当前成熟度和演进速度。LSP 的成熟度很高但演进速度慢。规范已经稳定社区重心是维护现有实现不会出现破坏性变更。对于要长期维护的工具链选 LSP 最稳妥。MCP 的成熟度中等但演进速度极快。规范本身比较稳定但生态每天都在新增 Server 和 SDK 功能。风险在于社区容易出现「封装过头」的二次标准选型时要紧盯官方 spec避免被厂商私有扩展绑定。ACP 的成熟度最低演进速度也最快。它目前最大的不确定性是「标准化能不能跑赢市场」。如果头部 Agent 厂商决定各自为战ACP 就可能沦为小众协议但目前 Anthropic、OpenAI 都参与了制定说明行业有统一意愿。我的建议是关注但不押注先小范围验证。6. 实战选型与组合架构我该怎么用这三个协议前面讲原理这一节讲落地。我给出一个经过多个项目验证的判断框架和三种典型架构。6.1 判断框架先回答四个问题在决定接哪个协议之前先回答这四个问题你的用户是谁是终端用户用编辑器还是模型直接操作工具用户决定了协议的最终交互面。你的核心能力是「读懂代码」还是「操作外部系统」前者走 LSP后者走 MCP。你希望用户能在一款编辑器里切换多个 Agent 后端吗如果是走 ACP。你的团队能接受新协议的演进风险吗如果做的是内部工具可以激进做商业产品则要控制依赖面。回答完这四个问题多数选型困惑都能解开。6.2 三种典型组合架构第一种IDE LSP MCP给传统编辑器加 AI 能力。编辑器通过 LSP 获取代码语义通过 MCP Server 接入外部知识库或工具。这是目前插件型 AI 编程助手最常用的架构风险和成本都最低。第二种IDE ACP Agent用编辑器承载编程智能体。用户在 VS Code、Zed 或其他编辑器里通过 ACP 连接 Claude Code 或 Codex。这种架构下LSP 通常由 Agent 进程内部使用来理解代码MCP 由 Agent 挂载来执行操作。你可以用编辑器界面享受 Agent 的完整能力同时保留编辑器的快捷键、多光标、插件生态。第三种Agent 原生 MCP不依赖编辑器。直接在终端使用 Claude Code、Codex CLI通过 MCP 挂载内部工具。这是当前 CLI Agent 用户的主流方案轻量、直接、调试方便。三种架构可以互相嵌套。我自己常用的组合是在 VS Code 里写代码LSP 负责语义服务开一个 Zed 通过 ACP 连 Claude Code 跑长任务Claude Code 挂了 5 个 MCP Server 接内网知识库和测试平台。听起来复杂但每条链路都是标准协议没有一条需要写私有适配器。6.3 避坑建议与个人经验最后分享几条从实际项目里踩出来的经验。MCP 的坑主要在权限和安全。MCP Server 暴露给模型的工具相当于把内部系统开放给 AI如果 Server 没有做鉴权任何能调用模型的人都可能间接访问你的数据。我见过有团队把带数据库账号密码的环境变量写进 MCP Server 代码这等于把钥匙放在门垫底下。一定要给每个 MCP Server 做最小权限设计生产环境用 HTTP 传输务必启用身份认证。ACP 的坑主要在版本和兼容性。作为一个新兴协议ACP 的破坏性变更比较频繁。某个 Client 版本支持的 method 映射换一个 Agent 版本可能就不认了。建议把 Client 和 Agent 都锁定版本升级前跑一遍全量回归别在周五下午升级。LSP 的坑主要在性能和资源占用。一个大型 Monorepo 里可能同时挂多个 Language Server每个都要吃掉几百 MB 内存。AI Agent 频繁请求语义上下文时LSP 响应延迟会成为瓶颈。优化办法是只对 Agent 真正关心的文件开 LSP 会话不要全仓库扫描。另外关于「Agent Skill 和 MCP 有什么区别」这类高频问题我的理解是Skill 是 Agent 内部的能力包定义的是「特定任务怎么做」比如某个 Agent 内置的代码评审流程MCP 是跨 Agent 的工具接入标准定义的是「外部工具怎么被调用」。两者不是替代关系Skill 强调流程编排MCP 强调工具互通。如果只让我说一条最重要的经验那就是协议是手段不是目的。MCP、ACP、LSP 都是为了让 AI 生态的连接更标准化而生的你的架构只要遵循「职责分层」原则——LSP 管理解、MCP 管执行、ACP 管交互——就不会在大方向上出错。剩下的事情就是边踩坑、边迭代、边看社区怎么演进。 
