3.3 分层记忆实战：写入、检索、遗忘与反思

3.3 分层记忆实战：写入、检索、遗忘与反思

本节摘要：短期窗口与长期库不是两个独立部件，而是一套有分工的记忆系统：写入有门槛、检索有时机、遗忘有策略、反思有周期。本节用一个 MemoryStore 类骨架把四件事串成闭环，并用两个月的助理运营案例展示这套系统上线前后的差别。

前两节分别讲了窗口怎么省、向量库怎么查，本节回答 remaining 的问题：两层的边界上，东西怎么进出？ 写入门槛定错，库会膨胀成垃圾场；没有遗忘机制，过时的记忆会持续污染决策；没有反思，几百条零散记忆永远等不来合并压缩的那天。这四件事对应四个机制，先看骨架再看细节。

MemoryStore：一套记忆系统的骨架

class MemoryStore:
    """短期窗口之外的长期记忆层：写入、检索、遗忘、反思四个入口。"""

    WRITE_POLICY = """
    满足任一条件才值得写入长期记忆：
    1. 用户表达的稳定偏好（"以后报告都用简体中文"）
    2. 环境的持久事实（"我们团队的代码必须过 code review 才能合并"）
    3. 任务的重要结论（"供应商 A 的报价含税、B 的不含税，不可直接比较"）
    单次任务的中间过程、情绪化表达、未确认的猜测：一律不写。
    """

    def write(self, text: str, kind: str, meta: dict) -> bool:
        """写入门槛：先过政策判断，再做语义去重。"""
        if not llm.judge(text, policy=self.WRITE_POLICY):
            return False                                  # 不值得记
        if self._near_duplicate(text, threshold=0.92):    # 换个说法的老条目
            return self._merge_instead(text)
        entry = embed_and_store(text, kind=kind, meta={
            "ts": now(), **meta, "ttl_days": TTL_BY_KIND[kind]})
        return True

    def recall(self, query: str, **kw) -> list:
        """检索时机由调用方决定：决策前、回答前、规划前各查一次。"""
        hits = search_memory(query, **kw)
        return [inject_source(h) for h in hits]           # 带来源与时间回填

    def forget(self):
        """周期任务：过期条目软删除（标记而非物理删，可审计）。"""
        for e in self._expired_entries():
            e.meta["expired"] = True                      # 检索层硬过滤

    def reflect(self):
        """周期任务：把同类零散条目合并成结构化摘要。"""
        for topic in self._cluster_unreflected():
            merged = llm.summarize(topic.entries,
                                   instruction="合并为一条结构化偏好/事实，保留例外情况")
            self._replace_entries(topic.entries, merged)  # 旧条目退役
​

四个方法对应四个决策点，逐一说明设计依据。

写入：门槛比容量重要。长期记忆的敌人不是装不下，是平均化——垃圾条目越多，真正值钱的记忆在检索里越难浮出。WRITE_POLICY 里的三分法（偏好、事实、结论）是实践中留存率最高的口径；判断这一步用便宜模型即可，成本低到可以忽略，却把库的增速压掉一半以上。

检索：时机多于算法。什么时候查比怎么查更影响体验。三个成熟时机：任务开始前查一次背景（用户偏好、项目约束）；决策中遇到事实缺口时查一次（工具没有、库里可能有）；回答输出前查一次关键主张（是否有与记忆冲突之处）。全靠模型自觉决定何时查不可靠，契约里写明这三个时点更稳。

遗忘：软删除加审计。直接物理删除记忆是危险的——删错了无法恢复，也无法向用户解释"为什么它忘了"。软删除（标记 expired，检索层过滤）保留了纠错能力。TTL 按类型区分：偏好类长（数月到永久）、事实类随事实生命周期（项目结束即过期）、任务结论类中等（一到三个月，被反思合并后自然退役）。

反思：从流水账到结构。零散条目的问题在积累三个月后爆发："喜欢简洁"以八种措辞存了八条，检索全回来挤窗口。反思任务按周期（如每周）聚类合并，把八条压成一条带例外的结构化条目。这一步同时也是给记忆"体检"的机会——合并时发现的互相矛盾（用户三月份说偏好邮件沟通，五月份又说别发邮件），正是要提请更新甚至询问用户的信号。

案例：报销助理上线八周的前后对比

背景：某团队给行政助理接上了本章的记忆系统，观察它第五周到第八周的行为变化。

操作与结果：第五周（反思机制刚上线），库里有四百多条条目，助理回答一个问题平均回填五条记忆，其中两条过时（旧版的审批限额）；第六周反思任务跑完，四百条合并为九十条结构化条目，回填降到两条，且 TTL 清理让旧限额彻底不再出现；第八周，助理开始出现"记忆驱动"的主动行为——用户提交一张招待费报销时，它直接引用三个月前的结论"本部门招待费需提前报备"，先提醒再受理。

解读：第八周的表现才是长期记忆的完整回报：不是"记得多"，而是把散落的过去变成当下的判断依据。这份回报的前提取决于两件事——写入门槛挡住了流水账，反思把流水账提炼成了结论。跳过任何一步，记忆库都会滑向"什么都存、什么都想不起来"。

变式：多用户系统里，记忆必须分命名空间隔离（user_id 硬过滤，3.2 节），另设一层"团队共享记忆"（流程、口径类事实），写入权限收窄到管理员——个人偏好与组织事实混库，是多租户场景最常见的隐私事故源。

⚠️ 常见坑：让记忆系统"自动学习一切"。没有门槛的自动写入，三个月后库里的主体不是用户偏好而是聊天寒暄；检索这些内容的成本不高，污染决策的代价却无法估量。

本节要点回顾

• 四机制闭环：写入有政策、检索有时点、遗忘用软删、反思做合并——记忆系统是流程，不只是存储。
• 三分写入法：偏好、持久事实、任务结论值得记；过程、情绪、猜测不配占库。
• 反思是记忆的代谢：周期性合并去重，让库从流水账进化成结构化知识，矛盾在此暴露。
• 隔离先于共享：多用户场景按命名空间硬隔离，组织级事实单独成层、单独管权限。

记忆让智能体"记得住过去"，但面对一个笼统的大目标，它还需要把路拆成一步一步的章法——这就是下一章的主角：规划。