# Hermes 24小时工作的秘密：Cron、Gateway 和 Heartbeat
**作者**: Bridge Wang
**日期**: 2026-05-17T09:07:33.000Z
**来源**: [https://x.com/qc777qc/status/2055938260103548970](https://x.com/qc777qc/status/2055938260103548970)
---
> 为什么别人的 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 一口气跑更久，而是让它每次醒来都知道自己是谁、在哪、要接着做什么。
## 相关链接
- [Bridge Wang](https://x.com/qc777qc)
- [@qc777qc](https://x.com/qc777qc)
- [27K](https://x.com/qc777qc/status/2055938260103548970/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [5:07 PM · May 17, 2026](https://x.com/qc777qc/status/2055938260103548970)
- [27.3K Views](https://x.com/qc777qc/status/2055938260103548970/analytics)
- [View quotes](https://x.com/qc777qc/status/2055938260103548970/quotes)
---
*导出时间: 2026/5/18 12:39:59*