记忆管理
② 记忆管理
Section titled “② 记忆管理”定位:模型天生失忆——每次对话都从零开始,上一轮干了什么、定了什么口径,统统不记得。Harness 注入记忆、检查点、上下文压缩,让一个长任务有历史、有上下文,能跨轮、跨天接着干。
📎 上级:设计指南/Agent设计;出处:实践分享第一章 P6(4 件事之二)。
一、问题:模型没有「昨天」
Section titled “一、问题:模型没有「昨天」”模型本身是无状态的。没有 Harness 帮它记,就会:
- 长任务「转着转着就忘了」前面的决定;
- 跨天续作时,昨天的进度全丢,只能重来;
- 同一口径反复重新确认,甚至前后不一致(口径飘 → 见 设计指南/本体设计)。
Harness 要做的,是给模型造一条时间线:
Day1 ──●── Day2 ──●── 今天 压缩 压缩 ↑ 接上昨天的进度二、三件套:记忆 / 检查点 / 压缩
Section titled “二、三件套:记忆 / 检查点 / 压缩”| 机制 | 解决什么 | 怎么做 |
|---|---|---|
| 记忆 Memory | 跨会话长期事实(偏好、项目状态、口径决定) | 落到外部文件/库,按需召回,不常驻上下文 |
| 检查点 Checkpoint | 长任务中途的「存档点」,可续作可回滚 | 把关键状态(已完成步骤、产物路径、待办)固化下来 |
| 上下文压缩 Compaction | 上下文快满时不「断片」 | 把历史对话压成摘要,保留结论与状态,丢掉过程噪音 |
三者配合:记忆管「长期记得」,检查点管「中途可续」,压缩管「窗口不爆」。
三、上下文窗口怎么分配
Section titled “三、上下文窗口怎么分配”把有限的窗口当预算来管,典型四块:
[ 系统/指令 ] [ 记忆·检查点 ] [ 当前任务材料 ] [ 余量 ]- 系统与指令常驻,占比要省;
- 记忆/检查点只放当前任务相关的那几条,不是全量历史;
- 给「余量」留空间,否则一步大返回就溢出;
- 这块和「上下文管理」直接咬合 → 见 设计指南/Agent设计/上下文管理。
四、案例:周五审到一半的控制价,周一怎么接着审
Section titled “四、案例:周五审到一半的控制价,周一怎么接着审”审核员让 Agent 审一份 200 页的招标控制价。周五下班时审了一半,周一早上接着干。
没有记忆的版本——周一一切归零:
- Agent 把 200 页重新读一遍(白烧一遍 token);
- 周五已经判过「桩基单价按 2024 定额、暂列金不计入下浮」的口径,周一重新判,还判成了不一样的结果;
- 审核结论前后矛盾,审核员得自己回去对账。
有记忆三件套的版本——周一从「存档点」续上:
周五:审完第 1–8 章 → 写检查点 checkpoint = { 已审: [第1-8章], 口径决定: { 桩基: "2024定额", 暂列金: "不计入下浮" }, ← 记忆 待办: [第9章 措施费, 第10章 其他项目费] }窗口快满 → 把前 8 章的逐条批注压成「8 条结论摘要」,过程丢弃 ← 压缩─────────────────────────────────────────周一:启动即载入 checkpoint → 跳过已审章节,沿用同一套口径 → 直接从第 9 章接着审,结论与周五一致转折点是那条「口径决定」记忆:它让周一的判断和周五锚定在同一把尺子上——记忆管的不只是「进度」,更是「别让口径飘」(口径治理见 设计指南/本体设计)。压缩则保证 200 页的长任务不会审着审着就爆窗口。
- 🚫 全塞进上下文,从不压缩 → 窗口爆掉,或越塞越「钝」(注意力被稀释)。
- 🚫 压缩时把关键状态也压没了 → 续作时口径/进度丢失,等于没存档。
- 🚫 记忆当垃圾桶 → 什么都记,召回时全是噪音;只记「非显而易见、未来还要用」的事实。
- 🚫 记忆与现实不同步 → 记的文件/字段已删却仍据此决策;召回后要先核验再用。
- 窗口是稀缺资源、怎么当守门人 → 设计指南/Agent设计/上下文管理
- 口径为什么会飘、怎么钉死 → 设计指南/本体设计
- 工具返回如何沉淀成检查点 → 设计指南/Agent设计/感知-行动循环