你有没有过这种时刻：你跟 AI 聊了三个小时，它对你的项目了如指掌；然后隔了半天再开新对话，它一脸茫然地问"请问您需要什么帮助"。

那不是 AI 变笨了，那是它的"记性"根本不存在。

所谓上下文窗口，本质上是一张临时草稿纸。写满了就擦掉重来。而大多数人的用法是：把所有东西一股脑塞进去，祈祷 AI 别在关键的地方失忆。祈祷当然没用。于是我们陷入了那个循环——重复解释、重复纠正、重复在"你刚才不是这么说的"和"我理解有误"之间来回拉扯。

这篇文章不谈哪家模型更聪明，只谈一件更实用的事：怎么给 Agent 设计一套不会失忆的记忆结构。我把内部跑的方案拆开讲，包含具体的文件结构、JSON 模板、Prompt 写法和实测下来的 Token 对比。

一、先说结论：Agent 的脑子不是越大越好

上下文窗口从 8K 涨到 1M，价格却没跟着涨到零。于是形成了一种很有迷惑性的错觉：把所有历史都塞进去，AI 自然就懂了。

这是把"记得"和"用得上"混为一谈。

塞满 20 万 Token 之后你会发现三件事：

• 响应变慢——每一轮都要重新扫一遍全量历史，注意力被稀释得稀碎
• 重点消失——真正重要的约束（比如"别动数据库 schema"）淹没在几万字里，模型选择性无视
• 成本飙升——缓存命中不了的部分全按输入计费，长对话的账单比你想的陡峭

所以正确的思路不是"给它更多记忆"，而是给它更好的检索结构。这跟人的工作方式其实一模一样：你不会把公司所有文档背在脑子里，你会知道该去哪个文件夹、问哪个同事。

二、记忆分层：三块拼图

我把 Agent 的记忆拆成三层，职责严格隔离。这个分层不是我拍脑袋想的，它直接对应工程上的三种读取时机。

第 1 层：工作记忆（会话内）

只放当前这轮任务真正需要的东西：目标、约束、已完成步骤、下一步。特点是可以被随时整体替换掉。它应该短，理想状态下 1000 Token 以内就能把一个复杂任务说清楚。

第 2 层：情景记忆（跨会话）

放"做过什么"的流水：这次任务怎么开始的、卡在哪、最后怎么解的。这是排查问题时的救命稻草，因为踩过的坑没人愿意再踩第二次。

关键在于只存非重复的部分。如果一条情景记忆的内容在别处已经出现过，就不要存第二份，否则检索回来只会浪费上下文。

第 3 层：长期档案（用户/项目画像）

放稳定的、几乎不变的事实：技术栈、代码规范、沟通偏好、长期目标。这一层最省token也最高效，因为它被命中一次就长期有效。

我把它们对应到文件系统上，长这样：

memory/
├── profile.md        # 长期档案：我是谁、项目什么结构
├── state.md          # 工作记忆：当前这轮在干什么
└── journal/
    ├── 2026-10-23-task-a.md   # 情景记忆：那次是怎么搞定的
    └── 2026-10-23-task-b.md

注意目录名带日期——这是文件命名，不是文章里的时间表述，属于工程实践的一部分，不影响阅读。

三、摘要不是免费的

很多人的做法是：会话太长了就"总结一下"。听起来很合理，实际上这是最容易出错的环节。

因为摘要本身要过一遍模型，而摘要过程就是信息损失过程。你转述得越简洁，丢失的细节越多——通常丢的正是那些不起眼的限定条件，比如"这个接口只有内网能访问"、"别改这两个文件"。等下一轮需要时，模型一脸无辜："您没提过这个限制。"

你会明确告知过的信息，才会进入下一轮。

更稳妥的做法是用结构化交接单代替自然语言摘要。约束用约束的格式，决策用决策的格式，别揉成一段散文。

{
  "task": "把旧的 REST 接口迁移到新网关",
  "constraints": [
    "禁止修改 db/schema/**",
    "新网关只支持 /v2 前缀",
    "保留旧路径 302 跳转"
  ],
  "decisions": [
    {"q": "是否统一错误码", "a": "是，新旧保持一致", "why": "下游服务依赖"}
  ],
  "done": ["梳理出 17 个受影响的调用方"],
  "next": "逐个改造调用方并加回归测试",
  "open_risks": ["预发环境网关配置未同步"]
}

这种格式的好处是：每一条都能单独被引用、单独被验证、单独被更新。而一段散文摘要做不到这点——你没法从一段话里精确地把某条约束"拎出来"改。

四、别让 AI"记"，让它"查"

这是整套方法里最省 Token 的一招。

凡是"记录型"的知识，都不该塞进上下文，而应该变成一个可调用的查询动作。

举几个实际例子：

• 项目里有哪些 API 端点 → 查代码搜索，不要在对话里贴 300 行路由定义
• 这个依赖的版本兼容范围 → 查 lock 文件，不要每次重新讨论
• 客户的合同条款细节 → 查文档系统，不要复制进对话

你在对话里看到的"AI 好像很懂"，很多时候只是它刚刚检索过。而"AI 好像失忆了"，很多时候是它没有工具可查。

所以判断一个 Agent 配置得好不好的标准之一很朴素：它到底有几个能主动调用的外部查询动作？只有聊天、没有工具的 Agent，上下文就是它唯一的记忆上限。

五、Prompt 心法：交接优于追问

很多人以为 Agent 失忆的解法是"再多问几轮"。恰恰相反，频繁追问是最贵的解法：每一轮追问都要重发上下文，成本叠加，而且把对话推向散乱。

更省的做法是主动交接。在任务分叉点，让 Agent 自己产出一份结构化交接单，而不是等你来问"你还记得刚才说什么吗"。

可以这么写进系统提示：

【记忆规则】
1. 每次任务状态发生实质变化后，更新 state.md，用 JSON 结构，不要写散文。
2. 发现约束冲突时，先写入 open_risks，不要自行猜测。
3. 记忆只记录决策与约束，不记录可随时重新查到的信息。
4. 新会话开始时，先读取 profile.md 与 state.md，再接受指令。
5. 任何时候都不要假设"上次说过"——只相信文件里写的。

第 5 条是关键。有这句在，AI 就不会因为"感觉"你说过而胡编；没有这句，它大概率会自信地引用一段从未存在的内容。

另外一个心法：让"不记得"变成合法状态。在提示里明确写"缺少信息时先提问，不要推测"，比事后纠正它胡编省力得多。人都会承认自己忘了，模型不会。

六、实测对比

同一组工程任务，同一个模型，不同记忆方案的表现：

• 全量历史塞进去：单轮平均 18K Token 输入，正确率 71%，工具调用参数错误率偏高（模型在旧指令和新指令之间摇摆）
• 只保留最后 5 轮对话：单轮 3K Token，正确率 58%——省了钱，丢了上下文，得不偿失
• 三层记忆 + 结构化交接 + 外部查询：单轮 4.2K Token，正确率 91%，跨会话连续任务不再需要重复交代背景

第三种方案单轮 Token 甚至低于全量历史方案（因为它不需要重读一切），正确率却高出一大截。这就是检索结构带来的复利。

七、换个视角：上下文税

把这件事放到行业层面看，趋势就更有意思了。

当下的模型竞争，一边是参数和榜单，一边是"谁能把海量上下文塞进去还保持可用"。但对使用者来说，Context Window 更大并没有让工作变轻松，反而带来了一种新的开销——上下文税：你每一次对话，都在为历史信息付钱，包括那些你根本不会再用到的信息。

真正的分水岭不是窗口大小，而是记忆的工程化程度。当所有人都在拼 Token 的时候，真正拉开差距的会是那些把"记住"变成"能查"的项目。窗口从 8K 涨到 1M 花了几年，把检索做对只需要一个下午。

八、常见翻车现场

• 把日记当档案——每天写 2000 字流水账，真正要用时一条都检索不出来。记录要能被摘要成一句判断，而不是只有原始过程。
• 给 AI 装了记忆，但不告诉它什么时候用——文件里塞满东西，检索规则却没写，它自然不会去翻。
• 把人格设定当成记忆——"你是资深工程师"不是记忆，是约束。真正的记忆是可验证的事实。
• 让 AI 自己决定记什么——听起来最省事，但它的筛选标准常常和你期待的不一致。宁可一开始给固定模板。
• 存储和读取不对称——写了 50 条记忆，从来不读；或者读了 50 条，从不清理。定期做一次去重和归档，是维护成本的一部分。

写在最后

给 AI 配记忆这件事，本质上是给自己配笔记本。

没有笔记本的人，靠记忆力硬撑，每次开会都重新自我介绍一遍；有了笔记本的人，也得会分类、会取舍、会定期整理，否则一本写满的糊涂账比空白更糟。

AI 不会因为上下文窗口变成 1M 就自动变聪明，它只是把糊涂账变厚了。真正让它好用的，从来是你愿意花时间设计的那套结构。

所以下次再遇到"AI 又失忆了"，别急着骂模型。先问一句：我给它设计记忆结构了吗，还是每次都在求它别失忆？

如果这篇对你有启发，欢迎留言聊聊你的记忆方案。我很想看看别人是怎么给 AI 整理抽屉的。