OpenClaw这几周在AI圈子里的热度是真的高，GitHub上刷star的速度快得离谱，社区里问得最多的就是：这东西到底怎么跑起来？跑起来之后应该用哪一套工具链才能让它干活顺手？我这段时间在安卓手机、Windows电脑、还有一台吃灰的树莓派上反复折腾OpenClaw，把踩过的坑和留下来的工具整理了一遍。这篇文章就当成一份自用的OpenClaw工具精选清单，从部署环境、算力接入到Skills扩展都覆盖到，如果你正好卡在某个安装配置环节，或者不知道怎么选模型接入方式，可以直接按这份清单来动手。
1. 部署环境类工具：从手机到服务器一把梭
OpenClaw的部署逻辑和传统软件不太一样，它本身是一个常驻后台的Agent服务，对外暴露统一入口，再由你决定通过什么终端去跟它对话。这个架构决定了部署的重点不在“装一个App”，而在“把常驻进程跑稳、跑通”。我按使用场景把部署工具分成三类：Termux（安卓）、Windows Companion、还有Docker/裸机服务器方案，大部分人的需求这三类就全覆盖了。
1.1 Termux安卓部署：把OpenClaw装进口袋
随身带一个Agent确实很爽，手机部署唯一合理的方案就是Termux。Termux本质是个安卓上的Linux终端环境，包管理、后台进程、文件系统都跟Linux接近，OpenClaw的主程序在里面跑，跟跑在服务器上几乎没有区别。我自己实测下来的步骤是这样：先在Termux里执行pkg update和pkg upgrade，把基础软件源和依赖都刷到最新，这一步不做后面经常会遇到包版本对不上的问题。接着安装Git和运行时环境，命令是pkg install git，然后按照你拉取的OpenClaw版本要求补齐对应运行时，社区版本一般还需要pkg install python或Go环境，这部分以官方release说明为准。然后把项目仓库clone到本地，执行安装脚本或者把预编译二进制放到/data/data/com.termux/files/usr/bin目录下，方便全局调用。第一次启动后去编辑配置文件，把模型服务地址、通信端口、Agent名称这些基础项填好，配置文件通常是TOML或YAML格式，默认位置在~/.openclaw/config，里面字段看起来多，但必填的只有模型接口和运行端口两项。
这里要专门提醒三个手机部署的细节。第一，Termux的进程很容易被安卓系统回收，所以要用tmux开一个持久会话来跑OpenClaw，我一般是开一个叫claw的会话，然后用tmux attach -t claw重新连回来。第二，务必把Termux加入电池优化的白名单，否则息屏一小时进程就被杀了，你问它问题它根本不在线。第三，存储权限要手动授予，否则后面写Skills、读配置文件都会提示Permission denied。这三个细节看着不起眼，但任何一个不处理好，手机上的OpenClaw都会处于“装了但用不了”的状态。
在手机上部署的一个额外好处是，你可以把那台旧手机当成一个低功耗常驻设备放在家里，插着电连着Wi-Fi，跑轻量级技能完全够用。我自己就是拿一台旧手机当家庭Agent，白天在外面通过消息渠道往里丢指令，它自己在家把定时任务跑完，体验比开一台台式机省电得多。而且Termux环境下OpenClaw对系统资源的占用其实很低，空闲时基本不耗CPU，只有接到指令才会瞬时拉起推理任务。
1.2 Windows Companion配置：桌面级常驻助手的正确姿势
如果你主力机是Windows，那OpenClaw的Windows Companion是你最顺手的入口。Companion这套东西定位不是主进程，而是“配对客户端”，主服务在后台跑，Companion在系统托盘提供交互入口。很多人在这一步卡在概念上：我装了Companion为什么连不上？因为你根本没在Windows上启动主服务，Companion只是个壳，真正干活的是后台那个主进程。
正确配置路径是这样的：下载Windows发行包，或者Git clone源码自己编译，先运行一次主服务，让它生成默认配置文件；然后编辑配置文件，关键是设置好host和port，默认通常是本机回环地址加一个自定义端口，注意端口别跟现有服务冲突；接着启动Companion，配对它和主服务的通信密钥或Token，首次启动时会有引导提示；最后配置开机自启，这里不建议直接丢进启动文件夹，而是用任务计划程序创建一个“登录时启动”的任务，再把主服务注册成计划任务，这样即使没有用户登录，服务也会在后台待命。
关于Windows部署还有一个很多人不知道的技巧：如果你希望OpenClaw在Windows上做到无人值守，可以用NSSM把主服务包装成一个真正的Windows系统服务。NSSM全称Non-Sucking Service Manager，作用就是让一个普通exe程序以服务方式运行，崩溃了能自动拉起，日志也归Windows事件系统管。我用它跑了将近两个月，稳定度远高于直接开一个控制台窗口——控制台窗口不小心关掉，Agent就断了，服务化的方式则完全不用担心这个问题。一个值得注意的问题是，Windows下OpenClaw默认会监听一个本地端口，如果开启了系统防火墙，记得把该端口加入到入站允许列表，否则手机或局域网里其他设备会连不进来，这个端口放行问题也是Windows部署里容易被忽略的坑。
1.3 服务器与Docker部署：多人多设备统一接入
当你不满足于单一设备，想让家里的电脑、手机、甚至项目里的几个朋友共用一个Agent实例时，就该上服务器部署了。Docker是这场景下最省心的方式，官方镜像或社区打包镜像基本都配置好了运行时依赖，你只需要用docker-compose.yml定义服务、映射端口、挂载配置目录：
version: "3.8" services: openclaw: image: openclaw/openclaw:latest container_name: openclaw restart: unless-stopped ports: - "8080:8080" volumes: - ./config:/root/.openclaw - ./skills:/root/.openclaw/skills environment: - CLAW_MODEL=ollama/qwen2.5:7b - CLAW_API_BASE=http://host.docker.internal:11434启动命令就一行docker compose up -d。这种方式的好处有两个：一是配置文件和Skills目录都挂载在宿主机上，你编辑技能或改配置不需要进容器；二是restart: unless-stopped保证进程挂掉会自动重启，对于Agent这种需要常驻的服务来说非常关键。如果你没有外网服务器，也可以在一台局域网内的旧电脑上做同样的事情，效果基本一致。树莓派跑OpenClaw也完全可行，Arm架构的预编译包一般都有提供，没有的话用源码编译也很简单，只是首次编译时间会长一点。
2. 算力与模型接入：API还是本地模型？
围绕OpenClaw问得最多的一个问题，就是“它是不是只能用接入API的方式来用算力”。答案是：不是。OpenClaw的算力来源完全是插拔式的——API只是最省事的一条路，本地模型、局域网模型服务、混合路由，这些都能跑。下面把三种方式拆开讲清楚。
2.1 本地模型搭配Ollama：零成本、低延迟、完全离线
把OpenClaw接到本地模型，我推荐的主力工具是Ollama。Ollama做的事情很简单：在你自己的电脑上跑一个兼容OpenAI接口的轻量服务，下载模型、加载、推理都帮你管好。OpenClaw只需要把API地址指向本地，模型名填成Ollama里的模型名，就能完成对接。
具体配置分两步。第一步，在宿主机上安装Ollama，拉取一个合适的模型，比如ollama pull qwen2.5:7b，或者数据更小的qwen2.5:3b。第二步，让Ollama监听局域网端口——默认Ollama只绑定了127.0.0.1，要让其他设备能访问，需要设置环境变量OLLAMA_HOST=0.0.0.0:11434再重启服务。之后在OpenClaw配置里把模型接口填成http://<宿主机IP>:11434即可。配置大概长这样：
[model] name = "qwen2.5:7b" api_base = "http://192.168.1.100:11434" type = "ollama"然后是大家最关心的性能问题。7B级别的模型在M系列芯片或者带独显的电脑上能做到每秒十几个token的推理速度，对于“帮我列个购物清单”“把这篇文章总结成三条”这类任务完全够用。如果你的电脑没独显，用CPU跑3B或4B的小模型也能用，只是速度慢一点，记得把超时时间调大。完全离线这一点对我来说非常关键，OpenClaw接上本地模型后，断网状态下也照样能干活，这直接解决了“家里网络一抖、Agent就瘫痪”的问题。
2.2 API模式接入：多模型切换与成本估算
API模式的优势是模型天花板高，你可以在OpenClaw里直接使用各家云端大模型，这些模型的能力远超本地小模型，适合做复杂推理、长文本生成、代码编写。配置也很简单，只需要把API密钥、接口地址和模型名填到配置里。我以一份实际配置为例：
[model] name = "gpt-4o-mini" api_base = "https://api.openai.com/v1" api_key = "sk-..." type = "openai"如果你用的是其他模型服务商，只要它提供OpenAI兼容接口，同样改api_base和api_key就能切过去。这种兼容接口在市场上已经很普遍，几乎成了事实标准。关于成本，我说一个比较直观的计算方式：一个普通的中文问答，假设用户输入大约300字，模型回复大约500字，按照中文每个字大约对应1到2个token来估算，一次的token消耗大约是1500到2000个。以目前主流入门级模型的定价来算，这样的对话单价在一分钱以内；即使使用旗舰模型，普通对话的成本也就在几分钱到一毛钱之间。如果你的使用场景是每天几十次交互量级的个人助手，API模式的月度账单不会成为让人焦虑的数目。唯一需要留意的是，API模式下你的数据会经过第三方服务，对数据敏感的场景就要慎用。
2.3 混合模式：让本地小模型和云端大模型各司其职
用了一段时间纯API和纯本地后，我的最终选择是混合模式。思路很简单：简单指令走本地小模型，复杂任务才走云端大模型。OpenClaw的Skills机制让这个路由变得很方便——你可以在每个Skill里单独指定它调用哪个模型。比如我定义了一个“天气查询”技能，它只需要做固定的信息抓取，我就让它调用本地3B模型，响应快、不花钱；而“写周报”这种高要求的技能，我就在配置里指定云端大模型，保证输出质量。
这里的技巧在于一次调用的“分工”：不要想着让AI自己做判断该用哪个模型，而是直接在人机交互的入口层用规则判断，或者干脆在配置层写好每个Skill对应的模型。对于普通用户来说，只需要知道一点：本地模型省的是钱和延迟，云端模型省的是折腾的时间，两者并不互斥。三种方式对比如下：
| 接入方式 | 优势 | 劣势 | 适合场景 |
|---|---|---|---|
| 纯API | 效果好、配置简单、模型选择多 | 有费用、依赖网络、数据出本机 | 个人主力助手、复杂任务 |
| 纯本地(Ollama) | 免费、离线可用、延迟低 | 模型上限低、需要一定硬件 | 隐私敏感、轻量任务、断网环境 |
| 混合模式 | 兼顾质量与成本 | 需要额外路由配置 | 日常高频使用、多Skill场景 |
3. 扩展生态：Skills、机器人集成与自动化中枢
OpenClaw真正的玩法在扩展性上。它不是一款“给你一个对话框”的工具，而是一套可以不断往上面添加“能力”的Agent框架。这部分我重点讲两个方向：一是Skills技能开发，二是跟ROS 2 + Gazebo的机器人模拟集成，后面这个方向是很多玩机器人的人非常关心的路子。
3.1 OpenClaw Skills：给Agent装上手和脚
Skills就是OpenClaw里的“技能”。每个Skill本质上是一个带结构化说明的文件和一段可执行逻辑，OpenClaw在对话中识别到意图后，触发对应的Skill完成具体操作。它跟Claude Skills、Cursor Rules这类方案的思路是同源的，只是生态和写法上有自己的习惯。我给你的最小可运行Skill模板是这样：
--- name: timer_remind description: 设置一个倒计时提醒，到时间后通知用户 version: "1.0" inputs: - name: duration description: 提醒时长，例如"10分钟" required: true - name: message description: 提醒内容 required: false --- 当用户说"提醒我xxx"或"帮我设个倒计时"时触发本技能。 调用系统定时器，在duration到达后，将message通过默认消息渠道发送给用户。文件放在~/.openclaw/skills/timer_remind/SKILL.md，重启OpenClaw后技能就生效了。第一次写不需要懂复杂代码，先把描述写清楚，把触发词和参数列出来，剩下的执行逻辑可以用简单的脚本或系统命令完成。另外提一句，OpenClaw对中文的支持本身就很友好，Skills描述可以直接用中文写，模型也天然支持中文上下文，不存在汉化障碍，这一点对国内用户来说省事不少。
Skills真正的价值在于，它让Agent不再只是一个应答机器人，而是变成了一个能操作你电脑、读取文件、调用API、控制硬件的“手脚”。我自己写了一个“晚餐推荐”技能，它把冰箱现有的食材清单喂给模型，让模型给出菜谱组合，再顺带生成买菜清单，整个技能也就几十行配置，但使用频率比普通的问答高得多。
3.2 机器人集成实操：OpenClaw + ROS 2 + Gazebo的模拟链路
这个方向很多玩机器人的朋友会关注。如果你想让OpenClaw作为机器人的“大脑”，在Gazebo仿真环境里跑通“感知—决策—控制”闭环，需要一串工具链：ROS 2 Humble + Gazebo仿真器 + 一个桥接方案。先说架构：OpenClaw本身不直接跟Gazebo通信，它要借助ROS 2的消息机制。Gazebo里运行的机器人不断地把激光雷达、里程计、摄像头数据发布成ROS 2话题；OpenClaw侧通过一个Skill去订阅这些话题、处理数据、做出判断，最终向/cmd_vel这类速度指令话题发布控制消息。这个链路打通之后，你等于让OpenClaw拥有了一个“虚拟身体”。
实际操作中，社区里有人把这一套集成做成了一个叫rosclaw的启动脚本工具形态，核心就是帮你省去手动配置ROS 2工作空间和话题桥接的麻烦。你在Gazebo里启动机器人模型后，再执行rosclaw的脚本，它会自动完成三件事：一是source ROS 2环境并启动必要的桥接节点；二是把OpenClaw的Skill注册到ROS 2节点树上；三是建立话题映射，将传感器话题接入OpenClaw，将控制指令转发给机器人。
我给你的建议是，第一步先在纯ROS 2环境下跑通ros2 topic list和ros2 topic echo，确认仿真器已经正常发布数据，然后再接OpenClaw。很多人一上来就在集成环境里调试，结果分不清是仿真器的问题还是桥接的问题。基础通了你再往上叠加Agent逻辑，排查起来会轻松很多。这一整套如果要用一个生活类比来解释：OpenClaw相当于大脑皮层，负责语义理解和决策；ROS 2相当于脑干和脊髓，负责把神经信号转成肌肉动作；Gazebo就是跑步机，给你一个安全的训练场地。每部分各司其职，中间任何一根“神经”断了机器人都不会动，所以集成调试的核心就是逐段验证。
3.3 周边工具链组合：语音、消息渠道和任务调度
除了核心技能，还有一些工具能让OpenClaw的使用体验提升一个档次。语音方向，我推荐faster-whisper或者whisper.cpp，它们在本地做语音转文字，延迟低、运行稳定，配合OpenClaw就能实现完全本地的语音助手，杂音环境下的识别效果在可接受范围内。
消息渠道方面，OpenClaw支持接入多种即时通讯工具，把Agent挂到常用聊天软件里之后，你在手机上随时可以交代任务，它干完活再主动把结果推给你。定时任务直接交给系统的cron或者OpenClaw自己的调度器就可以，让Agent每天早上自动生成日程摘要，这种“主动输出”的体验和“被动回答”完全不一样。这一组工具搭配下来，OpenClaw就不只是一个对话机器人了，它更像一个能听懂语音、能在聊天软件里协作、能按照时刻表干活的数字同事。
4. 常见问题与排查技巧实录
这段时间我收到最多的求助基本都集中在部署和联调这两关，我把高频问题和排查思路整理成了速查表，你在实际动手时可以直接按表排查。
4.1 手机与Termux部署的典型问题
pkg install提示找不到包：先执行pkg update，Termux的软件源索引不定时更新，老源里可能已经挂掉或移除部分包路径。- 后台进程总是被杀：除了加入电池优化白名单，还要检查是否有清理类App在做“一键清理”，清理进程会连带把Termux的常驻进程终止掉。直接把Termux加入这些App的忽略名单，比任何配置都有效。
- 技能文件放在手机上后技能不生效：大概率是目录权限问题，用
termux-setup-storage授权一下存储访问。
另一个经常被忽略的点是配置文件编码。手机端用文本编辑器改配置时，如果保存成了带BOM的UTF-8，OpenClaw在解析时会直接报错，建议优先用Termux里的nano或vim编辑，而不是手机上常见的第三方编辑器。遇到解析报错时先查编码，这个问题比你想的常见得多。
4.2 模型接入与API连接问题
- 本地Ollama在其他设备上连不上：先确认宿主机的Ollama是否设置了
OLLAMA_HOST=0.0.0.0:11434，只看服务本机自启是不够的。然后在OpenClaw所在设备上用curl http://<宿主机IP>:11434测试连通性，能通再回OpenClaw侧检查配置。 - API返回401或403：不要急着怀疑密钥过期，先检查
api_key字段有没有复制出多余的空格或换行，这类问题十次里有八次是这个原因。 - 对话时长时间没响应：注意OpenClaw的请求超时时间设置。本地小模型在CPU上推理可能需要几十秒，默认超时如果只有10秒，就容易出现“问完没反应”的假死现象。把超时调大到120秒能解决绝大多数误判。
还有一个关于模型切换的要点：如果你从API切到本地模型，记得把配置文件里的type和api_base一起改掉，很多人只改了模型名，结果没生效，就是因为类型字段还停留在openai，指向的还是API服务。
4.3 机器人集成环节的避坑要点
- 在启动任何节点之前，记得先执行
source /opt/ros/humble/setup.bash，否则节点之间版本不一致会导致话题找不到。 - 话题名称必须逐字对照，
/cmd_vel和cmd_vel是不一样的，用ros2 topic list去确认实际存在的名称，而不是凭记忆写。 - Gazebo仿真环境启动慢是正常的，别一启动就去测，等模型加载完成、话题稳定出现在列表里之后再开始跑OpenClaw的集成脚本。
- 如果机器人原地打转或者乱走，先检查TF坐标系是否完整，
ros2 run tf2_tools view_frames可以快速导出坐标树，确认机器人的base_link和odom之间有没有断链。
这一条尤其值得说出来：机器人集成不是一个“一把梭”的活儿，它天生就是分层的事情。分层去排查，每一层都验证通过了再进下一层，你的时间会省很多；反过来，什么都不验证直接集成，最后排查的时间会成倍增加。
我个人实际使用中，建议你把第一套环境搭在纯API模式下跑通全链路，再换成本地模型。因为API模式没有环境和推理性能的干扰，能更快帮你确认配置文件、Skill逻辑和消息渠道都没问题；这一层稳定了，换本地模型时问题再出现，就能定位到是算力侧而不是框架侧。这套“先易后难、逐层替换”的思路，适用性远远不限于OpenClaw一个项目，任何Agent类工具都可以这么磨合。
最后再分享一个小技巧：OpenClaw的配置文件底稿记得做版本管理，哪怕只是丢进Git仓库里，每次大改之前能回滚，这比任何备份方案都管用。工具选型也是一样的逻辑，没必要一上来就上最重的那套方案，先用最简单的跑通，再慢慢加砝码，你会发现自己折腾的时间越来越少，Agent真正干活的时间越来越多。
