Nox-Lumen MfgMemory 记忆系统
为什么需要 Memory
单个 Session 的上下文是短期的，而用户需要：
- 保留跨 Session 的关键事实（客户偏好、既往决策）
- 接入领域知识库（专利语料、汽车规范、企业规章）
- 让 Agent 在需要时检索相关背景
Memory 层级
| 层级 | 生命周期 | 典型内容 |
|---|---|---|
| Session Memory | 当前会话 | 当前对话历史、工作变量 |
| User Memory | 跨会话、属于用户 | 个人偏好、常用术语 |
| Tenant Memory | 跨用户、属于组织 | 企业规章、术语表、模板 |
| Knowledge Base | 外部接入 | 领域文档、参考资料、历史产出 |
记忆检索
系统支持多种检索方式：
- 语义检索 — 基于向量相似度
- 关键词检索 — 精确匹配
- 结构化查询 — 按元数据（时间、作者、标签）
跨会话搜索
通过 Graft 技能，Agent 可以在用户授权下跨 Session 检索和引用成果。
从 KB 到 LTM 的加工路径
KB（Knowledge Base）和 LTM（Long-Term Memory）在平台里承担不同职责：
| KB | LTM | |
|---|---|---|
| 粒度 | 大颗粒（整篇文档 / 一条 Bug 记录） | 小颗粒（一条 fact / preference） |
| 存储 | 原文 + 向量索引 | 结构化 fact + 溯源元数据 |
| 用途 | 精确 RAG 检索原始内容 | 检索已加工的规律与洞察 |
| 写入 | 用户导入或系统产出 | Agent 在对话中沉淀 或 定时加工器产出 |
两者不是替代关系，而是层级关系——KB 是原始素材，LTM 是从素材中加工出来的规律。
两条记忆流
平台里的 LTM fact 来源于两条并行的流：
Rendering diagram…
流 1（对话即时）：单轮交互触发，粒度碎片化，回答"Agent 该怎么跟我说话"。承载者是 memory-sdk。
流 2（KB 加工）：定时批量触发，粒度聚合，回答"这个项目 / 这家企业沉淀出了什么规律"。承载者是加工器类 skill。
加工器范式（通用模板）
任何"把 KB 中某类结构化数据加工成 LTM fact"的 skill，都遵循同一套模板：
| 环节 | 内容 |
|---|---|
| 触发 | 跟随平台 LTM cron（默认 6h），非实时 |
| 增量 | 只处理未打 ltm_extracted_at 标记的条目 |
| 聚合维度 | 按领域特征设计多维聚合（典型 2–4 维） |
| confidence | 基线 + 数量加权 + 严重度加权，上限 0.95 |
| 溯源 | source_*_ids 记录来自哪些原始条目 |
| 更新 vs 新增 | 比对 source_*_ids 决定是 update 还是 insert |
| 误报回溯 | 原始条目被标无效时，下次 cron 重算并降 confidence / 删除 |
| 容量保护 | 单次产出上限 + 单条长度上限 + 溯源列表上限 |
已实现的加工器
| 加工器 | 输入（KB） | 输出（LTM） | 消费端 |
|---|---|---|---|
| bug-import | 历史 Bug 记录 | bug_pattern 四维 fact | L2 code-review |
未来扩展（需求变更加工器、审查意见加工器、事故报告加工器等）可以按同一范式实现——新加工器本身就是 skill，通过 skill-architect 按 bug-import 的模式设计即可。
为什么加工环节是定时的
| 原因 | 说明 |
|---|---|
| 模式需要累积 | 单条数据看不出模式，必须 ≥N 条后才能聚合 |
| 成本可控 | 加工成本（LLM 调用 + 聚合计算）集中在 cron 周期，不阻塞业务交互 |
| 避免半成品 | 实时加工会在数据刚进来时产出"1 条证据支持"的 fact，既浪费又污染 LTM |
| 自然对齐业务节奏 | Bug / 需求变更本身就是定期批量事件，加工节奏对齐即可 |
相关文档
- Session 会话
- Graft 跨会话嫁接
- Cron 定时调度 — 加工器的触发机制
- memory-sdk — LTM 读写底层 API
- bug-import — 加工器范式的首个实现