写作现场：2026 年 5 月 18 日。 OpenHuman 在这一版本中并非普通的 vector top-k RAG。它先把邮件、聊天和文档编译为带 provenance 的持久材料，再同时维护 Source、Topic 与 Global 三种层级投影。技术难点不是保存更多文本，而是在持续写入、摘要压缩和来源追溯之间维持可解释性。
摄取管线：来源语义决定幂等策略
连接器先把 chat、email 与 document 规范为 Markdown，并保留来源类型、所有者、时间和 SourceRef。内容按消息边界或段落切分，每块约 3,000 token，并由内容生成稳定 ID：
来源适配器
→ Markdown + provenance
→ 确定性切块
→ 原子写入 .md
→ SQLite 状态与索引
→ 快速评分
→ 持久队列执行抽取、准入与封桶
同步路径只完成规范化、切块和低成本评分；实体抽取、最终准入、树更新与摘要进入 SQLite-backed job queue。这样可以缩短请求延迟，并在进程中断后根据任务状态恢复后台处理。
幂等策略依赖来源语义。不可变文档使用 source-level claim，避免同一文件被并发导入；聊天与邮件属于持续增长的流，同一个 source_id 后续仍会产生新内容，只能依赖稳定 chunk ID 消除真正重放。把所有来源统一成单一去重键，会在文档场景产生重复，在流式场景丢失增量。
写入阶段已经包含编辑判断：哪些片段值得长期保留、何时封桶、哪些实体需要物化。OpenHuman 的 memory ingestion 更接近持续运行的编译管线，而不是无条件写入向量库。
三种投影与可追溯检索
三棵树复用同一批原始材料，但优化不同查询：
- Source Tree 按 Slack channel、邮件参与者集合或文档语料组织时间树。叶子进入 L0 buffer，达到 token gate 或 idle timeout 后封为 L1 summary，再逐层压缩。
- Topic Tree 按人物、公司和项目聚合跨来源材料。实体达到 hotness 阈值后才物化主题树，并从近期索引回填内容，以控制重复与无限增长。
- Global Tree 先生成 daily digest，再按周、月、年汇总，用于回答跨来源的时间问题。
它们是物化视图，不是三份独立真相。新增、删除或纠错原始材料后，派生摘要存在失效与重建问题；层级越深，压缩漂移越难察觉。Global Tree 尤其容易把一次例外压成长期模式。
检索层暴露 query_source、query_topic、query_global、search_entities、drill_down 和 fetch_leaves 六个原语。模型先选择投影视角，再沿 summary 的 child_ids 下钻到原始 chunk，并通过 source_ref 返回邮件、聊天或文档：
高层摘要 → 低层摘要 → 原始 chunk → source_ref
这条 provenance path 使高层结论可审计，但并不保证模型每次都会下钻到足够深；延迟和 token 成本也随深度增加。产品层需要显示结论的来源、压缩次数、更新时间和被哪些回答使用过，而不是只给出一段流畅摘要。
Memory Tree 的 Markdown 与 SQLite 可以存放在本机，但 embedding、实体抽取、summarization 和最终回答仍可能由外部 provider 执行。local-first 因此应按数据流逐段验证，而不能由一个开关概括。对拥有多年跨应用资料的研究者与项目负责人，这种结构的价值是可导航且可回到原文；相应的迁移成本也包含全部派生索引和机器解释，而不仅是原始文件。
版本与源码
信息边界：本文只采用 2026-05-18 及此前已经公开的事实和当日
a719d78源码；三棵树是这个时间点的真实设计。