夜雨聆风
OpenClaw 定时任务配置:构建自动持续运行的工作流
摘要
昨天介绍了 5 个围绕 Obsidian 知识库工作的 skill：读知识库、写知识库、论文分析、Kimi CLI 代码分析，以及 Kimi CLI 联网搜索。我整理了 5 个 Agent Skill：把论文阅读、知识库读写和分析探索工作流接起来
今天继续往前走一步：如果这些 skill 只能靠手动触发，它们仍然更像是一组工具；如果把它们接入 OpenClaw 的定时任务，它们就可以变成一个持续运行的知识工作流。
每天早上由 OpenClaw 自动检查论文目录，必要时自动发现新论文，完成 PDF 归档、全文抽取、长篇分析和知识库写入；随后再由另一个定时任务检查笔记质量，并通过 Obsidian 的 Digital Garden 插件把新笔记和相关 Topic/Reference 页面发布到线上：https://graygoo.forestry.md/
本地仍然是 Markdown 和 Obsidian，网页构建与发布交给 Digital Garden（Obsidian 的网页构建与发布插件），OpenClaw 负责把“每天做一次”这件事变成稳定的自动流程。
从 skill 到定时工作流
上一篇文章里的几个 skill 解决的是单次能力问题：
-
agent 能不能读我的知识库。 -
agent 能不能按结构写入知识库。 -
agent 能不能认真分析一篇论文。 -
agent 能不能调用外部 CLI 做辅助分析。 -
agent 能不能把联网搜索变成可核验的资料链。
但知识积累真正难的地方，不是偶尔做一次，而是持续做。
论文阅读尤其如此。每天手动打开 arXiv、筛论文、下载 PDF、让 agent 分析、整理进 Obsidian、再发布到网页，这个流程只要有几个步骤依赖人，就很容易断掉。OpenClaw 的定时任务可以把这个流程拆成两个后台任务：
07:00 论文自动分析07:45 论文笔记质检与发布第一个任务负责“摄入知识”，第二个任务负责“整理并发布”。两者之间留出 45 分钟，是为了给 PDF 下载、文本抽取和长文分析留出缓冲时间。
cron 和 heartbeat 的区别
OpenClaw 里可以做周期触发的机制主要有两类：heartbeat 和 cron。
heartbeat 更像是主会话里的心跳检查，适合做一些轻量提醒，例如对话中顺便检查邮件、天气、待办事项。
cron 更像是独立闹钟，适合做固定时间、固定流程、可能持续较久的任务，例如论文分析、知识库归档、网页发布。
我这里选择 cron，原因很简单：论文分析不是一句提醒，而是一条工具调用链。它会读目录、下载文件、抽取 PDF、写 Markdown、改 frontmatter、调用 Obsidian 命令。如果这些过程都塞进主会话，用户正常聊天时上下文会被大量工具记录污染。所以核心原则是：
轻量提醒，放在 main session。复杂执行，放在 isolated session。只传递行为提示，用 systemEvent。需要 agent 真正做事，用 agentTurn。任务一：每天自动分析一篇论文
第一个核心任务是 daily-paper-analysis。
它每天早上检查一个论文投放目录，例如：
msg-box/reading/如果目录里已经有 PDF，就优先分析这些 PDF；如果目录为空，就根据预设研究方向自动搜索一篇未读论文，下载到目录里，然后进入同一套分析流程。一个简化后的配置如下：
{"name": "daily-paper-analysis","schedule": {"kind": "cron","expr": "0 7 * * *","tz": "Asia/Shanghai"},"sessionTarget": "isolated","wakeMode": "now","payload": {"kind": "agentTurn","message": "请检查 <工作区>/msg-box/reading/ 中的 PDF；如果为空，请围绕 <研究主题列表> 搜索并下载 1 篇未读论文。随后使用论文分析 skill 完成 PDF 归档、全文抽取、长篇分析和知识库写入。成功写入后再删除投放目录中的原始 PDF；如果中途失败，不要删除原始 PDF。","model": "<论文分析模型>","thinking": "medium"},"delivery": {"mode": "none"}}这里有几个关键点。
第一，sessionTarget 使用 isolated。论文分析通常会持续几分钟到几十分钟，而且会产生大量中间步骤。隔离会话可以避免主会话被工具调用历史淹没。
第二，payload.kind 使用 agentTurn。因为这不是“提醒 agent 记得做某事”，而是要求 agent 真正执行一套流程。
第三，自动发现论文时要做去重。最简单的方法是让 agent 先查已有知识库标题、论文链接和文件名，确认没有分析过，再下载新论文。
任务二：检查并发布论文笔记
第二个核心任务是 daily-paper-analysis-report。
它在每天 07:45 执行，负责把刚生成的论文分析从“草稿状态”推到“可发布状态”。这个任务会检查当天新增的论文笔记，通常包括三件事：
-
Frontmatter 是否完整，尤其是 title、Categories、Topics、References。 -
笔记底部是否补了 Topics 和 References 链接，方便 Digital Garden 生成可浏览的知识网络（Digital Garden 当前还不能识别 frontmatter 链接）。 -
是否设置了 dg-publish: true，让 Digital Garden 插件把这篇笔记纳入发布范围。
简化后的配置如下：
{"name": "daily-paper-analysis-report","schedule": {"kind": "cron","expr": "45 7 * * *","tz": "Asia/Shanghai"},"sessionTarget": "isolated","wakeMode": "now","payload": {"kind": "agentTurn","message": "请检查 <知识库目录>/Notes/ 中今天新增的 paper_analysis 笔记。修复 frontmatter title，补齐底部 Topics 和 References 链接，确保 dg-publish 为 YAML boolean true。然后调用 Obsidian Digital Garden 的批量发布命令，发布论文笔记及其关联页面。最后将处理结果追加到 <记忆目录>/YYYY-MM-DD.md。","model": "<发布检查模型>","thinking": "medium"},"delivery": {"mode": "none"}}这里最容易踩坑的是 dg-publish。
Digital Garden 需要的是 YAML 布尔值：
dg-publish: true而不是字符串：
dg-publish: "true"如果通过 Obsidian CLI 设置属性，要确保写入的是 checkbox/boolean 类型。否则看起来 frontmatter 里有 true，但 Digital Garden 可能不会按预期识别。因此，简化后的配置仅仅说明了步骤，如果需要更精确的执行，可以将使用 Obsidian CLI 设置 dg-publish、执行发布的命令直接写在定时任务 message 里，便于任务的精确执行。例如当前 Digital Garden 发布全部笔记命令：
obsidian command id=digitalgarden:publish-multiple-notes为什么用 Digital Garden 发布
我选择 Obsidian 的 Digital Garden 插件，是因为它刚好适合这种“本地知识库，选择性发布”的工作方式。
本地 Obsidian vault 里可以有很多私人笔记、过程笔记和未完成内容，但只有被标记 dg-publish: true 的页面会进入发布流程。这样 agent 可以在本地大胆沉淀知识，发布任务只把整理过的论文分析、Topic 页面、Reference 页面同步出去。
论文笔记不是孤立页面。它通常会链接到若干 Topic，例如某种 agent 架构、记忆机制、推理方法；也会链接到若干 Reference，例如机构、项目、数据集、模型或论文作者组织。
所以发布时最好不要只发布单篇笔记，而是使用 Digital Garden 的批量发布能力，把论文笔记和它引用的相关页面一起发布。否则网页上会出现很多可以点击但不存在的链接。
整个发布链路大致是：
论文分析笔记 -> Topics 页面 -> References 页面 -> Categories 页面 -> Digital Garden 批量发布 -> 线上知识库更新这也是为什么前一天介绍的 knowledge-base-writer 很重要。只要每篇论文笔记一开始就有稳定的 frontmatter 和链接结构，后面的网页发布就会顺很多。如果本地 Obsidian vault 里可以有很多私人笔记，在设置 Skill 和定时任务时需要谨慎，避免非公开笔记带有 dg-publish: true 标签，以及在定时任务 message 中强调对于笔记内容的检查等；更推荐的做法是尽量将非公开笔记与用于发布的笔记进行 Obsidian vault 层面的隔离。
辅助任务：让 agent 记得维护自己
除了论文分析和发布，我还配置几个轻量任务，用来维持 agent 工作习惯。
第一个是记忆主动召回提醒。它每隔几个小时提醒 agent：后续回答问题时，先根据话题搜索 memory 和 knowledge-base，而不是完全依赖当前上下文。
这类任务适合放在 main session，并使用 systemEvent：
{"name": "memory-recall-reminder","schedule": {"kind": "every","everyMs": 21600000},"sessionTarget": "main","wakeMode": "now","payload": {"kind": "systemEvent","message": "后续对话中，请根据话题需要主动检索 memory 和 knowledge-base，将相关背景融入当前上下文。"},"delivery": {"mode": "none"}}第二个是每日日志提醒。每天中午和晚上，让 agent 回顾当前 session 中是否有值得保存的内容，并写入当天的 memory 文件。
这同样适合 main + systemEvent，因为它需要看到主会话里的上下文。
第三个是定期自我提升。每隔几天回顾近期被纠正的问题、工具使用经验和新的工作方法，整理到长期学习记录中。它不直接生产论文笔记，但会让整个自动化流程越来越稳。
一张表总结配置选择
可以把这些任务压缩成一张表：
|
|
|
|
|
|
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
我的判断标准是：
需要影响当前对话行为，放 main。会长时间运行或大量调用工具，放 isolated。只是提醒或注入规则，用 systemEvent。需要实际读写文件和调用 CLI，用 agentTurn。复现时的最小目录结构
为了让这套流程稳定运行，工作区里至少需要有几个约定目录：
<工作区>/ msg-box/ reading/ # 待分析论文 PDF knowledge-base/ Notes/ # 论文分析笔记 Topics/ # 主题页面 References/ # 实体页面 Categories/ # 分类页面 attachment/ papers/ # PDF 归档 memory/ # 每日日志如果你已经在使用 Obsidian，这些目录可以直接放在 vault 里。OpenClaw 负责读写 Markdown，Obsidian 负责本地编辑体验，Digital Garden 负责把标记为可发布的页面构建成网站。
这里的关键不是目录名字必须完全一致，而是任务 prompt、skill 配置、Obsidian vault 和 Digital Garden 发布设置必须指向同一套结构。只要这四者对齐，目录可以按自己的习惯调整。
调试建议
不要一开始就把所有任务都设成无人值守。
更稳的做法是先把 daily-paper-analysis 的 prompt 直接发给 agent 手动跑一次，观察它是否能正确找到 PDF、抽取文本、调用论文分析 skill、写入知识库，并在成功后清理投放目录。
然后再手动跑一次发布任务，检查 dg-publish 是否真的是 YAML boolean，检查 Digital Garden 是否能发布论文笔记和相关页面。
等这两步都稳定后，再把它们放进 cron。由于 Digital Garden 会将库中所有带有dg-publish 标签的笔记进行发布，所以推荐在 skill/cron 中对笔记进行 frontmatter 核查，或者采用更保守的方法：专门的公开库存放发布笔记。
另外，第一次调试 isolated 任务时，最好确认 OpenClaw 的任务日志位置。复杂任务失败时，不能只看最终有没有生成笔记，还要看失败发生在下载、PDF 抽取、frontmatter 修改、Obsidian 命令还是 Digital Garden 发布阶段。
结语
这套配置解决的不是“让 agent 总结一篇论文”，而是“让论文分析变成每天会自动发生的事情”。昨天的 skill 提供了能力：读、写、分析、搜索、核验。
今天的 OpenClaw 定时任务提供了节奏：什么时候分析，什么时候检查，什么时候发布，什么时候记忆，什么时候复盘。
当这两部分接起来之后，知识库就不再只是一个手工整理的 Markdown 文件夹，而会变成一个持续更新的研究工作流：论文进入投放目录，agent 完成分析，笔记进入 Obsidian，Digital Garden 把整理后的内容发布到线上，后续提问又可以回到知识库里检索和复用。