手机直连本地大模型：PWA 远程渲染架构实测与避坑

凌晨两点半，我在自己的桌面工作站上跑通了某本地大模型编排框架的移动伴侣端全链路：终端里服务端口亮起、手机扫码进入界面、第一轮对话开始流式返回的那一刻，确实会让人产生“把本地算力揣进口袋”的错觉。但把整条链路拆开，再叠加一轮高强度任务实测之后，我的结论是：这类方案的工程本质，与社区传言中“手机上跑大模型”的想象相去甚远。这篇文章把架构边界、典型故障和对应对策一次性讲清楚。

一、先给结论：手机上跑的不是模型，是“遥控器”

先纠正最常见的误解。这类“手机伴侣端”既不是独立移动应用，也不包含任何推理能力。它的技术本质可以拆成三层：

1. 展示层：一个 PWA（渐进式 Web 应用）。由现代前端构建工具打包的网页应用，借助浏览器标准的 Service Worker 能力在本地缓存静态资源，再通过“添加到主屏幕”伪装成常驻桌面的图标。看起来像 App，运行时是网页。
2. 通信层：一条局域网内的 WebSocket 长连接（形如 ws://192.168.x.x:8030）。用户输入、模型流式输出、任务状态回传，全部走这条链路。
3. 算力层：全部留在宿主机。模型推理、本地接口响应、Agent 的工具调用编排，由宿主机上的插件化内核驱动。手机端不加载任何模型参数，也不执行任何计算，它只是一个远程 UI 渲染器。

这个分层意味着一条硬边界：脱离宿主机所在的本地环境，整套架构无法独立运行。宿主机关机或手机离开局域网，伴侣端就只是一个打不开的空壳。

二、为什么是 PWA + WebSocket：合理性与其代价

这套选型并非偷懒，而是有明确的工程动机：

• 分发成本：无需上架应用商店、无需审核、一次构建多端可访问，迭代速度快，特别适合开源社区项目的传播路径。
• 通信选型：大模型流式输出天然需要全双工、低延迟通道，WebSocket 是浏览器环境下的标准答案。

数据流向可以概括为：

手机（渲染 / 输入）
   ⇅  WebSocket（ws://内网IP:端口）
宿主机插件内核（推理 / 调度 / 工具执行）

但代价同样清晰：PWA 完全受制于浏览器运行时约束，尤其是移动端浏览器严格的后台生命周期管理——这一点会成为后文最深的坑。而 WebSocket 的“长连接”属性，在移动操作系统面前恰恰是最脆弱的资产。

三、实测三大坑：根因与对策

坑一：扫码配对卡死在首屏——AP 隔离屏蔽了点对点通信

现象：首轮扫码，移动端持续卡在 Loading。宿主机服务日志里，连一次 TCP 握手记录都没有。

根因：家用路由器普遍默认或可选开启“AP 隔离”（Access Point Isolation，部分固件叫“客户端隔离/隐私隔离”）。该策略会阻断同一无线网络内不同客户端之间的广播与点对点报文，浏览器发出的握手包被直接丢弃。握手都完不成，WebSocket 无从建立。

自检三步：

1. 手机与宿主机分别查看内网地址，确认是否处于同一网段——注意双频路由常把 2.4G 与 5G 划为不同网段，访客网络默认开启隔离；
2. 在手机侧对宿主机内网地址做连通性探测（ICMP ping、端口探测），确认链路通断；
3. 登录路由器管理后台，检索“AP 隔离/客户端隔离”开关并关闭。

延伸提醒：在企业办公网或公共 Wi-Fi 下，你几乎必然撞上同网段隔离，这是网络管理员的刻意安全策略，不能指望自己关掉，只能申请放行，或临时用移动热点自组网络绕开。

坑二：切后台数秒断连——移动端生命周期是长连接的天敌

现象：触发一个复杂自动化任务（例如让 Agent 编写并运行数据抓取脚本，中途需要调用浏览器自动化组件安装驱动），在终端显示第 2 轮工具调用正在执行 shell 指令的间隙，我把手机浏览器切到后台处理其他事务。切回页面时，渲染进程直接抛出 Connection Closed 异常，任务上下文全部丢失，没有任何断点续传。

根因分两层：

• 系统层：主流移动操作系统对后台网页进程执行强休眠策略。页面一旦失焦，渲染进程被挂起，持有的 WebSocket 长连接在数秒内被系统冻结、切断。这是平台级行为，网页脚本层面不存在可靠的“后台保活”手段。
• 应用层（真正的设计缺陷）：会话状态只存在于页面内存与服务进程内存中，没有服务端持久化，也没有消息序号与回放机制。连接一断，上下文即焚毁。

对策按“治标—治本”排序：

治标是心跳与重连：前端维持十几秒级心跳，断开后按指数退避自动重连（上限 30 秒左右），至少保证“回到前台即恢复连接”。

治本是状态外置与会话恢复协议：把会话与任务状态持久化到服务端，为每条下发消息打上递增序号；重连后客户端携带会话 ID 与最后确认序号，服务端回放未确认区间：

// 伪代码：指数退避重连 + 会话恢复
function connect(session) {
  const ws = new WebSocket(serverUrl);
  ws.onopen = () => {
    heartbeat(ws, 15000);
    ws.send({ type: "resume", sessionId: session.id, lastSeq: session.lastSeq });
  };
  ws.onclose = () =>
    setTimeout(() => connect(session),
               Math.min(1000 * 2 ** retries++, 30000));
}

服务端需配合：任务以队列推进、工具调用设计为幂等，回放期间允许客户端补拉任务快照。做到这一步，“切后台再回来”才不再是灾难事件，而是可恢复的普通网络抖动。

坑三：公网穿透等于裸奔——无鉴权的本地算力接口是高危资产

动机与现象：想走出家门使用，就必须借助内网穿透/隧道类工具，把宿主机服务端口暴露到公网。但实测链路上没有任何鉴权防护层。

风险量级：无鉴权端口暴露公网后，常规端口扫描器在数秒内即可完成定位。而这类伴侣端背后的接口能力是——驱动宿主机执行任意 Agent 工具调用。一旦被恶意注入高危指令（最坏情况：远程执行系统级删除操作），损失的不是一张网页，而是整台主机。

对策按优先级：

1. 鉴权前置：在服务前加一层反向代理，统一完成 TLS 终止与令牌校验，所有请求必须携带访问令牌，未授权一律拒绝；
2. 最小权限：Agent 可调用的工具做白名单，高危 shell 类指令默认禁用，或强制沙箱执行加二次确认；
3. 观测与限流：开启访问审计日志与异常来源限流，一旦泄漏可快速止损与溯源。

# 伪配置：代理层完成 TLS 与令牌校验后，再转发到本机服务
route /ws:
    require_tls(on)
    require_header("Authorization", "Bearer <token>") else 401
    forward_to("ws://127.0.0.1:8030", upgrade=websocket)

另一条思路：若公网可用是刚需，与其自建穿透，不如评估公有云上的通用托管能力——例如百度智能云等厂商提供的容器托管、模型推理服务、API 网关与日志监控类通用产品，把鉴权、审计与算力调度整体放到托管层完成，安全边界由平台兜底，通常比手工穿透更稳妥。

四、部署同类方案前的检查清单

网络层

• 手机与宿主机同网段，AP 隔离已关闭；
• 宿主机防火墙放行服务端口，且仅对内网网段开放；
• 为宿主机做静态内网地址分配，避免每次配对地址漂移。

会话层

• WebSocket 心跳 + 指数退避重连；
• 会话状态服务端持久化，消息带序号，支持重连回放；
• 工具调用幂等设计，任务支持断点续传。

安全层

• 公网暴露必须经过鉴权代理层与 TLS，禁止端口直连裸奔；
• 工具调用白名单 + 沙箱，高危指令二次确认；
• 审计日志、限流，必要时叠加来源 IP 白名单。

五、写在最后：给这类方案一个正确预期

“手机直连本地大模型”的真实图景是：手机是一块随身屏幕，算力与数据主权留在你的宿主机里。在家庭与办公局域网内，它是低成本的“人机协同遥控器”，体验上限取决于网络与会话工程做得是否扎实；一旦要走出局域网，安全边界就必须亲手补齐，否则它就是一台对全网敞开的主机。

技术选型没有银弹，但有边界。评估或自建同类方案时，先回答三个问题：哪些能力在手机上？哪些能力在宿主机上？链路断掉时会发生什么？想清楚这三点，你就不会被社区热度与宣传语带偏了。