https://github.com/LinJinl/CodeLife

这几天在把器灵这个AI Agent的设计重新理一遍，打算针对记忆系统做大更新，因此需要整体梳理一下当前的一些想法，主要探讨 Memory分层/写入策略/检索融合 这条线

对于长期陪伴式的agent，最稳的不是单层记忆，而是五层记忆模型

• 即时上下文
  • 包括本轮和最近几次对话，当前任务目标、当前页面、系统规则，它的作用是保证这次回答接的上话
• 工作记忆
  • 工作记忆是为了完成正在进行中的中短期任务，比如今天正在排查某个审批链bug，这周在读哪篇论文，当前一轮工具调用拿到了什么中间结果，它的特点是高相关，短寿命，任务结束就该清理或者降级
• 长期偏好
  • 存的是用户稳定风格，比如“少分段、高密度、技术内容附带上参考”等信息，会持续影响输出风格
• 技能、洞察记忆
  • 复用价值高的技术结论，比如“写操作审批必须tool + payload hash绑定token”，或者“深度文档生成要先结构后展开并覆盖边界、权衡”，它是未来可复用的方法
• 事件、轨迹记忆
  • 存的是时间性事实，比如哪天收藏了什么文案的那个，哪天排查了什么bug，哪天形成了什么决策

当前的系统中已经设计了一些雏形，比如 ： 对话、偏好、誓约、技能卡、日志、藏经阁等，但是还需要把它们从功能模块升级到记忆层模型

长期记忆设计

这五层里，最容易出问题的是把“什么都存进一个向量库”误当成长期记忆。这么做短期省事，长期必炸。原因很直接：向量检索擅长召回语义相近的信息，但不擅长天然区分“这是稳定偏好”“这是过时事件”“这是高价值技能”“这是临时情绪化表达”。如果把用户一次随口抱怨、一个旧项目上下文、一个过期决定、一个高价值技术原则都混在一起，模型下一次检索到什么就看 embedding 运气，最后器灵会出现两种坏症状：第一，人格和判断不稳定，一会儿像记得你，一会儿又被旧垃圾召回带偏；第二，当前任务被历史噪声污染，本该专注当前问题，却被相似但无关的旧对话强行拉走。所以你后面改器灵，第一条铁律是：长期状态不要只靠语义检索组织，必须有显式结构化记忆。 至少稳定偏好、技术洞察、誓约、日志这几类，都应该有各自独立的数据结构和调用策略，向量检索只作为补充，而不是唯一记忆机制

写入策略

接下来讨论写入策略，真正好的agent不是随时能存，而是要明白什么时候不能存，我们可以给器灵设计四种写入触发

• 显式授权写入
  • 最简单，用户说“记一下”、“记住这个偏好”等，那就直接写，写到对应层
• 规则触发写入
  • 适合高确定性的场景，比如用户明确表达稳定偏好、誓约变更、收藏文档、完成某个长期目标，这类可以即时入库
• 观察延迟写入
  • 比如我说“后续回答不要分太多段”，这是明确偏好，可以立刻存，但是如果只是某一次嫌解释太长，不能立刻稳定偏好，应该先作为observation积累，重复出现后再升级成偏好
• 总结型写入
  • 总结写入适合对话结束或者任务完成后，把高价值的内容提炼成短而稳的结构化记录，而不是把整段原文塞进去，现在系统里已经有 save_preference、save_skill_card、write_note 这些工具，下一步最值得优化的不是“再加一个记忆工具”，而是把何时调用哪个写入工具的规则做成可解释的 policy。这会让器灵从“会记”变成“记得有节制”。

检索策略

器灵什么适合该检索，不该靠每次都搜一遍，也不该靠大模型自己想不想搜，应该要有对应的机制和分类，可以分为三类

• 强触发
  • 该场景是必须查的场景，比如用户问“最近状态”，“上次我们聊到哪里”，“我有哪些誓约”，“我之前总结过这个问题吗“，”我写过相关博客吗“，这些都有明确数据源，应该优先走结构化查询或者定向检索，而不是让模型凭借印象答
• 弱触发
  • 弱触发时可能需要补充历史背景的场景，比如用户说继续上次那个设计思路，或者说按我之前的偏好来，这种情况下可以先看最近上下文和显式偏好，不够再搜历史对话
• 禁止触发
  • 比如用户问一个纯技术问题，当前任务不依赖于用户历史，此时不应该为了显得有记忆强行召回一堆无关记录，检索不是越多越好，而是只有在历史信息能提高当前决策质量时才触发。这点和 RAG 系统一样，真正难的不是检索能力，而是检索克制

此外检索回来之后，很多系统的第二个大坑是不会融合。召回信息不是越全越好，而是要做 context packing。器灵的融合顺序可以参考固定成：系统规则 > 当前用户问题 > 当前任务状态 > 稳定偏好 > 与当前问题直接相关的结构化记忆 > 必要的历史对话片段 > 外部资料。 这个顺序的意义在于，优先保证系统行为和当前任务不被历史噪声压垮。比如用户现在问一个 Anthropic 文档总结问题，这时“你偏好少分段高密度”是相关的，“2026/04/10 你聊过项目结构”就不一定该进上下文。又比如用户问“晨省”，那最近日志和誓约就是高优先级，外部资料反而不重要。后面改器灵时，最好不要把所有召回结果原样堆给模型，而是先做一层memory summarization / packing：每类最多给几条，每条压成结构化摘要，明确来源和时间。这样既节省 token，也降低模型被旧细节带偏的概率。

记忆更新、冲突、衰减机制

没有更新策略，所有的长期记忆系统都会慢慢腐烂，至少需要三种应对机制

• 覆盖
  • 覆盖适合偏好类，比如今天明确说”后续回答不要分太多段，每段要更丰富一点“，他就应该覆盖同类旧偏好，而不是并列堆积
• 合并
  • 合并适合技能类和项目经验类信息，比如同一个审批链token设计的主题多次出现，可以积累成一张不断增强的skill card，而不是生成5张重复卡
• 失效
  • 失效适合事件和临时状态，比如某次”今天在排查bug“任务完成后，就不该高频召回某些只针对特定项目有效的偏好，也应该允许降权

进一步说，我们可以给记忆加两个元属性，confidence可信度和volatility易变性，用户明确授权的写入的偏好，可信度高，通过观察推断的习惯，初期可信度低，临时任务状态易变性高，长期写作风格易变性低

如何做

将上述综述映射到目前项目，可以总结出四个动作

• 给现有记忆实体重新分层标注
  • 现在的 conversation、daily log、preference、skill card、vow、library item，最好都明确属于哪一层、默认何时检索、有效期多长
• 补充统一的memory policy文档
  • 里面至少写清：什么情况下写 save_preference，什么情况下只做 observation，什么情况下写 save_skill_card，什么情况下只记入今日 note，什么时候禁止自动写入
• 做retrieval gating
  • 不是每题都查历史，而是按问题类型映射到记忆源，像你系统提示里那样：问近况先查日志，问誓约先查 vow，问写过什么先查博客/藏经阁，问偏好再查 preference，这个方向已经对了，但可以更系统化
• 做memory packing
  • 把召回结果统一压成“来源 + 时间 + 一句话摘要 + 可信度”，再交给模型用。这样器灵会明显更稳，不容易被冗长历史淹没

核心结论：好的器灵记忆系统，不是“记得多”，而是“分层清楚、写入克制、检索有门槛、更新有规则”。 后面要改进器灵，优先级不该是“继续堆更多 memory feature”，而是先把这四件事做硬：分层、写入策略、检索触发、更新淘汰。 这四件事一旦理顺，后面的偏好适配、技能积累、长期陪伴感、甚至输出质量，都会一起上一个台阶

最小可行改造路线：先改什么，再改什么

建议分三步。第一步，梳理并标注现有记忆对象的层级、生命周期和检索触发条件，先不改存储，只改认知和调用规则；第二步，补写统一的 memory policy，明确什么场景调用 save_preference、save_skill_card、write_note、update_persona_observation，并补“禁止自动写入”规则；第三步，加入 retrieval gating 和 memory packing，让检索从“想起来就搜”变成“按问题类型查固定记忆源，并先压缩后注入上下文”。这节还应说明为什么不建议先做“大一统向量库重构”：因为在 policy 不清楚前，底层重构只会把混乱写进更复杂的基础设施里