命令行是很多 OpenClaw 用户绕不开的一道坎也是拉开使用效率差距的关键。这篇是【OpenClaw 超级 AI 实战专栏】基础篇的第三讲前两篇我们聊完了环境搭建和核心概念后台问得最多的就是“命令到底怎么记”“一堆参数到底怎么选”。与其零散地翻帮助文档不如把最常用的指令、参数背后的设计逻辑一次讲透。这篇内容不挑基础。哪怕你之前从来没碰过终端只要会敲字、会回车就能跟着一步步把命令跑起来如果你已经用了一段时间 OpenClaw但总觉得每次输入命令都要现查帮助那这篇文章更适合你——我会帮你把命令按逻辑归好类让你从“背命令”变成“懂命令”。读完你至少能解决三个问题知道每个命令是干什么的、知道参数该怎么搭配、遇到报错知道去哪儿查。OpenClaw 的核心思路是把 AI 能力打包成语义清晰的操作指令通过终端这层薄薄的壳让人和 AI 之间形成可复现、可审计、可批量执行的协作流程。图形界面确实能完成大部分日常工作但剩下那 20% 的效率提升基本都藏在命令行里。这篇没有假设你已经学过命令行一点基础都没有也完全没问题。1. 命令行为什么值得系统学一遍OpenClaw 的操作范式1.1 图形界面与命令行的本质区别先泼一盆冷水如果你只是偶尔在图形界面里用一次 OpenClaw那完全没必要强迫自己学命令行。但一旦你的工作流里出现了这些场景——每天要跑多次重复任务、需要在脚本里调用 AI 能力、想精确控制每个任务的输出格式、要批量处理一批同类请求——图形界面就会变成瓶颈。点鼠标的效率与敲命令的效率差距不是两倍三倍而是数量级。举一个最直观的例子。假设你要对 10 个 Markdown 文件依次做“总结 生成标题 输出 JSON 结构”图形界面的做法是逐个上传、逐个等待、逐个复制结果操作 10 次。命令行只需要一条循环指令加一次导出剩下的全部交给 OpenClaw 自己跑。而且命令行的操作是可以被记录的今天这条命令效果好把它存成一个脚本明天、下周、下个月都能重复使用整个流程无比确定。图形界面那种“上次怎么点的来着”的模糊感在命令行里不存在。还有一个容易被忽略的点命令行天然自带审计能力。图形界面里的每一次点击如果不刻意截图事后很难还原当时做了什么而命令行的每一次执行都会留下运行记录配合日志命令可以精确回溯某次任务用了什么参数、输出了什么结果。对于需要复现结果、团队协作、复盘失败的场景来说这种确定性是无可替代的。这也是我坚持在项目里推动“命令优先”的原因不是为了显得专业而是为了让自己在出问题时能少一点猜测、多一点证据。1.2 OpenClaw 命令行的三条设计主线在用了相当长一段时间之后我把 OpenClaw 的命令行总结成三条主线只要把这三条主线记住绝大多数命令都能归位不需要死记硬背。第一条是生命周期主线对应“启动—运行—停止—检查”这一套动作核心命令是 init、run、stop、status。第二条是对象管理主线对应“我要操作谁”包括 task任务、agent代理、session会话、model模型。第三条是环境治理主线对应“怎么配置、怎么排错、怎么导出”核心是 config、log、export 这一类命令。把这三条主线画在脑子里命令行就不再是一串需要硬记的单词而是一套有逻辑的工具箱。遇到一个新需求先问自己这是要启动什么、操作什么还是治理什么答案基本能把命令范围缩小到两三个。后文我会按这条主线把最常用的命令逐个拆开讲每条都会标注它属于哪条主线方便你建立自己的记忆索引。1.3 命令的通用结构先看懂再上手在拆解具体命令之前先花一分钟看懂 OpenClaw 命令的通用结构这是所有指令的地基openclaw [全局参数] command [局部参数] [参数值]方括号代表可选尖括号代表必填。比如openclaw --log-level debug run --input demo.txt里--log-level debug是全局参数run是具体命令--input demo.txt是局部参数。这个结构贯穿所有命令理解它之后即使遇到一个从没见过的子命令你也能通过openclaw command --help快速反推用法。我在带新人时发现大部分命令行恐惧症其实源自结构不清。戒掉恐惧的最快方法就是把“命令”和“参数”分开看命令决定做什么参数决定怎么做。后文涉及的所有命令你都用这个框架去理解会轻松很多。遇到不认识的参数先别慌openclaw run --help会列出所有可用的局部参数和它们的作用比任何记忆都可靠。2. 最常用指令全景一个命令一张卡这个部分我按命令卡片的形式来组织每张卡片包含“作用—常用参数—典型用法—注意事项”四块建议收藏后当速查表用。我不会把每个命令的所有参数都列出来只挑使用频率最高、效果最明显的讲避免信息过载。2.1 生命周期管理init、run、stop、statusinit作用初始化一个工作目录生成 OpenClaw 项目所需的基础结构比如配置文件模板、任务存放目录、日志目录。典型用法openclaw init --name my-project --template standard参数说明--name项目名后续所有任务标识都会带上这个前缀方便区分不同项目。--template初始化模板standard 是通用型minimal 是精简模式后者适合只需要一个配置文件、不需要额外目录结构的轻量场景。--force当目录已有配置时强制覆盖慎用会丢失旧配置。为什么推荐先 init 再动手因为 OpenClaw 会把很多运行时状态会话记录、任务历史、缓存写入工作目录。如果不初始化就开始跑任务这些文件会散落在当前目录里后续管理会非常痛苦。init 之后所有东西都有了一个明确的家日志、缓存、任务记录都会被归拢到固定位置排查问题也容易得多。我见过不少朋友用了几周 OpenClaw 才发现任务历史散在十几个目录里后来统一 init 之后整个工作目录清爽了很多。run这是使用频率最高的命令作用是一次性执行任务前台运行结束后退出。典型用法openclaw run --input ./notes.md --output ./result.md --model fast --max-tokens 2000--input指定输入文件--output指定结果输出位置。如果在项目目录里执行OpenClaw 会自动读取当前目录的配置文件把任务绑定到当前会话。--model可以在单次执行时临时切换模型不改变全局配置非常适合“这次想跑快点就用 fast跑精点就用 pro”的临时需求。注意事项run 是前台命令任务没跑完之前终端会被占用。如果你需要同时做别的事可以考虑把任务拆出来交给 task 管理或者干脆让任务在后台运行这会在后面的章节展开。此外run 命令适合单次、明确的请求如果你的场景是连续多轮对话用 session 会更合适。stop作用停止当前正在运行的任务。前台任务直接用 CtrlC 中断即可但如果开了后台任务或者任务卡住stop 就派上用场。典型用法openclaw stop --task 20250112_1423 --force--task指定任务ID--force表示即使任务当前正处于“正在保存中间结果”的状态也强制终止。非必要不使用 force因为强制终止可能丢失部分进度比如已经生成但还没写入文件的中间内容。我一般在任务确实卡了五分钟以上或者确认结果已经不需要了才会加 force。如果你只是想暂停而不是终止可以查一下任务管理相关命令不同版本的 OpenClaw 对暂停的支持不太一样。status作用查看当前运行状态包括 OpenClaw 版本、当前是否有任务在跑、最近一次执行结果、当前默认模型。典型用法openclaw status示例输出版本: v0.9.2 状态: 运行中 当前任务: 20250112_1423 [处理中 43%] 模型: fast 最近执行: 2025-01-12 14:23:05 [成功]status 是我建议每个用户都养成习惯的命令。每次跑任务之前看一眼 status能避免很多“我明明启动了但怎么没反应”的困惑——大概率是上一次任务还挂着资源被占了一部分。特别是在你同时管理多个项目的时候status 能帮你快速确认当前终端绑定的到底是哪个项目目录避免把任务跑到了莫名其妙的地方。2.2 任务与代理管理task、agent、sessiontask作用管理任务列表是后台任务和批量任务的核心入口。子命令主要有 list、show、cancel。典型用法openclaw task list --limit 20 --status running openclaw task show --id 20250112_1423 openclaw task cancel --id 20250112_1423--limit控制展示多少条--status按状态过滤running、done、failed、cancelled。show 会展示某个任务的全部元信息包括参数、输入输出路径、耗时、token 消耗等。建议每个自动化脚本结尾都加一行openclaw task list方便事后确认结果。task 和 run 的关系你可以理解成“run 是快速下单task 是订单管理后台”。日常简单任务用 run 就好一旦涉及批量、后台、定时就必须通过 task 来管理。agent作用管理 AI 代理。代理可以理解为“预设了角色和行为的 AI 执行单元”比如“文档整理员”“代码审查助手”“翻译官”。子命令有 list、create、use。典型用法openclaw agent list openclaw agent create --name 文档整理员 --role summarizer --model fast openclaw agent use --name 文档整理员 --input ./report.mdagent 的价值在于复用。你不需要每次都在命令行里重复描述角色要求只需要在 create 时定义一次之后所有任务都能直接用。我在实际项目中把常用的三类角色文档整理、代码审查、数据分析提前配好每天的工作流就从“输入一大段提示词”变成了“一句命令加一个文件路径”。这里要提醒一下创建代理时写的角色描述会直接影响后续所有任务的质量所以不要偷懒把背景、风格、约束条件都写清楚一次投入长期受益。session作用管理会话适合需要连续追问、多轮对话的场景。子命令有 start、list、resume。典型用法openclaw session start --name 需求讨论 openclaw session list openclaw session resume --name 需求讨论 --append ./新需求.mdrun 更像是“一次性调用”session 则保持了上下文。如果你的任务是多轮交互比如先让 AI 梳理大纲再让它基于大纲写正文session 能避免每次都重新交代背景。注意 session 会占用更多资源用完记得结束会话或者通过带时间参数的命令清理历史会话。这里有个实际经验长时间不用的 session 会积累大量上下文导致后续执行变慢所以我的习惯是每个会话结束后都会主动关闭需要保留的记录通过 export 导出到本地再关。2.3 模型与配置管理model、configmodel作用查看当前配置的模型、切换默认模型、列出可用模型。典型用法openclaw model list openclaw model set --name fast openclaw model show--name指定模型别名。模型别名对应什么取决于你的配置文件可能是某个开源模型也可能是某个本地部署的推理服务。本章不做模型选型展开只看命令层model set 会永久修改当前项目的默认模型如果要临时切换用 run 命令的--model参数。模型切换后建议立刻跑一条小任务验证一下而不是直接上大规模任务。因为不同模型的输入输出格式在某些场景下有微妙差异先小成本确认再规模化使用是我踩过不少坑后的教训。config作用查看和修改配置。子命令有 get、set、list。典型用法openclaw config list openclaw config get --key model.default openclaw config set --key model.default --value pro --global--global表示写进用户级全局配置不加则只写当前项目配置。OpenClaw 的配置体系遵循“项目配置覆盖全局配置”的原则所以同一个 key你可以在不同项目里设置不同值。config 是我处理疑难问题时第一个查的地方——很多“命令行为异常”的根源其实是某个配置项在不知情的情况下被改掉了。用config list把所有当前生效的配置打出来往往一眼就能看出问题所在。2.4 日志与导出log、exportlog作用查看运行日志。日志是排错的第一现场比任何猜测都可靠。典型用法openclaw log --task 20250112_1423 --level warn openclaw log --live--level按级别过滤debug、info、warn、error--live实时滚动显示。debug 级别的日志信息量很大正常使用不用看但当你遇到诡异的问题比如同样的命令上次成功这次失败建议直接上 debug 级别跑一遍通常能看到差异点在哪里。log 和 status 的区别在于status 告诉你“现在怎么样”log 告诉你“刚才到底发生了什么”。排错时先看 status 建立全局印象再针对性翻 log效率最高。export作用把任务结果导出成指定格式。典型用法openclaw export --task 20250112_1423 --format json --output ./result.json openclaw export --task 20250112_1423 --format markdown --output ./result.md支持的格式包括 json、yaml、markdown、txt具体还要看你当前项目配置里启用了哪些输出插件。export 的价值在于任务执行完是一回事结果能不能被下游工具消费是另一回事。我在做自动化流程时几乎总是让 OpenClaw 把结果输出成 JSON再由后续脚本做进一步处理这个习惯让整个链条的稳定性提升了不少。如果你经常需要把结果分享给不熟悉终端的人markdown 格式通常是最友好的选择。3. 参数体系深度拆解全局参数与局部参数命令好比动词参数好比副词——副词决定动作怎么做。OpenClaw 的参数体系分成两层全局参数和局部参数理解这两层的边界就掌握了九成以上的参数用法。3.1 全局参数影响所有指令的基础开关全局参数可以直接放在任何命令的前面或后面它影响的是这一次命令的整体行为而不是某个具体功能。最常用的几个如下openclaw --config ./custom.yaml run --input demo.txt openclaw --log-level debug run --input demo.txt openclaw --no-color status openclaw --verbose run --input demo.txt openclaw --output-format json status--config指定本次使用的配置文件。如果不指定OpenClaw 会按“当前项目配置 → 用户全局配置 → 内置默认配置”的顺序自动寻找。--log-level设置日志级别可取值 debug、info、warn、error。同一件事不同级别的日志信息量差别很大。--no-color关闭彩色输出在纯文本日志环境或自动化流水线里非常有用。否则你会看到一堆 ANSI 转义符干扰解析。--verbose-v输出更多细节包括每一步的耗时、调用链等。--output-format设置整体输出格式可取值 table、json、yaml、plain。默认是 table但做脚本调用时要记得切到 json 或 yamltable 格式对自动解析很不友好。全局参数的记忆方法是凡是“不管执行什么命令都生效”的参数基本都归为全局参数。它们不会改变任务内容本身只改变任务的表达方式和行为环境。我建议在交互式终端里用默认的彩色输出在脚本和自动化环境里统一加--no-color这样日志解析不会出乱子。3.2 局部参数控制单次执行的关键旋钮局部参数跟随具体命令只有在该命令的上下文里才有意义。常用的局部参数我按功能分组说明这样比逐个记更容易举一反三。第一组是输入输出类--input/-i定义输入源--output/-o定义结果去向。OpenClaw 允许输入源是文件、目录或标准输入用-表示。标准输入的支持让你可以把命令接入管道比如把上一个命令的输出直接交给 OpenClaw 处理这是脚本化的基础能力。第二组是质量与风格类--model临时指定模型--temperature控制输出的随机性数值范围 0 到 1越低越保守稳定越高越发散有创意--max-tokens限制单次生成的最大 token 数。这几个参数直接决定同样的输入会产出什么样的结果。比如做数据清洗时我会把 temperature 调到 0.2 左右让输出尽量稳定写文案时可以调到 0.8让表述更丰富。这个参数的调整逻辑和你在图形界面里调节“温度滑块”是同一个东西只是一个在屏幕上拖动一个在终端里输入。第三组是执行控制类--timeout设定单任务超时时间--dry-run只检查命令和参数是否正确、不真正执行--force跳过确认提示。dry-run 是我强烈推荐新手使用的参数——它不会产生任何副作用却能帮你提前发现一半以上的低级错误比如参数拼写错、输入文件路径不存在等。记住一句话拿不准的时候先 dry-run 一遍成本极低收益极高。3.3 参数的优先级与覆盖规则参数多了自然会遇到“我明明设了 A怎么最后生效的是 B”的问题。OpenClaw 对参数来源有一个统一的优先级从高到低是命令行显式参数本次执行时你在终端里写的值环境变量比如当前会话里导出的配置项项目配置文件用户全局配置内置默认值这个优先级意味着配置文件里设了某种模型但如果运行命令时你加了--model pro那么本次执行一定会用 pro其他地方的配置不会覆盖它。反过来如果你发现某个配置改了没生效先想想是不是命令行里有更高优先级的参数把它的值覆盖掉了。还有一个细节容易被忽略环境变量虽然排第二但在实际使用中很容易被遗忘。比如你在某个运行脚本里导出了特定模型变量你会发现任何项目里执行 run 都默认用它改配置文件也没用。遇到这种“配置改了不生效”的情况先检查一下当前环境里有哪些相关变量在悄悄起作用排查效率会高很多。这一条几乎每隔几周就会有人在交流群里问一遍值得画个重点。4. 实操演练从零开始跑通一个真实任务理论讲了一堆最后还是得落到手上。本节我们完整走一遍用 OpenClaw 整理一份技术文档生成结构化摘要并导出成 JSON 供后续脚本使用。整个过程完全命令行操作你会发现这套流程跑通一次之后完全可以沉淀成模板反复使用。4.1 场景设定与前置准备模拟一个非常常见的需求你手上有一份结构比较散乱的会议记录meeting_notes.md内容有十几段中间夹杂着任务项、待确认问题、闲聊记录。你的目标是通过 OpenClaw 自动完成三件事提炼会议核心议题、提取所有“待办事项”、按角色归类责任人最后输出一个便于程序处理的 JSON 文件。前置准备只需要两步。第一步在一个空目录里初始化项目mkdir ~/demo-project cd ~/demo-project openclaw init --name demo --template standard第二步确认当前状态正常openclaw status看到状态为空闲后再继续下一步。这一步很多人会跳过但我建议保留它帮你建立“动手前先确认环境”的习惯这个习惯在真实项目里能省很多排查时间。尤其是当你同时维护多个项目时status输出里的项目路径信息能立刻告诉你当前终端是否在你以为的那个目录里。4.2 分步执行从输入到输出首先把会议记录内容写入输入文件或者直接从你已有的文档复制过来。然后执行openclaw run \ --input ./meeting_notes.md \ --output ./summary.json \ --model pro \ --temperature 0.2 \ --max-tokens 1500 \ --output-format json这里几个参数的选择意图需要解释一下--model pro是因为这次任务需要做语义提炼用 fast 模式会明显感觉总结质量打折这种“需要理解文本结构”的任务值得用更强的模型--temperature 0.2是刻意把随机性压低的——提炼会议纪要不需要创意需要的是稳定和准确过高的 temperature 会让每次跑出来的要点不完全一致不利于后续做结果比对--max-tokens 1500是给输出一个合理上限防止模型失控生成超长内容--output-format json是为了让结果能直接被脚本读取。命令执行期间终端会显示进度信息比如[14:23:05] 读取文件 meeting_notes.md (1280 tokens) [14:23:06] 调用模型 pro [14:23:14] 生成完成 (1420 tokens) [14:23:15] 写入输出 summary.json看到写入完成提示后检查一下输出文件cat summary.json可以用cat或任意编辑器打开确认内容结构是预期的 JSON。如果发现摘要里缺少某类信息不要急着改命令第二步是调整提示词相关内容——在 OpenClaw 中角色模板或任务模板里通常包含“提示要点”把它补进去再重新跑一次往往比调一堆参数更有效。这里也体现出一个思维习惯先确认参数没问题再往提示内容的方向深挖两件事要分开排查不要混在一起瞎试。4.3 沉淀脚本与复用任务跑通之后最值得做的事是把它固化成脚本而不是下次再敲一遍。新建一个run_summary.sh文件把关键命令放进去同时做一点小改进#!/bin/bash cd ~/demo-project openclaw run \ --input $1 \ --output ${1%.md}_summary.json \ --model pro \ --temperature 0.2 \ --max-tokens 1500 \ --output-format json \ --log-level warn注意这里加了--log-level warn脚本里跑命令时不需要那么多进度信息出问题时再看日志即可。${1%.md}是 bash 的字符串处理意思是把传入的文件名的.md后缀去掉再拼上_summary.json。这个小技巧让你不用手写输出文件名输入什么文件自然就会在旁边生成对应的结果文件。以后处理新的会议记录只需要bash run_summary.sh another_meeting.md一次调用一个结构化 JSON 就出现在同目录下。这种“参数固定 脚本包装”的做法是提升效率性价比最高的方式——不需要学任何编程语言只是把验证过的命令用脚本沉淀下来就能让每次重复劳动变成一次敲击。等脚本积累多了你会发现一个属于自己的命令工作台就这么搭起来了。5. 常见问题与排查技巧实录这是所有文章里我最喜欢写的一部分因为这些都是真实踩过的坑。按提问频率从高到低整理如下全是硬干货。5.1 命令不存在的排查思路错误信息长这样Error: unknown command ran别急着说“我命令打对了啊”先想清楚三个可能性。第一命令拼写错误这是最常见的原因run 写成 ran、config 写成 congig排查方式很简单用 tab 键自动补全别手敲。第二子命令不存在比如你输入了openclaw task delete但当前版本里只有openclaw task cancel这时需要执行openclaw task --help看看合法的子命令有哪些。第三版本差异你的某个命令是在旧版本学的但当前安装的版本已经调整了命令名。推荐的做法是遇到 unknown command先执行openclaw --help查看顶层命令再执行openclaw command --help查看子命令。帮助系统本身就是最权威的命令手册熟悉了它你甚至可以不需要这篇教程——虽然这篇教程能帮你更快定位。如果你在帮助列表里都没找到想要的命令那就去查一下当前版本和文档版本是否一致别对着旧教程用新工具那是纯粹的折磨。5.2 参数没生效的三大原因“我明明加了 --model pro为什么跑出来还是 fast”这个问题我在交流群里见过不同版本。参数没生效通常逃不出以下三个原因。第一优先级覆盖。命令行参数优先级最高但如果你在命令行里同时写了两个同名参数比如--model pro --model fast后写的会覆盖先写最终生效的是 fast。第二环境变量干扰。项目配置文件里明明设置了默认模型但系统环境里存在同名变量它的优先级高于配置文件导致你以为配置生效了实际是环境变量说了算。第三写错了命令层级。参数放错了位置全局参数被放在命令后面或者局部参数被放在命令前面某些情况下会被解析成别的含义。提示排查参数问题时环境变量是最容易被忽略的干扰项。先看当前环境里有哪些相关变量再检查命令行写法基本能覆盖九成以上问题。这三大原因里环境变量干扰尤其讨厌因为它很难一眼发现。我自己的习惯是在每个项目里用一个统一的运行脚本脚本里明确设置好所有环境变量避免“隐形的配置”散落在各处。5.3 超时与资源不足的处理任务跑到一半报超时是后台任务里最常见的问题。错误信息通常是Error: task timed out after 300 seconds处理思路分三步。第一步判断是偶发还是必然。偶发就加大超时时间再跑一次比如--timeout 600。第二步如果每次都在同一个阶段超时说明这个任务确实需要更多时间此时可以用后台模式执行或者把一个大任务拆成几个小任务分段跑。第三步如果你需要长时间运行建议在配置里把默认超时时间调大而不是每次都写参数——配置一次省心一生。资源不足的另一个典型现象是任务直接报“内存不足”或“无法分配上下文”。这通常不是你电脑真的缺内存而是单个任务的上下文长度设置超过了模型实际支持范围。解决方法非常简单降低--max-tokens或者减少输入文件的长度。有时候把一个大文件拆成多个小文件分批处理反而是效率最高的方案。这个思路也适用于那些“一跑就失败”的大任务别纠结于一次处理完分段处理通常又快又稳。5.4 日志与调试技巧最后一组技巧关于怎么用日志定位问题这是我压箱底的经验。第一遇到诡异问题先把--log-level debug打开。debug 日志会记录每一步的命令解析结果、参数值、调用链和耗时绝大多数“命令行为不对”的问题在 debug 日志里都能看到明确线索。比如你会发现“原来我写的参数被解析成了另一个值”“原来程序读取的是另一个配置文件”这些信息在普通输出里完全看不到。第二善用--dry-run。OpenClaw 支持只检查不执行这条命令不会产生任何副作用却能验证参数、输入路径、输出路径是否合法。我强烈建议任何复杂命令在正式执行前都先 dry-run 一遍。特别是那些包含了很多参数的长命令dry-run 能在几秒钟内告诉你“这条命令到底能不能跑”省下的时间远远超过多敲那一下。第三查看日志时不要只看最后几行。把 error 级别和 warn 级别的日志分开看往往能发现隐藏的警告。有些任务虽然显示成功但中途出现过警告这些警告可能影响结果质量。比如某个输入文件部分段落被跳过了这类警告在普通输出里根本看不到但在日志里明明白白。养成“执行完扫一眼 warn 日志”的习惯你会提前发现很多潜在问题。第四养成“固定目录存日志”的习惯。在项目配置里指定日志目录每次跑完任务后顺手看一眼日志尽量不要让日志散落在临时位置。几周之后你会发现回顾历史问题时有日志和没日志完全是两种体验。日志就像飞行记录仪平时用不上一旦出了状况它就是唯一的真相来源。写到这里最想分享的一条体会是命令行的门槛其实不在记忆而在建立“先理解结构、再动手实践”的习惯。我刚接触 OpenClaw 时也觉得命令多得记不住后来把所有命令画成生命周期、对象管理、环境治理三条线一切突然变得清晰了。现在每次跑任务前我都会先问自己三个问题我要启动什么我要操作什么我怎么确认它正常答案自然就出来了。这篇列出的指令和参数是使用频率最高的子集覆盖日常绝大多数场景但每个版本的 OpenClaw 可能都有细微差异遇到不确定时--help永远是值得依赖的伙伴。如果这篇对你有帮助后续我会继续更新实战专栏的进阶篇聊聊多任务编排和自动化脚本的深入玩法。 
长河君 · 2026/10/18 12:17:06 · 阅读 1.2k OpenClaw 命令行从入门到实战：核心命令、参数体系与排错技巧
命令行是很多 OpenClaw 用户绕不开的一道坎也是拉开使用效率差距的关键。这篇是【OpenClaw 超级 AI 实战专栏】基础篇的第三讲前两篇我们聊完了环境搭建和核心概念后台问得最多的就是“命令到底怎么记”“一堆参数到底怎么选”。与其零散地翻帮助文档不如把最常用的指令、参数背后的设计逻辑一次讲透。这篇内容不挑基础。哪怕你之前从来没碰过终端只要会敲字、会回车就能跟着一步步把命令跑起来如果你已经用了一段时间 OpenClaw但总觉得每次输入命令都要现查帮助那这篇文章更适合你——我会帮你把命令按逻辑归好类让你从“背命令”变成“懂命令”。读完你至少能解决三个问题知道每个命令是干什么的、知道参数该怎么搭配、遇到报错知道去哪儿查。OpenClaw 的核心思路是把 AI 能力打包成语义清晰的操作指令通过终端这层薄薄的壳让人和 AI 之间形成可复现、可审计、可批量执行的协作流程。图形界面确实能完成大部分日常工作但剩下那 20% 的效率提升基本都藏在命令行里。这篇没有假设你已经学过命令行一点基础都没有也完全没问题。1. 命令行为什么值得系统学一遍OpenClaw 的操作范式1.1 图形界面与命令行的本质区别先泼一盆冷水如果你只是偶尔在图形界面里用一次 OpenClaw那完全没必要强迫自己学命令行。但一旦你的工作流里出现了这些场景——每天要跑多次重复任务、需要在脚本里调用 AI 能力、想精确控制每个任务的输出格式、要批量处理一批同类请求——图形界面就会变成瓶颈。点鼠标的效率与敲命令的效率差距不是两倍三倍而是数量级。举一个最直观的例子。假设你要对 10 个 Markdown 文件依次做“总结 生成标题 输出 JSON 结构”图形界面的做法是逐个上传、逐个等待、逐个复制结果操作 10 次。命令行只需要一条循环指令加一次导出剩下的全部交给 OpenClaw 自己跑。而且命令行的操作是可以被记录的今天这条命令效果好把它存成一个脚本明天、下周、下个月都能重复使用整个流程无比确定。图形界面那种“上次怎么点的来着”的模糊感在命令行里不存在。还有一个容易被忽略的点命令行天然自带审计能力。图形界面里的每一次点击如果不刻意截图事后很难还原当时做了什么而命令行的每一次执行都会留下运行记录配合日志命令可以精确回溯某次任务用了什么参数、输出了什么结果。对于需要复现结果、团队协作、复盘失败的场景来说这种确定性是无可替代的。这也是我坚持在项目里推动“命令优先”的原因不是为了显得专业而是为了让自己在出问题时能少一点猜测、多一点证据。1.2 OpenClaw 命令行的三条设计主线在用了相当长一段时间之后我把 OpenClaw 的命令行总结成三条主线只要把这三条主线记住绝大多数命令都能归位不需要死记硬背。第一条是生命周期主线对应“启动—运行—停止—检查”这一套动作核心命令是 init、run、stop、status。第二条是对象管理主线对应“我要操作谁”包括 task任务、agent代理、session会话、model模型。第三条是环境治理主线对应“怎么配置、怎么排错、怎么导出”核心是 config、log、export 这一类命令。把这三条主线画在脑子里命令行就不再是一串需要硬记的单词而是一套有逻辑的工具箱。遇到一个新需求先问自己这是要启动什么、操作什么还是治理什么答案基本能把命令范围缩小到两三个。后文我会按这条主线把最常用的命令逐个拆开讲每条都会标注它属于哪条主线方便你建立自己的记忆索引。1.3 命令的通用结构先看懂再上手在拆解具体命令之前先花一分钟看懂 OpenClaw 命令的通用结构这是所有指令的地基openclaw [全局参数] command [局部参数] [参数值]方括号代表可选尖括号代表必填。比如openclaw --log-level debug run --input demo.txt里--log-level debug是全局参数run是具体命令--input demo.txt是局部参数。这个结构贯穿所有命令理解它之后即使遇到一个从没见过的子命令你也能通过openclaw command --help快速反推用法。我在带新人时发现大部分命令行恐惧症其实源自结构不清。戒掉恐惧的最快方法就是把“命令”和“参数”分开看命令决定做什么参数决定怎么做。后文涉及的所有命令你都用这个框架去理解会轻松很多。遇到不认识的参数先别慌openclaw run --help会列出所有可用的局部参数和它们的作用比任何记忆都可靠。2. 最常用指令全景一个命令一张卡这个部分我按命令卡片的形式来组织每张卡片包含“作用—常用参数—典型用法—注意事项”四块建议收藏后当速查表用。我不会把每个命令的所有参数都列出来只挑使用频率最高、效果最明显的讲避免信息过载。2.1 生命周期管理init、run、stop、statusinit作用初始化一个工作目录生成 OpenClaw 项目所需的基础结构比如配置文件模板、任务存放目录、日志目录。典型用法openclaw init --name my-project --template standard参数说明--name项目名后续所有任务标识都会带上这个前缀方便区分不同项目。--template初始化模板standard 是通用型minimal 是精简模式后者适合只需要一个配置文件、不需要额外目录结构的轻量场景。--force当目录已有配置时强制覆盖慎用会丢失旧配置。为什么推荐先 init 再动手因为 OpenClaw 会把很多运行时状态会话记录、任务历史、缓存写入工作目录。如果不初始化就开始跑任务这些文件会散落在当前目录里后续管理会非常痛苦。init 之后所有东西都有了一个明确的家日志、缓存、任务记录都会被归拢到固定位置排查问题也容易得多。我见过不少朋友用了几周 OpenClaw 才发现任务历史散在十几个目录里后来统一 init 之后整个工作目录清爽了很多。run这是使用频率最高的命令作用是一次性执行任务前台运行结束后退出。典型用法openclaw run --input ./notes.md --output ./result.md --model fast --max-tokens 2000--input指定输入文件--output指定结果输出位置。如果在项目目录里执行OpenClaw 会自动读取当前目录的配置文件把任务绑定到当前会话。--model可以在单次执行时临时切换模型不改变全局配置非常适合“这次想跑快点就用 fast跑精点就用 pro”的临时需求。注意事项run 是前台命令任务没跑完之前终端会被占用。如果你需要同时做别的事可以考虑把任务拆出来交给 task 管理或者干脆让任务在后台运行这会在后面的章节展开。此外run 命令适合单次、明确的请求如果你的场景是连续多轮对话用 session 会更合适。stop作用停止当前正在运行的任务。前台任务直接用 CtrlC 中断即可但如果开了后台任务或者任务卡住stop 就派上用场。典型用法openclaw stop --task 20250112_1423 --force--task指定任务ID--force表示即使任务当前正处于“正在保存中间结果”的状态也强制终止。非必要不使用 force因为强制终止可能丢失部分进度比如已经生成但还没写入文件的中间内容。我一般在任务确实卡了五分钟以上或者确认结果已经不需要了才会加 force。如果你只是想暂停而不是终止可以查一下任务管理相关命令不同版本的 OpenClaw 对暂停的支持不太一样。status作用查看当前运行状态包括 OpenClaw 版本、当前是否有任务在跑、最近一次执行结果、当前默认模型。典型用法openclaw status示例输出版本: v0.9.2 状态: 运行中 当前任务: 20250112_1423 [处理中 43%] 模型: fast 最近执行: 2025-01-12 14:23:05 [成功]status 是我建议每个用户都养成习惯的命令。每次跑任务之前看一眼 status能避免很多“我明明启动了但怎么没反应”的困惑——大概率是上一次任务还挂着资源被占了一部分。特别是在你同时管理多个项目的时候status 能帮你快速确认当前终端绑定的到底是哪个项目目录避免把任务跑到了莫名其妙的地方。2.2 任务与代理管理task、agent、sessiontask作用管理任务列表是后台任务和批量任务的核心入口。子命令主要有 list、show、cancel。典型用法openclaw task list --limit 20 --status running openclaw task show --id 20250112_1423 openclaw task cancel --id 20250112_1423--limit控制展示多少条--status按状态过滤running、done、failed、cancelled。show 会展示某个任务的全部元信息包括参数、输入输出路径、耗时、token 消耗等。建议每个自动化脚本结尾都加一行openclaw task list方便事后确认结果。task 和 run 的关系你可以理解成“run 是快速下单task 是订单管理后台”。日常简单任务用 run 就好一旦涉及批量、后台、定时就必须通过 task 来管理。agent作用管理 AI 代理。代理可以理解为“预设了角色和行为的 AI 执行单元”比如“文档整理员”“代码审查助手”“翻译官”。子命令有 list、create、use。典型用法openclaw agent list openclaw agent create --name 文档整理员 --role summarizer --model fast openclaw agent use --name 文档整理员 --input ./report.mdagent 的价值在于复用。你不需要每次都在命令行里重复描述角色要求只需要在 create 时定义一次之后所有任务都能直接用。我在实际项目中把常用的三类角色文档整理、代码审查、数据分析提前配好每天的工作流就从“输入一大段提示词”变成了“一句命令加一个文件路径”。这里要提醒一下创建代理时写的角色描述会直接影响后续所有任务的质量所以不要偷懒把背景、风格、约束条件都写清楚一次投入长期受益。session作用管理会话适合需要连续追问、多轮对话的场景。子命令有 start、list、resume。典型用法openclaw session start --name 需求讨论 openclaw session list openclaw session resume --name 需求讨论 --append ./新需求.mdrun 更像是“一次性调用”session 则保持了上下文。如果你的任务是多轮交互比如先让 AI 梳理大纲再让它基于大纲写正文session 能避免每次都重新交代背景。注意 session 会占用更多资源用完记得结束会话或者通过带时间参数的命令清理历史会话。这里有个实际经验长时间不用的 session 会积累大量上下文导致后续执行变慢所以我的习惯是每个会话结束后都会主动关闭需要保留的记录通过 export 导出到本地再关。2.3 模型与配置管理model、configmodel作用查看当前配置的模型、切换默认模型、列出可用模型。典型用法openclaw model list openclaw model set --name fast openclaw model show--name指定模型别名。模型别名对应什么取决于你的配置文件可能是某个开源模型也可能是某个本地部署的推理服务。本章不做模型选型展开只看命令层model set 会永久修改当前项目的默认模型如果要临时切换用 run 命令的--model参数。模型切换后建议立刻跑一条小任务验证一下而不是直接上大规模任务。因为不同模型的输入输出格式在某些场景下有微妙差异先小成本确认再规模化使用是我踩过不少坑后的教训。config作用查看和修改配置。子命令有 get、set、list。典型用法openclaw config list openclaw config get --key model.default openclaw config set --key model.default --value pro --global--global表示写进用户级全局配置不加则只写当前项目配置。OpenClaw 的配置体系遵循“项目配置覆盖全局配置”的原则所以同一个 key你可以在不同项目里设置不同值。config 是我处理疑难问题时第一个查的地方——很多“命令行为异常”的根源其实是某个配置项在不知情的情况下被改掉了。用config list把所有当前生效的配置打出来往往一眼就能看出问题所在。2.4 日志与导出log、exportlog作用查看运行日志。日志是排错的第一现场比任何猜测都可靠。典型用法openclaw log --task 20250112_1423 --level warn openclaw log --live--level按级别过滤debug、info、warn、error--live实时滚动显示。debug 级别的日志信息量很大正常使用不用看但当你遇到诡异的问题比如同样的命令上次成功这次失败建议直接上 debug 级别跑一遍通常能看到差异点在哪里。log 和 status 的区别在于status 告诉你“现在怎么样”log 告诉你“刚才到底发生了什么”。排错时先看 status 建立全局印象再针对性翻 log效率最高。export作用把任务结果导出成指定格式。典型用法openclaw export --task 20250112_1423 --format json --output ./result.json openclaw export --task 20250112_1423 --format markdown --output ./result.md支持的格式包括 json、yaml、markdown、txt具体还要看你当前项目配置里启用了哪些输出插件。export 的价值在于任务执行完是一回事结果能不能被下游工具消费是另一回事。我在做自动化流程时几乎总是让 OpenClaw 把结果输出成 JSON再由后续脚本做进一步处理这个习惯让整个链条的稳定性提升了不少。如果你经常需要把结果分享给不熟悉终端的人markdown 格式通常是最友好的选择。3. 参数体系深度拆解全局参数与局部参数命令好比动词参数好比副词——副词决定动作怎么做。OpenClaw 的参数体系分成两层全局参数和局部参数理解这两层的边界就掌握了九成以上的参数用法。3.1 全局参数影响所有指令的基础开关全局参数可以直接放在任何命令的前面或后面它影响的是这一次命令的整体行为而不是某个具体功能。最常用的几个如下openclaw --config ./custom.yaml run --input demo.txt openclaw --log-level debug run --input demo.txt openclaw --no-color status openclaw --verbose run --input demo.txt openclaw --output-format json status--config指定本次使用的配置文件。如果不指定OpenClaw 会按“当前项目配置 → 用户全局配置 → 内置默认配置”的顺序自动寻找。--log-level设置日志级别可取值 debug、info、warn、error。同一件事不同级别的日志信息量差别很大。--no-color关闭彩色输出在纯文本日志环境或自动化流水线里非常有用。否则你会看到一堆 ANSI 转义符干扰解析。--verbose-v输出更多细节包括每一步的耗时、调用链等。--output-format设置整体输出格式可取值 table、json、yaml、plain。默认是 table但做脚本调用时要记得切到 json 或 yamltable 格式对自动解析很不友好。全局参数的记忆方法是凡是“不管执行什么命令都生效”的参数基本都归为全局参数。它们不会改变任务内容本身只改变任务的表达方式和行为环境。我建议在交互式终端里用默认的彩色输出在脚本和自动化环境里统一加--no-color这样日志解析不会出乱子。3.2 局部参数控制单次执行的关键旋钮局部参数跟随具体命令只有在该命令的上下文里才有意义。常用的局部参数我按功能分组说明这样比逐个记更容易举一反三。第一组是输入输出类--input/-i定义输入源--output/-o定义结果去向。OpenClaw 允许输入源是文件、目录或标准输入用-表示。标准输入的支持让你可以把命令接入管道比如把上一个命令的输出直接交给 OpenClaw 处理这是脚本化的基础能力。第二组是质量与风格类--model临时指定模型--temperature控制输出的随机性数值范围 0 到 1越低越保守稳定越高越发散有创意--max-tokens限制单次生成的最大 token 数。这几个参数直接决定同样的输入会产出什么样的结果。比如做数据清洗时我会把 temperature 调到 0.2 左右让输出尽量稳定写文案时可以调到 0.8让表述更丰富。这个参数的调整逻辑和你在图形界面里调节“温度滑块”是同一个东西只是一个在屏幕上拖动一个在终端里输入。第三组是执行控制类--timeout设定单任务超时时间--dry-run只检查命令和参数是否正确、不真正执行--force跳过确认提示。dry-run 是我强烈推荐新手使用的参数——它不会产生任何副作用却能帮你提前发现一半以上的低级错误比如参数拼写错、输入文件路径不存在等。记住一句话拿不准的时候先 dry-run 一遍成本极低收益极高。3.3 参数的优先级与覆盖规则参数多了自然会遇到“我明明设了 A怎么最后生效的是 B”的问题。OpenClaw 对参数来源有一个统一的优先级从高到低是命令行显式参数本次执行时你在终端里写的值环境变量比如当前会话里导出的配置项项目配置文件用户全局配置内置默认值这个优先级意味着配置文件里设了某种模型但如果运行命令时你加了--model pro那么本次执行一定会用 pro其他地方的配置不会覆盖它。反过来如果你发现某个配置改了没生效先想想是不是命令行里有更高优先级的参数把它的值覆盖掉了。还有一个细节容易被忽略环境变量虽然排第二但在实际使用中很容易被遗忘。比如你在某个运行脚本里导出了特定模型变量你会发现任何项目里执行 run 都默认用它改配置文件也没用。遇到这种“配置改了不生效”的情况先检查一下当前环境里有哪些相关变量在悄悄起作用排查效率会高很多。这一条几乎每隔几周就会有人在交流群里问一遍值得画个重点。4. 实操演练从零开始跑通一个真实任务理论讲了一堆最后还是得落到手上。本节我们完整走一遍用 OpenClaw 整理一份技术文档生成结构化摘要并导出成 JSON 供后续脚本使用。整个过程完全命令行操作你会发现这套流程跑通一次之后完全可以沉淀成模板反复使用。4.1 场景设定与前置准备模拟一个非常常见的需求你手上有一份结构比较散乱的会议记录meeting_notes.md内容有十几段中间夹杂着任务项、待确认问题、闲聊记录。你的目标是通过 OpenClaw 自动完成三件事提炼会议核心议题、提取所有“待办事项”、按角色归类责任人最后输出一个便于程序处理的 JSON 文件。前置准备只需要两步。第一步在一个空目录里初始化项目mkdir ~/demo-project cd ~/demo-project openclaw init --name demo --template standard第二步确认当前状态正常openclaw status看到状态为空闲后再继续下一步。这一步很多人会跳过但我建议保留它帮你建立“动手前先确认环境”的习惯这个习惯在真实项目里能省很多排查时间。尤其是当你同时维护多个项目时status输出里的项目路径信息能立刻告诉你当前终端是否在你以为的那个目录里。4.2 分步执行从输入到输出首先把会议记录内容写入输入文件或者直接从你已有的文档复制过来。然后执行openclaw run \ --input ./meeting_notes.md \ --output ./summary.json \ --model pro \ --temperature 0.2 \ --max-tokens 1500 \ --output-format json这里几个参数的选择意图需要解释一下--model pro是因为这次任务需要做语义提炼用 fast 模式会明显感觉总结质量打折这种“需要理解文本结构”的任务值得用更强的模型--temperature 0.2是刻意把随机性压低的——提炼会议纪要不需要创意需要的是稳定和准确过高的 temperature 会让每次跑出来的要点不完全一致不利于后续做结果比对--max-tokens 1500是给输出一个合理上限防止模型失控生成超长内容--output-format json是为了让结果能直接被脚本读取。命令执行期间终端会显示进度信息比如[14:23:05] 读取文件 meeting_notes.md (1280 tokens) [14:23:06] 调用模型 pro [14:23:14] 生成完成 (1420 tokens) [14:23:15] 写入输出 summary.json看到写入完成提示后检查一下输出文件cat summary.json可以用cat或任意编辑器打开确认内容结构是预期的 JSON。如果发现摘要里缺少某类信息不要急着改命令第二步是调整提示词相关内容——在 OpenClaw 中角色模板或任务模板里通常包含“提示要点”把它补进去再重新跑一次往往比调一堆参数更有效。这里也体现出一个思维习惯先确认参数没问题再往提示内容的方向深挖两件事要分开排查不要混在一起瞎试。4.3 沉淀脚本与复用任务跑通之后最值得做的事是把它固化成脚本而不是下次再敲一遍。新建一个run_summary.sh文件把关键命令放进去同时做一点小改进#!/bin/bash cd ~/demo-project openclaw run \ --input $1 \ --output ${1%.md}_summary.json \ --model pro \ --temperature 0.2 \ --max-tokens 1500 \ --output-format json \ --log-level warn注意这里加了--log-level warn脚本里跑命令时不需要那么多进度信息出问题时再看日志即可。${1%.md}是 bash 的字符串处理意思是把传入的文件名的.md后缀去掉再拼上_summary.json。这个小技巧让你不用手写输出文件名输入什么文件自然就会在旁边生成对应的结果文件。以后处理新的会议记录只需要bash run_summary.sh another_meeting.md一次调用一个结构化 JSON 就出现在同目录下。这种“参数固定 脚本包装”的做法是提升效率性价比最高的方式——不需要学任何编程语言只是把验证过的命令用脚本沉淀下来就能让每次重复劳动变成一次敲击。等脚本积累多了你会发现一个属于自己的命令工作台就这么搭起来了。5. 常见问题与排查技巧实录这是所有文章里我最喜欢写的一部分因为这些都是真实踩过的坑。按提问频率从高到低整理如下全是硬干货。5.1 命令不存在的排查思路错误信息长这样Error: unknown command ran别急着说“我命令打对了啊”先想清楚三个可能性。第一命令拼写错误这是最常见的原因run 写成 ran、config 写成 congig排查方式很简单用 tab 键自动补全别手敲。第二子命令不存在比如你输入了openclaw task delete但当前版本里只有openclaw task cancel这时需要执行openclaw task --help看看合法的子命令有哪些。第三版本差异你的某个命令是在旧版本学的但当前安装的版本已经调整了命令名。推荐的做法是遇到 unknown command先执行openclaw --help查看顶层命令再执行openclaw command --help查看子命令。帮助系统本身就是最权威的命令手册熟悉了它你甚至可以不需要这篇教程——虽然这篇教程能帮你更快定位。如果你在帮助列表里都没找到想要的命令那就去查一下当前版本和文档版本是否一致别对着旧教程用新工具那是纯粹的折磨。5.2 参数没生效的三大原因“我明明加了 --model pro为什么跑出来还是 fast”这个问题我在交流群里见过不同版本。参数没生效通常逃不出以下三个原因。第一优先级覆盖。命令行参数优先级最高但如果你在命令行里同时写了两个同名参数比如--model pro --model fast后写的会覆盖先写最终生效的是 fast。第二环境变量干扰。项目配置文件里明明设置了默认模型但系统环境里存在同名变量它的优先级高于配置文件导致你以为配置生效了实际是环境变量说了算。第三写错了命令层级。参数放错了位置全局参数被放在命令后面或者局部参数被放在命令前面某些情况下会被解析成别的含义。提示排查参数问题时环境变量是最容易被忽略的干扰项。先看当前环境里有哪些相关变量再检查命令行写法基本能覆盖九成以上问题。这三大原因里环境变量干扰尤其讨厌因为它很难一眼发现。我自己的习惯是在每个项目里用一个统一的运行脚本脚本里明确设置好所有环境变量避免“隐形的配置”散落在各处。5.3 超时与资源不足的处理任务跑到一半报超时是后台任务里最常见的问题。错误信息通常是Error: task timed out after 300 seconds处理思路分三步。第一步判断是偶发还是必然。偶发就加大超时时间再跑一次比如--timeout 600。第二步如果每次都在同一个阶段超时说明这个任务确实需要更多时间此时可以用后台模式执行或者把一个大任务拆成几个小任务分段跑。第三步如果你需要长时间运行建议在配置里把默认超时时间调大而不是每次都写参数——配置一次省心一生。资源不足的另一个典型现象是任务直接报“内存不足”或“无法分配上下文”。这通常不是你电脑真的缺内存而是单个任务的上下文长度设置超过了模型实际支持范围。解决方法非常简单降低--max-tokens或者减少输入文件的长度。有时候把一个大文件拆成多个小文件分批处理反而是效率最高的方案。这个思路也适用于那些“一跑就失败”的大任务别纠结于一次处理完分段处理通常又快又稳。5.4 日志与调试技巧最后一组技巧关于怎么用日志定位问题这是我压箱底的经验。第一遇到诡异问题先把--log-level debug打开。debug 日志会记录每一步的命令解析结果、参数值、调用链和耗时绝大多数“命令行为不对”的问题在 debug 日志里都能看到明确线索。比如你会发现“原来我写的参数被解析成了另一个值”“原来程序读取的是另一个配置文件”这些信息在普通输出里完全看不到。第二善用--dry-run。OpenClaw 支持只检查不执行这条命令不会产生任何副作用却能验证参数、输入路径、输出路径是否合法。我强烈建议任何复杂命令在正式执行前都先 dry-run 一遍。特别是那些包含了很多参数的长命令dry-run 能在几秒钟内告诉你“这条命令到底能不能跑”省下的时间远远超过多敲那一下。第三查看日志时不要只看最后几行。把 error 级别和 warn 级别的日志分开看往往能发现隐藏的警告。有些任务虽然显示成功但中途出现过警告这些警告可能影响结果质量。比如某个输入文件部分段落被跳过了这类警告在普通输出里根本看不到但在日志里明明白白。养成“执行完扫一眼 warn 日志”的习惯你会提前发现很多潜在问题。第四养成“固定目录存日志”的习惯。在项目配置里指定日志目录每次跑完任务后顺手看一眼日志尽量不要让日志散落在临时位置。几周之后你会发现回顾历史问题时有日志和没日志完全是两种体验。日志就像飞行记录仪平时用不上一旦出了状况它就是唯一的真相来源。写到这里最想分享的一条体会是命令行的门槛其实不在记忆而在建立“先理解结构、再动手实践”的习惯。我刚接触 OpenClaw 时也觉得命令多得记不住后来把所有命令画成生命周期、对象管理、环境治理三条线一切突然变得清晰了。现在每次跑任务前我都会先问自己三个问题我要启动什么我要操作什么我怎么确认它正常答案自然就出来了。这篇列出的指令和参数是使用频率最高的子集覆盖日常绝大多数场景但每个版本的 OpenClaw 可能都有细微差异遇到不确定时--help永远是值得依赖的伙伴。如果这篇对你有帮助后续我会继续更新实战专栏的进阶篇聊聊多任务编排和自动化脚本的深入玩法。