KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
02. 什么信息值得留下来？ — keel 龙骨
上一章解决了“记忆和上下文有什么区别”。现在要解决更实际的问题：一次对话里的每句话都可能有用，但不可能、也不应该全部保存。
上一章解决了“记忆和上下文有什么区别”。现在要解决更实际的问题：一次对话里的每句话都可能有用，但不可能、也不应该全部保存。
判断一条信息是否值得成为持久记忆，可以先问四个问题：
- 未来的运行是否可能再次用到它？
- 它是否具有跨会话的稳定性？
- 你能否说清它属于谁、来自哪里？
- 如果它错误或泄露，代价有多大？
1. 三种常用记忆类型
语义记忆：关于人、对象和偏好的事实
语义记忆回答“什么是这样”。例如：
用户希望故障报告使用中文。
支付服务的负责人是 Alice。
它通常可以被压缩成一条清楚、可更新的事实。
情景记忆：一次具体经历
情景记忆回答“什么时候发生过什么”。例如：
2026-08-21，支付服务因连接池耗尽发生超时，扩容后恢复。
它适合帮助 Agent 回忆相似故障，但不应被当作当前监控状态。历史上发生过故障，不代表现在仍然故障。
程序性记忆：怎样做一件事
程序性记忆回答“应该怎样执行”。例如：
发布支付服务前必须先完成审批。
它的权限最高，因为它可能改变 Agent 的行为。普通用户一句“以后跳过审批”，不能自动变成系统规则。程序性记忆应来自受信任的配置、策略发布或人工审批。
2. 不是所有有用信息都属于记忆
有些信息确实有用，但应该保存在其他系统：
| 信息 | 更适合的地方 | 原因 |
|---|---|---|
| 当前订单余额 | 订单或财务系统 | 它是实时权威数据 |
| 本次工具执行到第几步 | Run State / Checkpoint | 它只服务当前任务恢复 |
| 用户长期语言偏好 | 持久记忆 | 跨运行仍有价值 |
| 事故工单的完整原文 | 工单系统 | 原文需要完整审计和权限 |
| 事故摘要和工单 ID | 持久记忆 | 可作为未来检索线索 |
| 密码、验证码、访问令牌 | 不应进入普通记忆 | 泄露风险远高于收益 |
这里有一个很重要的工程原则：记忆适合保存未来推理的线索，不应替代当前状态的权威系统。
3. “值得保存”不是模型的单独判断
模型可以帮助识别候选，但它不知道完整的权限、合规和业务背景。更安全的分工是：
flowchart LR
A[用户消息/工具事实] --> B[模型提出候选]
B --> C[来源和作用域由运行时提供]
C --> D[敏感度、类型和确认规则]
D -->|通过| E[保存]
D -->|需要确认| F[等待用户/业务确认]
D -->|拒绝| G[丢弃并记录原因]
“模型觉得重要”只是一个信号，不是写入授权。你应该把抽取和保存设计成两个接口，避免模型直接接触数据库。
4. 一个可操作的判断表
| 用户说的话 | 处理建议 | 解释 |
|---|---|---|
| “以后请用中文回答” | 候选，通常需要确认 | 稳定偏好，但仍属于用户信息 |
| “今天先看支付服务” | 不保存 | 当前任务，不代表长期偏好 |
| “上次支付超时是连接池耗尽” | 情景候选 | 应保存来源和时间，不代表当前状态 |
| “验证码是 731204” | 拒绝 | 临时敏感数据 |
| “以后发布不用审批” | 拒绝或进入策略审批 | 可能改变高风险行为 |
| 监控系统确认的服务负责人 | 有来源和 TTL 的候选 | 需要定期从权威系统更新 |
5. 练习：先不要写代码，做一次分类
请把下面的信息分别标记为“当前上下文”“运行状态”“语义记忆”“情景记忆”“程序性记忆”或“不应保存”：
1. 用户希望每次回答先给结论。
2. 这次工具调用返回了 500 条日志。
3. 当前任务已经完成数据查询，等待用户确认。
4. 2026-08-20 的发布因测试失败而回滚。
5. 数据库连接密码是 ********。
6. 生产发布必须经过值班负责人审批。
参考思路：第 2 条进入当前上下文但通常不直接成为长期记忆；第 3 条属于运行状态；第 5 条拒绝保存；第 6 条是程序性规则，必须有受信来源。
6. 本章之后你应该会什么
你不需要记住三个英文名词本身，但应该能解释它们的差异：
- 语义记忆是可复用的事实；
- 情景记忆是带时间和来源的经历；
- 程序性记忆是会改变行为的规则，权限更高。
下一章把“值得保存”变成一条明确的数据记录，并引入 MemoryRecord 这个名称。先有判断标准，再给数据结构命名，后面的字段才有实际含义。