长对话先收口：用“工作记忆 vs 长期记忆“管理 AI 上下文

发布日期： 2026年09月19日
阅读时间：约 12-15 分钟
分类：技术杂谈
专栏：主流AI工具指南
关键词：上下文工程 收口 中间迷失 LLM 长期记忆 AI

你有没有过这种体验：跟 AI 聊了四五十轮，从"帮我写个函数"一路拐到"顺便把数据库也调一下"，又或者“这个项目有什么思路”直到“帮我思考细节”。结果越往后越变得答非所问，甚至把你开头说下的硬性规定忘得一干二净，还捡起了已经枪毙掉的方案。你以为是模型变笨了，其实不是——是它的"脑子"装不下了。

本篇文章就来聊一个被很多人忽略的原理：大模型本身没有记忆，它唯一能"想起来"的东西，就是当前窗口里那几万 token 的上下文。 而一旦我们理解这一点，再用"工作记忆 / 长期记忆"的框架重新看，就会发现"长对话先收口、再开新对话"不是玄学，而是一套有理论支撑、而且在 2025–2026 年被正式命名的方法论——上下文工程（Context Engineering）。

一、在对话层面，LLM 其实是无状态的

很多人直觉里觉得：我跟 AI 聊了这么久，它总该"记得"我们聊过啥吧？就像和人对话一样。
但现实并没有这么简单。不同的 AI LLM 在对话记忆方面存在差异：有些只能在当前对话中利用上下文，有些支持跨对话记忆，还有些可以通过外部存储或检索系统保留历史信息。即使是同一个模型，也不意味着它能完整、持续且准确地记住与用户的所有交流。
所以，与其把 AI 当作一个拥有完整长期记忆的聊天对象，不如把它理解为：一个能够在特定条件下利用历史信息，但记忆范围、持久性和准确性都受到系统设计限制的智能工具。
每一次你发出消息，模型都需要基于当前可用的输入进行推理。这些输入可能包括当前对话中的部分或全部历史消息，也可能包括系统指令、用户偏好、检索到的外部资料，以及其他由应用程序提供的上下文。
从技术底层来看，大模型的推理绝大多数是‘无状态’的——你发送的每一条消息，本质上都是把过去整个聊天记录打包重新传给 API。模型本身并不会在两次对话之间‘留存’你的记忆，全靠客户端应用在后台不停地帮你‘复读’历史对话。
但这并不意味着所有 AI 产品都是完全无状态的。有些系统在模型之外构建了持久化记忆机制，能够保存用户偏好、历史事实，甚至检索过去的对话内容。此时，所谓的“记忆”不一定存在于模型参数内部，而可能由整个应用系统共同实现。
因此，更准确的理解是：
$$
\text{AI 的当前上下文} \neq \text{AI 的全部记忆}
$$
当前上下文是模型在一次推理中能够直接利用的信息，而系统记忆则可能包括暂时未被加载、存储在外部，或通过检索机制按需调用的历史信息。
上下文窗口决定了模型一次能够处理的信息边界，但它并不等同于完整的长期记忆。更重要的是，即使历史信息被保存并重新提供，模型也不一定能够准确理解或复现其中的每一个细节。
AI 的记忆，不只是模型能处理多少信息的问题，更是一个关于信息保存、选择、检索与理解的系统工程问题。
而工作记忆，恰恰是AI的认知系统中，最不完善的一部分。

二、换个新词——上下文工程

如果说“提示词工程（Prompt Engineering）”解决的是“怎么问”，那么“上下文工程（Context Engineering）”解决的就是“给模型什么背景”**。而“收口”，恰恰是上下文工程里最被低估、却最省钱的那个操作。
早几年大家的注意力放在"提示词工程（Prompt Engineering）"——怎么把一句话问得更巧。但 2025 年起，这个注意点已经逐渐迁移到 上下文工程（Context Engineering）：与其纠结"怎么问"，不如设计"每次推理时，到底往上下文窗口里塞什么"。
Shopify 的 Karpathy 有一句被反复引用的话：context engineering is the art of filling the context window with just the right information. 收口，恰恰就是上下文工程的写这一半——把上一局里有价值的东西精炼出来、存好，下一局只把"对的"那部分读回来。
几个相关术语：

Context Rot（上下文腐烂）：不再只说"越长越乱"，而是指长上下文里注意力被稀释、早期约束最先失效的系统现象。它就是上一节"幻觉"的工程学名。
Lost-in-the-Middle（中间迷失）：Liu et al. 2023 的经典结论——模型对长文本中间位置的注意力显著弱于首尾。开头定的"exam ≥ 30"这种硬约束，最容易被它忘。
Agent Memory / Long-term Memory Layer：Mem0、Zep、LangMem 这类框架干的事，本质就是自动收口 + 按需检索——给 agent 装一层跨会话的长期记忆。我们手边的协作工具，底层也是同一套思路。

三、我们都一样：人类也受工作记忆的限制

认知心理学研究发现，人的工作记忆（Working Memory）容量非常有限。它就像大脑的临时草稿纸，只能同时放下少量信息。早期研究提出过著名的“7±2”理论，后来的研究则认为，在很多情况下，人一次能够处理的独立信息组块可能只有 4 个左右。
那我们是怎么完成复杂任务的？比如下厨房做饭，我们要一边看菜谱、一边准备食材，还要记住下一步做什么。即使熟能生巧，也不能面面俱到。
我们通常不会把所有信息都一直放在脑子里，而是会把重要内容记录下来，需要时再查阅。笔记、待办清单、日历，甚至一张贴在桌上的便签，都是在帮我们减轻大脑的负担。这可以理解为一种“外部记忆”：把暂时不需要一直记住的信息放到大脑之外，在需要的时候再取回来。
大模型其实也面临着类似的问题，只是表现方式不同。
首先，模型的上下文窗口虽然通常比人的工作记忆能够容纳更多信息，但这并不意味着信息越多越好。上下文越长，处理成本可能越高；当信息堆积到一定程度时，模型也可能难以准确利用其中的内容。这类问题常被称为 Context Rot（上下文退化）。
其次，模型不会像人一样自然地形成完整、可靠的长期记忆。一个 AI 应用是否保存历史信息、如何整理和检索这些信息，取决于它的系统设计。很多时候，我们需要借助笔记、数据库、检索工具或自动化记忆功能，帮助 AI 在不同对话之间保留重要内容。
最后，即使信息已经放进上下文，模型也不一定能够同等关注每一部分。当上下文变得很长时，模型对不同位置的信息利用能力可能出现差异。研究发现，在某些任务中，位于长上下文中间的信息更容易被忽略，这种现象被称为 Lost-in-the-Middle。因此，把关键约束埋在大量历史信息中，可能降低模型准确利用这些约束的能力。
所以，人类和 AI 之间确实存在一个值得比较的共同点：
工作记忆帮助我们处理眼前的事情，而长期记忆和外部记录帮助我们跨越时间保存信息。
但两者并不完全相同。人类可以通过学习、经验和习惯形成长期记忆；AI 的持久化记忆则通常需要模型训练、系统设计或外部工具的支持。
这带来一个很有意思的思考：
当我们希望 AI 长期记住重要信息时，我们究竟是在使用一个拥有记忆的智能体，还是在逐渐为它搭建一套外部记忆系统？

四、AI 的两种"记忆"

借鉴认知心理学中的记忆模型，我们可以将 AI 协作中的信息清晰地划分为两类：

	工作记忆（上下文）	长期记忆（收口摘要）
载体	当前对话窗口	外部文件 / 笔记 / 知识库 / Memory Layer
成本	上下文中的信息会占用模型的输入 token；随着对话变长，处理成本可能增加。但实际系统可能使用缓存、截断、摘要或检索等机制，因此并不一定每轮都重新处理完整历史。	一次整理写入；后续读取时按需检索并注入上下文，整体 Token 开销更低，但存在前期整理与检索计算成本。
稳定性	易失性（Volatile）。生命周期仅限单次会话/窗口内。	持久性（Persistent）。生命周期跨越会话与时间。
抗干扰	较弱：易发生上下文腐化（Context Rot）、长文本注意力衰减，易被中间试探/错误过程带偏。	较强：经过提炼与结构化，噪音低；但需定期更新以防过时信息干扰。
典型内容	过程性对话、草稿、多轮纠错、上下文背景、临时指令。	最终决策、核心事实、用户偏好（SOP）、标准化知识、下一步计划。

总结：工作记忆是"当下的负担"，长期记忆是打包精炼后的"未来资产"。

五、收口收什么？

很多人以为"收口"就是把聊天记录整段贴进笔记，其实不是，重点在“收”这个聚集的动作。
收口是提炼出未来用得上的骨架，通常就三样：

决策：选了哪本教材、技术栈定了什么、考核结构怎么算；
关键事实 / 结论：核心概念、公式、约束条件（比如"考试门槛是 exam ≥ 30"这种硬约束，最该被显式记下来）；
下一步：还没做完的事、待办项。
在很多日常协作任务中，一份经过提炼的短摘要可以保留原对话中最重要的信息，从而避免每次重新加载大量历史内容。但它不能完全替代原文：如果任务需要精确细节、代码、原始数据或完整上下文，仍然需要回到原始资料。
新对话开局只需读取这份摘要，就能接上前文。这样既能大幅节省 Token，又避开了“开头约束被遗忘”的隐患。

六、实战：在 WorkBuddy 里用 Prompt 收口

在用 WorkBuddy 这类带记忆系统的工具时，收口可以靠一句 prompt 直接触发，不用手动建文件。它的记忆是分三层的：

云端档案（自动注入的 profile + 历史对话检索）：跨项目、跨会话都能被召回；
用户级跨项目记忆 ~/.workbuddy/MEMORY.md：相当于用户的个人习惯与长期偏好（跨项目有效）；
工作区级记忆 项目/.workbuddy/memory/：当日日志 YYYY-MM-DD.md + 项目长期笔记 MEMORY.md，仅当前项目有效。
（注：以上是 WorkBuddy 记忆系统的底层落盘结构；官方面向用户的「记忆」功能以自动抽取 + 对话管理为主，详见文档《记忆》。）
对应关系很清晰：临时结论 → 当日日志；可复用的偏好/约定 → 各类 MEMORY.md；跨项目经验 → 用户级 MEMORY.md。

下面三句分别对应上下文工程的"写—读—沉淀"闭环。养成习惯后，云端档案会在每次会话自动注入；而每段任务的收口笔记，下次开新对话时用 ② 号 prompt 就能一键召回。

① 收口：任务告一段落时

请把本次对话的核心结论收口，写入工作区记忆：
1. 决策（选了什么方案 / 技术栈 / 考核结构）
2. 关键事实与硬约束（公式、阈值、不能踩的坑）
3. 下一步待办
格式：追加到 .workbuddy/memory/今日日期.md；
跨项目的长期偏好写进用户级 ~/.workbuddy/MEMORY.md，
仅本项目的约定写进工作区 MEMORY.md。

② 注入（读）：开新对话、接上前文时

开始新任务前，先检索 .workbuddy/memory/ 下相关日志和 MEMORY.md，
以及与「[当前任务]」有关的云端历史对话，
把要点作为背景注入本次上下文。不要重读旧对话全文。

（WorkBuddy 的 conversation_search 就是干这个的——它只检索、不加载整段原文，正是"用几百 token 买回几十万 token 专注度"的具象化。）

③ 固化长期偏好（跨项目复用）

记住：我之后写 AI 协作类博客，默认用
「工作记忆 vs 长期记忆 + 上下文工程」这套框架。
把这条写进用户级 MEMORY.md。

七、Prompt实例：初学Java

用户刚刚进行初步学习后，先收口以便下次继续学。
错误姿势：第一讲聊完不收口，直接接着聊第二讲。上下文越滚越大，到第三讲时模型可能已经忘了第一讲定的考核结构，还把早先某个否掉的思路又捡回来——这就是典型的 Context Rot。
正确姿势：第一讲结束，用上面的 ① 号 prompt 把要点（大纲、考核结构、8 个核心概念）收口进当日日志。开新对话聊"第二讲 "时，用 ② 号 prompt 让工具把那份摘要调回来当背景——模型不用重读几百行转录，你也不用重新讲一遍前情。

这是workbuddy(Hy3)给出的prompt:

请帮我把这次 Java 入门学习的核心进度收口，写入工作区记忆，方便下次接着学：
1. 决策：今天定的学习资料与路径（如《Java 核心技术》第 1–3 章、JDK 版本、IDE 选型、是否跟视频）
2. 关键事实与已掌握概念：变量/数据类型、类与对象、main 方法结构、包与导入等；
   以及硬约束/环境约定（如 JDK 17 已配好、源码目录约定、public 类名须与文件名一致等不能踩的坑）
3. 下一步待办：下次要学的内容（如第 4 章 继承/接口）、待敲的练习题、今天卡住没搞懂的问题
格式：追加到 .workbuddy/memory/今日日期.md；
可复用的长期偏好（如"默认 JDK 17 + IntelliJ、跟练代码放 src/ 下"）同步到 MEMORY.md。

我接着上次 Java 入门学习继续。先读 .workbuddy/memory/ 下 Java 相关的当日日志和 MEMORY.md，
把我已掌握的概念、环境约定和"下一步待办"作为背景注入本次上下文，
然后从「下一步待办」里第一个未完成的任务开始带我学。不要重读旧对话全文。

八、结语

长对话的"上下文税"会越滚越大，大模型本身并不会像人类一样自然地形成持续的个人经历记忆；但现代 AI 产品可以通过 Memory、数据库、检索和自动摘要等机制保存并重新调用历史信息。因此，AI 的“长期记忆”更多是模型与外围系统共同实现的能力，而不是简单存在于模型本身。
到了 2026 年，随着 AI 能够处理越来越长的上下文，如何组织、筛选、保存和调用信息变得越来越重要。与其一味追求更复杂的 prompt，不如同时关注 上下文工程（Context Engineering）：在合适的时机整理当前上下文中的重要信息，并通过摘要、检索、外部存储或 Memory 等机制，让这些信息在之后的任务中继续发挥作用。

参考文献

Anthropic. (2025, September 29). Effective context engineering for AI agents. https://www.anthropic.com/engineering/effective-context-engineering
Chhikara, P., Khant, D., Aryan, S., Singh, T., & Yadav, D. (2025). Mem0: Building production-ready AI agents with scalable long-term memory. arXiv. https://arxiv.org/abs/2504.19413
Karpathy, A. [@karpathy]. (2025, June 25). +1 for "context engineering" over "prompt engineering" ... context engineering is the delicate art and science of filling the context window with just the right information for the next step [Tweet]. X. https://x.com/karpathy
LangChain. (2025). LangMem (Version 0.x) [Computer software]. GitHub. https://github.com/langchain-ai/langmem
Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2023). Lost in the middle: How language models use long contexts (arXiv:2307.03172). arXiv. https://arxiv.org/abs/2307.03172
Lütke, T. [@tobi]. (2025, June 18). I really like the term "context engineering" over prompt engineering. It describes the core skill better: The art of providing all the context for the task to be plausibly solvable by the LLM [Tweet]. X. https://x.com/tobi
Rasmussen, P., Paliychuk, P., Beauvais, T., Ryan, J., & Chalef, D. (2025). Zep: A temporal knowledge graph architecture for agent memory. arXiv. https://arxiv.org/abs/2501.13956
WorkBuddy. (2026). 记忆（WorkBuddy 从入门到精通指南·功能说明）[Computer software documentation].Retrieved September 19, 2026, from https://www.workbuddy.cn/docs/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Memory

🗓️ 文章信息