Skip to content

RomiVu/mi-mirror

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

2 Commits
 
 
 
 
 
 

Repository files navigation

mi-mirror

mirror, mirror, tell me about meself...


面向个人长期可信记忆系统的架构设计文档

版本:Draft v0.1 定位:Personal Trusted Memory System for LLM-driven Personal Intelligence


1. 文档目标

本文档定义一个面向个人使用的长期记忆系统架构。该系统围绕用户个人生活、工作、关系、目标、经历与日常事务构建,目标是形成一个:

  • 可长期演化的个人外部记忆系统
  • 可供 LLM / agent 在任务中调用的可信上下文基础设施
  • 可由用户持续校对、澄清、修订的记忆治理系统
  • 在安全边界上明确区分普通记忆与高敏感秘密信息

该系统的核心目标不是“尽可能自动记住一切”,而是:

以可靠、可追溯、可确认、可修订为前提,逐步构建一个面向个人的长期可信记忆基础设施。


2. 设计目标与非目标

2.1 设计目标

G1. 长期可信

系统应优先保证记忆的可信度,而非覆盖率。 对于未确认、存在冲突、时间线可疑、观点/事实混淆的信息,系统应显式保留不确定性,而不是强行固化为“真相”。

G2. 人机共建

系统应允许并鼓励用户参与:

  • 确认关键记忆
  • 澄清冲突
  • 修订过时信息
  • 否决错误推断
  • 周期性回顾与补全

G3. 面向任务服务

系统应支持在具体任务中,为 LLM / agent 提供适量、相关、可信的上下文,而不是把所有历史记忆粗暴注入上下文窗口。

G4. 分层治理

系统应区分:

  • 当前工作记忆
  • 情节记忆(事件)
  • 语义记忆(稳定事实)
  • 关系记忆
  • 偏好与习惯
  • 敏感引用对象

G5. 安全边界清晰

密码、恢复码、私钥等高敏感秘密不得进入普通语义记忆系统。 系统只维护其外围引用和生命周期元信息,不接触秘密正文。

G6. 可解释与可审计

系统对任何高价值记忆应能回答:

  • 记忆来自哪里
  • 何时被确认
  • 是否存在冲突
  • 为什么当前版本被视为有效
  • 被哪些任务使用过

2.2 非目标

NG1. 不追求完整模拟生物大脑

系统不试图模拟人脑全部认知机制,不涉及意识、自我、完整心智建模。

NG2. 不将所有信息都自动长期化

并非所有对话内容都应该进入长期记忆。系统应对长期写入设置门槛。

NG3. 不承载高敏感秘密正文

系统不存储密码、助记词、私钥、OTP 等明文内容。

NG4. 不把 LLM 当作唯一事实仲裁者

系统不依赖模型“主观判断”来决定最终事实,而是依赖证据、版本、时间、用户确认和治理规则。


3. 总体设计原则

P1. 可信优先于全面

宁可少记,不能错记并长期污染。

P2. 记忆对象必须带证据

关键记忆必须能追溯到来源,而不是只存压缩后的自然语言摘要。

P3. 允许不确定性存在

系统应允许“候选”“冲突中”“待确认”“疑似过期”等状态存在。

P4. 事实、观点、情绪、解释分离

系统必须区分用户说过的话、发生过的事、用户对此的解释,以及当时情绪。

P5. 遗忘和降权是一级能力

不是所有信息都应该永远保持高权重。

P6. 高敏感资产与普通记忆彻底解耦

秘密内容由外部安全系统处理,记忆系统仅维护非重建型引用。


4. 系统概览

系统由五个核心子系统组成:

  1. Memory Capture

    • 接收原始输入和事件
    • 包括聊天、语音转写、手工录入、文档摘要、外部信号
  2. Memory Interpretation

    • 从原始内容中抽取候选记忆
    • 完成事件抽取、实体关系抽取、时间解析、观点识别、冲突检测
  3. Memory Governance

    • 决定是否进入长期记忆
    • 管理确认、冲突、审计、周期复核、归档、删除
  4. Memory Storage

    • 多层存储不同类型记忆
    • 包括 session、episodic、semantic、relationship、secret reference
  5. Memory Serving

    • 面向任务编排检索和上下文装配
    • 只返回与任务相关且可信度足够的记忆

5. 核心概念模型


5.1 Memory Object

系统中的长期记忆单元统一抽象为 MemoryObject。 每条记忆都不是一段散文本,而是一个带有类型、状态、证据、时间与版本的对象。

通用字段建议

{
  "memory_id": "mem_xxx",
  "memory_type": "fact | event | opinion | preference | relationship | secret_reference",
  "state": "captured | extracted | inferred | pending_review | confirmed | conflicted | stale | superseded | archived | deleted",
  "subject": "entity_or_user",
  "predicate": "relation_or_attribute",
  "object": "value_or_entity",
  "content_text": "human-readable normalized form",
  "confidence": 0.0,
  "importance": 0.0,
  "sensitivity": "low | medium | high | restricted",
  "scope": "session | cross-session | long-term",
  "source_type": "chat | user_form | import | tool | external_reference",
  "evidence_ids": ["evt_001", "evt_099"],
  "created_at": "2026-03-18T12:00:00Z",
  "updated_at": "2026-03-18T12:00:00Z",
  "valid_time_start": null,
  "valid_time_end": null,
  "last_confirmed_at": null,
  "last_accessed_at": null,
  "access_count": 0,
  "version": 1,
  "supersedes": null,
  "tags": ["family", "career"]
}

5.2 Evidence Object

证据对象记录记忆来源。它通常对应某次原始输入、文档片段或用户手动填写内容。

{
  "evidence_id": "evt_001",
  "source_type": "chat",
  "session_id": "sess_123",
  "actor": "user",
  "timestamp": "2026-03-18T11:55:00Z",
  "raw_content": "我应该是2021年中从A公司离开的",
  "parsed_entities": ["A公司", "2021年中"],
  "sensitivity": "low"
}

5.3 Memory Issue

系统将记忆冲突、待确认项、时间线歧义等,建模为独立对象 MemoryIssue

{
  "issue_id": "iss_001",
  "issue_type": "timeline_conflict | fact_conflict | unclear_reference | stale_memory | ambiguous_preference",
  "priority": "low | medium | high | critical",
  "status": "open | waiting_user | resolved | dismissed",
  "memory_ids": ["mem_001", "mem_041"],
  "question": "你是在2021年中离开A公司,还是2022年初离开A公司?",
  "evidence_ids": ["evt_001", "evt_045"],
  "created_at": "2026-03-18T12:10:00Z",
  "resolved_at": null,
  "resolution_type": null
}

6. 记忆类型设计


6.1 Event Memory(事件记忆)

描述“发生过什么”。

示例

  • 2021 年进入 A 公司
  • 2025 年孩子出生
  • 去年搬家到东京

特征

  • 时间属性强
  • 通常来自用户叙述或导入记录
  • 可成为人生时间线主干

Schema 示例

{
  "memory_type": "event",
  "event_type": "career_change",
  "subject": "user",
  "object": "joined_company_A",
  "valid_time_start": "2021-03",
  "time_precision": "month",
  "state": "confirmed"
}

6.2 Fact Memory(稳定事实)

描述当前或某时间段内被认为成立的客观事实。

示例

  • 当前居住城市是东京
  • 有一个孩子
  • 当前从事嵌入式 AI 方向工作

特征

  • 可能被更新
  • 需要版本与生效时间
  • 是日常任务检索的重要来源

6.3 Relationship Memory(关系记忆)

描述实体之间的关系。

示例

  • X 是表哥
  • Y 是直属上级
  • A 服务依赖 B 服务

特征

  • 适合图模型或关系表
  • 便于多跳推理
  • 对日常人物/项目管理极有价值

6.4 Opinion Memory(观点/解释)

描述用户对某事的看法、解释、主观评判。

示例

  • 认为管理岗不适合自己
  • 觉得某段经历改变了人生方向
  • 对某位亲戚长期不信任

设计要求

  • 不得与客观事实混存
  • 必须标明它是“用户观点”
  • 最好带时间上下文与稳定性估计

6.5 Preference Memory(偏好/习惯)

描述用户长期偏好和行为模式。

示例

  • 技术资料偏好英文
  • 喜欢高频短时练习
  • 做计划喜欢结构化步骤

设计要求

  • 区分 session preference / task preference / long-term preference
  • 多次重复出现后才适合晋升为长期偏好

6.6 Secret Reference(敏感秘密引用)

描述外部安全资产的“存在性”和“定位性”,而不持有秘密内容。

示例

  • 2026-03-18 为工作邮箱存过登录凭据
  • 某银行账户恢复码已存入外部密码管理器
  • NAS 管理员凭据已登记于 vault

约束

  • 不存正文
  • 不做 embedding
  • 不参与自然语言检索正文
  • 仅允许非重建型提示

Schema 示例

{
  "memory_type": "secret_reference",
  "subject": "work_email_account",
  "predicate": "credential_stored_in",
  "object": "external_vault",
  "label": "工作邮箱登录信息",
  "hint": "与主工作邮箱相关",
  "content_stored_in_memory_system": false,
  "state": "confirmed"
}

7. 状态机设计

每条记忆需要生命周期状态。推荐状态如下:

captured
  -> extracted
  -> inferred
  -> pending_review
  -> confirmed
  -> conflicted
  -> stale
  -> superseded
  -> archived
  -> deleted

7.1 状态含义

captured

系统已捕获原始输入,但尚未抽取为结构化对象。

extracted

已从原始内容中提取出候选记忆。

inferred

系统推断出了记忆,但尚未被用户确认。

pending_review

等待用户澄清或确认。

confirmed

用户确认,或证据链足够稳定且策略允许自动确认。

conflicted

与其他记忆对象冲突,暂不可作为高可信上下文。

stale

长期未确认,且存在过期风险。

superseded

被更高版本替代。

archived

不再主动参与常规检索,但保留历史。

deleted

被用户要求删除,或因策略需移除。


7.2 状态迁移原则

  • captured -> extracted:抽取器成功解析
  • extracted -> inferred:完成结构化归一
  • inferred -> pending_review:高价值但需用户确认
  • inferred -> confirmed:低风险且高置信内容可自动确认
  • confirmed -> conflicted:发现强冲突证据
  • confirmed -> stale:长时间未验证且可能失效
  • confirmed -> superseded:新版本替换
  • stale -> archived:长期无使用价值
  • any -> deleted:用户要求删除或策略删除

8. 数据分层与存储设计


8.1 Layer 0:Working Memory(工作记忆)

用于当前任务执行。

包含

  • 当前会话最近消息
  • 当前任务目标
  • 当前 planner 状态
  • 当前工具调用摘要
  • rolling summary

特点

  • 生命周期短
  • 强任务相关
  • 不一定写入长期库

可选实现

  • 内存对象
  • Redis
  • session DB

8.2 Layer 1:Episodic Store(情节事件层)

保存原始事件与事件化记忆。

包含

  • 原始对话 turn
  • 用户手工输入回忆录
  • 工具调用结果摘要
  • 导入的生活事件记录

特点

  • append-heavy
  • 强时间序列
  • 是长期语义记忆的原材料

可选实现

  • document DB
  • object store + metadata
  • append-only event log

8.3 Layer 2:Semantic Store(语义事实层)

保存长期事实、偏好、解释、状态。

包含

  • 当前稳定事实
  • 长期偏好
  • 关系归纳
  • 当前有效版本的观点对象

特点

  • 版本化
  • 可更新
  • 高价值检索源

可选实现

  • relational DB
  • document DB with versioning

8.4 Layer 3:Relationship Store(关系层)

维护实体图及关系。

包含

  • 人物关系
  • 工作项目依赖
  • 账户与设备关系
  • 服务与凭据引用关系

可选实现

  • graph DB
  • relational tables + graph projection

8.5 Layer 4:Secret Reference Store(敏感引用层)

保存对外部 vault 项的引用信息。

约束

  • 不含任何秘密正文
  • 不参与 embedding
  • 访问需更严格授权

9. 记忆采集与解释流程


9.1 Capture Pipeline

输入来源可以包括:

  • 日常对话
  • 语音转写
  • 用户表单
  • 回忆录输入
  • 手工事件录入
  • 外部系统同步摘要

初步步骤:

  1. 原始内容接收
  2. 敏感信息预检测
  3. 生成 Evidence
  4. 路由到解释器或安全分流器

9.2 敏感信息预检测

系统必须在进入普通记忆抽取前,识别是否包含:

  • 密码
  • PIN
  • OTP
  • 私钥
  • 助记词
  • 恢复码
  • API key

若命中:

  • 不写入普通记忆
  • 不进入 embedding
  • 不进入摘要
  • 转交外部安全界面
  • 仅在本系统中留 SecretReference

9.3 Interpretation Pipeline

对普通内容进行结构化解释,包括:

  • 实体抽取
  • 时间抽取
  • 事件识别
  • 关系抽取
  • 观点识别
  • 偏好识别
  • 情绪快照识别
  • 时间线冲突检测
  • 事实/观点混淆检测

输出为若干 MemoryCandidate


10. 写入策略与治理策略


10.1 长期写入门槛

候选记忆是否进入长期层,应满足以下维度判断:

  • 跨会话价值
  • 用户相关性
  • 稳定性
  • 重要性
  • 时间有效性
  • 敏感性
  • 可证据支持程度
  • 与既有记忆的冲突程度

示例策略

  • 一次性情绪表达:通常不晋升为长期事实
  • 重复出现的习惯:可晋升为 preference
  • 关键人生事件:进入 pending_review 或 confirmed
  • 高敏感秘密正文:禁止进入

10.2 自动确认 vs 用户确认

建议分三类:

A 类:可自动确认

低风险、明确、短链路对象 例如:

  • 用户明确说“以后技术资料优先英文”
  • 用户明确说“我现在住东京”

B 类:需用户确认

高价值、可能长期影响任务表现 例如:

  • 工作变动
  • 家庭核心关系
  • 长期目标改变
  • 财务安排变化

C 类:必须人工确认

冲突强、高敏感、高影响 例如:

  • 重大时间线差异
  • 核心身份/关系冲突
  • 健康/财务等高风险信息
  • 任何 secret reference 的标签与分类

11. 冲突检测设计


11.1 冲突类型

timeline_conflict

同一事件在不同时间被描述为不同版本。

fact_conflict

同一事实对象当前状态冲突。 例如当前居住城市同时为东京与大阪。

relation_conflict

同一关系对象冲突。 例如某人既被记为朋友又被记为直属上级。

opinion_fact_confusion

把观点误写成客观事实。

stale_vs_recent_conflict

旧记忆与近期新证据不一致。


11.2 冲突处理原则

  • 不立即删除旧版本
  • 标记冲突状态
  • 建立 MemoryIssue
  • 降低冲突对象在检索中的优先级
  • 用户确认后生成新版本并 supersede 旧版本

12. 用户确认与澄清工作流


12.1 澄清问题生成原则

系统只在以下情况下打扰用户:

  • 冲突对后续任务影响大
  • 自动推断不足以消解
  • 一次澄清可修复多条记忆
  • 该问题用户容易回答
  • 处于合适的交互时机

12.2 问题形式

推荐形式:

  • 简明问题
  • 附带证据摘要
  • 可选项明确
  • 用户可选“以后再说”

示例

“我发现你关于离开 A 公司的时间有两个版本: 1)2021 年中 2)2022 年春节后 哪个更接近实际?”


12.3 周期复核机制

Daily

  • 抓取新候选记忆
  • 低成本增量整理

Weekly

  • 冲突核查
  • 新长期记忆确认
  • 时间线补全
  • 当前目标修正

Monthly

  • 人生主线回顾
  • 关系状态检查
  • 长期偏好变化评估
  • 旧记忆降权/归档

13. 时间线系统设计

个人记忆系统必须把时间处理当成独立能力,而不是普通 metadata。


13.1 时间表示

每条事件记忆应支持:

  • 发生时间(valid time)
  • 被提及时间(mention time)
  • 记录时间(system time)
  • 时间精度(year / month / day / rough)
  • 时间置信度

示例

  • 2021
  • 2021-06
  • 2021-06-15
  • 疫情后不久
  • 孩子出生前几个月

系统应允许模糊时间存在。


13.2 时间解析原则

  • 不强行将模糊时间转成高精度日期
  • 保留原始表达
  • 保存归一化推断结果和精度
  • 若关键任务依赖精确时间而证据不足,应生成 issue

14. 面向 LLM 的上下文服务设计

系统不应“把所有记忆塞进 prompt”,而应做任务感知型装配。


14.1 Retrieval Orchestrator

负责为给定任务选择候选上下文来源:

  • 当前会话摘要
  • 近期事件
  • 稳定事实
  • 关系邻居
  • 当前目标与约束
  • 相关偏好
  • 相关 issue 或风险提醒

14.2 检索排序维度

综合打分建议考虑:

  • 语义相关性
  • 时间相关性
  • 重要性
  • 置信度
  • 是否已确认
  • 与任务类型匹配度
  • 冗余惩罚
  • 冲突状态惩罚

14.3 Context Assembler

最终上下文建议按槽位装配:

[System Policy]
[Task Goal]
[Current Session Summary]
[Relevant Stable Facts]
[Relevant Preferences]
[Relevant Relationships]
[Relevant Recent Events]
[Open Constraints / Risks]
[Open Memory Issues if Necessary]

14.4 Serving 原则

  • 默认优先 confirmed 对象
  • conflicted / stale 对象仅在必要时附带不确定性标签引入
  • opinion 与 fact 不混写
  • 任务只拿需要的最小上下文
  • 对高影响任务可附来源摘要

15. 安全边界:Secrets 与普通记忆隔离


15.1 顶层原则

系统不得存储、嵌入、摘要、索引或检索以下高敏感内容的明文:

  • 密码
  • 恢复码
  • 私钥
  • 助记词
  • OTP
  • API 密钥
  • 安全口令

15.2 允许存储的只有外围元信息

可记录内容包括:

  • 是否已存入外部 vault
  • 存入时间
  • 资产类别
  • 安全标签
  • 非重建型定位提示
  • 生命周期状态

15.3 hint 约束

hint 只允许“帮助定位”,不得“帮助重建”。

允许:

  • “工作邮箱相关”
  • “海外券商登录项”
  • “NAS 管理后台”

不允许:

  • 构成规则
  • 字符片段
  • 生日/手机号组合规则
  • 恢复码片段
  • 助记词部分词语

16. 审计与可信性机制


16.1 可追溯性

关键记忆必须能追到:

  • 原始证据
  • 何时进入系统
  • 是否经用户确认
  • 更新历史

16.2 版本机制

记忆对象不建议就地粗暴覆盖。 应优先:

  • 新建版本
  • 标注 supersedes
  • 保留历史链条

16.3 访问审计

系统应记录:

  • 哪些任务调用过哪些记忆
  • 哪些记忆被用户修改过
  • 哪些 sensitive reference 被访问过元数据

17. 初始化建模流程

初始化阶段不应要求用户一次性完整录入人生,而应先建立主干。


17.1 初始化主干建议

人生时间线主轴

  • 成长与教育
  • 工作经历
  • 居住迁移
  • 家庭重大事件
  • 健康重大事件
  • 财务重大事件

关系主轴

  • 核心家庭
  • 重要亲友
  • 核心同事与合作对象

长期偏好主轴

  • 学习偏好
  • 工作偏好
  • 沟通偏好
  • 风险偏好
  • 决策风格

当前状态主轴

  • 当前角色
  • 当前目标
  • 当前压力源
  • 当前约束

17.2 初始化策略

  • 先建主干,不追求穷尽
  • 允许模糊时间
  • 高价值信息优先确认
  • 后续在日常对话中逐步补全细节

18. 推荐的最小可用实现(MVP)

若要先做可落地版本,建议范围如下:


18.1 MVP 必做

A. Memory Object 基础模型

至少支持:

  • fact
  • event
  • preference
  • relationship
  • secret_reference

B. Evidence + Versioning

每条记忆有来源和版本。

C. Issue Queue

能显式管理冲突与待确认项。

D. Weekly Review

支持每周生成记忆澄清列表。

E. Context Serving

能够面向任务检索 confirmed 的稳定记忆 + 近期事件。


18.2 MVP 可暂缓

  • 复杂 graph DB
  • 高级多跳推理
  • 自动人生叙事生成
  • 深度情绪建模
  • 完整多模态统一记忆

19. 风险与失败模式


19.1 过度自动化

系统误把低质量推断固化为长期事实。

对策

  • 高价值对象进入 pending_review
  • 严格 evidence 要求
  • 支持用户纠错

19.2 事实与观点混淆

情绪化表达被当成稳定事实。

对策

  • opinion 独立 schema
  • 抽取器显式分类
  • 对长期语义层设置类型约束

19.3 时间漂移

模糊记忆被过度精确化。

对策

  • 保存时间粒度
  • 保留原始表达
  • 时间冲突独立建 issue

19.4 上下文污染

低置信度旧记忆影响当前任务。

对策

  • serving 时优先 confirmed
  • stale/conflicted 降权
  • token budget 控制

19.5 安全越界

高敏感秘密进入普通检索链路。

对策

  • 敏感检测前置
  • 分流外部安全界面
  • 禁止 embedding / logging / summary

20. 总结

本系统的核心不在于“把个人历史做成一个大向量库”,而在于建立一套:

  • 分层存储
  • 状态治理
  • 证据追踪
  • 用户确认
  • 冲突管理
  • 周期复核
  • 安全边界清晰

的个人长期记忆基础设施。

一句话概括:

这不是自动真相机,而是一个以证据、确认、修订和审计为基础的人机共建个人长期记忆系统。

About

mirror, mirror, tell me about meself...

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors