短期靠上下文，长期靠外部记忆，RAG 是记忆方案而不是银弹
上一讲结束，我们留了一个尾巴：任务跑长了，上下文迟早写满，到时候怎么办？是扔掉，还是压缩，还是搬出去？
这一讲就把这三个选项挨个讲清楚。先说结论：扔掉是最差的选择，压缩是日常手段，搬出去才是长任务的正解。你可能常听 RAG——给模型外挂一个资料库，先查再答。它也属于”搬出去”，但地位经常被高估。
问题一：写满了，直接扔掉会怎样？
最简单的处理方式当然是扔：上下文写满了，截断前面的，或者直接开一个新会话。有没有产品默认就是这么干的？扔掉会发生什么？
一个跑了 40 轮的代码重构任务，把前 20 轮扔掉，模型会：
忘掉当时定下的技术选型 → 用另一种风格继续写，前后不一致
忘掉已经改过的文件清单 → 同一个文件改两遍，或者漏改
忘掉客户提过的约束 → 交付的东西违反一开始的要求第 1 讲咱们验证过”模型没有记忆”——历史是每次重新塞进去的。所以”扔掉历史”不是”忘掉一些细节”，而是模型根本意识不到那些事情发生过。它不会说”让我回忆一下”，它只会无缝地、自信地继续往前走，走得南辕北辙。
像不像开了一下午会，中途把会议纪要烧了？后半场的人只能靠猜。
问题二：压缩，怎么压才算会压？
扔不得，那就压缩（compaction）：在上下文写满之前，把历史总结成一份摘要，带着摘要继续跑。这是目前主流 Agent 产品的标配动作。
压缩的难点不在”压”，在”留”。一份好的压缩，留什么、扔什么？
要留的（丢了任务就断片）：
关键决策和决策理由 例如："选了方案 B，因为客户要求兼容旧系统"
未完成的事项和当前状态 例如："7 个文件改了 4 个，还剩 3 个"
重要的中间结论 例如："已确认性能瓶颈在数据库查询"
要扔的（留着纯属占预算）：
工具返回的原始大段输出 例如：整屏的日志、完整的文件内容
已完成步骤的琐碎过程 例如：每一次搜索的关键词、每一次试错
客套和重复 例如：每一轮的"好的，我来帮你……"举个数字感受一下：40 轮对话可能有 5 万 token，压成一份好摘要可能只要 500 token——预算省 99%，任务还能接着跑。Anthropic 还提到一个最轻量的压缩形式：工具结果清理。工具的原始输出在被消化之后直接删掉，只留结论。这一步非常实用，经常是最划算的一步。
压缩是门手艺活。压少了没用，压多了断片——先求全（别丢关键信息），再求精（删掉废话），这个顺序不能反。
问题三：搬出去，外面应该怎么建记忆？
压缩解决的是”窗口内省着用”，但任务跑到几百轮、几天、几周，光靠压缩还是不够——总有些事情需要”过很久还记得”。这时候就要把记忆搬到上下文窗口之外：写成文件，需要时再读回来。
官方管这个叫结构化笔记（structured note-taking）：Agent 定期把重要信息写到外部文件里，后续回合按需取回。两个真实例子：
- 编码 Agent 维护一个 todo 清单文件，改了什么、还剩什么，全在里面——上下文被压缩了也不怕，清单还在文件里；
- 有团队让模型玩宝可梦，它靠不断记笔记，在几千步游戏里精确记住自己探索过哪些区域、抓了几只怪。
注意这里和第 3 讲的呼应：外部记忆 + 用时取回，本质上就是”按需加载”的延伸——长期信息放文件里，上下文里只留指针。思想还是那个思想。
那 RAG 呢？大伙天天听到的检索增强生成（RAG），在这个框架里的位置是：RAG 是”外部记忆 + 按需检索”的一种实现。但为什么说它是方案而不是银弹？两个原因：
- 检索质量决定一切——检索不准，拿回来的就是噪声，反而稀释注意力预算（第 3 讲的结论在这里照样成立）；
- 检索回来的内容照样占上下文——RAG 没有扩大窗口，只是让窗口里的内容更相关。它解决”喂什么”，不解决”喂多少”。
RAG 不是记忆本身，RAG 是图书管理员。书（记忆）还是在外面的书架上，管理员负责帮你找——找得准不准，看这个管理员的本事。
落到 sdd-site-agent：记忆结构怎么设计
回到咱们的贯穿项目。上一讲的作业①做了分层设计表（什么永远在线、什么按需加载），这一讲给它加上”记忆维度”：
长期记忆（外部文件，需要时读入）：
三个规范 需求/原型/架构规范——沉淀的，不轻易变
决策记录 每次生成的关键决策和理由——是资产
短期上下文（当前会话内）：
当前任务 这次要开发的需求 a、原型 a、方案 a
当前规范 这一步需要哪个规范，就只载哪一个
压缩策略：
过程对话 定期压缩成"当前状态 + 关键决策"
工具输出 原始大段输出（文件、日志），消化完就清掉这样设计完，sdd-site-agent 跑再长的任务也不怕：规范在文件里，丢不了；上下文里只有当前任务和当前规范，塞不满；过程对话定期压缩，断不了片。记忆不是模型的功能，是咱们设计出来的结构——这就是长任务的底气。
到这儿，地基和上下文工程两个模块就齐了。接下来 25 分钟，咱们亲手把长任务的记忆装上。
实操演练（约 25 分钟）
必做部分 + 一步加餐。做完必做部分，本讲的核心手感就到手了。
检验一下
①sdd-site-agent 记忆结构表：在第 3 讲作业①的分层设计表上，加长期记忆 / 短期上下文 / 压缩策略三行——这是第 5 讲设计 Agent 循环的直接输入。压缩策略那行，用实操压缩实验里记下的”丢了什么”三条当底线。
skills/目录就是长期记忆（规范写在文件里，丢不了），对话历史就是短期上下文（每轮重放）。先自己动手做，再对照着看。mini-agent 的完整代码，后续我会分享出来——但别等它，先把你的设计做出来。你如果想深挖一层，还是这篇：Anthropic · Effective context engineering for AI agents
压缩、工具结果清理、结构化笔记、子代理，长任务四件套都在里面。宝可梦 Claude 的笔记故事也出自这篇——这篇文章我们引了三讲，它值得一次完整的通读。（沈剑注：宝可梦那个例子我给好几拨人讲过——记笔记这个办法，人也是一样的。）
但还有一个没解决的问题：记忆解决了，可光会记的就是 Agent 吗？一个程序定时帮我们查天气，算 Agent 吗？如果它自己判断要不要提醒我们带伞呢？——第 5 讲，咱们讲 Agent 的本质。
知其然，知其所以然。思路比结论更重要。