别再让 AI 说完就下班了：Hermes 24 小时工作的秘密

全文约 5200 字，阅读约需 9-12 分钟。建议先看上一篇《别让 Hermes 只躲在终端里：把它接进钉钉、飞书、微信和 QQ》。上一篇讲入口，这一篇讲后台连续工作机制。

上一篇我们聊了 Hermes Gateway。

简单说，就是别让 Hermes 只躲在终端里。

你平时在哪工作，就让它去哪儿。

钉钉、飞书、微信、QQ，这些都是入口。

但入口解决完以后，还有一个更狠的问题：

Hermes 能不能不等我叫它？

能不能自己按点醒来，自己看状态，自己推进任务？

说人话就是：

能不能从“你问一句它答一句”，变成“它真的在后台帮你干活”？

最近我刷到 Bridge Wang 发的一篇长文，讲的正好就是这个问题。

标题很直接：Hermes 24 小时工作的秘密。

我看完第一反应是：

这不就是上一篇 Gateway 后面必须补上的那块拼图吗？

很多人现在玩 Agent，都会遇到同一个尴尬场面。

你给它一个任务。

它分析得头头是道。

最后还特别积极地说：

“下一步我会继续推进。”

然后呢？

然后它就下班了。

嘴上说继续，身体很诚实。

这篇文章，我们就把这件事讲透。

为什么你的 Agent 做完一轮就停？

为什么别人的 Agent 看起来可以 24 小时工作？

答案不是模型更强。

答案是：

你没给它接上真正的后台机制。

01 你以为它在继续，其实它已经下班了

先讲一个很典型的场景。

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

这里先说明一句：这篇不聊投资建议，也不教你自动实盘交易。

我们只拿这个场景当例子，讲 Agent 怎么长期工作。

这个长期自治交易员的设想很清楚：

它就像一个刚入职的交易员。

一开始啥背景都没有。

但它可以 24 小时不断学习套利知识、调研市场、整理案例、写策略、做模拟交易、写日记、做复盘。

只有遇到账户、资金、实盘、风控放宽这些关键决策，才来找老板。

其他时候，不要老问。

自己往前推。

听起来是不是很合理？

这不就是很多人想象里的 autonomous agent 吗？

老板只定方向。

Agent 自己干活。

但一跑起来，就会出现一个很赛博打工人的场面。

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

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

听着很积极。

像极了周报里写“下周持续推进”的同事。

问题是，它说完以后，真的就停了。

没有继续收集案例。

没有搭建模拟环境。

没有写文件。

没有更新状态。

啥也没有。

它只是把“我要继续”这句话输出给你看。

然后本轮对话结束。

完了。

这时候很多人的第一反应是：

是不是 prompt 写得不够狠？

是不是模型不够自觉？

是不是得换个更强的模型？

先别急。

问题大概率不在模型。

也不在那句“继续工作”写得不够虔诚。

问题在于，你把“文字承诺”误会成了“后台执行”。

02 问题不在提示词，而在运行机制

一开始，很多人会本能地加 prompt。

比如：

你必须持续工作。
不要停下来等待。
只在关键决策时请求老板。
如果无需老板决策，就继续推进。

这些话有没有用？

有一点。

但不够。

因为大多数 Agent 产品的基本交互单位，是一个 turn。

也就是一轮对话。

用户发消息。

Agent 工作一轮。

Agent 回复。

这轮结束。

系统不会因为它最后写了“我会继续”，就自动再开一轮。

你让它“继续”，它可以在文字里答应你。

但如果没有外部调度器再次唤醒它，下一轮根本不会发生。

这就像你跟员工说：

“你明天早上 9 点继续干。”

但你没给他排班。

没设闹钟。

没开门禁。

没给他任务板。

然后你怪他为什么没来。

这个锅不能全让员工背。

Agent 也是一样。

你以为自己缺的是更强的 prompt。

其实你缺的是一个会按时叫醒它的 runtime。

也就是运行时机制。

这句话很关键。

很多人对 autonomous agent 的误解就在这里。

他们以为“自治”就是让模型自己一直想、一直说、一直跑。

不是。

真正靠谱的长期自治，不是让一个上下文窗口硬撑 24 小时。

那玩意迟早会爆。

上下文会乱。

成本会飙。

状态会丢。

最后变成一个很努力但记忆混乱的赛博实习生。

正确做法是：

把长期任务拆成很多个短周期。

每次只醒来一小会儿。

看一眼状态。

推进一个明确工作单元。

写回状态。

然后等下一次被叫醒。

这才像一个能长期跑的系统。

03 普通对话和长期自治，差别到底在哪？

先看普通对话。

用户发消息
  -> Agent 工作一轮
  -> Agent 回复
  -> 停止

这个模式没问题。

适合问答。

适合临时任务。

适合你说一句，它回一句。

但它不适合长期工作。

长期自治的结构应该是这样：

调度器到点
  -> 新建 Agent session
  -> 读取状态文件
  -> 工作一轮
  -> 写回状态
  -> 等待下次调度

你看，差别非常明显。

普通对话靠“人”触发。

长期自治靠“调度器”触发。

普通对话靠“聊天上下文”记事。

长期自治靠“状态文件”记事。

普通对话结束就停。

长期自治结束以后，会等下一次 heartbeat。

这就是 24 小时工作的核心。

不是让 Agent 一次性跑 24 小时。

而是让它每 30 分钟醒一次。

醒来以后做一小块事。

比如：

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

这玩意儿像什么？

像值班制度。

不是让一个人连续不睡觉干三天。

而是每次交班都看交接记录。

上一班做到哪了？

现在最重要的事是什么？

有没有阻塞？

本班至少推进哪一项？

干完以后，把交接记录写清楚。

下一班接着来。

Agent 长期工作的秘密，就是这套交接班机制。

在 Hermes 里，可以简单拆成四个东西：

Gateway。

Cron。

Heartbeat。

状态文件。

下面我们一个个拆。

04 Gateway：真正的后台闹钟

先说 Gateway。

上一篇我们已经讲过 Gateway。

它不只是把 Hermes 接到钉钉、飞书、微信、QQ。

在长期任务里，Gateway 还有一个关键作用：

它是后台一直醒着的那个人。

很多人创建 cron 任务的时候，会以为任务写进去就完事了。

比如你执行：

hermes cron create "every 30m" "按 HEARTBEAT.md 推进一个工作单元" --name "Work Heartbeat" --workdir /path/to/project

这只是把任务写进 Hermes 的任务列表。

注意，是写进列表。

不是保证它一定会自动跑。

真正负责到点检查、启动任务、创建 fresh agent session 的，是 Gateway。

如果你执行 hermes cron list 的时候，看到类似提示：

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

这句话翻译成人话就是：

闹钟列表已经写好了。

但没有人在后台看表。

你把闹钟写在纸上，不等于闹钟会响。

所以第一步是让 Gateway 真正跑起来。

常用命令是：

hermes gateway install

如果已经安装过后台服务，但状态不对，可以检查：

hermes gateway status

需要启动时再用：

hermes gateway start

新手可以先记住一句：

没有 Gateway，cron 任务能创建，能列出来，但不会自动按点跑。

这就是很多人第一个坑。

任务列表看着挺漂亮。

实际没人执行。

像什么？

像你把健身计划写满一整页。

但你没有去健身房。

计划是计划。

执行是执行。

Gateway 就是那个负责把计划推到执行的人。

05 Cron：别把“30 分钟后”写成“每 30 分钟”

Gateway 是后台闹钟。

Cron 负责定义什么时候响。

这个地方也特别容易翻车。

Hermes 里可以这样创建一个周期任务：

hermes cron create "every 30m" "按 HEARTBEAT.md 推进一个工作单元" --name "Work Heartbeat" --workdir /path/to/project

也可以在聊天里用：

/cron add "every 30m" "按 HEARTBEAT.md 推进一个工作单元"

重点来了。

every 30m 和 30m 不是一回事。

如果你写：

hermes cron create "30m" "提醒我检查任务"

这通常表示：

30 分钟后运行一次。

它不是每 30 分钟运行一次。

你在列表里可能会看到：

Schedule: once in 30m
Repeat: 0/1

这就是一次性任务。

跑完就结束。

如果你想让它循环运行，要写：

hermes cron create "every 30m" "按 HEARTBEAT.md 推进一个工作单元"

every 这个词很关键。

少了它，意思就变了。

很多技术坑就这么朴素。

不是你架构不懂。

不是模型不行。

就是少写了一个单词。

然后你盯着屏幕思考人生。

这也是为什么老麦建议：

新手第一次配置 cron，别上来就搞一堆花活。

先创建一个最小任务。

先确认它能按点触发。

再去搞复杂的长期项目。

别一上来就“我要打造 24 小时自治公司”。

结果第一个任务是 once。

这就像你说要开连锁店，结果店门只开了一次。

06 Heartbeat：每次醒来到底该干什么

Cron 只负责叫醒 Agent。

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

这一点非常重要。

很多人会写一个很空的 cron prompt：

继续刚才的工作。

看起来很自然。

但问题是，cron run 可能是一个 fresh session。

也就是一个新的会话。

它不一定继承你当前聊天窗口里的上下文。

你说“刚才”，它可能根本不知道刚才是谁。

就像你给一个新员工发消息：

“继续昨天那个。”

人家一脸懵。

哪个昨天？

哪个那个？

你是谁？

所以长期任务必须有一个自包含的交接文件。

这个文件可以叫：

HEARTBEAT.md

你可以把它理解成 Agent 的交接班卡片。

里面要写清楚每次被唤醒后必须做什么。

比如：

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

最关键的是这句话：

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

为什么要写这么狠？

因为 Agent 很容易变成“计划大师”。

它醒来以后说：

我分析了当前情况。

下一步建议继续推进。

我将会优先处理最高优先级任务。

然后本轮结束。

听起来很忙。

实际啥也没干。

这就叫赛博开会。

所以 Heartbeat 的核心不是“提醒它想一想”。

而是告诉它：

本轮必须实际推进一个工作单元。

哪怕很小。

也得落到文件、代码、报告、日志、记录里。

不能只写鸡血计划。

07 状态文件：别让聊天记录承担连续性

长期自治还有一个核心问题：

上下文从哪来？

很多人默认以为，Agent 会记得前面所有聊天。

但 cron run 很可能是新的 session。

它不会天然继承你当前窗口里那堆上下文。

就算继承了，也不应该完全依赖聊天记录。

为什么？

因为聊天记录是给人看的。

状态文件才是给系统接力用的。

老麦建议，长期任务至少准备这几个文件：

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

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

比如：

当前阶段：资料收集
主任务：整理套利案例库
已完成：读取 20 篇案例，提取 8 个可复盘样本
当前问题：缺少模拟交易环境

task-queue.md 记录任务队列。

最好分成几类：

NOW
NEXT
LATER
BLOCKED
DONE

NOW 是现在必须做的。

NEXT 是下一步。

LATER 是以后再说。

BLOCKED 是被卡住的。

DONE 是已经完成的。

这样 Agent 每次醒来，不需要重新猜“我现在该干啥”。

它直接读任务队列。

run-state.md 记录上一轮运行留下来的接力信息。

比如：

最近一次运行：2026-05-18 14:00
本轮完成：整理了 3 个新案例
更新文件：case-library.md、task-queue.md
当前 focus：继续补齐案例字段
下一步：抽取每个案例的入场条件和退出条件
是否阻塞：否

这样下一轮 Agent 醒来，就知道自己是谁、在哪、上一轮做了什么、下一轮接着干什么。

这才是长期自治的关键。

不要让聊天记录承载连续性。

要让文件系统承载连续性。

聊天窗口可以关。

session 可以换。

模型可以重启。

但工作状态不能丢。

这才像一个正经系统。

08 一个通用 Work Heartbeat 可以怎么写

这里给你一个通用写法。

不用搞得玄学。

核心就两个字：自包含。

你要让 Agent 每次醒来都能自己恢复现场。

可以这样写：

你是这个项目的长期工作 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/ 写一条简短运行记录。

本轮回复只需要说明：
- 完成了什么
- 更新了哪些文件
- 下一轮继续什么
- 是否需要用户决策

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

因为“刚才”是模糊词。

Agent 讨厌模糊词。

准确说，不是讨厌。

是它会装懂。

你说继续刚才，它可能编一个“刚才”出来。

然后一本正经地往下跑。

这就危险了。

所以你要让它从工作目录和状态文件恢复自己。

每次醒来都重新读。

每次做完都重新写。

这才是长期任务的基本盘。

如果你要配成 Hermes cron，可以先用这种最小命令：

hermes cron create "every 30m" "读取 HEARTBEAT.md，按项目状态推进一个明确工作单元，并更新 memory/ 与 logs/。不要只输出计划。" --name "Work Heartbeat" --workdir /path/to/project

这里的 /path/to/project 要换成你的真实项目路径。

别照抄。

照抄以后报错，然后说 AI 又骗人。

那就有点冤。

09 一开始别搞复杂，先设三个 Cron 就够了

很多人一听长期自治，就开始兴奋。

我要每 5 分钟跑一次。

我要 12 个 Agent 同时工作。

我要它自动读新闻、写代码、做策略、发报告、开飞书文档、推 GitHub。

先冷静。

你不是在造赛博天庭。

你是在搭一个能稳定接力的小系统。

Bridge Wang 的建议很实用：

一开始设置 3 个 cron 就够。

1. Work Heartbeat     every 30m
2. Short Review       every 12h
3. Major Review       every 48h

第一个，Work Heartbeat。

负责持续推进日常工作。

每 30 分钟醒一次，干一小块事，写回状态。

第二个，Short Review。

负责短周期复盘。

比如每 12 小时看一次：是不是一直在堆文件？是不是方向跑偏？有没有阻塞没处理？

第三个，Major Review。

负责阶段性反思。

比如每 48 小时重新看目标、任务队列、当前策略，判断要不要调整方向。

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

Work Heartbeat every 30m

先确认它能稳定接力。

能读状态。

能推进任务。

能写日志。

能在阻塞时停下来问你。

这些都跑通以后，再加 12 小时复盘和 48 小时复盘。

不要一上来就全自动。

全自动听起来很爽。

翻车的时候也很爽。

尤其是涉及钱、账号、权限、文件删除、公开发布的时候。

老麦建议加一条铁律：

涉及资金、实盘、删库、发外部消息、push 公开仓库、改安全配置，一律让人确认。

Agent 可以自动工作。

但不能自动替你承担后果。

10 最小文件结构：别靠玄学，靠文件

一个长期任务，最小文件结构可以这样：

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

不用一开始就搞得很豪华。

这些文件解决的是不同问题。

HEARTBEAT.md：每次醒来做什么。

config/continuity_policy.md：长期运行规则是什么。

比如哪些事情可以自动做，哪些必须问用户。

memory/current-state.md：当前进展到哪了。

memory/task-queue.md：下一步到底做什么。

memory/run-state.md：上一次运行留下来的接力信息。

logs/：每次运行留下简短日志。

你会发现，这套结构一点都不神秘。

甚至有点土。

但它很管用。

因为长期 Agent 最怕的不是不会思考。

是每次醒来都像失忆。

你让一个失忆的人每天继续工作，他能干成啥？

最多每天写一份“我将继续努力”。

所以核心不是把 prompt 写得像圣旨。

核心是把上下文变成可读取、可更新、可接力的文件。

一句话：

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

这句话记住。

很值钱。

11 Git 不应该当实时日志

长期机制跑起来后，文件会频繁变化。

状态文件会变。

任务队列会变。

日志会变。

报告会变。

这时候很多技术人会下意识说：

那我让它每 30 分钟自动 commit 一次，顺便 push 到 GitHub。

听起来很工程化。

但老麦劝你别急。

Git 应该是审计账本。

不是运行日志。

运行日志放 logs/。

状态变化写状态文件。

Git commit 应该记录明确工作单元的完成。

比如一个模块写完了。

一个脚本跑通了。

一份报告成稿了。

一组案例整理完了。

而不是每 30 分钟“自动提交一下”。

比较稳的规则是：

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

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

API key
cookie
token
密码
私钥
个人身份材料
大体量原始数据
高频变化的数据库文件

这里要特别说一句。

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

自动化不是把刹车拆了。

自动化是把重复动作交出去，同时把关键风险拦住。

不要为了“省心”，最后变成“省命”。

那就亏大了。

12 最后问自己四个问题

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

先问自己四个问题。

第一，有没有后台 Gateway？

如果 Gateway 没跑，cron 任务就是写在纸上的闹钟。

第二，Cron 是 once 还是 every？

如果你写的是 30m，它可能只是 30 分钟后跑一次。

如果你要循环，记得写 every 30m。

第三，每次唤醒的 prompt 是否自包含？

不要写“继续刚才”。

要告诉它工作目录在哪，要读哪些文件，要更新哪些状态。

第四，有没有状态文件承接上一轮工作？

没有 current-state.md、task-queue.md、run-state.md 这类东西，Agent 很容易每次醒来都重新做人。

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

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

它不是懒。

是你没给它排班。

也没给它交接本。

更没给它后台闹钟。

长期工作的秘密，不是让 Agent 一口气跑更久。

而是让它每次醒来都知道：

我是谁。

我在哪。

我上次做到哪。

我这次要推进什么。

干完以后，要把接力棒放回哪里。

这才是 Agent 从“会聊天”走向“会干活”的关键一步。

上一篇我们讲了怎么把 Hermes 接进消息平台。

这一篇讲的是怎么让 Hermes 在后台按点醒来。

下一步，如果你真想把它变成自己的长期助手，就别只盯着模型参数了。

先把 Gateway、Cron、Heartbeat、状态文件这四件套跑通。

模型再强，没有运行机制，也只是个会说话的临时工。

机制搭起来以后，它才开始像一个真正能接力的工作搭子。

好了，以上就是本期的全部内容。