2026-08-26 · 上下文专题 · 总纲 整理自一段设计讨论：怎么判断一条信息/记忆值不值得留、该留多久、放哪。 配套（决策层）：记忆分层规则引擎：决策思路复盘（怎么一步步拍板的）；代码与规格在 V2 仓库。
记忆/上下文管理的难点，不在"能存多少"，在能不能快速判断出什么值得反复用，再按它的类型和用法决定放哪、留多久。
最初的直觉：长周期才有价值。修正之后：
- 长周期是底子：身份、原则、项目目标这类，确定性强，存一次能反复用。
- 短周期在活着的时候更顶用：今天的行情、这周的临时状态，在有效期内价值密度反而高。
- 关键是判断拐点：一条短周期信息反复出现，说明它正在变成长周期问题（热词天天用，就变成你的长期语境）；一条长周期信息没人再碰，说明它正在失效。判断"正在变长还是变短"，比单纯追求"存得久"重要。
有必要，三个实际好处：
- 力气花得不一样：长周期的精读、内化、存进知识骨架；短周期的扫一眼就行，用完就扔。不用对每条信息都花同样的力气。
- 收藏夹不再积灰：给信息标个保质期——长线的进知识库，短线的定时清空。"收藏"这个动作自带过期，就不会攒下一堆永远不看的。
- 不用每次纠结：规则定好就是条件反射——重要的细读，临时的快看。省的是每次决策的脑力。
成立，AI 长期记忆系统的核心逻辑就是这两条：
- 频率（后验）：重要的东西会反复出现。反复出现 = 权重高 = 从临时区升到长期区。
- 属性（先验）：出生时的类型决定活多久。人名、合同天生该长期存；天气、热搜天生该过期。
两条合起来用，是用频率检验属性猜得对不对：
- 属性该长命，但从来没人用 → 降级冷藏（占着位置没用）；
- 属性该短命，但反复出现 → 升级（它正在变成长周期问题）。
先验给初判，后验给修正，后验可以推翻先验。
能定出一套"什么信息放哪、放多久"的规则：
- 上下文分四档：
- 常驻：重要且常用，一直在上下文里（身份、核心约束）；
- 检索：重要但不常用，用的时候查进来（RAG）；
- 临时：不重要但这一轮要用，用完删；
- 不存：不重要也不常用，直接忽略。
- 满了删谁：不按先来后到删。删"不重要又久没用"的，保"重要"的。淘汰带着价值判断，不是纯顺序问题。
- 长周期信息不硬压缩：存"它变了什么"和"因果链"，不存流水账。流水账占地方、过期快；因果链占地方小、活得久。
- 每条信息带有效期：过期自动忽略。上下文的有效利用率靠每条信息的保质期，不靠窗口大小。
一句话：上下文管理的下一步，不是把窗口做大，是把取舍做聪明。
频率（实际用得多不多）+ 属性（天生该活多久）+ 有效期（现在过没过期）
三个维度回答同一个问题：这条信息现在该放哪、留多久。
这套思想不是空谈——记忆分层规则引擎 就是它的第一块落地，12 条规则和上面逐条对应：
| 思想层（本文） | 落地（规则引擎） |
|---|---|
| 属性：天生该活多久 | R1 类型查表、R2 变更成本判据 |
| 频率：实际用得多不多 | P1 召回 ≥3 次/30 天 → 升级长期 |
| 用频率检验属性 | "属性短但反复出现 → 升级"与 P1 同构 |
| 有效期 | L2 带 TTL，P2 到期降级（不静默删，防误杀） |
| 满了删谁：保重要的 | "以使用定生死，不以预测定生死" |
| 上下文四档 | L3 长期 / L2 工作 / L1 临时 / 不入库，一一对应 |
| 存因果链不存流水账 | "一条记忆只能有一个生命周期"（提取粒度） |
- 上下文四档落成真实的管理模块（V2 路线图候选）；
- "变化量 + 因果链"的抽取实现；
- 全局有效期元数据标准。
等需求出现再做（YAGNI）。