KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
07. 模型看到什么，系统保存什么？ — keel 龙骨
运行能循环起来以后，新的问题出现了：下一轮模型应该看到哪些内容？哪些内容只服务当前运行？哪些内容值得跨运行保存？
运行能循环起来以后，新的问题出现了：下一轮模型应该看到哪些内容？哪些内容只服务当前运行？哪些内容值得跨运行保存？
五个容易混淆的对象
| 对象 | 它解决的问题 | 典型寿命 |
|---|---|---|
| Chat history | 这次对话说过什么 | 当前 thread 或会话 |
| Context | 本次模型调用实际看到什么 | 当前调用 |
| Run state | 当前任务进行到哪一步 | 一次运行 |
| Checkpoint | 怎样从某个状态恢复 | 运行生命周期 |
| Long-term memory | 未来运行仍有价值的事实 | 可过期、更新、删除 |
可以把它们想成：聊天录音、这次会议桌上的材料、项目看板、看板快照和确认后写入知识库的条目。它们可能互相产生数据，但不能互相替代。
Context 是预算，不是仓库
当前上下文可能包含系统规则、当前问题、工具结果、摘要和记忆。它必须受到 token 预算约束，并且在每次模型调用前重新选择。
持久数据 --检索/授权/排序--> 当前上下文 --> 模型
当前运行 --候选抽取/写入策略--> 长期记忆
thinking 是生成过程中的推理字段，不能未经策略直接成为事实；工具结果是当前证据，也不自动成为长期记忆。
记忆在 Harness 中的位置
flowchart LR
A[认证后的运行上下文] --> B[记忆检索]
B --> C[Context Builder]
C --> D[模型循环]
D --> E[回答/工具结果]
E --> F[后台候选抽取]
F --> G[写入门禁]
G --> H[持久记忆]
Harness 决定何时读写、传入谁的作用域、给上下文多少预算；持久记忆子系统负责记录的生命周期、检索和删除。详细实践见持久记忆课程。
本章练习
把一个工具返回的 500 条日志放进下一轮上下文，再改成“摘要 + 证据 ID”。比较 token 数和模型能否找到关键证据。你会看到上下文工程是数据选择问题，不是简单地把 prompt 变长。
本章自测
- 为什么 checkpoint 保存了工具结果，也不代表工具结果值得长期记忆？
- 为什么一条记忆即使被检索到，也不能绕过当前工具权限？
- 为什么 Context Builder 应该保留来源和记忆 ID？