为什么 OpenHuman 的记忆树始终显示 0 buffer(s)？一次从 Vault 到 Summary Tree 的完整排障
“
本文核心问题：为什么 OpenHuman 明明已经同步了文件，但点击“构建摘要树”后始终提示
Building summary trees · 0 buffer(s)？
简短答案先说结论：
如果你只添加了本地 Vault（例如 Markdown、TXT 文件），即使显示 synced 成功，也可能无法生成记忆树。当前流程中，记忆树构建依赖 Gmail、Slack、Notion 等来源的数据，而本地 Vault 仅同步，不会自动进入 Summary Tree。
这篇文章记录了一次完整的排障过程：从怀疑文件路径错误、怀疑 Embedding 配置问题、查看日志、分析 worker，到最终确认产品当前行为边界。过程本身，比答案更有价值。
什么是 OpenHuman 的“记忆”？
“
本段核心问题：OpenHuman 的记忆功能到底在做什么？它和聊天记录有什么区别？
很多人第一次接触 OpenHuman，都会自然地理解为：
“
“它会把我所有东西记住。”
但实际体验很快会发现：
“
它并不是一个无限聊天记录系统，而是一个结构化的长期上下文系统。
在使用过程中，可以看到几个明显的概念：
-
Vault -
Sync -
Summary Tree（摘要树） -
Tree View（树状视图） -
Storage（存储库）
这些名字容易让人产生一种预期：
“
“只要把本地文件加进去，它就能自动理解我的知识库。”
事实并非如此。
在实际使用里，OpenHuman 更像一个：
“
个人数字上下文系统
它希望从：
-
Gmail -
Slack -
Notion
这类持续产生行为数据的来源中，提取结构化记忆。
例如：
-
联系人 -
项目 -
决策 -
会议 -
偏好
而不是简单地把文件全文塞给模型。
这一点，是后面所有误解的起点。
问题出现：为什么 Summary Tree 永远是空的？
“
本段核心问题：为什么文件已经同步成功，但记忆树仍然构建失败？
问题出现得很直接。
在 OpenHuman 中添加了一个本地 Vault：
F:\12
界面最初显示：
0 file(s)
这意味着：
“
系统还没有读取到任何内容。
第一反应通常是：
-
路径错了？ -
权限问题？ -
文件格式不支持？ -
Sync 没执行？
于是开始排查。
后来目录里加入测试文件后，状态变成：
3 file(s) · synced 1m ago
这时直觉上会认为：
“
已经同步成功，接下来点击「构建摘要树」就行。
但真正点击后，却出现了一个令人困惑的提示：
Building summary trees · 0 buffer(s)
Force-sealing every L0 buffer through the configured AI summariser. The graph will refresh once the worker drains.
问题来了：
“
为什么已经同步了 3 个文件，却还是 0 buffer？
第一步误判：怀疑是文件路径问题
“
本段核心问题：路径中的
\\?\F:\12是不是错误？
在界面中，Vault 路径后来显示成：
\\?\F:\12
很多人第一次看到这个都会紧张。
尤其是：
“
为什么多了一个问号？
第一反应是：
“
文件系统是不是坏了？
实际上并不是。
这是 Windows 的扩展路径格式。
例如：
普通路径：
F:\12
内部路径：
\\?\F:\12
它的意义是：
“
按原始路径访问，不做路径解析。
在很多桌面应用里都属于正常行为。
因此：
“
路径不是问题。
更关键的是：
3 file(s) · synced
已经证明：
“
文件确实被读取到了。
排除路径问题后，问题开始进入下一阶段。
第二步误判：怀疑是 Embedding 或模型没有配置
“
本段核心问题：是不是因为没有配置模型，导致摘要树无法构建？
看到：
0 buffer(s)
一个很自然的推断是：
“
Embedding 没配置。
或者：
“
Summary model 没启动。
于是开始寻找：
-
Embedding provider -
Model settings -
Local AI -
Inference
甚至开始检查：
-
OpenAI API Key -
Ollama -
本地模型
这是一个非常合理的推断。
因为：
“
构建记忆树，看起来像是一个需要模型参与的动作。
而且提示中也出现了：
AI summariser
让人更加确信：
“
一定是模型问题。
第三步：查看系统日志
“
本段核心问题：日志到底透露了什么信息？
随后查看日志。
关键日志包括：
[memory:ingestion_queue] background worker started
这说明：
“
ingestion worker 已经启动。
还有：
openhuman.inference_status -> ok
以及：
openhuman.local_ai_downloads_progress -> ok
这些信息表面上看似正常。
最关键的是：
日志里没有任何真正的 memory build 行为。
例如没有：
embedded chunk
summary tree
sealed buffer
memory summarising
理论上，如果 Summary Tree 正在构建，应该能看到类似行为。
但完全没有。
这意味着：
“
系统甚至没有进入真正的 summarisation 阶段。
这时问题变得奇怪起来：
“
为什么 worker 启动了，却没有任何 buffer？
第四步误判：怀疑是 Ingestion Bug
“
本段核心问题：会不会是 Sync 成功，但 Chunk 没进入 Buffer？
随后发现一个 issue。
一开始的推断是：
“
可能是 ingestion queue 没 flush。
即：
文件存在
↓
sync 成功
↓
但 chunk 没进入 L0 buffer
↓
summary tree = 0
这个猜测当时很合理。
因为表面现象完全一致：
3 file(s)
但：
0 buffer(s)
从逻辑上看，似乎只能解释为：
“
ingest 出问题。
但后来发现：
“
这仍然不是根因。
真正根因：Summary Tree 并不消费本地 Vault
“
本段核心问题：为什么本地 Markdown 文件无法进入记忆树？
最终定位到真正的问题：
“
当前记忆树只支持 Gmail / Slack / Notion 等来源。
这意味着：
即使你：
Add Vault
↓
Sync 成功
↓
3 file(s)
也不会进入：
L0 buffer
↓
summary tree
因为：
“
本地 Vault 并不是 Summary Tree 的数据来源。
换句话说：
系统行为更像：
Gmail / Slack / Notion
↓
Structured Events
↓
L0 Buffer
↓
Summary Tree
而不是：
Local Markdown Files
↓
Summary Tree
这解释了所有现象。
包括：
为什么：
3 file(s) synced
却依然：
0 buffer(s)
因为：
“
没有符合条件的 buffer。
它并不是报错。
而是：
“
没有可构建对象。
一个容易误解的地方：Vault 为什么看起来像知识库？
“
本段核心问题：既然不能生成记忆树，为什么还支持添加 Vault？
这是整个体验里最容易让人误解的地方。
从界面设计来看：
用户会自然联想到：
本地文件
↓
同步
↓
AI 理解
↓
记忆树
尤其当界面出现：
-
Sync -
Tree View -
Storage -
Summary
时，预期会更强。
但实际情况是：
“
Vault 更多是一个同步能力。
而不是：
“
一个自动进入长期记忆的知识库入口。
因此：
“能 Sync” ≠ “能进入 Summary Tree”。
这是理解 OpenHuman 当前状态最重要的一点。
一次最小可复现测试
“
本段核心问题：如何快速验证自己是不是遇到了同样的问题？
可以做一个最简单的测试。
创建：
F:\12\test.md
内容：
项目名：Atlas
技术栈：
Rust
SQLite
不要 ORM
然后：
Step 1：添加 Vault
路径：
F:\12
Step 2：点击 Sync
观察：
是否变成：
3 file(s)
或者：
1 file(s)
如果成功：
说明文件读取没问题。
Step 3：点击构建摘要树
此时如果出现：
Building summary trees · 0 buffer(s)
基本可以确认：
“
你遇到的是同一个限制。
不是：
-
路径问题 -
权限问题 -
文件格式问题 -
API Key 问题 -
Embedding 配置问题
而是：
“
Summary Tree 不消费本地 Vault。
一个重要反思：不要把产品预期强行套给现实行为
“
本段核心问题：这次排障最大的经验是什么？
这次过程里，一个很典型的问题是：
“
我们不断在寻找技术错误。
例如：
-
路径 -
权限 -
Embedding -
Summariser -
Worker -
API Key -
Queue
但最后发现：
“
系统根本不是这么设计的。
换句话说：
“
不是系统坏了，而是预期错了。
这是一种很常见的工程误区。
当一个产品界面给出：
Vault
Sync
Memory Tree
时，用户会自然推断：
“
它像 Obsidian + RAG。
但真实行为是：
“
它更像 Personal Digital Memory。
也就是：
“
从 Gmail、Slack、Notion 中抽取长期上下文。
理解这一点后，整个系统 suddenly makes sense。
虽然体验上仍然容易误导，但逻辑开始一致。
当前可行的测试方式
“
本段核心问题：如果想验证记忆树，应该怎么测试？
既然本地 Vault 不会进入 Summary Tree。
当前最直接的方法是：
连接一个支持的数据源。
例如：
-
Gmail -
Slack -
Notion
然后：
1. 同步来源
等待 ingestion。
2. 构建摘要树
点击：
构建摘要树
3. 查看树状视图
理论上应该开始出现：
People
Projects
Conversations
Tasks
以及：
-
联系人 -
邮件主题 -
对话 -
决策
如果这里开始有节点：
说明：
“
Summary Tree 真正开始工作。
实用摘要
如果你看到 0 buffer(s)，优先检查什么？
先看：
3 file(s) synced
有没有。
没有
说明：
“
文件读取失败。
检查：
-
路径 -
文件格式 -
权限
有，但仍是 0 buffer(s)
优先判断：
“
是否只用了本地 Vault。
如果是：
“
当前属于预期行为。
不是配置问题。
不要优先排查什么？
在确认来源前，不建议优先折腾：
-
OpenAI API Key -
Ollama -
Embedding model -
Summariser provider
因为：
“
根因可能根本不在模型层。
一页速览（One-page Summary）
FAQ
1. 为什么显示 3 file(s) 但记忆树还是空？
因为：
“
文件同步成功，不代表进入 Summary Tree。
本地 Vault 当前不会自动生成记忆树。
2. 0 buffer(s) 是报错吗？
不是。
更准确地说：
“
没有可构建的 buffer。
3. \\?\F:\12 说明路径坏了吗？
不是。
这是 Windows 的内部路径格式。
属于正常现象。
4. 我需要配置 Embedding 吗？
仅从当前问题来看：
“
不是优先原因。
因为问题发生在：
“
数据来源层。
5. 本地 Markdown 文件会进入记忆树吗？
根据当前测试结果：
“
不会。
至少当前流程中不会进入 Summary Tree。
6. 如何验证记忆树真的工作？
连接：
-
Gmail -
Slack -
Notion
然后重新同步与构建。
7. 为什么这个问题容易误导人？
因为界面上的：
Vault
Sync
Summary Tree
很容易让人自然联想到：
“
本地知识库 → AI 记忆。
但当前行为并不是这样。
8. 最重要的经验是什么？
一句话：
“
先确认产品真实边界，再排查技术问题。
