Skip to main content

双层记忆模型

羽忆将记忆分为两个语义截然不同的层，这是整个系统的核心设计决策。

为什么需要区分两层​

混淆记忆类型会直接破坏召回质量。"你上次的任务是什么" 和 "API 总是返回统一结构" 是两种从根本上不同的信息，它们的存储要求、召回策略、老化逻辑都不同。

Stable Memory（稳定记忆）​

存储已提炼的、跨会话保持稳定的事实性知识。

典型内容：

  • 项目架构约定（"所有 API 返回 {code, message, data} 结构"）
  • 用户偏好（"代码示例优先使用 Java"）
  • 领域规则（"金融模块必须记录审计日志"）

存储特性：

  • 按 semantic_key 去重，同一语义键只保留最高置信度版本
  • 支持冲突标记（hasConflict），召回时优先浮现
  • 长期有效，无自动过期

History Recall（历史召回）​

存储任务过程中的上下文快照，用于跨会话的工作连续性。

典型内容：

  • 任务摘要（"完成了用户认证模块，MailCodeService 处理 TTL"）
  • 决策记录（"选择 pgvector 而非 Elasticsearch，理由：部署复杂度"）
  • 错误记录（"JWT 方案因移动端兼容性问题放弃"）

存储特性：

  • 按时序存储，不去重
  • 有新鲜度权重，近期记录得分更高
  • 支持 30/90/365 天老化提示阈值

内存分配策略​

召回时，可通过 prefer 参数动态调整两层的 token 配额：

模式StableHistory适用场景
stable_first70%30%知识密集型任务
history_first30%70%工作连续型任务
balanced50%50%通用场景（默认）
stable_only100%—纯知识查询

数据模型​

// Stable Memory
{
  "id": "mem_a1b2c3d4",
  "content": "所有 API 统一返回 {code, message, data}",
  "memoryType": "project_rule",
  "semantic_key": "api-response-format",
  "importance": 0.9,
  "scope": { "projectId": "p_demo" },
  "status": "active",
  "hasConflict": false,
  "version": 1
}

// History Record
{
  "id": "rec_x9y8z7w6",
  "content": "完成用户认证模块，MailCodeService 用 Redis 管理 TTL",
  "recordKind": "task_summary",
  "agentId": "claude-agent-001",
  "scope": { "projectId": "p_demo" }
}