企业官网建设流程全解析

最近 MCP 这个圈子突然热闹了起来，不是因为协议本身发了什么大版本，而是因为一件挺反常的事——网页本身也能提供 MCP 了。以前我们提到 MCP Server，脑子里默认就是本地进程：要么npx起一个 Node 服务，要么用 Python 跑一个脚本，通过stdio跟 Claude Desktop、Cursor 这类客户端通信。可这段时间你会发现，Figma 上了 MCP，蓝湖上了 MCP，MasterGo 也在布局，Blender、Unity、Cocos Creator 陆续接入，连很多纯网页服务都直接把 MCP 端点挂在了 URL 后面。你不需要在本地安装任何 agent 进程，只要在客户端里填一个https地址，就能让 AI 直接读取云端设计稿、操作 3D 场景对象、查询线上数据库。这篇文章就围绕这个现象展开，聊聊网页 MCP 的技术本质、为什么厂商愿意这么做，以及我实际搭建和接入过程中的一些经验和坑。

1. 先搞清楚一件事：网页 MCP 到底长什么样

1.1 MCP 不只是"又一个接口协议"

MCP 全称是 Model Context Protocol，模型上下文协议。翻译成人话，它就是 AI 应用访问外部数据的"USB 接口"。电脑要接键盘、鼠标、显示器，需要 USB 这样的统一接口；AI 助手要读文件、查数据库、操作设计工具，也需要一个统一协议，让"模型"和"工具"不用挨个做私有对接。

MCP 的核心概念其实不多，只要抓住三样：

• Tools（工具）：AI 可以按需调用的一组操作，比如"查询订单"、"创建文档"、"修改图层"。每个工具都有名字、描述、参数 schema，模型根据你的提问决定调不调、怎么调。
• Resources（资源）：暴露给 AI 的可读数据，类似 REST API 里的 GET 接口，比如给 AI 提供一份项目文档、一份配置文件的完整内容。
• Prompts（提示模板）：预先封装好的指令模板，让 AI 在特定场景下按照固定流程干活，比如"帮我按这个规范审查设计稿"。

这套设计最大的好处是：模型侧不需要关心工具背后的语言和框架，工具侧也不需要关心模型是哪一家。你装一个 MCP Server，理论上 Claude、Cursor、Dify、Cherry Studio 都能连。这就是它能在短短一年内从概念火到落地的根本原因。

但注意，MCP 并不是一个"万能的插件系统"。它解决的是AI 与数据/工具之间的连接，而不是 UI 自动化，也不是数据库同步。你在热词里会看到有人问 "computer use 和 MCP 的区别"，其实这两个东西层级完全不同：Computer Use 是让 AI 用视觉识别屏幕、模拟鼠标键盘去操作 GUI，本质是"把 GUI 当作人的界面来用"；MCP 是让 AI 用结构化接口直接读写数据，本质是"把系统能力做成可供模型调用的函数"。前者适合改不了源码的遗留系统，后者适合所有能开放 API 的现代产品。以后大概率是两者配合——MCP 负责高效路径，Computer Use 负责兜底。

1.2 从 stdio 到 Streamable HTTP：网页 MCP 的形态变化

回到标题，网页为什么能提供 MCP？关键在传输层的变化。

早期 MCP Server 默认走stdio，也就是客户端在本地帮你启动一个子进程，通过标准输入输出流跟这个进程通信。这种方式的好处是安全、隔离、免鉴权，特别适合"给我的编辑器装一个插件"这种单机场景。但它有个硬伤：服务必须跑到你的电脑上，数据必须存在你本地。你没法让团队共享一个 MCP Server，也没法把线上的设计稿、订单数据直接暴露给 AI。

后来 MCP 规范加入了基于 HTTP 的传输方式。最开始是 HTTP+SSE（Server-Sent Events），也就是客户端用 POST 发请求，服务端通过 SSE 单向推送事件；再往后升级成了Streamable HTTP，支持请求-响应和流式返回，还可以复用连接，比 SSE 更灵活。现在你在客户端里填一个https://xxx.com/mcp就能连上，本质上就是因为服务端把 MCP 协议跑在了一个普通的 Web 端点后面。

这背后的意义是深远的。一旦 MCP 端点变成 URL，它就拥有了普通 Web 服务的一切属性：可以部署在云服务器上、可以做负载均衡、可以接网关鉴权、可以被国内外的客户端跨地域访问。也就是说，"网页提供 MCP"并不是什么黑魔法，它就是把原来跑在用户电脑上的 MCP Server 搬到了服务器上，换成 HTTP 协议对外输出而已。理解到这一层，后面所有实操都不难了。

2. 为什么软件厂商愿意把数据开放成 MCP

2.1 Agent 优先的趋势：工具不再只是给人用

我最早看到 Figma、蓝湖做 MCP 的时候，第一反应是：这不等于把自己家的核心数据开放给 AI 去读吗？设计稿、图层结构、标注信息都通过 MCP 暴露出去，难道不怕被爬走？后来想明白了，厂商开放的恰恰是"给别人带来价值同时给自己带来粘性"的能力。

以设计工具为例。设计师的工作流里，最烦的就是"设计稿到代码"这一步。以前要么设计师导出切图，要么前端照着标注一个个量尺寸，效率很低。现在有了 MCP，AI 编程助手可以直接读设计稿的图层树、样式数据、组件属性，然后生成高度还原的页面代码。工具方把 MCP 开放出来，等于降低了自己用户的使用门槛，也把 AI 编程工具变成了自己的"生态合作伙伴"。

这就是所谓的Agent 优先（Agent-First）趋势。过去软件设计的第一用户是人，界面、菜单、快捷键都是给人设计的。现在 AI Agent 成了新的使用方，产品经理开始琢磨"AI 应该怎么用我的产品"。与其让 AI 去截屏猜按钮，不如直接给它一个干净的结构化接口。MCP 就是这个"给 AI 的接口"。

另一个驱动力是数据飞轮。当 AI 通过 MCP 频繁读取某个平台的数据时，这个平台就等于嵌入了用户日常 AI 工作流，用户不会被轻易替换。蓝湖、MasterGo 这些国内设计交付平台积极跟进，本质上是在抢占"AI 时代设计数据入口"的位置。

2.2 网页 MCP 与本地 MCP：不是替代，是分层

有人会问：既然网页 MCP 这么方便，本地 MCP 是不是要淘汰了？我个人的看法是，两者会长期共存，解决的是不同层次的问题。

可以这么理解：本地 MCP 适合"读我自己这台电脑上的东西"，网页 MCP 适合"读整个团队/整个公司共享的东西"。一个典型的混合场景是——你用本地 MCP 让 AI 读项目源码，用网页 MCP 让 AI 读取蓝湖上的最新设计稿，两边同时工作，效果最好。热词里那个 "trae builder with mcp"、"cursor连接蓝湖mcp" 的搜索量能说明问题：开发者已经意识到，打通"设计稿-代码"这条路，本地文件加云设计稿缺一不可。

2.3 网页 MCP 能覆盖哪些离谱场景

从热词里能看出，MCP 生态的覆盖面相当广，而且已经超出了"给前端写代码"的范畴：

• 设计工具：Figma MCP、蓝湖 MCP、MasterGo MCP，AI 直接读取画布和图层。
• 游戏与 3D 引擎：Blender MCP 可以控制建模、调材质；Unity MCP、Cocos Creator MCP 可以操作场景、管理资源。对独立开发者来说，这相当于给 AI 发了一双操控 3D 软件的手。
• 办公与文档：Office Word MCP Server，AI 直接读写 Word 文档。
• 数据与数据库：在 Dify、Cursor 里配置 MySQL 的 MCP，让 AI 直接对线上库做查询分析和慢查询诊断。
• 浏览器自动化：Playwright MCP，AI 控制真实浏览器完成登录、截图、抓取等动作。
• 安全测试与运维：一些安全扫描、日志监控类工具也在尝试通过 MCP 把扫描结果、规则库暴露给 AI，方便做自动化研判。这块我没有深入实操，但方向上确实在往这里走。
• 移动端/桌面端工具：甚至"MT 管理器 MCP"、"剪映 MCP"这类偏个人工具的接入也在被讨论。

你会发现，这些场景有一个共同点：传统上都需要人工一步一步操作，而现在这些操作被封装成了 AI 可调用的工具。网页 MCP 的价值不在于"网页能连 AI"，而在于"任何有 URL 的系统都能成为 AI 工作流的一部分"。

3. 手把手：把一个网页服务变成 MCP Server

3.1 选型：FastMCP 还是官方 SDK？

如果你也想搭一个网页 MCP 服务，第一件事是选型。目前主流有两种：

• Python 生态：推荐fastmcp，封装得非常好，装饰器写工具，一行代码启动 Streamable HTTP 服务，学习成本极低。
• TypeScript/Node 生态：官方@modelcontextprotocol/sdk，适合你已经有一套 Node 服务、想直接集成进路由的场景。

我的建议是：快速验证概念用fastmcp，正式接入已有 Web 项目用官方 SDK 或者你想要的服务端框架自带适配器。JVM 生态的话，spring-ai-alibaba和新版 Spring AI 也内置了 MCP 服务端支持，Java 团队可以直接用它来发布和消费 MCP。

3.2 写一个最简可用的网页 MCP 服务

下面我以一个"在线数据查询服务"为例，演示怎么用fastmcp搭一个网页 MCP。这个服务其实干的事很简单：暴露一个接口，AI 可以通过它查询某份业务数据。

先装依赖：

pip install "fastmcp[server]" httpx

然后写代码：

from fastmcp import FastMCP import httpx mcp = FastMCP("WebDataServer") @mcp.tool() def get_order_status(order_id: str) -> str: """根据订单号查询订单状态，用于客服和售后场景""" # 真实场景里这里可以替换成查数据库、调内部 API return f"订单 {order_id} 当前状态：已发货，预计明天到达" @mcp.tool() def search_products(keyword: str, limit: int = 5) -> str: """按关键词搜索在售商品，返回商品名和价格""" # 这里演示直接返回模拟数据 return "运动鞋 ¥299\n跑步服 ¥159" @mcp.resource("company://profile") def get_company_profile() -> str: """返回公司公开资料""" return "XX 科技有限公司，主营智能硬件设计与销售" if __name__ == "__main__": # 关键：transport 指定为 streamable-http，并监听 0.0.0.0 mcp.run(transport="streamable-http", host="0.0.0.0", port=8000)

这一段代码里，三个地方最容易出问题：

1. 工具描述要认真写。AI 是拿描述来决定"这个工具适不适合当前任务"的，描述写得太笼统，它就可能该调的不调、不该调的乱调。
2. transport参数不要写错。旧版fastmcp用sse，新版默认streamable-http。如果你要把服务暴露到公网，尽量用streamable-http，兼容性更好。
3. 监听地址。本地调试用127.0.0.1，但要部署到服务器或让局域网其他电脑访问，务必监听0.0.0.0。

启动后，你可以在浏览器或 curl 验证一下：

curl -X POST http://127.0.0.1:8000/mcp \ -H "Content-Type: application/json" \ -H "Accept: application/json, text/event-stream" \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

能返回一批工具列表 JSON，说明服务已经起来了。注意很多 MCP 客户端默认探测的是/mcp这个路径，fastmcp默认也挂在这个路径下，所以不需要额外配置。

3.3 用 Cursor / Claude Code 连接远程 MCP

服务起来了，接下来把它接进客户端。

Cursor 的连接方式：

打开 Cursor 设置里的 MCP 选项卡（不同版本入口略有差异，一般在 Settings > MCP），点击Add New MCP Server。在弹窗里选择连接类型为 HTTP，然后在 URL 栏填：

http://127.0.0.1:8000/mcp

Cursor 会自动拉取工具列表，并显示"Connected"。接着你在对话里问一句"帮我查一下订单 123456 的状态"，它就会自动调用get_order_status。

Claude Code 的连接方式：

claude mcp add --transport http my-web-server http://127.0.0.1:8000/mcp

然后重启 Claude Code，用claude mcp list确认连接状态。注意老版本 Claude Code 只支持--transport sse，新版本才支持http（即 streamable-http），如果报错先升级。

这个过程中我踩过的最大一个坑是：远程服务如果在 HTTPS 反向代理后面，MCP 客户端的 HTTP 头会被代理剥掉，导致 SSE/流式响应异常。解决办法是给 Nginx 或 Caddy 配置正确的升级段（Upgrade 相关的 header），把proxy_buffering关掉，否则流式响应会攒到一整块才返回，AI 体验非常奇怪。

3.4 鉴权：从裸奔到 OAuth

本地 MCP 不需要鉴权，但网页 MCP 如果直接暴露公网，相当于把内部工具裸奔在网上，非常危险。我建议按资源风险分级处理：

• 内网部署：如果只在公司内网或本机用，可以先不加鉴权，配合防火墙做限制。
• Header Token：最简单的做法，在 Nginx 层校验一个自定义 Header，比如Authorization: Bearer 你的token。客户端配置里填上对应的 Header 即可。
• OAuth 2.0：MCP 官方规范已经支持 OAuth 2.1 授权流程。适合面向外部用户开放的服务，用户用 GitHub/微信扫码后获得令牌，再把令牌带给 MCP 端点。热词里那个 "mcp oauth认证" 搜得多，大概率就是被这玩意儿卡住了。

我个人强烈建议：只要你的网页 MCP 服务不是跑在localhost，就一定要做鉴权。工具能干什么、数据有多敏感，你永远不知道用户会拿 AI 问出什么来。

4. 实际场景里的接入细节与设计取舍

4.1 设计稿类 MCP：Figma、蓝湖、MasterGo

先说最火的场景——设计稿转代码。

Figma MCP 允许客户端读取一个文件里的画板、Frame、图层树、样式信息，甚至可以直接导出选中元素的 SVG 或 PNG。这意味着前端开发可以让 Cursor/Claude 直接基于 Figma 链接生成还原度很高的页面代码。

国内团队通常用的是蓝湖或 MasterGo。蓝湖 MCP 的价值在于它把设计稿、交互稿和标注信息集中在一起，AI 可以直接拿到每个元素的尺寸、颜色、间距。我实测的流程是：

1. 在客户端里配置蓝湖 MCP 的 URL；
2. 把设计稿链接贴给 AI；
3. 让它先"看"一下整体结构，再针对某个页面输出 React/Vue 代码；
4. AI 会通过 MCP 工具读取设计稿的图层信息，生成代码片段。

这套流程的现实意义是：减少"照图敲样式"这种重复劳动，把注意力留给业务逻辑和交互细节。但也不要神化它，AI 读到的毕竟是标注数据和结构，不是人的视觉理解，遇到那种嵌套很深、组件命名混乱的设计稿，生成的代码照样需要人工整理。我的建议是：给 AI 一个清晰的指令模板（MCP 里的 Prompts 就干这个），把命名规范、组件库偏好提前塞进去，效果会好很多。

4.2 引擎类 MCP：Blender、Unity、Cocos Creator

这类 MCP 和网页服务的关联有点特殊。像 Blender MCP 通常还是本地进程，因为它要操纵本机的 Blender 实例；但 Unity MCP、Cocos Creator MCP 已经开始出现"云端编辑器场景 + 网页 MCP"的形态，也就是你在浏览器里操作场景，AI 通过 MCP 直接改参数。

对独立游戏开发者来说，最有价值的用法是：让 AI 读项目场景结构、批量修改资源属性。我以前调 Unity 里一堆 Prefab 的材质参数，需要写编辑器脚本，现在如果接入了场景 MCP，直接对 AI 说"把所有角色的血量上限上调 20%"就够了。它会在 MCP 工具的支持下遍历场景对象并修改。

不过这类 MCP 的成熟度参差不齐，很多还处于"实验性"阶段。我的经验是：接之前先确认它支持哪些具体工具，不要只看 README 画的饼。你连上去之后第一时间列出工具列表（tools/list），看看有没有你真正需要的操作。

4.3 数据类和浏览器类：数据库 MCP、Playwright MCP

网页 MCP 在数据场景的表现其实最"实在"。比如 Cursor 里配置 MySQL 的 MCP 之后，你可以在对话里直接问"订单表里近 7 天退货率最高的商品是哪些"，AI 会生成 SQL、执行查询、返回分析结果。这么做最大的风险是 AI 把高危语句执行到生产库，所以务必用只读账号，并且把INSERT、UPDATE、DELETE权限全部禁止。

Playwright MCP 我最近用得也比较多。它本质上是把浏览器自动化能力封装成 MCP 工具，AI 可以控制一个真实浏览器去执行点击、填表、截图、抓取数据。和公司内部网页系统对接时，它可以帮你自动完成登录、导出报表这种固定动作。但注意，这类工具在和 OAuth 登录页面混在一起时很容易把人搞晕，因为 AI 经常无法处理图形验证码和短信验证码。我的做法是：提前在测试环境把登录态处理好，让 AI 从登录后的页面开始干活。

至于热词里提到的安全工具类 MCP（扫描器、WAF 日志、监控系统），我目前更多是观望状态。技术方向值得期待，但要在生产环境落地，还得看厂商对数据脱敏和权限模型做得够不够细。

5. 这波热词背后的实操问题：排查与避坑

5.1 URL 填了但连不上，先查这三个地方

用网页 MCP 最挫败的时刻，就是你明明填对了 URL，客户端却一直转圈。我遇到的连接问题，90% 出在三个地方：

• 路径不对。客户端默认访问/mcp，你自己部署的服务可能挂在业务路径下，比如/api/v1/mcp，填的时候要带全。
• 代理把流式传输弄坏了。这个前面提过，Nginx 没关proxy_buffering，SSE/流式响应会一直不返回。
• 防火墙和端口。服务器的 8000 端口未必对外开放，云服务商的安全组、操作系统防火墙都要检查。很多人本地好好的，一部署到服务器就废了，基本都是这个原因。

我的建议是：先不用客户端，直接拿 curl 测tools/list，测通了再连客户端。这样能把问题明确到"服务端"还是"客户端"。

5.2 CORS、鉴权、超时，一个比一个坑

网页 MCP 暴露到公网后，客户端浏览器环境会遇到 CORS 跨域问题。MCP 规范里对 CORS 有推荐配置，但fastmcp默认不一定开完全。如果你是用自定义 Node 服务实现的，记得在响应头里加：

Access-Control-Allow-Origin: * Access-Control-Allow-Headers: authorization, content-type, mcp-protocol-version Access-Control-Allow-Methods: GET, POST, OPTIONS

鉴权失败的表现也很有迷惑性——有时不是提示 401，而是客户端默默显示"未连接工具"。排查时先看一眼 MCP 日志（很多客户端可以在设置里打开调试日志），如果看到no auth credentials之类的字样，就是鉴权 Headers 没配上。

超时问题主要是两类：一是 AI 调用某个工具时服务端处理时间太长，导致客户端主动掐断连接；二是返回的数据量太大，超过了模型的上下文窗口。我的经验是：在工具代码里做好分页和截断，宁可分多次查，也不要一次性返回十万行 JSON，否则 AI 的上下文窗口直接被塞爆，后面的对话就全乱了。

5.3 工具描述不清晰，AI 就会乱来

这是最隐蔽、最容易忽略的一个坑。MCP Server 接上了，工具也列出来了，但 AI 就是不会用，或者用错。问题几乎都出在工具描述上。

我看到过太多这样写的工具描述：

查询订单

这信息量约等于没有。AI 根本不知道这个工具需要什么参数、返回什么格式、适合什么场景。正确写法是：

查询订单状态，输入订单号，返回订单当前物流状态和预计送达时间，适合客服处理售前售后问题时调用。

我实测过，描述写详细之后，AI 调用工具的准确率能提升一大截。别把这当成小事，MCP 的 Tools 本质上就是让你给模型写"API 使用说明书"，说明书写得好不好，直接决定 Agent 干活靠谱不靠谱。

另外，客户端这边也有细节：很多客户端可以配置工具是否自动批准执行。对于高风险工具（比如写数据库、删文件），建议手动批准；对于只读查询类工具，才开自动批准。这个习惯能帮你避免很多"AI 自作主张"的灾难。

一点实际体会

做到最后，我发现"网页提供 MCP"真正的门槛从来不是技术，而是思路转换。MCP Server 从本地进程搬到 URL 之后，很多人潜意识里还在拿它当"本地插件"用，只给自己本机配；但它的潜力恰恰在于"大家共用一套工具"——团队的 AI 助手、每个人的编程客户端、甚至其他 Agent 服务，都可以接同一个端点。我这几周把公司的几个查询类接口陆续封装成网页 MCP 之后，最明显的变化是：团队里不同人用不同 AI 工具，问的都是同一套内部数据，但谁都不用再单独写接入脚本了。

当然，安全边界一定要划清楚。网页 MCP 的权限控制、审计日志、敏感数据脱敏，这些事在没有成熟工具之前，只能靠我们自己谨慎处理。把 MCP 端点做成一个标准 Web 服务来对待，该鉴权鉴权、该限流限流，别因为它带着"AI"的光环就放松警惕。总的来说，现在是试用和积累经验的最好窗口期，等这波生态再成熟一点，网页 MCP 可能就会像现在的 REST API 一样，成为每家公司对外开放能力的基本形态了。