OpenClaw 最近在自动化圈子里挺火但大多数人卡在同一个地方装好了却不知道让它干什么。我当初也一样折腾三天把服务跑起来然后每天都在手动敲指令这跟没用有什么区别所谓“真正自动化”指的是让 OpenClaw 自己触发任务、自己执行、自己把结果送到你面前。这需要十多个进阶配置我从实操中整理出 10 个最关键的技能覆盖浏览器操作、定时任务、文件传输、消息推送、运维巡检和重试告警。无论你是拿它做个人助理还是准备搭一条 AI 自动化流水线这 10 个技能都值得挨个试一遍。1. 先搞懂 OpenClaw 的自动化逻辑1.1 自动化三要素触发源、执行体、出口要真正自动化首先得改变“手动发消息给 agent”的习惯。我见过太多人把 OpenClaw 当成一个高级 ChatGPT每次需要做事就打开终端敲一句话。这不叫自动化这叫遥控。把自动化拆成三层看思路会清晰很多触发源定时器、文件变化、Webhook、消息事件。执行体agent 本身加能调用的工具链比如浏览器、Shell、文件传输、测试框架。出口飞书、Teams、邮件、Webhook 等 channel把任务结果主动送到该去的地方。这三个要素必须协同。如果只有 agent 没有触发源它就是个需要你手动戳一下的遥控机器人如果只有触发源和 agent、没有出口任务跑完也没人知道结果如果只有出口没有执行体那就只是条通知管道。所以设计任何自动化任务前先逼自己回答三个问题谁来唤起它它要做什么结果去哪我第一版自动化只搭了前两层定时拉数据、agent 生成报告结果每天还要 SSH 上服务器翻日志。后来加了飞书推送才感觉这条链子算是闭环了。这也是为什么下面 10 个技能里有一半都在讲“出口”和“触发”而不是只讲 agent 本身。1.2 部署形态单实例还是多实例很多人第一次部署 OpenClaw 时容易踩一个坑为了“稳定”在服务器上同时开好几个进程结果隔一会儿就报错agent failed before reply: session file locked (timeout 60000ms)。这个错误说白了就是多个进程同时抢同一个会话文件谁都没法正常工作。OpenClaw 默认用本地文件做会话锁保证同一时刻只有一个进程能读写会话数据。它不是天生为多实例设计的分布式系统你别拿它当 Kubernetes 玩。推荐方案是单实例常驻用 systemd 或 Docker 管起来让它崩了自动重启。如果你确实需要多份任务同时跑请给每个实例单独指定数据目录通过环境变量或启动参数区分比如设置各自的OPENCLAW_HOME。我实际测试下来单实例加外部任务调度比多实例硬扛要稳得多。部署位置方面如果你在 Windows 上很多人会装在 WSL 里这样和 Linux 服务器环境更一致。还有人在 Windows 上直接用 windowshub 之类的工具装也能跑但要注意路径和权限问题。我的建议是正式跑任务放 Linux 服务器或云服务器上别放个人电脑。个人电脑一休眠所有定时任务就全停了。1.3 接模型千问是性价比比较高的选择OpenClaw 本身不产生智能它得接一个模型 API。现在可选的模型不少但我个人用得最多的还是千问原因很简单国内访问稳定、文档齐全、成本低。配置方式一般靠环境变量以我常用的配置为例export OPENCLAW_MODEL_PROVIDERdashscope export OPENCLAW_MODEL_API_KEYsk-xxxx export OPENCLAW_MODEL_NAMEqwen-plus如果任务偏结构化分析比如提取网页表格、整理日志用qwen-turbo够用成本还能再降一截。涉及复杂推理、多步骤规划的任务再切qwen-max。这玩意儿不是越贵越好是要匹配任务复杂度。我见过有人拿顶配模型跑“每天复制文件”这种任务纯属浪费。2. 五个让 Agent 主动干活的技能上2.1 技能一接管浏览器让 Playwright 替你操作网页OpenClaw 如果要处理网页最常用的工具是 Playwright。它能打开浏览器、点击按钮、填表单、抓数据、截图几乎能干所有前端操作。我通常会在 agent 的工具配置里启用 Playwright注册一个叫web的工具然后让 agent 根据自然语言指令操作。典型场景是每天早上抓内部系统报表、监控某个商品价格、或者把某个页面的更新内容自动保存下来。使用前记得安装浏览器内核不然 agent 会提示找不到浏览器playwright install chromium一个我踩过很多次的坑让 agent 等待页面加载时不要用固定sleep。有些页面 2 秒能开有些 5 秒都开不完固定等待要么超时要么白等。正确做法是让 agent 用wait_for_selector等待关键元素出现比如打开 https://example.com/report 等待 #data-table 出现 提取表格前 10 行 保存为 report.csv另外最好要求 agent 每次关键操作后截图保存到./screenshots目录。这样任务失败时你能通过截图回放判断是哪一步出了问题不用瞎猜。2.2 技能二定时任务让自动化从被动变主动手动触发永远不算自动化。OpenClaw 里注册定时任务一般是定义 cron 调度。我的配置长这样schedules: - name: morning_report cron: 0 8 * * * agent: reporter prompt: 抓取昨日销售数据并生成日报这里有三个细节要注意。第一时区。服务器默认可能是 UTC你在北京时间早上 8 点想跑任务cron 得写0 0 * * *否则会差 8 个小时。我习惯在启动服务前设TZAsia/Shanghai一劳永逸。第二cron 表达式要会读。0 8 * * *意思是每天 8 点 0 分执行*/10 * * * *是每 10 分钟执行一次。别把分钟和小时写反。第三任务日志。定时任务最容易出现“静默失败”——表面上没报错实际根本没跑。我建议在配置里强制开启日志记录每次执行后写一条日志到文件。这样你可以每周检查一次日志确认任务是“执行了但失败”还是“根本没触发”。定时任务是把 OpenClaw 从“脚本机器人”变成“值班员”的关键一步。一旦它能自己醒来干活你就成功了一半。2.3 技能三把 Agent 的脑回路固化成任务卡你有没有遇到过这种情况同一件事你今天问 agent它给你一个格式明天问它又换了套格式。原因很简单你每次给的指令不够稳定。解决办法是给每个高频任务写一张任务卡。所谓任务卡就是一份 Markdown 文件把目标、步骤、输出格式全部写死。我给“日报生成”写的任务卡长这样# 任务卡日报生成 ## 目标 每天早上抓取维表数据生成日报并推送飞书。 ## 步骤 1. 连接数据库读取昨日汇总 2. 调用内置 chart 工具生成趋势图 3. 输出 Markdown 表格报告 4. 将报告摘要推送到飞书群完整报告保存到 reports/ 目录 ## 输出要求 - 文件名report-YYYY-MM-DD.md - 前置摘要不超过 200 字 - 表格包含日期、订单数、销售额、同比、环比然后把任务卡路径放到 agent 的 prompt 里或者直接在调度任务里指定schedules: - name: daily_report cron: 0 8 * * * agent: reporter task_card: cards/daily-report.md实际测试下来任务卡能显著提高 agent 的稳定性。哪怕你换了底层的模型任务卡里的步骤约束还在不太容易跑偏。这就像你给新同事写了 SOP他照着做至少能在及格线上。2.4 技能四跨系统文件传输Ubuntu 自动把文件送到 Windows自动化经常涉及文件流转。最典型的需求是Linux 服务器上生成了报表要把文件传到 Windows 办公电脑上。很多人第一反应是用网盘但网盘要手动同步且不够可控。更好的方案是让 OpenClaw 直接用 SFTP/SCP 传输。以我日常用的配置为例transfers: - name: push_report type: sftp host: 192.168.1.10 port: 22 username: user key_file: ~/.ssh/id_rsa remote_path: C:/Users/xxx/Documents/reports这里最需要注意的是 Windows 那边的 SSH 服务。如果 Windows 没开 OpenSSH Serversftp 是连不进去的。你需要在 Windows 上启用 OpenSSH Server 服务并且保证防火墙放行 22 端口。另一个常见问题是路径写法。Windows 上 SFTP 的路径不是C:\Users\...而是C:/Users/...反斜杠会被转义导致目录找不到。我在这上面吃过亏后来统一改成正斜杠问题消失。用密钥免密传输比密码靠谱得多。配置好之后agent 在任务里只要说“把今天的报表传到 Windows 的 reports 目录”它就会自动执行 scp 命令。这个技能对经常在 Ubuntu 和 Windows 之间来回搬文件的人非常实用。2.5 技能五接口自动化让 Agent 驱动 pytest 并翻译报错如果你做开发或测试可以把 OpenClaw 当成一个测试调度器。它本身不是测试框架但它能调用 pytest、Appium 这类工具并把执行结果处理成人话。我的做法是在 agent 工具里注册一个run_pytest命令执行接口测试并输出 JUnit 格式的结果pytest tests/api -q --junitxmlresult.xml然后给 agent 的指令是运行 tests/api 下的接口测试 完成后读取 result.xml 把失败用例按接口分组生成错误摘要为什么强调让 agent 读取 JUnit XML 而不是直接看终端输出因为 pytest 的终端输出太长会刷掉有用信息。agent 直接读 XML能结构化地拿到“哪个用例挂了、报什么错、耗时多少”。让 agent 生成摘要推送到群里而不是把几千行原始输出全贴出去这是关键。这里我建议按接口分组整理错误类似/api/order/create3 个用例失败原因全是 500/api/user/login1 个用例失败断言超时这样开发人员一看到消息就能定位问题不用自己去翻测试报告。如果你把 Appium 也接进来移动端 UI 自动化同样可以用这套逻辑调度。3. 打通外部系统让自动化形成闭环下3.1 技能六接入飞书或 Teams把结果主动推到你面前没有消息推送的自动化和没有闹钟的早起一样不可靠。OpenClaw 的 channel 机制就是干这个的。我最早接的是飞书后来也试过 Teams两边套路差不多。飞书接入时你要先在飞书开放平台建一个自建应用拿到 App ID 和 App Secret再配置一个机器人或 Webhook。OpenClaw 里配置好后agent 可以直接发送消息到指定群或用户。这里有个高频问题飞书输出容易被截断。OpenClaw 生成的内容比较长尤其是测试报告或日志分析推送超过一定长度飞书会直接截掉后半段。解决办法是给 agent 定一个规矩超过 2000 字的内容先保存成文件群里只发摘要和文件链接。如果必须发全文就拆成多条消息每条控制在 1500 字以内。Teams 的接入思路类似注册一个 Incoming Webhook把 URL 配进 OpenClaw。你不需要自己处理认证Webhook URL 本身就带校验。但 Teams 对消息卡片格式有要求建议在 agent prompt 里明确“输出为可读文本不要用复杂 Markdown”。3.2 技能七用 Webhook 接收外部事件让系统主动找 OpenClaw定时任务是“到点干活”Webhook 是“有事叫你”。很多外部系统都支持 Webhook 回调比如监控报警、代码仓库事件、云服务告警。你可以把这些事件接到 OpenClaw 上。配置方式通常是在 OpenClaw 里开一个 Webhook 入口比如POST /webhook/run收到 JSON 请求后触发指定 agent。我实际用过的一个场景是阿里云监控检测到服务器负载偏高通过 Webhook 通知 OpenClawagent 自动拉取最近日志、分析 CPU 占用、判断是否需要重启服务然后把结论推送到群里。这个技能要注意三件事。第一安全校验。Webhook 地址一旦暴露任何人都可以触发你的任务。必须在 OpenClaw 侧校验请求里的 token 或签名否则相当于给人留了个免密后门。第二幂等性。同一个事件可能被外部系统重发多次agent 执行任务时要能识别重复事件避免重复操作。比如“重启服务”这个操作连续触发两次会出问题需要在任务里做去重判断。第三返回信息。Webhook 可以同步返回执行结果也可以异步处理。我的建议是默认异步。同步响应容易卡住外部系统异步则把任务放进队列OpenClaw 处理完再主动推结果。3.3 技能八结合 Ansible 做运维巡检让 Agent 当值班员运维同学看到 OpenClaw 会想问这玩意儿能帮我管服务器吗能而且不需要写太复杂的东西直接让 agent 调用 Ansible 就行。我给你一个最简单的场景每天早上检查一批服务器的磁盘和内存。传统做法是写脚本、看结果用 OpenClaw 的做法是让它跑命令再对结果做分析。agent 可以执行ansible all -i hosts.ini -m shell -a df -h free -m然后它自己解析输出如果发现某台服务器磁盘使用率超过 80%就生成一条告警消息推送到飞书群。如果所有服务器都正常它只发一句“巡检完成无异常”。这样你早上打开手机一眼就知道服务器健不健康。这个玩意的价值不在于“执行命令”而在于 agent 能理解输出并做初判。以前 Ansible 跑完你还是得人工看数据现在 agent 帮你把异常筛出来了。当然谨慎起见正式的生产环境变更不要全自动放权建议只做巡检和报警把“执行变更”留给人来确认。3.4 技能九多 Agent 分工搭一条完整流水线单 Agent 能干活但复杂任务最好交给多个 Agent 分工协作。比如“每天早上自动跑一遍全链路数据同步并生成报告”这种任务拆成三个 agent 会更清晰采集 agent负责登录平台、下载数据、存到本地。分析 agent负责清洗数据、生成统计图表、写分析结论。通知 agent负责把报告摘要推送到群聊并把完整报告归档。每个 agent 可以配置不同的模型和工具。采集 agent 用便宜快速的模型分析 agent 用推理能力更强的模型通知 agent 只做文本处理响应要快。串联方式可以用简单的文件交接比如采集 agent 完成后写一个.done标记文件分析 agent 轮询到标记就开始处理。也可以用消息接口串联前一个 agent 完成后主动触发下一个。我做过 3 个 agent 的流水线之后最大的感受是排查故障变容易了哪一个环节挂了只需要重跑那一个 agent不用全部重来。3.5 技能十给任务加重试与告警让系统自己消化偶发故障再稳定的自动化也会遇到网络波动、API 超时、下游系统抽风。真正可靠的系统不是不出错而是出错后能自己恢复或者至少能主动告诉你。OpenClaw 里可以给任务配置重试策略我一般这么写retry: max_attempts: 3 backoff: 10s on_failure: notify_channel: feishu但要注意并不是所有失败都值得重试。网络超时、依赖服务暂时无响应这类临时错误可以重试配置写错、鉴权失败、任务逻辑出错这类永久错误重试一百次也没用反而把错误刷屏。所以我会在任务卡里明确告诉 agent哪些情况属于“不重试直接告警”。还有一个更隐蔽的问题任务“静默失效”。比如 cron 配置被别人误删了或者 Webhook 入口停了任务不会报错只是再也不执行了。解决方法是加一个健康检查任务每天固定时间检查所有 schedule 是否还在如果发现缺失就发告警。这是我在实际运维中补上的最后一道防线。4. 常见问题与排查实录4.1 “session file locked (timeout 60000ms)”到底怎么解决这个报错在 OpenClaw 用户群里出现的频率极高我一开始也遇到过。它的本质是会话文件被锁住当前进程等待锁释放等了 60 秒还没等到直接就放弃了。常见原因有三个前一个 OpenClaw 进程没有正常退出锁文件残留。两个实例用了同一个数据目录互相抢锁。某个 Agent 任务卡死一直持有锁。排查顺序也很固定。先看有没有残留进程ps aux | grep openclaw如果有多个进程在跑kill 掉多余的保留一个。然后看数据目录下有没有.lock文件如果是死锁残留直接删掉再启动。最后如果你确实遇到偶发超时可以把锁超时时间调大一些比如设置环境变量OPENCLAW_SESSION_LOCK_TIMEOUT120000。但注意调大超时是缓兵之计治标不治本。最稳的方案还是单实例部署不要同时开多个进程。4.2 飞书输出被截断分段推送飞书机器人对单条消息长度有限制OpenClaw 默认如果一股脑把长文本推过来后半段会被截断。我见过有人查了半天为什么报告没有结论部分结果发现是被平台截了。解决办法是养成两个习惯。第一在 agent 的全局指令里写一句“所有推送内容控制在 1500 字以内超长文本先保存为文件再推送文件和摘要。”第二确实需要发送长内容就要求 agent 拆分消息每段之间加一个【续】之类的标记保证阅读连贯。Teams 也有类似问题但表现不同。Teams 的 Webhook 对卡片 JSON 格式敏感有时推送失败是因为 Markdown 语法不兼容。遇到这类问题把消息类型切成纯文本再重试。4.3 自动化任务“没反应”的排查顺序定时任务没跑、Webhook 到了但没触发、agent 执行一半就停了……这些“没反应”问题按下面这个顺序排查能省不少时间看调度是否生效。用openclaw schedule list查一下定时任务在不在cron 表达式对不对。看任务日志。大多数 OpenClaw 版本都有openclaw logs或日志文件目录确认任务到底是没触发还是执行了但报错。看模型 API 是否正常。有时平台欠费或限流agent 会卡在请求模型那一步表面看起来就是“没反应”。看 channel 配置。飞书或 Teams 的 Webhook 地址可能过期了导致结果发不出去任务本身却执行完了。我给你整理成一张速查表现象优先检查定时任务没执行schedule 列表、时区、服务器是否休眠任务执行了但没结果channel webhook / token 是否失效agent 一直转圈模型 API 余额、网络连通性日志里有报错任务卡路径、权限、依赖工具是否安装排查时一定要按这个顺序来别上来就怀疑是 OpenClaw 有 bug。我踩过最惨的一次是 Windows 电脑休眠导致所有 cron 任务停了一天最后发现 OpenClaw 一切正常电脑睡过去了。最后再分享一个实际体会把这些技能全用上之后我最大的感受是真正难的从来不是某一个工具而是如何拆任务。你让一个 agent 去做“帮我弄个报表”它大概率输出一堆花里胡哨但不可用的东西但你给它一张任务卡、一个定时器、一条推送通道它就能稳定产出。建议不要试图一开始就搭一个万能机器人先从一个小任务开始比如每天早上 8 点用 Playwright 抓一个网页新闻推到飞书群。把这一条链路跑通再慢慢叠加接口测试、运维巡检、多 agent 协作。当你发现自己连续一周不需要手动登录服务器时才算真的自动化了。