人工智能AI Agent大模型AI 应用媒体生成【免费下载链接】xiaobei为OPC/中小微企业量身打造的自媒体获客智能体项目地址https://gitcode.com/gh_mirrors/wi/xiaobei点击查看免费下载导读本文以 xiaobeiOpenClaw 特制版中content-producer内容制作 crew 的 HEARTBEAT.md 为切入点系统讲解 OpenClaw 心跳文件机制的工作原理、按需触发型 crew 与定时任务型 crew 的差异以及当 HRBP/用户希望让 content-producer 实现每日定时自动制作视频定时上传队列处理时应当如何在 HEARTBEAT.md 中编排任务清单、并通过 IT Engineer 的 MCP cron 工具落地为真正的定时任务。读完本文你将掌握 HEARTBEAT.md 的编写范式、cron 配置链路、以及内容制作流水线对接定时任务时的关键约束。一、HEARTBEAT.md 是什么OpenClaw 的心跳轮询任务清单在 xiaobei 的 crew 体系里每个 crew 的工作区~/.openclaw/workspace-id/下都存放着一组 Markdown 文件OpenClaw 在每次 agent 运行时将它们注入系统提示从而影响 agent 的行为与记忆。其中编号为 6 的 HEARTBEAT.md 承担着心跳轮询任务清单这一职责agent 在 heartbeat 触发时依照此文件执行周期性检查。从 Workspace Bootstrap 文件机制 的加载规则可以看到它的特殊地位会话类型HEARTBEAT.md 是否加载主会话用户直接发起的对话✓加载全部 8 个 bootstrap 文件子 agent / Cron 会话✗排除减少 token 消耗Heartbeat 会话周期性心跳轮询✓在最小集合基础上额外加载HEARTBEAT.md心跳开启heartbeat.lightContext: true时✓只加载HEARTBEAT.md其余全部排除极致节省 token也就是说HEARTBEAT.md 是心跳会话专属的指令文件只有被配置了心跳的 agent在心跳触发时才会读到它。这也解释了为什么每个 crew 的 HEARTBEAT.md 内容都应当小而精——它只装周期性任务不该放常规工作流内容Crew 自查清单 中明确要求HEARTBEAT.md 只包含必要的周期性任务保持小而精避免 token 浪费。此外文件注入还有硬性大小限制单文件注入最大 20,000 字符agents.defaults.bootstrapMaxChars、所有文件合计最大 150,000 字符agents.defaults.bootstrapTotalMaxChars超出会被截断。因此心跳任务清单必须克制精简这也是理解 content-producer 现有 HEARTBEAT.md 为何如此简短的前提。二、content-producer 的当前定位按需触发型 crew暂无定时任务打开 crews/content-producer/HEARTBEAT.md全文极其简洁# HEARTBEAT — content-producer 定时任务 ## 当前无定时任务 content-producer 为按需触发型 crew暂无定时心跳任务。 如需定时自动发布可由 HRBP 在此配置 - 每日定时制作如每天 9:00 自动制作一条视频 - 定时上传队列处理 当前回复 HEARTBEAT_OK这段内容透露了两个关键事实content-producer 是按需触发型 crew——它不做周期性自驱所有内容制作需求由用户或 main agent 发起当前心跳状态为空转——触发时无需执行任何任务直接回复HEARTBEAT_OK表示存活即可。这与同仓库其他 crew 形成鲜明对比。例如 main 的 HEARTBEAT.md 是一份数百行的凌晨复盘任务清单Step 1 读 published-track 已发布内容 → Step 2 按平台取互动数据 → Step 3 content-calibrator 复盘 → Step 4 用户咨询回复 → Step 5 汇总报告sales-cs 的 HEARTBEAT.md 则是一份主动跟进流程查询到期跟进任务 → proactive-send 发送 → 更新状态机。对比可见回复 HEARTBEAT_OK 是心跳文件的最小可用形态表示该 crew 无周期性职责、仅做存活确认。从配置层面也能印证这一判断config-templates/openclaw.json 中只有mainagent 配置了heartbeat段every: 1d、target: none、isolatedSession: true而content-produceragent 段只配置了skills、subagents、tools、thinkingDefault、reasoningDefault没有 heartbeat 配置块。也就是说content-producer 目前连定时触发都没有接入HEARTBEAT.md 仅作为机制占位存在。三、有心跳的 crew 长什么样HEARTBEAT.md 的编写范式要理解 content-producer 若启用定时任务后 HEARTBEAT.md 该写成什么样最直接的参照是仓库中两份已落地的心跳文件。3.1 范式一main 的多步骤顺序清单main 的 HEARTBEAT.md 展示了顺序内联执行范式——凌晨心跳被拆成 Step 1→5每一步都有明确脚本入口# Step 1查看哪些平台启用了 content-calibrator ./skills/content-calibrator/scripts/cal-toggle.sh --list # Step 2对每条已发布记录取数douyin / xhs / kuaishou / bilibili ./skills/published-track/scripts/fetch-and-update-metrics.sh \ --platform platform --id rowid # Step 3一键扫描待复盘作品 ./skills/published-track/scripts/query-retro-pending.sh --days 3同时该文件前置了大量执行约束包括深夜执行不受时间限制、技术故障时 spawn IT Engineerfire-and-forget 不许sessions_yield、登录失效一律跳过 记录 汇总上报严禁硬行恢复登录、禁止在心跳里自动升级 rubric 或改阈值等。这些约束沉淀了真实事故教训如 2026-06-29 凌晨 Agent 用 CDP 注入 cookie 强造会话导致小红书风控处罚。这告诉我们一份合格的 HEARTBEAT.md 不只是命令清单还要包含失败处理、风控红线与汇报格式。3.2 范式二sales-cs 的到期任务驱动sales-cs 的 HEARTBEAT.md 展示了查询到期任务→逐条处理→更新状态范式# 1. 查询当前到期的跟进任务 ./skills/customer-db/scripts/follow-up-due.sh # 2. 无到期任务则回复 HEARTBEAT_OK 结束 # 3. 对每条到期任务读 context_summary → 生成话术 → proactive-send 发送 # 按状态机更新pending → sent_once → completed ./skills/customer-db/scripts/follow-up-mark-sent.sh --id id --sent-text 消息 ./skills/customer-db/scripts/follow-up-complete.sh --id id --sent-text 消息其中发送失败exit 1→ 跳过本条、不更新状态、下次心跳自动重试以及最多跟进两次pending → sent_once → completed的设计对 content-producer 配置定时上传队列处理有直接借鉴意义定时任务的失败项应该留待下一轮重试而不是阻塞整轮心跳。3.3 模板机制HEARTBEAT_TEMPLATE.mdmain 的 HEARTBEAT_TEMPLATE.md 提供了更一般的配置套路当用户确认某个工作模式后按模板格式将对应模式写入 HEARTBEAT.md原则是只写入用户实际启用的模式不要预填未启用的模式。模板中 Lead Hunting 等模式均包含状态已启用 / 执行参数频率、每次最大量/ 执行调用 XX 技能三段式结构。若 content-producer 要启用定时制作同样应遵循这一启用才写入的原则。四、让 content-producer 定时化从任务编排到 cron 落地的完整链路结合 HEARTBEAT.md 预留的两个配置方向下面给出落地路径这是仓库中 HRBP 配置约定 cron 运维规范的结合推导非现有运行配置。4.1 方向一每日定时制作在 HEARTBEAT.md 中写入类似段落## 每日定时制作已启用 - **执行时间**每天 9:00cron 表达式 0 9 * * *时区 Asia/Shanghai - **任务内容**调用 video-producer 技能走 Stage 0→14 全流程制作一条视频 - **输入来源**brief 由用户前一晚提供或接收 main agent 喂入的 viral-chaser 追爆报告 - **执行**video-producer.sh wrapper 内 exec python3 $SCRIPT_DIR/scripts/子命令.py $随后 spawn IT Engineer 配置 cron。依据 it-engineer 的 MEMORY.md 中的运维规范生产 Gateway 运行中严禁调用pnpm openclaw cron ...CLI 入口会触发重新 build 并写运行中 Gateway 共享的dist/多次连续调用可能导致系统崩溃正确姿势是走 MCPcron工具cron(actionadd, job{ name: content-producer-daily-video, schedule: {kind: cron, expr: 0 9 * * *, tz: Asia/Shanghai}, ... })cron 的增删改查list/get/add/update/remove/run/runs全部走 MCP 工具自 v2026.6.6 起 cron 存储已从 JSON 文件迁移至 SQLite禁止再编辑任何 JSON 文件也不得直接 UPDATE/INSERT/DELETEcron_jobs表会与 MCP 的状态机、job_json冲突。4.2 方向二定时上传队列处理定时上传队列处理本质上与 sales-cs 心跳同构查询待处理队列 → 逐条处理 → 更新状态。需在 HEARTBEAT.md 中定义队列查询脚本、处理步骤、失败重试策略参考 sales-cs 的失败跳过、下次重试约定。4.3 涉及的关键配置点openclaw.json 的 heartbeat 段参考 config-templates/openclaw.json 中 main 的写法为 content-producer 增加heartbeat: {every: 1d, target: none, isolatedSession: true}isolatedSession保证心跳在独立上下文运行、不占主 sessionHEARTBEAT 更新 cron 配置双步走HEARTBEAT_TEMPLATE.md 明确更新 HEARTBEAT.md 配置 → spawn IT engineer 配置定时任务所有已启用任务应在 MEMORY.md「已启用的定时任务」段登记技能密钥路径定时任务所需的环境变量如AWK_API_KEY、VOLC_ASR_*必须写入~/.openclaw/.envstate-dir dotenv因为该文件被每个 openclaw 进程含 cron isolated-agent加载写入 daemon.env / service-env 则只有 gateway 进程继承subagent / cron 子进程拿不到。五、定时自动制作与内容流水线的衔接约束content-producer 的核心生产能力集中在 video-producer 技能。将其接入定时任务时必须正视流水线自带的多重护栏与定时任务的天然冲突——这些是本文基于 AGENTS.md 与 SKILL.md 的源码级推断Brief 确认与无人值守的矛盾AGENTS.md 通用约定Brief 确认前不得干活——任何方向都先把需求整理成 brief发用户确认后再进后续。定时自动制作若要成立必须在 HEARTBEAT.md 中显式写明 brief 来源例如用户前一晚已确认的 brief或main 喂入的 viral-chaser 报告否则心跳会话无人批准 brief流水线会被自身规则卡死在 Stage 0。GATE A / GATE B 两道人肉闸门video-producer 阶段链中Stage 6 后是 GATE A文本闸门脚本分镜机位角色全齐停下发用户审Stage 9 后是 GATE B素材闸门素材齐计划过审发用户看 contact sheet。SKILL.md 明确禁止跳过 GATE A/B 交付呈交摘要后必须结束本轮回复等用户批且批准是逐闸门的。定时任务若跨越闸门要么配置cron(actionrun, runModeforce)人工接力要么把定时任务的范围限定在已批准项目的后续执行段——这是落地每日自动制作时绕不开的设计决策。产物文件存在性即 checkpointSKILL.md 规定每个子命令先查产物文件是否存在、存在则 load 不重生成允许用户手改 JSON 后续跑。这实际上为定时任务提供了天然断点续跑能力心跳若在中途失败下一轮从产物文件恢复无需从头重来。每阶段返工上限与耗时上限每阶段最多返工 3 次、全片最多 3 次 send-back、每阶段 wall-time 默认上限 20 分钟——卡住要报不要反复撞。定时任务应在 HEARTBEAT.md 中写明卡住即跳过该步并在汇报中说明的处理方式参考 main 心跳跳过当前任务继续执行后续步骤不要卡住整个 HEARTBEAT的约束。CP 不做平台发布AGENTS.md 明确发布到抖音/B站/小红书等归 main agent 的各 publish 技能CP 不碰。因此定时上传队列处理中 CP 侧只能负责成片产出与交付物落盘真正的发布动作仍需转交 main agent 的发布技能如 xhs-publish、douyin-publish。六、小结content-producer 的 HEARTBEAT.md 虽然只有寥寥数行但它精准反映了 xiaobei 的 crew 设计哲学按需触发型 crew 的心跳保持最小占位回复HEARTBEAT_OK只有用户确认启用某周期性工作模式后才按模板写入任务清单并由 IT Engineer 通过 MCP cron 工具激活。这一占位-激活两级机制配合 HEARTBEAT.md 的会话级加载规则、token 上限约束、失败兜底与风控红线构成了整个系统定时任务的统一底座。若要让内容制作 crew 从按需走向每日定时只需在 HEARTBEAT.md 中补齐任务清单、在 openclaw.json 中加上 heartbeat 段、再走 MCP cron 添加 job并妥善处理 Brief/闸门/checkpoint 这三条流水线约束即可。进一步阅读Workspace Bootstrap 文件机制、main 心跳范例、sales-cs 心跳范例、HEARTBEAT 写入模板、video-producer 技能、cron 运维规范。赞分享人工智能AI Agent大模型AI 应用媒体生成【免费下载链接】xiaobei为OPC/中小微企业量身打造的自媒体获客智能体项目地址https://gitcode.com/gh_mirrors/wi/xiaobei点击查看免费下载相关推荐Tasmota定时器规则触发机制深度解析Tasmota定时器规则触发机制深度解析 定时器规则触发机制的工作原理 Tasmota固件中的定时器功能是其自动化控制的核心组件之一。系统支持最多16个定时器嵌入式物联网固件智能家居如何用 Kortix 的 cron 触发器让 agent 按定时任务自动运行如何用 Kortix 的 cron 触发器让 agent 按定时任务自动运行 Kortix 的 trigger触发器可以启动一个没有人参与的 session测试开发工具Charticulator用约束交互打造个性化数据可视化的完整指南Charticulator用约束交互打造个性化数据可视化的完整指南 你是否厌倦了千篇一律的图表模板是否曾为无法创建符合自己设计想法的数据可视化而感到沮丧在前端数据可视化上一篇在线画 Mermaid 流程图从粘贴代码到导出分享的完整走法下一篇DLSS版本切换器深度解析如何通过动态库管理解锁游戏性能潜力创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
