https://jiajia.fun/qa/44af65a8-%E6%96%87%E4%B8%AD%E7%9A%84-memory-notes-%E5%92%8C-%E6%8C%89-%E6%97%B6%E9%97%B4%E7%BA%BF%E8%AE%B0%E5%BD%95%E7%9A%84%E5%B7%A5%E4%BD%9C%E6%97%A5%E5%BF%97%E7%9A%84%E5%8C%BA%E5%88%AB%E6%98%AF%E4%BB%80%E4%B9%88-%E6%88%91%E6%B3%A8%E6%84%8F%E5%88%B0%E5%83%8F%E6%98%AF-workbuddy-%E5%92%8C-openclaw-%E8%BF%99%E7%A7%8D-agent-%E5%9C%A8%E5%81%9A%E8%AE%B0%E5%BF%86%E7%9A%84%E6%97%B6%E5%80%99%E9%83%BD%E5%96%9C%E6%AC%A2%E8%AE%B0%E5%BD%95%E5%B7%A5%E4%BD%9C%E6%97%A5%E5%BF%97

# 文中的 memory notes 和 按 时间线记录的工作日志的区别是什么？我注意到像是 workbuddy 和 openclaw 这种 agent 在做记忆的时候都喜欢记录工作日志。他的形态和 transcripts 这种 facts 有点像。还有关注下 hermes 的记忆系统，它好像是有检索会话日志数据库来获取记忆的方式的。

回复 群友 3892 那篇 Anthropic 的文章之前有群友问过，完整解读在这里：https://jiajia.fun/digest/3d9bc42bab3319755bffed14 你这个问题问到了关键点上。先给结论：工作日志和 memory notes 的区别不在于写的时候有没有筛选，而在于记录的对象不同。工作日志记录的是「我做了什么事」，它回答的是时间线；memory notes 记录的是「我学到了什么」，它回答的是知识。前者是叙事性的，按顺序读才知道发生了什么；后者是断言的，单看一条就有意义。 一、工作日志为什么会被误当成带筛选的 transcript 你的直觉是对的：它和 transcript 确实像，都属于事实层。差别在于，transcript 是完整的原始记录，不可能有遗漏；工作日志则是事后的压缩，写的时候已经决定了记什么、不记什么。所以它其实处在中间位置：比 transcript 窄，但比 notes 更接近流水账。 这也是它容易踩坑的地方。日志压缩的是时间线，而不是知识。写「今天重构了 auth 模块，踩了个 token 刷新的坑，最后改成滑动窗口过期策略」这种方式，你一个月后读到，知道了曾经发生过这件事，但并不清楚那条规则是什么，还得回去翻代码。反过来，memory notes 写的是「refresh token 用滑动窗口过期，不要用固定 TTL，原因是并发刷新会互相踢掉」，这条你随时可以直接使用。 更麻烦的一点是日志会不断变长。Anthropic 那篇里，Sonnet 3.7 在 Pokémon 里写了 413 个文件，大部分是「遇到了谁、捡到了什么」这类流水，结果游戏状态一变就全部过期，到第 步往后 17 步里它建了 6 个文件删了 9 个文件，一步游戏都没玩。纯日志形态的记忆就会这样：它越忠实于「发生过什么」，维护成本就越高，而且这些内容大部分是可以重新读回来的。 所以工作日志真正该做的不是当记忆，是当索引。它最有价值的用法是留个入口，标明「X 那天动过」，需要细节时再去原始记录里查。如果把它当成常驻记忆来注入上下文，那就是把所有历史都摊在桌上。 二、Hermes 走的是另一条路：干脆不压缩，直接检索原始记录 我刚去看了它的官方文档。它的记忆系统分成两层，边界很清楚： 一层是 MEMORY.md（2200 字符，约 800 token）和 USER.md（1375 字符），在会话开始时作为冻结快照注入系统提示词。空间很紧，写满时工具直接报错，让它自己合并、删减腾位置。它明确建议：如果你想让 agent 每次都记住某个路径，用 skill 而不是记忆条目；skill 只在相关时加载，不占这 2200 字符。 另一层是 session\_search。所有会话都存在本地 SQLite 里，用 FTS5 做全文检索，返回的是原始消息，不做 LLM 摘要、也不截断，还能在命中的会话里前后翻。成本对比很直白：常驻记忆每轮都要花掉约 1300 token，检索每次约 20ms、零 LLM 成本、按需触发。 这套设计等于承认了：能靠检索可靠地找回内容，就不用花力气去抽象。它和 Anthropic 那种「抽象出 wiki，用链接当地图」是两条反方向的路。 但要注意 Hermes 文档里自己写的一个前提：记忆系统是在「会话结束」那一刻才起作用的。会话太长的后果是，前面提到的记忆机制不会生效，记忆条目被冻结在本会话快照里，本会话写的看不到，所以它让你在任务边界手动用 /new。这一点比实现细节更重要：检索式记忆的成本不在存储，而在你需要一个明确的边界来触发它。在一直连贯的聊天形态下，检索几乎不会发生，agent 会退化成只反复做上下文压缩。 三、把这三种形态排一排 transcript 是原始日志，保真但不可用，要检索才能取；工作日志是压缩后的事实，介于两者之间，方便人看，但容易过期，也容易变成流水账；memory notes 是对未来的预测，最短，也最直接可用，但可能写错，必须靠下层记录打回重写；wiki 和图谱是结构，用于跨文档导航，只在综合类任务上有收益，任务简单时反而膨胀。 所以 Hermes 那种「小常驻 + 检索原始日志」就是：把 knowledge 层的成本转给检索；Anthropic 那种「小常驻 + dreaming 抽象成 wiki」是把成本转给后台算力。前者适合查询密集、问题离散的场景；后者适合需要反复综合同一批材料的场景。 如果换成你更熟悉的口径：工作日志是 ca 的产物，面向过程；memory notes 是 pa 的产物，面向跨会话连续性。ca 记录一次任务的过程有意义，因为它需要可审计；pa 记录一次对话的过程基本没用，因为你从来不问它上周二问了什么，你问的是它现在还记不记得你的偏好。 要不要我接着把 Hermes 的 session\_search 和 Claude Code 那套自动记忆在「什么时候读、什么时候写」上做个对照？那两处差异直接决定检索式记忆和抽象式记忆的取舍。
