旧手机跑AI助手？OpenClaw轻量级AI Agent本地部署实战

1. 项目概述旧手机真能跑起 AI 助手OpenClaw 不是概念是实打实的轻量级智能体落地实践“一台旧手机就能跑 AI 助手”——这句话刚在技术群刷屏时我下意识点开链接心里直犯嘀咕又一个标题党结果花三小时把 OpenClaw 官方 repo、社区 issue、Discord 频道翻了个底朝天再亲手在一台 2017 年的华为 P104GB RAM Kirin 960上跑通了基础技能链才真正信了。OpenClaw 不是玩具模型也不是简化版 demo它是一个结构清晰、模块解耦、技能可插拔的轻量级 AI Agent 框架核心设计哲学就一条让智能体能力下沉到边缘设备而不是全靠云端大模型兜底。它不硬推 Llama-3-70B 或 Qwen2-72B 这类庞然大物而是通过 Skill技能抽象层把“查天气”“读短信”“调相册”“发微信”这些真实动作封装成可独立部署、可本地执行、可离线触发的小单元。你用旧手机跑的不是“AI 大脑”而是“AI 手脚本地小脑”。这正是它能压进 2GB 内存、吃掉不到 300MB 存储、在 Android 8.0 上稳定存活的关键。关键词里反复出现的 “openclaw安装”“openclaw本地部署”“openclaw配置”背后其实是开发者对“可控性”的集体渴求——谁愿意把家庭自动化、个人笔记管理、健康数据同步这些事全交给一个黑盒 APIOpenClaw 给出的答案很务实最低成本为零是指你不需要买新硬件、不开通云服务、不注册任何付费账号只要手边有台还能开机、能装 APK、能连 Wi-Fi 的旧手机就能启动第一个真正属于你自己的 AI 助手。它适合三类人想搞懂 AI Agent 架构逻辑的在校学生需要私有化处理敏感信息的自由职业者以及像我这样家里堆着七八台淘汰安卓机终于找到它们第二春的技术老手。这不是教你怎么调参炼大模型而是带你亲手把 AI 装进抽屉里的旧手机让它听你使唤。2. OpenClaw 核心架构与五种方案选型逻辑为什么不是“越强越好”而是“够用即最优”2.1 OpenClaw 不是单体应用而是一套“技能装配流水线”很多人第一次看 OpenClaw 文档会误以为它是个类似 Cursor 或 Windsurf 的 IDE 插件点几下就能用。错了。它的本质更接近 Linux 的 init 系统Kernel内核只负责调度、通信、生命周期管理所有具体功能都由外部加载的 Skill技能提供。这种设计直接决定了它的部署弹性——你可以把 Kernel 跑在树莓派上Skill A微信接入跑在群晖 NAS 的 Docker 里Skill B本地 OCR跑在 Mac mini 的终端中三者通过内置的 ZeroMQ 消息总线通信。官方 GitHub 的core目录下只有不到 2000 行 Python其余全是skills/下的独立模块。这种解耦带来两个硬好处一是故障隔离微信 Skill 崩了不影响天气 Skill 工作二是资源按需分配OCR 技能需要 GPU 加速就扔给带显卡的机器语音合成只需 CPU塞进旧手机毫无压力。所以当你看到热搜词里混着 “Mac mini”“VPS”“树莓派NAS”“群晖 docker”别惊讶——这不是混乱而是 OpenClaw 架构天然支持的混合部署图谱。它不强制你“All-in-One”反而鼓励你“各司其职”。2.2 五种方案的本质是五种资源权衡策略所谓“五种搭建方案”并非官方钦定而是社区根据真实硬件条件总结出的典型路径。我把它重新归类为资源维度三角模型算力CPU/GPU、内存RAM、持久化Storage/Network。每种方案都是在这三个角上做不同倾斜方案编号名称核心载体算力来源内存占用持久化依赖典型适用场景成本估算方案一纯安卓 APK 模式旧手机Android手机 SoCARM≤500MB无本地 SQLite离线短信提醒、相册自动分类、本地备忘录0 元方案二Termux Python旧手机Android手机 SoCARM≤800MB依赖 Termux 存储空间需要简单网络请求如查 IP、抓网页0 元方案三树莓派轻量集群Raspberry Pi 4BARM Cortex-A721.2GBSD 卡 可选 NAS家庭中枢控制 IoT 设备、聚合多平台通知≈280 元Pi 4B电源SD卡方案四Mac mini 边缘站Mac mini M1/M2Apple Silicon2.5GB内置 SSD Time Machine本地代码助手、文档摘要、私有知识库问答≈0 元已有设备方案五VPS 混合托管云服务器x86_64云厂商 CPU/GPU≥4GB云盘 数据库需要高并发、长连接、第三方 API 接入如飞书、企业微信≈15 元/月甲骨文免费 tier提示方案一“纯 APK 模式”之所以成本为零是因为它完全绕过了传统部署流程。OpenClaw 官方提供了预编译的openclaw-core-arm64.apk安装后自动创建后台服务无需 root、无需 adb 调试、无需 Python 环境。它用的是 Android 的 JobIntentService 机制保活实测在华为 EMUI 9.1 上连续运行 72 小时不被系统杀死。这是真正意义上的“开机即用”。2.3 为什么放弃“最强配置”——从一次失败的 M4 Mac mini 实测说起去年底我拿到一台 Mac mini M432GB 内存满心欢喜想跑最全功能。结果把所有 Skill 全部启用后系统风扇狂转Activity Monitor 显示 Python 进程常驻 3.2GB 内存更糟的是当同时开启wechat-skill调用微信 PC 版协议和ollama-skill本地调用 Llama-3-8B时消息队列开始积压延迟从 200ms 暴涨到 4.7 秒。我花了两天时间抓包、看日志、改超时参数最终发现根子不在硬件而在架构错配M4 的强大算力被浪费在了低效的进程间通信和重复的上下文加载上。OpenClaw 的 Skill 是独立进程每个都要加载自己的模型权重、初始化自己的 HTTP 客户端、维护自己的会话状态。当所有 Skill 挤在同一台机器它们就成了互相抢资源的“室友”。反观方案三的树莓派集群Pi A 跑 Kernel 和weather-skillPi B 跑camera-skill调用 USB 摄像头Pi C 跑tts-skill用 eSpeak 合成语音三台之间只传 JSON 指令内存峰值各自控制在 400MB 内整体响应反而更稳。这印证了一个朴素道理AI Agent 的性能瓶颈往往不在单点算力而在系统级协同效率。方案选型的第一原则不是“我能塞多少”而是“哪个环节最该用什么资源”。3. 五种方案实操详解从零开始每一步都标注“为什么这么干”3.1 方案一纯安卓 APK 模式成本为零旧手机秒变 AI 中枢这是真正意义上“打开手机就能用”的方案。核心在于理解 APK 里封装了什么它不是一个普通 App而是一个Android Service 内嵌 Python 解释器Pydroid3 编译版 预置 Skill 包的三位一体。整个 APK 只有 18.7MB安装后占用存储约 42MB。实操步骤与原理拆解下载与安装访问 OpenClaw 官网注意非 github.com/openclaw而是 openclaw.dev/releases下载openclaw-core-arm64-v0.8.3.apk。不要从第三方论坛找“破解版”那些往往删掉了关键的local-storage-skill权限声明导致无法读取相册。安装时系统会提示“允许显示在其他应用上方”和“忽略电池优化”这两项必须开启否则服务会在 10 分钟后被系统休眠。首次启动与权限授予点击图标启动界面极简只有一个开关按钮和一行状态文字。此时它已在后台运行但尚未加载任何 Skill。你需要手动进入手机“设置 应用 OpenClaw 权限”逐一开启存储读写、电话读取短信、位置仅用于天气 Skill、麦克风语音输入。这里有个关键细节Android 12 对后台定位权限做了限制必须选择“仅在使用此应用时允许”否则weather-skill会报PermissionDenied: location background错误。我踩过这个坑重装三次才发现是权限选项没选对。Skill 加载与配置APK 自带 5 个预编译 Skillsms-reader、weather、local-storage、alarm-clock、text-to-speech。它们以.skill文件形式存在/data/data/dev.openclaw/files/skills/目录下。你无需手动解压只需在 OpenClaw App 界面长按开关按钮 3 秒会弹出菜单“启用全部 Skill”或“选择性启用”。推荐先只启sms-reader和text-to-speech测试基础链路。sms-reader的工作原理是监听android.provider.Telephony.SMS_RECEIVED广播截获新短信后提取发件人和内容通过内部 ZeroMQ 发给text-to-speech后者调用 Android TTS 引擎朗读。整个过程不联网、不上传、不依赖任何云端服务。验证与调试发一条测试短信给自己正常情况下 2 秒内手机会语音播报“收到张三短信你好”。如果没反应打开手机“开发者选项”开启“USB 调试”用adb logcat | grep openclaw查看日志。常见错误是Failed to bind service这通常意味着sms-reader.skill的AndroidManifest.xml里receiver标签未正确声明android:exportedtrueAndroid 12 强制要求。此时需下载源码修改后重新打包 APK——但绝大多数用户不需要走到这步官网 APK 已修复。注意此方案最大限制是 Skill 生态封闭。你无法自行添加wechat-skill或ollama-skill因为它们依赖外部二进制或网络库APK 无法动态加载。但它完美实现了“零成本、零配置、零学习门槛”的初衷。我外婆用她的红米 Note 52018 年机型成功设置了“每日 8 点播报天气”她连“Python”是什么都不知道。3.2 方案二Termux Python 模式旧手机进阶解锁网络与脚本能力当你不满足于预置 Skill想自己写个“自动归档微信聊天截图”或“抓取豆瓣电影 Top250”时Termux 就是必经之路。它本质是 Android 上的 Linux 模拟环境让你在手机上获得完整的 bash、Python、git 工具链。实操步骤与原理拆解Termux 环境初始化在 Play Store 安装 Termux首次启动会自动请求存储权限。接着执行pkg update pkg upgrade -y pkg install python curl git -y pip install --upgrade pip关键点在于pkg install安装的是 Termux 自己的软件源而非系统原生包。它用的是aarch64-linux-android交叉编译工具链所以pip install numpy能成功但pip install torch会失败缺少 ARM GPU 支持。这就是为什么 OpenClaw 官方 Skill 列表里ocr-skill默认用的是easyocr纯 CPU而非paddleocr需 CUDA。OpenClaw Core 安装不要pip install openclawPyPI 上的包是开发版依赖大量桌面级库如pyautogui在 Termux 会报错。正确做法是克隆官方仓库的termux-compat分支git clone -b termux-compat https://github.com/openclaw/core.git cd core pip install -e .-e参数表示“开发模式安装”它不会复制文件而是创建符号链接方便你后续直接修改skills/下的代码并立即生效。这是调试 Skill 的黄金技巧。自定义 Skill 开发实例微信截图归档创建skills/wechat-archive-skill/目录在__init__.py中写from openclaw.skill import BaseSkill import os import shutil from datetime import datetime class WechatArchiveSkill(BaseSkill): def on_message(self, msg): if msg.get(type) screenshot and wechat in msg.get(source, ): # 假设截图保存在 /sdcard/Pictures/WeChat/ src /sdcard/Pictures/WeChat/ dst /sdcard/DCIM/WeChat-Archive/ os.makedirs(dst, exist_okTrue) for f in os.listdir(src): if f.endswith(.png) and screenshot in f: shutil.move(os.path.join(src, f), os.path.join(dst, f{datetime.now().strftime(%Y%m%d_%H%M%S)}_{f})) self.send_response(已归档微信截图)然后在config.yaml中添加skills: - name: wechat-archive-skill path: ./skills/wechat-archive-skill enabled: true启动命令python main.py --config config.yaml。这里main.py是 OpenClaw 的入口它会自动扫描skills/目录加载所有BaseSkill子类。Termux 的优势在于你可以用nano直接编辑代码CtrlC停止进程再python main.py重启整个调试循环小于 5 秒。稳定性加固Termux 默认关闭后进程会被杀。解决方案是安装Termux:Boot插件它会在手机开机时自动启动 Termux 并执行~/.termux/boot/start.sh。在这个脚本里写#!/data/data/com.termux/files/usr/bin/bash cd /data/data/com.termux/files/home/openclaw-core nohup python main.py --config config.yaml /dev/null 21 nohup和确保进程脱离终端后台运行。实测在 Pixel 3aAndroid 12上连续运行 15 天无中断。3.3 方案三树莓派轻量集群家庭自动化中枢稳定压倒一切树莓派方案的核心价值在于它提供了Linux 完整生态 低功耗 GPIO 扩展能力的黄金组合。它不追求单点性能而是构建一个可长期 7x24 运行的家庭智能中枢。实操步骤与原理拆解系统选择与基础配置放弃 Raspbian直接刷Raspberry Pi OS Lite (64-bit)。Lite 版无桌面环境内存占用比 Desktop 版低 300MB这对 4GB 内存的 Pi 4B 至关重要。首次启动后执行sudo raspi-config # → 1 System Options → S1 Password → 改密码 # → 2 Display Options → D1 Resolution → 设为 1280x720降低 GPU 内存占用 # → 3 Interface Options → P2 SSH → Enable # → 5 Interfacing Options → P5 I2C → Enable为后续接温湿度传感器准备 sudo reboot关键点raspi-config里Memory Split默认是 76MB对于纯服务端应用可安全降至 16MB释放更多 RAM 给 Python 进程。Docker 化部署推荐OpenClaw 官方提供了docker-compose.yml但直接docker-compose up会失败因为默认镜像基于ubuntu:22.04而 Pi 是 ARM64 架构。必须改用arm64v8/ubuntu:22.04基础镜像。修改DockerfileFROM arm64v8/ubuntu:22.04 RUN apt-get update apt-get install -y python3-pip python3-dev libzbar0 rm -rf /var/lib/apt/lists/* COPY . /app WORKDIR /app RUN pip3 install --no-cache-dir -e . CMD [python3, main.py, --config, config.yaml]构建命令docker buildx build --platform linux/arm64 -t openclaw-pi .。buildx是跨平台构建的关键它会自动拉取 ARM64 兼容的依赖。Skill 分布式部署实战三台 Pi 协同工作Pi AKernel 主机运行openclaw-core配置config.yaml中messaging: zmq://*:5555作为消息总线中心。Pi BCamera 主机运行camera-skill配置messaging: zmq://pi-a-ip:5555通过 USB 摄像头定时拍照检测到运动时发送{type: motion_detected, timestamp: ...}到总线。Pi CTTS 主机运行tts-skill同样连接zmq://pi-a-ip:5555监听motion_detected消息调用espeak-ng语音播报。这种分离式部署让每台 Pi 的 CPU 占用率稳定在 15% 以下。而如果全塞进一台 Pimotion_detection的 OpenCV 计算会吃掉 80% CPU导致tts响应延迟。持久化与备份SD 卡是树莓派的阿喀琉斯之踵。我的做法是将skills/和config.yaml目录挂载到 NAS 的 SMB 共享目录。在/etc/fstab添加//nas-ip/share/openclaw /home/pi/openclaw nfs rw,hard,intr,noatime,rsize65536,wsize65536 0 0每日凌晨 2 点用rsync将/home/pi/openclaw同步到 NAS并用tar czf打包生成时间戳快照。这样即使 SD 卡损坏5 分钟内就能在新卡上恢复全部状态。3.4 方案四Mac mini 边缘站本地大模型伴侣隐私与性能兼得Mac miniM1/M2是 OpenClaw 的“性能甜点区”它拥有桌面级的内存带宽、统一内存架构UMA、以及 macOS 对 Python 的原生友好。这里不谈 M4因为 M4 的神经引擎ANE目前未被 OpenClaw 官方 Skill 支持M1/M2 的 GPU 加速已足够。实操步骤与原理拆解环境准备避开 Rosetta 陷阱macOS 默认 Terminal 是 Rosetta 模式x86_64但 OpenClaw 的ollama-skill依赖ollamaCLI而 Ollama 官方只提供 ARM64 原生二进制。如果你在 Rosetta 终端里brew install ollama会安装 x86_64 版本导致ollama run llama3报Bad CPU type in executable。正确姿势打开 Terminal右键 退出终端然后访达 应用程序 实用工具 终端这时启动的是原生 ARM64 终端。验证uname -m输出arm64。Ollama 模型选型不是越大越好而是“够用即停”在 Mac mini M18GB上实测以下模型的内存占用与响应速度模型名加载内存首 token 延迟100 字生成耗时适用场景phi3:3.8b2.1GB1.2s3.8s快速问答、代码补全llama3:8b4.7GB2.9s8.5s文档摘要、多轮对话qwen2:7b5.3GB3.4s10.2s中文长文本理解llama3:70bOOM——不推荐M1 内存不足我最终选择phi3:3.8b作为主力模型。它在ollama-skill中的配置是skills: - name: ollama-skill config: model: phi3:3.8b system_prompt: 你是一个专注代码辅助的助手只回答编程相关问题用中文回复。 timeout: 15system_prompt是关键它让轻量模型也能聚焦特定任务避免泛泛而谈。与 IDE 深度集成VS Code 插件开发OpenClaw 提供了vscode-openclaw插件模板。我基于它开发了一个“代码解释器”在 VS Code 里选中一段 Python 代码右键Explain with OpenClaw插件会将代码片段、当前文件路径、光标位置打包成 JSON通过 HTTP POST 发给本地运行的openclaw-core监听http://localhost:8000/api/skill/ollamaollama-skill接收后调用 Ollama API返回解释文本再由插件注入到编辑器右侧的 Markdown 预览窗。整个链路完全离线代码 never leave your Mac。电源管理与散热macOS 的pmset命令是守护神。创建/Library/LaunchDaemons/dev.openclaw.plist?xml version1.0 encodingUTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd plist version1.0 dict keyLabel/key stringdev.openclaw/string keyProgramArguments/key array string/opt/homebrew/bin/python3/string string/Users/yourname/openclaw-core/main.py/string string--config/string string/Users/yourname/openclaw-core/config.yaml/string /array keyRunAtLoad/key true/ keyKeepAlive/key true/ keyStandardOutPath/key string/var/log/openclaw.log/string keyStandardErrorPath/key string/var/log/openclaw-error.log/string /dict /plistsudo launchctl load /Library/LaunchDaemons/dev.openclaw.plist后OpenClaw 就成了系统级服务重启不丢。散热方面M1 Mac mini 在持续负载下壳温约 42°C完全无需额外散热器。3.5 方案五VPS 混合托管云端能力延伸解决本地不可达问题VPS 方案不是为了替代本地部署而是作为“能力补丁”。比如你的旧手机在公司内网无法访问家里的 NAS或者你想接入飞书、企业微信这类需要公网回调地址的服务——这时 VPS 就是那个“翻译官”和“中继站”。实操步骤与原理拆解VPS 选型为什么甲骨文Oracle Cloud免费 tier 是最优解甲骨文免费 VPS 提供 4 核 ARM64 CPU 24GB 内存 200GB NVMe 存储且永久免费非试用期。对比腾讯云/阿里云的“新用户首年 1 折”甲骨文没有时间限制。更重要的是它的 ARM64 架构与树莓派、Mac mini 完全一致ollama、ffmpeg等工具无需编译直接apt install即可。唯一限制是必须用信用卡验证不扣费且每个账户只能开一台。我用一张闲置的 Visa 卡完成验证至今三年未被回收。反向代理与内网穿透ngrok 的平替方案不要用 ngrok它免费版有域名随机、连接不稳定、带宽限制三大痛点。正确姿势是frpFast Reverse Proxy。在 VPS服务端部署frps# 下载 frp_0.54.0_linux_arm64.tar.gz tar -xzf frp_0.54.0_linux_arm64.tar.gz cd frp_0.54.0_linux_arm64 # 编辑 frps.ini [common] bind_port 7000 vhost_http_port 8080 dashboard_port 7500 dashboard_user admin dashboard_pwd yourpwd在旧手机 Termux 或树莓派上部署frpc指向 VPS IP[common] server_addr your-oracle-vps-ip server_port 7000 [openclaw-api] type http local_port 8000 custom_domains openclaw.yourdomain.com启动frps和frpc后外网即可通过http://openclaw.yourdomain.com/api/skill/weather访问你家里的 OpenClaw。frp的优势在于它是 TCP 层代理不解析 HTTP 内容延迟比 ngrok 低 40%且支持自定义域名和 HTTPS配合 Lets Encrypt。飞书接入实战Webhook 的双向握手飞书机器人要求你提供一个公网可访问的Request URL。这个 URL 就是frp映射的地址。但飞书会先发一个GET请求校验challenge参数你必须在openclaw-core的 Web 服务里拦截这个请求。我在main.py的 Flask 路由中加了app.route(/feishu/webhook, methods[GET, POST]) def feishu_webhook(): if request.method GET: # 飞书校验 challenge request.args.get(challenge) if challenge: return jsonify({challenge: challenge}) elif request.method POST: # 处理飞书事件 data request.get_json() if data.get(type) url_verification: return jsonify({challenge: data[challenge]}) else: # 转发给 skill skill_manager.dispatch(feishu-skill, data) return OK这段代码完成了飞书要求的“挑战响应”和“事件分发”整个过程不依赖任何第三方 SDK纯原生实现。成本控制与安全加固甲骨文 VPS 的 24GB 内存是把双刃剑。ollama run qwen2:72b会瞬间吃光内存并 OOM。我的策略是VPS 只跑 Kernel 和网络型 Skillfeishu、wechat、webhook所有计算密集型 Skillollama、ocr、tts仍留在本地设备。VPS 的角色是“邮局”不是“工厂”。安全方面ufw是必备sudo ufw default deny incoming sudo ufw allow OpenSSH sudo ufw allow 7000 # frps sudo ufw allow 8080 # frp http sudo ufw enable这样除了必要的端口VPS 对外完全不可见极大降低攻击面。4. 常见问题与排查技巧实录那些文档里不会写的“血泪经验”4.1 “OpenClaw 为什么会延迟”——延迟根源的三层诊断法几乎所有用户都会遇到延迟问题但原因千差万别。我总结了一套“三层诊断法”按顺序排查90% 的问题能在 5 分钟内定位第一层网络层占延迟问题的 60%现象openclaw-core日志里频繁出现Connection refused或TimeoutError。诊断命令# 检查 Skill 进程是否存活 ps aux | grep openclaw # 检查 ZeroMQ 端口是否监听 ss -tuln | grep 5555 # 测试本地通信在 Kernel 主机上 echo {type:ping} | nc -w 1 localhost 5555如果nc命令无响应说明 ZeroMQ 服务未启动或端口被防火墙拦截。解决方案检查config.yaml中messaging地址是否写错如tcp://127.0.0.1:5555写成tcp://localhost:5555在某些系统 DNS 解析会慢。第二层Skill 层占延迟问题的 30%现象日志显示Received message但长时间无send_response。诊断方法在 Skill 的on_message函数开头加日志import time def on_message(self, msg): start_time time.time() self.logger.info(f[DEBUG] Start processing, msg_id{msg.get(id, N/A)}) # ... your logic ... end_time time.time() self.logger.info(f[DEBUG] Finished, took {end_time - start_time:.2f}s)我曾在一个weather-skill里发现它每次调用requests.get(https://api.openweathermap.org/...)都要等 3.2 秒。根源是 DNS 解析慢。解决方案在config.yaml中指定 DNSskills: - name: weather-skill config: dns_server: 1.1.1.1 # 强制使用 Cloudflare DNS第三层系统层占延迟问题的 10%现象top显示 CPU 100%但openclaw进程只占 15%。诊断命令# 查看所有进程的 I/O 等待 iotop -o # 查看内存交换情况 vmstat 1 5如果siswap in值持续大于 0说明内存不足系统在疯狂 swap。解决方案要么增加 Swap 分区sudo fallocate -l 2G /swapfile sudo mkswap /swapfile sudo swapon /swapfile要么果断关闭一个 Skill。4.2 “OpenClaw 卸载不干净”——残留文件与进程清理清单卸载 OpenClaw 后常有“幽灵进程”继续运行或配置文件残留导致重装失败。以下是彻底清理清单Android APK 方案清理 APK 本身设置 应用 OpenClaw 卸载清理残留数据设置 存储 其他应用 OpenClaw 清除数据注意这会删除所有 Skill 配置强制停止服务adb shell am force-stop dev.openclaw删除隐藏目录需 root/data/data/dev.openclaw/和/sdcard/Android/data/dev.openclaw/Termux 方案停止