企业官网建设流程全解析

如果你最近下载过任何一款AI编程工具，大概率会被几个长得差不多的缩写绕晕：MCP、ACP、LSP。我把它们同时装进一个IDE里折腾了一圈之后，一度以为这三者又是什么三选一的“标准大战”——就像当年VHS和Betamax争录像带格式一样。后来把三方的协议日志同时打开，跟踪了一轮真实任务才发现，这个“三足鼎立”完全是我脑补出来的。它们不仅不互斥，反而像三根接力棒，在一套AI应用里各跑各的赛段。

这篇文章想把这三根接力棒到底怎么传的讲清楚，顺便聊聊各自容易踩的坑。如果你正在用Claude Code、Codex这类Agent工具，或者你在给团队搭AI辅助开发环境，又或者你只是想搞明白“MCP是什么”“LSP在AI编程里有什么用”“ACP为什么要存在”，这篇应该能帮你把这些碎片拼起来。

1. 三个高频缩写，三件完全不同的事

先说结论：MCP、ACP、LSP虽然都叫Protocol，但它们解决的是三个完全不同层面的通信问题。我在很多讨论帖里看到有人问“MCP会不会取代LSP”，或者“ACP是不是MCP的升级版”，说实话，这类问题本身就问错了方向。就好比问“USB接口会不会取代方向盘”——这俩根本不解决同一个问题。

1.1 一张表看明白三者的定位差异

从这个表就能看出来，它们根本不是同一次比赛里的对手。LSP是“编辑器—语言”的接口，MCP是“模型—工具/数据”的接口，ACP是“客户端—Agent”的接口。三者的“协议”都是形容词，但修的对象完全不同。

1.2 一个容易令人混淆的原因：它们都在处理AI应用中的“上下文”

为什么大家会把三者放在一起比较？我琢磨了一下，因为它们都在回答同一个大问题：AI程序需要的信息/动作，到底怎么在进程之间传递？

• LSP传递的是代码语义信息：这个符号在哪里定义、这段代码有没有语法错误、当前函数有哪些引用。
• MCP传递的是模型与外部世界的调用：模型需要查订单表，就通过MCP去调用数据库工具，拿回查询结果。
• ACP传递的是用户与Agent之间的任务信息：用户发来一句话，Agent在后台思考并执行，然后把思考进度、工具调用请求、最终结果回传给前端。

理解了这个区别，你就会明白为什么我强烈反对把它们看成替代关系。真正合理的视角是：它们各自处于AI应用协议栈的不同层位，相互之间还有协作接口。接下来逐个拆开看。

2. LSP：八年前终结编辑器插件乱局，如今成了AI读懂代码的“视觉皮层”

LSP可能是三者中最“老古董”的一个，但在AI编程时代，它的价值反而被重新放大了一轮。不夸张地说，现在你用的AI补全、AI问答工具，多半在后台偷偷踩在LSP的肩膀上。

2.1 2016年之前：每个编辑器都要为每种语言写N套插件

回到2016年之前，做过编辑器插件的人应该都懂那种痛苦。VS Code要支持Python，得写一套Python插件；Vim要支持Python，又得写一套Python插件；Emacs、Atom、Sublime各自再来一套。对语言作者来说更痛苦，他发布一门新语言，光是给主流编辑器各写一遍语法高亮、补全、诊断的适配，就能耗掉一个团队半个月。

LSP的破局思路很有意思：把“语言能力”单独抽成一个进程——language server，编辑器只负责当好客户端。两者约定一套统一的JSON-RPC 2.0消息，从此语言作者只需要写一次server，所有遵循LSP的编辑器都能直接用。这等于把所有编辑器拉进了同一个“通用插座”。

2.2 LSP的一次握手：initialize到shutdown的生命周期

LSP的生命周期控制得相当严格，核心流程可以简单理解为：

1. 编辑器启动一个语言服务器进程，通常通过stdio连接。
2. 编辑器发送initialize请求，跟服务器做能力协商——服务器告诉编辑器：“我支持补全、诊断、跳转，但我不支持重命名。”
3. 双向确认之后，编辑器发initialized通知，表示“可以开始干活了”。
4. 用户打开文件时，编辑器发textDocument/didOpen；编辑时发textDocument/didChange。
5. 编辑器按需发textDocument/completion、textDocument/definition、textDocument/references这类请求。
6. 结束阶段，编辑器发shutdown和exit，服务器退出。

一个典型的initialize请求长这样：

{ "jsonrpc": "2.0", "id": 0, "method": "initialize", "params": { "processId": 12345, "rootUri": "file:///home/user/my-project", "capabilities": {} } }

服务器返回它支持的能力范围，比如textDocumentSync、completionProvider、definitionProvider等等。这些消息全是JSON-RPC 2.0，格式统一，边界清晰。

2.3 AI编程时代，LSP为什么反而更重要了

很多人以为AI编程工具是“大模型直接看代码”，其实不完全对。LLM直接吃纯文本有个致命问题：它分不清一个标识符到底是本地变量、类成员还是系统API；它也不知道某个符号在整个工程里的引用关系。如果只把文件原文塞给模型，它经常把同名变量搞混。

这时候LSP的价值就体现出来了。现在的AI代码补全和AI问答工具，很多会作为LSP客户端接入语言服务器，通过textDocument/references拿到“这个函数的所有调用方”，通过textDocument/definition拿到“这个变量在哪里定义”，通过textDocument/diagnostic拿到“当前文件的编译错误”。这些语义级上下文被拼进prompt之后，模型的理解准确率会提升一个档次。

我实测过对比：不给LSP上下文，让AI直接解释一个跨文件的函数调用链，它经常一本正经地编出一个不存在的调用关系；给了LSP返回的符号表、引用集合之后，解释基本能对应上真实代码。可以这么说，LSP在AI时代变成了“AI读懂代码的视觉皮层”——模型自己看不见代码结构，是LSP替它看见了。

2.4 LSP的局限：它是为“人看IDE”设计的，不是为“Agent跑任务”设计的

但LSP不是万能的。它返回的消息是给编辑器UI渲染用的——组件hover内容、跳转目标位置、诊断列表。AI Agent想要的是“可以作为一条指令执行的结构化动作”，比如“把文件里所有排序接口的入参校验逻辑统一重写”。LSP给不了这个，它只是一个语义管道，不负责任务编排。

另外，语言服务器吃资源是个老问题。rust-analyzer索引一个大型monorepo，内存经常几个GB起步；TypeScript语言服务器在超大前端工程里也容易卡。这个我放到后面“踩坑”部分专门说，这里先记住一个观点：LSP是必要的底层设施，但它是“工具”，不是“统治者”。

3. MCP：把大模型变成一台可以外接设备的主机

如果说LSP是八年前埋下的基础设施，那MCP就是过去一年里AI应用生态最大的变量。从热度和生态上看，MCP几乎是火箭式增长，甚至一度让人觉得“不会MCP就不配叫AI工具”。

3.1 MCP出现之前：每接一个数据源，都要写一套胶水代码

两年前想让大模型查一次数据库，是个什么体验？你至少得经历这些环节：选一个模型后端，拿它的function calling接口写工具定义，把SQL语句作为参数传入，然后再写回调处理返回结果。换一个模型平台，这套定义方式可能全变；换一个数据源，又得重写一套。你写的不是“业务代码”，而是无穷无尽的适配层。

Anthropic在2024年11月开源MCP，目标非常明确：让模型和外部工具/数据源之间的连接变成标准化的“插座”。这个思路被很多人称作“AI应用的USB-C接口”。有了MCP之后，工具提供方只需要写一次MCP Server，任何支持MCP的客户端都可以调用它，而不是为每个模型单独做适配。

3.2 MCP的架构与三个核心原语

MCP的架构分三层：Host（宿主应用，比如Claude Desktop、一个IDE插件）、Client（宿主内部维护的MCP客户端连接）、Server（独立的工具/数据服务进程）。

在协议内容上，MCP定义了三个核心原语，我分别打个比方：

• Tools：这是模型可以主动“调用”的行动。好比给模型装了一双手，它能按按钮、拉杆、拿东西。典型例子是执行SQL、读文件、调API。
• Resources：这是模型可以“读取”的数据。好比给模型开了几扇窗户，让它能看到数据库里的记录、配置文件内容、外部文档。
• Prompts：这是可复用的提示词模板。好比给用户准备了一套标准化表单，用户勾选几个选项，就能生成一段结构化的指令。

其中Tools是大家用得最多、也最容易理解的。下面是一个简化的MCP请求/响应，演示“AI调用数据库查询工具”这个动作：

// 客户端 → MCP Server { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "query_orders", "arguments": { "sql": "SELECT count(*) FROM orders WHERE status='failed' AND created_at > now() - interval '7 days'" } } } // MCP Server → 客户端 { "jsonrpc": "2.0", "id": 1, "result": { "content": [ { "type": "text", "text": "{\"count\": 137}" } ] } }

这个流程里，模型不需要知道你的数据库密码，不需要了解你的内网拓扑，它只是通过MCP这个“公用车钥匙”向Server发出了一个经过授权的请求。

3.3 MCP的传输方式：stdio和Streamable HTTP

MCP早期主推的是stdio传输，也就是客户端直接启动一个本地Server进程，通过标准输入输出进行JSON-RPC通信。这种方式好处是安全、隔离、简单，尤其适合本地的文件操作、命令行工具类MCP Server。你现在在Claude Desktop或各种IDE插件里配置一个本地MCP Server，绝大多数走的就是stdio。

后来随着云端Agent和远程服务增多，MCP支持了Streamable HTTP传输，Server部署成一个HTTP端点，客户端通过网络请求访问。配置MCP Server时，填“stdio类型”需要给出启动命令，填“http类型”需要给出URL和鉴权信息，这两者千万别搞混——我在后面踩坑章节会详细说。

3.4 为什么MCP能迅速被Figma、数据库、蓝湖等接走

MCP生态能爆，核心原因是它太“省事”了。对工具方来说，我只要写一个标准的MCP Server，所有支持MCP的客户端都能调用我，不用为OpenAI写一套、为Anthropic写另一套。对模型应用方来说，我只要实现MCP Client协议，就能接上所有生态里的工具，不用每个工具定制开发。

Figma MCP就是典型的例子：设计稿的结构、图层、样式都通过MCP暴露给大模型，AI就能直接分析设计稿并生成前端代码。蓝湖、各类数据库MCP Server也纷纷跟进。你甚至能看到很多文章在教“Java将REST接口发布为MCP”，本质上就是给老服务套一层MCP外壳，让它能被AI调用。

很多人问“MCP怎么被调用的”，其实可以简单理解成：模型生成一个符合MCP协议的tools/call请求，发到MCP Client，Client转发给对应的MCP Server，Server执行完毕后把结果原路返回。模型本身不需要关心Server内部的实现细节，它只需要知道“有一个名叫query_orders的工具，参数是SQL字符串”。

3.5 MCP和function calling的区别

这里顺便把另一个高频问题说透：MCP不是function calling的替代品，两者根本不在一个抽象层级。

Function calling是模型API内部的一个特性，它让模型学会在回复中夹带“工具调用标记”，由应用层去执行。它解决的只是“模型怎么把调用意图表达出来”这一小段。MCP解决的是“工具怎么被描述、怎么被发现、怎么被调用、怎么被授权”这一整条链路。你可以把function calling看成是一个具体实现，把MCP看成是一套完整的“工具协议生态”。

4. ACP：给Agent装一套“方向盘与仪表盘”

如果说MCP让模型“长了手”，那ACP就是让Agent“有了驾驶舱”。ACP目前名气不如MCP大，但如果你用IDE去连接Codex CLI或Claude Code这类Agent，你其实已经间接在用它的逻辑了。

4.1 ACP要解决什么问题：Agent CLI进IDE的适配之痛

2025年，Agent命令行工具开始爆发：Codex CLI、Claude Code、Gemini CLI……它们能在终端里自主完成读文件、改代码、跑测试、提交PR这一串动作。但问题也来了：用户并不总想待在终端里。如果我想在VS Code里选中一段代码，让Claude Code去分析并修改，怎么办？

最原始的做法，是为每个Agent CLI写一套IDE插件适配器。Codex接入VS Code写一套，Claude Code接入VS Code再写一套；Codex接入JetBrains又得写一套。这跟LSP出现前编辑器插件各自为政的混乱几乎一模一样。ACP的目的，就是把客户端应用（IDE、Web UI、移动端）和Agent之间的通信方式标准化。

ACP的几位关键推手是Sourcegraph和Block（原Square），随后得到了包括OpenAI在内的生态支持。它被设计成一套基于JSON-RPC 2.0的双向协议，一个ACP会话里可以承载Agent的完整生命周期：从初始化、创建会话、发送用户提示，到Agent返回状态事件、发起工具调用请求、客户端执行并把结果回传。

4.2 一次ACP会话的简化消息流

下面这个流程我做了简化，不同实现会有方法名差异，但不影响理解整体结构：

1. 客户端启动Agent进程，通过ACP的initialize握手，协商双方能力。
2. 客户端发送session/new，Agent返回一个唯一的sessionId。这一步相当于“开了一条独立的对话车道”。
3. 客户端发送session/prompt，把用户选中的代码、上下文和指令交给Agent。
4. Agent开始工作后，持续返回事件流：包括状态更新（“正在搜索定义”）、消息内容、以及工具调用请求。
5. 当Agent想修改文件或执行命令时，它不直接做，而是通过ACP向客户端发送一个“工具调用请求”。这一步是整个ACP的核心设计——真正的环境操作权保留在客户端。
6. 客户端弹窗让用户确认，用户同意后，客户端执行真正的写文件/跑命令动作，再把结果通过ACP回传给Agent。
7. 任务完成后，可以继续发session/prompt，或者发session/close回收会话。

换句话说，ACP的“Agent”本身是很克制的：它规划任务、生成决策，但实际动手必须让客户端来。这么做的好处是安全可控，坏处是如果你直接用一个纯CLI去连Agent，不经过任何客户端适配，那ACP根本没用——你缺了一个“驾驶舱”。

4.3 “failed to initialize acp session”这类报错背后，是谁在作妖

很多人在IDE里配置Agent时会碰到形如：

failed to initialize acp session. error: internal error: "already initialize"

这种报错我排查过好几次，问题几乎都出在会话生命周期的管理上。ACP的session/new跟LSP的initialize不一样，它不是一次性握手死了就完事，而是在一个长连接里可以创建多个会话。常见踩坑原因有几个：

• 客户端代码在每次发消息前都调用了一次初始化逻辑，结果第二次初始化时发现“你已经有session了”，于是报already initialize。
• 某个插件在IDE窗口加载和激活时被调用了多次，导致同一个transport上重复new session。
• Agent进程其实已经异常退出过，但客户端的会话缓存没清，导致恢复连接时拿着旧sessionId又去初始化，撞上了“already initialize”的内部状态。

我的经验是：先把transport和session分开看待。Transport是长连接，进程活着就一直复用；Session是“一次对话任务”的容器，复用一个session去继续对话是合理的，但没有必要反复初始化。代码里如果要写Agent连接层，应该保证初始化逻辑只执行一次，后续发prompt都往同一个session里塞。

4.4 ACP与LSP、MCP的分工：带状态的LSP，还是带方向盘的外设总线

ACP经常被拿来和LSP类比，因为它俩确实像：都是“客户端—服务端”架构，都用JSON-RPC 2.0，都有清晰的协议边界。但两者有个本质差异。

LSP处理的是无状态的查询：你问我一个符号在哪里定义，我回答你位置，这中间没有“改代码”的动作。ACP处理的是有状态的持续任务：你让我修复一个bug，我需要读文件、改文件、跑测试、看到测试结果、再迭代修改。这个循环里有状态、有上下文、有多次工具调用的反馈。

跟MCP的区别也很明显。MCP的“工具调用”是模型发起的、面向外部系统的一次性数据/动作请求，它不管谁在驾驶全局；ACP的“工具调用”是Agent把具体的环境操作请求提升到客户端，让客户端负责执行和授权。放一起看，ACP更像“方向盘与仪表盘”，MCP更像“USB-C集线器”，LSP则像“后视镜和车窗”。

5. 一条真实链路：一次AI改bug任务里三条协议的分工

纸上谈兵没什么意思。我拿一个我曾经反复配置过的真实场景，完整走一遍三条协议怎么配合。

场景是这样：我在IDE里接了一个Agent类型的编程助手，这个Agent能自主规划并修改代码。Agent侧配置了一个MCP Server，用来查询团队业务数据库。IDE本身还挂着语言服务器，比如Pyright或rust-analyzer。用户选中一个函数，然后输入指令：“找出get_order()的所有调用方，顺便查一下最近7天失败订单数量，最后把结论追加到运行日志里。”

整个过程可以拆成这样：

1. IDE通过ACP的session/prompt，把选中的代码、文件路径、用户指令发给Agent进程。
2. Agent内部开始规划，它第一步要搞清楚get_order()到底被哪些地方调用了。它不能靠肉眼扫，它向IDE的LSP客户端发起一个textDocument/references请求。
3. LSP语言服务器在后台建立代码索引，返回所有引用位置列表。Agent拿到这些位置之后，把它们作为上下文继续推理——它终于知道改动会影响哪些地方。
4. Agent发现还需要查数据库，于是通过MCP Client调用配置好的“订单查询”MCP Server，发送tools/call请求，带上SQL参数。
5. 数据库MCP Server执行查询，把失败订单数量返回给Agent。
6. Agent综合代码引用和数据库结果，生成总结，并通过ACP事件流把“写运行日志”的工具请求返回给IDE客户端。
7. IDE弹出审批框，用户点击允许后，IDE真正执行文件追加操作，再把结果通过ACP回传给Agent，Agent收尾结束。

是不是发现，这三条协议其实互不打扰，但缺了谁都会出事？

• 如果LSP没配好，Agent会拿不全引用关系，它修改get_order()调用方时漏改一两个地方，bug照样在原处。
• 如果MCP Server超时，Agent拿不到订单数据，它可能会在日志里写一段“看起来很像真的”的猜测数字。
• 如果ACP会话断开，最直观的体验是：Agent实际还在后台跑，但IDE界面上没有任何响应，像卡死了一样。

所以我的选型建议其实很简单：想让编辑器里的AI工具“看懂代码”，先检查LSP接口通不通；想让模型拿到外部数据或调用外部系统，去配MCP；想让Agent能被任意前端接入、被好好管理生命周期，再考虑ACP。三者不存在互相替代的关系，只存在你需不需要的问题。

6. 协议栈里的坑：session初始化失败、server超时、LSP吃内存

协议这块我踩过的坑不算少。下面挑三类最有代表性的问题，给出我自己的排查路径，不一定全，但能帮你在踩坑时省点时间。

6.1 MCP Server超时或“连接不上”

症状一般是：AI在回答时提到“工具调用失败”，或者面板里直接报MCP Server connection closed。

排查步骤我会从三层递进：

1. 传输层：如果你配置的是stdio，确认启动命令里的路径是绝对的，虚拟环境路径别写错，工作目录也要配对。Windows下尤其注意Python环境路径。如果你配置的是Streamable HTTP，确认URL没漏掉版本前缀，例如/mcp这类路径。
2. 协议层：确认传输类型没选反。stdio对应的是本地进程，http对应的是远程端点。见过很多人把本地MCP Server填成http://localhost然后请求一直pending，其实类型选错的话，请求根本发不到对的地方。
3. 业务层：MCP Server进程本身有没有崩溃？最简单的方式是用MCP Inspector这类调试工具直接手动发起tools/list，如果手动调用都失败，那就是Server自身的问题，跟AI客户端无关。

我遇到过的最高频原因是stdio配置里没有写--stdio参数，导致Server以某种待机模式启动后既不接受输入也不输出，客户端等半天超时。

6.2 ACP session重复初始化

前面提到的failed to initialize acp session...already initialize，我给出一个可复现的排查链路：

1. 打开Agent进程的日志，看是哪个模块触发了第二次初始化。
2. 检查客户端代码里session/new的调用点是否在“每次发送消息”的执行路径上。如果是，把它挪到连接建立之后只执行一次。
3. 检查IDE插件或客户端工具是否在“窗口加载”和“命令面板激活”两个时机都执行了一遍初始化。这种情况常见于插件开发者没有做幂等保护。
4. 如果Agent进程本身卡在异常状态，重启进程再试，别想着复用旧session。

这类问题的根源通常是“状态管理不严谨”。LSP时代大家习惯了无状态查询，到了ACP这种有状态协议，很多人还按老思路在每次交互前初始化一遍，不出错才怪。

6.3 LSP服务器内存吃满、启动慢

用rust-analyzer或者TypeScript语言服务器的人，应该都见过内存飙到几个GB的场面。解决方案不一定是一味加内存，我常用的几个有效手段：

• 缩小工作区：LSP的workspace越窄，索引越快。如果项目是monorepo，试试只加载跟你当前代码相关的子工程。
• 配置语言服务器的文件排除规则，把vendor、node_modules、target这类目录排除在索引范围外。
• 按需启动：改成平时不启动语言服务器，等AI工具或用户主动需要语义信息时才启动。这样一来，很多“后台吃内存”的情况就消失了。

在AI编程的场景里，LSP吃内存的痛点会被放大，因为AI工具可能会在后台频繁请求语义上下文。我的建议是给语言服务器单独设一个较高的资源上限，同时把不相关的排除项配好，别让它在无关目录上白白建索引。

6.4 通用排查法：先分传输层、再查协议层、最后看业务层

这三类问题的排查思路其实是通用的。我建议你在面对任何“协议相关”的问题时，都按下面的三层清单过一遍：

大方向上，协议对接的问题九成出在传输层和协议层，业务层反而没那么容易出问题。因为MCP、ACP、LSP这类协议的消息格式基本都是JSON-RPC 2.0，结构不难，难的是“哪个进程在维护那个连接”“生命周期谁在管”“路径有没有写对”。

7. 三足鼎立会变成一统天下吗：开发者当下怎么选

写到最后这部分，很多朋友关心的是：这三种协议会不会统一成一种？现在学哪个最划算？

我的判断是：短期不会出现“大一统”协议替代三者。原因不复杂——三者绑定的上下文完全不同，硬塞到一起只会让协议变得无比臃肿。LSP如果你的目标是做一款编辑器插件，那LSP直接给AI提供语义上下文；MCP如果你是给AI应用接数据源和工具，MCP是一等公民；ACP如果你想把Agent接入不同的前端，并且需要完善的会话管理，那值得花时间深入研究。

7.3 标准格局与生态现状：老邻居、新基建、新玩家

从标准化进程来看，LSP已经稳定多年，版本迭代虽然不快，但生态相当扎实，所有主流编辑器、语言服务器都按它来。MCP在2024年底开源后迅速得到OpenAI、Google等官方生态支持，2025年基本坐实了“模型—工具”层的实际标准。ACP起步最晚，但方向明确——它瞄准的是Agent基金会与可移植性的空白，已经在Codex CLI等实际产品中出现了落地案例。

这三者就像是城市交通里的“老路网”、“地下管道”和“自动驾驶调度系统”：老路网（LSP）为所有车辆提供基础通行能力；地下管道（MCP）为城市供能送水；自动驾驶调度系统（ACP）则让车辆能自主决策、和指挥中心通信。三条系统各自进化，但谁也取代不了谁。

我个人的体会是，协议这种东西，真正让人放心的不是“标准”这个词，而是“调试入口”。MCP你可以用Inspector手动试；ACP你可以用日志跟踪session生命周期；LSP你可以开trace看每次请求耗时。这三个“入口”比背规范更有用。所以如果你现在有点被这些缩写搞晕，我的建议很简单：不要急着读全规范，先在自己最常用的AI工具里，打开它的协议日志窗口，跑一个任务，看看MCP、ACP、LSP各发了几条消息。那个画面一亮起来，你瞬间就懂了这些协议到底是什么。