1. 日常维护之前先搞清楚你的OpenClaw部署形态先说个容易被忽略的点OpenClaw 的“日常维护命令”不是一套命令打天下。你装在 Windows 上用 Companion 跑和塞进 Termux 里跑安卓版或者挂在 ROS2 Humble 环境里配合 Gazebo 仿真用初始化方式、进程管理方式、日志路径都不一样。如果上来就照着 Docker 那套 systemctl 命令去折腾很可能连服务都找不到。我接触 OpenClaw 的时间不算短从最早的裸机脚本部署到后来用 Ollama 做本地推理、再到帮朋友配安卓手机上的 Termux 版本前前后后踩了不少坑。今天这篇文章我就把日常维护里最高频、最实用的命令整理成一套“速查手册”顺便把每个命令背后的原因也讲清楚。不是简单罗列而是让你知道为什么用这个命令、什么时候该用、踩坑了怎么救。需要提前说明的是OpenClaw 本身没有锁死某一种部署方式。官方支持“原生进程”和“容器化”两种主要运行形态而社区里常见的安卓部署Termux其实也是原生进程的一种特例。所以下面的命令我会按“原生进程为主、容器为辅”的方式展开再单独给 Termux 和 Windows Companion 场景做标注。你自己对照当前环境选着用就行。1.1 三种典型部署形态原生进程、容器化、Termux 安卓端原生进程部署是最直观的形态。你把 OpenClaw 的源码或者编译好的二进制放在某个目录然后用命令行直接启动。这种形态下维护命令的核心就是“找到进程、控制进程、看日志”。优点是简单直接缺点是进程一旦崩溃没有任何守护机制需要借助 systemd 或者 supervisor 这类工具来保活。容器化部署Docker / Docker Compose则把 OpenClaw 和它的依赖封装成镜像。日常维护主要围绕 docker 命令展开比如docker ps、docker logs、docker compose restart。这种形态的好处是环境隔离、迁移方便坏处是排查问题的时候多了一层“容器内 vs 容器外”的复杂度。你如果用的是 Docker 部署下面的原生进程命令可能要对应改成docker exec才能生效。Termux 安卓端是另一个热闹的方向。很多人在手机上装 Termux跑 OpenClaw 的 Android 版。这种形态本质上还是原生进程但是 Termux 对后台进程的管理比较特殊系统在内存不足时有可能会把 Termux 整个杀掉。所以安卓端的维护命令除了常规的进程操作还涉及到 Termux 的termux-wake-lock、termux-battery-status这类辅助命令。1.2 维护命令的“入口”在哪里CLI 工具与配置文件OpenClaw 正常安装完成后会提供一个主命令openclaw后面可以跟各种子命令。比如openclaw status、openclaw logs、openclaw update等等。这个 CLI 工具实际上是维护操作的总入口所有常规的启停、更新、状态查看都可以通过它完成不需要你手动去 kill 进程或者找日志文件。不过 CLI 命令能够做到的事情终究有限更深层的维护仍然绕不开配置文件。OpenClaw 的核心配置默认放在用户主目录下的.openclaw/目录中里面会有类似config.yaml或config.json的文件用来管理模型接入比如 Ollama 的地址、API Key、技能skills目录、对话历史存储路径、日志级别等。我个人的习惯是每次维护之前先用openclaw config --show看一眼当前生效的配置确认没有被人改过或者出现奇怪的字段。配置文件是维护工作的地图地图错了后面的命令全部白搭。1.3 环境变量与配置管理的基础在 OpenClaw 里不少运行参数可以通过环境变量覆盖配置文件中的默认值。比如OPENCLAW_LOG_LEVEL控制日志详细程度OPENCLAW_MODEL指定默认模型OPENCLAW_OLLAMA_HOST指定 Ollama 服务地址。为什么需要了解这些因为日常维护中有一类高频操作就是“临时调日志级别看问题”如果你不知道环境变量覆盖规则就只能手改配置文件再重启费时费力。我用一个生活中的类比来解释配置文件像是你手机里的“设置”菜单环境变量则是你在特定场景下临时拉起的“快捷开关”。快捷开关只在本次运行时生效重启后回到设置菜单的状态。也就是说OPENCLAW_LOG_LEVELdebug openclaw start这种命令只会在启动的这一次进程里输出详细日志不会把配置文件永久改成 debug 级别。2. 高频日常维护命令状态查看、启停与更新日常维护里用得最多的就是状态查看和启停操作。很多时候你收到告警说 OpenClaw 不回复了第一反应不是去改代码而是先看它到底还活着没有。这一节我把状态查看、启动停止、版本更新这三类高频操作拆开讲每个都给出实际命令和排障思路。2.1 查看运行状态与健康检查最简单直接的命令是openclaw status这个命令会输出进程是否运行、PID、运行时长、当前内存占用、监听的端口、当前加载的模型等信息。如果输出中能看到running字样说明主进程是正常的。但“进程活着”不等于“服务健康”你还需要进一步确认内部任务调度是否正常。我建议配合下面这个健康检查接口一起看curl http://127.0.0.1:8080/healthOpenClaw 默认会起一个本地 HTTP 服务/health端点会返回 JSON比如{status:ok,model:qwen2.5:7b,uptime_seconds:12345}。如果这个接口能通基本可以说明主服务和模型连接都没问题。如果status显示 running但/health超时那大概率是模型推理线程卡死了属于“假活”状态。在 Docker 部署形态下命令要换成docker ps --filter nameopenclaw docker logs --tail 50 openclaw2.2 启动、停止与重启的正确姿势停止 OpenClaw 有一个比较重要的讲究尽量不要直接kill -9进程。因为 OpenClaw 在处理对话任务时会产生临时状态强制杀进程可能导致对话记录没有落盘甚至让 SQLite 数据库出现损坏。正确做法是openclaw stop这个命令会先向主进程发送 SIGTERM 信号让它有机会完成当前任务的保存收尾再退出。如果stop之后进程仍然没有退出偶尔会发生再用openclaw stop --force兜底。启动则很简单openclaw start如果你用 systemd 托管那么对应的命令就是systemctl --user start openclaw、systemctl --user stop openclaw、systemctl --user restart openclaw。注意 OpenClaw 官方推荐以用户态 systemd 服务方式运行因为这样就可以开机自启且崩溃自动重启。重启命令我单独说一下openclaw restart实际上等价于stop加start但它会额外检查配置文件语法如果配置文件有错会拒绝启动并且回滚到停止前状态避免“停了起不来”的尴尬。所以日常版本更新后、配置调整后我都建议用openclaw restart而不是手动stop start。2.3 版本升级与回滚操作OpenClaw 的迭代速度比较快社区热词里也经常出现“OpenClaw部署”、“OpenClaw安装配置”这类话题。升级操作本身并不复杂openclaw update这个命令会从官方源拉取最新版本然后执行迁移脚本。迁移脚本主要用来升级配置文件格式和数据库结构。所以我特别提醒升级之前务必先做备份备份命令在下一节详细讲。升级过程中如果报错最常见的原因是旧配置里的某个字段在新版本中已经被废弃。这时候 OpenClaw 会给出类似Deprecated key: model.temperature的警告但不会中断升级。你可以升级后再用openclaw config migrate --dry-run检查配置兼容性。如果需要回滚版本OpenClaw 提供了版本快照能力openclaw update --rollback这个命令会回退到上一个稳定版本并且自动恢复升级前的配置备份。不过回滚不是万能的如果数据库已经因为升级产生了不可逆的结构变化那么回滚之后可能面临数据读不出来的情况。所以版本升级真的是“备份先行”别偷懒。3. 日志、备份与数据维护日志是排查问题的第一手资料备份是灾难恢复的救命稻草。这一节我会讲清楚 OpenClaw 日志怎么看、如何备份对话历史与模型配置、SQLite 数据库怎么维护。这些命令不像启停那么高频但每次用上的时候基本都是在救火。3.1 日志查看与轮转策略OpenClaw 的日志默认保存在~/.openclaw/logs/目录下按天切分文件名为openclaw-YYYY-MM-DD.log。查看当前日志可以直接用openclaw logs --tail 50这等价于tail -n 50 ~/.openclaw/logs/openclaw-$(date %F).log。如果你在调试某个特定技能skill或某个 API 接入问题建议带上时间过滤openclaw logs --since 10 minutes ago日志级别默认是INFO排查问题时可以先临时调到DEBUGOPENCLAW_LOG_LEVELdebug openclaw start这样不会永久修改配置。确认问题之后重启正常服务即可。还有一个容易被忽略的点日志轮转。OpenClaw 默认只保留最近 7 天的日志文件但如果你处理的任务量很大一天的日志可能就有几百 MB。我建议自行配置 logrotate 或者定期清理openclaw logs --clean --keep 3这条命令会删除 3 天前的日志释放磁盘空间。在容器部署下对应的操作是docker logs --tail结合外部 logrotate不过一般 Docker 部署建议直接让 OpenClaw 的日志写到挂载卷里再对挂载卷做轮转。3.2 对话历史与模型配置备份OpenClaw 的对话历史、技能配置、用户偏好都存储在~/.openclaw/目录下其中最关键的是history.dbSQLite 数据库和config.yaml。备份这两个文件就等于备份了整个 OpenClaw 的“记忆”。我常用的备份命令是# 创建备份目录 mkdir -p ~/openclaw-backups # 带时间戳备份整个配置目录 tar -czf ~/openclaw-backups/openclaw-$(date %Y%m%d-%H%M%S).tar.gz -C ~ .openclaw注意tar命令里的-C ~是为了把备份路径里的前缀去掉这样还原的时候直接解压到~目录即可。如果你只关心对话数据可以只备份history.dbcp ~/.openclaw/history.db ~/openclaw-backups/history-$(date %Y%m%d).db但这里有一个重要的坑SQLite 在运行状态下直接cp可能会得到一个不一致的快照尤其是当写入任务正在执行时。稳妥做法是先用openclaw stop停服务再备份或者使用 SQLite 的在线备份命令sqlite3 ~/.openclaw/history.db .backup ~/openclaw-backups/history-online.db这条命令是 SQLite 官方支持的在线热备方式即使服务正在运行也能保证一致性。3.3 数据库SQLite维护命令OpenClaw 的元数据存储默认使用 SQLite日常维护中偶尔需要手动检查数据库完整性。最常用的维护命令是# 检查数据库完整性 sqlite3 ~/.openclaw/history.db PRAGMA integrity_check;返回ok就说明数据库没问题如果返回database disk image is malformed那就得用备份恢复了。另外随着对话记录增多SQLite 可能会出现膨胀建议定期执行 VACUUM 来回收空闲空间sqlite3 ~/.openclaw/history.db VACUUM;VACUUM会重建数据库文件期间不能有写入操作所以最好在openclaw stop之后进行。执行完成后你会发现history.db文件明显变小。这个操作属于“优化型维护”频率不用太高每周或者每月一次就行。4. 资源监控与性能调优很多 OpenClaw 的日常故障并不是代码 bug而是资源不够用。尤其是你在安卓 Termux 上部署或者同时跑多个技能的时候内存和 CPU 很容易被吃满。这一节我讲讲怎么监控资源占用以及几个有效的性能调优思路。4.1 CPU、内存、GPU 占用排查当你觉得 OpenClaw 响应变慢时第一步是看资源占用而不是重装。原生进程部署下最直接的命令是ps aux | grep openclaw关注%CPU和%MEM两列。如果 OpenClaw 进程的 CPU 占用长期超过 100%说明推理任务可能陷入了死循环如果内存占用持续上涨却不回落大概率存在内存泄漏这通常需要升级版本或者重启进程来释放。如果你配置了 Ollama 作为本地推理引擎还要额外检查 Ollama 的资源占用。因为 OpenClaw 本身不承载推理它只是把任务发给 Ollama。很多情况下模型加载在 Ollama 侧GPU 显存被模型占满之后新的推理请求就会排队表现出来就是 OpenClaw 回复很慢。GPU 占用排查命令以 NVIDIA 为例nvidia-smi重点关注MiB显存占用和%GPU利用率。如果你看到显存被占满但利用率很低说明模型已经加载但没有处理请求此时可以考虑让 Ollama 闲置时自动卸载模型OLLAMA_KEEP_ALIVE0。4.2 模型缓存与 Ollama 配置调优Ollama 的模型文件默认保存在~/.ollama/models目录下占用空间相当可观。一个 7B 参数的模型通常需要 4~6GB 空间如果你同时加载多个模型磁盘瞬间就爆了。常用的维护命令# 查看已下载的模型列表 ollama list # 删除不用的模型 ollama rm qwen2.5:7b # 修改默认并发数 export OLLAMA_NUM_PARALLEL2OLLAMA_NUM_PARALLEL是 Ollama 的一个重要参数默认值是 1也就是同时只能处理一个请求。如果你有多用户使用 OpenClaw可以调大这个值但要注意显存或者内存的承受能力。我有一次把并发数调到 4结果 8GB 显存的卡直接被 OOM进程被系统杀掉日志里报的是CUDA out of memory排查了很久才发现是并发数的问题。对于“OpenClaw 只能用接入 API 的方式使用算力吗”这个热词我想专门说明一下不是的。OpenClaw 支持通过 Ollama 接入本地推理模型算力完全由你自己的机器提供不需要任何外部 API。日常维护中把 Ollama 当成一个独立服务来管理即可OpenClaw 和 Ollama 之间的关系就是客户端和服务端。4.3 安卓端Termux资源限制与保活在 Termux 上跑 OpenClaw 是社区里比较热门的玩法但手机的资源远不如桌面机器系统经常会在内存紧张时清理掉后台进程。Termux 上维护 OpenClaw除了常规的openclaw status/openclaw logs之外还要加上两个 Termux 特有的命令# 阻止 CPU 休眠 termux-wake-lock # 查看电池状态确认是否在充电 termux-battery-statustermux-wake-lock是保活的关键。如果不执行这个命令手机一锁屏系统很快就会把 OpenClaw 进程挂起或者杀掉。另外建议在 Termux 里使用tmux或screen来运行 OpenClaw这样即使 Termux 界面被关闭进程也能在后台继续跑。内存方面不要在安卓机上加载超过手机内存一半的模型。比如一台 8GB 内存的手机选择 4GB 左右的量化模型可能刚好加载 7B 模型就会非常吃力。你可以通过free -h查看内存剩余如果发现 Swap 占用过高说明内存已经完全不够用了这时要考虑换更小的模型而不是继续调优。5. 常见问题排查与恢复技巧这一节是实战经验最集中的部分。我把日常维护中遇到的高频问题整理成一个速查表每个问题都给出排查命令和解决路径。你会发现排查过程其实就是“看日志 - 确认状态 - 针对性处理”三步走。5.1 服务无法启动的排查思路症状执行openclaw start后进程立即退出status显示failed或exited。第一步看启动日志openclaw logs --since 5 minutes ago --level debug这里我会直接加--level debug参数因为很多启动错误在 INFO 级别不会完整展示。常见的错误有以下几类端口被占用日志中会出现address already in use。排查命令是ss -tlnp | grep 8080找到占用端口的进程改 OpenClaw 端口配置或停掉那个进程。配置文件解析失败日志中会指出具体的 YAML 行号。这时候用openclaw config validate检查配置格式会得到一个比较明确的错误提示。数据目录权限不足日志中可能出现Permission denied。检查~/.openclaw/目录的所有者和当前用户是否一致使用chown -R $USER ~/.openclaw修复。5.2 模型加载失败的常见原因如果你启动 OpenClaw 成功但一问话就报模型错误大概率是 Ollama 侧的模型命名或者服务地址有问题。排查第一步确认 Ollama 是否在线ollama list curl http://localhost:11434/api/tags如果ollama list能显示模型但 OpenClaw 仍然报model not found那就要检查 OpenClaw 配置里写的模型名称是否和ollama list输出的完全一致。这里有一个容易踩的坑Ollama 拉取模型时可能用了带标签的完整名称比如llama3:8b而配置里只写了llama3虽然很多时候 Ollama 会自动补全但遇到自定义标签时就会报错。如果ollama list本身不可用则要看 Ollama 服务有没有被系统杀掉。处理方式systemctl restart ollama # 或者手动启动 ollama serve5.3 网络异常与 API 连接问题OpenClaw 的部分技能需要访问外部服务比如更新技能信息或者调用某些在线服务。出现网络异常时日志里会显示Connection timeout或TLS handshake failed。排查步骤先用curl -I检查外部服务是否可达确定是不是 OpenClaw 的问题。查看代理环境变量是否影响了服务。OpenClaw 默认会读取HTTP_PROXY/HTTPS_PROXY如果你配置了代理但代理挂了就会造成所有对外请求失败。可以用unset HTTP_PROXY HTTPS_PROXY后重启 OpenClaw 验证。检查 DNS 解析是否正常nslookup或dig都可以。有一点要特别提醒很多技能在设计时会定期访问 GitHub 或其他代码托管平台拉取更新。如果间歇性出现超时不一定是 OpenClaw 的问题也可能是对方服务被限流。一般过几分钟重试就能恢复。6. 自动化维护脚本与进阶技巧当我发现自己每隔几天就要重复执行同一批维护命令时就觉得应该写个脚本把它们串联起来。OpenClaw 的维护场景非常适合自动化因为命令本身比较固定而且没有复杂的交互逻辑。6.1 一个实用的每日维护脚本下面这段脚本是我在自己机器上跑的“日常体检”脚本逻辑很简单查状态、看关键日志、备份、清理过期日志。每个步骤都有输出方便人工复核。#!/usr/bin/env bash set -e BACKUP_DIR~/openclaw-backups DAY$(date %F) # 检查服务状态 echo Checking OpenClaw status openclaw status /tmp/openclaw-status.txt || echo OpenClaw not running! cat /tmp/openclaw-status.txt # 查看过去10分钟的ERROR日志 echo Recent errors grep -i error\|panic ~/.openclaw/logs/openclaw-$(date %F).log | tail -20 || true # 备份 echo Backing up mkdir -p $BACKUP_DIR sqlite3 ~/.openclaw/history.db .backup $BACKUP_DIR/history-$DAY.db tar -czf $BACKUP_DIR/config-$DAY.tar.gz -C ~ .openclaw/config.yaml # 清理3天前的日志 echo Cleaning logs openclaw logs --clean --keep 3 echo Done把这段脚本保存为openclaw-daily-maintenance.sh然后给它执行权限chmod x openclaw-daily-maintenance.sh脚本里我特意用了|| true来包住 grep 命令避免日志里没有错误时脚本因 grep 返回非零码而中断。日常维护脚本的第一原则是“宁可跳过某个步骤也不要让脚本死在半路上”。6.2 用 cron 实现定时维护如果你想把上面的脚本跑起来最简单的方式是用 cron。在终端输入crontab -e然后添加一行0 6 * * * /home/yourname/openclaw-daily-maintenance.sh /home/yourname/openclaw-daily.log 21这里0 6 * * *表示每天早上 6 点执行。注意脚本里使用了绝对路径引用了备份目录这是因为 cron 环境变量比交互 shell 少容易找不到 PATH。保险做法是在脚本开头加上export PATH/usr/local/bin:/usr/bin:/bin。如果你用 systemd 而不是 cron也可以写一个.timer单元思路类似但 cron 更简单适合个人场景。6.3 维护命令速查表最后把这一节内容浓缩成一张速查表方便贴在你自己的笔记里操作原生进程/通用命令Docker 部署命令查看状态openclaw statusdocker ps --filter nameopenclaw查看日志openclaw logs --tail 50docker logs --tail 50 openclaw停止服务openclaw stopdocker compose stop openclaw启动服务openclaw startdocker compose start openclaw重启服务openclaw restartdocker compose restart openclaw更新版本openclaw updatedocker compose pull docker compose up -d回滚版本openclaw update --rollback重新 pull 上一个镜像版本配置备份tar -czf backup.tar.gz -C ~ .openclaw备份挂载卷目录数据库校验sqlite3 history.db PRAGMA integrity_check;docker exec openclaw sqlite3 ...清理日志openclaw logs --clean --keep 3挂载卷外使用 logrotate这张表不能覆盖所有场景但能覆盖 80% 以上的日常操作。真遇到命令对不上的情况先回到openclaw --help看看实际版本支持什么子命令。我个人在实际使用中的一个体会是维护 OpenClaw 最忌讳的是频繁重装。很多问题看起来像坏了其实就是日志文件太大、端口冲突、模型名称写错、或者进程卡死。按照这篇文章里的排查顺序走一遍大部分问题都能在 5 分钟内定位。把这些命令沉淀成自己的维护习惯之后OpenClaw 完全可以做到“部署一次长期稳定跑”。如果你是在 ROS2 Humble 环境里配合 Gazebo 仿真使用 OpenClaw维护重点会稍微偏一点——除了要关注 OpenClaw 本身还要注意 ROS2 节点是否正常、ros2 node list里能否看到对应的话题节点。但底层维护命令的思路是完全一致的先看进程再看日志最后动配置。把这一套命令玩熟练了不管部署在什么环境里你都不会慌。