Hermes Cron记忆机制：让定时任务从“金鱼”进化成“实习生”

周一你配好了一个每天早上 8 点跑数并生成摘要的定时任务，周二一查结果，它把昨天跑出来的数全忘了，分析结论也没接上，等于每天晚上都失忆一次。这就是典型的“金鱼型”定时任务：每天都在执行，但从不记得自己做过什么。而 Hermes 做 Cron 定时任务时，最大差异恰恰在于它自带一套记忆机制——把任务从只会重复执行的“金鱼”，变成能积累经验、越干越顺的“实习生”。这篇文章我会围绕 Hermes Cron 记忆机制，拆解它到底怎么设计、状态存在哪、如何跨任务执行流转，以及我们实际配置和排障时最容易踩的坑。

如果你在用 Hermes 跑定时任务、做自动化脚本或 Agent 工作流，又不想让每次触发都从头开始，这篇文章适合你。就算你只是对“怎么给定时任务做记忆”这个工程问题感兴趣，也可以参考里面的分层思路和排查方法。

1. 从「金鱼」到「实习生」：定时任务失忆的本质

1.1 为什么大多数 Cron 任务执行完就「归零」

大部分定时任务框架的触发模型很直接：Cron 时间一到，启动一个进程或拉起一个执行实例，跑完收工，相关资源全部释放。内存里的变量、对象、会话上下文，随着进程退出一起消失。哪怕你这个进程是常驻的，只要任务内部没有主动把数据写进文件或数据库，第二次执行时同样拿不到第一次的任何信息。

用大白话说，这就是“金鱼记忆”——7 秒前的事，转头就忘。很多人在单次任务里写逻辑写得行云流水，一到“昨天执行到哪了”“上次报错的记录是什么”这种跨天需求，就发现无从下手，因为任务本身没有记忆载体。

这跟很多人对定时任务的直觉是相反的。大家总觉得“我昨天跑过一次，今天再跑，任务应该知道我昨天干了什么”，但绝大多数 Cron 实现就是不知道。它不是不想记，是设计上就没给你记。

1.2 记忆机制到底改变了什么

带记忆的定时任务和不带记忆的定时任务，差别不是“多存了个变量”，而是整个执行模型都变了。我整理了一个最简单的对比。

举两个我实际见过的例子。

第一个是数据同步任务。普通写法是每天凌晨全量拉取，数据量大了以后根本不现实。如果任务能记住“上次同步到哪一条记录”或“上次拉到的数据水位线”，第二次执行就可以只拉增量，这个 checkpoint 就是记忆机制的最小形态。

第二个是日报生成任务。每天早上自动跑业务数据并生成一份摘要。没有记忆时，今天的摘要从零开始写，跟昨天的摘要之间没有任何承接；有记忆时，它知道“昨天已经分析过哪些问题”“哪个遗留项还没关闭”，今天生成的内容就能自然延续，而不是像两个互不相识的人各写各的。

1.3 “实习生”这个比喻到底准确在哪

用“实习生”比喻带记忆的定时任务，不是因为实习生一定比金鱼强，而是因为实习生具备两个关键特征：第一，他会把做过的活记下来，第二天知道接续；第二，他会犯错——会记错、会记串、会不知道什么时候该忘掉旧经验。

这意味着记忆机制不能只做“无限累积”。如果一个定时任务把每一次执行的记录全部堆着不清理，第二次执行还能看，跑到第 500 次的时候，历史记忆可能比本次数据还大，模型加载上下文都费劲，并且旧经验会污染新判断——我们后面会专门讲“旧记忆污染”这个现象。

所以，一套能用的记忆机制，必须包含三件事：能往记忆里写、能把记忆读出来用、能按策略去更新和遗忘。Hermes 的 Cron 记忆机制在这三点上都有对应设计，下面我按层次拆开讲。

2. 记忆的分层架构：会话记忆、任务记忆、全局记忆

2.1 会话记忆是单次执行里的“工作台”

会话记忆（Session Memory）指的是本次任务执行过程中产生的短期上下文，包括当前对话的历史、模型调用链、工具返回的结果、中间变量等等。一次 Cron 触发就是一个会话，会话内的记忆保证了任务在“这一次运行”里能连续思考，不会每调一次模型就忘掉前面的上下文。

但它解决不了跨次问题。会话结束，短期上下文默认就没了。很多人误以为“我的智能体能记住对话内容，定时任务肯定也能记住”，其实不是——那个记忆只在会话生命周期内有效。Cron 任务每次触发都是新会话，如果只有会话记忆，那它还是一个每天失忆的金鱼。

2.2 任务记忆是“实习生的工作笔记”

任务记忆（Task Memory）是跨执行的关键，也是本文的重点。它记录一个定时任务在多次执行之间需要保留的状态，通常以结构化形式持久化存储，常用的字段包括：

{ "task_id": "daily_report_8am", "last_run_at": "2025-06-10T08:00:00+08:00", "last_status": "success", "result_summary": "昨日订单总量 12,847，环比下降 3.2%，库存预警 3 个 SKU", "checkpoint": "binlog_offset: 283749201", "attention": ["库存预警SKU: SKU-1024", "待跟进供应商: 华东仓"] }

这段笔记什么时候写？我的建议是：任务正常结束前必须写一次；如果中途异常退出，也要尽量写一条失败状态和失败位置，否则下一次执行连“上次失败了”都不知道。

任务记忆的关键特性是按任务隔离。daily_report_8am 的笔记不会混到 data_sync_2am 的笔记里，每个任务有自己的工作笔记。

2.3 全局记忆是可跨任务检索的“知识库”

除了按任务隔离的任务记忆，Hermes 还有一层全局记忆。这层记忆不是按任务隔离的，而是把执行过程中沉淀出的可复用结论存入知识库，其他任务可以通过语义检索的方式召回。

我举个典型场景：任务 A 每 5 分钟监测线上接口状态，某天发现“下单接口连续 3 次超时，疑似网关抖动”；任务 B 每天早上生成运维报告，它能通过全局记忆检索到“下单接口不稳定”这条结论，并写进当天的报告里。如果没有全局记忆，任务 B 只能看到自己的执行数据，没法引用任务 A 沉淀下来的发现。

全局记忆和任务记忆的定位差异很大：任务记忆是“我的笔记”，按任务隔离、必须携带、精确读取；全局记忆是“团队知识库”，按内容检索、跨任务复用、只召回语义相关的部分。实际项目里如果只有一个定时任务、十几行逻辑，不接全局记忆也完全没毛病；一旦任务多、结论要互相引用，全局记忆的价值才会显现出来。

2.4 记忆在两次执行之间如何流转

把三层记忆串起来看，一次带记忆的 Cron 执行完整链路是这样的：

1. Cron 触发，Hermes 启动一次新的任务会话；
2. 会话初始化阶段，先读取该任务的任务记忆（工作笔记）；
3. 如果需要跨任务知识，再从全局记忆里做一次语义检索，召回相关结论；
4. 把“任务记忆摘要 + 全局记忆召回结果 + 本次触发数据”一起组装进执行上下文；
5. 模型推理、调用工具、执行动作，过程中使用会话记忆保存中间状态；
6. 执行结束前，把本轮结果摘要、checkpoint、状态写回任务记忆；
7. 有价值的可复用结论，按策略写入全局记忆；
8. 会话销毁。

看这个流程就明白了：普通定时任务的输入只有“本次数据”，Hermes 带记忆的定时任务输入是“本次数据 + 上次总结 + 相关历史结论”。这就是“实习生”和“金鱼”在运行机制上的本质差别。

3. 记忆存在哪、怎么存：从状态文件到向量索引

3.1 最基础的任务记忆载体：本地状态文件

任务记忆最朴素的落地方式，就是给每个任务维护一个状态文件。路径一般在一个固定的记忆目录下，比如用任务 ID 或任务名做文件名：

hermes/memory/tasks/daily_report_8am.json hermes/memory/tasks/data_sync_2am.json

文件内容就是我上面给到的那种 JSON 结构。每次任务开始读这个文件，结束后覆盖写。优点是非常直观、可排查、可手动修复；缺点是并发写容易互相覆盖，而且随着执行次数增加，文件里不能只塞一条“最新结果”。所以更稳的做法是写入时带上版本号或时间戳：

{ "memory_version": 42, "updated_at": "2025-06-10T08:00:00+08:00", "payload": { "last_status": "success", "result_summary": "...", "checkpoint": "..." } }

读的时候先看 memory_version，再决定要不要信任这份记忆。版本书写是有实际意义的——任务代码升级后，旧版记忆可能跟新逻辑不匹配，这时候版本号能帮你直接丢掉旧记忆。

3.2 为什么长期记忆要用向量检索而不是直接匹配

全局记忆如果只靠关键词搜索，基本没法用。原因是自然语言表达太灵活了：今天任务 A 写的是“接口延迟升高”，明天任务 B 想查“服务响应变慢”，字面上完全对不上，但语义是同一个事。关键词匹配的结果就是召回率极低，知识库形同虚设。

向量化解决的正是这个问题。记忆写入时，先把文本转成一串高维向量，存进向量索引；检索时把查询也转成向量，按语义距离找相近内容。这样“接口延迟升高”和“服务响应变慢”能够映射到相近的向量空间，任务 B 就能召回任务 A 沉淀的结论。

在实际工程里，这段“向量化 + 相似度检索”的环节通常不是你自己实现的，而是 Hermes 内部集成的记忆存储模块帮你完成的。你要关心的主要是两个参数：一是召回阈值，阈值太高召不回东西，阈值太低会召回过期无关内容；二是每条记忆的保留时间，后面在遗忘机制里细说。

3.3 遗忘机制：TTL、压缩和覆盖写

记忆不是越多越好，设计时必须考虑遗忘策略。我用了三个策略，分别对应三个动作。

Memorize（写入）：只在任务产生关键结论时写入记忆，例如状态变化、异常告警、checkpoint 推进。不要事无巨细全写，否则记忆文件会迅速膨胀。

Summarize（压缩）：当一段任务记忆已经积累了多条历史时，触发压缩，把旧记录汇总成一条更短的摘要。比如每天跑一次的日报任务，可以保留最近 7 天的逐日摘要，再往前压缩成一条“上周整体趋势：订单量稳步上升，库存预警集中在华东仓”。

Forget（过期清理）：记忆条目带时间戳或 TTL，超过有效期就不再加载。配置项上大概长这样：

memory: enabled: true policy: summarize ttl_days: 30 max_entries: 50

TTL 设 30 天，就是 30 天前的记忆默认不加载。具体字段名以你所用 Hermes 版本为准，但机制是通用的。

3.4 记忆文件被外部修改的风险

这一节是给你打的预防针。任务记忆文件以纯文本形式躺在磁盘上，就有一个风险：人忍不住去手改。我见过有人手动编辑 JSON 记忆文件，把引号写错，导致整个任务启动时记忆解析失败；还有人把过期结论手动塞回去，结果下次执行立刻被旧结论带偏。

我的建议是：记忆文件面向程序，不要手工编辑。要调整记忆，走配置或者调接口；真要手工修，先备份，再改，改完检查 JSON 合法性，并且在测试任务上验证，不要直接在线上任务上试。

4. 配置实战：让 Hermes 定时任务真正「带记忆运行」

4.1 Cron 表达式回顾与任务定义结构

先花 30 秒把 Cron 表达式对齐一下。标准 5 位表达式从左到右分别是：分、时、日、月、周。Hermes 这类智能体平台一般还支持 6 位带秒的格式，配置前看你平台的说明。

Cron 表达式决定的是“什么时候跑”，记忆配置决定的是“跑的时候还记得什么”。这是两条独立的配置线，很多人只配了前者，从来没碰过后者，任务自然就是金鱼。

4.2 开启任务记忆的最小配置

在 Hermes 里创建一个带记忆的定时任务，核心配置通常包含任务定义、Cron 触发器和记忆模块三块。下面是一个最小骨架示例：

task: id: daily_market_summary name: 每日行情摘要 cron: "0 8 * * *" memory: enabled: true mode: task_only policy: summarize ttl_days: 30 max_entries: 20 inject_mode: auto prompt: | 你是每日行情分析助手。 请结合今天的数据与历次执行记忆，生成今天的行情摘要。 如果记忆中有待跟进事项，请优先说明其最新进展。

enabled: true是开启记忆的开关；mode: task_only表示只启用任务记忆，不启用全局记忆；policy是记忆压缩策略；inject_mode: auto表示让平台自动把记忆片段注入到上下文。

字段名在不同版本里可能有差异，但思路一致。我建议你拿到环境后先新建一个测试任务，把配置字段一个个试，确认了再搬到正式任务上。

4.3 把“上一次的经验”注入提示词的两种方式

开启记忆只是第一步，真正的收益取决于“记忆怎么参与生成”。常见有自动注入和手动引用两种方式。

自动注入模式下，Hermes 会在模型推理前自动组装一个“记忆上下文块”，里面包含上次执行的摘要。你不需要在提示词里写任何模板变量，任务跑起来就自动带记忆。

手动引用模式下，你在提示词模板里通过变量名引用记忆字段，适合需要精确控制记忆位置的场景。例如：

prompt: | 你是数据同步任务。 上次同步进度为：{{ memory.checkpoint }} 本次只同步该进度之后的新数据，完成后更新 checkpoint。

两种模式可以混合用。坦白说，日常大多数场景用自动注入就够了；但如果你的任务逻辑对“上一次状态”极度敏感，比如同步位点、分页游标，建议改成手动引用，把 checkpoint 直接定位到关键步骤里，防止被自动记忆摘要揉碎。

4.4 不同场景下的记忆参数建议

记忆参数不是一套配置走天下，不同任务类型侧重点完全不同。我按实际场景给三组参考配置思路。

数据采集类任务，比如定时抓取接口数据。这种任务最看重 checkpoint，记忆摘要不要太长，能说明“上次同步到哪个位置、成功还是失败”即可。建议把摘要长度控制在一两句，保障 TTL 可以设长一点，因为 checkpoint 过期会导致重复全量拉取。

内容生成类任务，比如日报、周报、市场分析。这种任务最看重 result_summary 和 attention，模型要参考上次结论生成连续判断。建议摘要保留最近 7 到 15 条，超过后压缩成历史趋势描述，TTL 不需要太长。

多步 RPA 自动化任务，比如模拟点击、表单填写、页面抓取。这种任务最怕中途失败后重启找不到步骤，建议每一步执行后都更新一个“当前步骤”字段，配合失败记忆，下次执行可以直接从断点恢复。

5. 排查实录：三类「假性失忆」与完整定位链路

5.1 现象一：配置了记忆，但下次执行还是白纸一张

先别怀疑平台有问题，按下面链路一层层查。

第一步，看执行日志开头有没有“load memory”之类的记录。如果压根没加载，大概率是配置没生效，检查memory.enabled是否被覆盖。

第二步，看记忆文件的路径。很多人把定时任务跑在 Docker 容器里，容器重建后本地文件被清掉，记忆自然归零。排查方法是进入容器看记忆目录是否存在、文件是否在更新，如果文件不存在或还是几天前的，说明存储没有持久化。

第三步，查权限。任务进程对记忆目录没有写权限时，写入会静默失败，表现就是“看起来配了记忆但永远没有记忆”。检查方式和排查普通文件权限一样：看运行用户、目录属主、写权限位。

第四步，查注入是否真的进入了上下文。开启调试日志，把每次任务的输入上下文打印出来，直接看记忆块在不在。这一步能区分“没存下”和“存了但没灌进去”。

5.2 现象二：旧记忆污染新结果

症状是任务跑着跑着，突然把很久之前的结论当成当前事实来用，输出里出现“根据两周前的数据判断现在应该怎样”这类奇怪逻辑。

排查第一步看 TTL。TTL 设得太长，比如一年，那半年前的结论也会被加载，语义检索时还可能因为相似度较高被召回，自然就污染了。

第二步看检索召回阈值。全局记忆模式下，阈值太低会把不相关历史也捞出来。我建议先在测试集上跑几个查询，观察召回内容的相关性，把阈值调到“只召回明显相关”的水平。

第三步看记忆摘要是否过度压缩。summarize 策略压缩时如果丢掉关键限定条件，比如把“上周接口偶发超时”压缩成“接口超时”，下次执行就会当成常态问题，这是非常典型的污染源。真遇到压缩丢信息，可以考虑提高 summary 的最短长度，或把重要字段单独放 attention 区，不参与压缩。

5.3 现象三：多个定时任务共享记忆导致串味

在多任务场景下，另一个高频问题是任务 A 的结论跑到了任务 B 的上下文里，而且看起来还挺合理，实际上风马牛不相及。

第一步，检查任务记忆的隔离键。任务记忆如果只按任务名关联，两个名称相近的任务可能复用同一个记忆空间。我见过“daily_report”和“weekly_report”开了两个任务，结果周报把日报的当日结论当成了长期事实。处理方式就是给每个任务显式指定独立的 memory_key 或 task_id。

第二步，检查全局记忆召回范围。全局记忆本身就是跨任务的，串味是正常现象，问题在于召回是否精确。你可以在检索配置里限定范围，比如只召回指定任务域或指定业务标签下的记忆，减少无关内容混入。

第三步，检查并发写。如果两个任务共用同一个状态文件或同一个数据库记录，后写覆盖先写，任务 B 读到的“上次记忆”实际上是任务 A 的。排查方式看日志里的写入时间戳，如果记忆文件在任务 A 执行期间被改写，说明存在跨任务写同一文件的竞争。解决方案就是各自独立记忆空间，或者引入按任务加锁。

5.4 一套可复用的记忆问题定位方法论

踩过上面三类坑之后，我后来排查记忆类问题基本固定成五步，分享给你参考。

第一步，确认现象类型。是完全没记忆，还是记忆有但不对。这两类问题的排查方向完全不同，前者查存储和注入，后者查过期、污染和并发。

第二步，查“记忆是否写入”。看任务结束阶段的日志，确认本次执行有没有把记忆写成功。这一步能快速排除“根本存不下来”的问题。

第三步，查“记忆是否加载”。看任务启动阶段日志，确认平台有没有读到记忆。读不到，就是路径、权限、持久化的问题。

第四步，查“记忆是否参与生成”。看注入到上下文的记忆块内容，确认模型确实看到了。看不到，就是注入模板和加载逻辑的问题。

第五步，查“记忆是否被错误内容占用”。确认载入的记忆是不是本任务自己的、是不是未过期的、是不是和当前任务相关的。如果记忆文件里混入了别的任务内容，回 5.3 节排查隔离键和并发写。

我在实际排查中感受最深的一点是：绝大多数“假性失忆”不是平台的 bug，而是持久化、隔离和注入这三个环节里的某一个配置没站稳。先把这几层链路摸清楚，再动手改代码或提工单，会省非常多时间。最后祝你配置的定时任务早日从“金鱼”进化成“实习生”，越跑越省心。