1. 为什么我最终选了 OpenClaw而不是自己写个 Cron 脚本先说一下我最初的需求每天早上起来不想再一个个打开资讯网站、公众号、技术社区去刷而是希望有一个助手在固定时间把前一天的重点内容整理好推送给我。这个需求听起来很简单定时访问几个RSS源抓标题、抓摘要再发到某个聊天工具里自己写个 Python 脚本也能跑。但真正动手之后你会发现问题根本不在“定时”这两个字上而在“资讯”和“推送”这两个词上。资讯源的格式五花八门有的输出完整JSON有的只有残缺的HTML有的需要登录才能拿到全文有的反爬手段还很激进。今天能抓的接口明天可能就加了个签名参数。今天推送用的企业微信机器人还能用明天通知策略一变又要重写发送逻辑。如果你只是写一个固定脚本基本上每周都要为各种外部变化去补丁。而OpenClaw这类AI Agent框架解决的恰好是“接入变化”这件事。OpenClaw 的核心思路不是让你写死一套流程而是把“理解需求”和“执行动作”分开。你定义一个 Skill告诉它这个任务的目标、输入输出和可用工具模型会自己决定怎么调用工具、怎么解析结果、遇到异常怎么处理。也就是说我不用在代码里硬编码“第一步访问这个URL第二步正则提取标题”而是让 Agent 根据 Skill 描述去完成整件事。这和传统的 Cron Python 脚本相比最大的差异在于容错性接口挂了模型会尝试换一个源内容没匹配上模型会基于已有信息重新组织推送内容。当然OpenClaw 也不是银弹。它比普通脚本重需要本地有一个能跑推理的模型或者至少一个可用的 API 服务配置复杂度也高一些。但如果你和我一样需要维护多个资讯源、多种推送渠道、经常调整推送内容形式这个成本是值得的。下面我把整套搭建过程按可复刻的方式拆开写方便你照着操作。2. 部署环境准备Windows、WSL2 与本地模型选型2.1 WSL2 环境初始化先别急着装 OpenClaw我自己是在 Windows 上开发的但 OpenClaw 这类 Agent 框架在 Linux 环境里跑得更干净所以我选择了 WSL2。很多人在这一步容易踩坑以为执行一个wsl --install就万事大吉结果后面装依赖时各种诡异报错。我建议按这个顺序做以管理员身份打开 PowerShell执行wsl --install安装 WSL 功能并重启。重启后执行wsl --status检查当前状态。如果输出里显示默认版本是 1或者内核版本很老先执行wsl --update更新内核。执行wsl --set-default-version 2确保后续安装的发行版跑在 WSL2 上而不是 WSL1。WSL1 的 I/O 性能差Node.js 安装依赖时慢到让人怀疑人生。打开 WSL 终端更新系统包sudo apt update sudo apt upgrade -y。如果你有多个发行版建议专门建一个跑 OpenClaw 的发行版别和日常工作环境混在一起。重要的事情说三遍隔离、隔离、隔离。因为后面会装不少依赖搞乱了不影响主系统。检查 WSL2 是否真的处于健康状态可以执行uname -r如果内核版本号里带有microsoft-standard-WSL2说明你已经在 WSL2 上了。还有一个我后来才注意到的细节WSL2 默认占用内存和 CPU 比较保守如果模型推理时觉得卡可以在 Windows 用户目录下创建.wslconfig文件写入[wsl2] memory8GB processors4 swap4GB改完后执行wsl --shutdown再重新进入内存配置才会生效。这一步很关键尤其是你在 WSL2 里同时跑 OpenClaw 和 Ollama 时默认配置很容易出现内存不足。2.2 模型选型Qwen2.5-3B 这类小模型为什么够用OpenClaw 本身不提供推理能力它需要一个可调用的大模型。你可以接入云厂商的 API也可以本地部署一个开源模型。我做这个资讯推送助手时用的是本地部署方案装了 Ollama 然后拉取 Qwen2.5-3B。为什么会选这个规格资讯推送这个场景对模型的要求是能理解“整理、摘要、按照某格式输出”这类指令能在给定上下文中提取关键信息推理速度要快推送任务通常发生在早晨固定时间我不想等三分钟才收到推送。3B 参数的模型在这些任务上完全够用而 7B 和 14B 虽然文本理解能力更强但在本地 CPU/GPU 资源有限的情况下推理延迟会明显增加。如果你没有 GPU建议从 3B 或更小的 1.5B 开始试如果你用的是家用显卡7B 也值得尝试。下面是我当时对比后的记录模型规格摘要质量平均推理时间无GPU适用判断Qwen2.5-1.5B可用偶尔遗漏细节约2-4秒快速试跑Qwen2.5-3B稳定能正确归纳多个资讯源约5-8秒推荐Qwen2.5-7B更好长文本更准确约12-20秒有GPU再考虑安装 Ollama 并拉取模型curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2.5:3b ollama serve注意ollama serve会一直占用终端如果你不想每次手动启动可以把 Ollama 配置成 systemd 服务。另外OpenClaw 连接 Ollama 时默认 API 地址是http://localhost:11434后面配置模型连接时会用到。2.3 OpenClaw 安装与初始配置OpenClaw 的安装方式在不同版本下会有差异我建议先去官方仓库看最新的安装命令这里写一个典型的 Node.js 全局安装流程npm install -g openclaw/cli如果 Node.js 还没装推荐用 nvm 来安装 LTS 版本避免直接下载安装包导致路径混乱curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash nvm install --lts node -v装好 OpenClaw 之后执行openclaw init这一步会生成一个工作目录包含配置文件、Skills 目录和日志目录。我用下来的体验是OpenClaw 的配置主要集中在一个全局配置文件和各个 Skill 自己的描述文件里。初始配置时会让你填写模型连接方式我直接填了 Ollama 的地址和模型名model: provider: ollama base_url: http://localhost:11434 model_name: qwen2.5:3b填完配置后先别急着写任何 Skill跑一个最简单的测试让 Agent 回答一个问题确认模型连接正常。如果这里就报错后面写再多 Skill 都是浪费时间。3. 资讯推送助手从 0 到 1 的核心实现3.1 先把“抓资讯”做成一个独立 Skill整个助手我把它拆成了三个 Skillfetch_news负责采集summarize_news负责总结push_digest负责推送。这样拆的好处是职责单一任何一个环节出了问题只需要替换或修改那一个 Skill。先说fetch_news。它的功能不是简单地把几个 RSS 源抓回来而是要处理编码、去重、提取链接和发布时间这些脏活。我定义 Skill 时的描述大致是从给定的资讯源列表中获取最新条目返回结构化列表每条包含标题、链接、发布时间和正文摘要。OpenClaw 的 Skill 一般由一个 YAML 描述文件和对应的脚本/提示词组成。我的做法是给这个 Skill 配了一个简单的 Node.js 脚本负责真正发起 HTTP 请求和解析内容Agent 负责根据自己的判断决定访问哪些源、如何处理异常。这种“脚本干活、模型决策”的模式是我后来觉得最舒服的搭配纯靠模型去写正则和抓取太不可控了纯靠脚本又失去了 Agent 的灵活性。我维护的资讯源是放在一个 JSON 文件里的[ { name: 少数派, rss: https://sspai.com/feed, category: 效率 }, { name: 开源中国, rss: https://www.oschina.net/news/rss, category: 开发者 }, { name: InfoQ 中文, rss: https://www.infoq.cn/feed, category: 技术管理 } ]你完全可以按自己的关注领域替换这些源。注意有些站点不提供 RSS这时候可以用 RSSHub 这类公共服务生成订阅源或者直接把网址配置成爬取地址让 Skill 内的脚本先抓取 HTML再用简单的正文提取规则去掉导航、广告、页脚这些噪音。3.2 定时触发从手动调用到 Cron 调度资讯抓取和推送逻辑跑通之后最关键的一步就是定时触发。OpenClaw 里给 Skill 加定时任务本质上就是配置一段 Cron 表达式。我的需求是每天早上 8 点推送所以我配置了schedule: 0 8 * * *第一次配置完等第二天早上跑结果发现推送时间比预期晚了整整 8 个小时。排查了很久才发现OpenClaw 容器/服务内部使用的时区是 UTC而我人在东八区。解决办法有两种一是在全局配置里指定时区二是在 Cron 表达式里直接加上时区偏移。我建议用第一种因为如果你有多个任务都去手动计算时区偏移很容易算错。timezone: Asia/Shanghai配置完记得重启 OpenClaw 服务。实测下来把时区写对之后定时触发的准确度是没问题的。定时任务的另一个问题是“重复触发”。Agent 框架如果出现崩溃重启可能会把没跑完的任务重新触发一次结果就是你早上收到两条一模一样的推送。我在后面会专门讲去重方案这里先记住凡是涉及“定时”的任务必须考虑“幂等性”也就是同一个任务执行多次结果也应该只有一次真正推送。否则自动化越成功打扰人的程度越高。3.3 推送渠道选择与配置邮件、钉钉和自定义 Webhook资讯整理好后推送到哪里我实际试过几条路这里把优缺点摆一下。邮件最省事只要配置 SMTP 就行但邮件的存在感低很容易被淹没在收件箱里。钉钉/企业微信机器人消息实时性强适合每天早上扫一眼我最终主力用的是这个。自定义 Webhook如果你有自己的服务端或者用 Server酱之类的工具也能做到手机推送。最终我选择了“钉钉群机器人 邮件兜底”的组合。配置推送 Skill 时你需要把机器人的 Webhook 地址和加签密钥写进 Skill 的环境变量里不要直接写在代码中。一个典型的推送 Payload 大概是这样{ msgtype: markdown, markdown: { title: 每日资讯摘要, text: ## 今日技术资讯\n\n### 开源中国\n- 标题一内容摘要\n- 标题二内容摘要\n\n### 少数派\n- 标题三内容摘要 } }在 Skill 里我让 Agent 把 summarize 的结果直接转换成这个 Markdown 格式然后调用脚本 POST 到 Webhook 地址。这样推送出来的效果比我手动拼文本好看很多。4. 稳定运行才是重头戏日志、守护进程与推送去重4.1 日志分级没有日志的 Agent 等于盲跑Agent 类应用有一个特点它执行动作的路径不是完全确定的同一份输入每次运行走的分支可能不一样。这就意味着你不能像调试传统脚本一样靠单步复现来排查问题只能靠日志回放。我给 OpenClaw 配置了三级日志体系运行日志OpenClaw 自己的输出记录何时触发、执行了哪个 Skill、模型调用的耗时。Skill 日志每个 Skill 内部记录关键节点比如抓取到了几条资讯、摘要生成了多少字、推送 HTTP 状态码。推送回执推送接口返回的 JSON 里通常有错误码这些信息我会额外落一份到本地文件里。排查问题时我最常用的命令是openclaw logs --tail 50如果发现某个 Skill 没有按预期工作第一件事永远是去看 Skill 日志而不是去猜模型是不是“变笨了”。大部分异常其实都有明确的技术原因比如 RSS 源返回 403、推送内容超过钉钉机器人单条消息长度限制、模型连续二次调用超时等等。把日志按小时归档出问题往回查就很快。4.2 自动重启与健康检查让定时任务不因进程崩溃而中断OpenClaw 作为一个长时间运行的服务必然会有崩溃的时候。我自己遇到的情况是WSL2 偶尔被 Windows 更新重启Ollama 服务没跟着起来导致第二天早上 Agent 找不到模型连接整个推送任务直接失败。解决方案分两层第一层把 Ollama 和 OpenClaw 都注册成 systemd 服务设置开机自启。WSL2 内执行sudo systemctl enable ollama sudo systemctl enable openclaw第二层写一个健康检查脚本每隔 5 分钟检查一次各服务是否存活如果挂了就自动拉起。这个脚本也可以检查模型的 API 是否能正常响应curl -s http://localhost:11434/api/tags /dev/null echo ollama ok || sudo systemctl restart ollama你还可以用 systemd timer 或 crontab 来循环执行这个检测脚本。别小看这一步很多人的 Agent 部署完能跑但是跑不了几天就悄无声息地停了多半就是没做进程守护。4.3 推送去重与摘要折叠避免重复轰炸定时推送最让人烦的事情不是不推而是重复推。资讯源本身更新频率不高但 RSS 的更新时间不稳定同一个链接可能在两次抓取中都出现如果不去重用户第二天早上看到的就是前两天推送过的旧闻。我在fetch_news里维护了一个本地 SQLite 数据库记录每条资讯链接的哈希值。抓取到新条目后先查一下哈希是否已存在存在就直接跳过。过期数据定期清理只保留最近 7 天的。摘要折叠是另一个体验优化的点。如果当天资讯很多全推出去会刷屏。我让summarize_news给所有条目生成一个“今日重点”列表最多 5 条其他内容折叠成一个简短列表今日共 12 条资讯以下为重点 1. ...... 2. ...... 3. ...... 其余 7 条见完整日报。这样既保证信息不遗漏又不会让推送显得太啰嗦。5. 常见问题与故障排查链路按现象定位根因5.1 提示“无法安全验证”时先检查系统时间和 CA 证书如果你部署 OpenClaw 时遇到“无法安全验证”这类提示先不要慌这通常不是你的配置写错了而是环境层面的证书或时间问题。我做过的排查顺序是检查系统时间date。如果时间和真实时间偏差超过几分钟TLS 证书校验就会失败因为证书的有效期校验依赖系统时钟。WSL2 偶尔会出现时间漂移尤其是从睡眠状态唤醒后。检查 CA 证书更新系统证书包sudo apt install ca-certificates -y sudo update-ca-certificates。检查是哪个环节在报错换一个更新源或者临时切换成国内可用的镜像地址绕开被安全策略拦截的更新通道。注意如果企业内网有 SSL 拦截很多工具都会报同样的错这种情况下直接使用内网指定的内部源反而更省事。我自己遇到这个报错的根因是系统里装了多个版本的 Node.js证书路径被污染了。用 nvm 重新安装 LTS 版本并确认 PATH 无误后问题消失。所以建议你排查时把“Node 相关组件的证书读取路径”也列入重点怀疑对象。5.2 wsl --status 显示环境不健康时如何修复很多人按教程装完 WSL2运行wsl --status却发现状态不对。最常见的两种异常默认版本还是 1或者某个发行版没有正确初始化。我的处理方案wsl --update wsl --set-default-version 2 wsl --shutdown然后重新进入发行版。如果某个发行版卡在初始化状态考虑直接注销重装别心疼里面的环境早重装早省心。还有一个小技巧在 PowerShell 里执行wsl --list --verbose看每一发行版的实际版本号确认你要用的那个显示的是 2。如果 WSL 终端里运行命令明显变慢优先检查你挂载的是不是 Windows 文件系统路径。比如你在/mnt/c/xxx下运行 OpenClawIO 性能会差很多把项目整体放到 Linux 文件系统内比如~/openclaw-workspace速度会明显提升。5.3 API 连接失败、模型响应超时的根因定位OpenClaw 连不上 Ollama 时错误信息通常指向连接超时。先手动测试curl http://localhost:11434/api/tags如果无响应说明 Ollama 没有正常启动或者它绑定的端口不是 11434。检查一下 Ollama 的启动日志确认它确实在监听。如果配置了远程模型 API就测一下你能不能用其他工具正常请求该 API很多时候问题出在网络策略或密钥权限上。模型响应超时则不太一样多半是提示词太长或并发请求太多。我遇到过模型明明能跑但 Agent 一次调用生成了一个超长列表推理时间暴增导致任务整体超时。解决办法是在 Skill 描述里加一句“输出摘要不超过 300 字”并设置更合理的请求超时时间。5.4 反复出现的坑时区、端口占用、日志膨胀和密钥泄漏最后汇总几个我实际过程中反复踩过的坑希望你别在同样位置跌倒现象实际原因解决办法定时任务晚 8 小时容器时区是 UTC在配置里显式设置Asia/Shanghai启动提示端口被占之前运行的实例没关干净kill $(lsof -t -i:PORT)后重启磁盘空间快速增长日志只追加不轮转配置 logrotate保留最近 30 天Skill 环境变量泄漏到日志调试时打印了完整配置统一用脱敏工具处理再写日志密钥泄漏这个我要多说一句。OpenClaw 的 Skill 会读取环境变量如果你在调试时把包含密钥的配置打印到了终端或日志里一旦这段日志被分享出去等于把推送权限交到了别人手上。我在配置里统一用SECRET_前缀命名敏感项并写了一个脚本自动扫描日志目录发现疑似密钥就立刻清掉。6. 再往前走一步多 Skill 协作与并发推送的取舍6.1 把采集、摘要、推送拆开之后改动成本明显下降我一开始图省事把抓取、摘要、推送写在一个 Skill 里后来发现每次微调都很痛苦。比如我想把摘要风格从“要点式”改成“一句话点评式”就得整体重新测试因为采集和推送逻辑也被裹在里面。拆开以后职责边界非常清楚fetch_news只负责返回结构化数据不关心摘要格式。summarize_news只负责把结构化数据变成摘要文本不关心数据从哪来。push_digest只负责把摘要文本推送到指定渠道不关心文本是谁生成的。这样你完全可以给summarize_news换一个更强的模型或者给push_digest增加一个新的通知渠道完全不影响另外两个 Skill。这种模块化的好处短期看只是“代码整洁”长期看就是“可维护性”。6.2 并发场景下的限流与队列如果你的需求不只是每天早上推一次而是每小时都要跑一轮并发问题就来了。OpenClaw 可以同时跑多个定时任务但底层模型服务的并发能力有限尤其是本地 Ollama 跑小模型时两个任务同时请求会让推理排队导致延迟激增。我的做法是给推送任务加了一个简单的信号量控制同一时间最多只允许一个summarize_news任务在跑其他任务排队等待。实现方式可以在 Skill 脚本里用一个锁文件if [ -f /tmp/summarize.lock ]; then echo summarize already running, skip this round exit 0 fi touch /tmp/summarize.lock trap rm -f /tmp/summarize.lock EXIT捕获锁之后如果检测到已有任务在跑直接跳过这一轮而不是排队堆积。因为资讯推送晚 10 分钟问题不大但堆积几轮之后一次性发一堆消息用户体验极差。6.3 后续可以扩展的方向搭建完这个定时资讯推送助手之后我又陆续给它加了不少能力把摘要内容同步生成一份 Markdown 文件归档到本地、对接语音合成服务做成早间语音播报、根据关键词自动筛选高优先级资讯单独推送。现在回头看OpenClaw 这类框架的真正价值在于它把“调用模型”这件事变成了 Agent 能力的一部分你可以灵活组合各种工具构建出非常个性化的自动化工作流。它不像传统脚本那样要求你预判所有分支而是给了你一个可以在运行时做决策的机制。最后分享一个我实际操作中的小技巧给定时任务加一个“手动触发入口”不要只依赖 Cron。因为在调试阶段你不可能每次等到第二天早上 8 点才能验证推送效果。我是在 OpenClaw 里额外注册了一个push_digest_now的 Skill随时可以手动跑一次全流程。等确认没问题了再放心地交给定时调度。这种“先手动验证、再自动执行”的习惯能让整个搭建过程减少至少一半的试错时间。