Hermes 24小时工作的秘密：Cron、Gateway 和 Heartbeat

为什么别人的 Agent 可以 24 小时工作，而你的 Agent 做完一小轮就停？秘密不是更强的模型，而是一个你没接上的后台机制。

我最近在搭一个基于 Hermes 的长期自治交易员。

设想很简单：它像一个零背景新入职交易员，24 小时不断学习套利、调研市场、整理案例、写策略、做模拟交易、写日记、复盘。除非遇到账户、资金、实盘、风控放宽这类关键决策，否则不要停下来找我。

听起来很合理。

但实际跑起来，我遇到了一个很典型的问题：

它会在一轮任务结束时说：

下一步：继续收集案例，之后搭建模拟交易环境。无需老板决策，继续工作。

然后它就真的不工作了。

嘴上说继续，身体很诚实地停在了当前回合。

问题不在提示词

一开始我以为是提示词不够强。

于是我写：

• 你必须持续工作

• 不要停下来等待

• 只在关键决策时请求老板

• 如果无需老板决策，就继续推进

这些话都对，但不够。

因为大多数 Agent 产品的基本交互单位是一个 turn。它完成本轮回复后，系统并不会自动再发起下一轮。你让它“继续”，它可以在文字上承诺继续，但如果没有外部调度器再次唤醒它，下一轮根本不会发生。

这就是很多人对 autonomous agent 的误解：

你以为你缺的是一个更强的 prompt，其实你缺的是一个会按时叫醒它的 runtime。

别人的 Agent 为什么可以

核心差异在这里：

普通对话： 用户发消息 -> Agent 工作一轮 -> Agent 回复 -> 停止 长期自治： 调度器到点 -> 新建 Agent session -> 读取状态文件 -> 工作一轮 -> 写回状态 -> 等待下次调度

真正的 24 小时工作，不是让一个上下文窗口硬撑 24 小时。

正确做法是把长期任务拆成很多个短周期：

每 30 分钟醒一次 -> 读取当前状态 -> 选择最高优先级任务 -> 推进一个明确工作单元 -> 更新任务队列 -> 写入运行日志 -> 等下一次 heartbeat

也就是说，长期工作的秘密不是“不断说继续”，而是：

Gateway + Cron + Heartbeat + 状态文件。

Hermes 里的四个部件

我最后把机制拆成四层。

1. Gateway：真正的后台闹钟

Hermes 的 cron 任务不是靠当前聊天窗口自己倒计时。

你执行：

hermes cron create …

只是把任务写进 Hermes 的任务列表。真正负责到点检查、启动任务、创建 fresh agent session 的，是 Gateway。

如果你看到：

Gateway is not running — jobs won’t fire automatically. Start it with: hermes gateway install

意思就是：闹钟列表已经写好了，但没有人在后台看表。

所以第一步是：

hermes gateway install

没有 Gateway，cron 任务能 list 出来，但不会自动跑。

2. Cron：按时唤醒 Agent

Cron 负责定义“什么时候叫醒 Agent”。

比如：

hermes cron create “every 30m” “…”

这里有一个坑：

hermes cron create “30m” …

这不是“每 30 分钟运行一次”，而是“30 分钟后运行一次”。

你会在列表里看到：

Schedule: once in 30m Repeat: 0/1

这就是一次性任务。

要循环运行，应该写：

hermes cron create “every 30m” …

或者在聊天里：

/cron add “every 30m” “…”

every 这个词很关键。

3. Heartbeat：每次醒来该做什么

Cron 只负责叫醒 Agent。

但它醒来以后做什么，不能靠临场发挥。

所以我建议给长期任务加一个文件：

HEARTBEAT.md

这个文件像交接班卡片，写清楚每次被唤醒后必须做什么：

1. 读取连续工作规则

2. 读取当前状态
3. 读取任务队列
4. 检查是否存在阻塞
5. 推进一个实际工作单元
6. 更新状态文件
7. 写运行日志

重点是这句话：

不要只输出计划。只要没有阻塞，就必须实际推进文件、研究、代码、报告或记录中的至少一项。

这样可以防止 Agent 每次醒来只说：

下一步我会继续。

然后继续什么都没做。

4. 状态文件：替代聊天上下文

Hermes 的 cron run 可能是一个新的 fresh session。

也就是说，它不继承你当前聊天窗口里的上下文。

如果你在 cron prompt 里写：

继续刚才的工作。

它大概率不知道“刚才”是什么。

所以要把上下文落到文件系统里：

memory/current-state.md memory/task-queue.md memory/run-state.md

current-state.md 记录当前阶段、主任务、已完成事项。

task-queue.md 记录：

NOW NEXT LATER BLOCKED DONE

run-state.md 记录最近一次运行类型、完成事项、当前 focus、下一步、是否被阻塞。

这样每次 cron 新建 session，它都能从文件里恢复上下文。

这才是长期自治的关键：

不要让聊天记录承载连续性，要让文件系统承载连续性。

通用 Work Heartbeat 可以这样写

核心不是复杂，而是自包含。

你是这个项目的长期工作 Agent。工作目录是 /path/to/project。 这是一次 Work Heartbeat。不要只汇报计划，必须实际推进一个工作单元，除非遇到明确阻塞。 先读取：

• HEARTBEAT.md
• config/continuity_policy.md
• memory/current-state.md
• memory/task-queue.md
• memory/run-state.md 然后执行：

1. 检查是否存在阻塞事项。
2. 如果没有阻塞，从 memory/task-queue.md 选择最高优先级任务。
3. 推进一个明确工作单元。
4. 更新 memory/current-state.md、memory/task-queue.md、memory/run-state.md。
5. 如有实质进展，在 logs/ 写一条简短运行记录。 本轮回复只需要说明：

• 完成了什么
• 更新了哪些文件
• 下一轮继续什么
• 是否需要用户决策

注意这里没有写“继续刚才”。

它每次都从工作目录和状态文件恢复自己。

我建议设置几个 Cron

对大多数 Hermes 用户来说，一开始不用搞复杂。

我建议先设置 3 个：

1. Work Heartbeat every 30m

2. Short Review every 12h
3. Major Review every 48h

第一个负责持续推进日常工作。

第二个负责短周期复盘，避免只是在堆文件。

第三个负责阶段性反思，更新方向和任务队列。

如果你的任务只是普通资料整理，甚至可以先只开一个：

Work Heartbeat every 30m

等确认它能稳定接力，再加 12 小时和 48 小时复盘。

最小文件结构

我建议任何长期任务至少有这些文件：

HEARTBEAT.md config/continuity_policy.md memory/current-state.md memory/task-queue.md memory/run-state.md logs/

你可以按项目需要增删，但这几个概念最好保留：

HEARTBEAT.md 每次醒来做什么 continuity_policy.md 长期运行规则 current-state.md 当前进展 task-queue.md 下一步到底做什么 run-state.md 上一次运行留下的接力信息

这几个文件解决的是同一个问题：

Agent 可以失去聊天上下文，但不能失去工作上下文。

Git 不应该当作实时日志

这个机制跑起来后，文件会频繁变化。

但我不建议让 Agent 每 30 分钟都自动 commit，更不建议自动 push。

Git 应该是审计账本，不是运行日志。

比较稳的规则是：

文件写入：随时 本地 commit：一个明确工作单元结束后 push GitHub：低频、确认无敏感信息后

尤其不要把这些东西提交进 Git：

• API key

• cookie

• token

• 密码

• 私钥

• 个人身份材料

• 大体量原始数据

• 高频变化的数据库文件

Cron 让它自动工作，不代表你要让它自动把一切推到远程。

最后总结

如果你的 Agent 做完一轮就停，不要急着骂模型。

先问自己四个问题：

1. 有没有后台 Gateway？

2. Cron 是 once 还是 every？
3. 每次唤醒的 prompt 是否自包含？
4. 有没有状态文件承接上一轮工作？

四个答案都对，它才真的有可能 24 小时工作。

否则你只是在跟一个很听话、但每次说完话就下班的 Agent 聊天。

长期工作的秘密，不是让 Agent 一口气跑更久，而是让它每次醒来都知道自己是谁、在哪、要接着做什么。