openhuman

一款让你"把AI变成真正助手"的开源桌面应用

想象这样一个场景：你每天早上醒来，桌面上的AI助手已经读完了你昨晚的邮件、整理了昨天未完成的任务、查好了今天会议的相关背景——它像一个尽职的秘书，在你还没打开电脑前就已经在工作了。这不是科幻，而是 OpenHuman 正在做的事情。

图1：OpenHuman 桌面吉祥物界面（支持 Google Meet 会议参与、语音交互、屏幕感知）

---

背景故事：为什么有人要做"比 ChatGPT 更懂你"的AI？

2024-2025年，AI助手市场竞争激烈，ChatGPT、Claude、Gemini 相继登场。但核心问题始终存在：每次对话，AI 都是"从零开始"，它不认识你、不记得你的工作、不知道你的偏好。 这就像雇了一个失忆症秘书——每次见面都要重新自我介绍。

Sena Makel（OpenHuman 创始人）意识到这个问题后，决定做一款"有记忆的AI"。他的方案不是简单的对话历史，而是让AI像人一样，建立一套"记忆树"——把用户的邮件、文档、日历、项目信息，自动整理成可搜索、可编辑的本地知识库。2026年5月18日，OpenHuman 冲上 GitHub Trending 第一名，当天收获数万 stars，一度包揽 Product Hunt 日榜、周榜、月榜三个第一。

图2：OpenHuman 核心功能架构——记忆树 + 第三方集成 + 模型路由

---

它到底是什么？用生活比喻解释

如果把 AI 助手比作一个"超级秘书"，那么：

传统AI	OpenHuman
每次对话重新认识你	每次对话都在强化对你的了解
只知道当前对话内容	记住你所有连接过的工具数据
要手动复制粘贴信息	自动拉取 Gmail、Notion、Slack 等数据
只能文字对话	有桌面吉祥物、会说话、能参加视频会议
记忆存在服务商服务器	记忆存在你自己的 SQLite 数据库里

简单来说：OpenHuman = AI大脑 + 本地记忆系统 + 桌面吉祥物 + 118个第三方集成 + 智能模型路由。

图3：TinyHumans AI 团队 Logo

---

核心技术：它是怎么实现的？

1. 架构设计：Rust + Tauri + React

OpenHuman 的技术栈走了一条"高性能+跨平台"的路：

• Rust 核心（openhuman-core）：用 Rust 编写，负责 JSON-RPC 服务器，处理记忆树、OAuth 集成、模型路由等核心业务逻辑。Rust 的内存安全特性保证了核心模块的稳定性。
• Tauri 桌面框架：用 Tauri 替代 Electron，大幅降低内存占用（约 50-100MB vs Electron 的 200-500MB），同时支持 Windows/macOS/Linux 三平台。
• React 前端：桌面 UI 使用 React 构建，提供流畅的交互体验。
• Node.js 运行时：内置 Node.js 运行时用于执行部分脚本和工具。

2. 记忆树（Memory Tree）——本地优先的知识管理

这是 OpenHuman 最核心的创新。它将用户数据切分成不超过 3k token 的 Markdown 片段，经过评分后折叠成层级化摘要树，存储在本地 SQLite 数据库中。同一批片段同时以 .md 文件形式写入 Obsidian 兼容的本地仓库，用户可以直接打开 Obsidian 浏览和编辑。

核心依赖包括 serde_json（序列化）、tokio（异步运行时）、reqwest（HTTP 客户端，支持 rustls-tls 和 socks 代理）、rusqlite（SQLite 绑定）、aes-gcm + argon2（安全加密）。

3. 118+ 第三方集成（Composio 连接器）

OpenHuman 通过 Composio 连接器层，接入了 Gmail、Google Calendar、Notion、GitHub、Slack、Stripe、Linear、Jira 等主流服务。每个连接以类型化工具形式暴露给 AI 智能体。核心每 20 分钟自动遍历每个活跃连接，将新数据拉入记忆树——无需提示词，AI 自动拥有当天上下文。

托管模式下，OAuth 握手和集成工具调用通过 OpenHuman 后端代理；用户也可以自带 Composio API Key 直连，但实时 webhook 触发器仍需托管后端。

4. 模型路由——智能选择最适合的LLM

OpenHuman 内置模型路由系统，会根据任务类型自动选择合适的 LLM（推理型、快速型、视觉型）。默认使用 OpenHuman 后端路由，一个订阅覆盖所有模型。此外，项目支持配置本地 LLM（如 Ollama）处理低级别任务，保护隐私。

5. 桌面吉祥物——让AI"有脸"了

OpenHuman 的桌面吉祥物不是简单的聊天窗口，而是一个可感知周围环境的AI参与者：它会说话（ElevenLabs TTS）、能参与 Google Meet 会议、跨周记住用户状态，甚至在用户停止输入后仍在后台持续思考。

图4：吉祥物在 Google Meet 会议中作为真实参与者加入

---

上手体验：适合谁，不适合谁

适合：

• 有一定技术背景、想要深度定制个人AI工作流的用户
• 需要跨工具（邮件/日历/文档）自动整理信息的知识工作者
• 注重隐私、想把AI记忆存在本地的用户
• 技术开发者——项目代码质量高（Rust + 模块化架构），贡献门槛低（提供 CONTRIBUTING-BEGINNERS.md 引导）

不适合：

• 纯非技术用户——尽管有"开箱即用"的宣传，但 OAuth 配置、Composio 集成等步骤仍需要一定动手能力
• 需要一键部署到服务器的运维场景——这是桌面应用，不是 Web 服务
• 追求稳定生产环境——项目明确标注为"早期测试版"

---

争议与局限

1. "早期测试版"的真实含义：README 坦承项目在"积极开发中，可能存在不完善之处"。对于普通用户，这意味着更新可能频繁BREAKING CHANGE。

2. 隐私的双刃剑：虽然记忆存在本地 SQLite，但 Composio 托管模式下的 OAuth 代理意味着部分数据仍经过 OpenHuman 服务器。

3. 记忆树的Token限制：官方宣传"记住多达10亿Token"，但实际体验中记忆质量依赖于数据切片策略，过长或过短都会影响检索效果。

4. 吉祥物的实用性争议：桌面吉祥物的演示效果吸睛，但部分用户认为"语音对话+视频会议参与"更像是炫技功能，实际办公场景中使用率存疑。

---

行业意义

OpenHuman 的出现代表了一个重要趋势：AI 智能体正在从"问答工具"进化为"行动助手"。当AI不仅能回答问题，还能主动读取你的邮件、日历、文档，并在会议中扮演参与者角色时，人机协作的边界正在被重新定义。

从 GitHub 数据看，项目在 2026 年 5 月短短数周内从 0 冲到 27k+ stars，增长曲线陡峭，说明市场对"有记忆的、跨工具的、桌面优先的AI助手"有强烈需求。OpenHuman 的成功也为同类项目提供了产品定义上的参考——不是做另一个聊天界面，而是做"你数字生活的AI管理层"。

---

总结：OpenHuman 是一款野心勃勃的本地优先 AI 智能体平台，核心技术亮点是 Rust 编写的记忆树系统和基于 Composio 的 118+ 集成生态。适合技术背景用户深度定制，不适合纯小白用户。其"把AI记忆存在本地 SQLite + Obsidian"的思路，在隐私敏感场景下有独特价值。项目仍处于早期阶段，生产使用需谨慎评估。