OpenHuman：Rust 构建的本地优先个人 AI 助理

做 AI 助理很难绕开一个矛盾：想要它了解你，就得把你的一部分数据交给它。OpenHuman 的取舍是把"了解用户"这件事放在本地做——用 Rust 写底层，把邮件、日程、仓库、聊天记录拉回本机，压缩成你可以直接用 Obsidian 打开的 Markdown 记忆，再让模型在这个记忆上回答你的问题。数据数量级敏感的时候，还可以把推理整体切到本机的 Ollama 或 LM Studio，让任何数据都不出设备。

学习目标

读完本文，你应该能够：

• 说清 OpenHuman 的核心主张「Context in minutes, not weeks」解决的是模型的什么问题
• 讲明白 Memory Tree + Obsidian Wiki 的双层记忆为什么需要两层
• 知道 auto-fetch、TokenJuice、模型路由分别是压在哪一环
• 按自己的硬件（有没有 GPU、内存大小）和隐私要求选部署方式
• 判断它适不适合当你的个人助理，而不是团队平台

目录

• 项目速览
• 核心主张：几分钟建立上下文
• 系统架构
• 特色功能
• 与其他方案的区别
• 安装：官方脚本、包管理器和 Docker
• 已知局限
• 常见问题
• 故障排查
• 总结
• 自测题
• 进阶路径

项目速览

一句话：它是个"有记忆的桌面向导"。你授权它访问 Gmail、Slack、GitHub 这些服务，它每 20 分钟把数据拉回本地，压缩成记忆树；你提问时，它已经带着上下文工作了，而不是每次从空白开始。

核心主张：几分钟建立上下文

模型本身是无状态的。你敲一句 prompt，它答一句，上下文随即蒸发；就算有"记忆"，也多半只是存了几条要点。OpenHuman 的立场是：几条要点相当于一张便利贴，不是智能。

所以它的主打口号是「Context in minutes, not weeks」——几分钟建立上下文，而不是几周。灵感来自 Andrej Karpathy 用 Obsidian 管理个人知识库的做法：与其把记忆塞进谁也看不懂的向量数据库，不如把它写成盘上的 Markdown，人读得懂，程序员也审得了。

它解决的是 Agent 的冷启动问题。你接好账号，让 auto-fetch 拉一轮数据，第一次提问时它就已经有了你的邮件、日程和仓库的全量摘要，不需要你再喂一遍背景。

系统架构

Memory Tree + Obsidian Wiki

记忆系统分两层，各司其职：

1. Memory Tree（记忆树）：数据经过一条确定性流水线，先转成规范 Markdown，切成不超过 3k token 的块，逐块打分，再按来源、主题、日期折叠成摘要树，落进本机 SQLite。这是模型查询用的结构化知识。
2. Obsidian Wiki：同一份知识同步生成 .md 文件，放进兼容 Obsidian 的 vault，随时能用 Obsidian 打开、浏览、手动修订。

关键在"可读"这件事。因为记忆是盘上的纯文本，而不是别人家的向量存储里的黑盒嵌入，你能审阅它对你的认知，也能删掉不想让它记住的东西。

工程分工：Rust 核心 + TypeScript 桌面

代码库是一个 pnpm monorepo，两头分开迭代：Rust 一侧承担记忆树、工具执行和模型路由；TypeScript 一侧做桌面外壳、安装器和集成层。

这样设计的好处是，UI、安装、插件这类需要高频改动的部分可以快速试错，而真正决定上下文质量的本地记忆链路留在 Rust，性能和安全的底线不会被 UI 拖累。相应的代价是：项目还在 Early Beta，桌面外壳、OAuth 接入和路由逻辑都可能随时发生破坏性变更。按它自己的说法，这是用来抢先体验的，稳定性不该被默认成既定事实。

内置工具集

不必为"读个文件"装插件。默认就有一整套 agent 工具：网页搜索、网页抓取、代码能力（文件系统、git、lint、测试、grep）、浏览器与电脑控制、定时任务、记忆工具、子代理编排，以及原生语音。

tinyagents 运行图 + tinyflows 工作流

每个回合跑在开源的 tinyagents 图引擎上，有三个对长任务很关键的特性：

• 持久化检查点：子代理可以暂停等你的输入，再精确恢复，而不是整个死掉重来。
• 无进展熔断器：能打断"反复调用同一个接口却毫无进展"的死循环，并给出根因摘要。
• 可重放运行日志：每个回合都留档，带每次调用的 token 和费用统计。

在它之上，tinyflows 负责持久的工作流。你在对话框里描述一个自动化，它会先在画布上给出流程草稿，你确认后才变成常驻行为；流程跑到审批点会停下来等你批，结束后从断点精确续跑，全过程有逐步历史。

auto-fetch：每 20 分钟自动同步

接好 OAuth 之后，OpenHuman 每 20 分钟从各服务拉取一次新数据——Gmail 邮件、Slack 消息、GitHub 的 Issue/PR、Notion 文档、Calendar 日程、Drive 文件、Linear/Jira 的任务状态，以及其他 100 多个源。整条链路无需手动触发，也不用写一行轮询代码。

TokenJuice：进模型前先压缩

数据进入模型上下文前，先过一层 TokenJuice 压缩：HTML 转 Markdown、长 URL 缩短、非 ASCII 字符清理、重复内容去重。官方称最多能省下 80% 的 token。对你这种自带 API Key 的用户，这直接决定了"扫六个月邮件"是花几块钱还是几十块钱。

118+ OAuth 集成

通过一键 OAuth，能接入 118 个以上第三方服务，每个都暴露成模型可以直接调用的类型化工具。不需要写插件，不需要手工配 API Key，授权全在标准 OAuth 流程里完成；token 加密存在本机。

模型路由 + 本地 AI

内置模型路由，按任务难度分派：

• 复杂推理 → 推理模型（hint:reasoning）
• 快速查询 → 便宜型号（hint:fast）
• 视觉输入 → 视觉模型

这些模型走一个统一订阅计费，不用维护一堆 Key。敏感数据可以切到本地运行时（Ollama、LM Studio、MLX，或兼容 OpenAI 的本地接口），推理完全不联网。

隐私与安全

• 记忆、工作流数据都存在本机，本地加密存储，密钥放进操作系统钥匙串。
• 数据归属用户，不强制经云端。
• Privacy Mode（隐私模式）：在 Rust 核心做硬约束，一旦开启就结构性阻断所有云端模型调用，只允许本机运行时生效。
• agent 与 agent 之间的会话走 Signal 协议的端到端加密。

特色功能

桌面形象 + 语音

OpenHuman 自带一个桌面形象（mascot），会说话、会跟着内容同步嘴型：用 Whisper 做语音识别，用 ElevenLabs 做语音合成。它不只是个摆设——它就是一个你能用嘴对话的助理。

Google Meet 会议参与

它可以作为真实参会者进入你的 Google Meet，在会议里帮你记录：把会议发言转写进 Memory Tree，还能在需要的时候代表你发声。对"既要参会又要分心去别的窗口"的远程办公场景，这是其它终端型 agent 补不上的能力。

与其他方案的区别

下表是相对定位参考。第三方的能力随版本变化，具体以它们各自官方文档为准：

安装：官方脚本、包管理器和 Docker

macOS / Linux 用官方安装脚本：

curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh | bash

想先看它会做什么，可以加 --dry-run 只打印动作不落地：

curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh | bash -s -- --dry-run

Windows 用户以及用过脚本的，都可以直接到 tinyhumans.ai/openhuman 下载安装包。官方也提供 Homebrew、Debian 包、Arch 的 AUR 以及 Docker 等安装渠道，具体命令以对应渠道的文档为准。

已知局限

1. Early Beta：官方自己标注仍处早期开发，界面和能力会变，订阅时别指望它长期稳定。
2. 常驻资源消耗：auto-fetch + 持续同步 + 后台整理会带来可感知的内存 / CPU 占用，不是装完就不理的应用。
3. OAuth 信任问题：118+ 的一键授权走的是标准流程，但要不要把 Gmail、Slack 读权限交给一个开源项目，是需要你自己权衡的信任决策。
4. TokenJuice 压缩有信息损失：省 80% 是真，但高压缩必然丢细节。对答案质量要求高的场景，可以调低压缩力度。

常见问题

Q1: 需要一直后台运行吗？

不用。它是普通桌面应用，像 Mac/Windows 应用一样开关。auto-fetch 只在运行时工作；想持续同步就设开机自启，但不强制。

Q2: 记忆会占多少磁盘？

取决于接入的数据量。记忆树存的是压缩摘要而非原始数据，普通个人用户（约 10 个服务跑一个月）通常在几十到两百 MB 量级。

Q3: OAuth 授权安全吗？它能不能看到我所有数据？

走标准 OAuth 2.0，你能看到并确认每个服务授权的具体范围（例如 Gmail 只读，而不是可发信）。token 加密存在本地钥匙串。

Q4: TokenJuice 压缩会降低回答质量吗？

会有影响。官方称在大多数场景下质量损失可接受；对精度敏感的任务，可以在配置里调低压缩比例，用更多 token 换更全的信息。

Q5: 能完全离线用吗？

分两半：AI 推理可以完全离线（切 Ollama / LM Studio）；但 OAuth 数据同步必须联网。记忆树、工作流和 Obsidian 文件始终在本地。

故障排查

打开后闪退

macOS 未签名应用被安全策略拦下的概率最高。到「系统设置 → 隐私与安全性」，找到被阻止的 OpenHuman，点「仍要打开」并输入管理员密码。

OAuth 授权后提示无法连接 localhost

OpenHuman 用本地端口接收 OAuth 回调，端口被占就会失败。把配置里的 OAuth 回调端口改成别的可用端口再重启即可。

auto-fetch 不更新数据

先确认应用确实在运行、并显示已连接；再查官方文档里的日志位置看具体报错。网络不通的话，通过环境变量配好 HTTP/HTTPS 代理再试。

记忆查询变慢

本地模型场景下先确认内存够用（至少预留 8 GB 空闲）；如果数据库持续增长，按官方文档调整缓存与压缩参数。

总结

OpenHuman 用 Rust + SQLite + Obsidian Markdown 搭了一套"本地优先、AI 可读、人也可读"的记忆系统，再用 auto-fetch 和 OAuth 把个人数据的汇总自动化。它没能绕开 Agent 的所有老问题——Beta 期、资源占用、第三方接入的信任——但至少把你给模型的"个人背景"这件事，从每次对话手动重讲，变成了一个会自己生长的本地文件。如果你受够了"每次都要重新交代自己是谁"的对话，这个项目值得看着它跑起来。

自测题

回答这 5 个问题，检验你读的是不是真懂了：

1. 为什么模型需要 Memory Tree，而不是对话记录里那几条要点？
2. Memory Tree 和 Obsidian Wiki 各自服务谁？为什么要留两层？
3. TokenJuice 在哪一环起作用，它改变了什么成本？
4. 118+ OAuth 对你意味着什么，对比"手写 API Key 脚本"不同在哪？
5. 如果让你真读这个仓库，你会先看哪几个设计决策、为什么？

3 题以上答不准，回头重看「核心主张」和「系统架构」两节。

进阶路径

阶段 1：跑通基础（1-2 天）——装好、接入 1-2 个服务，观察 auto-fetch 生成的 Obsidian 文件，确认记忆树正确记录了你的上下文。

阶段 2：深入配置（3-5 天）——配模型路由、调 TokenJuice 压缩比例，接入 GitHub、Slack、Calendar，读 Memory Tree 源码搞清双层记忆怎么落盘。

阶段 3：日常与隐私（1-2 周）——真的上班用起来，接 Google Meet 参会体验语音；按资源与隐私诉求调 auto-fetch 频率，或整体切本地模型。

阶段 4：读源码（2-4 周）——读 Rust 核心的 Memory Tree 和工具执行，读 TypeScript 外壳的 UI 与集成，试着提 PR，再想想这套架构能不能复用到你自己的项目。