OpenHuman 实战：让 AI 真正懂你的桌面级个人智能体

作者：PySuper | 来源：zhengxingtao.com

当所有 AI 助手都在比拼"谁更聪明"时，OpenHuman 选择了另一条路——"谁更懂你"。

一、为什么需要 OpenHuman：AI 助手的"上下文碎片化"困境

你有没有经历过这样的场景？

早上打开 ChatGPT，问它"帮我整理下这周的进展"，它一脸茫然——它不知道你这周做了什么。你打开 Claude，想让它帮忙回顾一下和客户的沟通，它让你把邮件贴过来。你换到 Gemini，希望它能帮你追踪 GitHub PR，它让你先装个插件。

每一个 AI 助手都很聪明，但每一个都从零开始。

这就是当前 AI 助手面临的核心困境——上下文碎片化：

• 你的工作数据散落在 Gmail、Notion、GitHub、Slack、Jira、Linear 等十几个工具中

• 每个 AI 只能看到你手动喂给它的内容，无法主动获取你的工作上下文

• 每次会话结束后，所有上下文归零，下次又得重新"教"它

• 你花在"给 AI 提供背景信息"上的时间，可能比 AI 帮你省下的时间还多

据 TechTimes 报道，OpenHuman 的创始人 Sena Makel 曾提到一段亲身经历：他试图帮父亲设置一个开源 AI Agent，结果在 API Keys、YAML 配置文件和从未打开过的终端之间挣扎了 3 个小时，最终两人都放弃了。这让他意识到——今天每一个强大的 AI Agent 都是为那 0.01% 能自己搭建运行环境的人设计的，剩下 99.99% 的人只能在场边观望。

OpenHuman 的核心主张很简单：Agent 应该先了解你，而不是你先教 Agent。

用户还没打字，Agent 就已经知道了你的收件箱里有什么、日历上排了什么、代码仓库昨天发生了什么。这就是 OpenHuman 的"Day One Context"理念。

与同期爆火的两个项目相比，OpenHuman 走了完全不同的路线：

• OpenClaw = 广度优先。50+ 消息平台、44,000+ 社区 Skill，解决的是"连接一切"的问题

• Hermes Agent = 深度优先。自进化学习闭环，解决的是"越用越聪明"的问题

• OpenHuman = 上下文优先。Memory Tree + 自动同步，解决的是"从一开始就懂你"的问题

三种哲学，三个方向。但如果你最头疼的是"AI 每次都从零开始"，OpenHuman 可能是最直接的那把钥匙。

二、OpenHuman 是什么

2.1 定位

OpenHuman 是一个开源桌面级个人 AI 超级智能体（Personal AI Super Intelligence），由 TinyHumans AI 团队开发。它不是又一个聊天窗口，而是一个常驻桌面的 AI 系统——会主动同步你的数据、构建记忆、在你需要时提供完整上下文，甚至在你停止打字后还在后台持续思考。

据 GitHub 仓库的 README 描述：

OpenHuman is your Personal AI super intelligence. Private, Simple and extremely powerful.

2.2 三大核心设计哲学

• Private（私密） ：所有工作流数据加密存储在本地 SQLite，不上传云端。OAuth Token 本地加密，永远不经过 OpenHuman 服务器。支持 Ollama 本地推理，完全离线可用。

• Simple（简洁） ：从安装到运行只需几次点击，无需终端配置，无需手动编写 YAML。干净的桌面 UI，内置 Onboarding 引导，几分钟内从安装到对话。

• Powerful（强大） ：118+ 应用集成 + 持久记忆 + 智能压缩 + 多模型路由 + 语音 + 编码工具 + 桌面吉祥物，全部内置，无需安装插件。

2.3 项目关键数据

表格

据 36kr 报道，OpenHuman 只花了一个周末就在 GitHub 突破了 1 万颗 Star。作为对比，OpenClaw 获得第 1 万颗 Star 花了 62 天，Hermes 用了 10 天。

2.4 技术栈：为什么是 Rust + Tauri

这是 OpenHuman 最有意识的架构决策之一。在几乎所有桌面 AI 应用都在用 Electron 的时代，OpenHuman 选择了 Rust + Tauri。

据 掘金文章分析，这个选择带来了几个关键优势：

表格

对于一个需要后台常驻、每 20 分钟轮询、持续构建记忆的桌面智能体来说，低内存占用和低资源消耗不是锦上添花，而是硬性需求。你不会希望一个 AI 助手吃掉你 500MB 内存然后还让风扇狂转。

但也要注意，Tauri + CEF 的组合在跨平台兼容性上偶尔会有一些 rough edges（后面踩坑部分会详细说）。

三、核心架构深度解析

3.1 三阶段流水线：Connect → Fetch → Memory

OpenHuman 的核心工作流可以用一条清晰的流水线来描述：

第一阶段：Connect（连接）

通过一键 OAuth 授权连接你的第三方服务。每个连接都被暴露为类型化工具（Typed Tool），Agent 可以直接调用。支持 118+ 服务，涵盖：

表格

第二阶段：Fetch（抓取）

每 20 分钟，核心调度器会遍历所有活跃连接，拉取最新数据——新邮件、日历事件、代码提交、文档编辑，全部自动同步到本地。不需要写 prompt，不需要写轮询循环。当你早上打开电脑时，Agent 已经有了你过夜的邮件、今天的日程和队友的代码提交。

据 GitHub README 的原话：

Every twenty minutes the core walks each active connection and pulls fresh data into the memory tree. No prompts, no polling loops you have to write, so the agent already has tomorrow's context this morning.

第三阶段：Memory（记忆构建）

这是最核心的部分。拉取到的数据不是简单存储，而是经过一套确定性处理管线：规范化 → 分块 → 评分 → 层级摘要 → 双写入。下面展开详解。

3.2 Memory Tree：从数据到可检索的知识树

Memory Tree 是 OpenHuman 最重要的技术创新。它不只是保存对话历史，而是构建一棵真正的知识树：

处理管线详解：

1. 内容规范化（Canonicalization） ：所有数据统一转换为 Markdown 格式。HTML 标签被剥离，长 URL 被缩短，非 ASCII 字符被移除。确保不同来源的数据有一致的格式。

2. 分块（Chunking） ：规范化后的内容按约 3,000 tokens 一块进行切分。这个大小是有讲究的——足够小以便精确检索，又足够大以保留上下文完整性。

3. 重要性评分（Scoring） ：每个数据块基于时效性（Recency）、相关性（Relevance）和访问频次（Frequency）进行评分。高频访问和近期数据的得分更高，确保 AI 回答时优先参考最相关的内容。

4. 层级摘要树（Hierarchical Summary Tree） ：这是最精妙的部分。子节点的摘要会被进一步摘要为父节点，形成层级结构。当 AI 需要回答"X 项目的总体状况"时，直接读取高层摘要节点；需要细节时，向下钻取具体数据块。

5. 双写入（Dual Write） ：同一份数据同时写入两个地方：

   • SQLite 本地数据库：AI 查询用，支持快速索引和检索

   • Obsidian 兼容 Vault：用户可浏览、编辑、搜索，拥有完全的透明度和控制权

3.3 Memory Tree vs 向量检索：两种记忆哲学

大多数带记忆功能的 AI 工具使用向量数据库：把内容分块、向量化，检索时找最相似的 Top-K 块。OpenHuman 选择了不同的路径：

表格

据 ai-navigate-news 的分析，Memory Tree 的设计灵感来自 Karpathy 的 Obsidian Wiki 工作流。这种层级化的记忆组织方式更接近人类的记忆模型——你先回忆整体轮廓，再逐步展开细节。

3.4 Obsidian Vault 兼容：你的记忆，你做主

这是 OpenHuman 区别于所有其他个人 AI Agent 的重要设计：Memory Tree 的每一个数据块都以 .md 文件的形式存储在本地 Obsidian 兼容 Vault 中。

这意味着什么？

• 你可以用 Obsidian 直接打开、浏览、搜索你的 AI 记忆库

• 如果 Agent 记错了什么，你可以手动编辑对应的 .md 文件修正

• 你的知识库可以用 Git 做版本控制

• 即使不再使用 OpenHuman，你的数据仍然以标准 Markdown 格式存在

• 记忆不再是黑盒——每一个 AI 的回答，你都能追溯到来源

据 GitHub README：

The same chunks land as .md files in an Obsidian-compatible vault you can open, browse and edit, inspired by Karpathy's obsidian-wiki workflow.

3.5 TokenJuice：智能 Token 压缩

在 Agent 系统中，真正昂贵的不是一次对话，而是后台的 Fetch、Tool Call、Search、Web Parsing 和 Long-context 注入。TokenJuice 是 OpenHuman 内置的 Token 压缩层，在所有内容送入 LLM 之前进行压缩处理：

TokenJuice 处理管线五步走：

1. HTML → 纯 Markdown：剥离所有 HTML 标签，只保留语义内容

2. URL 缩短：将长 URL 替换为短标识符

3. 去除非 ASCII 字符：移除表情符号、特殊符号等对语义理解无用的字符

4. 冗余内容去重：去掉导航栏、页脚、广告等模板化内容

5. 关键信息提取：保留标题、正文、元数据，丢弃噪声

据官方声称，TokenJuice 可以降低 80% 的 Token 消耗。但需要注意——据 GitHub Issue #2020 的讨论，80% 是自报数字，实际效果取决于数据类型和压缩配置。对于合同、账单、医疗记录、合规材料等场景，你不能只看 Token 节省，还需要考虑可追溯性、原文审查和压缩误差控制。

3.6 模型路由：把合适的任务交给合适的模型

OpenHuman 支持超过 200 个模型，并根据任务类型自动路由：

表格

据 primeaicenter 的评测，OpenHuman 的路由系统在实际使用中表现合理——复杂任务会被正确升级到前沿模型，简单任务不会浪费昂贵的 API 调用。但在 Beta 阶段，偶尔会出现路由判断不准的情况。

默认模型配置中有一个重要的安全考量：据 Issue #2020 的审计，DEFAULT_MODEL = "reasoning-v1" 实际指向 OpenHuman 后端（api.tinyhumans.ai）。要完全本地化运行，用户需要手动覆盖 config.toml 中的 8 个 provider 字段。这在后面安全考量部分会详细讨论。

3.7 Neocortex 记忆引擎

据 头条文章 介绍，OpenHuman 的记忆系统被称为 Neocortex Memory Engine（新皮质记忆引擎），采用分层记忆架构：

表格

据说可以存储高达 10 亿 token 的信息，在普通 CPU 上 10 秒内检索 1000 万 token 的内容。不过这些性能数据来自官方宣传，实际表现需要你自己验证。

四、安装与上手

4.1 安装方式

OpenHuman 提供了三种安装方式：

方式一：官网下载（推荐）

访问 tinyhumans.ai/openhuman 下载对应平台的安装包：

• macOS：.dmg 文件

• Windows：.exe 安装包

• Linux：.AppImage / .deb

方式二：终端一键安装

bash

# macOS 或 Linux x64
curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh | bash

# Windows（PowerShell 管理员模式）
irm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 | iex

⚠️ 安全提示：据 KnightLi 的分析，管道式安装（piped shell command）是一个公认的供应链风险向量。如果你的电脑是日常主力机，建议先下载安装脚本审查后再执行：

bash

# 更安全的做法：先下载审查，再执行
curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh -o install.sh
cat install.sh  # 审查脚本内容
bash install.sh

方式三：从源码构建

据 GitHub 仓库 的贡献指南，从源码构建需要：

bash

# 前置依赖
# Git, Node.js 24+, pnpm 10.10.0, Rust 1.93.0, CMake

# 1. Fork 并 Clone 仓库
git clone https://github.com/tinyhumansai/openhuman.git
cd openhuman

# 2. 初始化子模块（包含 vendored Tauri/CEF 源码）
git submodule update --init --recursive

# 3. 安装前端依赖
pnpm install

# 4. 开发模式
# 仅 Web UI 开发
pnpm dev

# 桌面应用开发
pnpm --filter openhuman-app dev:app

# 5. 代码检查
pnpm typecheck
pnpm format:check
cargo check -p openhuman --lib

4.2 首次配置：5 分钟从安装到第一次对话

Step 1：安装并启动

下载安装包，双击安装，启动应用。首次运行会显示欢迎向导。

Step 2：连接第三方服务

在欢迎向导或设置页面中，点击你使用的服务进行 OAuth 授权。推荐先连接最核心的 3-5 个：

• Gmail：邮件上下文

• Google Calendar：日程上下文

• GitHub：代码和 PR 上下文

• Notion：文档和笔记上下文

• Slack：团队沟通上下文

Step 3：选择模型方案

两个选择：

1. 云 API（默认） ：直接使用 OpenHuman 内置的模型路由，开箱即用

2. Ollama 本地推理：隐私优先，完全离线

如果选择 Ollama 本地推理：

bash

# 1. 先安装 Ollama（如果还没装）
# macOS
brew install ollama
# Linux
curl -fsSL https://ollama.com/install.sh | sh

# 2. 拉取推荐模型
ollama pull gemma3:4b      # 轻量快速
ollama pull qwen2.5:7b     # 中文能力强

# 3. 在 OpenHuman 设置中配置
# Settings → Developer → Local Model
# 填入 Ollama Server URL（默认 http://localhost:11434）
# 点击 Test Connection 验证
# 点击 Save 保存

据 GitHub PR #1569，OpenHuman 现在支持在 UI 中直接配置 Ollama Server URL，不再需要手动编辑 config.toml。但在早期版本中，这个配置项是个 no-op，需要特别注意你使用的版本。

Step 4：等待首次同步

连接服务后，OpenHuman 会立即拉取一次数据。根据连接的服务数量和数据量，首次同步通常需要 1-5 分钟。之后每 20 分钟自动轮询。

Step 5：开始对话

试试这些提示词，感受 Day One Context 的威力：

plaintext

"我这周有哪些重要的未回复邮件？"
"帮我总结一下 X 项目的最新进展"
"今天有什么日程安排？"
"我最近的 GitHub PR 有什么需要处理的吗？"

五、实战 1：个人知识管理助手

5.1 连接 Gmail + Notion + GitHub

这是最常见的知识工作者场景：你的信息分散在邮件、文档和代码三个维度中。OpenHuman 的 Memory Tree 可以把它们统一成一个可检索的知识库。

连接配置：

1. Gmail：OAuth 授权后，OpenHuman 会自动拉取你的邮件标签和消息

2. Notion：OAuth 授权后，会同步你的页面和数据库

3. GitHub：OAuth 授权后，会追踪你的仓库、PR、Issue

每个连接在 OpenHuman 中都被暴露为类型化工具。这意味着 AI 不仅能读取历史数据，还能执行操作——发送邮件、更新 Notion 页面、创建 Issue 等。

5.2 自动构建个人知识库

连接完成后，OpenHuman 的自动同步机制开始工作：

5.3 用 Obsidian 浏览和编辑 Memory Tree

这是 OpenHuman 最独特的功能之一。你的 Memory Tree 数据以标准 .md 文件的形式存储在本地 Vault 中，可以直接用 Obsidian 打开：

Vault 目录结构示例：

plaintext

openhuman-vault/
├── gmail/
│   ├── inbox/
│   │   ├── 2026-05-client-a-project-discussion.md
│   │   ├── 2026-05-team-standup-notes.md
│   │   └── ...
│   ├── sent/
│   └── important/
├── github/
│   ├── my-project/
│   │   ├── pr-123-feature-implementation.md
│   │   ├── issue-456-bug-report.md
│   │   └── ...
│   └── another-repo/
├── notion/
│   ├── project-docs/
│   ├── meeting-notes/
│   └── ...
├── slack/
│   ├── general-channel/
│   └── dev-team/
└── calendar/
    ├── 2026-05-events.md
    └── ...

在 Obsidian 中操作：

• 浏览：双击任何 .md 文件即可查看 AI 存储的记忆内容

• 搜索：使用 Obsidian 的全局搜索快速定位特定信息

• 编辑：直接修改 .md 文件内容，下次 AI 查询时会读取更新后的内容

• 关联：使用 Obsidian 的双向链接功能建立知识关联

• 图谱：利用 Obsidian Graph View 可视化你的知识网络

5.4 搜索和召回历史上下文

OpenHuman 提供了两种记忆召回方式：

1. 自然语言查询（通过 Agent 对话）

plaintext

你：上个月和客户 A 关于定价的讨论结论是什么？

OpenHuman：（基于 Memory Tree 检索）
根据你的邮件记录和 Notion 文档，上个月和客户 A 的定价讨论结论如下：
1. 客户认为初始报价偏高，希望有 15% 的折扣
2. 你在 4 月 12 日的邮件中提出了阶梯定价方案
3. 客户在 4 月 15 日回复接受方案 B
4. 相关 Notion 文档：[项目定价策略]
5. 邮件来源：gmail/sent/2026-04-pricing-proposal.md

2. 直接浏览 Obsidian Vault

当你不确定该问什么的时候，直接打开 Obsidian 浏览 Vault 目录，像一个个人知识库一样使用。

六、实战 2：开发工作流自动化

6.1 连接 GitHub + Slack + Linear/Jira

对于开发者来说，OpenHuman 最大的价值在于打通代码、沟通和项目管理的边界。

推荐连接组合：

表格

6.2 自动追踪 PR、Issue、任务状态

OpenHuman 每 20 分钟自动同步，这意味着你的 Agent 始终了解最新的开发状态：

实际使用示例：

plaintext

你：帮我看看今天有哪些 PR 需要处理？

OpenHuman：
今天有 3 个 PR 需要你关注：

1. PR #234 - feat: add user authentication
   - 状态：等待你的 Review
   - 作者：@张三
   - Slack #dev 频道中 @张三 今天提到这个 PR 比较紧急
   - Linear Task: ENG-456 关联

2. PR #235 - fix: resolve memory leak in worker
   - 状态：已 Approve，等待合并
   - 有 2 个 Comment 未回复

3. PR #240 - refactor: update API client
   - 状态：CI 失败，需要修复
   - 最后一次 Commit 是 3 小时前

注意 Agent 不只是从 GitHub 获取信息——它还关联了 Slack 中的讨论和 Linear 中的任务，给出了完整的上下文。

6.3 代码审查辅助

OpenHuman 内置了完整的编码工具集（filesystem、git、lint、test、grep），可以作为代码审查助手：

plaintext

你：帮我审查一下 PR #234，重点关注安全性

OpenHuman：
我审查了 PR #234 (feat: add user authentication)，发现以下问题：

🔴 严重问题：
1. src/auth/token.rs:42 - JWT Secret 硬编码在源码中
   建议：使用环境变量或 Secret Manager

2. src/auth/middleware.rs:78 - 缺少 Rate Limiting
   建议：在认证端点添加请求频率限制

🟡 建议改进：
1. src/auth/password.rs:23 - 密码哈希使用 SHA-256
   建议：改用 bcrypt 或 argon2

2. tests/auth_test.rs - 缺少 Token 过期测试用例
   建议：添加 Token 过期和刷新的测试

整体评价：核心功能实现完整，但安全性需要加强后再合并。

6.4 团队沟通摘要

plaintext

你：昨天 #dev 频道讨论了什么重要的事情？

OpenHuman：
昨天 #dev 频道的主要讨论：

1. 🔥 热门话题：API v2 迁移时间线
   - @李四 提出建议将迁移截止日期延后一周
   - @王五 同意，认为测试覆盖率还不够
   - 最终决定：截止日期从 5/30 延后到 6/6

2. 📋 任务分配：
   - @张三 负责 Redis 缓存层重构
   - @赵六 负责前端性能优化

3. ⚠️ 阻塞问题：
   - staging 环境的数据库连接不稳定
   - 需要运维团队介入排查

七、实战 3：桌面吉祥物与语音交互

7.1 桌面 Mascot 配置

OpenHuman 的桌面吉祥物（Mascot）不是一个纯 UI 装饰——它是一个功能性的后台 Agent 接口。据 GitHub README，Mascot 的核心能力包括：

• 会议参与：作为真实参与者加入 Google Meet，实时记录讨论内容

• 后台处理：在你工作期间持续运行同步任务

• 主动提醒：基于日历和任务数据提醒即将到来的截止日期

• 个性化交互：拥有性格和记忆，不是一个无状态的"帮助机器人"

• 语音交互：原生语音输入（STT）+ ElevenLabs TTS 输出 + 口型同步

7.2 语音输入输出

OpenHuman 内置了原生语音支持：

• 语音输入：使用 STT（Speech-to-Text）将语音转为文本

• 语音输出：使用 ElevenLabs TTS 生成自然语音

• 口型同步：Mascot 的嘴巴动作与语音输出同步

• 热键：支持全局语音输入热键，随时启动语音交互

默认配置下，STT 和 TTS 都走云服务。如果需要完全离线，可以在 config.toml 中切换到本地模型：

toml

# config.toml - 语音配置
[local_ai]
stt_provider = "local"    # 云端 "cloud" / 本地 "local"（Whisper）
tts_provider = "local"    # 云端 "cloud" / 本地 "local"（Piper）

7.3 Google Meet 参会

这是 OpenHuman 最酷也最让人不安的功能之一。Mascot 可以作为真实的参与者加入你的 Google Meet：

• 实时转录会议讨论

• 自动生成会议纪要

• 提取行动项和待办任务

• 会后将摘要同步到 Memory Tree

据 36kr 报道，这个功能的体验相当惊艳——Mascot 会出现在参会者列表中，像一个沉默但专注的同事一样记录一切。但也要注意，让 AI 参加会议涉及隐私问题，确保所有参会者都知情并同意。

7.4 后台持续思考

OpenHuman 的 "Subconscious Loop"（潜意识循环）是一个后台进程，即使你停止打字，Agent 仍在持续工作：

• 每天执行约 10,000 次记忆检索循环

• 从你的数据中发现规律并主动提供洞察

• 检测到重要事件时主动提醒

实际体验：

plaintext

（你正在工作中，OpenHuman 弹出提醒）

🤖 OpenHuman：注意到客户 A 的邮件已经 3 天没有回复了，
上次讨论的是合同续签事宜。要帮你起草一封跟进邮件吗？

这种主动式智能是 OpenHuman 区别于"被动响应"型 AI 助手的核心体验。

八、与 OpenClaw / Hermes 的对比

8.1 三种哲学

据 TechTimes 报道，OpenHuman 的出现让开源 Agent 市场形成了三足鼎立的格局：

• OpenClaw = 广度：50+ 消息平台、44,000+ 社区 Skill，解决"连接一切"的问题。它的核心是 Gateway——把所有平台连在一起，然后通过 Skill 扩展能力。

• Hermes Agent = 深度：自进化学习闭环，解决"越用越聪明"的问题。它的核心是 Skill 自动生成——Agent 完成任务后会自动提取经验、生成可复用的 Skill 文档，并在未来任务中持续优化。

• OpenHuman = 上下文：Memory Tree + 自动同步，解决"从一开始就懂你"的问题。它的核心是 Memory——通过主动拉取你的所有数据，构建一个始终更新的个人知识库。

据 OpenHuman README 的原话：

Most agents start cold. Hermes learns by watching you work; OpenClaw waits for plugins to ferry context in.

8.2 功能对比表

表格

8.3 安全性对比

安全性是这三个项目共同的软肋，但问题各有不同：

据 BrainRoad 的报告，Cisco 的 AI 威胁和安全研究团队在 2026 年 5 月发布的分析中称 OpenClaw 是"a security nightmare"：

• CVE-2026-25253（CVSS 8.8）：零点击 WebSocket 漏洞，攻击者可以通过恶意网页远程执行命令

• Claw Chain 漏洞链（Cyera 发现）：4 个漏洞可以链式利用，实现代码执行 → 凭证窃取 → 权限提升 → 持久化后门

• Skill 市场：26% 的 31,000 个分析 Skill 包含安全漏洞，排名第一的 Skill 实际上是恶意软件

• 135,000+ 公网暴露实例，93.4% 无认证

据 CybersecurityNews 报道，约 245,000 个公网可访问的 OpenClaw 实例暴露在攻击面下。

相比之下：

表格

8.4 谁适合用什么

表格

九、安全考量

9.1 OAuth 权限范围：请求的权限确实很广

OpenHuman 需要持续 OAuth 访问你连接的所有账户。当你点击"连接 Gmail"时，你授予的不是一次性读取权限，而是持续的、广泛的访问权限。这对于实现"20 分钟自动轮询"是必要的，但也意味着：

• 如果 OpenHuman 被攻破，攻击者可以访问你所有连接的服务

• OAuth Token 存储在本地，但本地存储本身也可能被恶意软件读取

• 广泛的权限范围增加了潜在的数据泄露面

据 GitHub Issue #2020 的详细审计，安全问题比 README 声称的更复杂。

9.2 "开源"但"云优先"的矛盾

这是 OpenHuman 最大的安全争议。Issue #2020 的审计者 @tseek 发现了几个关键问题：

1. 默认模型指向 OpenHuman 后端

toml

# config.toml 默认配置
DEFAULT_MODEL = "reasoning-v1"  # 指向 api.tinyhumans.ai

make_openhuman_backend() 将这个别名映射到 OpenHumanBackendProvider，所有推理请求都发送到 api.tinyhumans.ai/openai/v1/chat/completions。要绕过，用户需要手动覆盖 8 个 provider 字段：

toml

# 需要手动覆盖的字段
reasoning_provider = "ollama"
agentic_provider = "ollama"
coding_provider = "ollama"
memory_provider = "ollama"
embeddings_provider = "ollama"
heartbeat_provider = "ollama"
learning_provider = "ollama"
subconscious_provider = "ollama"

没有 local-first 预设。 一个新安装的用户，即使本地运行了 Ollama，默认仍然会将所有推理请求发到云端。

2. 118+ 集成依赖 Composio 后端

toml

# 默认配置
composio.mode = "backend"  # 所有 Gmail/Notion/Slack 调用代理通过 api.tinyhumans.ai

在这个模式下，所有第三方集成调用都经过 api.tinyhumans.ai/agent-integrations/composio/* 代理。"direct" 模式存在，但需要用户自己的 Composio API Key，且实时触发 webhook 不工作。没有第三条路。

3. 记忆、嵌入、语音默认都走云端

toml

memory_tree.llm_backend = "cloud"       # → OpenHumanBackendProvider
memory.embedding_provider = "cloud"      # → OpenHumanBackendProvider
local_ai.stt_provider = "cloud"         # → 云端 STT
local_ai.tts_provider = "cloud"         # → 云端 TTS (ElevenLabs)

4. 计费遥测无条件回传

useUsageState 无条件轮询 api.tinyhumans.ai 的计费端点。即使用户将所有推理流量转到本地 Ollama，仍然会看到红色横幅"Your Usage is Exhausted"——因为计费 UI 绑定的是 OpenHuman 后端的计费计数器，而不是用户实际的推理路径。

5. 没有文档化的 self-host 路径

find . -iname 'self-host' -o -iname 'selfhost' 返回零匹配。没有文档说明当 api.tinyhumans.ai 不可达时，哪些功能还能工作。

这些发现与 OpenHuman 宣传的"Private, Local-first"形成了明显张力。正如 Issue #2020 审计者所问：

如果核心架构无条件将计费、遥测和默认工作负载路由到 api.tinyhumans.ai——没有明确的用户同意或清晰的文档——这究竟算"开源桌面客户端"还是"开源前端 + 云端后端"？

9.3 数据本地存储的隐私优势

尽管有上述争议，OpenHuman 的本地存储架构确实有真实的隐私优势：

• Memory Tree 数据：所有从第三方同步的数据存储在本地 SQLite，AES 加密

• Obsidian Vault：知识库以标准 Markdown 文件存储，完全透明

• Ollama 支持：可以切换到完全本地推理，数据不离开你的机器

• 桌面应用：默认不开放网络端口，不像 OpenClaw 那样常被公网暴露

9.4 安装脚本审计建议

无论你选择哪种安装方式，都建议：

bash

# 1. 下载安装脚本审查
curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh -o install.sh

# 2. 审查关键内容
# 检查是否从非 GitHub 域下载二进制
grep -E "curl|wget|http" install.sh
# 检查是否有 sudo 提权
grep -E "sudo|chmod|chown" install.sh
# 检查是否修改 PATH 或启动项
grep -E "export|PATH|launchctl|systemctl" install.sh

# 3. 确认后再执行
bash install.sh

9.5 与 Cisco 对 OpenClaw 安全报告的关联思考

OpenHuman 登上 GitHub Trending 的同一周，Cisco 发布了 OpenClaw 的安全报告，称其为"安全噩梦"。据 TechTimes 的分析，这并非巧合——任何要求同样广泛权限的新产品都值得被同等仔细地审视。

OpenClaw 的安全问题主要来自：

1. 公网暴露：135,000+ 实例无认证暴露在公网

2. Skill 市场：任何人都能发布恶意 Skill

3. WebSocket 漏洞：零点击远程代码执行

OpenHuman 在架构上有天然优势——桌面应用默认不开放网络端口，没有社区 Skill 市场。但 OAuth 权限范围同样广泛，而且默认将数据代理到云端的架构选择，与宣传的"local-first"存在矛盾。

9.6 最佳实践：使用最小权限、定期审计 Token

如果你决定使用 OpenHuman，建议采取以下安全措施：

bash

# 1. 仅连接你真正需要的服务
# 不要一次性连接所有 118+ 集成

# 2. 使用本地模型减少云端暴露
# config.toml
[local_ai]
base_url = "http://localhost:11434"
stt_provider = "local"
tts_provider = "local"

[memory]
embedding_provider = "local"
llm_backend = "local"

# 3. 定期检查和撤销 OAuth Token
# Google: https://myaccount.google.com/permissions
# GitHub: https://github.com/settings/applications

# 4. 监控网络流量
# 检查 OpenHuman 是否向非预期域名发送数据
sudo lsof -i -P | grep openhuman

# 5. 加密 Obsidian Vault
# 如果你的 Vault 包含敏感数据，考虑使用加密文件系统

# 6. 定期备份和审计 Memory Tree
# SQLite 数据库位置通常在:
# macOS: ~/Library/Application Support/OpenHuman/
# Linux: ~/.local/share/OpenHuman/
# Windows: %APPDATA%/OpenHuman/

十、生态与未来

10.1 第三方集成生态

OpenHuman 的 118+ 集成是通过 Composio 实现的。这意味着：

• 优势：集成质量由 Composio 维护，覆盖面广

• 劣势：默认模式下所有集成调用经过 api.tinyhumans.ai 代理，不是真正的本地优先

• Direct 模式：需要自备 Composio API Key，且实时触发功能受限

据 primeaicenter 的评测，集成的核心覆盖了知识工作者最常用的工具栈，但对于中国用户来说，缺少飞书、钉钉、微信等国内应用的适配是一个明显的短板。

10.2 MCP 协议支持

Model Context Protocol（MCP）是 Anthropic 提出的模型上下文协议标准，正在成为 AI Agent 互操作性的基础协议。截至目前，OpenHuman 还没有正式宣布 MCP 支持。但随着 MCP 生态的快速发展（Claude Desktop、Cursor 等都已支持），OpenHuman 未来很可能会加入 MCP 兼容层。

10.3 Skill 兼容性

与 OpenClaw 的 44,000+ ClawHub Skill 和 Hermes 的自动 Skill 生成不同，OpenHuman 目前没有社区 Skill 市场。其 118+ 集成是内置的，功能扩展主要通过配置和 Agent 配置文件（.agents/ 目录下的 .agent.md 文件）实现。

从源码中可以看到几个内置 Agent 配置：

plaintext

openhuman/
├── .agents/agents/
│   ├── coder.agent.md    # 编码代理
│   ├── planner.agent.md  # 规划代理
│   └── reviewer.agent.md # 代码审查代理

10.4 开源社区活跃度

表格

社区活跃度很高，但贡献者以核心团队为主。作为一个 GPL-3.0 协议的项目，任何修改和分发都需要开源，这为社区审计提供了法律保障。

10.5 路线图

据官方文档和社区讨论，OpenHuman 的近期方向包括：

• 自托管路径文档化：回应 Issue #2020 的安全审计，可能会发布 self-hosting.md

• Local-first 预设：一个一键切换到完全本地运行的配置选项

• 更多平台集成：持续扩展 Composio 支持的服务

• Mascot 功能增强：更多会议平台支持（Zoom、Teams 等）

• Mobile Companion：移动端配套应用

• 多人协作：团队共享记忆和 Agent 配置

十一、踩坑记录

作为一个 Early Beta 项目，OpenHuman 有不少 rough edges。以下是实际使用中遇到的常见问题。

11.1 Beta 阶段的各种 Rough Edges

问题：首次启动后 UI 渲染偶尔异常，Mascot 动画卡顿

原因：Tauri + CEF 的渲染管线在 Beta 阶段优化不充分

解决方案：

bash

# 如果 UI 渲染异常，尝试清理缓存后重启
# macOS
rm -rf ~/Library/Application\ Support/OpenHuman/Cache
# Linux
rm -rf ~/.local/share/OpenHuman/Cache
# Windows
rd /s /q "%APPDATA%\OpenHuman\Cache"

11.2 Tauri 框架兼容性问题

问题：在部分 Linux 发行版（特别是 Wayland 环境）上，Tauri 应用可能无法正常启动或渲染

原因：Tauri 依赖 WebView2/WebKitGTK，Wayland 支持仍不完善

解决方案：

bash

# 强制使用 X11 后端
GDK_BACKEND=x11 openhuman

# 如果 WebKit 版本过低，更新系统包
# Ubuntu/Debian
sudo apt update && sudo apt install libwebkit2gtk-4.1-dev

# Fedora
sudo dnf install webkit2gtk4.1-devel

问题：Windows 上安装后首次启动报错 "No CryptoProvider set"

原因：Tauri 的 vendored dev-server 代理构建了一个需要 rustls CryptoProvider 的 reqwest 客户端。这个问题在 PR #915 中已修复，但需要确保你使用的是最新版本。

11.3 OAuth 连接失败排查

问题：连接 Gmail/Notion 等 OAuth 服务时失败

常见原因和解决方案：

bash

# 1. 检查网络连接
curl -I https://accounts.google.com

# 2. 检查系统时间是否正确（OAuth 对时间敏感）
date  # 确认时间准确

# 3. 清理过期的 OAuth Token
# 删除本地存储的认证信息，重新授权
# macOS
rm ~/Library/Application\ Support/OpenHuman/auth-profiles.json
# Linux
rm ~/.local/share/OpenHuman/auth-profiles.json

# 4. 检查是否在企业网络/VPN 后面
# OAuth 回调需要能访问 localhost
# 如果被防火墙拦截，尝试：
# - 临时关闭 VPN
# - 配置防火墙允许 OpenHuman 的 OAuth 回调端口

# 5. Composio 后端模式检查
# 如果使用 direct 模式，确认你的 Composio API Key 有效

11.4 Memory Tree 增长过大的处理

问题：长时间使用后，Memory Tree 的 SQLite 数据库和 Obsidian Vault 文件夹体积过大

诊断：

bash

# 检查 SQLite 数据库大小
du -sh ~/.local/share/OpenHuman/*.db
# 或 macOS
du -sh ~/Library/Application\ Support/OpenHuman/*.db

# 检查 Obsidian Vault 大小
du -sh ~/OpenHuman\ Vault/

# 查看 SQLite 内部统计
sqlite3 ~/.local/share/OpenHuman/memory.db "
  SELECT 
    COUNT(*) as total_chunks,
    SUM(length(content)) as total_bytes,
    AVG(length(content)) as avg_chunk_size
  FROM memory_chunks;
"

解决方案：

bash

# 1. 手动清理旧记忆
# 在 Obsidian 中手动删除不再需要的 .md 文件
# 或直接编辑 SQLite 数据库

# 2. 调整记忆保留策略
# config.toml
[memory]
max_age_days = 90        # 仅保留 90 天内的热记忆
cold_storage_path = "/external/archive"  # 冷记忆归档路径

# 3. 压缩 SQLite 数据库
sqlite3 ~/.local/share/OpenHuman/memory.db "VACUUM;"

# 4. 增量同步调整
# 如果数据量特别大，可以增加轮询间隔
# config.toml
[sync]
poll_interval_minutes = 60  # 从 20 分钟改为 60 分钟

11.5 Ollama 本地模型性能不足

问题：使用 Ollama 本地模型时，推理速度太慢或内存不足

诊断：

bash

# 检查 Ollama 运行状态
ollama ps

# 检查系统资源
# macOS
top -l 1 | head -10
# Linux
htop

解决方案：

bash

# 1. 根据硬件选择合适的模型
# 8GB RAM 以下
ollama pull gemma3:4b        # 约 3GB，速度优先

# 8-16GB RAM
ollama pull qwen2.5:7b       # 约 5GB，平衡性能和质量

# 16GB+ RAM
ollama pull qwen2.5:14b      # 约 9GB，质量优先

# 2. 限制 GPU 显存使用
OLLAMA_MAX_VRAM=4G ollama run qwen2.5:7b

# 3. 使用外部 GPU 服务器
# config.toml
[local_ai]
base_url = "http://192.168.1.100:11434"  # 指向 GPU 服务器

# 4. 卸载不常用的模型释放内存
ollama stop qwen2.5:14b
ollama rm qwen2.5:14b

11.6 TokenJuice 压缩效果实测

官方声称 TokenJuice 可以降低 80% 的 Token 消耗。实际测试发现：

表格

关键发现：

• HTML 重度内容（网页抓取）的压缩效果最好，可达 70%+

• 纯文本内容（如简单邮件）的压缩效果有限，仅 15-25%

• 压缩率高度依赖原始数据的结构——冗余信息越多，压缩越有效

• 80% 是最佳情况下的数字，不是平均值

TokenJuice 的潜在风险：

据 KnightLi 的分析，压缩层也带来了新的问题——它决定了哪些信息被保留，哪些被丢弃。如果你用 OpenHuman 处理合同、账单、医疗记录或合规材料，你不能只看 Token 节省，还需要可追溯性、原文审查和压缩误差控制。

总结

OpenHuman 是一个野心勃勃但仍在 Beta 阶段的项目。它提出了一个令人兴奋的愿景——AI 应该先了解你，而不是你先教 AI。Memory Tree + 自动同步 + Obsidian Vault 的组合，确实在解决"上下文碎片化"这个真实痛点。

但正如我们在安全考量部分详细讨论的，"开源"和"local-first"的标签需要被仔细审视。默认配置下的云端路由、Composio 依赖和计费遥测，与宣传的隐私优先存在明显张力。Issue #2020 的审计揭示了一个重要的真相：OpenHuman 目前的架构更接近"开源前端 + 云端后端"，而非 README 暗示的"完全本地运行"。

我的建议：

• 如果你是隐私极客，愿意花时间配置 Ollama + 本地推理 + Direct 模式，OpenHuman 是目前最好的本地优先个人 AI Agent

• 如果你是普通用户，想要"装上就用"的体验，OpenHuman 的默认配置虽然方便，但你的数据实际上在走云端——你需要知道这一点

• 如果你在企业环境，在 Issue #2020 的安全问题得到正式回应之前，不建议将 OpenHuman 连接到包含敏感数据的服务

• 如果你是开发者，OpenHuman 的 Rust + Tauri 架构和 Memory Tree 设计值得深入研究，无论你是否使用这个产品

OpenHuman 的出现，标志着个人 AI Agent 从"通用聊天"到"个人操作系统"的演进。它不完美，但它提出的问题——AI 如何真正了解你——是这个领域最重要的问题之一。

代码是开源的，记忆是本地的，但选择权永远在你手中。

参考链接：

• OpenHuman GitHub 仓库

• OpenHuman 官网

• GitHub Issue #2020: Critical Security and Architecture Concerns

• TechTimes: The Agent That Reads You First

• BrainRoad: Personal AI Agents like OpenClaw Are a Security Nightmare

• CybersecurityNews: OpenClaw Chain Vulnerabilities

• PrimeAI Center: OpenHuman Review 2026

• KnightLi: OpenHuman Quick Read

• 36kr: OpenHuman 刷屏硅谷

• 掘金: 一天一个开源项目 - OpenHuman

• ai-navigate-news: OpenHuman Deep Read