A3.1 上下文 = 工作记忆：装满了怎么办
一间只进不出的房子
心理学有个经典结论：人的工作记忆同时只能端住七件事左右，多了就往外掉。智能体也有工作记忆，就是上下文窗口——模型每一步「看得见」的全部世界。
麻烦在于，A0 深入层埋过的那颗雷：循环每转一圈，上下文只增不减。 读一个代码文件，3000 token 进来了；跑一次测试，6000 token 的报错日志灌进来了；每次思考和工具调用也各占一截。先算笔账：
- 读 3 个文件 ≈ 10k token；
- 跑 2 次测试 ≈ 12k token；
- 十几步的思考、修改、调用 ≈ 8k token。
一个 32k 的窗口，一个十几步的重构任务就能顶到天花板——长任务撞墙是必然，不是意外。
而且撞墙之前就已经开始付代价了。上篇 8.2 节讲过「标称窗口 ≠ 有效窗口」：窗口塞得越满，模型对中间内容的注意力越差，容易「读了但没看见」；同时每一步的计算都要背着全部历史，又贵又慢。业内管这叫上下文腐烂——还没溢出，先变笨了。
四种活法，亲手跑一遍
同一个 12 步的重构任务，四种上下文策略，四种结局：
上下文管理器：同一个长任务，四种活法
任务：重构订单模块（12 步）。上下文窗口 32k token（示意）。选一种策略跑完时间线，重点盯着上方的「上下文水位条」——四种策略都 试完，你就懂上下文工程了。
什么都不做，任由上下文一路膨胀
上下文水位0 / 32,000 token（0%）
请四种策略全部跑完（按钮上会打 ✓）：
- ① 硬扛不管理：水位一路爬升，第 12 步 💥 溢出——前 11 步的工作全部白费；
- ② 截断最旧：第 10 步 ✂️ 自动扔掉最早的内容，其中恰好有第 3 步的接口约定「金额一律用分为单位存储」——收尾时模型凭感觉用了「元」，一个金额差 100 倍的 bug 就这么埋进了代码；
- ③ 定期压缩：第 9 步触发 🗜️，把 1~7 步压成 1500 token 的摘要，接口约定被写进摘要保住了——任务完成，代价是一次压缩调用和「摘要必丢细节」的隐患；
- ④ 外置记忆：第 3 步就主动把约定 📝 写进笔记文件，大文件读后即弃、测试日志只留关键行——全程水位没过半，收尾时读回笔记，最稳的一条时间线。
四种策略的取舍一张表：
| 策略 | 存活 | 关键信息 | 额外成本 | 一句话 |
|---|---|---|---|---|
| 硬扛 | ❌ 溢出 | — | 无 | 不是选项 |
| 截断最旧 | ✅ 但带病 | 可能被扔 | 无 | 按时间扔，不看重要性 |
| 定期压缩 | ✅ | 摘要保留（有损） | 压缩调用 | 有损保命 |
| 外置记忆 | ✅ 最稳 | 笔记永存 | 记/读笔记的调用 + 纪律 | 好记性不如烂笔头 |
这门「决定什么信息进上下文、以什么形式、留多久」的手艺，2025 年起有了正式名字：上下文工程。业界的共识是：提示工程管「怎么说」，上下文工程管「给模型看什么」——对智能体而言，后者往往更决定成败。
这个实验在哪里不准确？
时间线和数字是教学构造：真实系统的压缩触发阈值、保留窗口、筛选规则远比「过 24k 就压缩 1~7 步」精细，而且会分层处理（系统提示永不压、最近几轮全保留）。另外要诚实：「压缩必丢细节」是原理性的——好的压缩提示词只能减损，不能免损。实验里③「丢的恰好是不再需要的测试日志」是剧本的仁慈，现实不保证这种运气。
小结
本节要点
- 上下文是智能体的工作记忆：循环每圈只增不减，长任务撞墙是必然。
- 溢出之前先「腐烂」：窗口越满，模型越贵越笨——管理要趁早。
- 四策略：硬扛必死、截断危险、压缩有损保命、外置记忆最稳；真实系统压缩兜底 + 笔记保关键，混着用。
📝 动手自测0/3
1. 智能体的上下文为什么在长任务里「只增不减」？
2. 实验里「截断最旧」策略埋下金额差 100 倍 bug 的根本原因是？
3. 关于「定期压缩」策略，下面哪个说法是对的？
延伸阅读
- Anthropic：Effective context engineering for AI agents——「上下文工程」一词的系统阐述（2025）。
- 下一节 A3.2 长期记忆：会话关掉之后，它凭什么还记得你。