Source adapters
Gmail / Slack / GitHub / Notion / Calendar 等连接器持续同步。
Hindsight
跨会话语义召回，适合“之前聊过什么”“这个决策从哪里来”。
Interactive Brief · Modeling, not just memory
它们本质上都在做一件事：给人的世界建模。
OpenHuman 的 Memory Tree、小虎这边的 LLM Wiki、Hindsight、Skills，并不是几种“记忆功能”。它们是在不同粒度上把主人的工作、偏好、项目、关系、证据、行动路径，编译成一个可查询、可修正、可执行的 personal operating model。
OpenHuman 的思路：从“记住”到“持续编译”。
它不是把所有东西塞进向量库，而是把数据流转成可读 Markdown、SQLite 状态和层级摘要树。点击每个节点，看它承担的建模职责。
Canonicalize
把异构数据统一成带 provenance 的 Markdown。
Chunks ≤3k
确定性切块、hash、去重，写入本地内容存储。
Score & admit
评分、实体抽取、决定 admitted 还是 dropped。
Memory Trees
source / topic / global 三种树持续 seal 摘要。
Retrieval
查询、drill-down、Obsidian vault、人可读可改。
Source adapters
OpenHuman 最重要的产品化动作，是把“用户主动喂资料”变成“连接器自动拉取”。每个连接维护 cursor、last sync、dedupe、budget，避免重复和失控。
auto-fetchOAuthcursor
every 20 min:
for connection in active_connections:
if interval_elapsed(connection):
items = provider.sync(cursor)
ingest(items, source=connection)
源码复核：OpenHuman 不是一个“手工 wiki 生成器”。
这页讲得好，因为它把 Memory Tree 定义成 deterministic、bucket-sealed pipeline，而不是“向量库套壳”。我对照源码后确认：Memory Compiler 是 SQLite job queue 驱动的异步编译管线；Wiki Curator 更接近“热度门控 + Obsidian 标签/本地 Markdown + topic tree materialization”。
ingest 热路径很薄
OpenHuman 的入口故意不做重活：先把异构来源标准化、切块、快评分、落 SQLite，然后把慢任务交给 job queue。
- chat/email 不做 source-level gate，因为它们是流；document 才做 source gate。
- chunk body 先写磁盘内容存储，SQLite 只保留状态和 preview。
- 新 chunk 只入队 ExtractChunk，后续 admission / tree append / seal 都异步。
memory/tree/ingest.rs:1-7ingest.rs:71-138ingest.rs:155-193这说明“小虎 Memory Compiler”不要一口气写 wiki：先做可靠的 ingest ledger、chunk idempotency、job lifecycle。
三种“记忆”其实是三种建模粒度。
拖动滑杆感受权衡：吞吐越高，越需要自动筛选；质量越高，越需要人工/agent 精修；行动越强，越需要 Skill 层闭环。
建模对象
文档片段相似度。问题来了才临时召回。
- 低维护
- 快启动
- 容易上下文碎片化
主要风险
每次都重新理解，没有稳定“世界模型”。事实、流程、决策容易散。
适用场景
资料库问答、搜索增强、短期项目资料查询。
建模对象
人的信息流。自动连接器把数据压缩成 source/topic/global 摘要树。
- 吞吐高
- 本地优先
- Obsidian 可读
主要风险
如果 admission 和 review 弱，自动摘要可能变成“漂亮垃圾场”。
适用场景
个人助理、长期上下文、跨工具状态同步。
建模对象
主人工作系统：偏好、项目事实、业务路径、QA 经验、可执行流程。
- Memory Tree 吞吐
- LLM Wiki 精修
- Skills 行动
主要风险
层太多会复杂，所以必须有清晰分工：memory 记硬偏好，wiki 记知识，skills 记流程。
适用场景
mecoland、image-studio、截图自动分析、PR/QA 维护、飞书日历会议。
当前推荐：Memory Tree 做缓冲，LLM Wiki 做精修，Skills 做行动。这个组合适合高价值长期项目。
小虎侧升级方案：Memory Compiler + Wiki Curator。
不是把 OpenHuman 照搬过来，而是把它的“持续建模管线”拆成适配 Hermes 的四个模块。左侧切换模块，看职责边界。
Memory Compiler
接收 GitHub、飞书、截图、OpenCLI、项目文件等来源，把它们转成统一 Markdown chunk。它只负责吞吐和初筛，不直接污染正式 wiki。
输入
webhook、cron、手动 ingest、截图事件、PR 评论、会议纪要。
状态
pending → admitted / dropped → buffered → sealed。
产物
chunks、source summary、topic summary、daily digest、candidate facts。
落地路线图：先建模，再自动化，最后产品化。
我建议不要一上来追求 118 个集成。先围绕主人真实高频流做小闭环：mecoland、飞书、GitHub、截图、OpenCLI。
建本地 Memory Compiler MVP
实现 canonical chunk、hash 去重、frontmatter provenance、admission score、JSONL/SQLite 状态。先支持手动文件/URL/GitHub/飞书会议。
接入 source/topic/daily 三种摘要树
按来源、主题和日期 seal 摘要。主题优先：mecoland、image-studio、ComfyUI、截图分析。
加入 review / promote 队列
低置信度、冲突、可能长期有价值的事实进入待审核。确认后升格到正式 LLM Wiki 页面。
做 Context Router
回答问题前自动判断该查 memory、hindsight、session_search、wiki 还是 skill，并说明引用来源。
做控制面与自动 digest
Telegram/Feishu 命令或小 Web UI：查看 pending、topic heat、daily digest、wiki lint、冲突页面。
关键不是“记更多”，而是分层治理。
如果所有东西都丢进一个 memory store，迟早变成噪音。小虎侧需要明确每层的职责和准入门槛。
Memory
只存稳定偏好、环境事实、长期约束。不能存 PR 号、临时进度、短期任务。
LLM Wiki
业务路径、产品事实、QA SOP、项目知识。可读、可审计、可链接。
Skills
可执行流程和工具经验。不是知识结论，而是下一次该怎么做。
Session Search
查历史原始对话，不做长期知识承诺。
Memory Tree
自动吞吐层。负责 buffer、summary、candidate facts，不直接等于事实。
Review Queue
冲突、低置信度、需主人确认的内容，不允许静默硬化成事实。
Action Layer
cron、webhook、subagent、browser、terminal。必须验证结果，不能只生成建议。
最终形态
Memory Tree 是自动建模引擎，LLM Wiki 是精修知识底座，Hindsight 是回忆入口，Skills 是行动肌肉。 OpenHuman 那页最值得借鉴的一句话是：它不是 vector database with a thin memory wrapper，而是 deterministic, bucket-sealed pipeline。小虎侧先不扩连接器，先围绕聊天记录和截图继承这个“先编译、再升格、可追溯”的骨架。