夜雨聆风做 AI 产品时，很多人一谈到 Memory，就容易先去看技术选型——向量库、embedding、RAG，这些概念对从业者来说并不陌生。但真正动手时，最先卡住的往往不是技术，而是另一个问题：哪些信息值得保留、什么时候该出现、出现时能不能信得过。
同样都叫 Memory，但教学产品关心的是学生总在哪类题上卡住，coding Agent 关心的是这个 repo 怎么构建和测试，个人助理关心的是今天上午刚定下的安排，客服 Agent 关心的是用户刚刚表达过的不满。拿同一套记忆设计去套用所有产品，形态可能完整，但体验还是会错。
所以 Memory 不适合先当成一个通用模块来做。不如先看它在你的产品里到底解决什么问题：减少用户重复自我介绍？让 AI 能延续昨天的工作？保存项目里的局部规则？把对话中出现的事实抽出来给系统用？还是长期形成对用户状态的理解？下面几种模式没有高低之分，也不是升级路线——但这不是做得越精细就越好。产品真正要解决的问题不同，Memory 的形态也会完全不同。
一、用户画像和对话搜索：稳定信息进上下文，历史事实按需查
最常见的一类 Memory，是把历史分成两层。少量稳定画像在启动时直接进上下文，完整历史则留在可搜索的地方，需要证据时再查。画像决定的是默认回答方式和背景知识，对话搜索负责回到过去，找具体发生过什么。
画像这一层要尽量克制，只放变化少、复用高、并且能被用户审查的信息，比如长期身份、常用技术栈、回答风格偏好、固定项目背景、常用路径、工具环境里的稳定约定。「最近在写一篇 Agent Memory 的博客」可以放，但「昨天改到了第三节」「上午定了方案 B」这种具体进度就不行——这类信息变化太快，放进画像几天就会过时，还是放在工作记忆里更合适。
画像从哪来？自动和手动可以共存。消费级产品基本只能靠自动——很少有人愿意开聊之前先填一张「关于我」的表；开发者 Agent 更需要显式文件，因为工程环境、工具链、安全边界都得能审查。理想情况是两边都要：系统自动发现候选记忆，再由人或 Agent 确认，最后写进稳定上下文。
Claude 偏自动总结，系统从历史对话里提炼长期偏好，用户可以去设置里看和改。注意 Claude 的 Chat Search 要和画像记忆分开看：画像把长期历史蒸馏成默认上下文，Chat Search 是回溯时做语义搜索找证据——两条路径，一条默认影响回答，一条按需出现，刚好就是这个模式的两层。Hermes 偏显式可控：USER.md 放用户偏好和沟通风格，MEMORY.md 放环境事实、项目约定、工具技巧和踩坑记录，会话开始时整体进系统提示。
这种设计很适合做产品的第一步个性化。你不想每次都重新解释自己是谁、喜欢什么语气、在做什么项目；产品也不可能把所有历史都塞进 Prompt。留一份稳定画像，再给历史证据留个搜索入口，两层各管各的。
二、时间分层：今天、昨天和当前任务需要单独放
很多时候，连续性问题并不是偏好问题。系统知道用户喜欢简洁回答，也知道用户在做 AI 产品，但不知道昨天那篇博客改到了哪一版，不知道上午拍板了哪个方案，也不知道一个分析做到一半停在了哪里。问题出在最近工作状态没有地方放。
这类信息太新，也太具体，变化太快，不适合直接写进长期画像。它也不适合只躺在聊天记录里等搜索——用户问「昨天说到哪了」「上午那个决定是什么」的时候，系统需要一个最近工作区，从所有历史里现搜现拼，既慢又不稳定。
所以这一层最自然的做法就是按日期记工作笔记：今天和昨天自动加载，更早的走搜索，配一个定期蒸馏把值得长期留的部分写进长期记忆。时间本身就是一种组织方式，文件格式只是载体。对一个天天用的助手，你最常问的就是「昨天说到哪了」「上午那件事怎么样了」「上次你提醒我的安排是什么」——几乎没人真的需要「帮我找一个语义相似的片段」。
工作记忆的原则其实很简单：短期但重要的信息先放这里，不要急着写进长期记忆。长期记忆应该是蒸馏出来的，不能把每天的噪音都灌进去。只做画像的系统记得「用户喜欢直接回答」，但不知道「昨天我们正在改一篇博客」；只能搜全量历史的系统，每次都得从旧会话里现找，很慢也不靠谱。
最需要工作记忆的是天天陪你的 AI：个人助理、行政助理、研究助理、写作协作、项目推进。你会很自然地问「昨天说到哪了」「今天还有什么没处理」「刚才那个决定是什么」。产品要是只记长期偏好，或者只能搜全量历史，聊几句连续性就断了。
OpenClaw 的 daily notes 是目前做这个模式做得最认真的：长期有 MEMORY.md，每天有 memory/YYYY-MM-DD.md，今天和昨天的笔记自动加载，更早的走 memory_search，可选的 dreaming 再定期把短期信号蒸馏进长期记忆。反过来看 Hermes：上下文工程做得很强，系统提示、工具约束、画像、记忆、会话搜索、当前任务上下文分层追加——但单看时间连续性，Hermes 缺的恰恰是这层中期记忆。
这层也不能变成流水账。当天发生的事可以先记下来，但必须有清理机制：临时状态完成后就该消失，值得长期保留的再进 MEMORY.md。否则 daily notes 只是把上下文污染从长期记忆挪到了最近记录里。
三、项目上下文记忆：重点是作用域
coding Agent 需要的 Memory 经常围着项目转。一个 Agent 进到陌生 repo，通用编程知识已经够用，真正缺的是这个项目自己的知识：怎么构建、怎么测试、哪些命令不能跑、哪个目录有特殊约定、团队长期形成了什么习惯、之前踩过哪些坑。
项目记忆里最重要的设计，是作用域。全局用户偏好、仓库规则、子目录约定、某次调试留下的经验，不能混在一份大文件里。一个 monorepo 里，前端、后端、infra 的测试方式和代码风格可能完全不同。路径级的记忆比全局记忆可靠，因为它不容易被错误泛化。
这类记忆也很适合由人来直接维护。团队共识、架构决策、安全边界、发布流程，本来就该写清楚，让模型从聊天记录里猜这些规则，风险很高。对开发者工具来说，手写的项目说明并不落后，很多时候它就是最重要的 Memory 入口。
Claude Code 的 CLAUDE.md 就是这个思路：根目录写仓库级规则，子目录写更具体的约定，Auto Memory 再把 Agent 工作中发现的构建命令、调试经验、架构笔记补进去。人写规则和边界，Agent 沉淀经验和踩坑记录，两者应该分清楚。
有一个地方要留意：项目记忆文件提供的是上下文，不是强制约束。它能影响模型行为，但无法保证模型一定遵守。强制边界得靠 hook、权限控制、沙箱、CI、代码审查这些系统机制。把规则写进 Memory，只是让 Agent 更容易按项目习惯工作，但并不等于安全问题已经解决。
四、可管理的记忆记录：当记忆需要被程序稳定处理
前面几种 Memory 大多可以用文本文件表达：画像、每日笔记、项目规则、经验总结。文本的好处很直接——人能看，模型也能看，想补充一类信息，就是多写几行。很多场景下，这已经够了。
但有些信息不能只停留在原始对话里。客服 Agent 和用户聊了几轮，用户说「以后通知我用邮件，不要用短信」。这句话如果只埋在聊天记录里，下次另一个 Agent 接手就只能靠搜索找回来。搜「通知方式」不一定能命中「用邮件，不要短信」；命中了，也还要判断这句话是不是最新的、是不是适用于当前业务。
这时候可以把这句话抽成一条可管理的记忆记录：例如它是一条偏好记录，内容是用户更希望用邮件而不是短信通知；这条记录归属于某个用户或应用，来自某一次对话，产生时间是那一天，当前仍然有效。不必一上来就套英文术语，可以把它理解成「从对话里抽出来、可以被系统查询和管理的记忆记录」。
但别因此就觉得一定要上一套很重的结构化系统。Markdown、JSONL、YAML、SQLite 里的文本字段，其实都能被程序读写。结构化的价值在稳定性：字段清楚，过滤更快，权限更好做，冲突检查更容易，批量清理和审计也更方便。
但 Schema 也有代价——它会把当前对业务的理解固定下来。产品早期还在变，字段定得太细，后面大改时会遇到迁移、兼容、旧数据解释、检索逻辑重写这些问题。所以早期可以只保留少数字段：归属、作用域、类型、内容、来源、时间、状态。等查询、权限、冲突管理真的需要了，再把实体关系、置信度、版本、权限模型补上。
轻量条目解决的是「这条信息能不能被稳定找到和管理」，更重的结构化事实网络解决的是「这些事实之间能不能被连接起来」——项目管理 Agent 需要知道 Alice 在 5 月 3 日提出的约束影响了里程碑 M2，Bob 后来改了方案，这几件事之间有关系。单条记忆不够用时，才需要实体、时间、关系和来源组成一张网。
不管轻量还是重量级，这些管理问题都应该排在检索前面。这条记忆属于谁、来源是什么、多久没被验证了、和旧条目是否冲突、用户能不能改能不能删——这些向量检索一件都干不了。缺了这些管理，记忆记录只是把上下文污染换了一种形式。
五、对用户的理解：事实和推断分开放
前面几类记忆主要回答「发生过什么」。但有些产品需要的不只是记录，而是理解：这个用户现在处在什么状态，通常怎么表达，什么时候需要直接结论，什么时候需要一步步解释。
教学助手是典型例子。它不只需要知道学生做错过哪些题，还要逐渐发现学生在哪个推理步骤上容易卡住，适合先看例子还是先看概念，最近几次是不是从「不会」变成了「会但不熟」。客服助手也类似——不只要知道用户提交过什么工单，还要感知用户是不是已经被重复解释搞烦了。教练、陪伴、学习类产品里，这种长期理解会直接影响体验。
这里可以用更简单的方式理解。系统先保留原始对话；等一轮对话结束后，后台再做一次整理：哪些是用户明确说过的事实，哪些只是这次对话的摘要，哪些是系统根据多次互动形成的判断，哪些只适合影响当前这一轮回复。等助手要回答时，它不是把所有历史都翻出来，而是先看这份整理后的理解：这个人现在最在意什么？他需要直接结论，还是需要一步步解释？最近是不是已经被重复说明弄烦了？
这种记忆不只是保存「用户说过什么」，而是持续更新「我对这个人的理解」。它关心的是：这个人通常怎么想、在意什么、怎么表达、现在可能需要什么。跟前面几种模式的关键区别在于，前面的记忆回答「发生过什么」，这一层回答「这个人现在可能需要什么」。
但这也是最容易过度设计的一层。系统对人的理解不如一条明文记录透明，也可能判断错。如果产品没有明确的使用场景，只是因为想「更懂用户」就加入这套机制，最后很可能得到一个成本高、解释困难、也难以调试的黑箱。
这类信息必须和事实分开放。事实是用户明确说过或系统明确观察到的；判断是系统根据互动形成的假设。假设可能错，也可能过期。助手要是把「用户可能时间很紧」当成事实，回答就会变得冒犯；把一次情绪化表达沉淀成长期人格判断，问题更严重。判断类记忆要有依据、可信程度和过期机制，也要能被后续互动推翻——用户明确纠正了，判断就要更新或作废。助手回答前可以参考这份理解，但不能把它当事实库用。
不是所有产品都需要这一层。查天气、做翻译、查资料的工具，价值不来自长期理解用户。强行建模只会增加成本和风险。判断标准很简单：如果你的产品体验会因为「更懂这个人」而明显变好——学生在同一类题上反复卡住时，系统能主动调整讲解方式；用户已经被重复解释搞烦时，系统能感知情绪变化；长期陪伴中，对人的理解能越来越准——这一层才值得做。否则，前面四种模式已经够用。
回到设计：五组核心关系
上面几种模式看起来不同，但做产品设计时会发现，绕来绕去就是五组关系。
给谁用？ 给模型默认看的，必须短、稳定、低噪音；给 Agent 搜的，可以大，但要有索引和证据；给人审的，必须透明、能改能删；给系统建模用户的，权限和纠错机制要格外小心。读者不同，形态就不同。
活多久？ 至少四种寿命：当前上下文、工作记忆（今天/昨天/手头任务）、长期记忆、归档。很多产品只做了后两种，中间的工作记忆是空的——Agent 要么只记得抽象偏好，要么只能搜全量历史。
是哪种信息？ 事实、偏好、规则、经验、推断、任务状态，可信度和处理方式都不一样。事实要来源和更新时间，规则要优先级和作用域，经验要绑定项目，推断要置信度和过期机制，任务状态做完就清。混在一层里，Agent 迟早把推断当事实、把临时状态当长期偏好。
什么时候写？ 用户喊「记住」当然要写；被纠正、发现稳定偏好、学到项目惯例时，也该主动写；会话结束、上下文压缩前、任务完成后，都是集中写入的好时机。写入越自动越要过滤——难的不只是把记忆取出来用，还有决定什么信息有资格从短期进长期。
什么时候读？ 稳定画像启动时注入，项目规则按作用域注入，今天昨天的笔记默认加载，更早的历史靠搜，复杂事实关系走结构化召回。默认注入要克制，塞多了就全是背景噪音。
几个容易踩的坑
把 Memory 等同于向量数据库。 向量数据库解决的是相似性检索，盖不住完整的记忆架构。它不知道什么该长期保存，不知道事实有没有过期，分不清用户偏好和任务状态，也不知道哪些内容该默认注入。把聊天记录切块全丢进向量库，确实能搜回一些相似片段，但那叫历史搜索，离长期记忆还远。
把所有历史都塞进 Prompt。 这就是上下文污染。Agent 带着一堆无关历史干当前的活，成本上去了，注意力下来了，行为也不可控。Memory 要做的是决定哪些过去值得出现，而不是把过去全部搬进来。
只有长期画像，没有最近工作状态。 个人助手最常见的问题。系统记得你的职业和偏好，却不知道昨天刚做了什么决定。Hermes 和 OpenClaw 的差距就体现在这里——Hermes 的画像和搜索不弱，但缺 daily notes 这层中间记忆，「昨天说到哪了」要靠搜全量历史去拼，连续性反而不如机制简单得多的 OpenClaw。
事实和推断不分。 用户明确说过的、系统观察到的、模型猜出来的，三者可信度不同。推断类记忆如果没有依据、置信度和更新机制，就会一点点污染用户画像。
没有过期和审查。 记忆多不一定好。过期的记忆比没有记忆更危险——它给模型的是错误的确定性：被推翻的结论还留着，三周前写下的「昨天」没人知道指哪天，重复条目互相打架。
OpenClaw 的 Dreaming 和 Claude Code 的 Auto Dream 干的就是这件事，做法略有不同，思路一致。OpenClaw 把蒸馏过程拆成三个阶段（浅睡去重、快速眼动提取主题、深睡加权打分），最终只把通过多轮筛选的条目写进 MEMORY.md，过程留一份人类可读的 DREAMS.md 供审查。Claude Code 更偏清理：合并重复、删掉已被推翻的结论、把相对时间改成绝对日期、把 MEMORY.md 压回启动加载的行数上限。
两者的共同点是：蒸馏和清理由系统自动做，但结果写成人能看懂、能改的 Markdown，而且保留了「什么被留下、什么被丢弃」的痕迹。
不同场景会长成不同形态
这些模式不是一套固定组合，也没有通用答案。
客服系统可能更早需要可管理的记忆记录，因为用户偏好、工单事实、服务状态需要被不同 Agent 稳定读取，也需要权限和审计。coding Agent 通常先需要项目上下文和作用域规则，因为 repo 里的局部知识比用户画像更重要。每天都陪用户推进工作的个人助理，画像、最近工作状态、历史搜索都会用到，但是否还需要用户理解，要看产品价值是不是来自长期个性化。
先想清楚你的产品缺什么，然后挑需要的来做：
• 默认上下文：少量稳定事实、用户偏好、项目约定，启动时进 Prompt。 • 最近连续性：手头任务、今天昨天、没干完的事、刚做的决定。 • 可检索证据：完整历史、旧的 daily notes、文档、日志，要用再搜。 • 记忆记录：从对话里提炼的偏好、事实、决策，确实需要程序处理时再结构化。 • 用户模型：产品真的需要长期个性化时再建。
两条原则。一是按需求定，别按复杂度定——不是做得越精细越好：第一版个人助手有前三块就够了，客服应用可能更早需要轻量记忆记录，只有陪伴、教学、教练类产品才有理由做用户模型。二是为扩展留余地，慎用结构化记忆：Schema 定得越早越细，后面改的成本越高——自由文本加一类信息就是多写几行，结构化存储加一类信息可能要动 Schema、迁移和检索逻辑。结构化应该是管理需求逼出来的，不是提前设计出来的。
实现本身大多不复杂。daily notes 就是几个按日期命名的 Markdown 文件加一个定时任务，记忆抽取就是一段提示词加几个作用域字段，项目规则就是仓库里的一份 Markdown。难的是边界和评估：哪些内容应该进入默认上下文，哪些只在搜索时出现；哪些短期状态可以清掉，哪些值得保留进长期记忆；加了一条 Memory 之后回答有没有变好，蒸馏之后连续性还在不在，旧记忆有没有污染新任务。没有评估，Memory 系统只会越做越凭感觉。
结语
Agent Memory 的目标不是记住一切。记住一切只是把问题推给上下文窗口，让模型自己在噪音里捞重点。更务实的目标是：让 Agent 在需要的时候，看到粒度合适的过去。
五种模式解决的是不同问题。把这些边界分清楚，Memory 才会从一个「存历史」的功能，变成产品体验里真正有用的一部分。好的 Agent Memory 归根结底是一套关于该忘什么、该留什么、什么时候取、信任谁的设计。更复杂的 Schema、更重的存储机制、更结构化的数据管理方式，不一定更好；只有当产品真的需要稳定查询、权限、冲突处理和审计时，它们才是合适的工具。
