企业官网建设流程全解析

最近后台不少人在问mobile-mcp这个词，有的把它当成某个开源项目，有的在问“手机怎么获取 MCP 服务”，还有人拿着某 MCP 网关的提示截图来问我：“这个提示说只支持移动设备访问，是怎么回事？”我把这段时间在移动端折腾 MCP 的经验整理成一篇东西：mobile-mcp 到底指什么、移动端跑 MCP 有哪几条路线、怎么从零把一个 MCP 服务接到手机里，以及最容易卡住人的几个坑。内容尽量照顾到完全没接触过 MCP 协议的新手，也会给出一些可以直接抄作业的配置和代码。

1. mobile-mcp 到底是什么：先分清移动端的两种玩法

1.1 MCP 协议是干嘛的，为什么和手机有关系

MCP 全称 Model Context Protocol，中文一般叫模型上下文协议。它解决的是一件很朴素的事：让 AI 应用能安全地调用外部工具和数据源。你可以把 MCP 理解为 AI 世界的 USB-C 接口——以前每个 AI 应用接外部工具都要写一套私有集成，有了这个协议，模型、客户端、工具服务端就能按统一的方式对话。

协议本身基于 JSON-RPC 2.0，消息通常是initialize、tools/list、tools/call这一类。工具服务端把能力暴露出来，AI 客户端发现这些工具后，在需要的时候调用。这个过程很像我们去店里点菜：菜单是工具清单，下单是调用工具，上菜是返回结果。

为什么 mobile-mcp 会被单独拿出来说？因为手机是我们最高频的终端，但绝大多数 MCP 示例都是跑在电脑上的。电脑上可以轻松跑 Python 服务、开浏览器调试工具、连本地数据库，手机就没那么方便。于是就有了两类典型需求：一类是把手机上的能力（传感器、文件、短信、剪贴板）暴露给电脑上的 AI 用；另一类是让手机上的 AI 助手去调用远程的 MCP 服务。

1.2 手机当客户端，还是当服务端？

我把移动端 MCP 的玩法拆成两条路线，这样后面遇到具体场景时不容易绕晕。

第一条路线是手机作为 MCP 客户端。手机上装一个支持 MCP 的 App，或者自己写一个最小客户端，然后让它去连接远程的 MCP Server。典型场景是：手机上的 AI 助手连接企业内部的 MCP 网关，查订单、查库存、发消息。这时候手机只是个“遥控器”，真正的计算和工具执行都发生在服务端。

第二条路线是手机作为 MCP 服务端。手机通过 HTTP/WebSocket 把自身能力暴露出来，电脑上的 AI 客户端（比如 Claude Desktop、Cursor）通过局域网或公网访问。常见做法是手机监听一个本地端口，电脑用adb forward或局域网 IP 连接。这种模式适合做自动化测试、传感器采集，或者把手机当成一个独立的“工具节点”。

现在很多项目里说的mobile-mcp，其实是指第二种——让手机变成一个可以随时被 AI 调用的移动工具集。但我在实际接触中，发现大部分提问者需要的是第一种：他们手里已经有一个 MCP 服务地址（比如wss://api.xiaozhi.me/mcp/?token=...），只是想搞清楚手机怎么连上去。所以我在下文会两条路线都覆盖，但会以“手机连远程 MCP 服务”为主线。

2. 手机怎么获取 MCP 服务：从协议到端口的完整链路

2.1 获取 MCP 服务端的三种渠道

先解决源头问题：MCP 服务从哪来？

第一种是用现成的公共服务平台。现在有不少团队把自己平台的 API 封装成 MCP 端点，用户申请 token 后直接在客户端里填地址就能用。比如小智 MCP 平台提供的api.xiaozhi.me/mcp端点，就属于这一类。这类服务最大的好处是省事，不用自己搭建，坏处是权限和数据都攥在别人手里，适合尝鲜和轻量使用。

第二种是自建 MCP Server。用 Python 或 Node 写一个服务，把自己常用的 API、脚本、数据库查包装成 MCP 工具。这种方式适合有定制需求的场景，比如把内部运维脚本暴露给 AI。热词里提到的swagger 转 mcp也是这个思路——把已有的 HTTP API 描述文件转换成 MCP Server，快速让 AI 能调用现有的后端接口。

第三种是改造桌面软件自带的 MCP 能力。现在很多专业工具已经内置了 MCP Server，比如 Chrome DevTools MCP、Playwright MCP、Figma MCP、蓝湖 MCP、甚至 Unity MCP、Blender MCP。它们本来跑在电脑上，但只要你把服务绑定到局域网或公网地址，手机端同样能连。

2.2 移动端连接 MCP 的网络链路选择

拿到服务端之后，手机要连上去，有三条常见链路：

• 同一局域网直连：手机和 MCP Server 连同一个 WiFi，手机直接访问ws://192.168.x.x:端口。优点是延迟低，缺点是不能出门。
• 通过公网服务器中转：把 MCP Server 部署在云服务器上，手机随时随地通过公网访问。这是最实用的方式。
• 通过网关/WSS 接入：服务端使用wss://协议，配合 token 鉴权。手机端只需要支持 WebSocket 客户端即可。

从实际体验看，MCP 走 WebSocket 比走普通 HTTP 更适合移动端，原因有两个：一是 WebSocket 是长连接，AI 对话过程中会多次调用工具，长连接能省去反复握手的时间；二是wss://走 TLS 加密，token 不容易在传输中被截获。很多公共服务平台选择wss://api.xxx.com/mcp/?token=xxx这种格式，就是这个道理。

这里要特别提醒一句：token 就是钥匙。我看到网上有人分享截图时没有打码，直接把?.token=.....整串丢出来。如果你手里的 token 是生产环境的，泄露后等于把服务控制权交出去了。轻则被别人刷爆额度，重则你的数据被拉走。截图时一定要把 token 中间段打码。

2.3 手机端“获取 MCP 服务”的通用四步

以“让手机连接一个远程 MCP 服务”为例，完整的流程可以浓缩成四步：

1. 申请/配置 token，确认服务端的地址（形如wss://api.example.com/mcp/?token=你的token）。
2. 确认传输协议。大多数公共服务用 WebSocket，少数用 SSE 或 Streamable HTTP。
3. 在手机客户端里填入地址。如果客户端不支持 MCP 协议，则需要写一个最小 WebSocket 客户端来做 JSON-RPC 消息转发。
4. 发起initialize握手，再拉tools/list工具列表，然后试调一个工具验证连通性。

这一步看起来简单，但第 3 步往往是坑最多的地方。很多手机 App 虽然打着“AI 助手”的旗号，却没有暴露自定义 MCP 地址的入口。遇到这种情况，我建议先用电脑端验证服务可用，再用支持 MCP 的手机客户端，最后才考虑自己写转发层。

3. 一次真实的 mobile-mcp 接入实战：手机连接 wss MCP 服务

3.1 准备工作：先在电脑上验证服务可用

我不建议一上来就在手机上折腾，因为手机端的问题和协议问题会混在一起，很难排查。正确顺序是：先在电脑上把服务调通，再去解决手机适配。

假设你要连的是wss://api.xiaozhi.me/mcp/?token=xxxx，第一步是在支持 MCP 的客户端里配置。如果你用 Chrome DevTools 的 MCP 扩展，可以在浏览器扩展设置中直接启用“MCP 连接”并填入地址。如果你用 Claude Desktop 或 Cursor，也可以在配置文件的mcpServers里加上：

{ "mcpServers": { "xiaozhi-mobile": { "url": "wss://api.xiaozhi.me/mcp/?token=你的token" } } }

注意，不同客户端的配置字段略有差异，有的用url，有的用command+args来启动本地 MCP Server。连 WebSocket 远程服务时，关键就是url字段不要写错，包括wss://前缀和 token 参数。

验证成功的标志是什么？打开客户端里的 MCP 工具列表，能看到服务端暴露出来的工具；调用一个无副作用的工具，能正常返回结果。到这一步，说明服务端是好的，token 是好的，协议交互是通的。

3.2 用 Python 快速写一个手机能连的 MCP Server

如果你的需求是“手机当服务端”，或者你想自己起一个 MCP 服务给手机用，我推荐用 FastMCP 这个库。它封装了协议细节，你可以把精力放在写工具函数上。

先安装依赖：

pip install fastmcp uvicorn

然后写一个最小服务，暴露一个返回手机信息的模拟接口：

from fastmcp import FastMCP mcp = FastMCP("mobile-demo-server") @mcp.tool() def get_device_info() -> dict: """返回一个模拟的设备信息示例，实际项目中可以在这里读取手机传感器或状态""" return { "device": "android-emulator", "battery": 85, "network": "wifi", } if __name__ == "__main__": mcp.run(transport="streamable-http", host="0.0.0.0", port=8000)

host="0.0.0.0"很关键，它表示监听所有网卡，这样手机才能通过电脑的局域网 IP 访问。跑起来后，手机在同一个 WiFi 下就能通过http://电脑IP:8000/mcp访问服务。

如果你想用 WebSocket 协议，需要换一种启动方式。FastMCP 底层支持不同的 transport，但目前最常见的远程部署组合是streamable-http+uvicorn。如果你对接的平台只认wss://，通常是在前面加一层 HTTPS/WSS 网关或者直接用支持 WebSocket 的 MCP Server 框架。

3.3 在手机上写一个最小 MCP 客户端

手机上没有现成客户端时，可以用 Flutter、React Native 或原生 WebSocket 写一个简单的测试程序。核心逻辑很简单，就是发 JSON-RPC 消息。我用 Dart 语言举例：

import 'dart:convert'; import 'dart:io'; Future<void> main() async { final ws = await WebSocket.connect('wss://api.example.com/mcp/?token=你的token'); // 1. 发送 initialize 请求 ws.add(jsonEncode({ 'jsonrpc': '2.0', 'id': 1, 'method': 'initialize', 'params': { 'protocolVersion': '2025-06-18', 'capabilities': {}, 'clientInfo': {'name': 'mobile-client', 'version': '1.0.0'} } })); ws.listen((data) { final msg = jsonDecode(data); if (msg['id'] == 1) { // 2. 初始化完成后，请求工具列表 ws.add(jsonEncode({ 'jsonrpc': '2.0', 'id': 2, 'method': 'tools/list', 'params': {} })); } if (msg['id'] == 2) { // 3. 打印工具列表 print(jsonEncode(msg)); } }); }

这段代码没有处理生命周期管理，但足够验证“手机能否连上服务”。在实际项目中，你还需要处理以下内容：notifications/initialized通知、心跳保活、断线重连、tool 调用结果的解析。

调试的时候，打开服务端日志看握手记录是最直接的。下面专门聊日志。

3.4 MCP Server 端日志的自定义管理

热词里有一条问“MCP server 端的日志如何使用自定义日志管理”，这确实是远程部署时容易忽略的点。默认情况下，很多 MCP 框架会把日志打到标准输出，但服务以 systemd 或容器方式运行时，标准输出会被吞掉，出了问题时什么都看不到。

我给自己的 MCP Server 配日志时，一般按下面这套来：

import logging from logging.handlers import TimedRotatingFileHandler logger = logging.getLogger("mcp-server") logger.setLevel(logging.DEBUG) handler = TimedRotatingFileHandler( "logs/mcp-server.log", when="midnight", backupCount=7, encoding="utf-8" ) formatter = logging.Formatter("%(asctime)s - %(levelname)s - %(name)s - %(message)s") handler.setFormatter(formatter) logger.addHandler(handler)

关键点有三个：一是按天轮转，防止日志文件无限膨胀；二是固定编码为 UTF-8，因为工具返回的文本经常带中文；三是把DEBUG级别打开，MCP 的 JSON-RPC 消息很长，只有 DEBUG 级别才能看到完整报文。等排查完再调回 INFO，避免日志刷得太猛。

如果你的服务部署在容器里，我建议把日志输出到 stdout/stderr，由容器的日志驱动统一收集，而不是直接写到容器内文件。原因很简单：容器重启后文件就没了，统一收集才能集中检索。

4. 把 PC 上的 MCP 能力“搬”到手机：常见场景拆解

4.1 浏览器调试：Chrome DevTools MCP 和 Playwright MCP

移动端页面调试一直是痛点，而 Chrome DevTools MCP 的出现让 AI 可以直接操作浏览器。这个场景和手机的关系是：你可以让 AI 通过 Chrome DevTools MCP 打开手机模拟器尺寸的视口，操作页面、抓取接口、检查控制台报错。

很多人在网上问“Browser Use MCP 跟 Playwright MCP 有什么区别”，我简单说下。Browser Use MCP 偏“让 AI 替你完成网页操作”，它封装的是整个浏览器自动化流程；Playwright MCP 偏“把浏览器当工具暴露给 MCP 调用”，更底层，适合做精准控制。如果你只是想快速让 AI 帮你测一个移动端页面，用 Playwright MCP 配合设备模拟器就够了。

实际操作中，我会在电脑上起一个 Playwright MCP Server，绑定到局域网地址，然后在手机端用一个支持 MCP 的客户端去触发浏览器操作。效果就像手机遥控电脑上的浏览器一样，适合演示和远程协助。

4.2 安全测试工具链：BurpSuite MCP、Yakit MCP 与 CTF

安全工具接入 MCP 也是今年的热门方向。比如 BurpSuite MCP 和 Yakit MCP 可以把抓包工具的能力暴露给 AI，AI 能直接读取 HTTP 请求、修改重放、分析接口逻辑。在授权测试和 CTF 比赛中，这种能力能省不少事。

这些工具默认跑在电脑上，手机要连，同样走远程 MCP 网关。要注意的是安全测试工具链的信息非常敏感，暴露到公网之前必须做鉴权和访问控制。我见过有人把 BurpSuite MCP 直接绑到公网端口上，没有任何 token，这是一个非常危险的操作——别人拿到了你的 MCP 工具列表，等于拿到了你的抓包工具手柄。这种服务至少要做到：token 鉴权、IP 白名单、TLS 加密、审计日志。

热词里提到的“Trae IDE 搭载 Burp Suite MCP Server 完整指南”也是同一个思路，只是把客户端换成了 Trae IDE。这类方案适合有授权的渗透测试人员在隔离环境里使用，不建议在公网环境长期开放。

4.3 设计协作与软件自动化：Figma MCP、蓝湖 MCP

设计协作场景同样有 MCP 需求。Figma MCP 可以把设计稿的图层、样式、标注暴露给 AI，蓝湖也提供了 MCP 服务。有人问“蓝湖 MCP 服务怎么部署”，这类商业服务通常不需要你自己部署，而是由平台方提供一个 MCP 端点，你在客户端里配置账号和项目 ID 就行。

这类 MCP 服务的优势是：AI 可以直接读取设计稿尺寸，生成代码时能对应到真实的样式 token。我在 VSCode 里配合 Figma MCP 试过几次，效果比截图给 AI 描述要准确得多，尤其间距和颜色这种细节，AI 不会猜错。

手机在这个场景里起什么作用？主要是“随时看”。设计师在手机上看效果图，发现细节不匹配时，可以直接把问题和 MCP 工具反馈给电脑上的 AI，不用再手动截图、圈红、写文字说明。工具链打通之后，反馈链路短很多。

4.4 专业软件里的 MCP：Unity、Blender、QGIS 等

热词里还有 Unity MCP、Blender MCP、Vivado 的 MCP、NXOpen MCP 之类的关键词。这说明 MCP 已经不局限于 AI 聊天工具接 API，而是逐渐进入专业软件控制领域。

比如 Unity MCP 可以让 AI 读场景结构、修改 GameObject、执行 Editor 脚本；Blender MCP 可以让 AI 操作三维模型、改材质、跑渲染。这对移动端的意义在于：你可以带着手机远程连接一台高性能工作站的 MCP 服务，让 AI 在后台执行重活，手机只用来下发指令和查看结果。

我在实际使用中发现一个规律：凡是有 Python 脚本接口或命令行接口的软件，包成 MCP 都不难。难点往往在鉴权和权限控制。因为 MCP 工具的能力等同于执行代码，一旦暴露到公网，风险比 API 泄露大得多。专业软件授权一般也有限制，开放远程 MCP 前务必先确认授权条款是否允许。

5. 常见问题与排查技巧实录

5.1 手机连不上 MCP 服务，先从这五步查

我把平时帮人排查的顺序整理成一个表，你可以照着做。

最后一行要说明一下：我之前也看到过某个 MCP 网关提示“此网站只支持移动设备访问，请使用你的手机上的 MCP 客户端”。这种提示一般出现在网页助手或移动端专属服务上，意图很明确——该服务就是给手机用户用的。最省事的做法就是直接拿手机访问，别在电脑上费劲。

5.2 调用工具返回“超时”或“连接被断开”

MCP 调用一个耗时的工具时，客户端很容易因为等待时间太长而主动断开。比如 AI 要调用一个批量处理图片的工具，执行时间超过 30 秒，WebSocket 连接可能就被中间层断开了。

处理办法有两个方向。一是把耗时操作改成异步任务模式：工具只负责提交任务并返回 task_id，AI 另查一个工具去轮询任务状态。二是调大客户端和服务端的读写超时参数。FastMCP 里可以通过mcp.run(transport="streamable-http", timeout_keep_alive=...)这类参数调整，具体名称取决于框架版本。

我强烈建议优先用异步任务模式，而不是单纯调大超时。因为移动端网络本身就不稳定，长连接超过 60 秒几乎必断，靠超时参数解决不了本质问题。

5.3 在手机上自建 MCP Server 的“省电”与“保活”

在手机上跑服务端的读者，一定会遇到两个现实问题：耗电和进程被杀。

耗电主要来自 WebSocket 长连接。如果你的手机服务端只是给电脑提供工具调用，可以考虑在无请求时进入休眠，由客户端侧自动重连，而不是一直保持活跃。我之前在一个 Android 项目里就是让服务监听 TCP 连接，15 秒没有消息就断开，客户端侧写好自动重连逻辑，功耗能降一半以上。

进程被杀则几乎无解。国产手机厂商的后台管理策略非常激进，一个前台 App 的 Service 都可能在锁屏后被回收。我的经验是：开发调试阶段用电脑模拟器替代真机；生产阶段把真正需要常驻的逻辑放到云端服务器，手机端只做轻量的采集和转发，这样既稳定又省电。

5.4 日志排查看不到有效信息怎么办

很多人问为什么日志里全是INFO和WARNING，看不到 JSON-RPC 报文。因为大多数框架默认日志级别就是 INFO，不会把请求内容打出来。你需要显式开启调试级别，或者自己加一个中间件来打印收发的消息。

如果你用的是 FastMCP，可以通过配置logging级别来开启：

export MCP_LOG_LEVEL=DEBUG python server.py

如果是自建服务，直接在自己封装的 WebSocket 处理函数里print出收到的原始帧。虽然不优雅，但排障时最管用。等你确认问题出在哪个环节，再把这些打印删掉也不迟。

6. 一些实操之后才明白的事

mobile-mcp 这个概念，说到底并没有多么高深，它只是把 MCP 协议的适用范围从桌面端扩展到了移动端。但真正做下来，我发现大家踩的坑都和“移动”两个字有关：网络不稳定、后台被杀、token 管理不便、日志难以查看。大原则一句话：手机适合做轻量客户端和临时服务端，不适合做长周期的高强度计算节点。

我在实际项目中最后采取的结构，一般是云端起一个 MCP Server，手机上跑一个轻量客户端，两者之间走wss://长连接，token 定期轮换，服务端日志统一收集到日志平台。这样一来，无论是电脑还是手机，都能以相同的接口访问工具链，不用为每个终端单独适配。

最后再分享一个小技巧：测试 MCP 服务时，不要一上来就用真实 token 去连生产环境。先在本地起一个最简单的 FastMCP 服务，然后用电脑、手机轮流通一遍，把协议和网络链路都摸清，再切换到正式服务。这个习惯能帮你避开大量“客户端配置错误”和“网络不通”的低级问题。我自己就是因为跳过这一步，浪费过整整一个下午。