上周有个做移动端开发的朋友问我有没有那种能在手机上跑的AI助手不依赖云端数据全放本地我当时能想到的方案不多——要么是Ollama之类的本地模型方案要么就是各种套壳App。后来他在群里丢了一个叫OpenClaw的项目圈内人称小龙虾说这玩意儿支持手机端部署。我这人吧看到新鲜东西就想拆开看看于是花了几天时间从客户端安装到服务端搭建跑了一遍这篇算是我的实测笔记。OpenClaw最新版本一键部署包下载地址https://top.wokk.cn/先交代一下我的测试环境免得有人说我在云里雾里服务端: OS: Windows Server 2019 Node.js: v22.21.1 内存: 16GB 客户端安卓测试: 设备: Pixel 6 (Android 14) 网络: 局域网WiFi 客户端iOS测试: 设备: iPhone 13 (iOS 17.5) 网络: 局域网WiFi另外再提一句如果你只是想在电脑上快速跑起来不想碰命令行的话官方那边有打包好的安装程序下载下来双击就行。下面主要聊我在搭建服务端和移动端对接过程中踩过的坑。先说结论能跑但不适合所有人在动手之前先搞清楚一件事——OpenClaw本身不是一个手机App。准确地说它是一个跑在服务器或你自己的电脑上的Agent框架然后通过Web界面或者API跟手机端交互。手机上不需要安装什么本地大模型所有的推理计算都在服务端完成手机只负责收发消息。这个架构选择其实挺合理的。你想啊手机那点算力和内存跑7B模型都费劲更别说70B了。把重活丢给服务端手机端保持轻量这是目前AI移动方案的主流思路。跟ChatGPT App的逻辑是一样的只不过OpenClaw把服务端交给你自己管。所以前提条件是你得有一台常开的服务器或者PC。家里有NAS的玩家正好。服务端搭建对比三种方案的实际体验我把目前能找到的部署方式都试了一遍整理了一下各自的优劣势。方案A源码部署npm install这是最灵活但也是最折腾的方式。适合想自定义功能的开发者。# 克隆并安装 git clone https://github.com/nicepkg/openclaw.git cd openclaw npm install # 配置环境变量 cp .env.example .env # 编辑 .env 填入你的API Key # 启动 npm run gateway我实测在国内网络环境下npm install这一步如果不配镜像源的话大概要跑15-20分钟。配了npmmirror之后快了很多npm config set registry https://registry.npmmirror.com npm install # 大概2-3分钟优点可以随时改源码、加自定义Skill、调试方便。 缺点Node.js版本管理是个坑升级和回退需要用nvm新手容易搞乱。方案BDocker部署如果你服务器上已经有Docker环境这是最省心的方式。# 拉取镜像 docker pull nicepkg/openclaw:latest # 运行容器 docker run -d \ --name openclaw \ -p 3456:3456 \ -v ~/.qclaw:/root/.qclaw \ -e ZHIPU_API_KEYyour_key_here \ nicepkg/openclaw:latest这里有个细节要注意-v ~/.qclaw:/root/.qclaw这个卷映射很关键。如果不做映射容器重启之后你所有的Agent配置、记忆文件都会丢失。我第一次就没加这个参数结果重启容器之后发现所有对话历史都没了郁闷了好一会儿。方案C官方安装包Windows/macOS这个没什么好说的下载、安装、启动三步搞定。适合纯小白。但灵活性最低出了问题排查空间也小。移动端接入实测服务端跑起来之后手机端怎么连上来OpenClaw默认开放了一个Web界面在局域网内直接用浏览器访问就行。但如果你想有App的体验有两条路。路径一PWA添加到桌面OpenClaw的Web界面支持PWA渐进式Web应用。在Chrome浏览器里打开服务端地址后浏览器右上角会出现一个添加到主屏幕的选项。点一下就会在桌面生成一个图标打开之后跟原生App几乎没区别——全屏显示、支持推送通知、离线缓存。我在Pixel 6上试了一下效果还行。消息收发延迟大概在100-200ms局域网环境下基本感觉不到延迟。不过在弱网环境下比如公司WiFi比较烂的时候偶尔会出现消息发送超时需要手动重发。路径二Telegram/Discord Bot对接OpenClaw原生支持通过Telegram Bot来交互。你不需要额外写什么客户端只需要在Telegram里跟你的Bot对话就行了。# config.yaml中添加Telegram配置 channels: telegram: botToken: ${TELEGRAM_BOT_TOKEN} allowedUsers: - 你的Telegram用户ID这个方案的优点是真正的跨平台安卓iOS都能用Windows桌面端也能用。缺点是消息经过Telegram中转有隐私方面的顾虑——虽然OpenClaw官方说消息内容不会被中间人读取但毕竟是第三方通道。我的建议如果你只是自己用、局域网环境下走PWA就够了。如果需要外网访问或者多人协作再考虑Telegram/Discord通道。几个实际遇到的坑坑1iPhone上PWA无法添加到桌面在iOS Safari上PWA添加到桌面的条件比安卓严格得多。要求网站必须有合法的HTTPS证书、必须有manifest.json文件、Service Worker必须正常注册。如果你在局域网环境下用HTTP访问Safari是不允许添加到桌面的。解决办法给服务端配一个自签名证书openssl就能生成然后在iPhone的设置里信任该证书。虽然麻烦但能解决。# 生成自签名证书 openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes # OpenClaw配置中启用HTTPS gateway: port: 3456 tls: key: /path/to/key.pem cert: /path/to/cert.pem坑2大模型响应流式输出在移动端的体验问题OpenClaw默认使用SSEServer-Sent Events来推送流式响应。在桌面浏览器里表现很好能看到文字一个个蹦出来。但在手机端尤其是iOS Safari上SSE的稳定性不太好——有时候会断连导致响应中断。我的workaround是把超时时间调大# 在config.yaml中 gateway: streamTimeout: 120000 # 120秒超时效果有改善但没有完全消除。这个应该是SSE协议在移动端的固有问题不是OpenClaw的bug。性能数据到底能不能日常用我跑了大概两天的一些数据记录供参考场景: 日常问答 代码生成 服务端: i5-12400 / 16GB RAM / Windows Server 模型: glm-4-flash智谱 冷启动时间: ~3.2秒首次请求到首个token 平均响应时间: ~1.5秒日常对话 代码生成: ~4-6秒中等复杂度 并发支持: 同时3个对话无明显延迟 内存占用: Gateway进程 ~180MBAgent进程 ~250MB CPU占用: 空闲时 2%推理时 ~15-25%说实话这个性能表现比我预期的好。之前以为跑个Agent框架会很吃资源结果发现大部分时间它就是在那待着只有用户发消息的时候才会调LLM接口。如果你的模型API调用走的是云端比如智谱、OpenAI那服务端的CPU压力其实很小。唯一的瓶颈在网络。如果你用的是国产模型API国内网络没问题。如果用OpenAI的API……那就看你有没有梯子了。和几个同类方案的对比为了让大家有个更直观的参考我简单列了一个对比。不是什么权威评测就是我个人使用后的主观感受。方案 | 本地部署 | 移动端 | 多Agent | 插件体系 | 学习成本 OpenClaw | 支持 | PWA/Bot | 原生支持 | Skill体系 | 中等 OllamaWebUI | 支持 | 浏览器 | 不支持 | 有限 | 低 Dify | 支持 | 浏览器 | 支持 | 插件生态 | 较高 LobeChat | 支持 | PWA | 不支持 | 插件生态 | 低 自建FastAPI | 需开发 | 需开发 | 需开发 | 完全自定义 | 高OpenClaw在多Agent和插件体系这两个维度上有明显优势。如果你需要同时跑多个不同角色的Agent比如一个写代码、一个查资料、一个管日程它的Agent隔离机制用起来确实方便。最后说两句这篇不是什么软文纯粹是我在折腾过程中记录的一些技术笔记。OpenClaw这个项目整体给我的感觉是——架构设计上有想法但生态还比较早期。Skill插件数量不多移动端的体验也还有优化空间特别是SSE流式在iOS上的稳定性。不过话说回来对于一个开源项目来说能做到这个程度已经挺不容易了。如果你对AI Agent的架构实现感兴趣或者刚好需要一个能跑在自己服务器上的AI助手框架它值得你花个周末试试。实在不想折腾命令行的直接去官网下载整合包三分钟搞定先跑起来再慢慢研究原理也不迟。