当前位置：首页 > news >正文

小龙虾App下载官网：安卓/iOS最新官方版免费获取

news 2026/6/19 18:59:27

上周有个做移动端开发的朋友问我："有没有那种能在手机上跑的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，新手容易搞乱。

方案B：Docker部署

如果你服务器上已经有Docker环境，这是最省心的方式。

# 拉取镜像 docker pull nicepkg/openclaw:latest # 运行容器 docker run -d \ --name openclaw \ -p 3456:3456 \ -v ~/.qclaw:/root/.qclaw \ -e ZHIPU_API_KEY=your_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通道。

几个实际遇到的坑

坑1：iPhone上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默认使用SSE（Server-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进程 ~180MB，Agent进程 ~250MB CPU占用: 空闲时 <2%，推理时 ~15-25%

说实话这个性能表现比我预期的好。之前以为跑个Agent框架会很吃资源，结果发现大部分时间它就是在那待着，只有用户发消息的时候才会调LLM接口。如果你的模型API调用走的是云端（比如智谱、OpenAI），那服务端的CPU压力其实很小。

唯一的瓶颈在网络。如果你用的是国产模型API，国内网络没问题。如果用OpenAI的API……那就看你有没有梯子了。

和几个同类方案的对比

为了让大家有个更直观的参考，我简单列了一个对比。不是什么权威评测，就是我个人使用后的主观感受。

方案 | 本地部署 | 移动端 | 多Agent | 插件体系 | 学习成本 OpenClaw | 支持 | PWA/Bot | 原生支持 | Skill体系 | 中等 Ollama+WebUI | 支持 | 浏览器 | 不支持 | 有限 | 低 Dify | 支持 | 浏览器 | 支持 | 插件生态 | 较高 LobeChat | 支持 | PWA | 不支持 | 插件生态 | 低 自建FastAPI | 需开发 | 需开发 | 需开发 | 完全自定义 | 高

OpenClaw在"多Agent"和"插件体系"这两个维度上有明显优势。如果你需要同时跑多个不同角色的Agent（比如一个写代码、一个查资料、一个管日程），它的Agent隔离机制用起来确实方便。