尧图网站建设 
OpenHuman Memory Tree 解析本地优先的确定性记忆管道与分层摘要树架构【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman导读Memory Tree 是 OpenHuman 的本地优先知识库——它不是套了一层记忆壳的向量数据库而是一条确定性的、桶密封bucket-sealed驱动的流水线把聊天、邮件、文档、集成同步结果等杂乱日常流转化为结构化、可检索、带摘要、直接存放在本机的 Markdown。本文基于 memory-tree.md 展开结合 src/openhuman/memory/ 下的源码结构完整讲解其管道设计、三种摘要树的作用域、后台队列与调度器、叶子状态机、磁盘布局以及桌面端 Intelligence 页面的使用方式让读者既能照章实操也能理解底层原理。它做什么一条管道喂饱所有来源你接入的每一个来源都走同一条管道source adapters (chat / email / document) | v canonicalize normalised Markdown provenance metadata | v chunker deterministic IDs, 3k-token bounded segments | v content_store atomic .md files on disk (body tags) | v store persistence (chunks, scores, summaries, jobs) | v score signals embeddings entity extraction | v source / topic / global trees per-scope summary trees | v retrieval search / drill_down / topic / global / fetch热路径canonicalize → chunk → fast-score → persist → 入队后续任务必须快重活——嵌入计算、实体抽取、摘要桶密封、每日摘要——都在后台 worker 中执行因此 UI 永远不会被阻塞。嵌入计算和摘要树构建可以通过 Ollama 完全在设备上运行在 Local AI 中开启即可否则它们和普通模型调用一样走 OpenHuman 后端。从源码结构看这一层在仓库中的对应物是 src/openhuman/memory/tree/ 及其子模块tree/树读写与 RPC、retrieval/检索原语、tree_runtime/运行时操作而宿主层 src/openhuman/memory/mod.rs 负责 RPC 表面与 Agent 工具的编排。三棵树三个作用域Source trees来源树每个来源一个滚动缓冲区L0装满后密封成 L1 → L2 → … 逐级向上。Gmail 的每个 label、Slack 的每个 channel、每个上传的文档各有一棵自己的树。Topic trees主题树按实体热度hotness惰性物化。一个实体人、项目、股票代码、仓库出现得越频繁它的主题树就被越积极地构建和刷新。Global tree全局树每天一棵全局摘要覆盖当天摄入的所有内容。检索可以针对任意作用域搜索单个来源、下钻某个主题、或直接拉取全局摘要。数据落在磁盘的哪里在工作区内默认~/.openhuman或OPENHUMAN_WORKSPACE环境变量指向的位置路径内容memory_tree/chunks.dbChunks、分数、摘要、实体索引、任务队列、热度数据wiki/Markdown 仓库vault——参见 Obsidian Wiki一切都在本地。除非你显式把某个聊天消息发送出去否则你的原始数据不会离开本机。为什么是树而不是向量库向量库回答的是什么和这个查询相似而记忆需要回答更多今天发生了什么全局摘要这个人最近有什么动态主题树热度驱动上周二下午 3 点 Stripe webhook 说了什么来源树 出处溯源树同时提供压缩与导航。嵌入向量仍然存在于树内部所以语义搜索继续有效但上面的树形结构才是让记忆像大脑而不是一袋碎片的关键。管道是如何工作的面向用户的说法很简单连接一个来源Agent 就拥有了对它的持久记忆。兑现这个承诺的管道横跨HTTP 触发的摄取路径、持久任务队列、后台 worker 池、三棵独立摘要树以及一个每日 UTC 调度器。1. Ingest摄取新的聊天 / 邮件 / 文档到达后热路径将其规范化canonicalize为 Markdown切分成有界 chunk带确定性 ID跑一次廉价快速打分在单个事务中持久化所有内容把每个 chunk 标记为pending_extraction并为 worker 入队后续任务。这里有三个关键属性确定性Deterministicchunk ID 是内容寻址的对相同输入重复跑 ingest 永远不会产生重复。快速Fast这条车道上没有 LLM 调用只有廉价启发式。有界写入Bounded write一切在单个事务中完成部分摄取不会留下悬挂行。2. Queue任务队列后续工作落在持久任务队列中与 chunks 存在同一个磁盘 store 里。每个任务携带 kind、payload、去重键dedupe key、重试簿记和调度窗口。任务种类如下Kind作用extract_chunk深度打分 实体抽取。决定admitted还是dropped。append_buffer把一条 admitted 的叶子追加到来源或主题树的 L0 缓冲区。可能触发密封。seal把 L0 缓冲区压缩为 L1 摘要若父缓冲区已满则逐级级联。topic_route把叶子路由进各实体的主题树受热度检查门控。digest_daily构建全局每日摘要节点。flush_stale强制密封闲置过久的缓冲区。3. Workers后台 worker一个小型后台 worker 池默认 3 个从队列取任务执行。池子会被摄取路径立即唤醒同时带有短轮询兜底避免错过唤醒导致任务滞留。一个共享信号量semaphore限制并发的 LLM 调用数防止一波新来源意外扇出几十个并发嵌入。启动时任何租约已过期因崩溃或 kill的任务都会被归还队列——崩溃不会丢失已 admitted 但尚未密封的工作。4. Tree state树状态三棵相互独立的树从同一条叶子流构建Source tree——每个来源一棵。新叶子进入 L0 缓冲区缓冲区满或触发 stale-flush时一次seal写出 L1 摘要级联继续向上。Topic tree——每个高热度实体一棵。路由器检查实体是否足够热以拥有自己的树若是则追加到其缓冲区。Global tree——只有一棵树每个 UTC 日增长一个节点随天数累积向上合并。5. Scheduler调度器调度器循环独立于摄取路径运行。每天 UTC 00:00 它为昨天入队一条全局每日摘要、为今天入队一次 stale-flush。调度器本身不运行摘要器——一切走队列因此重试、去重和过期锁恢复都集中在同一处。6. Leaf lifecycle叶子生命周期每个 chunk 走过一个小型状态机pending_extraction -- admitted -- buffered -- sealed \ -- dropped抽取阶段根据深度打分决定admitted还是dropped。Admitted 的叶子进入缓冲区buffered。缓冲区密封时其中的每片叶子都被标记为sealed。dropped的叶子到此为止。其 chunk 行保留用于溯源但没有任何缓冲区或摘要引用它。这正是检索无需重跑管道就能展示出处的原因chunk 行加上它的终态生命周期标记就已足够。触发摄取Triggering ingest自动——每个活跃集成每 20 分钟自动拉取一次参见 Auto-fetch。手动——桌面应用的 Memory 标签页为每个来源暴露 Run ingest 触发器。RPC——openhuman.memory_tree_ingest供高级工作流使用。对应实现位于 src/openhuman/memory/tree/tree/rpc.rs 及其测试 rpc_tests.rs。桌面应用中的 Intelligence 标签页从底部导航栏打开。系统状态System status。页面顶部显示当前状态idle、ingesting、summarizing和一个Run ingest按钮可针对任意已连接来源手动触发同步。记忆指标Memory metrics指标含义Storageworkspace/memory_tree/chunks.db与 Obsidian vault 的总大小Sources已摄取的不同来源数量Gmail label、Slack channel、文档等各算一个Chunksstore 中 ≤3k-token 的 chunk 总数Topics目前物化出的主题树数量由热实体构建的 per-entity 摘要First / latest memory最早与最新 chunk 的时间戳记忆图谱Memory graph。基于实体索引绘制的力导向实体关系可视化。图谱会随 auto-fetch 持续拉取数据而增长——早期稀疏几天后变密。Obsidian vault。View vault in Obsidian按钮通过obsidian://open?path...深链直接打开workspace/wiki/。你也可以在任何文件浏览器中打开该目录。注意首次使用需先在 Obsidian 中把该目录注册为 vaultOpen folder as vault深链无法替你完成注册。摄取活动Ingestion activity。一个显示随时间变化的摄取事件热力图类似 GitHub 贡献图。适合发现 auto-fetch 空转的时段例如某个连接断开后停止同步。搜索与检索Search retrieval。覆盖 Memory Tree 的搜索栏。支持 source-scoped、topic-scoped 和全局查询任何结果都可以链接回 Obsidian vault 中对应的底层 chunk 文件实现完整溯源。路由Routing。Intelligence 标签页还会显示 Agent 每个任务正在使用哪个模型——参见 Automatic Model Routing。摄取的数据从哪来sources 与 auto-fetch在理解树本身之后值得把上游补全memory_sources域src/openhuman/memory/sources/维护一个类型化的连接器注册表支持 Composio OAuth 集成、对话记录、本地文件夹默认 glob**/*.md、10 MB/文件上限、带路径穿越防护、GitHub 仓库、RSS、网页可用 CSS selector 收窄以及 Twitter 查询等来源类型。每个来源还可设置max_tokens_per_sync、max_cost_per_sync_usd、sync_depth_days等每同步预算。自动拉取由 20 分钟一次的调度器驱动详见 auto-fetch.md每个活跃连接都有独立的游标、last-sync 时间戳、去重集合与每日预算状态按(toolkit, connection_id)维度持久化重启后从本地 KV 重建。webhook 等事件驱动同步与周期同步共享同一份 sync_state避免重复触发。最初的 60 秒设计被改成 20 分钟是为了用少量新鲜度换取显著更低的笔记本前台负载。入树前的关卡scoring 与检索并非每个 chunk 都配得上进入 Memory Tree。打分是入口关卡在 chunking 之后、追加到 L0 缓冲区之前执行详见 scoring.md综合 token 数、词汇多样性、来源权重、交互标签interaction权重最高因为直接用户参与最接近这对人很重要等信号配合DEFINITE_KEEP(0.85)/DEFINITE_DROP(0.15)/DROP_THRESHOLD(0.3) 三段式门控——只有落在中间地带的边缘 chunk 才会付出一次 LLM 调用。priority_high标签GitHub 提交/合并的 issue 与 PR会获得0.25提升。读取侧则由memory_tree多模式工具承担src/openhuman/memory/query/mod.rssearch_entities模糊解析规范实体 ID、query_source按来源时间窗检索、drill_down沿child_ids下钻、cover_window覆盖时间窗的最小节点集、fetch_leaves批量水合原始叶子、ingest_document唯一的写模式以及无需 LLM 的确定性walk/smart_walkE2GraphRAG 风格基于实体共现图路由参数如limit默认 10、max_hops默认 2。历史query_global/query_topic模式已被移除——来源树的层级结构加上实体索引即可重建时间与主题两个投影。完整机制参见 retrieval.md。更换后端agentmemoryMemory Tree 管道chunker → score → seal → summarise是默认实现。自行托管 agentmemory 的多 Agent 场景中若希望 OpenHuman 共享同一份持久 store可以通过MemoryConfig.backend agentmemory选择外部后端。具体配置键、字段映射、端点表、安全性与失败模式参见 agentmemory-backend.md。关键设计取舍小结确定性优先内容寻址的 chunk ID 让重跑幂等单事务写入杜绝悬挂状态。热路径与重活分离摄取只做廉价启发式嵌入与实体抽取全部下沉到后台 worker。队列统一一切密封、主题路由、每日摘要、stale-flush 全部入队重试、去重、崩溃恢复集中管理。树而非纯向量压缩 导航 出处三者兼得嵌入只负责底层相似度召回。本机可读、可编辑、可导出wiki/是纯 MarkdownObsidian 可直接打开Agent 的记忆字面意义上就是你自己拥有的一个文件夹——如果 Agent 记错了找到那个文件、改掉它下一次检索就正确了。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenHuman Memory Tree 解析：本地优先的确定性记忆管道与分层摘要树架构
OpenHuman Memory Tree 解析本地优先的确定性记忆管道与分层摘要树架构【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman导读Memory Tree 是 OpenHuman 的本地优先知识库——它不是套了一层记忆壳的向量数据库而是一条确定性的、桶密封bucket-sealed驱动的流水线把聊天、邮件、文档、集成同步结果等杂乱日常流转化为结构化、可检索、带摘要、直接存放在本机的 Markdown。本文基于 memory-tree.md 展开结合 src/openhuman/memory/ 下的源码结构完整讲解其管道设计、三种摘要树的作用域、后台队列与调度器、叶子状态机、磁盘布局以及桌面端 Intelligence 页面的使用方式让读者既能照章实操也能理解底层原理。它做什么一条管道喂饱所有来源你接入的每一个来源都走同一条管道source adapters (chat / email / document) | v canonicalize normalised Markdown provenance metadata | v chunker deterministic IDs, 3k-token bounded segments | v content_store atomic .md files on disk (body tags) | v store persistence (chunks, scores, summaries, jobs) | v score signals embeddings entity extraction | v source / topic / global trees per-scope summary trees | v retrieval search / drill_down / topic / global / fetch热路径canonicalize → chunk → fast-score → persist → 入队后续任务必须快重活——嵌入计算、实体抽取、摘要桶密封、每日摘要——都在后台 worker 中执行因此 UI 永远不会被阻塞。嵌入计算和摘要树构建可以通过 Ollama 完全在设备上运行在 Local AI 中开启即可否则它们和普通模型调用一样走 OpenHuman 后端。从源码结构看这一层在仓库中的对应物是 src/openhuman/memory/tree/ 及其子模块tree/树读写与 RPC、retrieval/检索原语、tree_runtime/运行时操作而宿主层 src/openhuman/memory/mod.rs 负责 RPC 表面与 Agent 工具的编排。三棵树三个作用域Source trees来源树每个来源一个滚动缓冲区L0装满后密封成 L1 → L2 → … 逐级向上。Gmail 的每个 label、Slack 的每个 channel、每个上传的文档各有一棵自己的树。Topic trees主题树按实体热度hotness惰性物化。一个实体人、项目、股票代码、仓库出现得越频繁它的主题树就被越积极地构建和刷新。Global tree全局树每天一棵全局摘要覆盖当天摄入的所有内容。检索可以针对任意作用域搜索单个来源、下钻某个主题、或直接拉取全局摘要。数据落在磁盘的哪里在工作区内默认~/.openhuman或OPENHUMAN_WORKSPACE环境变量指向的位置路径内容memory_tree/chunks.dbChunks、分数、摘要、实体索引、任务队列、热度数据wiki/Markdown 仓库vault——参见 Obsidian Wiki一切都在本地。除非你显式把某个聊天消息发送出去否则你的原始数据不会离开本机。为什么是树而不是向量库向量库回答的是什么和这个查询相似而记忆需要回答更多今天发生了什么全局摘要这个人最近有什么动态主题树热度驱动上周二下午 3 点 Stripe webhook 说了什么来源树 出处溯源树同时提供压缩与导航。嵌入向量仍然存在于树内部所以语义搜索继续有效但上面的树形结构才是让记忆像大脑而不是一袋碎片的关键。管道是如何工作的面向用户的说法很简单连接一个来源Agent 就拥有了对它的持久记忆。兑现这个承诺的管道横跨HTTP 触发的摄取路径、持久任务队列、后台 worker 池、三棵独立摘要树以及一个每日 UTC 调度器。1. Ingest摄取新的聊天 / 邮件 / 文档到达后热路径将其规范化canonicalize为 Markdown切分成有界 chunk带确定性 ID跑一次廉价快速打分在单个事务中持久化所有内容把每个 chunk 标记为pending_extraction并为 worker 入队后续任务。这里有三个关键属性确定性Deterministicchunk ID 是内容寻址的对相同输入重复跑 ingest 永远不会产生重复。快速Fast这条车道上没有 LLM 调用只有廉价启发式。有界写入Bounded write一切在单个事务中完成部分摄取不会留下悬挂行。2. Queue任务队列后续工作落在持久任务队列中与 chunks 存在同一个磁盘 store 里。每个任务携带 kind、payload、去重键dedupe key、重试簿记和调度窗口。任务种类如下Kind作用extract_chunk深度打分 实体抽取。决定admitted还是dropped。append_buffer把一条 admitted 的叶子追加到来源或主题树的 L0 缓冲区。可能触发密封。seal把 L0 缓冲区压缩为 L1 摘要若父缓冲区已满则逐级级联。topic_route把叶子路由进各实体的主题树受热度检查门控。digest_daily构建全局每日摘要节点。flush_stale强制密封闲置过久的缓冲区。3. Workers后台 worker一个小型后台 worker 池默认 3 个从队列取任务执行。池子会被摄取路径立即唤醒同时带有短轮询兜底避免错过唤醒导致任务滞留。一个共享信号量semaphore限制并发的 LLM 调用数防止一波新来源意外扇出几十个并发嵌入。启动时任何租约已过期因崩溃或 kill的任务都会被归还队列——崩溃不会丢失已 admitted 但尚未密封的工作。4. Tree state树状态三棵相互独立的树从同一条叶子流构建Source tree——每个来源一棵。新叶子进入 L0 缓冲区缓冲区满或触发 stale-flush时一次seal写出 L1 摘要级联继续向上。Topic tree——每个高热度实体一棵。路由器检查实体是否足够热以拥有自己的树若是则追加到其缓冲区。Global tree——只有一棵树每个 UTC 日增长一个节点随天数累积向上合并。5. Scheduler调度器调度器循环独立于摄取路径运行。每天 UTC 00:00 它为昨天入队一条全局每日摘要、为今天入队一次 stale-flush。调度器本身不运行摘要器——一切走队列因此重试、去重和过期锁恢复都集中在同一处。6. Leaf lifecycle叶子生命周期每个 chunk 走过一个小型状态机pending_extraction -- admitted -- buffered -- sealed \ -- dropped抽取阶段根据深度打分决定admitted还是dropped。Admitted 的叶子进入缓冲区buffered。缓冲区密封时其中的每片叶子都被标记为sealed。dropped的叶子到此为止。其 chunk 行保留用于溯源但没有任何缓冲区或摘要引用它。这正是检索无需重跑管道就能展示出处的原因chunk 行加上它的终态生命周期标记就已足够。触发摄取Triggering ingest自动——每个活跃集成每 20 分钟自动拉取一次参见 Auto-fetch。手动——桌面应用的 Memory 标签页为每个来源暴露 Run ingest 触发器。RPC——openhuman.memory_tree_ingest供高级工作流使用。对应实现位于 src/openhuman/memory/tree/tree/rpc.rs 及其测试 rpc_tests.rs。桌面应用中的 Intelligence 标签页从底部导航栏打开。系统状态System status。页面顶部显示当前状态idle、ingesting、summarizing和一个Run ingest按钮可针对任意已连接来源手动触发同步。记忆指标Memory metrics指标含义Storageworkspace/memory_tree/chunks.db与 Obsidian vault 的总大小Sources已摄取的不同来源数量Gmail label、Slack channel、文档等各算一个Chunksstore 中 ≤3k-token 的 chunk 总数Topics目前物化出的主题树数量由热实体构建的 per-entity 摘要First / latest memory最早与最新 chunk 的时间戳记忆图谱Memory graph。基于实体索引绘制的力导向实体关系可视化。图谱会随 auto-fetch 持续拉取数据而增长——早期稀疏几天后变密。Obsidian vault。View vault in Obsidian按钮通过obsidian://open?path...深链直接打开workspace/wiki/。你也可以在任何文件浏览器中打开该目录。注意首次使用需先在 Obsidian 中把该目录注册为 vaultOpen folder as vault深链无法替你完成注册。摄取活动Ingestion activity。一个显示随时间变化的摄取事件热力图类似 GitHub 贡献图。适合发现 auto-fetch 空转的时段例如某个连接断开后停止同步。搜索与检索Search retrieval。覆盖 Memory Tree 的搜索栏。支持 source-scoped、topic-scoped 和全局查询任何结果都可以链接回 Obsidian vault 中对应的底层 chunk 文件实现完整溯源。路由Routing。Intelligence 标签页还会显示 Agent 每个任务正在使用哪个模型——参见 Automatic Model Routing。摄取的数据从哪来sources 与 auto-fetch在理解树本身之后值得把上游补全memory_sources域src/openhuman/memory/sources/维护一个类型化的连接器注册表支持 Composio OAuth 集成、对话记录、本地文件夹默认 glob**/*.md、10 MB/文件上限、带路径穿越防护、GitHub 仓库、RSS、网页可用 CSS selector 收窄以及 Twitter 查询等来源类型。每个来源还可设置max_tokens_per_sync、max_cost_per_sync_usd、sync_depth_days等每同步预算。自动拉取由 20 分钟一次的调度器驱动详见 auto-fetch.md每个活跃连接都有独立的游标、last-sync 时间戳、去重集合与每日预算状态按(toolkit, connection_id)维度持久化重启后从本地 KV 重建。webhook 等事件驱动同步与周期同步共享同一份 sync_state避免重复触发。最初的 60 秒设计被改成 20 分钟是为了用少量新鲜度换取显著更低的笔记本前台负载。入树前的关卡scoring 与检索并非每个 chunk 都配得上进入 Memory Tree。打分是入口关卡在 chunking 之后、追加到 L0 缓冲区之前执行详见 scoring.md综合 token 数、词汇多样性、来源权重、交互标签interaction权重最高因为直接用户参与最接近这对人很重要等信号配合DEFINITE_KEEP(0.85)/DEFINITE_DROP(0.15)/DROP_THRESHOLD(0.3) 三段式门控——只有落在中间地带的边缘 chunk 才会付出一次 LLM 调用。priority_high标签GitHub 提交/合并的 issue 与 PR会获得0.25提升。读取侧则由memory_tree多模式工具承担src/openhuman/memory/query/mod.rssearch_entities模糊解析规范实体 ID、query_source按来源时间窗检索、drill_down沿child_ids下钻、cover_window覆盖时间窗的最小节点集、fetch_leaves批量水合原始叶子、ingest_document唯一的写模式以及无需 LLM 的确定性walk/smart_walkE2GraphRAG 风格基于实体共现图路由参数如limit默认 10、max_hops默认 2。历史query_global/query_topic模式已被移除——来源树的层级结构加上实体索引即可重建时间与主题两个投影。完整机制参见 retrieval.md。更换后端agentmemoryMemory Tree 管道chunker → score → seal → summarise是默认实现。自行托管 agentmemory 的多 Agent 场景中若希望 OpenHuman 共享同一份持久 store可以通过MemoryConfig.backend agentmemory选择外部后端。具体配置键、字段映射、端点表、安全性与失败模式参见 agentmemory-backend.md。关键设计取舍小结确定性优先内容寻址的 chunk ID 让重跑幂等单事务写入杜绝悬挂状态。热路径与重活分离摄取只做廉价启发式嵌入与实体抽取全部下沉到后台 worker。队列统一一切密封、主题路由、每日摘要、stale-flush 全部入队重试、去重、崩溃恢复集中管理。树而非纯向量压缩 导航 出处三者兼得嵌入只负责底层相似度召回。本机可读、可编辑、可导出wiki/是纯 MarkdownObsidian 可直接打开Agent 的记忆字面意义上就是你自己拥有的一个文件夹——如果 Agent 记错了找到那个文件、改掉它下一次检索就正确了。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考