聊天窗口每次对话从零开始——没有记忆，没有上下文积累。 Agent Harness 如何让 AI 在下次对话中依然记得你是谁、你的偏好、你上次聊到哪了？
人类的记忆不是一维的。Agent 的记忆同样需要分层：
| 类型 | 是什么 | 聊天窗口有吗 |
|---|---|---|
| 短期记忆 | 当前对话的上下文窗口 | ✅ 有 |
| 长期记忆 | 用户偏好、项目背景、历史对话摘要——跨 session 持久化 | ❌ 没有 |
| 工作记忆 | 当前任务的 TODO 列表、中间状态、已执行步骤 | ❌ 没有 |
像图书馆：可以存很多书，靠索引找到想要的那本。
每天的事件记入 memory/YYYY-MM-DD.md，核心事实提炼到 MEMORY.md。
检索演进路径：
第一代：FTS 全文检索——本质是关键词匹配 + BM25 排序。问题很明显：用户说"上次那个定价的事"，但记忆里写的是"报价模型：软件61.5万"。"定价"和"报价"语义相近但字面不同 → 漏检，召回率为零。
第二代：嵌入向量检索——每条记忆做 embedding，用户 query 也做 embedding，在向量空间找最近邻。"定价"和"报价"的向量距离很近 → 能召回。
但精确匹配反而不如 FTS——找具体文件名 pricing-v3.xlsx 时，向量检索会返回一堆"关于定价"的内容。
最佳实践：混合检索（Hybrid Search）——FTS + Embedding 两条路都走，合并排序。语义归语义，精确归精确。
像笔记本：内容精选到足够小，直接全塞进上下文。 上限约 2200 字符，零检索开销，零遗漏——但必须持续维护，删旧增新。
| 维度 | OpenClaw | HERMES |
|---|---|---|
| 存储策略 | 大量记录，按日期归档 | 精炼蒸馏，控制总量 |
| 检索策略 | 主动检索（FTS/Embedding） | 全量注入（不需要检索） |
| 权衡 | 可以存很多，但检索可能遗漏 | 零遗漏，但容量有限 |
| 类比 | 图书馆（书多，靠索引） | 笔记本（内容精选） |
实际工程中，OpenClaw 用 Qdrant 做向量存储，4096 维 embedding。 4 个 agent 工作区的所有会话记录已灌入，语义召回效果显著——"定价"→"报价"这类问题能正确召回，"竞品分析"能关联到"市场竞争"相关记录。