最近团队在折腾 AI 编程工具链群里讨论已经从哪个模型写代码更稳变成了MCP、ACP、LSP 到底有什么不同。这三个缩写经常同时出现又常常被人画等号其实它们解决的问题完全不同MCP 负责让大模型连上外部工具和数据LSP 负责让编辑器真正理解代码ACP 则让 AI Agent 能在编辑器里亲自操作文件、终端和缓冲区。这篇我不打算复述官方文档而是结合我接入 Claude Code、Codex、OpenCode以及自建 MCP Server 的实际经历把三个协议的定位、核心消息、适用场景、常见坑逐个拆开讲清楚。适合正在做 AI 编程工具、Agent 开发、IDE 插件或者只是被各种 MCP 热搜词绕晕的工程师。1. 三足鼎立三大协议各管哪一摊很多人第一次看到这几个词是在同一个项目的 README 里同时出现的。比如 Zed 编辑器集成 Claude Code一边要初始化 LSP 做代码诊断一边要拉起 MCP Server 给模型提供工具中间还要通过 ACP 让 Agent 能读写文件。信息量一大人就懵了。我先把三者最朴素的分工讲清楚后面才不会绕晕。1.1 一句话定位MCPModel Context Protocol模型上下文协议是 Anthropic 在 2024 年底开放的协议目标是让大模型以统一方式调用外部工具、读取外部数据。你可以把它理解成给 AI 插上USB-C 接口以后接数据库、接设计稿、接安全扫描器都走同一个协议。LSPLanguage Server Protocol语言服务器协议是微软 2016 年发布的协议负责把代码智能从编辑器里抽出来做成独立的语言服务器。它解决的问题是为什么同样的补全、跳转、报错能在 VS Code、Neovim、Zed 里都长得差不多因为有 LSP 在里面做翻译。ACPAgent Client ProtocolAgent 客户端协议是 2025 年以来被推到台前的一个新协议主要是 Zed 团队在推动目标是把宿主环境比如一个编辑器的能力暴露给外部 AI Agent。Agent 通过 ACP 可以打开文件、改缓冲区、跑终端命令、拿诊断等于给 Agent 装上了手和眼。1.2 一张表看懂三者差异我整理了下面这张对比表建议收藏遇到同事问就直接甩给他。对比维度MCPLSPACP提出方Anthropic微软Zed 团队推动出现时间2024 年底2016 年2025 年前后核心关注点模型与外部世界连接编辑器与语言智能连接Agent 与宿主环境连接典型客户端AI Agent、MCP Client编辑器 / IDEAgent 宿主如 IDE典型服务端MCP Server工具、数据源语言服务器languageserver宿主持有能力的服务通信基础JSON-RPC 2.0JSON-RPC 2.0JSON-RPC 2.0核心资产Tools / Resources / Prompts诊断 / 补全 / 跳转文件 / 终端 / 缓冲区典型例子Figma MCP、Blender MCPpyright、goplsClaude Code 在 Zed 里的运行注意三者都建立在 JSON-RPC 2.0 上这是它们看起来像同一种东西的根本原因。但消息内容、生命周期、服务端职责完全不同。看清楚表格最后一行的核心资产比纠结协议名字重要得多。2. MCP给大模型插上外设的标准化接口如果说大模型是一个大脑MCP 就是大脑伸向真实世界的所有神经末梢的接口标准。没有 MCP 之前你想让 GPT 调用公司内部 API得写一堆胶水代码把 API 包装成 function calling 的格式每换一个模型供应商就重写一遍。这种一个模型一套工具调用方式的做法很快会被 MCP 式的一次接入、处处复用替代。2.1 MCP 到底解决什么问题我用一个实际场景说明。假设你正在做 AI 辅助研发工具需要让模型能查工单、读代码仓库、调接口测试。没有 MCP你需要给 Claude Code 写一套插件再给 Codex 写一套函数还要给自研 Agent 再做一套适配。三个系统之间的工具定义、参数格式、错误处理全都不一样维护成本直接起飞。MCP 的做法是把工具和数据源统一成 MCP Server用一套协议对外暴露能力。Agent 不管底层到底是 Java 的 REST 接口还是 Python 脚本只要它实现了 MCP 标准模型就能用同样的方式调用。这也是为什么现在连 Java 开发者都在问怎么将 Rest 接口发布为 MCP因为企业内部的遗留系统太多与其让 Agent 逐个适配不如统一包一层 MCP。2.2 MCP 的三种原语Tools、Resources、PromptsMCP 规范里最核心的是三种原语我分别说Tools可被模型调用的工具。比如查询天气读取数据库条目执行一条 SQL。工具由模型决定何时调用调用结果再喂回给模型。Resources可被读取的资源。以 URI 标识比如file:///etc/config、db://users/1。资源的作用是给模型提供上下文数据不是让模型执行动作。Prompts提示词模板。类似预设好的技能包用户或 Agent 可以按需引用快速拿到一个结构化的 Prompt。理解这三者的区别很关键。Tools 是动词Resources 是名词Prompts 是剧本。很多初学者把一切能力都设计成 Tools结果模型为了读一个配置也要调一次函数调试时完全看不出来 Agent 在干什么。正确做法是静态数据走 Resources动作走 Tools标准化操作流程走 Prompts。2.3 从一次 MCP 调用看通信链路MCP 最基础的通信方式是 stdio也就是客户端把一个 MCP Server 作为子进程拉起来通过标准输入输出传 JSON-RPC 消息。线上环境常用 Streamable HTTP走 POST SSE。一次典型的工具调用长这样{ jsonrpc: 2.0, id: 1, method: tools/call, params: { name: get_weather, arguments: { city: 北京 } } }服务端返回{ jsonrpc: 2.0, id: 1, result: { content: [ { type: text, text: 晴27 摄氏度 } ] } }发请求之前客户端和服务端要先做一次 initialize 握手交换协议版本和各自能力。很多 MCP Server 连接失败的问题就出在握手阶段服务端没有按规范返回 capabilities客户端直接报错。我自己的习惯是新写一个 MCP Server 时先用命令行手动发一条 initialize 请求确认握手通了再去接 Agent。别一上来就在 Claude Code 里配出了问题日志又多又乱。2.4 MCP 生态现状从 Blender 到 BurpSuite 都在接MCP 生态发展非常快你可以搜到的热门用法基本覆盖了各个行业Figma MCP让模型直接读取设计稿结构自动生成前端代码。Blender MCP通过套接字让大模型控制 3D 建模软件输入自然语言就能改模型参数。BurpSuite MCP / Yakit MCP把安全测试工具的能力开放给 AI Agent模型能直接触发扫描器并读取结果。Chrome MCP Server让 LLM 驱动浏览器做页面操作、表单填写。NXOpen MCP / CATIA MCP工业 CAD 软件也在接入用于参数化建模的 AI 辅助。蓝湖 MCP设计交付场景AI 直接从蓝湖拉取标注和切图信息。这些例子说明 MCP 不是程序员圈子的自嗨而是把模型联网能力泛化到普通软件接口上的一种基础设施。你可以把心仪的软件想象成一个外设MCP Server 就是这个外设的驱动程序模型则是拥有万能操作系统的宿主。3. LSP看似老古董其实是 AI 编程的地基LSP 已经快十年了。很多搞 AI 的年轻工程师会问ChatGPT 都能直接生成代码了为什么还要研究 LSP答案很简单模型生成代码之后要验证语法、看报错、跳转定义这些背后都站着 LSP。你让 Claude 改完一段 JS 代码编辑器里立刻出现的红波浪线就是语言服务器通过 LSP 推送的诊断。3.1 LSP 的诞生逻辑与核心设计2016 年之前每种语言都要给每个编辑器写一套插件。VS Code 想支持 Python给 Python 写插件Neovim 想支持 Python再写一遍。语言本身的智能分析逻辑语法分析、类型推导、补全建议和编辑器界面逻辑强绑在一起社区重复劳动严重。LSP 的解法是把语言分析逻辑抽成独立的语言服务器进程通过统一协议和编辑器通信。编辑器从此只需要实现一套 LSP 客户端就可以获得任意语言的支持。这也是为什么 pyright、gopls、rust-analyzer 这些语言服务器能同时服务 VS Code、Neovim、Zed 等编辑器。3.2 LSP 的关键消息从握手到诊断LSP 的帧格式比较特别在 JSON-RPC 2.0 外包了一层 HeaderContent-Length: 123\r\n \r\n {jsonrpc:2.0,id:1,method:initialize,params:{...}}打开文件之后客户端会发送textDocument/didOpen让语言服务器知道当前文件内容。每次用户敲一个字符就发一次textDocument/didChange。这也是为什么大型项目里 LSP 流量很大几乎每个输入事件都会触发一次增量同步。诊断信息是反过来的由语言服务器主动推送给编辑器{ jsonrpc: 2.0, method: textDocument/publishDiagnostics, params: { uri: file:///project/src/main.py, diagnostics: [ { range: { start: { line: 10, character: 4 }, end: { line: 10, character: 16 } }, severity: 1, message: Undefined variable foo } ] } }套用一句老话LSP 的价值不在于某个请求多复杂而在于它把代码分析能力和代码呈现界面彻底解耦了。这一解耦让后来的 AI 编程工具也能直接消费语言服务器产生的符号、诊断、结构信息而不必自己重新实现一遍编译器的前端。3.3 LSP 在 AI 时代为什么没有过时恰恰相反AI 编程工具越多LSP 越重要。原理很简单大模型生成代码不是零错误的你需要一个裁判来检验每次改动是否引入了语法或类型问题。这个裁判就是语言服务器它的判定结果通过 LSP 传给编辑器AI Agent 再从编辑器侧读取并根据诊断继续修改。OpenCode 这类开源 AI 编程终端工具底层同样可以配合 LSP。你让它在项目里加一个函数它需要先借助 LSP 知道当前文件的符号表、引用关系才能改得不出错。opencode 如何使用 LSP这类热搜本质上就是人们在探索如何把 AI 的生成能力和 LSP 的结构化代码认知结合起来。我经常跟人讲一个比喻LSP 是代码世界的 GPS。它不写字不生成代码但它一直告诉你你现在在哪、这条路上有哪些坑、从 A 到 B 应该走哪条线。AI 编程工具要在一个陌生仓库里高效工作GPS 是基础。4. ACP让 Agent 在编辑器里亲自动手的新协议如果说 MCP 是在给模型插外设LSP 是在给编辑器接语言大脑那 ACP 干的事更接近操作层它让 Agent 能在编辑器里真正的动手干活——读写文件、执行命令、操作缓冲区、获取当前光标位置。4.1 ACP 是从什么场景里长出来的我第一次注意到 ACP是在 Zed 里跑 Claude Code 的时候。当时的痛点很明显Claude Code 作为一个终端里的 Agent能自己写代码、跑测试但它看不到我在编辑器里开的文件不知道我的光标停在哪个函数上也没法直接把修改写进我正在编辑的缓冲区。MCP 解决的是工具连接可和宿主编辑器深度协同这件事一直没有标准。ACP 的设计目标就是补上这一层。它定义了 Agent 和宿主环境之间的通信方式Agent 启动时先创建一个 session通过 session 里的各个请求获取宿主提供的文件、搜索、终端、诊断、编辑器状态等能力。Zed 集成 Claude Code就是典型应用场景之一。社区里搜claude code acp的人越来越多说明大家在实际用的时候都遇到了怎么让 Agent 和我所见即所得的需求。4.2 ACP 的核心能力清单根据我在实践中接触到的规范草案ACP 的能力域大致包含以下几类文件系统读文件、写文件、列目录、重命名、删除。搜索在项目内做文本搜索类似 grep。终端在宿主环境中启动 shell 命令并持续读取 stdout / stderr 输出流。诊断从宿主读取当前打开文件的 LSP 诊断结果。编辑器操作获取打开文档列表、获取选区与光标位置、修改缓冲区内容、打开或关闭文件。这几个能力放在一起恰好构成一个远程程序员在 IDE 里工作的完整闭环。Agent 不再是瞎子摸象它知道自己打开了哪个文件、错误的红色波浪线在哪一行、终端里跑测试的输出是什么。会话语义是 ACP 的一个特色。一个 session 往往代表一次完整的 Agent 任务里面有多个请求和事件宿主可以根据 session 的当前状态渲染Agent 正在做什么的面板。我实际用下来的经验是如果你在自己编辑器里实现 ACP优先做 session 的生命周期管理不要把所有请求设计成无状态的否则界面上的进度展示会非常别扭。4.3 ACP 与 LSP / MCP 的分工与重叠你会发现 ACP 的诊断能力听着耳熟这不就是 LSP 在干的事吗对ACP 自己并不重新发明诊断算法它通常是复用宿主已经收集到的 LSP 诊断结果再提供给 Agent。所以 ACP 在下层可以依赖 LSP。同理ACP 也没有把调用外部工具这件事自己包揽。Agent 需要查天气、查数据库、调设计稿照样走 MCP。ACP 管的是宿主环境内的操作MCP 管的是宿主环境外的连接LSP 管的是代码本身的理解。三层叠加才是一个完整的 AI 编程工作流。5. 一个真实场景里三者怎么配合讲完概念你可能还是觉得抽象。我举个具体例子在编辑器里让 AI Agent 修复一个 bug。整个过程里三个协议都会出现配合得非常紧密。5.1 完整链路让 Agent 修一个 bug假设我在一个 Python 项目里代码有个未定义变量编辑器的红波浪线已经出现了。我对 Agent 说帮我看看这个报错把它修好。第一步Agent 启动通过 ACP 创建一个 session。它会问宿主当前打开的是哪个文件光标在哪这个阶段走的是 ACP 的编辑器状态接口。第二步Agent 要想知道哪里报错不需要自己扫描代码。宿主早就通过 LSP 从 pyright 拿到了诊断信息。Agent 通过 ACP 调用获取诊断能力直接拿到「第 10 行第 4 列未定义变量 foo」的精确位置。第三步Agent 通过 ACP 读取文件内容看到上下文判断foo应该是什么。如果这个项目里foo的取值依赖某个内部 APIAgent 会走 MCP 请求企业的知识库或接口文档。这一步是 MCP 的主场。第四步Agent 通过 ACP 修改缓冲区把修复后的代码写进去。编辑器立刻触发textDocument/didChange语言服务器重新分析通过 LSP 推送新的诊断。Agent 看到诊断结果从 error 变成干净再通过 ACP 启动终端执行测试。整个过程走下来LSP、MCP、ACP 各司其职缺一层都不完整。没有 LSPAgent 只能靠肉眼读文件猜错误没有 MCPAgent 拿不到外部信息没有 ACPAgent 改完代码还要自己去终端里找路径处理文件根本无法做到在编辑器里顺滑工作。5.2 谁替代谁其实是分层共生很多人看到新协议出来就急着宣布XX 过时了这三个协议根本不在同一个层次上。你非要说替代关系LSP 被替代的概率反而最低因为它解决的问题非常稳定编辑器与语言服务器解耦。MCP 和 ACP 出现得更晚是因为大模型和 Agent 的出现才产生了新需求。未来更可能的方向是LSP 继续做代码智能底座MCP 继续做工具连接标准ACP 逐步收敛 Agent 操作宿主环境的接口甚至可能反过来被 MCP 或 LSP 的一部分能力吸收但短期内三者会共存。6. 选型建议与踩坑实录协议再多落到自己项目里就要做选择。我根据实际项目经验给出选型建议和常见问题排查思路。6.1 什么场景优先考虑哪个协议你的需求优先考虑理由让 LLM 调用外部 API、数据库、设计工具、安全扫描器MCP生态最广工具定义成熟一次接入多处复用让编辑器补全、报错、跳转支持多语言LSP十年沉淀编辑器支持度最好让外部 Agent 在编辑器内读写文件、执行命令、操作缓冲区ACP专门为宿主机能力开放设计做一款 AI 编程 IDE同时需要代码智能、工具连接、Agent 操作LSP MCP ACP三层各司其职缺一不可如果你的团队在为一个已有的 IDE 做 AI 增强插件我建议先用 LSP 接语言智能再用 MCP Server 把外部工具统一接入最后评估是否要让 Agent 深度操作 IDE 内部状态需要的话再引入 ACP。不要一开始就三个一起上学习成本和调试成本会翻倍。6.2 常见问题速查表问题可能原因排查思路MCP Server 连接失败传输方式不匹配、未完成 initialize 握手、API Key 缺失先用手工脚本发 initialize 请求确认服务端正常MCP 工具调用超时工具执行时间过长客户端没有设置超时长任务应设计成异步执行调用接口立即返回任务 IDLSP 诊断不刷新客户端未发送 didChange或语言服务器等待 didSave检查是否在保存时才触发诊断很多服务器默认 didSaveLSP 补全结果为空capabilities 里没有声明 completionProvider用initialize响应里的 capabilities 确认能力开启ACP session 初始化失败报already initialize同一个 session 被重复初始化重启宿主进程检查启动脚本只创建一次 session不知道 Agent Skill 和 MCP 区别概念混用Skill 是提示词和流程的打包MCP 是工具和数据的连接标准Failed to initialize ACP session. Error: internal error: already initialize这个报错我印象特别深。有次我在一个编辑器插件里写得很急把 session 初始化逻辑写进了热更新回调里宿主一刷新就重复创建 session。排查到最后发现不是协议本身的问题而是我自己的生命周期管理漏洞。这个报错的通用解法就是检查 session 是否有全局唯一实例是否在插件初始化、重载、配置变更等多个入口都被调用了。6.3 我的两条实操心得第一调试 MCP / ACP 这类 JSON-RPC 协议建议把所有原始消息打日志。很多工具提供的友好错误提示会丢上下文不如直接看原始 JSON立刻能定位是字段名拼错、id 不匹配还是握手顺序错了。第二做工具接入时优先选那些有真实业务场景的 MCP Server 练手。比如你先接一个 Figma MCP 或 Chrome MCP让模型完成一个从网页提取文章并摘要的任务。这一步能让你快速理解 Tools、Resources、Prompts 的区别等你想把公司内部 API 改成 MCP Server 时就不会手忙脚乱了。我个人的体会是这场所谓的三足鼎立其实更像三层地基。上面吵得再凶下面还是 LSP 在默默维持代码智能MCP 把模型与世界的距离拉近到一次tools/callACP 则让 Agent 真正成为宿主环境的长住居民。如果你正在给团队选型我的建议是先别急着站队而是问一句你的 Agent 需要的是更多工具、更懂代码还是更能操作答案不同投入顺序就完全不同。最后补一个实战小技巧无论你最终做哪一层先把 JSON-RPC 的帧解析和日志打点做好。这三个协议本质都是消息请求/响应能看懂消息流转后面所有坑都好排查。协议会演进规范会更新但搞清楚消息从哪里来、到哪里去、在哪里断掉这个方法任何时代都不会过时。
MCP、LSP、ACP三协议详解：AI编程工具如何分层协同工作
最近团队在折腾 AI 编程工具链群里讨论已经从哪个模型写代码更稳变成了MCP、ACP、LSP 到底有什么不同。这三个缩写经常同时出现又常常被人画等号其实它们解决的问题完全不同MCP 负责让大模型连上外部工具和数据LSP 负责让编辑器真正理解代码ACP 则让 AI Agent 能在编辑器里亲自操作文件、终端和缓冲区。这篇我不打算复述官方文档而是结合我接入 Claude Code、Codex、OpenCode以及自建 MCP Server 的实际经历把三个协议的定位、核心消息、适用场景、常见坑逐个拆开讲清楚。适合正在做 AI 编程工具、Agent 开发、IDE 插件或者只是被各种 MCP 热搜词绕晕的工程师。1. 三足鼎立三大协议各管哪一摊很多人第一次看到这几个词是在同一个项目的 README 里同时出现的。比如 Zed 编辑器集成 Claude Code一边要初始化 LSP 做代码诊断一边要拉起 MCP Server 给模型提供工具中间还要通过 ACP 让 Agent 能读写文件。信息量一大人就懵了。我先把三者最朴素的分工讲清楚后面才不会绕晕。1.1 一句话定位MCPModel Context Protocol模型上下文协议是 Anthropic 在 2024 年底开放的协议目标是让大模型以统一方式调用外部工具、读取外部数据。你可以把它理解成给 AI 插上USB-C 接口以后接数据库、接设计稿、接安全扫描器都走同一个协议。LSPLanguage Server Protocol语言服务器协议是微软 2016 年发布的协议负责把代码智能从编辑器里抽出来做成独立的语言服务器。它解决的问题是为什么同样的补全、跳转、报错能在 VS Code、Neovim、Zed 里都长得差不多因为有 LSP 在里面做翻译。ACPAgent Client ProtocolAgent 客户端协议是 2025 年以来被推到台前的一个新协议主要是 Zed 团队在推动目标是把宿主环境比如一个编辑器的能力暴露给外部 AI Agent。Agent 通过 ACP 可以打开文件、改缓冲区、跑终端命令、拿诊断等于给 Agent 装上了手和眼。1.2 一张表看懂三者差异我整理了下面这张对比表建议收藏遇到同事问就直接甩给他。对比维度MCPLSPACP提出方Anthropic微软Zed 团队推动出现时间2024 年底2016 年2025 年前后核心关注点模型与外部世界连接编辑器与语言智能连接Agent 与宿主环境连接典型客户端AI Agent、MCP Client编辑器 / IDEAgent 宿主如 IDE典型服务端MCP Server工具、数据源语言服务器languageserver宿主持有能力的服务通信基础JSON-RPC 2.0JSON-RPC 2.0JSON-RPC 2.0核心资产Tools / Resources / Prompts诊断 / 补全 / 跳转文件 / 终端 / 缓冲区典型例子Figma MCP、Blender MCPpyright、goplsClaude Code 在 Zed 里的运行注意三者都建立在 JSON-RPC 2.0 上这是它们看起来像同一种东西的根本原因。但消息内容、生命周期、服务端职责完全不同。看清楚表格最后一行的核心资产比纠结协议名字重要得多。2. MCP给大模型插上外设的标准化接口如果说大模型是一个大脑MCP 就是大脑伸向真实世界的所有神经末梢的接口标准。没有 MCP 之前你想让 GPT 调用公司内部 API得写一堆胶水代码把 API 包装成 function calling 的格式每换一个模型供应商就重写一遍。这种一个模型一套工具调用方式的做法很快会被 MCP 式的一次接入、处处复用替代。2.1 MCP 到底解决什么问题我用一个实际场景说明。假设你正在做 AI 辅助研发工具需要让模型能查工单、读代码仓库、调接口测试。没有 MCP你需要给 Claude Code 写一套插件再给 Codex 写一套函数还要给自研 Agent 再做一套适配。三个系统之间的工具定义、参数格式、错误处理全都不一样维护成本直接起飞。MCP 的做法是把工具和数据源统一成 MCP Server用一套协议对外暴露能力。Agent 不管底层到底是 Java 的 REST 接口还是 Python 脚本只要它实现了 MCP 标准模型就能用同样的方式调用。这也是为什么现在连 Java 开发者都在问怎么将 Rest 接口发布为 MCP因为企业内部的遗留系统太多与其让 Agent 逐个适配不如统一包一层 MCP。2.2 MCP 的三种原语Tools、Resources、PromptsMCP 规范里最核心的是三种原语我分别说Tools可被模型调用的工具。比如查询天气读取数据库条目执行一条 SQL。工具由模型决定何时调用调用结果再喂回给模型。Resources可被读取的资源。以 URI 标识比如file:///etc/config、db://users/1。资源的作用是给模型提供上下文数据不是让模型执行动作。Prompts提示词模板。类似预设好的技能包用户或 Agent 可以按需引用快速拿到一个结构化的 Prompt。理解这三者的区别很关键。Tools 是动词Resources 是名词Prompts 是剧本。很多初学者把一切能力都设计成 Tools结果模型为了读一个配置也要调一次函数调试时完全看不出来 Agent 在干什么。正确做法是静态数据走 Resources动作走 Tools标准化操作流程走 Prompts。2.3 从一次 MCP 调用看通信链路MCP 最基础的通信方式是 stdio也就是客户端把一个 MCP Server 作为子进程拉起来通过标准输入输出传 JSON-RPC 消息。线上环境常用 Streamable HTTP走 POST SSE。一次典型的工具调用长这样{ jsonrpc: 2.0, id: 1, method: tools/call, params: { name: get_weather, arguments: { city: 北京 } } }服务端返回{ jsonrpc: 2.0, id: 1, result: { content: [ { type: text, text: 晴27 摄氏度 } ] } }发请求之前客户端和服务端要先做一次 initialize 握手交换协议版本和各自能力。很多 MCP Server 连接失败的问题就出在握手阶段服务端没有按规范返回 capabilities客户端直接报错。我自己的习惯是新写一个 MCP Server 时先用命令行手动发一条 initialize 请求确认握手通了再去接 Agent。别一上来就在 Claude Code 里配出了问题日志又多又乱。2.4 MCP 生态现状从 Blender 到 BurpSuite 都在接MCP 生态发展非常快你可以搜到的热门用法基本覆盖了各个行业Figma MCP让模型直接读取设计稿结构自动生成前端代码。Blender MCP通过套接字让大模型控制 3D 建模软件输入自然语言就能改模型参数。BurpSuite MCP / Yakit MCP把安全测试工具的能力开放给 AI Agent模型能直接触发扫描器并读取结果。Chrome MCP Server让 LLM 驱动浏览器做页面操作、表单填写。NXOpen MCP / CATIA MCP工业 CAD 软件也在接入用于参数化建模的 AI 辅助。蓝湖 MCP设计交付场景AI 直接从蓝湖拉取标注和切图信息。这些例子说明 MCP 不是程序员圈子的自嗨而是把模型联网能力泛化到普通软件接口上的一种基础设施。你可以把心仪的软件想象成一个外设MCP Server 就是这个外设的驱动程序模型则是拥有万能操作系统的宿主。3. LSP看似老古董其实是 AI 编程的地基LSP 已经快十年了。很多搞 AI 的年轻工程师会问ChatGPT 都能直接生成代码了为什么还要研究 LSP答案很简单模型生成代码之后要验证语法、看报错、跳转定义这些背后都站着 LSP。你让 Claude 改完一段 JS 代码编辑器里立刻出现的红波浪线就是语言服务器通过 LSP 推送的诊断。3.1 LSP 的诞生逻辑与核心设计2016 年之前每种语言都要给每个编辑器写一套插件。VS Code 想支持 Python给 Python 写插件Neovim 想支持 Python再写一遍。语言本身的智能分析逻辑语法分析、类型推导、补全建议和编辑器界面逻辑强绑在一起社区重复劳动严重。LSP 的解法是把语言分析逻辑抽成独立的语言服务器进程通过统一协议和编辑器通信。编辑器从此只需要实现一套 LSP 客户端就可以获得任意语言的支持。这也是为什么 pyright、gopls、rust-analyzer 这些语言服务器能同时服务 VS Code、Neovim、Zed 等编辑器。3.2 LSP 的关键消息从握手到诊断LSP 的帧格式比较特别在 JSON-RPC 2.0 外包了一层 HeaderContent-Length: 123\r\n \r\n {jsonrpc:2.0,id:1,method:initialize,params:{...}}打开文件之后客户端会发送textDocument/didOpen让语言服务器知道当前文件内容。每次用户敲一个字符就发一次textDocument/didChange。这也是为什么大型项目里 LSP 流量很大几乎每个输入事件都会触发一次增量同步。诊断信息是反过来的由语言服务器主动推送给编辑器{ jsonrpc: 2.0, method: textDocument/publishDiagnostics, params: { uri: file:///project/src/main.py, diagnostics: [ { range: { start: { line: 10, character: 4 }, end: { line: 10, character: 16 } }, severity: 1, message: Undefined variable foo } ] } }套用一句老话LSP 的价值不在于某个请求多复杂而在于它把代码分析能力和代码呈现界面彻底解耦了。这一解耦让后来的 AI 编程工具也能直接消费语言服务器产生的符号、诊断、结构信息而不必自己重新实现一遍编译器的前端。3.3 LSP 在 AI 时代为什么没有过时恰恰相反AI 编程工具越多LSP 越重要。原理很简单大模型生成代码不是零错误的你需要一个裁判来检验每次改动是否引入了语法或类型问题。这个裁判就是语言服务器它的判定结果通过 LSP 传给编辑器AI Agent 再从编辑器侧读取并根据诊断继续修改。OpenCode 这类开源 AI 编程终端工具底层同样可以配合 LSP。你让它在项目里加一个函数它需要先借助 LSP 知道当前文件的符号表、引用关系才能改得不出错。opencode 如何使用 LSP这类热搜本质上就是人们在探索如何把 AI 的生成能力和 LSP 的结构化代码认知结合起来。我经常跟人讲一个比喻LSP 是代码世界的 GPS。它不写字不生成代码但它一直告诉你你现在在哪、这条路上有哪些坑、从 A 到 B 应该走哪条线。AI 编程工具要在一个陌生仓库里高效工作GPS 是基础。4. ACP让 Agent 在编辑器里亲自动手的新协议如果说 MCP 是在给模型插外设LSP 是在给编辑器接语言大脑那 ACP 干的事更接近操作层它让 Agent 能在编辑器里真正的动手干活——读写文件、执行命令、操作缓冲区、获取当前光标位置。4.1 ACP 是从什么场景里长出来的我第一次注意到 ACP是在 Zed 里跑 Claude Code 的时候。当时的痛点很明显Claude Code 作为一个终端里的 Agent能自己写代码、跑测试但它看不到我在编辑器里开的文件不知道我的光标停在哪个函数上也没法直接把修改写进我正在编辑的缓冲区。MCP 解决的是工具连接可和宿主编辑器深度协同这件事一直没有标准。ACP 的设计目标就是补上这一层。它定义了 Agent 和宿主环境之间的通信方式Agent 启动时先创建一个 session通过 session 里的各个请求获取宿主提供的文件、搜索、终端、诊断、编辑器状态等能力。Zed 集成 Claude Code就是典型应用场景之一。社区里搜claude code acp的人越来越多说明大家在实际用的时候都遇到了怎么让 Agent 和我所见即所得的需求。4.2 ACP 的核心能力清单根据我在实践中接触到的规范草案ACP 的能力域大致包含以下几类文件系统读文件、写文件、列目录、重命名、删除。搜索在项目内做文本搜索类似 grep。终端在宿主环境中启动 shell 命令并持续读取 stdout / stderr 输出流。诊断从宿主读取当前打开文件的 LSP 诊断结果。编辑器操作获取打开文档列表、获取选区与光标位置、修改缓冲区内容、打开或关闭文件。这几个能力放在一起恰好构成一个远程程序员在 IDE 里工作的完整闭环。Agent 不再是瞎子摸象它知道自己打开了哪个文件、错误的红色波浪线在哪一行、终端里跑测试的输出是什么。会话语义是 ACP 的一个特色。一个 session 往往代表一次完整的 Agent 任务里面有多个请求和事件宿主可以根据 session 的当前状态渲染Agent 正在做什么的面板。我实际用下来的经验是如果你在自己编辑器里实现 ACP优先做 session 的生命周期管理不要把所有请求设计成无状态的否则界面上的进度展示会非常别扭。4.3 ACP 与 LSP / MCP 的分工与重叠你会发现 ACP 的诊断能力听着耳熟这不就是 LSP 在干的事吗对ACP 自己并不重新发明诊断算法它通常是复用宿主已经收集到的 LSP 诊断结果再提供给 Agent。所以 ACP 在下层可以依赖 LSP。同理ACP 也没有把调用外部工具这件事自己包揽。Agent 需要查天气、查数据库、调设计稿照样走 MCP。ACP 管的是宿主环境内的操作MCP 管的是宿主环境外的连接LSP 管的是代码本身的理解。三层叠加才是一个完整的 AI 编程工作流。5. 一个真实场景里三者怎么配合讲完概念你可能还是觉得抽象。我举个具体例子在编辑器里让 AI Agent 修复一个 bug。整个过程里三个协议都会出现配合得非常紧密。5.1 完整链路让 Agent 修一个 bug假设我在一个 Python 项目里代码有个未定义变量编辑器的红波浪线已经出现了。我对 Agent 说帮我看看这个报错把它修好。第一步Agent 启动通过 ACP 创建一个 session。它会问宿主当前打开的是哪个文件光标在哪这个阶段走的是 ACP 的编辑器状态接口。第二步Agent 要想知道哪里报错不需要自己扫描代码。宿主早就通过 LSP 从 pyright 拿到了诊断信息。Agent 通过 ACP 调用获取诊断能力直接拿到「第 10 行第 4 列未定义变量 foo」的精确位置。第三步Agent 通过 ACP 读取文件内容看到上下文判断foo应该是什么。如果这个项目里foo的取值依赖某个内部 APIAgent 会走 MCP 请求企业的知识库或接口文档。这一步是 MCP 的主场。第四步Agent 通过 ACP 修改缓冲区把修复后的代码写进去。编辑器立刻触发textDocument/didChange语言服务器重新分析通过 LSP 推送新的诊断。Agent 看到诊断结果从 error 变成干净再通过 ACP 启动终端执行测试。整个过程走下来LSP、MCP、ACP 各司其职缺一层都不完整。没有 LSPAgent 只能靠肉眼读文件猜错误没有 MCPAgent 拿不到外部信息没有 ACPAgent 改完代码还要自己去终端里找路径处理文件根本无法做到在编辑器里顺滑工作。5.2 谁替代谁其实是分层共生很多人看到新协议出来就急着宣布XX 过时了这三个协议根本不在同一个层次上。你非要说替代关系LSP 被替代的概率反而最低因为它解决的问题非常稳定编辑器与语言服务器解耦。MCP 和 ACP 出现得更晚是因为大模型和 Agent 的出现才产生了新需求。未来更可能的方向是LSP 继续做代码智能底座MCP 继续做工具连接标准ACP 逐步收敛 Agent 操作宿主环境的接口甚至可能反过来被 MCP 或 LSP 的一部分能力吸收但短期内三者会共存。6. 选型建议与踩坑实录协议再多落到自己项目里就要做选择。我根据实际项目经验给出选型建议和常见问题排查思路。6.1 什么场景优先考虑哪个协议你的需求优先考虑理由让 LLM 调用外部 API、数据库、设计工具、安全扫描器MCP生态最广工具定义成熟一次接入多处复用让编辑器补全、报错、跳转支持多语言LSP十年沉淀编辑器支持度最好让外部 Agent 在编辑器内读写文件、执行命令、操作缓冲区ACP专门为宿主机能力开放设计做一款 AI 编程 IDE同时需要代码智能、工具连接、Agent 操作LSP MCP ACP三层各司其职缺一不可如果你的团队在为一个已有的 IDE 做 AI 增强插件我建议先用 LSP 接语言智能再用 MCP Server 把外部工具统一接入最后评估是否要让 Agent 深度操作 IDE 内部状态需要的话再引入 ACP。不要一开始就三个一起上学习成本和调试成本会翻倍。6.2 常见问题速查表问题可能原因排查思路MCP Server 连接失败传输方式不匹配、未完成 initialize 握手、API Key 缺失先用手工脚本发 initialize 请求确认服务端正常MCP 工具调用超时工具执行时间过长客户端没有设置超时长任务应设计成异步执行调用接口立即返回任务 IDLSP 诊断不刷新客户端未发送 didChange或语言服务器等待 didSave检查是否在保存时才触发诊断很多服务器默认 didSaveLSP 补全结果为空capabilities 里没有声明 completionProvider用initialize响应里的 capabilities 确认能力开启ACP session 初始化失败报already initialize同一个 session 被重复初始化重启宿主进程检查启动脚本只创建一次 session不知道 Agent Skill 和 MCP 区别概念混用Skill 是提示词和流程的打包MCP 是工具和数据的连接标准Failed to initialize ACP session. Error: internal error: already initialize这个报错我印象特别深。有次我在一个编辑器插件里写得很急把 session 初始化逻辑写进了热更新回调里宿主一刷新就重复创建 session。排查到最后发现不是协议本身的问题而是我自己的生命周期管理漏洞。这个报错的通用解法就是检查 session 是否有全局唯一实例是否在插件初始化、重载、配置变更等多个入口都被调用了。6.3 我的两条实操心得第一调试 MCP / ACP 这类 JSON-RPC 协议建议把所有原始消息打日志。很多工具提供的友好错误提示会丢上下文不如直接看原始 JSON立刻能定位是字段名拼错、id 不匹配还是握手顺序错了。第二做工具接入时优先选那些有真实业务场景的 MCP Server 练手。比如你先接一个 Figma MCP 或 Chrome MCP让模型完成一个从网页提取文章并摘要的任务。这一步能让你快速理解 Tools、Resources、Prompts 的区别等你想把公司内部 API 改成 MCP Server 时就不会手忙脚乱了。我个人的体会是这场所谓的三足鼎立其实更像三层地基。上面吵得再凶下面还是 LSP 在默默维持代码智能MCP 把模型与世界的距离拉近到一次tools/callACP 则让 Agent 真正成为宿主环境的长住居民。如果你正在给团队选型我的建议是先别急着站队而是问一句你的 Agent 需要的是更多工具、更懂代码还是更能操作答案不同投入顺序就完全不同。最后补一个实战小技巧无论你最终做哪一层先把 JSON-RPC 的帧解析和日志打点做好。这三个协议本质都是消息请求/响应能看懂消息流转后面所有坑都好排查。协议会演进规范会更新但搞清楚消息从哪里来、到哪里去、在哪里断掉这个方法任何时代都不会过时。
