记忆系统

有一件事初学者几乎都会想错：他们以为大模型「记得」刚才聊过什么。它压根不记得。每一次 API 请求对模型来说都是人生第一次——你之所以觉得它有记忆，是因为你的程序每次都把之前的全部对话重新念了一遍给它听。这个真相一旦接受，接下来所有问题就都变成了工程问题：对话变长以后念不完怎么办？超过上下文窗口被截断怎么办？昨天的事今天还要记得怎么办？这一节要把这套「外挂账本」从头拆开——为什么必须往外存（有 Anthropic 官方给的最具体理由）、上下文为什么是「有限资源」而不是「越长越好」、Lost in the Middle 到底证明了什么、又没有证明什么（这是中文互联网上错得最普遍的一处），以及怎么用向量检索给 Agent 装一套能长期回忆的记忆，附一段可跑的代码。

先破一个幻觉：模型天生没有记忆

把这件事说得再直白一点：大模型的 API 是「无状态」的。所谓无状态，说白了就是——服务器不替你记任何东西，你这次发过去什么，它就只看到什么。你在聊天界面里看到的「上下文连贯」，是客户端替你做的一件很笨的事：每发一句新话，就把整段历史重新打包发一遍。

用代码看这件事最清楚，一眼就懂：

# 第 1 轮
messages = [
  {"role": "user", "content": "我叫张伟，我对花生过敏。"}
]
# → 模型回："好的张伟，我记住了。"   ← 它其实什么都没记

# 第 2 轮：你必须把第 1 轮整段带上，一个字都不能少
messages = [
  {"role": "user",      "content": "我叫张伟，我对花生过敏。"},
  {"role": "assistant", "content": "好的张伟，我记住了。"},
  {"role": "user",      "content": "推荐一道适合我的菜。"}
]
# → 模型回："建议清蒸鱼，避开含花生的菜。"

# ★ 如果第 2 轮你只发了最后那一句：
messages = [
  {"role": "user", "content": "推荐一道适合我的菜。"}
]
# → 模型回："推荐宫保鸡丁！"        ← 里面就有花生
#   它不是忘了，它是从来没知道过。

这个「每次重念一遍」的机制，是理解本节所有后续问题的钥匙。它直接导出三个必然后果，每一个都是工程上的硬约束：

• 后果一 · 成本随对话长度线性增长第 10 轮要把前 9 轮全发一遍，第 50 轮要把前 49 轮全发一遍。你为同样的开头付了 50 次钱。这就是为什么长对话越聊越贵。
• 后果二 · 迟早会撞上上下文窗口的天花板窗口是一次请求能容纳的 token 上限（§8.3 详细讲过）。对话只要够长，一定会超。超了之后要么报错，要么被截断——被截断意味着最早的内容凭空消失。
• 后果三 · 跨会话完全断片你关掉窗口再打开，之前的 messages 数组没了，模型就彻底不认识你。要做到「昨天说过的事今天还记得」，唯一办法是你自己把它存到数据库里，下次再捞出来塞进提示词。

换成大白话总结：模型不是记忆力差，它是压根没有记忆这个器官。所有你以为的「记忆」，全是你在外面搭的脚手架。相当于那位失忆医生本人没有记忆功能，是整个医院的病历系统在替他记。

为什么必须往外存：一个来自官方的具体理由

「所以要加个外部记忆」这句话很容易说得很空。这里给一个非常具体、来自 Anthropic 官方多 Agent 系统博客的理由，它比任何抽象论证都有说服力：

这个例子妙在哪里？妙在它暴露了「截断」这件事真正的危险之处——被切掉的不是随便某段闲聊，而可能是最关键的目标声明。而且截断通常是从最早的内容开始切，偏偏「我要做什么」这句话总是出现在最开头。

用生活场景说：你去菜市场买菜，出门前想好了「今天做红烧肉，要买五花肉、生姜、冰糖」。结果你在市场里逛了两个小时，看见什么便宜买什么，篮子塞满了，最后发现五花肉忘了买。正确做法是什么？在纸上写一张清单塞进兜里——不管中途看见多少打折的东西，清单永远在兜里，不会被挤掉。

这就是 LeadResearcher 那个动作的全部含义：把目标从「容易被冲掉的短期记忆」搬到「不会被冲掉的外部存储」。这也是本节要给你的第一条实操准则：任何长任务的 Agent，都应该在开工之前把计划落到外部存储里，并在每一轮开头重新读一遍。

业界常见的划分：短期记忆与长期记忆

说白了，这套划分就是把「这次对话里的事」和「跨越很多次对话都要记住的事」分开放。

讲 Agent 记忆几乎所有资料都会先分「短期 / 长期」两类。这里必须先做一个诚实标注：「短期记忆 / 长期记忆」这套二分法在 Agent 领域没有权威论文给出过标准定义，它是业界通行的说法，不是论文结论。你在别处看到有人把它标成某篇论文的分类，那是加戏。

不过这个划分确实好用，因为它对应了两种物理上完全不同的存储方式：

有些资料还会再切出一类叫「工作记忆」或「情景记忆」，划分方式各家不同。我建议你不必纠结名词，抓住三个真正要做的决策就够了：

• 决策一 · 什么必须每轮都带着目标、约束、硬性规则（比如「用户对花生过敏」）。这类信息一旦漏掉就会出严重错误，宁可多花 token 也要每轮带上。
• 决策二 · 什么可以压缩成一句话前面二十轮的来回，往往能压成「已确认用户是 iOS 开发者，正在排查一个内存泄漏，已排除 A、B 两种原因」。这一句话顶两千 token。
• 决策三 · 什么该存起来等需要时再捞大段的文档内容、历史工单、以前的会话记录。这类东西塞进每轮上下文是纯浪费，该放向量库，等相关时再检索。

上下文工程：把上下文当成有限资源

换成大白话：上下文窗口不是一个越塞越好的仓库，它更接近一张办公桌——桌面就那么大，你摊开的东西越多，真正在看的那份反而越容易被压在下面。

这里要引入一个近两年才立起来的概念——上下文工程（context engineering）。它有明确的官方出处：Anthropic 的文章《Effective context engineering for AI agents》，发布于 2025 年 9 月 29 日。

先把这个词当场翻译：提示词工程（prompt engineering，§10 章讲过）关心的是「这一句话怎么写」；上下文工程关心的是「模型眼前那一整块内容里，该放什么、不该放什么、怎么排」。前者是措辞，后者是资源分配。相当于前者是「菜谱怎么写清楚」，后者是「一张只能摆四个盘子的桌子，摆哪四个」。

文章里最核心的一句判断是：上下文是一种有限资源，并且存在边际收益递减。「边际收益递减」这个词听着像经济学，说白了就是：往里塞第一千个 token 带来的帮助，比塞第一个 token 小得多；塞到某个程度之后，再塞不但不涨，反而拖累。

官方给出的解释是「注意力预算」（attention budget）这个说法：模型有一份有限的注意力预算，每一个新塞进去的 token 都在消耗它。这个比喻很好懂——就像你在办公室一边开会一边回微信一边盯着报表，你的注意力总量不变，事情多一件，每件事分到的就少一点。

更硬的原因来自架构层面，官方文章给了两条，都值得记住：

• 原因一 · n 个 token 产生 n² 对关系Transformer 的自注意力要让每个 token 和其他所有 token 两两建立关系（§7.1 讲过）。n 个 token 就有 n² 对关系。上下文越长，模型捕捉这些关系的能力就越被摊薄——不是它变笨了，是同一份能力要覆盖的关系对变多了。
  把这个平方换算成可感知的量：1000 个 token 是一百万对关系；10000 个 token 是一亿对关系。长度涨 10 倍，要照顾的关系涨 100 倍。
• 原因二 · 训练数据里短序列远多于长序列模型是在语料上学出来的，而语料里短文本的数量远远超过超长文本。所以模型对「处理很长的输入」这件事，练得本来就少。好比一个学校里的学生，平时练的都是三百字小作文，突然让他写一篇三万字的报告——不是他不会写字，是这种长度他没练过。

官方还引用了一项来自 Chroma 的研究，术语叫 context rot（上下文腐坏，字面意思是「上下文烂掉」）：随着 token 数增加，模型准确召回信息的能力会下降。

★ 但请注意：这是「性能梯度」，不是「断崖」

这一小节是专门用来防止你把上面那些结论用歪的。因为中文互联网上一个极普遍的说法是：「上下文一超过某个长度，模型就废了」。这是把梯度当成了断崖。

Anthropic 官方文章在讲 context rot 时特别强调了一句限定，原文是 「a performance gradient rather than a hard cliff」——这是一条性能梯度，而不是一道硬悬崖。

这两个词的差别很关键，值得画出来：

误解版（断崖）              事实版（梯度）
准确率                       准确率
 │████████                    │████████
 │████████                    │ ███████
 │████████                    │  ██████
 │████████                    │   █████
 │████████▏                   │    ████
 │        ▏← 一超就废          │     ███
 └────────┴──────► 长度       └──────────────► 长度
  「128k 以内满血，              「越长越吃力，但是
   超一点就完全不能用」            一点一点地下降」

为什么这个区别对你有实际影响？因为它决定了你该怎么做决策。

用生活场景说这件事：这就像开车带人。车上多坐一个人，油耗高一点、加速慢一点，但车不会「多一个人就抛锚」。它是一条平缓变差的曲线，不是一个开关。所以正确的态度是「能少带就少带」，而不是「只要没超载就随便塞」。

★★ Lost in the Middle：它测的是位置，不是长度

接下来这一小节，我认为是本节最该慢慢读的部分——因为它是中文技术文章里出错率最高的一处，而且错得非常一致，说明大家都在互相抄。

先把论文坐标摆清楚：

• 论文《Lost in the Middle: How Language Models Use Long Contexts》（迷失在中间：语言模型如何使用长上下文）
• arXiv 编号2307.03172
• 发表处TACL 2023——这是正式的同行评议期刊（Transactions of the ACL），不是只挂在 arXiv 上的预印本。这一点让它的分量比大多数被引用的「某篇论文」都重。
• 测了两个任务多文档问答（给一堆文档，问一个只有其中一篇能回答的问题）和键值检索（给一大串「键：值」对，问某个键对应什么值）

它的实验做法是这一切的关键，请务必看清：研究者移动关键信息在输入中的位置。也就是说——输入的总长度是固定的，里面的内容也是同一批，唯一被改变的变量是「那条有用的信息被放在开头、中间、还是结尾」。

结论是：关键信息放在开头或结尾时性能最高，放在中间时性能显著下降；而且即使是那些声称支持长上下文的模型，也一样有这个毛病。

把实验形状画出来，误读就无处藏身了：

论文实际做的实验（长度不变，只挪位置）

  实验 A：★ 在最前面
     [★关键文档] [无关1] [无关2] ... [无关19]   → 准确率 高
  实验 B：★ 在正中间
     [无关1] ... [无关9] [★关键文档] [无关11] ... → 准确率 低  ← 就是这里
  实验 C：★ 在最后面
     [无关1] [无关2] ... [无关19] [★关键文档]   → 准确率 高

  ★★ 三个实验的输入长度完全一样！
     变的只有那一份关键文档摆在第几个位置。


很多文章误以为它做的是这个实验（长度在变）

     [★] [无关×5]      → 准确率 高
     [★] [无关×50]     → 准确率 中
     [★] [无关×500]    → 准确率 低
  ✗ 这是「提示越长越差」，论文没有用这个设计得出主结论。

所以必须把两句话分开说，一句是论文说的，一句不是：

为什么这个区分对你有真金白银的价值？因为两种理解会导出完全不同的做法：

• 如果你理解成「越长越差」你会去做的事：拼命压缩上下文、砍掉信息。可信息砍掉了，模型压根就答不了。
• 如果你理解成「中间容易被忽略」你会去做的事：同样这些信息，把最关键的那几条挪到最开头或最末尾。一个 token 都没减少，效果就上去了——这是免费的优化。

这件事有一个特别贴切的生活类比：会议。你在办公室开一个一小时的会，要传达十件事。大家散会后能记住的，通常是最先说的那件和最后说的那件；夹在中间的第五、第六件，第二天问起来没人有印象。那怎么办？解法不是「把会缩短到十分钟只讲三件事」（那七件事还是要办），而是「把最重要的那件放在开头，再在结尾复述一遍」。

落到 Agent 记忆设计上，这条给出三个非常具体的动作：

• 硬性约束放在系统提示的最开头「用户对花生过敏」这种绝不能漏的信息，位置要么最前要么最后，绝不放中间。
• 当前任务目标在每轮结尾复述一遍很多 Agent 框架会在拼完一大堆历史之后，最后再补一句「记住，你当前的任务是：……」。这不是啰嗦，这是利用「结尾位置性能高」这个已被论文证实的特性。
• 检索回来的片段要排序，最相关的放两头如果你检索回了 5 段材料，别按相似度从高到低顺序摆——把第 1 相关的放最前，第 2 相关的放最后，剩下的塞中间。这是 §11.4 讲 RAG 时那条建议的理论依据。

短期记忆怎么管：四种常见策略

打个比方，这四种策略相当于整理冰箱的四种思路：塞不下了，你可以扔最旧的、可以把剩菜合并成一盒、可以只留今天要吃的、也可以拿个本子记下都放了什么。

知道了「上下文是有限资源」之后，第一个要解决的具体问题是：对话越来越长，该扔掉什么？下面四种做法都是业界常见实践（不是论文结论、也不是官方规范，请这样引用）：

关于「摘要压缩」有个坑值得单独说：反复摘要会失真。第一次把 20 轮压成一段，第二次把「那段摘要 + 新的 20 轮」再压成一段，第三次再压……这跟复印件再去复印一样，每一代都损失一点，几代之后细节全糊了。缓解办法是把关键事实单独抽成结构化条目永久保存（比如一个 facts 列表：用户名、过敏、偏好、已排除的方案），摘要只负责叙事部分。

换成大白话：摘要负责「故事讲到哪儿了」，结构化条目负责「有哪些不能忘的死规矩」。两者分开存，死规矩就永远不会在传话游戏中走形。

长期记忆的技术底座：同一套向量检索原理的复用

其实就是把 § 9.2 讲过的那套东西原封不动搬过来用了一遍——本质上就是「把内容变成一串数字，再比谁离得近」。

长期记忆的核心问题是：存了一万条历史信息，这次对话该捞哪几条出来？如果用关键词匹配，用户说「我不能吃坚果」，就检索不到三个月前存的那条「花生过敏」——字面上一个字都不重样。

所以要按「意思接近」来找，这就是 §9.2 讲过的 Embedding（嵌入向量）和向量检索。这里值得单独点明一件事：Agent 记忆用的检索技术，和 RAG 用的是同一套原理。不是两套东西，是同一套原理在两个场景里复用。区别只在于「库里存的是什么」——RAG 存的是文档片段，长期记忆存的是过往对话与结论。

快速回顾一下这套原理，因为它是长期记忆能不能用起来的全部关键。Embedding 说白了就是：把一段文字变成一串数字（一个向量），意思相近的文字对应的向量在空间里也靠得近。比较两个向量有多近，用余弦相似度——说白了就是量两个箭头之间的夹角，夹角小就是意思近：

cos_sim(A, B) = (A · B) / (|A| · |B|)

  A · B  是点积：对应位置相乘再全部加起来
         [1, 2, 3] · [4, 5, 6] = 1×4 + 2×5 + 3×6 = 32
  |A|    是向量长度（模）：各分量平方和再开根号
         |[3, 4]| = √(9 + 16) = 5

结果范围 -1 ~ +1
  +1  完全同向 → 意思几乎一样
   0  互相垂直 → 毫不相关
  -1  完全反向 → 意思相反

两个非常实用的工程结论，直接影响你怎么写代码：

• OpenAI 的 embedding 已归一化为单位长度也就是每个向量的模都恰好等于 1。于是公式的分母 |A|·|B| 恒等于 1，余弦相似度直接退化成点积——省掉两次开根号。在几十万条向量上反复算，这点省下来很可观。
• 对单位向量，余弦相似度和欧氏距离给出完全相同的排序所以你在向量库里选 cosine 还是 L2，Top-K 的结果顺序一模一样。这是很多人纠结半天的伪问题。

下面这个小工具让你亲手拖两个向量、看夹角和余弦值怎么变。建议把两个箭头分别调到「几乎重合」「垂直」「反向」各试一次，你对「相似度 0.82 到底算近还是不近」会形成一个手感——这比读十遍公式管用。

几十万条记忆怎么秒级查完：HNSW

知道怎么比两个向量之后，下一个问题是速度。假设你的记忆库攒到了 50 万条，每条 1536 维。老老实实跟每一条都算一遍点积（这叫暴力搜索），是 50 万 × 1536 ≈ 7.7 亿次乘法。换算成可感知的量：现代 CPU 单核每秒能做几十亿次这种运算，所以一次查询要花零点几秒——单人用还行，几十个人同时用就堵住了。

于是需要索引。今天最主流的算法叫 HNSW（Hierarchical Navigable Small World，「分层可导航小世界」），坐标很清楚：

• 论文Malkov & Yashunin，arXiv 1603.09320，2016 年
• 核心结构多层邻近图——每个向量是图上一个点，和它比较近的若干点之间连边，这样的图叠好几层
• 分层办法每个点用指数衰减的概率决定它最高能出现在第几层。结果是：绝大多数点只在最底层，少数点能爬到高层
• 查询复杂度对数复杂度——数据量从 50 万涨到 5000 万（100 倍），查询代价只增加个位数倍
• 结构上像什么类似跳表（skip list）——一种在有序链表上加「快车道」的经典数据结构

跳表这个类比一说就懂，用地铁来讲：最底层是每站都停的普通线，中间层是只停大站的快线，最高层是只停三四个枢纽的机场快轨。你要从城市一头到另一头，聪明的走法是先坐机场快轨跨过大半个城市，再换快线靠近，最后换普通线走完最后两站——而不是从头到尾坐每站都停的车。

HNSW 的查询就是这个过程：从最高层的少数枢纽点出发，朝着「离查询向量更近」的方向跳；这一层跳不动了（周围邻居都比自己远），就下沉一层，在更密的图上继续跳；一直沉到最底层，得到答案。那个「指数衰减概率」保证了高层点稀少（枢纽就该少）、底层点密集（普通站就该多）——正好是地铁网络的形状。

要记住一句限定：HNSW 给的是「近似」最近邻，不保证百分百找到真正最近的那一条（专业叫法是 ANN，Approximate Nearest Neighbor，近似最近邻）。做记忆检索完全能接受——你要的是「相关的几条回忆」，漏掉排第 4 相关而拿到排第 6 相关的，差别很小。但如果你要做的是「精确查用户 ID 12345 的档案」，那压根不该用向量检索，该用数据库的主键索引。

动手：给 Agent 装一套向量记忆

把上面说的全部串起来。这段代码实现了一个完整可跑的记忆层：写入记忆、按语义检索、拼进提示词。为了彻底透明、不依赖任何框架，检索这里手写成暴力搜索（几千条以内完全够用）：

import json, time
import numpy as np
from openai import OpenAI

client = OpenAI()          # 需要环境变量 OPENAI_API_KEY
EMB_MODEL = "text-embedding-3-small"

# ==================== 记忆层 ====================
class VectorMemory:
    """最小可用的长期记忆：一条记忆 = 一段文本 + 一个向量 + 元数据"""

    def __init__(self):
        self.texts = []        # 记忆原文
        self.metas = []        # 元数据（时间、类型、重要度）
        self.vecs  = None      # 形状 (条数, 1536) 的矩阵

    def _embed(self, texts):
        r = client.embeddings.create(model=EMB_MODEL, input=texts)
        return np.array([d.embedding for d in r.data], dtype=np.float32)
        # 注意：OpenAI 的 embedding 已归一化为单位长度，
        #      所以余弦相似度可直接退化成点积。

    def add(self, text, kind="fact", importance=1):
        v = self._embed([text])
        self.texts.append(text)
        self.metas.append({"kind": kind, "importance": importance,
                           "ts": time.strftime("%Y-%m-%d %H:%M")})
        self.vecs = v if self.vecs is None else np.vstack([self.vecs, v])

    def recall(self, query, k=3, min_score=0.30):
        """按语义相关度召回。min_score 是「宁可不给也不给错」的门槛"""
        if self.vecs is None:
            return []
        q = self._embed([query])[0]
        scores = self.vecs @ q                    # 点积 = 余弦相似度
        # 重要度轻微加权：让硬约束更容易被召回（业界常见实践）
        scores = scores + 0.02 * np.array(
            [m["importance"] for m in self.metas], dtype=np.float32)
        order = np.argsort(-scores)[:k]
        return [(self.texts[i], self.metas[i], float(scores[i]))
                for i in order if scores[i] >= min_score]

# ==================== 组装进对话 ====================
mem = VectorMemory()
mem.add("用户叫张伟，是 iOS 开发者。", kind="profile")
mem.add("用户对花生严重过敏，任何含花生的建议都要避开。",
        kind="constraint", importance=5)        # ★ 硬约束给高重要度
mem.add("上次排查内存泄漏，已排除「图片缓存未释放」和「循环引用」两种原因。",
        kind="episode")
mem.add("用户偏好简短回答，不喜欢客套话。", kind="preference", importance=3)

SYSTEM_TMPL = """你是一个长期陪伴用户的助手。

【必须遵守的硬约束】
{constraints}

【可能相关的过往记忆】
{recalled}

回答时如果用到了记忆，请自然地体现出来，不要机械复述。
再次强调，上面的硬约束不得违反。"""       # ★ 结尾复述，利用首尾位置优势

def build_prompt(user_input):
    hits = mem.recall(user_input, k=3)
    # 硬约束永久固定在最前面，不依赖检索能不能命中
    constraints = "\n".join(
        f"- {t}" for t, m, _ in
        [(t, m, 0) for t, m in zip(mem.texts, mem.metas)]
        if m["kind"] == "constraint") or "（无）"
    recalled = "\n".join(
        f"- [{m['kind']} {m['ts']}] {t}  (相关度 {s:.3f})"
        for t, m, s in hits) or "（没有检索到相关记忆）"
    return SYSTEM_TMPL.format(constraints=constraints, recalled=recalled)

def chat(user_input):
    sys = build_prompt(user_input)
    r = client.chat.completions.create(
        model="gpt-4o-mini", temperature=0.3,
        messages=[{"role": "system", "content": sys},
                  {"role": "user",   "content": user_input}],
    )
    return sys, r.choices[0].message.content

if __name__ == "__main__":
    for q in ["晚上想吃点下酒菜，给我推荐两个。",
              "那个内存问题还有什么方向可以查？"]:
        sys, ans = chat(q)
        print("=" * 60)
        print("问：", q)
        print("--- 实际拼出来的系统提示 ---")
        print(sys)
        print("--- 回答 ---")
        print(ans)

这段代码里有五处是刻意这样设计的，每一处都对应本节讲过的一条原理：

• 硬约束不靠检索，永久固定在最前面「花生过敏」这条绝不能依赖检索命中——万一用户问「推荐个下酒菜」，语义上跟「过敏」不够近，没检索到，模型就可能推荐花生米。凡是「漏了会出严重后果」的信息，一律无条件常驻，不参与检索。
• 结尾又复述了一遍约束这就是利用 Lost in the Middle 的结论：首尾位置性能高。同一条约束在开头和结尾各出现一次，成本几乎为零。
• 检索有 min_score 门槛分数太低的记忆宁可不给。塞一条不相关的回忆进去，比不塞更糟——它会干扰模型，还占注意力预算。
• 重要度参与打分让关键记忆更容易被召回。这属于业界常见实践，不是标准做法，权重大小要自己实测。
• 把相关度分数打印出来调试记忆系统的第一件事永远是看分数。如果最高分只有 0.2，说明压根没检索到，此时模型答错的锅在检索层不在模型。

补一句工程实话：这段代码用暴力搜索，几千条记忆以内毫无问题。上到几十万条再换成带 HNSW 索引的向量库（Faiss、Milvus、pgvector、Qdrant 之类），架构不用改，只把 recall 里那一行矩阵乘法换成库的查询调用。不要一上手就套大框架——自己手写一遍，你会对每一步在干什么有彻底的掌控。

该记什么、该忘什么：比技术更难的那个问题

这一条听着玄，其实就是在问一件很日常的事：什么值得写进本子，什么说过就算了。

技术部分到这儿其实讲完了。但真正让记忆系统好用或不好用的，是一个产品问题：什么值得存？把所有对话原文全存进向量库是最省事的做法，也是最糟的做法——因为库里塞满了「嗯」「好的」「谢谢」这类噪音之后，每次检索捞回来的都是垃圾。

一个可用的分类（这属于业界常见实践，不是标准）：

最后两行是记忆系统最容易翻车的地方，值得单独说。矛盾的记忆比没有记忆更危险。假设库里同时存着「用户项目用 MySQL」和「用户项目用 PostgreSQL」，检索时两条都被捞出来，模型看到互相矛盾的资料，它会怎么办？它不会说「你的记忆自相矛盾」，它会挑一条看起来顺的，然后自信地讲下去。

这就像一本病历上前后写着「青霉素过敏」和「青霉素皮试阴性」，两句都没划掉。医生翻到哪一页就按哪一页开药——这已经不是信息不足，这是信息污染。所以记忆系统必须有「更新」这个动作，不能只有「追加」。

同理，时效性信息不带过期时间是个隐形炸弹：三个月前存的「这周在出差」，三个月后被检索出来，模型就会一本正经地说「考虑到您在出差……」。一条实操建议：凡是句子里有「今天」「这周」「最近」的记忆，写入时一律带上写入日期，并在拼进提示词时把日期一起给模型看——让它自己判断这条还新鲜不新鲜。

关于工程实践的来源标注

本节前后用到了一批工程手法，这里统一做一次来源交代，避免你把它们当成权威结论去引用：

• 可以直接引用的（有明确出处）Anthropic 官方的上下文工程文章（2025 年 9 月 29 日）关于「上下文是有限资源」「注意力预算」「n 个 token 产生 n² 对关系」「训练数据里短序列远多于长序列」「context rot 是性能梯度而非断崖」；多 Agent 博客里 LeadResearcher 把计划写入 Memory 因为超过 200,000 token 会被截断（★该博客发布日期未取得，故不标日期）；Lost in the Middle（arXiv 2307.03172，TACL 2023）；HNSW（Malkov & Yashunin，arXiv 1603.09320，2016）；OpenAI embedding 已归一化为单位长度。
• 属于业界常见实践（不要当论文结论引）「短期记忆 / 长期记忆」这套二分法没有权威论文定义；chunking（切块）策略、rerank（重排）、hybrid search（混合检索）同样没有取得权威一手来源，它们是工程社区的共识实践，不是论文结论也不是官方规范；滑动窗口、摘要压缩、重要度加权、min_score 门槛，也都属于这一类。

为什么要花一整段讲这个？因为在一个演进这么快的领域里，「知道哪句话有出处、哪句话只是大家都这么干」本身就是一种关键能力。把工程惯例说成论文结论，是技术写作里最常见也最有害的一种失真。你自己在团队里做技术决策时也该这样区分——「有论文支持的」和「大家都这么做的」，能承受的质疑强度完全不同。

记忆系统的六个高频坑：一份排查清单

常见误解一次澄清