Agent数据价值分类存储原则

价值分类存储原则:大模型主动储存 × 框架设计自动储存

日期 :2026-08-12

定位 :架构设计原则文章------以「价值分类学 + 淘汰机制 + 召回预算」为可叠加的治理三环,补足「大模型主动储存」的治理短板,而非以对立范式取代它。

核心分类轴 :AI 运行数据的储存判定存在两条正交的轴,而非非此即彼的两类------

大模型主动储存(LLM Active Storage):判定权部分归属 LLM,由模型抽取事实、自行沉淀;

框架设计自动储存(Framework-Designed Automatic Storage):判定权归属框架,通过设计 LLM 的输出契约让数据自动入库。

本文论证:两轴是分工互补 而非互斥------LLM 擅长长周期语义价值判定,框架擅长结构价值判定与确定性治理;三环(价值分类 / 淘汰 / 召回预算)是两范式都需要的横切能力,补齐后大模型主动储存同样可避免膨胀失败。

关联文档:

Agent/数据驱动反应式Agent架构设计.md(反应式中枢 + PersistencePort)

Agent/docs/2026-08-09-Agent存储项目重构方案.md(Agent.Persistence 组合根)

docs/Introduction/Universal/06_数据库使用逻辑.md(双库设计理念)

摘要

当前主流 AI Agent 记忆方案(L0-L3 金字塔、Chat/Skill/Wiki/CodeGraph 四类资产、Team Memory 等)多采用大模型主动储存 :由 LLM 在运行中抽取事实、自行决定沉淀什么,框架只在事后做治理。这类方案在长期运行中暴露出一组可复现的风险------图谱膨胀不可控、旧逻辑删不掉、全量加载爆上下文、拼凑式逻辑------其根因不在于"LLM 参与判定"这一行为本身,而在于治理三环(价值分类 / 淘汰 / 召回预算)的缺失:无判定累积 + 软删除治理 + 事后裁剪 + 异构抽取,导致累积动机与治理能力不匹配。

本文并不主张以对立范式取代大模型主动储存,而是论证两种储存方式是分工互补的两条轴 ------LLM 的语义价值判定能力是框架难以替代的,框架的确定性治理能力是 LLM 不具备的。健康的记忆架构是二者的协同:LLM 负责长周期语义价值判定 (这段知识是否仍代表当前事实),框架负责结构价值判定与确定性治理(是否入事实表、是否在召回预算内、何时物理淘汰)。两者处在同一条价值判断链的不同环节,而非竞争关系。

基于上述互补视角,本文给出框架侧应提供的治理能力------框架设计自动储存 :框架预声明价值类别、在循环边界对每个数据点做结构化判定(有价值 / 无价值),有价值的全量长期自动入库,无价值的运行时即用即弃;LLM 的输出被框架设计为结构化契约,数据按契约自动流入储存。该治理闭环为三段式机制------入库判定(ValueClassifier)+ 周期淘汰(ValueDecayer)+ 召回预算(RecallBudgetGuard)------三组件均为框架级、确定性、非 AI 决定,与 DeterministicCoreDisjoint 硬约束天然对齐。这三环是可叠加的横切能力:既可作为范式 B 的完整实现,也可叠加到大模型主动储存(范式 A)之上补齐其治理短板。

本文给出三组件的接口契约、价值类别清单、与现有 StorageLayer/PersistencePort 的落地映射,并以两种储存方式为对照轴,与典型累积式记忆引擎、Mem0、传统快照+checkpoint 方案做对比------其结论不是"B 取代 A",而是"A 的治理缺口如何用 B 的三环补齐、二者如何按适用域分工"。

关键判据(确定性产物 vs 可重建的派生关系) :本文进一步澄清大模型主动储存的正确对象 ------它应当沉淀的是代码、文档、配置等确定性产物 (一手产出、可验证、丢失不可恢复),而不是引用关系 。引用关系(符号依赖、调用图、影响路径)本质是可重建的派生数据 ,正如 C# 编译产物 .obj/.dll 可从源码随时重新编译生成、不入版本库------只要确定性产物在库,引用关系随时可从其重新分析生成。因此引用关系应由框架在过程中记录、按需重建,而非作为长期记忆实体沉淀(详见 §4.1、§7)。这一判据从根上消解了 CodeGraph 类"图谱膨胀":膨胀的从来不是确定性产物,而是被误当不可再生记忆来存的可重建派生图。

根本论点(经济性判据) :构建记忆/知识图谱的本质动机是节约成本 (主要是 LLM token 与上下文重建成本)。若治理缺失,维护成本(存储 + 索引 + 治理 + 召回延迟)随累积量无界增长,而节约成本只随任务数线性增长(单次有界,受任务频率约束),维护成本中检索/索引/治理项还会随体积超线性 增长------此时维护成本增长率(超线性)> 节约成本增长率(线性) ,盈亏平衡点必然到来。这一倒挂并非范式 A 的本质属性,而是治理三环缺失 的必然结果:补齐价值分类、物理淘汰与召回预算后,维护成本可收敛到稳态有界。结论:判断记忆库成败的不是"谁判定",而是"治理是否闭环";大模型主动储存与框架设计自动储存是分工互补,框架的治理三环是让任意储存范式免于倒挂的工程基础。

目录 · 模块导览

阅读路径:立论(模块 1)→ 风险分析(模块 2-3)→ 方案设计(模块 4-7)→ 落地与对比(模块 8-9)→ 决策与展望(模块 10-11)→ 附录速查。

模块	标题	职责	依赖
模块 1	[两类储存范式的分工](# 接口与设计约束模块 5 模块 7 价值类别清单(框架预声明) 框架预声明的类别清单与衰减规则,含"确定性产物 vs 派生关系"判据模块 6 模块 8 落地映射项目落位、StorageLayer / PersistencePort 关系模块 6 · 7 模块 9 对比分析:两种储存范式对照与典型方案/快照做对照模块 1-4 模块 10 关键决策点(待拍板) 待治理流程拍板的决策清单模块 4-8 模块 11 结论与开放问题结论、开放问题、落地优先级全模块附录 A/B/C 术语表 / 硬约束对照 / 判定流程对照速查 —)	定义两条判定轴、范式 A/B 及互补关系、确定性产物 vs 派生关系判据、经济性判据(该不该建)	---
模块 2	[大模型主动储存的风险模式分析](# 接口与设计约束模块 5 模块 7 价值类别清单(框架预声明) 框架预声明的类别清单与衰减规则,含"确定性产物 vs 派生关系"判据模块 6 模块 8 落地映射项目落位、StorageLayer / PersistencePort 关系模块 6 · 7 模块 9 对比分析:两种储存范式对照与典型方案/快照做对照模块 1-4 模块 10 关键决策点(待拍板) 待治理流程拍板的决策清单模块 4-8 模块 11 结论与开放问题结论、开放问题、落地优先级全模块附录 A/B/C 术语表 / 硬约束对照 / 判定流程对照速查 —)	分析范式 A 在治理缺位时的四大风险与根因	模块 1
模块 3	[大模型主动储存的典型方案剖析](# 接口与设计约束模块 5 模块 7 价值类别清单(框架预声明) 框架预声明的类别清单与衰减规则,含"确定性产物 vs 派生关系"判据模块 6 模块 8 落地映射项目落位、StorageLayer / PersistencePort 关系模块 6 · 7 模块 9 对比分析:两种储存范式对照与典型方案/快照做对照模块 1-4 模块 10 关键决策点(待拍板) 待治理流程拍板的决策清单模块 4-8 模块 11 结论与开放问题结论、开放问题、落地优先级全模块附录 A/B/C 术语表 / 硬约束对照 / 判定流程对照速查 —)	剖析代表方案,展示治理缺口的共性	模块 2
模块 4	[框架设计自动储存:价值分类存储原则](# 接口与设计约束模块 5 模块 7 价值类别清单(框架预声明) 框架预声明的类别清单与衰减规则,含"确定性产物 vs 派生关系"判据模块 6 模块 8 落地映射项目落位、StorageLayer / PersistencePort 关系模块 6 · 7 模块 9 对比分析:两种储存范式对照与典型方案/快照做对照模块 1-4 模块 10 关键决策点(待拍板) 待治理流程拍板的决策清单模块 4-8 模块 11 结论与开放问题结论、开放问题、落地优先级全模块附录 A/B/C 术语表 / 硬约束对照 / 判定流程对照速查 —)	给出范式 B 核心原则与约束契合	模块 1
模块 5	[完整闭环:入库 + 淘汰 + 召回](# 接口与设计约束模块 5 模块 7 价值类别清单(框架预声明) 框架预声明的类别清单与衰减规则,含"确定性产物 vs 派生关系"判据模块 6 模块 8 落地映射项目落位、StorageLayer / PersistencePort 关系模块 6 · 7 模块 9 对比分析:两种储存范式对照与典型方案/快照做对照模块 1-4 模块 10 关键决策点(待拍板) 待治理流程拍板的决策清单模块 4-8 模块 11 结论与开放问题结论、开放问题、落地优先级全模块附录 A/B/C 术语表 / 硬约束对照 / 判定流程对照速查 —)	三组件闭环流程与职责边界	模块 4
模块 6	[三组件接口契约](# 接口与设计约束模块 5 模块 7 价值类别清单(框架预声明) 框架预声明的类别清单与衰减规则,含"确定性产物 vs 派生关系"判据模块 6 模块 8 落地映射项目落位、StorageLayer / PersistencePort 关系模块 6 · 7 模块 9 对比分析:两种储存范式对照与典型方案/快照做对照模块 1-4 模块 10 关键决策点(待拍板) 待治理流程拍板的决策清单模块 4-8 模块 11 结论与开放问题结论、开放问题、落地优先级全模块附录 A/B/C 术语表 / 硬约束对照 / 判定流程对照速查 —)	三组件 C# 接口与设计约束	模块 5
模块 7	[价值类别清单(框架预声明)](# 接口与设计约束模块 5 模块 7 价值类别清单(框架预声明) 框架预声明的类别清单与衰减规则,含"确定性产物 vs 派生关系"判据模块 6 模块 8 落地映射项目落位、StorageLayer / PersistencePort 关系模块 6 · 7 模块 9 对比分析:两种储存范式对照与典型方案/快照做对照模块 1-4 模块 10 关键决策点(待拍板) 待治理流程拍板的决策清单模块 4-8 模块 11 结论与开放问题结论、开放问题、落地优先级全模块附录 A/B/C 术语表 / 硬约束对照 / 判定流程对照速查 —)	框架预声明的类别清单与衰减规则,含"确定性产物 vs 派生关系"判据	模块 6
模块 8	[落地映射](# 接口与设计约束模块 5 模块 7 价值类别清单(框架预声明) 框架预声明的类别清单与衰减规则,含"确定性产物 vs 派生关系"判据模块 6 模块 8 落地映射项目落位、StorageLayer / PersistencePort 关系模块 6 · 7 模块 9 对比分析:两种储存范式对照与典型方案/快照做对照模块 1-4 模块 10 关键决策点(待拍板) 待治理流程拍板的决策清单模块 4-8 模块 11 结论与开放问题结论、开放问题、落地优先级全模块附录 A/B/C 术语表 / 硬约束对照 / 判定流程对照速查 —)	项目落位、StorageLayer / PersistencePort 关系	模块 6 · 7
模块 9	[对比分析:两种储存范式对照](# 接口与设计约束模块 5 模块 7 价值类别清单(框架预声明) 框架预声明的类别清单与衰减规则,含"确定性产物 vs 派生关系"判据模块 6 模块 8 落地映射项目落位、StorageLayer / PersistencePort 关系模块 6 · 7 模块 9 对比分析:两种储存范式对照与典型方案/快照做对照模块 1-4 模块 10 关键决策点(待拍板) 待治理流程拍板的决策清单模块 4-8 模块 11 结论与开放问题结论、开放问题、落地优先级全模块附录 A/B/C 术语表 / 硬约束对照 / 判定流程对照速查 —)	与典型方案/快照做对照	模块 1-4
模块 10	[关键决策点(待拍板)](# 接口与设计约束模块 5 模块 7 价值类别清单(框架预声明) 框架预声明的类别清单与衰减规则,含"确定性产物 vs 派生关系"判据模块 6 模块 8 落地映射项目落位、StorageLayer / PersistencePort 关系模块 6 · 7 模块 9 对比分析:两种储存范式对照与典型方案/快照做对照模块 1-4 模块 10 关键决策点(待拍板) 待治理流程拍板的决策清单模块 4-8 模块 11 结论与开放问题结论、开放问题、落地优先级全模块附录 A/B/C 术语表 / 硬约束对照 / 判定流程对照速查 —)	待治理流程拍板的决策清单	模块 4-8
模块 11	[结论与开放问题](# 接口与设计约束模块 5 模块 7 价值类别清单(框架预声明) 框架预声明的类别清单与衰减规则,含"确定性产物 vs 派生关系"判据模块 6 模块 8 落地映射项目落位、StorageLayer / PersistencePort 关系模块 6 · 7 模块 9 对比分析:两种储存范式对照与典型方案/快照做对照模块 1-4 模块 10 关键决策点(待拍板) 待治理流程拍板的决策清单模块 4-8 模块 11 结论与开放问题结论、开放问题、落地优先级全模块附录 A/B/C 术语表 / 硬约束对照 / 判定流程对照速查 —)	结论、开放问题、落地优先级	全模块
附录 A/B/C	[术语表 / 硬约束对照 / 判定流程对照](# 接口与设计约束模块 5 模块 7 价值类别清单(框架预声明) 框架预声明的类别清单与衰减规则,含"确定性产物 vs 派生关系"判据模块 6 模块 8 落地映射项目落位、StorageLayer / PersistencePort 关系模块 6 · 7 模块 9 对比分析:两种储存范式对照与典型方案/快照做对照模块 1-4 模块 10 关键决策点(待拍板) 待治理流程拍板的决策清单模块 4-8 模块 11 结论与开放问题结论、开放问题、落地优先级全模块附录 A/B/C 术语表 / 硬约束对照 / 判定流程对照速查 —)	速查	---

模块 1 · 两类储存范式的分工

AI 运行数据(对话、决策、执行结果、事件、token 流......)的储存判定,可从两条正交的轴 观察:谁做语义价值判定(LLM / 人),谁做结构治理(框架)。本文以「判定权归属」为主分类轴,区分范式 A 与范式 B------但必须强调:二者是分工,不是对立。

1.1 范式 A:大模型主动储存(LLM Active Storage)

定义:入库判定权归属 LLM。模型在运行中自行抽取「值得记住」的事实并主动沉淀,框架只负责承接 LLM 的抽取输出,不做前置判定。

适用优势(为何不能简单否定) :LLM 具有跨领域、长周期的语义价值判定 能力------它能理解"这段对话暗含的用户长期偏好""这个失败模式未来会再次出现"这类无法用静态规则枚举的意义。这恰是框架规则判定的短板。范式 A 的问题不在"由 LLM 判定"本身,而在缺少数量的结构治理(分类/淘汰/预算)。

储存对象澄清(关键判据) :LLM 主动储存的正确对象是确定性产物 ------代码、文档、配置、决策结果(一手、可验证、丢失不可恢复)。它不应沉淀引用关系(符号依赖、调用图、影响路径):这类数据是可重建的派生关系,只要确定性产物在库即可随时重新分析生成。"让 LLM 主动存引用关系图"是把可重建的派生数据误当不可再生的记忆来存------这正是 CodeGraph 类方案膨胀的根因(完整判据与 C# 编译产物类比见 §7)。

典型代表:

典型累积式记忆引擎 L0-L3 金字塔(服务端 LLM 自动抽取 L1 原子记忆);
Mem0(LLM 抽取个性化事实写入 KV);
Letta(模型自行决定记忆块更新);
任何「让 LLM 自己总结要点并写入记忆库」的设计。

核心特征:

入库判定宽松:LLM 抽取以「宁多勿少」为隐含原则,框架不做二分过滤;
储存策略累积:一旦 LLM 写入即长期保留,治理靠版本/Owner/ACL 等软删除机制;
召回策略全量倾向:主动召回 + 工具召回并行,以「塞越多越准」为隐含假设;
裁剪策略事后:超出 token 上限时,靠「上下文窗口管理」补丁式裁剪。

1.2 范式 B:框架设计自动储存(Framework-Designed Automatic Storage)

定义:入库判定权归属框架。框架预声明价值类别,在循环边界对每个数据点做结构化判定;LLM 的输出被设计为结构化契约,数据按契约自动流入储存。

适用优势 :框架提供确定性、可治理、可审计 的结构判定------是否入事实表、是否在召回预算内、何时物理淘汰。这些判定要求一致性与可重放性,正是 LLM 不擅长的(非确定性、不可复现)。范式 B 的价值在于为任意判定(含 LLM 的语义判定)提供结构护栏。

典型代表:

本文的价值分类存储原则(ValueClassifier + ValueDecayer + RecallBudgetGuard);
任何「框架在循环边界决定落库、AI 不决定」的设计。

核心特征:

入库判定严格:框架预声明价值类别,二分判定(Valuable / Discarded),无中间态;
储存策略极致:有价值者全量长期自动入库,无价值者运行时即用即弃(不进入 cell);
召回策略预算化 :RecallBudgetGuard 事前截断,永不全量加载;
淘汰策略周期化 :ValueDecayer 周期重判 + 物理删除,与软删除对立。

1.3 两种范式的根本区别对照

维度	大模型主动储存(范式 A)	框架设计自动储存(范式 B)
判定权归属	LLM	框架
入库触发	LLM 抽取后写入	框架在循环边界按契约收集
LLM 角色	判定者 + 写入者	输出生产者(不参与判定)
入库粒度	宽松,宁多勿少	严格,二分判定
储存语义	累积,只增不删	全量有价值 + 舍弃无价值
淘汰机制	软删除(版本/Owner/ACL)	周期重判 + 物理删除
召回策略	全量倾向 + 事后裁剪	召回预算上限 + 事前过滤
数据模型	多 schema 拼凑	统一抽象(`ur_*` 事实表)
维护成本增长	O(累积量),无界	稳态 O(1)(经 ValueDecayer 物理淘汰收敛,见下注)
「自动」的语义	LLM 自动抽取并写入	框架自动按契约入库
失败模式	6-12 个月图谱膨胀爆掉	无累积,无膨胀可能

注(维护成本阶) :范式 B 的「稳态 O(1)」以 ValueDecayer 物理淘汰为前提------淘汰使已入库量收敛到稳态规模,不再随运行时间无界增长。对个别「永不 Purge / 永不衰减」类别(决策迹、输入事件、失败结果,见 §7),须以摘要化 / 总量上限 / 冷归档承载,否则其累积会退化为线性,破坏该阶的成立前提。
注(二分覆盖边界) :本文的「两类」是分析工具 而非穷尽分类------实际系统往往是混合形态。(1) 快照 + checkpoint 由框架全量捕获,判定权属框架但无价值分类,是范式 B 的退化形态(见 §9.3);(2) Team Memory 的判定权可能落在人 Owner 而非 LLM,是「非框架判定」的第三种来源(见 §3.3);(3) 更普遍的是「LLM 建议 + 框架裁决」的混合链路(见 §10.4)。这些中间态恰说明:两范式不是互斥的终点,而是判定链上可调用的不同环节。

一句话总结 :两种范式的区别不在「存什么」,而在「谁在哪一环判定」------LLM 判语义价值,框架判结构治理,二者互补。范式 A 若补上三环治理、范式 B 若允许 LLM 提供语义建议,它们会在"治理闭环"这一点上收敛。

1.4 经济性方程:成本收益倒挂的形式化

记忆库的根本动机是节约成本,但维护它本身也有成本。把问题形式化为净收益方程:

复制代码

Net(t) = Σ C_task_saved(i) - Σ C_recall(i) - C_maintain(t)
       (节约的成本)        (召回的成本)    (维护的成本)

成本项	大模型主动储存的增长率	框架设计自动储存的增长率
`Σ C_task_saved(i)`	O(N) ------ 每次任务省一份	O(N)
`Σ C_recall(i)`	O(N) ------ 召回随任务线性	O(N) ------ 但预算有界
`C_maintain(t)`	O(累积量),超线性 ------ 存储线性、索引/治理/检索延迟随体积超线性增长	稳态 O(1) ------ 入库有过滤 + 已入库有淘汰(存储收敛到稳态)+ 召回与 Store 大小无关
净收益趋势	`O(N) - O(N) - O(累积量) → -∞`	`O(N) - O(N) - O(1) → 正值且稳定(前提:单任务净节约 > 0)`

关键观察:

单次节约有界 :单次任务省 token 最多省到任务本身的 LLM 调用成本,这是硬上限(但随任务数累加的 Σ C_task_saved(i) 仍为 O(N),即总量线性、单次有界)。
维护成本无界(范式 A):存储随累积线性增长、向量检索延迟随数据量增长、治理(版本/Owner/ACL)检查随资产数增长、淘汰尝试(若有)也随累积增长。
盈亏平衡点必然到来 :C_maintain(t) 增长率 > Σ C_task_saved(i) 增长率,在某个 t* 处 Net(t*) = 0,之后 Net(t) < 0 且单调下降。
不可逆性(缺治理时) :若只靠软删除治理,即使意识到倒挂也难以清理(只能标记不能删除)。但这是治理缺位的不可逆,而非范式 A 的本质不可逆------补上物理淘汰后,倒挂即可被纠正,即「经济失败需靠治理闭环来防」。

界定(「必然」的成立条件) :「维护增长率 > 节约增长率」的关键是范式 A 维护成本含随体积超线性 增长的检索/索引/治理项,而节约成本仅随任务数线性增长。若只比较存储一项(两者同阶线性),倒挂并不必然。故「必然」须限定于范式 A 含超线性维护项的前提;范式 B 因维护收敛到稳态 O(1),该前提不成立。

框架设计自动储存(范式 B)在经济方程下的表现:

ValueClassifier 把无价值数据挡在库外 → 累积源头被切断;
ValueDecayer 周期物理淘汰 → C_maintain 不随时间累积;
RecallBudgetGuard 召回与 Store 大小无关 → C_recall 不随数据量膨胀。

三组件合起来把 C_maintain 从「O(累积量)」压到「稳态 O(1)」(经 ValueDecayer 物理淘汰,已入库量收敛到稳态规模,不再随运行时间无界增长),在经济性上根除倒挂可能,而不只是缓解技术症状。注:稳态 O(1) 的前提是淘汰覆盖所有类别------对「永不 Purge / 永不衰减」类别(§7),须以摘要化、总量上限或冷归档承载,否则会退化为线性累积。

1.5 经济性判据落地:该不该建记忆库?(含估算与阈值)

职责声明:本章为「该不该建记忆库」的唯一权威判定位置;§10 仅保留交叉引用。

经济性判据下,真正的问题不是「如何建记忆库」,而是**「该不该建」**:

复制代码

ShouldBuild(domain):
  if 预期 Σ C_task_saved < 预期 C_maintain:
      → 不建,直接每次重新计算
  else:
      → 建,但必须配框架三环治理(确保 C_maintain 有界)

很多场景下答案是不建:

短周期任务:任务自洽,无跨会话沉淀价值;
强一致性场景:过时记忆反而是噪声,召回负收益;
低重复度场景:每次任务都是新的,无经验复用;
小型项目:维护成本直接超过节约成本。
长周期 + 高重复度 + 弱一致性场景 → 建,且必须配框架的治理三环(分类/淘汰/预算)确保有界。

落地所需的估算方法与判定阈值

经济性方程(见 §1.4)给出判定框架,但实际落地需明确如下参数:

如何估算 Σ C_task_saved:基于历史任务负载做采样统计------典型任务的 LLM 调用成本 × 跨会话沉淀命中率;
如何估算 C_maintain :框架设计自动储存下 C_maintain 有界,可用 P0 阶段实测数据外推;大模型主动储存下需假设无界增长做长期外推;
判定阈值 :当 预期 C_maintain / 预期 Σ C_task_saved > 0.5 时,即应审视是否建库;> 1.0 时直接弃建;
建议:在 P0 阶段同时输出「该不该建」判定报告,作为价值分类原则的前置门禁。

这些场景强行建记忆库,就是把「省 token」变成「烧 token 省不了 token」。本文的框架设计自动储存适用于「该建」的场景;对于「不该建」的场景,正确决策是根本不建。

模块 2 · 大模型主动储存的风险模式分析

本章分析范式 A(大模型主动储存)在治理三环缺失 条件下暴露的四大风险。这些风险并非"由 LLM 判定"这一行为的必然宿命,而是判定权与治理能力不匹配的结果------LLM 做语义判定却无人为它的累积结果做结构治理。认清这一点是找到解药的关键:解药不是取消 LLM 判定,而是补上框架治理。

模块定位 :承接 [模块 1](#模块 1) 的范式 A 定义,逐条分析其治理缺口;其补齐方案(三环)在 [模块 4](#模块 4) 给出,代表性方案佐证见 [模块 3](#模块 3)。

2.1 现象一:图谱膨胀不可控

以 CodeGraph 为例,其作用是「索引仓库的符号 / 文件 / 调用关系 / 影响路径」。在真实大型项目(>10 万行代码、>1 万符号)下:

符号节点数随代码量线性增长;
调用关系边数随符号数平方级增长;
影响路径计算需全图遍历;
仓库演进后,旧符号关系无 TTL、无版本淘汰机制。

结果是 CodeGraph 在 6-12 个月内膨胀到无法维持:全量加载超 100 万 token,无法塞入任何主流 LLM 上下文。

缺口归因 :LLM 抽取符号关系时不会主动舍弃旧关系(对它而言,多存一条不影响本次任务),而框架又未提供物理淘汰------语义判定的天然累积倾向 × 框架治理缺位共同导致膨胀。

根本解法(关键判据) :CodeGraph 的符号依赖、调用关系、影响路径本质是可重建的派生关系 (参见 §7 关键判据)------只要源码/文档这些确定性产物 在库,引用图随时可从其重新分析生成。因此正确做法不是"努力为膨胀的图做淘汰",而是根本不把引用图当作长期记忆实体沉淀:需要时由框架从确定性产物重建、在过程中记录、可清理。膨胀问题的根源是"把可重建的派生数据误当不可再生的记忆来存"。

2.2 现象二:旧逻辑删不掉

L0→L1→L2→L3 抽取沉淀后,原始 L0 仍被保留(白盒可溯源要求);L1 原子事实在 L2 场景中重复出现;L3 用户画像引用 L2,删除任一下层都会破坏上层可追溯性。治理层提供:

版本号(可回滚但不可物理清理);
Owner 标识(归属管理而非生命周期);
ACL 可见性(访问控制而非删除控制);
强制归档(确保不遗失,反向加剧累积)。

这些机制本质是软删除------「标记可用」而非「物理清除」。结果是历史决策、过时偏好、废弃 SOP 永久占据存储与召回预算,即使业务已演进入新阶段。

缺口归因 :LLM 写入时只考虑「现在有用」,框架又缺少物理淘汰,二者叠加导致历史层删不掉------问题不在 LLM 判定,而在缺少能突破"可溯源锁死"的物理淘汰策略。

2.3 现象三:全量加载爆上下文

主动召回 + 工具召回并行设计,默认假设是「召回越多越准」。但 LLM 上下文窗口是硬上限:

GPT-4 Turbo:128K token;
Claude 3.5 Sonnet:200K token;
即便 Gemini 1.5 Pro 的 2M token,在 6 个月累积的 CodeGraph + Chat Memory + Wiki 面前也捉襟见肘。

补救手段是「上下文窗口管理」:当任务上下文膨胀时,将暂时无关的历史片段卸载至持久化存储,需要时再回调。但这是事后裁剪,本质上仍承认「召回策略可以超量」,只是把超量问题延后到运行时。

缺口归因 :LLM 主动召回倾向于「多召回以提升本次任务准确率」,把 token 预算问题甩给框架------缺一个事先的召回预算守卫,把"超量"从设计默认改为被禁止的路径。

2.4 现象四:拼凑式逻辑

四类记忆资产(Chat Memory / Skill / Wiki / CodeGraph)是四套独立 schema:

资产	数据形态	召回方式	演进路径
Chat Memory	对话序列 → L0/L1/L2/L3 抽取	关键词 + 向量	对话级累积
Skill	SOP + 触发边界 + 验证规则	关键词匹配	任务级累积
Wiki	文档结构化 + 链接图谱	关键词 + 文档树	文档级累积
CodeGraph	符号 / 调用 / 影响路径	图查询 + 向量	仓库级累积

四套 schema 各自演进,治理面板(Memory Hub)做表层统一,但底层无统一抽象。这种拼凑导致:

资产间引用关系混乱(Chat Memory 引用 Wiki?Skill 引用 CodeGraph?);
淘汰规则无法跨资产统一(删 Skill 是否连带删其引用的 CodeGraph 节点?);
召回预算无法跨资产统一计算(每类资产各自召回,token 总量无界)。

缺口归因 :LLM 对不同类型数据有不同的抽取习惯,框架被动承接且无统一抽象,最终形成多 schema 拼凑------缺一个统一的价值分类抽象来收拢异构输出。

2.5 根因归纳

风险模式	根因	对应治理三环缺口
图谱膨胀不可控	无判定累积 + 无 TTL + 无版本淘汰	缺「淘汰」(ValueDecayer)
旧逻辑删不掉	软删除治理 + 白盒可溯源强约束反向锁死	缺「淘汰」(物理删除)
全量加载爆上下文	召回策略默认全量倾向 + 事后裁剪	缺「召回预算」(RecallBudgetGuard)
拼凑式逻辑	多 schema 独立演进 + 无统一抽象	缺「价值分类」(ValueClassifier) 的统一抽象

核心根因一句话 :大模型主动储存的风险,不在"LLM 参与判定",而在只做了粗粒度的语义判定、却没有配套的结构治理(无分类、无淘汰、无预算)------判定权与治理能力脱节。因此解药是补上治理三环,而非废黜 LLM 判定。

模块 3 · 大模型主动储存的典型方案剖析

本章剖析范式 A 的几个典型方案,说明它们形态各异但共享同一组治理缺口------它们的失败都可用"缺三环"解释,也因此都可通过补三环改善,而非必须推倒重来。

3.1 典型累积式记忆引擎 L0-L3 金字塔:压缩不等于舍弃

层级	内容	处理方式
L0 原始对话	用户/助手消息原文	全量保留
L1 原子记忆	事实/偏好/指令	服务端自动抽取,保留 L0 指针
L2 场景分块	场景模式	聚合 L1,保留 L1 指针
L3 用户画像	稳定结论	沉淀 L2,保留 L2 指针

金字塔的设计目标是「白盒可溯源」------L3 结论可逐级下钻至 L0 原始证据。但这一目标反向锁死了淘汰机制:任一层级的物理删除都会破坏上层溯源链 。结果是「压缩」(L0→L3 形态变换)≠「舍弃」(数据真正消失),只是降低单层访问成本,不降低总存储量。

判定归属:L1 由服务端 LLM 自动抽取,属大模型主动储存------其价值正是 LLM 的语义抽取能力,缺口在于缺少物理淘汰与召回预算。

3.2 四类资产:拼凑式 schema

如 §2.4 所述,四类资产是四套独立设计。其本质矛盾是:

Chat Memory 是时序数据(对话流);
Skill 是过程数据(SOP 步骤);
Wiki 是结构数据(文档树);
CodeGraph 是图数据(符号关系)。

四种数据模型在底层无法统一,只能靠 Memory Hub 在表层做「资产管理」门面。这种拼凑并非范式 A 的必然宿命,而是治理三环缺失 的结果------缺统一的价值分类抽象来收拢异构输出。若由框架提供 ur_* 统一抽象做结构收口,LLM 的异构抽取同样可被归拢。

但更关键的是 CodeGraph 的类别错位 :Chat/Skill/Wiki 是确定性产物 (对话、SOP、文档,丢失不可再生),而 CodeGraph 的符号关系是可重建的派生关系------只要源码在库,图可从源码重新分析生成(见 §7 关键判据)。把"可重建的派生数据"和"不可再生的确定性产物"放在同一优先级长期沉淀,正是 CodeGraph 膨胀的根因。正确做法:CodeGraph 应降为过程记录,随源码确定性产物按需重建。

3.3 Team Memory:治理替代淘汰

Team Memory 的核心机制是:

每条记忆有 Owner;
每条记忆有版本;
每条记忆有可见性(private / team / restricted);
共享需 Owner 主动发起。

这套机制解决的是「记忆资产归属与访问控制」问题,而非「记忆生命周期管理」问题 。Owner 不会主动删除自己的记忆(累积对自己有利),版本机制使得即便 Owner 想清理,也只能「标记归档」而非「物理清除」。Team Memory 实际上用治理替代了淘汰------以为管理好「谁可见」就等于管理好「该不该存在」,这是范式性误判。

判定归属:Owner(LLM 或人)主动决定储存与共享,判定权在语义侧------其价值是保留人对知识的自主权,缺口在于框架未提供客观的淘汰依据,只能依赖 Owner 的自律。

3.4 上下文卸载:事后裁剪的工程补丁

短期记忆的「上下文卸载」机制:任务上下文膨胀时,将冷数据迁移至持久化存储,释放窗口空间给关键状态。这是对全量召回失败的事后补救:

假设:召回可以超量,运行时再裁剪;
现实:裁剪逻辑需要识别「冷数据」,这本身就是一次价值判定;
矛盾:如果框架能判定「冷数据」,为什么不在入库时就判定「无价值」?

卸载机制的存在,说明"全量召回 + 事后裁剪"这条路不可持续------但这恰恰反证了价值判定应前置:框架若能判定"冷数据",就应当把它在入库时就判为低价值,交由淘汰机制处理。这与 LLM 是否参与语义判定无冲突。

判定归属:卸载是范式 A 内部的工程补丁,试图在不改变判定权归属的前提下缓解症状------治标不治本,但补丁本身证明了框架具备"判定冷热"的能力,只是使用位置偏晚。

模块 4 · 框架设计自动储存:价值分类存储原则

本章给出范式 B 的工程实现------价值分类存储原则。其核心是把判定权从 LLM 收回框架,通过设计 LLM 的输出契约让数据自动入库。

模块定位 :承接 [模块 1](#模块 1) 的范式 B 定义与 [模块 2](#模块 2) 的失败诊断,给出核心原则;三组件闭环流程见 [模块 5](#模块 5),接口契约见 [模块 6](#模块 6),落地映射见 [模块 8](#模块 8)。

4.1 核心原则

AI 的运行数据应分为有价值与无价值两类:有价值的全量、长期、自动储存;无价值的运行时即用即弃。整体价值由框架设计决定,而非 AI 决定。

该原则包含三个可独立落地的子命题:

二分判定:数据在产生时即被框架判定为有价值 / 无价值,无中间态(语义判定可由 LLM 提供,但结构判定收敛为二分的入库决策);
极致处置:有价值者全量长期自动入库;无价值者运行时即用即弃(不进入 cell,不占 Transient 内存);
判定权属框架(结构层) :价值类别由框架预声明,入库/淘汰/预算规则由框架执行------LLM 可参与语义价值判断(见 §10.4),但结构裁决权在框架。

「有价值」的判定标准(关键判据) :不是"这段数据有用"就值得长期存,而要看它是否满足确定性产物特征------一手产出、可验证、不可从别处重建。具体地:

✅ 值得长期存(确定性产物):代码、文档、配置、决策结果、执行结果------丢失不可恢复,是事实源;
❌ 只作过程记录(可重建的派生关系):引用关系、符号依赖、调用图、影响路径------只要确定性产物在库,随时可从其重新分析生成。

据此,LLM 主动储存的正确对象是确定性产物 ,而非可重建的派生关系。后者应由框架在过程中生成、按需重建,不沉淀为长期记忆实体(完整判据与 C# 编译产物类比见 §7)。

「自动储存」的语义澄清 :这里的「自动」指框架自动 ,非 LLM 自动。LLM 按框架设计的输出契约生产数据(并可提供语义价值建议),框架在循环边界按契约收集并做出入库裁决。这一设定不排斥 LLM 参与语义判断------它只保证结构治理的确定性,是判定链上框架这一环的职责。

4.2 与现有架构约束的契合

本原则与项目硬约束高度一致:

项目硬约束	本原则对应
`DeterministicCoreDisjoint`(确定性核心单一写者,不做越权写预算)	结构判定权属框架,LLM 不触碰确定性核心(语义建议仅作输入)
`StateRootSingleSource`(单 `IStorageEngine` 根)	储存统一入口,无多 schema 拼凑
写回数据库 = 框架决定,非 AI 决定	自动储存的「自动」指框架自动,非 AI 自动
落库由框架经 PersistencePort 在循环边界决定	入库判定在循环边界执行
Transient 层永不进入 PersistencePort	无价值者比 Transient 更彻底------直接舍弃,不进 cell

4.3 与范式 A 的互补分工

本节易被误读为"范式对立"。事实上,两轴是分工而非"谁对谁错":LLM 贡献语义价值判断(范式 A 的强项),框架贡献结构治理(范式 B 的强项)。维度级对照见 §1.3,此处只点明互补关系。

两轴在同一判定链上的分工:

入库:LLM 提语义候选,框架做结构裁决;
储存:累积需配淘汰才有界;
淘汰:物理淘汰补软删除之短;
召回:预算守卫约束语义召回;
数据模型:统一抽象收拢异构输出;
治理与淘汰:二者需并存,而非以治理替代淘汰。

结论 :范式 A 与范式 B 不是替代关系,而是判定链上两个环节的分工------语义价值判断交给 LLM(或人),结构治理交给框架。本文的核心工程贡献,是把范式 B 的三环(分类/淘汰/预算)抽象为可叠加到任意储存范式之上的治理能力。

模块 5 · 完整闭环:入库 + 淘汰 + 召回

无论由谁判定(LLM 或框架),完整的记忆治理都必须在入库判定之外补全淘汰与召回预算两环,否则会重蹈累积无界的覆辙:

复制代码

   数据产生(LLM 按契约输出)
      │
      ▼
┌─────────────────┐
│ ValueClassifier │  ← 入库判定(框架级,确定性)
│  有价值?        │
└─────────────────┘
      │
      ├─ 有价值 → 全量长期自动入库(ur_* 事实表)
      │              │
      │              ▼
      │         ┌──────────────┐
      │         │ ValueDecayer │  ← 周期重判 + 物理淘汰
      │         │  价值衰减?   │
      │         └──────────────┘
      │              │
      │              ├─ 仍 valuable → 保留
      │              └─ 已 decayed → Purge(物理删除)
      │
      └─ 无价值 → Discard(运行时即用即弃,不进 cell)


   召回请求
      │
      ▼
┌──────────────────────┐
│ RecallBudgetGuard    │  ← 召回预算上限
│  按 max_tokens 截断  │
└──────────────────────┘
      │
      ▼
   LLM prompt(永不全量)

注 :ValueDecayer 的衰减并非一步 Purge,而是按 §7 的 Full → SummaryOnly → HashOnly → Purge 阶梯逐级降级;上图为简化的二分示意。对「永不 Purge」类别(决策迹、输入事件、失败结果),衰减停留在 SummaryOnly/HashOnly,不进入最终 Purge。

三组件职责边界:

组件	触发时机	输入	输出	失败模式(若缺失)
`ValueClassifier`	数据产生时(循环边界)	data_point	Persist / Discard 决策	无价值数据累积,Transient 层膨胀
`ValueDecayer`	周期触发(commit / checkpoint / 定时)	已入库数据集	保留 / Purge 决策	旧逻辑删不掉,图谱膨胀
`RecallBudgetGuard`	召回请求时	query + max_tokens	截断后的结果集	全量加载爆上下文

模块 6 · 三组件接口契约

6.1 ValueClassifier

csharp 复制代码

namespace Agent.Persistence.Core;

/// <summary>价值类别,由框架预声明。</summary>
public enum ValueCategory
{
    /// <summary>有价值:全量长期自动入库。</summary>
    Valuable,
    /// <summary>无价值:运行时即用即弃,不进入 StorageCell。</summary>
    Discarded,
}

/// <summary>
/// 入库前价值判定器(框架级,确定性,非 AI 决定)。
/// 在循环边界对每个 data_point 做二分判定。
/// </summary>
public interface IValueClassifier
{
    /// <summary>判定数据点是否值得入库。</summary>
    /// <param name="dataPoint">待判定数据点(已封装为 ValueCandidate)。</param>
    /// <returns>Valuable → 入库;Discarded → 直接舍弃。</returns>
    ValueCategory Classify(in ValueCandidate dataPoint);
}

/// <summary>待判定数据点。</summary>
public readonly struct ValueCandidate
{
    public required string Category { get; init; }      // 数据类别(决策迹/执行结果/事件/...)
    public required string Source { get; init; }        // 来源(模块/执行器)
    public required ReadOnlyMemory<byte> Payload { get; init; }  // 序列化负载
    public required DateTimeOffset OccurredAt { get; init; }
    public required string? ThreadId { get; init; }     // 关联线程(可空)
    public required string? RoundId { get; init; }      // 关联轮次(可空)
}

设计约束:

Classify 必须纯函数(无副作用、确定性):相同输入永远相同输出,便于重放与测试;
判定规则由框架配置驱动(ur_strategy 表热加载),不依赖运行时状态;
严禁调用 LLM 或外部服务做判定(违反 DeterministicCoreDisjoint,也违反范式 B 的判定权归属原则);
ValueCandidate.Category 必须来自框架预声明的类别清单(ur_strategy),未登记 / 非法类别一律 Discard 并按配置错误记录------防止 LLM 输出随意类别绕过分类(与「框架预声明」的类别封闭性一致)。

6.2 ValueDecayer

csharp 复制代码

namespace Agent.Persistence.Core;

/// <summary>
/// 周期淘汰器(框架级,确定性)。
/// 对已入库数据做价值重判,将价值衰减者物理删除。
/// </summary>
public interface IValueDecayer
{
    /// <summary>执行一轮淘汰扫描。</summary>
    /// <param name="policy">淘汰策略(保留窗口、衰减规则)。</param>
    /// <param name="ct">取消令牌。</param>
    /// <returns>本轮淘汰统计(物理删除条数、释放空间)。</returns>
    Task<DecayReport> RunAsync(DecayPolicy policy, CancellationToken ct = default);
}

/// <summary>淘汰策略。</summary>
public sealed class DecayPolicy
{
    /// <summary>各类别的保留窗口(轮次数 / 天数 / 条数)。</summary>
    public required IReadOnlyDictionary<string, RetentionWindow> Windows { get; init; }
    /// <summary>衰减规则:全量保留 → 仅留摘要 → 仅留哈希 → Purge。</summary>
    public required IReadOnlyList<DecayStage> Stages { get; init; }
    /// <summary>本轮扫描的类别范围(null = 全部)。</summary>
    public string[]? ScopeCategories { get; init; }
}

public sealed record RetentionWindow(int? Rounds, int? Days, int? MaxCount);

public enum DecayStage
{
    Full,        // 全量保留
    SummaryOnly, // 仅留摘要
    HashOnly,    // 仅留哈希指针
    Purge,       // 物理删除
}

public sealed record DecayReport(
    int ScannedCount,
    int PurgedCount,
    long BytesFreed);

设计约束:

物理删除,非软删除 :DecayStage.Purge 直接从 ur_* 表 DELETE,不留版本/归档;
可重放、可幂等:同一策略多次执行结果一致;
淘汰报告入库 :自身执行记录也走 ValueClassifier(有价值者入库,供可观测);
触发时机:框架在 commit / checkpoint 边界触发,或定时任务触发,均非 AI 决定。

6.3 RecallBudgetGuard

csharp 复制代码

namespace Agent.Persistence.Core;

/// <summary>
/// 召回预算守卫(框架级,确定性)。
/// 在召回结果返回前按 max_tokens 截断,永不全量加载。
/// </summary>
public interface IRecallBudgetGuard
{
    /// <summary>在预算内召回。</summary>
    /// <param name="query">召回查询(关键词/向量/混合)。</param>
    /// <param name="budget">召回预算(token 上限)。</param>
    /// <param name="ct">取消令牌。</param>
    /// <returns>截断后的结果集 + 截断统计。</returns>
    Task<RecallResult> RecallAsync(RecallQuery query, RecallBudget budget, CancellationToken ct = default);
}

public sealed class RecallQuery
{
    public required string Text { get; init; }
    public string[]? Categories { get; init; }    // 限定类别
    public string? ThreadId { get; init; }        // 限定线程
}

public sealed record RecallBudget(int MaxTokens, int MaxItems);

public sealed record RecallResult(
    IReadOnlyList<RecalledItem> Items,
    int UsedTokens,
    int TruncatedCount,
    bool BudgetExhausted);

public sealed record RecalledItem(
    string Category,
    ReadOnlyMemory<byte> Payload,
    int EstimatedTokens,
    float RelevanceScore);

设计约束:

事前预算,非事后裁剪:召回在 SQL/向量检索阶段即带 LIMIT,不在内存中裁剪;
预算由框架配置 (ur_strategy 表),AI 不可改;
截断统计入库:截断次数、预算耗尽频率作为效率指标,供观测优化;
永不返回全量:即使 Store 中只有少量数据,也强制走预算路径,避免路径分歧。

模块 7 · 价值类别清单(框架预声明)

下表是初始价值类别清单,由框架在 ur_strategy 表预声明,可通过配置热加载扩展。注意 :这些类别由框架预声明,LLM 在产生数据时按类别契约输出,框架按类别规则判定入库------类别结构由框架决定,语义内容的价值可交由 LLM 提供建议(见 §10.4),但最终入库裁决在框架。

类别	是否有价值	储存方式	衰减规则	现有承载
决策迹(switch_strategy、budgetTerminate、终止裁决)	✅	全量 append-only 长期	N 轮后仅留摘要,永不 Purge	`ur_events`
执行结果(Cline/MCP/Guardrails 输出)	✅	全量长期	M 天后仅留哈希,失败结果永不衰减	`ur_outputs`
输入事件(外部写入触发源)	✅	全量 append-only 长期	永不衰减(事实源)	`ur_inputs` / `ur_events`
checkpoint(LangGraph 兼容状态)	✅	全量长期	父链超过 K 跳后 Purge 中间节点	`ur_checkpoints`
资源(确定性产物:代码 / 文档 / 配置)	✅	全量长期	引用计数为 0 后 Purge	`ur_resources`
引用关系(符号依赖 / 调用关系 / 图谱边)	❌ 过程记录	不沉淀事实表,按需重建	分析时生成,过程内记录(同编译产物 `.obj/.dll`)	(建议移除 `ur_references`,或降级为派生缓存)
配置 / 策略(配置即数据行)	✅	全量长期	旧版本 Purge,仅留当前 + N 回滚	`ur_config` / `ur_strategy`
中间临时态(轮内计算中间值、reducer 合并前 partial)	❌	直接舍弃	不入库	(现为 Transient,建议升级为 Discard)
LLM 原始 token 流(未沉淀为决策的)	❌	直接舍弃	不入库	(现走 `AgentLog`,建议降级为调试可选)
未触发的探测分支	❌	直接舍弃	不入库	无承载
调试日志(`AgentLog.Log` 埋点)	❌	直接舍弃	不入库,生产环境关闭	`AgentLog` 现状

关键判据:确定性产物 vs 可重建的派生关系

上表隐含一条常被忽略的价值判据------区分"确定性产物"与"可重建的派生关系":

	确定性产物(存)	派生关系(过程记录)
定义	一手产出,可验证、不可从别处重建	二手关系,可从确定性产物重新生成
示例	代码、文档、配置、决策结果	引用关系、符号依赖、调用图、影响路径、图谱边
类比(C#)	源码 `.cs`(版本库长期保存)	编译产物 `.obj/.dll/.pdb`(随时可重建,不入版本库)
价值	是事实源,LLM 主动储存的对象	是推导结果,由框架在过程中生成
缺失代价	丢失不可恢复	丢失可从源码重新分析重建

推论 :引用关系(CodeGraph 的符号依赖、调用关系、影响路径)本质是可重建的派生数据------只要源码/文档这些确定性产物在库 ,引用关系随时可从它们重新分析生成。因此它不应作为长期记忆实体沉淀进 ur_references,而应像编译产物一样在需要时生成、在过程中记录、可被清理后重建。这从根上消解了 §2.1 的"图谱膨胀"------膨胀的不是确定性产物,而是被误当长期记忆沉淀的可重建派生图。

关键差异点:

决策迹永不 Purge:这是审计与可观测的底线,但通过「摘要化」降存储;
引用关系不沉淀为事实 :引用关系(依赖/调用图)属可重建的派生数据,不在 ur_references 长期沉淀,由框架在过程中生成、按需重建(见上文"关键判据");
执行结果失败者永不衰减:失败是教训,价值高于成功;
配置旧版本 Purge 而非归档:回滚窗口有限,超出即物理删除;
调试日志直接舍弃 :这是与「白盒可溯源」的取舍------本原则认为运行日志不是事实,不进事实源;若确需可溯源,通过 decision_trace 摘要与 execution_result 承担,而非全量保留日志。

⚠ 有界性约束 :上表中「永不 Purge」(决策迹)与「永不衰减」(失败结果、输入事件)三类,其「永不」指证据不物理删除 ,但为支撑范式 B「存储稳态有界」的核心经济主张(§1.4),三者的承载必须降级到有界形态------决策迹走摘要化或总量上限(MaxCount)约束(与其「衰减到 SummaryOnly」一致),失败结果走总量上限(MaxCount)约束(其「永不衰减」要求保留 Full,故不能用摘要化),输入事件严格 append-only 但可压缩 / 冷归档。否则这三类会无限累积,使 C_maintain 退化为 O(N),动摇本文根除倒挂的核心论点。

模块 8 · 落地映射

8.1 项目落位

三组件均落位于 $Agent.Persistence/Core/$ (file:///d:/Project/Program/WorkFlowPrj/Agent/docs/2026-08-09-Agent存储项目重构方案.md#L101-L130),作为业务无关的通用逻辑:

复制代码

Agent.Persistence/
├─ Abstractions/
│   ├─ IPersistenceStore.cs
│   ├─ ICheckpointStore.cs
│   └─ ...
├─ Core/
│   ├─ AgentPersistenceStore.cs      # 现有门面
│   ├─ SnapshotSerializer.cs         # 现有
│   ├─ CheckpointReducer.cs          # 现有
│   ├─ ValueClassifier.cs            # 新增:入库判定
│   ├─ ValueDecayer.cs               # 新增:周期淘汰
│   ├─ RecallBudgetGuard.cs          # 新增:召回预算
│   └─ PersistenceException.cs
├─ Configuration/
│   └─ ...
└─ Sqlite/ ...

8.2 与 StorageLayer 三分层的关系

本原则是 StorageLayer 三分层的判定前置,不替代分层:

复制代码

判定流程:
  data_point
      │
      ▼
  ValueClassifier.Classify(data_point)        ← 新增前置层(价值判定)
      │
      ├─ Valuable  → StorageLayer.Config / Session → PersistencePort → SQLite
      └─ Discarded → Discard(不进入 cell)

StorageLayer	原语义	加入价值判定后的语义
Config	静态声明 / 配置	价值类别 = Valuable,长期落盘
Session	运行时状态(快照语义)	价值类别 = Valuable(决策/结果/事件),全量入库;快照仅作为崩溃恢复手段
Transient	瞬态(TTL 回收)	建议降级:原 Transient 的语义被 Discard 取代,不进 cell,运行时即用即弃

8.3 与 PersistencePort 的关系

PersistencePort 在循环边界调用,执行顺序变为:

复制代码

Persist(session):
  1. for each data_point in session:
       if ValueClassifier.Classify(data_point) == Valuable:
           collect into persist_batch
       else:
           discard  # 不进 cell,不进 batch
  2. serialize persist_batch(Config/Session 层)
  3. write to SQLite within transaction
  4. (周期性) ValueDecayer.RunAsync(policy)

RebuildCell(db) 启动恢复路径不变------只重建 Valuable 数据,Discarded 数据本就不在 DB 中。

8.4 配置驱动

价值类别清单、衰减规则、召回预算均由 ur_strategy 表配置驱动:

json 复制代码

{
  "ValueCategories": {
    "decision_trace": { "Valuable": true, "DecayStage": "SummaryOnly", "Retention": { "Rounds": 100 } },
    "execution_result_success": { "Valuable": true, "DecayStage": "HashOnly", "Retention": { "Days": 30 } },
    "execution_result_failure": { "Valuable": true, "DecayStage": "Full", "Retention": null },
    "input_event": { "Valuable": true, "DecayStage": "Full", "Retention": null },
    "llm_token_stream": { "Valuable": false },
    "debug_log": { "Valuable": false }
  },
  "RecallBudget": {
    "DefaultMaxTokens": 8000,
    "DefaultMaxItems": 50,
    "PerCategoryOverrides": {
      "decision_trace": { "MaxTokens": 2000 },
      "execution_result_failure": { "MaxTokens": 4000 }
    }
  }
}

改 DB 即改框架行为,无需部署------契合项目「配置即数据行」原则。

模块 9 · 对比分析:两种储存范式对照

本章以两条判定轴为对照,与典型方案做对比,说明它们的差异点是治理完备度而非范式标签------补上治理三环,各方案都能走向收敛。

模块定位 :对照对象承接 [模块 2-3](#模块 2-3)(范式 A 治理缺口的实证)、[模块 4](#模块 4)(治理三环);结论汇总见综合对比表 §9.4。

9.1 vs 典型累积式记忆引擎

维度	典型累积式记忆引擎(范式 A)	价值分类原则(范式 B)
范式归属	大模型主动储存	框架设计自动储存
入库判定	LLM 抽取,宽松	框架预声明类别,严格二分
储存语义	累积 + 软删除	全量有价值 + 物理淘汰
数据模型	4 类资产(Chat/Skill/Wiki/CodeGraph)拼凑	统一 `ur_*` 事实表
淘汰机制	缺失(版本/Owner/ACL 是软删除)	`ValueDecayer` 周期物理淘汰
召回策略	主动召回 + 工具召回,事后裁剪	`RecallBudgetGuard` 事前预算
多 Agent 共享	Team Memory 原生支持	暂不支持,可作为后续扩展
语义检索	向量 + BM25 + RRF 融合	暂不支持,可作为 `RecallQuery` 扩展
失败模式	6-12 个月图谱膨胀爆掉	无累积,无膨胀可能

注(关键判据) :表中"4 类资产"里的 CodeGraph 与 Chat/Skill/Wiki 存在类别错位 ------后三者是确定性产物(丢失不可再生),而 CodeGraph 的符号关系是可重建的派生数据,只要源码在库即可重新分析生成(见 §7 关键判据)。范式 A 把可重建的派生图与不可再生的确定性产物同优先级长期沉淀,才是"图谱膨胀"的真正根因;范式 B 将派生关系降为过程记录,故无膨胀可能。

9.2 vs Mem0

Mem0 是轻量化记忆层,核心是「个性化事实存储」,比典型累积式记忆引擎简单,但同样属于范式 A(大模型主动储存):

入库:LLM 抽取事实,无框架判定;
储存:轻量 KV,无淘汰;
召回:关键词 + 向量,无预算。

Mem0 的失败模式与典型累积式记忆引擎相同,只是规模更小、膨胀更慢。

9.3 vs 传统快照 + checkpoint

传统方案(以本 Agent 项目 P0 阶段为代表):

入库:全量快照 + checkpoint;
储存:按时间点切片;
淘汰:保留最近 N 个快照;
召回:不召回(快照用于恢复,不用于上下文)。

本方案是「按时间生命周期分层」,与「按价值分类」是正交维度。本原则不替代快照+checkpoint,而是在其前加一层价值判定:有价值的数据才进入快照/checkpoint 流程,无价值的根本不进。

分类界定 :快照 + checkpoint 由框架全量自动捕获、不含 LLM 判定,故不属于范式 A(判定权不在 LLM);但它也未做价值分类(全量入库),故也不构成完整范式 B。它属于「框架判定权 + 无价值分类」的中间形态,是范式 B 价值判定的前置基础设施(判定前置见 §8.2)。因此综合对比表(§9.4)不将其归入范式 A。

9.4 综合对比表

方案	范式归属	入库判定	淘汰机制	召回预算	数据模型统一性	适用场景
典型累积式记忆引擎	A:大模型主动储存	LLM 抽取	软删除	事后裁剪	4 schema 拼凑	短期对话助手
Mem0	A:大模型主动储存	LLM 抽取	无	无	单 KV	轻量个性化
传统快照+checkpoint	框架全量(判定权属框架,无价值分类;非范式 A)	全量	时间窗口	不召回	单一	状态恢复
价值分类原则	B:框架设计自动储存	框架判定	物理淘汰	事前预算	统一	长周期数据驱动 Agent

模块 10 · 关键决策点(待拍板)

落地本原则需明确以下决策,本文不预设答案,留给项目治理流程:

模块定位 :面向治理流程的待拍板清单,依赖 [模块 4](#模块 4)(原则)、[模块 5-6](#模块 5-6)(机制与接口)、[模块 7](#模块 7)(类别清单)、[模块 8](#模块 8)(落地);其中「该不该建」的经济性判据唯一权威位于 §1.5。

10.1 「全量」是否覆盖 LLM 原始 token 流?

选 A:不覆盖(默认)。Token 流无价值,只存决策摘要。优点:存储省、与「白盒可溯源到决策」对齐;缺点:失去细粒度调试能力。
选 B:覆盖。Token 流全量入库。优点:完全可追溯;缺点:存储膨胀,违反「价值分类」初衷。
本文倾向 A 。注意:选 A(token 流不入库)则库内无 token 流可留哈希指针------这与 §7 将 token 流列为「直接舍弃、不入库」一致。完整性校验应改由已入库的 decision_trace 摘要承担;若确需 token 级校验,仅在调试模式下于库外(不参与召回的独立哈希表)保留轻量哈希,不写入 ur_* 事实表。

10.2 「自动储存」的触发点是否仍是 commit/checkpoint 边界?

现有硬约束:框架在 commit/checkpoint 边界执行写入。
本原则的「自动」指框架自动,非 AI 自动------二者不冲突。
建议:保持 commit/checkpoint 边界触发,新增「周期性 ValueDecayer 触发」(定时或每 N 轮)。

10.3 「直接舍弃」的语义是「不落盘」还是「运行时也不保留」?

现有 Transient 层:不落盘但占用内存。
本原则的「直接舍弃」似乎倾向「运行时即用即弃」。
建议升级 :新增 Discard 语义,比 Transient 更彻底------不走 StorageCell.Set,用本地变量 + GC 自然回收。

10.4 淘汰策略是否需要 LLM 参与?

严格按 DeterministicCoreDisjoint:不允许 LLM 参与。
但复杂语义判定(如「这段决策摘要是否仍代表当前业务事实」)规则化困难。
建议:全部走规则化(配置驱动),复杂语义通过框架预声明的类别规则近似;确实需要 LLM 判定时,LLM 输出仅作为建议,最终决策仍由框架规则执行。

10.5 是否需要支持跨 Agent 共享(Team Memory)?

典型累积式记忆引擎的 Team Memory 是其优势之一。
本原则当前不支持,但可在 ur_* 表中加 agent_id / team_id 字段做隔离,共享通过显式授权实现。
建议:作为后续扩展,不进 P0。

注 :关于「何时根本不该建记忆库」的经济性判据,唯一权威位置为 §1.5,此处不再重复。

模块 11 · 结论与开放问题

11.1 结论

大模型主动储存(范式 A)的膨胀风险,根源不在"由 LLM 判定"这一行为,而在治理三环的缺失 (四大风险与根因归纳见 §2.5):无分类累积致膨胀、软删除治理致删不掉、全量召回致爆上下文、多 schema 拼凑致无法统一治理。

关键判据 :真正的记忆只有确定性产物 值得长期存(代码、文档、配置,丢失不可恢复);引用关系是可重建的派生数据 ,应由框架在过程中生成、按需重建,不沉淀为长期记忆实体------据此"图谱膨胀"并非不可解(详见 §7)。

框架设计自动储存(范式 B)提供的是可叠加的治理三环 ,而非与之竞争的替代品:结构判定 + 二分处置避免无价值数据累积、物理淘汰避免旧逻辑删不掉、召回预算避免全量加载、统一 ur_* 抽象收拢异构输出。

因此,本文的工程结论是:大模型主动储存与框架设计自动储存并不冲突------前者是语义价值判定的一环,后者是结构治理的一环,二者处在同一条判定链上。健康记忆架构 = LLM(或人)的语义判断 + 框架的分类/淘汰/预算护栏。判断记忆库成败的标准是"治理是否闭环",而非"判定权归属谁"。

三组件(ValueClassifier / ValueDecayer / RecallBudgetGuard)均落位于 $Agent.Persistence/Core/$ (file:///d:/Project/Program/WorkFlowPrj/Agent/docs/2026-08-09-Agent存储项目重构方案.md#L101-L130),框架级、确定性,与项目现有硬约束(DeterministicCoreDisjoint、StateRootSingleSource、PersistencePort 边界)天然对齐,可作为任意储存范式的治理底座。

11.2 开放问题

价值类别清单的完备性:本文 §7 的初始清单是否覆盖所有运行数据类别?需在实际运行中迭代校准。
衰减规则的语义合理性:「N 轮后仅留摘要」的 N 如何选择?需基于真实负载做 KPI 驱动的调参。
召回预算的动态化:当前固定预算,是否需要按任务类型动态调整?如长任务 vs 短任务。
与可观测的关系:被 Discard 的数据如何保证不破坏可观测性?需明确「观测需要的最小数据集」由哪类 Valuable 数据承担。
与外部记忆引擎的集成 :若未来确实需要外部记忆引擎的语义检索能力,如何作为 PersistenceProvider 接入而不破坏价值分类原则?预想路径:外部记忆引擎只承载 RecallQuery 的向量检索部分,RecallBudgetGuard 仍由本框架执行。
范式边界的灰度:若某些场景确实需要 LLM 参与判定(如复杂语义衰减),如何在「框架最终决策权」前提下安全引入 LLM 建议?参见 §10.4。

11.3 落地优先级建议

阶段	内容	验收
P0	`ValueClassifier` + 价值类别清单 + Discard 语义	无价值数据不再进 cell;`ur_*` 表无膨胀
P1	`ValueDecayer` + 衰减规则配置	周期淘汰跑通;物理删除可重放
P2	`RecallBudgetGuard` + 召回预算配置	召回永不全量;截断统计入库
P3	衰减规则调优 + 召回预算动态化	长周期运行 6 个月后,Store 大小稳定

附录 A:术语表

术语	定义
大模型主动储存(范式 A)	入库判定权归属 LLM,由模型自行抽取事实并沉淀的储存范式
框架设计自动储存(范式 B)	入库判定权归属框架,通过设计 LLM 输出契约让数据自动入库的储存范式
累积式记忆库	范式 A 的典型实现,入库宽松 + 储存累积 + 召回全量,主流分层记忆引擎多采用此范式
价值分类学	范式 B 的核心原则,框架对 AI 运行数据做二分判定(有价值 / 无价值)
确定性产物	一手产出、可验证、丢失不可恢复的数据(代码 / 文档 / 配置 / 决策结果),是长期记忆的对象
可重建的派生关系	可从确定性产物重新生成的关系数据(引用 / 依赖 / 调用图 / 影响路径),类比 C# 编译产物 `.obj/.dll`,由框架在过程中生成、按需重建,不沉淀为长期记忆实体
价值衰减	已入库数据随时间 / 轮次推进,价值等级下降的过程(Full → SummaryOnly → HashOnly → Purge)
物理淘汰	从 `ur_*` 表 DELETE 数据,不留版本/归档,与软删除对立
召回预算	召回时返回数据量的 token 上限,由框架配置,AI 不可改
框架级判定	判定逻辑由框架确定性执行,不调用 LLM,不依赖运行时状态

附录 B:与项目硬约束的对照

项目硬约束	本原则的实现
所有函数必须通过 FunctionContext 传参	三组件接口签名遵循
执行必须经过 NodeExecutor + WorkflowContext	淘汰周期触发通过 NodeExecutor 调度
新功能通过增强现有循环实现,不新建模块	三组件增强 `Agent.Persistence/Core/`,不新建项目
模块注册用反射 `TryRegister*`	`AddAgentPersistence` 中 `TryRegister` 三组件
落库由框架经 PersistencePort 在循环边界决定	入库判定在 `Persist(session)` 内执行
Transient 层永不进入 PersistencePort	Discard 语义更彻底,不进 cell
写回数据库 = 框架决定,非 AI 决定	三组件全部框架级(范式 B 的判定权归属)
诊断数据存内存,不导出	淘汰报告入 `ur_events`,调试日志直接舍弃

附录 C:两种范式的判定流程对照

复制代码

范式 A:大模型主动储存(缺治理三环时)
─────────────────────────────────
LLM 运行
  └─ LLM 自行抽取「值得记住」的事实(语义判定)
       └─ 框架被动承接,写入累积库
            └─ 治理层软删除(版本/Owner/ACL)------缺物理淘汰
                 └─ 召回全量倾向 + 事后裁剪------缺召回预算
                      └─ 累积无界,6-12 个月膨胀爆掉


范式 B:框架设计自动储存(治理三环)
─────────────────────────────────
LLM 按框架契约输出结构化数据
  └─ 框架在循环边界收集 data_point
       └─ ValueClassifier 二分判定(结构判定)
            ├─ Valuable → 全量长期入库(ur_*)
            │              └─ ValueDecayer 周期物理淘汰
            └─ Discarded → 运行时即用即弃(不进 cell)
       └─ RecallBudgetGuard 事前预算召回
            └─ Store 大小长期稳定


范式 C:协同(范式 A 的语义判定 + 范式 B 的治理三环)------推荐
─────────────────────────────────
LLM 运行
  └─ LLM 提供语义价值建议(哪些知识值得长期记)
       └─ 框架 ValueClassifier 结构裁决(建议是否入事实表)
            ├─ Valuable → 全量长期入库 + ValueDecayer 周期淘汰
            └─ Discarded → 即用即弃
       └─ RecallBudgetGuard 事前预算召回
            └─ Store 大小长期稳定,同时保留 LLM 的语义判断

作者注 :本文的出发点是对"大模型主动储存 + 治理缺位"这一组合的根因分析,但结论不是以范式 B 取代范式 A,而是指出两种储存方式并不冲突------LLM(或人)的语义价值判定与框架的结构治理处于同一条判定链的不同环节。任何「LLM 决定存什么 + 无分类 + 软删除 + 全量召回」的设计,都因治理缺位而面临膨胀风险;补上价值分类 + 物理淘汰 + 召回预算三环后,即便保留 LLM 判定,也能免于该风险。把"治理三环"抽象为可叠加的工程能力,是本文的最小完备贡献。