上下文与记忆 — 结构胜于大小
这一章讲三件事: 为什么「窗口越大越好」是错觉; 一个 markdown 文件(plan.md)凭什么同时干五份工作; 摘要、交接、工件驱动工作流——没有记忆的系统怎么假装自己有记忆。 读完你能回答:长会话进行到一半,模型为什么开始「忘了最初的目标」?
1. 这一章讲什么
模型没有记忆,这一点第 06 章说过:它每次只是在续写一段文字, 「之前说过什么」必须全部写进这段文字里。这段文字的容量上限,就是 上下文窗口——模型一次能读进来的全部文本,行业也把它叫工作记忆。
原书这一节回答的是安全工程师视角下的下一个问题:这个记忆怎么管理, 系统才既省、又稳、还不容易被带偏。答案一句话:起决定作用的是结构与相关性, 不是窗口大小。
2. 顶层全景
同样的 8 万 token 预算,两种装法(数值为演示所编):
装法 A:垃圾场 装法 B:结构化
┌──────────────────┐ ┌──────────────────┐
│ 目标(第 3 页,已淹没)│ │ plan.md(常驻顶部) │
│ 指令(散在 12 处) │ │ ├── 目标与约束 │
│ 示例(与任务无关) │ │ ├── 已完成 ✓✓✓ │
│ 半成品输出(6 版) │ │ ├── 当前阶段 │
│ …… │ │ └── 下一步 │
└──────────────────┘ │ 相关资料(按需挂载) │
信噪比低,目标被稀释 └──────────────────┘
信噪比高,随时回锚
图说:窗口是固定大小的房间;结构决定这间房里「要紧的东西」
离模型「注意力」有多远。
3. 核心原理
3.1 大,不等于好
书里的第一个论断泼冷水:现代模型支持的窗口确实极大,但加窗口尺寸不会自动 提升输出质量;而且日常使用根本用不满——实践中,超大上下文往往变得嘈杂低效, 除非喂进去的东西被精心组织过1。
「嘈杂」为什么伤质量?书里引的研究(Liu 等人 2023 年的 《Lost in the Middle》)给的是机制:模型并不均等地使用长 prompt 的各个部分; 相关信息埋在长输入的中段、或被不相关内容包围时,更难被取用1。 论文原结论的形状是「两头好、中间差」:开头和结尾的信息利用率高,中段塌陷 (补充,不在书里,来自通用知识:该论文测的是多文档问答,把答案所在文档 挪到 prompt 中段,准确率明显低于放在开头或结尾)。
书里把这条总结成一个对仗:more context ≠ better context—— 大窗口只有在模型「找得到、排得出优先级、复用得上」要紧内容时才有用; 没有结构,大 prompt 就是个堆满便签、指令、示例和半成品的乱摊子——要紧信息与 噪声(不相干的杂音内容)的比例,行话叫信噪比——反而低于组织良好的短输入。 所以这门手艺的名字叫上下文工程(context engineering)—— 功夫全在结构,不在长度2。
3.2 plan.md:一个文件的五份工作
结构化的现代做法,书里选的代表朴素得出奇:用文件把意图和执行过程外化。
一个 plan.md(计划文件,普通 markdown 文本)同时干五份活3:
| 工作 | 具体是什么 |
|---|---|
| 压缩意图 | 任务是什么、约束是什么,几行写死,不用模型从对话史里重新猜 |
| 结构化信息 | 已完成/进行中/待办分区,信息有了地址 |
| 滤噪 | 对话里绕的弯路、失败的尝试不用常驻上下文,沉淀到文件里的只有结论 |
| 人机协作的锚 | 人要审就审这个文件——它是给人看的工作台 |
| 稳定锚点 | 上下文快满时,模型回到这个文件「重新定向」,而不是顺着漂 |
第五份工作最值钱,书里的表述是:与其指望长长的对话历史始终保持同等「醒目」, 不如给模型一个耐久的工件,写明任务是什么、做完了什么、还剩什么; 上下文被填满的过程中,模型随时可以回文件里刷新方向, 这比祈祷对话史不褪色可靠得多3。
这个思路我们有现成的工程印证(补充,不在书里,依据我们的 frontier 书架):
开源框架 deepagents 的记忆中间件做的正是这件事——把 AGENTS.md 常驻注入
system prompt,让「项目约定」这类锚点在每次会话开始就在场,不依赖模型记得。
依据: shelf=ai-frontier-reference/deepagents#06-skills-memory-rubric.md @25aa2735dabbca6a8c82afae2c7c9f35830d151c 事实=MemoryMiddleware 在 agent 启动时主动把 AGENTS.md 内容注入 system prompt,文件先于对话存在。
3.3 摘要:无状态系统的假记忆
第二个抓手是摘要(summarization)。书里给它的定位远高于「省 token 的技巧」: 摘要,是 LLM 系统在无状态(就是自己不保存任何东西)的架构里模拟连续性的主要手段—— 它同时是日志、是省钱、是记忆管理3。
摘要对象的几个工程细节,书里给得很具体:
- 它双向收益:既缩短上下文(省钱),又把「要紧的部分」持续写进某个记忆结构;
- 大型长流程里,高频小步地摘要胜过偶尔来一次大总结;重写计划、更新进度笔记、 往日志文件里记执行轨迹,让「已验证有效的想法」能从一个阶段带进下一个阶段4;
- 每份摘要可以当交接(handoff)用:agent 交班给下一个 agent、或交给验证者 一个可检查的台阶;书里顺便立了条纪律——验证者不该是 LLM 查 LLM; 真要这么做,也不该用同一个模型(同一双眼睛查不出同一类盲区)4;
- 不知道摘要什么,书里给了保底清单:试了什么、什么成了、什么败了、 当前在用的假设、已完成的计划步骤、下一步计划——就这六项,最简形式也能 省钱并改善连贯性、引用质量与任务连续性4;
- 摘要反复重写同一个文件时,留一份备份当历史参照——摘要是有损压缩, 压掉的万一后来要呢3。
工具现状书里也没粉饰:Claude Code 会替用户天真地管理记忆,但作者自己的经验 是自己管,效果好得多(比如把记忆挂在 git 提交说明里,避免项目目录膨胀)4。
3.4 主走查:同一场长会话,两种命运
场景:让 agent 重构一个有 40 个文件的项目。会话进行到第 6 小时 (数值全部为演示所编):
装法 A(裸聊,无工件):
08:00 目标:「把 utils/ 下的重复函数合并,行为不变」
11:00 对话已 6 万 token:30 轮往返、5 版被否掉的方案、2 次跑偏
(一次去优化了无关的日志格式,一次重写了用户没让动的入口文件)
13:00 上下文逼近窗口,最早的指令已在「中段塌陷区」
14:00 模型开始重复 10:00 已否掉的方案(它看不见 10 点的否决了)
15:00 上下文截断,最早的目标声明被推出窗口 → 模型在给一个
它已经读不到原文的目标干活,越干越偏
结果:烧了 8 小时,合并了 3 个函数,引入 2 个回归。
装法 B(plan.md 常驻 + 每阶段摘要):
08:00 plan.md 写入:目标、约束(行为不变)、验收标准(测试全绿)、阶段表
每完成一阶段:摘要六件套(试了什么/成/败/假设/已完成/下一步)追加进 plan.md
14:00 同样逼近窗口 → 模型 read plan.md 重新定向:
「已完成 utils/a、utils/b;当前 utils/c;失败方案 #3 勿再试」
结果:5 小时,合并 9 个函数,测试全绿。
差异的根源不是模型变聪明了,是「要紧信息」在两种装法里的
位置和保鲜度不同——结构压过了大小。
3.5 为什么不全信 agent:书里的立场
有人会说:这些不都是 agent 该自己解决的事吗?书里的回答很干脆:现实中的 agentic 系统仍会绕圈、会押注在错误假设上、会迈不过自己的盲区;作者见过 成群的 agent(多 agent 并行)彻底丢失主线、空转烧钱,也见过在早期 Manus 平台上跑到会话丢失此前大量上下文的项目5。
而工件驱动的工作流(artifact-driven workflow:人和 AI 一起靠文件维护 上下文与记忆——plan.md、prompt 文件、日志;人再审日志、摘要与输出, 审过的产物又被当输入复用)给出了更可控的替代:保住连续性,同时不交出监督权。 书里的判断是:这类工作流在实践中常胜过裸聊天系统和完全自主的 agent 系统6。
研究侧也有旁证:模型把推理外化到草稿纸(scratchpad,中间输出或可复用的 脚手架)上时,表现好于一口气解完——把中间步骤写出来,本身就是一种外部记忆7。
4. 作者的判断与证据
- 有证据的:Lost in the Middle(书内脚注给了 arXiv 编号 2307.03172)与 scratchpad 研究(书内脚注给了 arXiv 编号 2112.00114,《Show Your Work》,2021)17;
- 作者的观察:agent 绕圈/押错假设、多 agent 丢主线、早期 Manus 丢上下文、 Claude Code 记忆管理不如手管——全部是一线经验,无量化数据45;
- 作者的立场:工件驱动 > 全自主 agent——这是本书反复出现的主张, 注意它是「更可控」的主张,不是「永远更快」6。
5. 边界与局限
- plan.md / 摘要的结构方案,书里明说「怎么组织记忆、输出或日志文件高度依赖 具体应用」——本书给的是原则与清单,不是模板;
- 摘要有损:书里只说「留备份」,没讨论哪些信息绝不能只存在于摘要里 (如安全约束原文);
- 「验证者不该是 LLM 查 LLM」书里一句带过,没有展开机制(自评偏好、 同源盲区);这是研究台的活跃课题,本书未深入;
- 书里对窗口大小与成本的关系只说「省钱」,没有给计价口径。
6. 可带走的
- 上下文窗口是工作记忆;结构决定质量,大小只是上限;
- 埋在中段的信息更难被用:要紧的东西放两头,或放进常驻工件;
- 一个 plan.md 干五份活:压缩意图、结构化、滤噪、人审锚、稳定锚点;
- 摘要不是省 token 技巧, 是无状态系统模拟连续性的主要手段;
- 摘要保底六项:试了什么/成/败/当前假设/已完成/下一步;
- 验证不要让同一个模型自己查自己;要查也换一个模型;
- 反复重写的摘要文件留备份——摘要有损;
- 长流程要么高频小步摘要,要么翻车:别让关键否决沉进对话史的中段;
- 工件驱动工作流:保连续性,且不交出监督权——比全自主 agent 更值得默认选择。
7. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 工作记忆、大小不等于效果、中段塌陷(注 2) | Context Windows & Memory Architecture | text/15-fm-context-windows-memory-architecture.txt:3(搜「buried in the middle」) |
| more ≠ better、信噪比、上下文工程 | Context Windows & Memory Architecture | text/15-fm-context-windows-memory-architecture.txt:5(搜「signal-to-noise」) |
| plan.md 五份工作、耐久工件、摘要=连续性 | Context Windows & Memory Architecture | text/15-fm-context-windows-memory-architecture.txt:7(搜「plan.md」) |
| 高频摘要、交接、验证者纪律、六项清单、手管记忆 | Context Windows & Memory Architecture | text/15-fm-context-windows-memory-architecture.txt:9(搜「what was attempted」) |
| agent 绕圈、Manus 丢上下文 | Context Windows & Memory Architecture | text/15-fm-context-windows-memory-architecture.txt:11(搜「losing the plot」) |
| scratchpad 外化 推理(注 3)、多步流程 | Context Windows & Memory Architecture | text/15-fm-context-windows-memory-architecture.txt:13(搜「scratchpads」) |