OpenClaw命令行速查手册：从安装到排障的完整指南

前阵子把 OpenClaw 从本地 Windows 迁到 Linux 服务器时，我被一连串命令折腾得不轻。安装、初始化、模型配置、审批文件迁移、容器日志……每一个环节看起来都有现成的命令，可真到敲命令的时候才发现，资料东一块西一块，关键提示还经常藏在报错信息的最后一行。

所以我把这段时间高频使用的命令整理成了一份速查手册。OpenClaw 本质上是一个命令行优先的智能体运行时，装没装好、跑没跑起来、接了什么渠道、用的哪个模型，几乎都靠命令和配置文件控制。这份手册会从安装初始化讲到日常对话、模型切换、Skill 管理、Active Memory、容器部署和常用报错排查，既能当新手入门路线，也能放在手边当字典查。需要说明的是，OpenClaw 版本迭代很快，命令细节在不同小版本会有差异，遇到不确定的，优先跑 openclaw 子命令 --help，这是最权威的答案。

1. 读懂 OpenClaw 的命令地图，再开始背命令

1.1 为什么 OpenClaw 值得一份命令速查

很多人第一次接触 OpenClaw，是冲着“个人 AI 助理”来的。它和单纯在网页里聊天不一样，OpenClaw 会把对话、工具调用、文件操作、命令审批、渠道接入这些东西全部绑定到一个运行时里。说得直白一点，它更像一个能替你干活的终端管家，而你要做的，就是通过命令行告诉它“用什么模型、按什么策略、允许执行哪些操作”。

也正因为这样，OpenClaw 的命令体系不是一条两条，而是按生命周期铺开的：安装阶段有版本检查和环境自检命令，初始化阶段有 onboard 引导命令，日常使用阶段有交互对话和一次性任务命令，进阶阶段还有 skill 管理、记忆管理、审批迁移等命令。如果没建立一张“命令地图”，你很容易在配置文件、workspace、审批文件这些概念里绕晕。

我的建议是不要零散地记命令，而是把命令分成四层来理解：

• 第一层是安装与自检命令，解决“装没装上、能不能跑”的问题；
• 第二层是初始化与配置命令，解决“用哪个模型、接哪个渠道”的问题；
• 第三层是日常运行命令，解决“怎么和智能体对话、怎么让它干活”的问题；
• 第四层是运维和排障命令，解决“报错了、卡住了、升级之后不兼容”的问题。

这样分层以后，每条命令都有了自己的位置，背起来轻松，遇到问题也知道该往哪个命令去查。

1.2 ~/.openclaw 目录：配置文件、工作区和审批记录都在这

命令虽然很重要，但 OpenClaw 的很多状态并不存在命令参数里，而是落在用户目录下的 .openclaw 文件夹里。无论在 Windows 还是 Linux 上，你都会看到类似这样的结构：

• ~/.openclaw/openclaw.json 或 openclaw.yaml：主配置文件，大模型 provider、模型名、平台开关全在这里；
• ~/.openclaw/workspace：智能体工作区，很多文件读写、任务产出都发生在该目录下，热词里出现的 c:\users\administrator\.openclaw\workspace 就是 Windows 环境的默认路径；
• ~/.openclaw/exec-approvals.json：命令执行审批记录，旧版本升级后会提示迁移；
• ~/.openclaw/skills：skill 相关文件存放目录；
• ~/.openclaw/logs、runtime metadata 等状态文件：运行日志和运行时元数据。

为什么要先讲目录结构？因为很多报错根本不是命令敲错了，而是它读的文件不对。比如智能体“假装干活”但没有任何实际操作，八成是审批文件或 skill 目录出了问题；比如换模型后仍然报 unknown model，八成是配置文件的模型字段没有被正确修改。命令只是操作入口，真正决定行为的是命令和文件的配合。这一点在后文的排障部分会反复出现。

1.3 命令入口差异：Windows、Linux 与容器内不一样

OpenClaw 在 Windows 上的常见安装方式是 PowerShell 脚本或 npm 包，在 Linux 上则通过 shell 或容器方式部署。命令本身的动词基本一致，但“如何让命令在终端里可用”就有差异了。

Windows 下最常见的坑，就是开一个全新的 PowerShell 窗口后执行 openclaw，系统提示“无法将 openclaw 项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。这个我在后面第 2 节会专门给排查思路，这里只想点明一个原则：命令入口本质就是可执行文件在不在 PATH 里。npm 全局安装的包，bin 目录默认在 npm 的全局 prefix 下，如果这个目录没加进用户 PATH，就会“命令找不到”。

Linux 和容器内的情况稍微好一点，但也要注意当前用户身份。如果 OpenClaw 装在 root 用户下，切换到普通用户执行命令就找不到配置和命令；如果通过容器部署，则要 docker exec 或 crictl exec 进入容器再执行。遇到问题先花一分钟确认“命令是否在 PATH 中”“配置文件是否在正确用户目录下”，比反复重装高效得多。

2. 安装与初始化阶段的高频命令，照着敲就行

2.1 检查版本和运行状态

拿到一个新环境，或者升级完 OpenClaw，我建议先跑下面几条命令确认基础状态：

bash复制openclaw --version
openclaw --help
openclaw doctor

--version 会输出版本号，很多排查都要先看版本，因为不同版本的配置字段和命令结构差异很大。doctor 是环境自检命令，会检查配置文件、工作目录、网络连通性和模型配置是否正常。这个命令非常实用，它能把几百字的手动检查压缩成几条提示。

如果提示某个子命令需要单独看参数，我习惯用 openclaw <子命令> --help，比如 openclaw onboard --help。这个用法能帮你在不确定参数名时直接查到当前版本支持什么，不需要去翻网页。

还有一条容易忽略的命令是查看运行时元数据，也就是热词里多次出现的 runtime metadata。这条命令会输出当前运行实例的信息，比如配置文件路径、工作区路径、当前启用的模型等。当你怀疑“它到底读的是哪份配置”时，这条命令是最直接的答案。

2.2 首次初始化 onboard 与环境自检 doctor

新装完 OpenClaw 后，你首先会遇到的是一条交互式引导命令，通常是 openclaw onboard。它会带你走一遍模型接入、渠道选择、workspace 配置等流程，相当于把散落在配置文件里的关键项一次性设置好。

我实际体验下来，onboard 能不能顺利走完，最关键的还是网络和模型参数。它会要求你填 provider 和模型名，此时如果填错一个字符，后面的智能体可能直接失败。热词里有条典型报错叫做 agent failed before reply: unknown model: deepseek，说白了就是模型名和 provider 实际提供的模型列表对不上。这个坑我在第 4 节会展开讲，这里只提醒一句：onboard 时填写的模型名必须和你配置的 API endpoint 完全一致，不要凭印象写。

onboard 结束后，保险起见再执行一次 openclaw doctor。如果提示配置缺失或权限不对，它会给出具体的修复建议，比你自己猜要快得多。我见过很多人 onboard 之后直接开聊，结果 Workspace 目录权限不对、审批文件路径异常，折腾半天才发现，其实 doctor 在第一轮就能暴露这些问题。

2.3 平台接入：微信、飞书等渠道怎么开怎么验证

OpenClaw 能接入不少 IM 平台，微信、飞书、Slack、Telegram 这类都在常被提及的范围内。渠道接入的命令入口一般藏在一个统一的渠道管理子命令下，比如 openclaw channel list 查看已接入渠道，openclaw channel connect <platform> 发起接入流程。

实际接入时，流程通常是这样：

• 先进入 onboard 或 channel connect，选择目标平台；
• 根据提示完成账号授权，比如扫码、填 token、设置回调地址；
• 接入成功后，执行 openclaw channel list 确认状态；
• 在对应 IM 里给智能体发一条消息，验证能正常收到回复。

这里容易被忽略的是回调地址和网络端口。如果你把 OpenClaw 部署在云服务器上，平台要回调到你服务器的某个端口，就需要在防火墙里放行对应端口，否则会反复出现“连接失败”或“无响应”。相关检查命令我会在第 7 节专门写。

2.4 安装后命令找不到怎么办

热词里有这样一条：openclaw : 无法将“openclaw”项识别为 cmdlet、函数、脚本文件或可运行程序的名。这就是 Windows 下典型的 PATH 问题。

遇到这种提示，我不建议直接重装，先按顺序排查：

1. 重新打开一个终端窗口，再看能否执行。PowerShell 不会自动刷新 PATH，新装的工具经常要新开窗口才生效。
2. 执行 Get-Command openclaw 或 where.exe openclaw，看看系统到底能不能找到这个命令、找到的是哪个路径下的命令。
3. 如果是 npm 全局安装，检查 npm 的全局 bin 目录是否在 PATH 里。可以执行 npm prefix -g 查看全局目录，再把对应的 bin 目录加进用户 PATH。
4. 如果加了 PATH 仍不行，临时可以用 npx openclaw 绕过，但需要让 npm 先安装到本地。
5. 如果已经通过安装脚本安装，检查安装目录是否正确，有些安装器会要求你手动把安装路径加入 PATH。

提示：Windows 下还需要留意 PowerShell 执行策略。如果安装脚本或 start 脚本被系统拦截，执行 Set-ExecutionPolicy -Scope CurrentUser RemoteSigned 可以在当前用户范围内放开本地脚本权限，这是相对稳妥的配置方式，不要动系统级策略。

3. 日常使用时真正高频的命令，比想象中少

3.1 核心命令速查表

日常使用 OpenClaw，并不需要每天敲几十条不同命令。大多数情况下，你会集中在下面这些命令上。我整理成一张速查表，方便直接贴到笔记里：

真实体验是，交互式聊天只适合一边调一边看效果的场景。想让智能体稳定完成重复任务，最好写成非交互式命令，比如把任务描述放在 openclaw run 后面，这样可以直接被脚本调用、被定时任务触发，也能配合 git 做版本管理。

每次接新渠道、改模型配置或升完级，我的固定动作是先跑一遍 openclaw doctor，再看一眼 openclaw runtime metadata，确认“当前运行实例用的确实是我想改的那份配置”。这两条命令一前一后，能挡住大多数低级配置错乱。

3.2 给 OpenClaw 发任务的三种姿势

很多人刚接触时只会一个 openclaw chat，但其实发任务有三种常见姿势，适用场景完全不同。

第一种是交互式对话，终端或 IM 里一问一答。优点是灵活、方便即时调整，缺点是无法自动化，也不适合大批量任务。

第二种是命令行直接传一句任务描述，也就是单次执行模式。比如你写了个脚本，每天要生成一份项目进展摘要，就可以在脚本里调用 openclaw，把任务描述直接作为参数传入。这种方式的结果通常是一次性输出，不会进入“持续会话”状态，适合执行范围明确的请求。

第三种是把它嵌到自己的项目或 CI/CD 流程里。OpenClaw 本身提供 workspace 和 Active Memory 的概念，你可以把项目上下文放进工作区，让智能体读取指定文件后执行任务。比如让智能体根据 Git 提交记录自动整理 changelog、根据飞书文档内容生成周报。这种用法对命令的要求不高，但对你如何组织 workspace 文件、如何给智能体设定边界要求很高。

我自己最常用的组合是 openclaw run 加一条详细任务说明，再配合 git 保存输入和输出。这样每次任务跑完，我都能回溯它当时读了什么、写了什么、结果对不对。

3.3 Git 命令：先备份你辛辛苦苦调好的配置

OpenClaw 的配置、skill、Active Memory、审批文件都是文本文件，所以天然适合用 git 管理。我在调模型参数和 skill 时，最怕的就是改坏了没法回滚。后来养成一个习惯：初始化完成后先切到一个专门目录，把 .openclaw 里关键文件纳入 git 版本控制。

基础操作很简单：

bash复制git status
git add openclaw.json skills/
git commit -m "调整模型配置，新增项目跟踪 skill"

配置文件的任何改动都可能会影响智能体行为，所以提交信息要写清楚“改了什么、为什么改”。升级 OpenClaw 或跑审批迁移前，先 git commit 一次，之后如果新版本出了问题，能快速回退到可用版本。别小看这条习惯，很多看起来“玄学”的故障，用 git diff 一对比就水落石出了。

除了配置文件，workspace 下的任务输出也可以选择性纳入版本管理。比如 Obsidian 配合 OpenClaw 做项目管理时，智能体写的任务记录最好都放在一个带版本管理的文件夹里，这样即使它哪天“失忆”或者把内容写乱了，也能从 git 历史里找回。

4. 模型配置与多模型共存：把 “unknown model” 这类报错一次讲透

4.1 模型配置字段与 unknown model 报错

OpenClaw 的模型配置都写在主配置文件里，核心无非是三样：provider、model 名称、API endpoint。大部分模型接入问题，最终都能归到这个三元组上。

热词里那条安装后报 agent failed before reply: unknown model: deepseek 的案例，本质就是模型三元组配置不正确。它通常意味着：

• 模型名写错，或者写了一个 provider 没有提供的别名；
• provider 配置的 base URL 指向的服务里没有对应模型；
• 大小写不一致，有些平台模型名是大小写敏感的；
• 模型没有正确启用，比如账号权限或额度问题导致请求时找不到。

我处理这类报错的经验是，第一步不急着改代码，而是先打开主配置文件，确认 model 相关字段确实被正确修改。下面是一个配置片段示例，字段名以当前版本的帮助信息为准，但思路通用：

json复制{
  "model": {
    "provider": "openai-compatible",
    "name": "deepseek-chat",
    "baseUrl": "https://your-api-endpoint.example.com/v1",
    "apiKeyEnv": "OPENCLAW_API_KEY"
  }
}

很多安装教程会让你把 apiKey 直接写进配置，但我更推荐用环境变量引用。这样配置文件和密钥分离，既方便 git 管理，又不至于因为一次公开分享泄露密钥。

如果确认配置没问题，再执行 openclaw doctor 或发起一次最简对话测试，看报错信息是否有变化。报错信息会告诉你具体是连接不上、鉴权失败还是模型不存在，这三者的排查方向完全不同。

4.2 NVIDIA NIM 与本地模型服务接入

热词里提到过 openclaw 配置 nvidia nim。NVIDIA NIM 是 NVIDIA 推出的一套推理微服务，可以把它理解为“把本地或远端的大模型封装成一个标准 API 服务”。OpenClaw 要接入这样的服务，配置思路和接其他 OpenAI 兼容接口基本一致，只是 baseUrl 和模型名要改成 NIM 实际提供的服务地址与模型名。

我在配置这类自建模型服务时，会特别留意两个点。一是网络连通性，OpenClaw 所在机器必须能访问到 NIM 服务地址，如果 OpenClaw 部署在容器里，还要看容器网络能不能访问宿主机或局域网内其他机器的 NIM 端口。二是 endpoint 路径，有些网关的 API 路径不是 /v1，而是带一层服务前缀，少写一层就会 404 或 model not found。

对只想快速验证的用户来说，可以先在浏览器或 curl 里直接访问模型服务的接口，确认这个地址和模型名本身可用，再填到 OpenClaw 配置里。这能把“OpenClaw 的问题”和“模型服务的问题”彻底分开，排查效率会高一截。

4.3 多模型路由与成本控制

OpenClaw 支持多模型这个能力，实用性很强，但很多人没用起来。实际场景很明确：日常闲聊和头脑风暴用高性价比模型，处理复杂代码或长文档时切到能力更强的模型；有些模型擅长中文写作，有些模型工具调用更稳。如果你只有一个模型配置，所有场景都走同一个，成本和效果都没法调到最佳。

多模型切换有两种常见手段。一种是在配置文件里维护多个模型配置组，需要时直接修改当前启用的模型名；另一种是通过环境变量或启动参数指定，比如在启动命令前注入不同 API Key 和模型名。

我的建议是优先以配置文件为主，避免在命令行里写太多转义和临时变量。要切模型时，先确认新的模型名在对应 provider 下真实存在，再修改配置并重启会话。这里又回到 unknown model 那条经验：模型名不是“你觉得叫什么都行”，而必须和 API 服务提供的模型列表完全一致。多模型用得好不好，关键在于你愿不愿意多花几分钟把模型清单和成本差异做成一张简单的对照表。

4.4 C 盘清理命令：别让工作区和日志把磁盘占满

Windows 用户跑 OpenClaw 有一个隐蔽问题：workspace、日志和依赖缓存会逐渐占据 C 盘空间。它不像普通软件那样有明显的“缓存键”，但只要你长期让它跑任务，尤其是让智能体频繁访问网页、下载文件、处理媒体，磁盘占用就会快速上升。

我自己会定期执行下面几个操作：

• 清理系统临时文件：执行 cleanmgr，让系统盘清理工具把临时文件和旧更新缓存清掉；
• 检查 .openclaw 目录体积：在 PowerShell 里查看 C:\Users\<用户名>\.openclaw 的大小，找出是 logs 还是 workspace 占了大头；
• 手动清理日志目录，只保留最近几天的日志；
• 对不再需要的 workspace 项目文件夹，用 rmdir /s /q 删除整个目录，注意先确认里面没有需要保留的产出物。

在 Linux 上对应的删除文件夹命令是 rm -rf，但使用前一定要看清楚路径。我见过有人把 ~/.openclaw 误写成 ~ / .openclaw 之类带空格的整体路径，结果把用户目录清理掉了。删除型命令要反复检查路径，这是命令行时代最重要的安全习惯。

5. 权限审批、Skill 和 Active Memory：让智能体更懂你的进阶操作

5.1 exec-approvals.json 与旧审批迁移

很多升级后出现“智能体不执行命令”的情况，不是模型坏了，而是命令审批机制变了。旧版本 OpenClaw 会把允许执行的命令记录在 ~/.openclaw/exec-approvals.json 里。升级后，系统会提示类似于热词里的这条：

legacy exec approvals exist at /root/.openclaw/exec-approvals.json. run openclaw ... ``

意思很简单：旧版审批记录还在，但新版本不会自动使用它，需要你执行一次迁移或转换操作，把旧的审批条目带入新格式。

我第一次遇到时走了弯路，直接删除了旧文件，结果所有需要执行 shell 命令的 Skill 全部失效，因为没有任何审批记录了。正确做法是：

1. 先备份旧文件：cp ~/.openclaw/exec-approvals.json ~/.openclaw/exec-approvals.json.bak；
2. 按照提示信息查看迁移命令的帮助，一般可能是 openclaw approvals migrate 之类的子命令，具体以你当前版本的提示为准；
3. 执行迁移后再用 openclaw doctor 检查一遍，确认不再有 legacy approvals 的告警；
4. 如果迁移命令确实不存在，再手动对照新版本的审批文件格式，把旧配置整合进去。

注意：审批文件不是可以随便删除的“缓存文件”。OpenClaw 的智能体执行命令属于高风险动作，删除审批文件后，它会默认拒绝绝大多数未授权命令，导致很多 skill 看起来“没反应”。升级前先备份，看不懂的警告不要急着用删除解决。

5.2 skill 的查看、安装和自建

Skill 是 OpenClaw 里特别有价值的概念。你可以把它理解成“给智能体预装的一本操作手册或一套指令模板”。比如你想让 OpenClaw 帮你管理 Obsidian 项目，那就可以装一个项目管理相关的 skill，告诉它任务文件放在哪里、周报模板长什么样、更新时要注意什么。

常用命令层面，一般会有 openclaw skill list 查看已装 skill，openclaw skill create 创建自定义 skill，或者在 marketplace 里安装别人写好的 skill。具体子命令名称不同小版本可能有差异，遇到权限问题先执行 openclaw skill list --help 看清楚再操作。

自己写 skill 时，我的经验是不要贪多求全。一个 skill 只解决一类问题，描述写得越具体，智能体越不容易跑偏。比如与其写“项目管理”，不如拆成“从任务列表生成每日站会纪要”“按 Obsidian 模板记录会议结论”“每周末汇总本周项目进展”三个更聚焦的 skill。命令和配置只是骨架，skill 的内容质量才是智能体能不能贴合你工作流的关键。

5.3 Active Memory 与 Obsidian 项目管理

热词里有一句“OpenClaw Active Memory 高阶指南: 构建具备长期工作记忆的智能体”，这确实是进阶使用 OpenClaw 时最值得研究的方向。Active Memory 可以简单理解为“让智能体在多次会话之间记住你和它的项目信息”。它不等同于聊天记录，而是把重点事实、当前任务状态、关键文件位置等整理成可检索的记忆结构。

我做 Obsidian 项目管理时，会把智能体的 workspace 指向 Obsidian 对应的项目文件夹，并用 Active Memory 记录以下内容：

• 当前项目的目标和里程碑；
• 最近一次任务的进展和下一步计划；
• 哪些文件是重要输入、哪些文件是智能体自己的产出；
• 项目涉及的命名约定和注意规则。

这样每次对话都不用重新向智能体解释背景，它能在已有记忆基础上继续干活。需要刻意维护的是，不要让记忆无限膨胀。我一般会定期清理过期任务，只保留仍然有效的项目信息。Active Memory 强调的是“精炼可检索”，不是把所有历史都堆进去。判断标准很简单：如果一段信息对新会话的任务执行没有帮助，就没必要占用记忆空间。

6. 高频报错与排查命令速查表

6.1 安装与启停阶段问题

我把实际使用中遇到频率较高的报错整理成了一张速查表，每个问题都给出根因和排查顺序。命令无法识别的问题，前文已经展开过，这里归纳一下其余几个高频项。

安装和启动坑大多是环境问题，不是 OpenClaw 本身的问题。这类问题最好的排查顺序是“看错误 → 确认执行身份 → 确认 PATH → 确认配置文件路径”，不要一上来就重装。

6.2 模型调用阶段问题

模型层面的报错是最让人头疼的，因为它经常长得像网络问题，但实际是配置问题。

模型问题排查时，我强烈建议在把 OpenClaw 扯进来之前，先用最朴素的工具测一遍模型 API 本身。用 curl 请求一次接口，看能不能拿到正常回复。如果能，说明问题出在 OpenClaw 的配置或调用方式；如果不能，问题就在模型服务端，调整 OpenClaw 配置没有任何意义。

6.3 运行阶段与智能体行为问题

模型通了之后，还会遇到一类“智能体行为不符合预期”的问题。这种问题最难查，因为它不会崩溃，只是结果不对。常见的情况包括：

遇到这类行为偏差，我会先检查“它实际能看到的文件路径是什么”“它被允许执行什么命令”，再调整配置，而不是盲目加提示词。智能体没有魔法，它的一切行为都受配置文件、skill 内容和命令权限共同约束。搞清楚这三样，大部分“不听话”的问题都能被解释清楚。

7. 容器、服务器与云端部署中的周边命令

7.1 拿 Docker/containerd 部署时要用到的排查命令

云端部署 OpenClaw 是很多人的目标，因为服务器能 7x24 小时运行，不会像笔记本一样关机就断开。部署形态最常用的就是 Docker，或是它底层的 containerd。容器化部署后，你日常操作的就不是直接执行 openclaw，而是先进入容器或查看容器日志。

常用命令如下：

bash复制# 查看容器列表和状态
docker ps -a

# 查看 OpenClaw 容器日志
docker logs <容器名或ID>

# 进入正在运行的容器
docker exec -it <容器名或ID> bash

# 在容器内执行 openclaw 命令
docker exec -it <容器名或ID> openclaw doctor

如果你所在的服务器只暴露了 containerd 接口，没有 docker 命令，也可以用 crictl 排查：

bash复制crictl ps -a
crictl logs <容器ID>
crictl exec -it <容器ID> bash

容器部署最容易踩的坑是“重启后配置丢失”。如果你把 OpenClaw 的 .openclaw 目录放在容器内部，容器删掉后所有模型配置、审批记录、记忆文件全部消失。正确做法是把配置目录持久化到宿主机，以命名卷或 bind mount 方式挂载进容器。这样无论容器怎么重建，配置和记忆都在。

7.2 云服务器端口与连通性检查

接入微信、飞书这类平台时，平台服务器通常需要主动回调你部署的 OpenClaw 服务，因此必须确保相应端口能从公网访问。很多部署失败并不是 OpenClaw 没有启动，而是端口被防火墙或云安全组挡在了外面。

我排查端口连通性的基本套路：

• 先在服务器本地确认服务监听正常；
• 再从另外一台机器测试端口是否能通；
• 不通时逐一检查云安全组和本地防火墙。

测试命令可以用 telnet 或系统自带网络工具，比如 telnet <服务器IP> <端口>。如果报错提示无法连接，优先看安全组规则有没有放行对应协议的源地址范围。云服务器上如果启用了本地防火墙，也需要先把端口或服务加入放行名单。

提示：只监听 127.0.0.1 的服务默认不接受外部访问。如果 OpenClaw 需要被平台上回调，必须监听适当的网络接口。安全起见，不要直接监听 0.0.0.0 就完事，建议加上认证或 Token，避免未授权请求直接打到你的智能体上。

7.3 进入容器后的日常操作命令

容器内 OpenClaw 已经跑起来后，我们还是要经常进去做配置修改。进入容器并切到相应用户后，最常用的几条命令包括：

bash复制# 切到存放配置的用户目录
cd ~/.openclaw

# 用编辑器修改配置
vim openclaw.json

# 查看当前目录占用
du -sh ~/.openclaw

# 查看运行日志
tail -f ~/.openclaw/logs/runtime.log

用 vim 改配置时，建议先备份一份再改。改完配置文件后，不要指望立即生效，大多数配置需要重启 OpenClaw 进程或重新发起会话才会被重新读取。重启动作在不同部署方式里差别很大，Docker 部署通常会重建容器，systemd 部署则用 systemctl restart <服务名>。一定要先搞清楚当前部署方式，再决定用什么命令重启。

容器内还有一个常见需求是删除不再使用的临时文件。Linux 下清掉目录里所有内容用的是 rm -rf <目录>/*，这个命令威力很大，使用前务必先 ls 确认路径正确。我吃过一次亏，把容器里的工作区目录变量当成普通路径直接删，结果把刚生成的任务产出全弄没了。谨慎删除，是运维 OpenClaw 过程中最值得记住的一条教训。

最后再唠叨一句执行审批的事。我自己的习惯是每次升级后先把 exec-approvals.json 备份到 git 仓库，再执行提示中的迁移命令。很多人觉得“速查手册”就是背命令，但真正的差距往往来自对警告消息的态度。遇到不认识的提示，先备份，再查帮助，最后动手，能少花好几个小时的返工时间。