花了将近两周时间把 OpenClaw 的命令行基础过了一遍我最大的感受是图形界面只是它的脸命令行才是它真正的手脚。很多同学装上 OpenClaw 之后第一反应是找可视化面板点按钮、看聊天窗觉得这样就叫会用了。但等你真正要批量处理文档、定时跑任务、把 AI 接进自己的脚本工作流时图形界面就会变得非常碍事——这时候命令行就是你绕不开的入口。这篇是这个系列的第三篇专门讲 OpenClaw 命令行里最常用的指令和参数。我会把我自己在实际项目里用到的命令原样列出来每条都解释为什么这么用、参数背后的逻辑是什么以及哪些地方容易踩坑。如果你是刚接触命令行的小白看完这篇至少能独立完成启动会话、跑一个任务、查看结果、续接上下文的完整闭环如果你已经有一定基础可以直接跳到后面的参数优先级和踩坑记录那几段写的是常规文档里不会说的东西。1. OpenClaw 命令行到底解决了什么问题1.1 图形界面够用但一定不够深先说清楚一件事OpenClaw 的图形界面做得并不差会话、记忆、技能管理都有可视化入口。但我用了一段时间后发现凡是重复性高、需要批量处理的操作图形界面几乎都要点好几下鼠标才能完成。比如我想把某文件夹里的 20 个 Markdown 文件逐一出给模型做摘要图形界面的操作路径是打开面板 → 新建会话 → 上传文件 → 等结果 → 复制保存 → 再新建会话……循环 20 次。而命令行只需要一条for循环命令加上管道几分钟全部搞定。这不是 OpenClaw 特有的问题而是所有 AI 工具共性的选择图形界面优化的是单次体验命令行优化的是批量效率。你在学习阶段当然可以只用面板但只要你想把 OpenClaw 嵌入到自己的脚本、定时任务、甚至是 CI 流程里命令行就是唯一的选择。1.2 命令行的真正优势可写、可重复、可交接命令行的优势总结下来有三点这三点是图形界面永远做不到的可写操作记录天然就是文本今天跑了什么、用了哪些参数、出了什么结果全部可以留存在 shell 历史或脚本文件里。可重复一条命令跑通了下次原样执行即可不需要回忆上次到底点了哪个按钮、选了哪个模型。可交接把脚本交给你同事对方不需要学习你的点击路径只要环境一样结果就能复现。我在某次给一个小团队搭共享 AI 工作流时就是靠一堆 OpenClaw 命令行脚本完成任务的。当时团队里有人习惯用面板有人只会跟着文档点我把整套流程封装成run_summary.sh、batch_process.py之后沟通成本直接降了一个量级——不再有人问这一步在哪个菜单里。1.3 本专栏采用的环境约定后面所有命令都默认你已经在命令行里装好 OpenClaw 并初始化完成终端前缀会显示当前会话状态。如果还没装先跑一遍官方的一键安装脚本再把可执行文件路径加进 PATH 环境变量。我这里用 Linux 或 macOS 的 bash 演示Windows PowerShell 使用者把单引号、双引号的习惯反过来基本就能对上。$ openclaw --version OpenClaw CLI version 0.9.32. 最常用指令的实战解读session、run、status、logs2.1 第一条命令openclaw status先看环境再看世界很多人上手第一件事就是跑openclaw run 你好觉得能回复就算通了。我的建议相反先记住openclaw status这条命令任何时候觉得莫名其妙了先看一眼状态再下结论。openclaw status的输出通常包含四类信息当前使用的配置文件路径、模型服务连接状态、当前活跃会话 ID、最近一次任务的状态码。它相当于给你提供了一面仪表盘让你在跑正式任务之前先确认引擎是热着的。$ openclaw status Config : /home/me/.openclaw/config.toml Model endpoint : connected (latency 238ms) Active session : s_abc123 Last exit code : 0你可能会问为什么status不只是一个简单的 OK / Not OK因为在真实使用中能连上和能干活是两码事。有一次我连续跑任务总是超时看日志没有任何报错最后就是靠status发现模型端点的延迟已经涨到 4000ms 以上网络链路出了问题。如果只看连接成功这个结果问题会很难定位。2.2 核心指令openclaw run一次任务一个世界openclaw run是平时最常用的执行指令用法很直观openclaw run 你的指令内容。它会把指令发给当前配置的模型等结果返回后直接打印到终端。我用一个实际例子说明$ openclaw run 请用三句话概括什么是事务性数据库要求通俗易懂 事务性数据库是一种强调要么全部成功、要么全部失败的数据库设计思路。 它通过 ACID 特性保证多个操作不会被拆成半成品避免数据出现中间状态。 通俗理解就是一笔钱转账要么扣款和入账都完成要么什么都不发生。这段回复本身没什么特别但我想让你注意两点。第一命令行模式下没有流式打字效果结果是整块返回的所以大任务会有等待时间别以为卡住了第二指令里的引号是有讲究的——bash 里双引号允许变量替换单引号才是字面字符串如果你的指令里含有$、这类特殊字符建议用单引号包住整个指令。run也是你调试技能、模型效果的最短路径。我通常会在写一个复杂提示词前先跑上十几条run每条只改动一个变量对比不同措辞、不同参数下的输出差异。这种高频试错的工作模式只有在命令行下才做得到。2.3 会话管理session子命令让你的对话有记忆run命令默认每次都是无状态的它在执行完任务后就把历史上下文丢掉了。如果你想让模型记住前文就要用到session子命令。简单说session是一个命名的上下文容器。你把一些指令放在同一个 session 里执行模型就能引用这些历史的对话内容。常用操作有三条# 新建会话并立即执行一条指令 $ openclaw session create --name 项目分析 --run 记住我们讨论的是用户增长项目 # 在指定会话中继续追问 $ openclaw run 刚才说的三个指标你觉得哪个最关键 --session 项目分析 # 查看当前所有活跃会话 $ openclaw session list这里最核心的概念是session 既不是聊天记录文件也不是模型上下文窗口的简单映射而是一个你主动控制的上下文容器。默认情况下OpenClaw 会在上下文接近模型上限时自动丢弃最早的对话内容但你也可以通过参数控制保留策略。后面第五章我会专门讲 session 丢失的问题那是初期最容易踩的坑。2.4 日志查看logs是排错的显微镜一旦任务报错或者结果莫名其妙就得看日志。logs子命令的常用形态有这三种# 查看最近 50 条日志 $ openclaw logs --tail 50 # 按关键字过滤日志 $ openclaw logs --grep timeout # 持续跟踪日志类似 tail -f $ openclaw logs --follow日志记录的信息颗粒度比终端输出细得多。终端上你只看到任务失败日志里会有具体的重试次数、网络响应码、上下文 token 用量。配合--verbose参数打开调试输出后能看到每次请求的具体请求头、耗时分布等更底层的数据。我的习惯是普通使用开默认日志级别定位问题时先看一眼日志再下结论这比反复重跑命令高效得多。3. 全局参数详解每个参数背后都有一段真实需求3.1 参数优先级命令行 环境变量 配置文件 默认值OpenClaw 参数体系里最重要的不是你背下了多少个参数名而是你理解它们如何被读取。任何配置项都可以通过四个层级来设定命令行参数、环境变量、配置文件、内置默认值。优先级从高到低如上。换句话说你在命令行写了--model fast那么它一定覆盖配置文件里的model standard。这个设计我一开始觉得啰嗦后来才发现它是干活的保障。比如同一台机器上你可能同时维护个人项目和客户项目两者模型偏好不同。如果你每次都手动改配置文件很容易忘记改回来然后拿错配置跑了一晚上。使用环境变量或者命令行参数覆盖就不会污染全局配置。3.2 必懂参数--model、--config、--verbose、--output下面这几个参数是我认为短期内必懂的每个我都给了一句为什么需要它的说明。参数作用实际使用场景一句话心得--model指定本次任务使用的模型跑摘要用便宜快的模型跑深度分析换强模型它让任务难度和模型成本可以动态匹配--config指定本次使用的配置文件一套终端环境对接多个项目的不同配置比频繁修改默认配置文件安全得多--verbose或-v输出详细调试信息任务异常时想看清请求流程排错时必开平时别开否则输出太吵--output指定输出形式把结果保存成文件供后续程序读取和--format json搭配可以实现程序对接举例来说想把某次任务结果保存成 JSON 文件供后续脚本使用命令是$ openclaw run 提取这段文字里的三个核心观点 \ --model fast \ --output ./result.json \ --format json生成的文件大概是这样的结构{ session_id: s_abc123, model: fast, response: [观点一..., 观点二..., 观点三...], usage: { input_tokens: 356, output_tokens: 128 } }--format json这个参数非常实用它让 OpenClaw 不再只是一个人机对话工具而是可以嵌入程序处理的处理单元。我在做一个关键词抽取的小工具时就是让模型定期输出 JSON然后由 Python 脚本统一汇总整个过程全程无人值守。3.3 慎用但有用的参数--dry-run、--timeout、--temperature这几个参数不是说不能碰而是在明白后果的情况下再用。--dry-run是最安全的排练模式。它会把你即将执行的完整请求打印出来但不会真正发送给模型。我写复杂的批处理脚本时必用这条命令用来检查将要发出去的指令到底长什么样——尤其当指令里拼接了变量时很容易拼出意外内容dry-run 能让你提前发现。--timeout是控制超时时间的默认值往往比较保守。如果你跑一个需要长思考链路的分析任务默认超时可能不够。我的做法是针对任务类型分别设定简单摘要给 30 秒深度分析给 300 秒。--temperature控制生成随机性数值越低回答越稳定、越高越有创意。如果你希望模型输出稳定可复现建议调到 0.2 左右如果你在做头脑风暴式的创意生成0.8 以上会更有惊喜。这里有一个常见的误会有人以为 temperature 越高模型越聪明其实它只是让输出分布更散并不会提升质量。3.4 环境变量不显眼但适合做固化配置配置文件能解决的问题就别用命令行参数硬扛。OpenClaw 读取环境变量的方式非常直接比如OPENCLAW_MODELfast、OPENCLAW_TIMEOUT120、OPENCLAW_CONFIG/path/to/config.toml。适合放环境变量的通常是这台机器上长期不变的偏好比如默认模型和默认超时。我在一台专门用来跑批处理的机器上会在.bashrc里写好这样几行省得每次敲命令都带一堆参数export OPENCLAW_MODELstandard export OPENCLAW_TIMEOUT180 export OPENCLAW_OUTPUT_FORMATjson注意环境变量的优先级低于命令行参数但高于配置文件。这意味着你可以在.bashrc里设一个通用偏好遇到特殊任务再用命令行覆盖。这个通用兜底临时覆盖的组合逻辑是参数体系中最值得养成的习惯。它跟编程里默认参数 局部重写的思路一模一样理解一次终身受用。4. 一条真实工作流从零开始用命令行完成一次批量文档总结4.1 需求拆解把大任务切成小命令只看单个命令总是不够直观所以我挑了一个我真实做过的小任务从头到尾把完整命令串一遍。这个任务是某目录下有 10 篇产品说明文档我需要逐个总结成三个要点并把结果按文件名一一对应地保存下来。先拆解一下需求。这项任务包含四个子步骤拿到文件列表、对每个文件调用模型做总结、把结果保存、最后确认所有文件都处理完。用图形界面做你得反复打开上传、复制、保存用命令行做则是一条循环加一个最终检查。4.2 第一步确认输入文件避免空跑我用一个变量把文件列表先接住先打印个数确认防止后面循环跑了个寂寞。$ files$(ls docs/*.md) $ echo $files | tr \n | wc -l 10这一步看似多余实则是在为后面的批处理打地基。人有视觉确认能力知道这里有 10 个文件但命令行不会替你数数。万一目录路径写错了后面循环跑了一通结果全是空输入浪费时间和 token排查还麻烦。脚本中先确认输入再循环是我一直坚持的习惯。4.3 第二步逐文件跑任务并保存结果接下来是核心循环。我用了--output参数把每个结果直接写入独立文件并用文件名做了映射$ for f in docs/*.md; do openclaw run 请阅读以下文档并给出三个核心要点$(cat $f) \ --model fast \ --format text \ --output ${f%.md}_summary.txt done说明一下这里要注意的地方。命令中的$(cat $f)会把文件内容直接拼接进指令文本这是一个非常常见但也很容易出问题的写法。如果文件太大指令会超过模型上下文窗口如果文件内容里含有特殊字符可能被 bash 重新解析。更稳妥的方式是用openclaw run --input-file $f前提是你用的版本支持这个参数。不支持的话我建议把大文件先拆成小块再批量提交。4.4 第三步检查输出状态别让错误悄悄溜走循环结束后我不会马上宣布完成而是先看退出码和输出文件个数。命令行模式下只要命令没有抛异常循环就会一路跑完哪怕里面有任务内容生成失败。所以批处理后的检查环节是必须的。$ echo exit$? $ ls docs/*_summary.txt | wc -l 10 $ openclaw logs --grep error --tail 200这组检查背后的逻辑是三层验证退出码判断命令本身是否正常执行文件数量判断是否每篇都有输出日志检查有没有隐藏的错误记录了但没弹出来。这三个都没问题我才会放心地把结果交出去。4.5 第二步的进阶版用管道直接喂内容如果你不想把文件内容拼到指令里也可以用管道把内容喂给 OpenClaw。这是命令行风格的典型用法也是我日常工作流里非常喜欢的一种形态$ cat docs/产品A.md | openclaw run 请提取这份文档的要点 --model fast管道输入的好处是干净、不容易被转义问题纠缠。缺点是一次只能处理一个文件的内容batch 能力弱。两个方式没有绝对优劣小文件快速任务我用管道需要保存结果、批量处理的场景我用带--input-file的方式。5. 那些文档不会写但实际操作一定会遇到的坑5.1 坑一session 上下文不是无限大的它会悄悄遗忘这是我这段时间踩得最疼的一个坑。有一回我在某个 session 里连续讨论了大量背景材料中间隔了一段时间没继续再回来追问时发现模型完全不记得之前提到的一个关键假设。我第一反应是OpenClaw 是不是有 bug翻日志才发现session 的上下文窗口是有容量上限的超出的部分会按策略被裁剪掉。理解这个机制很重要session 的记忆不等于永久存储。它更像是临时工位东西多了就得腾地方。如果要长期保存某些信息应该把它们写入外部知识库或文件而不是寄托在对话上下文里。我的实际做法是关键背景资料单独写成context.md文件每次开启重大问题分析时重新加载一下而不是指望模型从长对话里回忆。5.2 坑二Windows PowerShell 下的引号转义会吃掉你的指令在 Linux/macOS 的 bash 里单引号、双引号各司其职规则相对容易理解。但换到 Windows PowerShell 环境转义规则完全不同——双引号内的$符号照样会被当作变量前缀处理单引号又不能包住含单引号的内容。我吃过一次亏在 PowerShell 里跑openclaw run 请解释$HOME变量的含义结果指令传到模型那里时$HOME已经被替换成了本机路径模型看到的是具体路径而不是$HOME 变量。这个问题的解决思路有两层。第一层在 PowerShell 里写指令尽量把$转义为$或者改用单引号包裹整个指令。第二层更建议把复杂指令写进文件再执行比如openclaw run --prompt-file ./prompt.txt从根本上避开 shell 解析。我在 Windows 机器上跑重要任务时几乎都走文件路径这比调引号规则要省心得多。5.3 坑三日志全开时输出太吵不开时问题又看不见--verbose、--debug这类参数确实能提供海量信息但一开起来终端输出会多到找不到北。我一开始图省事直接在.bashrc里设了默认调试输出结果每次命令输出几十行附加信息真正想看的结果被淹没在日志里。后来我调整了策略日常运行用默认日志级别只有任务失败时才临时加--verbose重跑一遍。这样既能保证正常输出的干净又能在排错时随时放大镜。另外如果你要定位的是网络层面的问题logs --grep latency比开着--verbose肉眼扫描要高效得多。5.4 坑四批处理循环里--output的路径必须干净写 batch 脚本时--output ./result.json看起来没问题但如果循环里文件名变量没处理好很容易把文件写到意外位置或者相互覆盖。有一次我在脚本里漏掉了文件名变量导致每次循环都往同一个文件里写跑完之后那个文件只有最后一次任务的结果前面几轮全白跑了。要避免这个问题一个简单的原则是输出文件名一定要包含输入文件的唯一标识。比如${f%.md}_summary.txt能保证一一对应。跑完后再用文件计数确认一遍这个习惯能救回大量无效工作。6. 参数速查表把常用的参数一次列全为了方便随时翻阅我把前面提到的所有高频参数整理成一张表。建议收藏尤其是刚开始掌握命令行的时候把表格放在手边可以少走很多弯路。参数类型默认行为典型用法--model字符串配置文件指定按任务难度切换模型--config路径默认配置文件多项目隔离配置--verbose/-v开关关闭排错时打开--debug开关关闭更详细的调试信息--output路径终端打印保存结果到文件--format字符串texttext / json / markdown--input-file路径无从文件读取输入内容--prompt-file路径无从文件读取提示词--session字符串临时会话指定要续接的会话名--dry-run开关关闭只显示请求不真正执行--timeout整数默认配置控制单次任务最长等待时间--temperature浮点数默认配置调整输出随机性这条表不是让你全背下来按需查才是常态。我的个人习惯是新参数先拿--dry-run跑一遍确认请求长什么样再真正执行。这个习惯让我躲过了很多次误操作。7. 我的日常命令行习惯几条可以照抄的经验7.1 用别名把长命令变短OpenClaw 的命令虽然清晰但敲多了也累。我的做法是在.bashrc里设置别名把高频命令缩短alias ocopenclaw alias oc-runopenclaw run --format text alias oc-jsonopenclaw run --format json alias oc-statusopenclaw status alias oc-logopenclaw logs --tail 80设好之后oc-run ...和oc-json ...用起来比原生命令顺手很多。特别是oc-json配合管道就可以非常方便地接入其他工具。7.2 默认输出格式切换为 JSON 再配 jq如果不仅是手动跑任务还想把结果交给脚本处理我强烈建议把--format json设为默认。JSON 输出的结构化程度远高于纯文本再配合jq做字段提取几乎就是一个轻量级的自动化流水线。$ openclaw run 列出三种常见的分布式事务方案 \ --format json | jq .response[]这行命令的效果是把结果里的每一条回答按数组元素打印出来方便后续做进一步处理。说实话我第一次在终端里看到自己的 AI 响应能被jq这样拆解时才真正理解命令行是给懂自动化的人准备的门票这句话。7.3 定期清理 session 列表保持工作区整洁session 多了之后openclaw session list输出会越来越乱。有些 session 只是顺手起的名字聊完就扔了堆积起来对后续查找造成干扰。我每周末会集中清理一次把已经结束任务的会话删除# 列出所有会话 $ openclaw session list # 删除不需要的会话 $ openclaw session delete s_abc123这里要提醒的是删除 session 之前先确认里面没有还没导出结果的内容。session 的上下文如果还没保存删除后就无法找回。我在早期就误删过一个存了较多上下文分析的会话那部分讨论材料只能靠记忆重写非常痛苦。7.4 给重要任务写一个任务脚本永远不要把复杂的多步骤任务用一行超长命令完成——回车一敲万一中间逻辑错了可能造成不可逆的结果。我的做法是为较复杂的任务单独写一个 shell 脚本脚本里按步骤分成几个函数每一步先打印提示再执行#!/usr/bin/env bash set -euo pipefail FILES$(ls docs/*.md) echo [1/3] 文件扫描完成共 $(echo $FILES | wc -w) 个文件 for f in docs/*.md; do openclaw run 总结要点$(cat $f) --model fast --output ${f%.md}_summary.txt done echo [2/3] 批处理执行完成 COUNT$(ls docs/*_summary.txt | wc -l) echo [3/3] 已生成 $COUNT 份总结文件set -euo pipefail这一行很关键它让脚本在遇到未定义变量或某个命令失败时立刻退出避免看起来跑完了其实一堆空结果的虚假成功。再加上每步的进度提示就算处理到一半出错你也能立刻知道问题出在第几步。8. 实战对话示例把几个指令放在同一情境里看这一节我会模拟一个真实使用场景把前文讲到的命令串在一段连续对话里展示。假设你临时接到一个任务分析某项目里的三份周报做出一份问题清单。# 新建会话准备上下文 $ openclaw session create --name 周报分析 # 依次导入三份周报 $ openclaw run 这份是第1周的周报$(cat week1.md) --session 周报分析 $ openclaw run 这份是第2周的周报$(cat week2.md) --session 周报分析 $ openclaw run 这份是第3周的周报$(cat week3.md) --session 周报分析 # 基于以上材料做问题汇总 $ openclaw run 请梳理这一季度的主要问题并标注风险等级输出JSON \ --session 周报分析 \ --format json这样做的好处是模型在汇总时能同时引用三份周报的内容因为三条指令都在同一个 session 下上下文是连贯的。如果分别用三个 session 执行第三次总结这步就会缺乏前文的对照信息分析质量会明显下降。这个例子也说明了一个观点session 的用途不只是聊天续上它可以作为小型的多步任务上下文容器来使用。把前置材料一步步喂进去再在最后一步做综合判断输出结构化结果这是命令行方式下非常高效的一种任务模式。最后再分享一个小经验如果你发现单次 session 里塞的材料太多导致模型遗忘不要犹豫直接把关键材料摘成独立文件存下来然后在每一步任务里显式引用。上下文再大也不如你把重要的信息写在配置文件里、写在指令里来得可靠。命令行归根结底是关于控制——控制输入、控制输出、控制上下文控制住了OpenClaw 才能真正成为你顺手的工作流工具。