Nox-Lumen Automemory-sdk
能力
提供完整的长期记忆（LTM）管理 API：
| 工具 | action | 用途 |
|---|---|---|
record_knowledge | write | 写入/更新记忆 |
record_knowledge | delete | 删除记忆 |
record_knowledge | list | 列出所有记忆 |
unified_search | search | 按语义检索记忆 |
5 种记忆类型
| 类型 | 用途 | 示例 |
|---|---|---|
fact | 客观事实 | "项目用 Java 17 + PostgreSQL 15" |
preference | 用户偏好 | "偏好简洁中文输出，不要 emoji" |
program | 操作流程 | "部署流程：lint → test → build → push" |
error_pattern | Bug 模式 / 误报 | "心跳超时必须触发断连" |
chunk_node | KB 认知分组 | 检索后自动记录（通常不手动调用） |
默认行为
如果用户没有显式配置，Agent 会在合适时机自动：
- 把用户明确陈述的偏好写入
preference - 把项目约束与事实写入
fact - 把可复用的工作流写入
program - 把踩过的坑 / 误报写入
error_pattern
触发方式
自然语言示例：
- "帮我记住我偏好中文回复"
- "从现在起记住这个项目的编码规范是 Google Java Style"
- "忘掉刚才我让你记的那个约定"
- "列出你对我的所有记忆"
Hook 配置模板
memory-sdk 提供了几种内置的记忆策略 Hook：
| Hook | 触发时机 | 默认行为 |
|---|---|---|
on_user_preference | 用户陈述偏好时 | 自动写入 preference |
on_error_learn | Agent 执行出错后 | 分析根因写入 error_pattern |
on_task_complete | 任务完成时 | 总结流程写入 program |
可在 Agent 配置里启用或关闭。
延伸：结构化数据 → LTM 的加工范式
以上两节讲的是单轮交互的记忆流（对话中产生记忆）。除此之外，平台还有另一条记忆流：
把 KB 里结构化数据，定时加工成 LTM 洞察
Rendering diagram…
这套范式的第一个实现是 bug-import——它把一条条独立的 Bug 记录，按模块/跨模块/文件/根因四维聚合，定时产出 bug_pattern 类的 fact，供 L2 代码审核命中。
为什么值得单独说
单轮交互产生的记忆是碎片化的（一条 preference、一条 fact），它们回答"Agent 应该怎么跟我交互"的问题。
而结构化数据加工产生的记忆是聚合性的，它们回答"这个项目 / 这家企业沉淀出了什么规律"——这是"组织记忆"，不是"个人偏好"。
可扩展的加工器类型
按相同的"KB → 定时 cron → LTM fact"范式，理论上可以做：
| 加工器 | 输入 | 产出的 LTM fact | 用途 |
|---|---|---|---|
bug-import（已实现） | 历史 Bug | bug_pattern | L2 审核命中 |
| 需求变更加工器（假想） | 需求变更历史 | 高频改动点 / 需求反复方向 | 需求评审预警 |
| 审查意见加工器（假想） | 历史 review 评论 | 常见批评点 / 争议方向 | 开发者自检清单 |
| 事故报告加工器（假想） | 生产事故 postmortem | 高频事故类型 / 预防措施 | SRE 变更评审 |
目前只有 bug-import 一个实现。加工器本身就是 skill——要新增加工器，可以通过 skill-architect 按 bug-import 的模式设计。
底层架构抽象
这套范式的架构层描述见 核心概念 · Memory 记忆系统 — 加工路径。
相关概念
- 核心概念 · Memory 记忆系统
- Hook 系统
- graft — 另一种跨会话协作方式（Session 级，粒度粗）