12. Memory 与 Session：长期记忆和历史会话怎么参与下一次任务

这篇解决什么问题

很多 Agent 号称“有记忆”，但记忆到底是什么，经常说不清。

在 Hermes 里，至少要区分三件事：

Memory：长期稳定事实
User Profile：关于用户是谁、偏好什么
Session：过去对话和任务过程

它们进入下一次任务的方式不一样。

Memory 适合放什么

Memory 适合放稳定事实，例如：

用户偏好中文短回复
某个项目使用 Astro
某个知识库默认路径
某类任务的长期约定

不适合放：

今天完成了什么
某个 PR 号
某次临时任务状态
一个很快会过期的链接

这些会污染后续会话。

User Profile 和 Memory 的区别

User Profile 更像“用户是谁”。

Memory 更像“我对环境和工作方式的稳定认识”。

例如：

用户叫勇谋，偏好中文沟通        → User Profile
future-observer-web 是 Astro 站点 → Memory

两者都会影响回答，但用途不同。

Session Search 做什么

Session Search 不是记忆写入。

它是搜索过去会话。

当用户说“上次那个任务继续”或“你还记得我之前做的项目吗”，Hermes 可以通过 session_search 找到历史对话，而不是要求用户重复讲一遍。

这适合找任务过程、决策和历史上下文。

Memory 如何进入上下文

agent/memory_manager.py 会把相关记忆构造成上下文块。

然后在 Agent 构建系统提示词/turn context 时注入。

这意味着 Memory 不是数据库里躺着的文本，而是会真实影响下一次模型调用。

所以写错 Memory 比写错一条普通消息更危险。

上下文压缩和记忆不是一回事

长会话里，Hermes 会做上下文压缩。

压缩解决的是：当前会话太长，模型上下文装不下。

Memory 解决的是：跨会话保留稳定事实。

不要把压缩摘要当长期记忆，也不要把长期记忆当任务进度表。

如果你要改记忆相关能力

先判断目标：

改记忆如何进入 prompt       → agent/memory_manager.py / prompt 构建
改 memory 工具写入规则      → memory tool 相关实现
改 session 搜索             → session_search / state.db 相关实现
改压缩策略                 → context_compressor / conversation_compression

不要把所有跨会话能力都归到一个文件里找。

一个实用原则

判断一条信息该放哪里，可以问：

一周后它还重要吗？

如果重要，可能是 Memory 或 Skill。

如果不重要，只是过程记录，就让它留在 Session 或 Git commit 里。

下一篇看什么

下一篇看 Cron。

Cron 是 Hermes 从“对话式助手”变成“长期自动化系统”的关键能力。