企业官网建设流程全解析

1. 项目缘起：一次原本以为只是“装个插件”的 MCP 接入

收到这个需求的时候，我第一反应是：MCP 不是有官方 SDK 吗？找个现成的 Server 装上，在客户端里填一行配置，最多半小时就能跑通。等到真动手，才发现“接入 MCP”这件事有个巨大的前置条件——你要接进去的那套工具链，可能同时存在于设计稿、浏览器、数据库、测试工具好几个不同的技术栈里。从方案澄清做到端到端验证，整整花了一周多，其中有一大半时间不是卡在“调用代码”上，而是卡在“接口边界没分清”和“验证方式不统一”上。这篇文章就是这次跨栈 MCP 接入的完整复盘。

先说清楚 MCP 到底是个什么东西。Model Context Protocol（模型上下文协议）是这两年 AI 工具链里最值得关注的一个开放协议，它解决的是“AI 应用怎么访问外部工具和数据”的问题。你可以把它理解成 AI 世界的 USB-C 接口：没有它之前，每个 AI 应用接入外部系统都要单独写一套私有接口；有了它之后，Host、Client、Server 三方按一套标准协议对话，工具接入就变成“插上去就能用”的过程。实际落地时最常见的宿主是 Claude Desktop、Cursor、Codex CLI 这类 AI 工具，它们充当 Host；Host 内置 MCP Client，负责与 Server 建立连接、管理会话；Server 则负责真正暴露工具、资源、提示词。一个典型的调用链路是：AI 模型在对话中判断需要调用工具，Host 里的 Client 向 Server 发出 tools/call 请求，Server 执行完把结果回传给模型，模型根据结果继续生成回复。

为什么这次特别麻烦？因为“跨栈”二字。我们的目标不是接入某一个 MCP Server，而是要把设计稿（蓝湖/Figma）、浏览器自动化（Playwright/Chrome DevTools）、本地资源（文件/MySQL）、安全测试工具（Burpsuite/Yakit）这几类能力统一接入同一个 Agent 工作流。每一个栈背后是完全不同的协议习惯、认证方式和部署形态，单拎出来哪个都不难，合在一起就变成了一次典型的边澄清边落地的过程。这篇文章我会按“先澄清 → 再选型 → 后验证 → 最后看生产问题”的顺序来写，既适合正在做 MCP 接入方案的技术负责人参考，也适合自己写 MCP Server 的开发者做对照。

2. 方案澄清阶段：把“MCP 接入”从口号翻译成工程需求

2.1 先分清三端角色，别让“接入”这个词背锅

很多人一开始会把“MCP 接入”理解成“让某个工具支持 MCP”，这是个误区。MCP 从来不是一个工具单方面的事情，它至少涉及三端：Host、Client、Server。实际协作中，这三端往往由不同的人负责。Host 一般是产品确定的，比如团队决定用 Cursor 还是 Codex CLI，这不是我们控制的；Client 是 Host 内置的，虽然协议同一套，但每个 Host 的配置方式、超时策略、资源管理模式各有差异；真正需要大量开发的，通常是 Server 侧，以及 Host 侧的配置文件。

我们在方案澄清时做的第一件事，就是画清楚“谁负责什么”。拿浏览器自动化来举例：Playwright MCP 是 Server，它负责把浏览器控制能力暴露出来；Cursor 是 Host，它内置的 MCP Client 负责与 Playwright MCP 进程通信；而真正决定“浏览器操作到什么程度、允许访问哪些域名”的是 Server 的配置和工具定义。如果这三层没有在方案阶段对齐，后面一定会出现这种情况：开发把 Server 部署好了，配置也能连上，但 Client 发现不了工具，或者工具发现了却调用失败，最后两边互相甩锅。澄清的作用就是消灭这类边界模糊。

2.2 盘点技术栈：不是所有东西都适合做成 MCP Server

第二个澄清动作是盘点“到底哪些栈要接”。这里我要给一个反直觉的提醒：MCP 解决的问题是“让 AI Agent 能够按需调用工具”，不是“让所有系统都暴露 MCP 接口”。有些系统适合接入，有些接入就是纯粹给自己找麻烦。我们当时的盘点维度有三个：第一，这个系统是否需要被 AI Agent 自主调用；第二，调用过程是否需要处理上下文之外的实时状态；第三，改造的成本是否小于直接写专用脚本。

按这个维度梳理下来，设计稿、浏览器、本地文件、数据库、安全测试工具都是高价值接入对象，因为它们都符合“AI 需要获取外部状态并做出动作”的特征。而像内部项目管理系统的审批流，当时也有人提议接 MCP，我们最后否决了——审批是一个强约束、强审计的流程，让 Agent 直接触碰审批逻辑风险太大，不如保留人工操作入口。这个判断在后来的验证阶段被证明是正确的，少了一个高风险暴露面。

2.3 澄清后的验收矩阵：把需求拆到能逐条打勾

方案澄清的最后一步，是把“接入 MCP”翻译成可验收的条目。我们当时建立了四个验收等级，每个等级对应明确的验证动作，这一步非常关键，因为它是后面端到端验证的裁判标准。

这套矩阵的价值在于，它把“能不能用”拆成了“能不能启动、能不能发现、能不能调用、能不能组合”四个层次。实际项目中，很多团队只验证到 MCP-02 就宣布完成，等真正让 Agent 自动跑任务时才发现工具调用数据格式对不上，或者上下文太长导致模型忽略工具结果。我们的经验是：MCP-03 和 MCP-04 必须在方案阶段就写进验收清单，宁可前期多花时间，也不要交付一个“看起来连通了，实际没法干活”的半成品。

3. 工具选型复盘：每个栈的 MCP 实现都有自己的脾气

3.1 设计稿侧：蓝湖 MCP 与 Figma MCP，选型关键是“交付物”

设计稿接入是这次项目里争议最大的选型，因为团队里同时存在两条工具链：UI 同学用 Figma，公司内部交付规范却统一走蓝湖。两个平台的 MCP 能力都成熟，但“接入以后 Agent 能拿到什么”完全不同。

先看蓝湖 MCP。蓝湖的核心是设计交付和协作，它的 MCP 能力偏重把设计稿里的切图、标注、版本信息直接输出给 AI Agent，尤其适合“设计稿已经上传到蓝湖、团队以蓝湖为唯一事实来源”的场景。Chrome 扩展配合本地服务的方式接入，在蓝湖官方文档里有标准流程。它最大的好处是符合国内团队的设计交付习惯：你不需要让 Agent 去解析 Figma 文件结构，只需要对蓝湖的标注数据做标准调用，拿到什么就是什么。

再看 Figma MCP。Figma 官方开放的 MCP 接口可以直接读取 Figma 文件、画板、样式变量，也支持直接切图导出——这正是热搜里“Figma MCP 可以直接切图吗”对应的能力。但要注意两个问题。第一是费用：虽然 MCP Server 本身开源，但底层依赖 Figma REST API 的调用额度，高频率调用很可能会触发付费配额，方案阶段没有评估清楚，后面很容易被打个措手不及。第二是数据边界：Figma MCP 拿到的图是源文件里实时的，但国内多数团队的交付流程里，Figma 源文件并不是所有人的“唯一事实来源”，接入前必须先确认 AI Agent 读到的数据和产品、开发看到的一致。

我们最终的选择是双轨并行：设计稿走蓝湖 MCP 作为正式链路，Figma MCP 作为项目早期探索阶段的临时手段。这个决定后来被证明是对的——正式链路的数据稳定性好，Figma 那条路因为 API 配额问题差点超支，幸好只是试用。

3.2 浏览器侧：Playwright MCP 与 Chrome DevTools MCP，别搞混定位

浏览器自动化是这次跨栈接入里的重头戏。这一类目下有两个知名度最高的实现：Playwright MCP 和 Chrome DevTools MCP。很多人会把它们混为一谈，觉得都是“让 AI 操作浏览器”，实际用起来定位差异非常大。

Playwright MCP 是微软提供的官方实现，本质是把 Playwright 的自动化能力包装成 MCP 工具。它的强项是“面向任务的自动化”：AI 可以驱动浏览器打开页面、填表单、点击按钮、截图、等待网络请求，甚至执行断言。团队里做 Web 端测试的同学对它最熟悉，因为它和已有的 Playwright 测试体系天然兼容。接入方式也很简单，在 MCP 配置里指向@playwright/mcp的启动命令即可，工具列表会一次性暴露几十个操作类型，非常丰富。

Chrome DevTools MCP 则是另一条路线。它通过浏览器扩展与 DevTools 协议对接，把调试能力暴露给 AI Agent。这里就涉及一个热搜词里反复出现的配置细节：你需要在谷歌浏览器扩展设置中启用“MCP 连接”，然后本地启动配套 Server，AI Agent 才能通过 DevTools 观察真实浏览器的 DOM、网络、性能数据。它的场景更偏“诊断观察”，而不是“自动执行测试流程”。如果你要的是“让 AI 自己把登录流程走一遍”，选 Playwright MCP；如果你要的是“让 AI 实时分析某个页面的性能瓶颈”，Chrome DevTools MCP 更贴切。

另外一个容易被忽略的接入选型，是类似browserskill、agent browser这类更上层的浏览器 Agent 框架。它们通常也兼容 MCP，但内部往往自带一套任务规划和浏览器控制逻辑，如果团队已经有这类基建，再额外接一套 Playwright MCP 就会导致能力重叠。选型时关键的判断标准不是“谁的 star 多”，而是“这个工具在 Agent 工作流里是充当执行器，还是充当规划器”。执行器交给 MCP 工具即可，规划器应该留在 Agent 框架层，别把层叠得太多。

3.3 本地资源侧：文件系统与 MySQL，自建 Server 的常识

本地资源是这次跨栈接入里最“接地气”的部分，但坑也不少。文件系统场景可以直接用官方 filesystem Server，配置一条命令就能让 Agent 读写指定目录。开机就跑的方案，但一个很容易被忽视的细节是：官方 Server 默认暴露的是stdio传输，也就是说它只能由本地进程拉起，不能通过网络被远程 Host 访问。如果团队里有人想把它部署到服务器上供远程 AI 客户端调用，就需要自己包一层 HTTP/SSE 传输，不能再拿官方 npx 命令直接怼上去。

MySQL 接入我们一开始想找现成的社区 Server，但试了几个都有兼容性问题，最后干脆自己写了一个轻量 Server。核心逻辑并不复杂：用 MCP SDK 声明一个query工具，接收 SQL 参数，连接数据库执行，然后以结构化文本返回结果。这个实现过程本身不复杂，但有一个安全细节值得所有人注意：让 AI Agent 直接执行任意 SQL 极其危险，我们最终加了一层“仅允许 SELECT / SHOW / EXPLAIN”的白名单过滤，并在 DSN 里配置只读账号。千万不要让 Agent 用高权限账号连接生产库，这句话值得写进每一个 MCP 接入方案的注意事项里。

3.4 安全工具和其他专业软件：扩展场景的接入注意点

这次项目还遇到一个特殊需求，是把安全侧的工具接入 MCP。Burpsuite MCP 和 Yakit MCP 都属于“把安全测试能力暴露给 AI Agent”的实现，方便在自动化流程里做接口扫描和基础检测。接入逻辑本身不复杂，但必须由专门的测试人员来把关工具权限和扫描范围，不能把所有工具无差别开放给所有 Agent。这是一个安全与效率的平衡问题，我们不展开具体攻击手法，只强调接入规范：工具白名单、目标域名白名单、操作审计日志，这三样缺一不可。

除安全工具外，垂直行业的 MCP 生态也值得关注。比如 Blender MCP 把 3D 建模操作暴露给 AI，Cesium MCP 让 Agent 能读取三维地理空间数据，IDA Pro MCP 则服务于逆向分析场景。这些例子说明 MCP 正在走出“浏览器+文件”的早期范畴，变成跨行业通用标准。对我们做基础架构的人来说，这意味着方案设计必须考虑抽象层：不要为某一个工具的 MCP 实现写死代码，而是通过统一的 Server 注册和配置管理来隔离差异。

4. 端到端验证：从 Server 能启动，到 Agent 真的干活

4.1 四段式验证链路：每一段都能单独失败

端到端验证是整个复盘里最有价值的一段，因为真正暴露问题的不是“Server 能不能启动”，而是“整条链路能不能被 Agent 顺畅地走通”。我把验证拆成四段，分别对应方案澄清阶段列出的四个等级，每一段都有独立的失败模式和排查方向。

第一段是协议握手。MCP 连接建立后，Client 会先发送initialize请求，交换协议版本和能力声明，完成后才能继续。这一段的失败通常表现为“连接建立但工具列表为空”，原因是协议版本不兼容或 Server 能力声明有问题。第二段是工具发现，也就是tools/list。这里失败多半是 Server 没正确注册工具，或者注册的工具参数描述不规范。第三段是单工具调用，发一个tools/call，直接验证返回结构。第四段才是真正的跨栈组合，让 Agent 自主规划并连续调用多个工具。我们的经验是：前三段可以用脚本验证，第四段必须放在真实对话里测，因为主动权在模型手里，它可能不按你预想的顺序调用工具。

4.2 一次完整链路：从设计稿到浏览器回归验证

分享一个实际的端到端验证案例。当时的需求是：Agent 根据蓝湖设计稿里的一个新按钮样式，自动在测试环境上打开对应页面，确认按钮是否已经上线。这条链路串联了三个栈：蓝湖 MCP、文件系统 MCP、Playwright MCP。

验证过程是这样的：Agent 先调用蓝湖工具，拿到设计稿里按钮的颜色、尺寸、文案标注；接着调用文件系统工具，读取前端项目里对应的样式文件，对比设计稿和实现代码的差异；最后调用 Playwright 工具，在浏览器里打开页面，定位到按钮元素，截一张图作为证据。整个流程跑完，Agent 输出了一段总结：“设计稿标注为 #1677FF，项目代码为 #1890FF，页面实测为 #1890FF，建议前端调整色值。”这个结果本身不算复杂，但它是跨栈接线是否通畅的最好证明。

这个案例里真正有价值的不是结果，而是验证过程中的一个小插曲：第一轮跑的时候，Agent 明明调用了 Playwright 工具，但浏览器截图里没有出现页面内容。排查后发现是 Playwright MCP 的浏览器实例与测试环境登录态不一致。这个问题不属于 MCP 协议本身，而是属于“浏览器环境状态管理”。MCP 工具只是执行动作，它不帮你维护会话状态，如果你要验证的是登录后的页面，必须在调用链路的开头用一次自动登录操作来初始化会话。我们把这一步写进了 Agent 的 Prompt 提示词里，之后验证就稳定了。

4.3 超时问题：timed out after 30 seconds 到底卡在哪

跨栈验证阶段我们碰到的最烦人问题，是 Codex CLI 的报错：“mcp client for codex_apps timed out after 30 seconds”。这个错误在各类 MCP 接入场景里都很常见，它的直接原因是 Host 在 30 秒内没有等到目标 Server 完成初始化握手。

但“30 秒超时”只是一个表面现象，根因往往有三种。第一种是首次启动太慢：如果用npx -y这种方式动态拉取 Server 包，首次启动时需要下载依赖，30 秒很容易不够用。第二种是 Server 进程自身启动后没有及时进入监听状态，比如它内部还要初始化数据库连接池或者读取大文件配置。第三种是工作目录或环境变量不对，Server 启动后报错退出，但 Host 侧因为进程还挂着，只能等到超时才报错。

我们的处理方案分两步。第一步是“预下载”，把用到的 Server 依赖提前安装到本地，配置里直接用已经安装的包路径，而不是用 npx 现拉。第二步是“逐个验证启动时间”，给每个 Server 单独记录初始化耗时，超过 20 秒的就要并行优化启动逻辑，或者调整 Host 的超时参数。这里的关键认知是：MCP 接入不是一个“配置完就完事”的动作，你要把每个 Server 的启动时间当成一个可量化指标来管理。第一次跑通觉得慢没关系，但你不能在交付的时候还说“多试几次就能通”，那不是一个可交付的状态。

5. 日志、权限与信息闭环：从“能用”到“敢用”的距离

5.1 日志问题：stdio Server 的 stdout 是协议通道，不是日志通道

跨栈接入跑通以后，我们很快就被日志问题打了一记闷棍。事情是这样的：为了排查某个 Server 的异常，有人直接在代码里写了console.log("处理请求...")，结果一启动，整个 MCP 连接直接失败。原理其实很简单，stdio传输模式下，Server 的标准输出会被协议层当作 JSON-RPC 消息来解析，任何非协议内容的输出都会把通信通道污染掉。如果你用console.log打日志，那些文本会被当成非法协议消息，Host 端就会断开连接。

正确的做法是把日志输出到标准错误流（stderr），或者直接接入日志文件。以 Node.js 的官方 SDK 为例，console.error是安全的，因为 MCP 的 stdio 传输只占用 stdout。但更规范的做法是配置自定义日志管理：给 Server 设置独立的日志目录，按级别输出，并加上轮转策略。这个细节看起来小，但在跨栈场景里非常要命——你有五个 Server 在跑，如果每个的日志格式不统一，出问题的时候你根本没法快速定位是哪一环断了。我们在复盘时达成的共识是：任何 MCP Server 都必须明确三项日志能力，启动日志、请求日志、错误堆栈日志，三项分别可查可关。避免把所有信息混在一个输出流里。

5.2 权限边界与工具白名单：让 Agent 该干什么、不该干什么都写清楚

跨栈接入之后，Agent 的能力范围显著扩大了：能读文件、能查数据库、能操作浏览器、还能调用安全测试工具。权限边界如果没设计好，这不是“效率工具”，而是“事故放大器”。我们定了几条硬性规则：第一，本地文件系统只对指定目录只读开放，AI 不能写项目根目录之外的文件；第二，数据库账号务必使用只读账号，白名单只放 SELECT、SHOW、EXPLAIN；第三，浏览器自动化限制在测试环境域名范围内，允许列表内才可访问；第四，安全测试类工具必须有项目负责人单独审批才能启用。

这套权限边界的核心原则是“最小必要权限”，不是“能跑通就行”。MCP 协议本身并不区分“安全工具”和“危险工具”，它只负责把工具暴露给 AI，工具怎么用、能不能用、给谁用，完全由接入方控制。我们后来还在 Server 层加了一层调用审计，每次 tools/call 都会记录调用者、目标工具、参数摘要和时间戳。遇到问题时，这条审计链路帮我们快速还原了“AI 为什么干了这件事”。

5.3 跨栈信息流闭环：让数据在设计稿、浏览器、测试报告之间自然流转

端到端验证做完，我们最后思考的问题是“信息流闭环”。跨栈 MCP 的真正价值，不在于单次调用某个工具，而在于数据在一个工作流内部自然流转，形成闭环。比如：设计稿的标注数据被 Agent 读到，转成截图对比结论；浏览器自动化的执行结果被汇总，生成测试报告；测试报告里的日志状态被进一步交给 RAG 知识库做检索分析。这里 MCP 和 RAG 的分工值得多说一句：RAG 解决的是“静态知识怎么被模型检索到”，MCP 解决的是“实时状态怎么被模型按需访问”，两者不是替代关系，而是互补关系。

为了让这个闭环真正可用，我们在方案阶段定义了一套统一的“结果返回约定”：所有 Server 返回给 Agent 的内容，必须是结构化文本，包含状态标识和摘要信息。比如文件系统 Server 读取文件后返回“读取成功，共 320 行，首行内容为 ...”，而不是把整份文件全量塞进上下文。这个约定的好处是节省模型的上下文窗口，也让后续工具可以继续基于摘要做决策。很多跨栈方案最后做不下去，不是因为哪个工具接不通，而是因为没有统一数据格式，Agent 拿到一个栈的结果后没法直接作为下一个栈的输入。这不是协议问题，是工程规范问题。

6. 复盘结论：如果重做一次，我会改掉的四个决定

第一个要改的决定是“过早进入选型”。项目开始时，我们几乎是照着热搜词把各个栈的 MCP 工具都下载下来试了一遍，Figma MCP、Playwright MCP、蓝湖 MCP 每样都想跑跑看。这种探索有价值，但顺序反了。先做方案澄清，明确每个栈的接入边界和验收标准，再进入选型，效率会高很多。否则你会在选型阶段被工具的宣传话术带着走，最后发现真正卡住你的是业务侧的接口边界，而不是工具能力。

第二个要改的决定是“没有提前统一超时策略”。我们直到验证阶段被 30 秒超时问题打懵了，才回头去统计每个 Server 的启动耗时。如果方案阶段就把“启动耗时”、“连接超时”、“调用超时”这三类指标定出来，后面根本不会浪费半天排查。接 MCP 本质上是在接一个“随时可能自己挂掉的外部进程”，超时和重试策略必须是方案的一部分，不是上线以后才补救的事情。

第三个要改的决定是“日志规范出台太晚”。前面说过，console.log污染 stdio 通道的坑是我们踩了才知道的。现在回头看，应该在一开始就给所有 Server 定一个统一的日志规范：默认输出到文件，stderr 只保留启动级错误，并且预留结构化日志字段。这件事不花多少时间，但它在排障效率上的收益是长期的，尤其是当你有五个以上 Server 同时在跑的时候，没有统一日志就等于没有日志。

第四个要改的决定是“端到端用例定义得太晚”。我们直到验证阶段才真正写了跨栈组合用例，但早该在方案澄清阶段就把“设计稿 → 浏览器 → 测试报告”这类典型任务用例定下来。跨栈 MCP 接入的验收，标准从来不是“某个 Server 能连上”，而是“一条真实业务链路能通过 Agent 自主走完”。用例定义得越早，方案方向偏得越少。

这一周多的复盘给我的体会是：MCP 接入的技术门槛不算高，真正的门槛在于你想清楚接入之后的完整运行状态是什么样的。它像拼积木，每块积木本身很漂亮，但拼起来之后能不能站稳，取决于你一开始有没有把接口、权限、日志、超时这些底层的“卡扣”设计好。希望这篇复盘能帮你少走几步弯路。