GitHub 上有一个仓库，README 开篇就把话说满了——"Your Personal AI super intelligence"，你的个人 AI 超级智能。但它紧接着自己找补了一句："OpenHuman is not AGI. But it is a meaningful architectural step closer, with better memory, better orchestration, and better tooling."（OpenHuman 不是 AGI，但它在架构上确实近了一步：更好的记忆、更好的编排、更好的工具链。）少见的是，它愿意先给自己划边界。
这个仓库叫 tinyhumansai/openhuman。GitHub API 实测（2026-09-01）：39,264 星 / 3,855 fork，主语言 Rust，许可证 GPL-3.0，创建于 2026-02-18，最近一次 push 就在今天（2026-09-01），382 个 open issue，未归档。创建者 @senamakel，文档托管在 tinyhumans.gitbook.io/openhuman，社区有 Discord、Reddit 与 X，README 带简体中文版（docs/README.zh-CN.md）。
先说清两个口径。第一，周榜数据（2026-08-30 快照）显示它排第 20 名、39k 星、周增 1,298——那是过时快照，正文一律以 API 实测的 39,264 星为准。第二，README 那句"上线一周内连续九天蝉联 GitHub trending 第一"是项目方自述，本站未做第三方核验；且"一周内连续九天"字面就自相矛盾，引用前先打折。
本文基于 README 一手材料与 GitHub API 实测拆解，事实截至 2026-09-01。它不是软文：后面有整整三段讲避坑，其中一段讲许可证。
一、它到底是什么：三件套，不是单点功能
官方描述把三件事并列说出来：一个为你的生活建立本地优先记忆的大脑、一个 agent 集群与工作流的编排器、一个深度研究员。这三件事不是三个功能开关，而是三层互相依赖的架构——记忆层给编排层供上下文，编排层给研究层供执行能力，研究层的产出又回流进记忆层。
市面上大多数 AI 助手只做其中一层：聊天框做对话，编程 agent 做代码，自动化工具做流程。OpenHuman 的野心是把三层串成一个闭环，而且数据全部落在本机。这一点决定了它的气质：它不是一个你打开的网页，而是一个常驻在你机器上的进程，会自己去拉数据、自己整理、自己跑任务，然后把需要你拍板的部分推到你面前。
二、The brain：把记忆压成"带评分的 Markdown 树"
第一件套是记忆。它的做法和主流 RAG 路线刻意不同：数据被压缩成一棵带评分的 Markdown 树，存在本机 SQLite 里，同时镜像成一份 Obsidian vault。
两个关键设计。第一是"带评分"：记忆不是平铺的日志，而是按重要性打分后组织成树，取用时可按分数剪枝，把有限的上下文窗口留给真正重要的节点。第二是"Markdown 树 + Obsidian 镜像"：你的记忆不是躺在只有程序能读的向量库里，而是一份能用 Obsidian 打开、能手动编辑、能 grep 的纯文本。README 那句"No vector-soup black box"说的就是这个——你可以随时查看它记住了什么，也能直接改错。
数据从哪来？官方自述有 100+ OAuth 集成、5,000+ MCP servers、90,000+ Skills——三个数字均为官方自述口径，未见第三方核验，请按"宣传量级"而非"实测规模"读。数据进来靠 auto-fetch：每 20 分钟本地拉一次喂给记忆层。这个"主动拉"而非"等你喂"的设计，是它与插件式方案最本质的差别，第五节展开。
记忆之上还有 Goals & Todos：长期目标、按会话线程（per-thread）的目标，以及每个会话共享的看板。这让 agent 不只是"记得你说过什么"，还"知道你当下在追什么"。
最后是 TokenJuice：工具输出在进模型之前先被压缩，官方口径是"up to 80% fewer tokens"，并直言"A brain this big would be unaffordable without it"。"up to 80%" 是官方自述上限，不是实测均值，别拿它做成本模型的基准值。但方向是对的：当记忆体量涨到一定规模，压缩层不是优化项，而是能否成立的前置条件。
三、The orchestrator：图、子 agent 集群与加密互调
第二件套是编排，也是三者里最有信息量的一层。
Graphs, not loops. 这是它对自己架构最核心的一句概括。多数 agent 的执行模型是循环：模型决定下一步、调工具、看结果、再决定，直到停。循环的问题是不可中断、不可恢复——进程崩了就全没了，中间想插句话也不行。OpenHuman 把每一轮跑在开源 tinyagents 的 checkpointed graphs上：每步都有检查点，因此可暂停等人、可 survive restart、可 resume mid-run。这三个能力合起来，"长任务托管"才真正可交付。
Sub-agent fleets. 专家 agent 可以嵌套到三层深（three levels deep）。更有意思的是失败处理：卡住的 agent 不会无限重试，而是收敛成一份 root-cause 报告交给上层。这是从"让它自己想办法"到"让它知道什么时候该上报"的一步——无限重试是 agent 系统最典型的成本黑洞，把它变成一份报告，是把失控风险转成了人的注意力成本。
Agent-to-agent, encrypted. 多个 OpenHuman 实例之间可以通过 Signal 协议的端到端加密会话加上 x402 支付互相编排，README 原话是"No server ever sees plaintext"（没有任何服务器看得到明文）。加密是 Signal 协议级别的，支付走 x402——这意味着跨实例的协作既有通信机密性，也有结算通道。
A split brain, always on. 一个快的 reflex agent 分流入站流量，一个 deep reasoning core 把复杂任务委派给 worker fleets，由 subconscious 引导。典型的快慢分层：便宜的快通道消化琐碎请求，昂贵的核心推理只在必要时介入。
Workflows 基于开源的 tinyflows：agent 提议自动化，你在可视化 canvas 上审查后保存。工作流 durable、由触发器驱动（schedules / webhooks / channel events）、能扛住重启，且所有副作用一律 gate 在审批之后。最后一点尤其重要——一个会自己写工作流的系统若没有审批闸门，等于给了它一把能自己配的钥匙。此外每次 run 可重放并显示 real per-call costs，对做成本治理的团队是刚需。
权限治理这条线，本站的 Agent 凭证与权限治理横评 拆过各家在凭证存储、审批闸门与最小权限上的差异，OpenHuman 的"审批前置 + OS 密钥环"可以放进那个框架横向对照。
四、The deep researcher & doer：搜索、路由与十七个入口
第三件套是执行与触达。
搜索由 Exa 驱动，内置且已含在订阅里，不需要你自己申请 API key；也可以自带 Exa key 走自己账户计费。配套工具有 scraper、coder toolset、真实 browser，以及 native voice（in-process Whisper，进程内转写，不是外挂服务）。
Model routing 按负载挑 LLM。这里的表述值得拎出来：订阅是默认值而非锁定——可指向自己的 provider key 或本地 Ollama，三种可混用。"订阅是默认不是锁定"，是判断 AI 产品是否尊重用户资产的关键判据。
生成能力上，Seedream / SeedEdit 出图，Seedance / Veo 出视频。触达面上支持 17 个消息渠道：Telegram、Discord、Slack、WhatsApp、Signal、iMessage 等，外加原生邮件（IMAP IDLE + SMTP）。它还能加入 Meet / Zoom / Teams / Webex 会议并发言、输出实时转录。"能进会"目前仍是稀缺项——它把 agent 的作用域从"你主动找它"扩展到了"它在你的协作现场"。
五、上手速度：从"等它学你"到"一次同步就有上下文"
这一节是 OpenHuman 自己最想讲的部分，也是它差异化最锋利的地方。
README 承认它受 Karpathy 的 LLM Knowledgebase 启发，并点名对比了两个同类："Hermes learns by watching you work; OpenClaw waits for plugins to ferry context in"（Hermes 看你干活来学习，OpenClaw 则等插件把上下文一趟趟搬进来）。它接着指出：这两条路都要几天到几周才够用。
OpenHuman 换了一条路：接上账号后，auto-fetch 每 20 分钟在本地拉一次数据，Memory Trees 压缩成 Karpathy 风格的 Obsidian wiki，一次同步就有完整的压缩上下文。它绕开"让模型慢慢观察你"的冷启动，改成直接把你已有的数字痕迹压成可检索档案，冷启动从"数天到数周"压到"一次同步"。
还有一条互通路径：把 Memory backend 代理到开源的 agentmemory，在 config.toml 里设 memory.backend = "agentmemory"，即可与 Claude Code / Cursor / Codex / OpenCode 共用同一套持久存储，解决的是"记忆碎片化"——你在四个工具里的上下文不再是互不相通的孤岛。
六、隐私边界：Privacy Mode 强制在哪一层
隐私这块，值得区分的是"承诺"与"架构强制"。
常规项四项：on-device encrypted data（本机加密数据）、approval gate（审批闸门）、OS-keyring secrets（密钥存进系统密钥环而非明文配置文件）、opt-in sandboxing（可选沙箱）。OS-keyring 是少有项目愿意做对的细节，成本不高却挡掉了最常见的一类泄露。
重点是 Privacy Mode：一键切换后推理不离开本机，README 强调在 Rust core 层强制（"enforced in the Rust core"）。分量在于它是架构级强制而非开关式承诺——开关式承诺依赖代码路径上每个调用点都不越界，核心层强制则意味着 outbound 路径在底层就被截断。但架构强制不等于可验证，本站未做流量层实测核验，是否真不出网，建议你在网关上自己抓包确认。
七、避坑一：Early Beta 与 382 个 open issue
现在开始泼冷水。
README 的徽章明写 Early Beta，原文"Under active development. Expect rough edges."（活跃开发中，请预期粗糙的边缘）。配合 382 个 open issue 一起看，图景很清晰：功能版图铺得很开、完成度仍在早期。
"功能版图铺得开"本身就是风险——十七个消息渠道、会议接入、图像视频、agent 集群、工作流，每一条都是需要长期维护的集成面，集成面越多，上游 API 变动带来的破碎率越高。382 个未关闭 issue 对 39k 星的仓库既不算失控（说明社区在真实使用），也绝不能读作"稳定"。结论：先做个人试点，别直接扛生产 SLA。
八、避坑二：GPL-3.0 的传染性，本篇最硬的一条约束
这是本文最该被记住的一段。
GitHub API 实测的 license.spdx_id 是 GPL-3.0（README 徽章写 GNU）。这与两个直接同类形成鲜明对比：OpenClaw 是 MIT，Hermes 也是 MIT。GPL-3.0 是强 copyleft：你若把 OpenHuman 的代码并入自己的产品并分发，派生作品通常也须以 GPL-3.0 开源。对想嵌进商业闭源产品的团队，这是硬约束，不是靠"只用一小段"就能绕过的软条款。
边界要说清楚：仅仅"运行使用"不触发传染，触发的是"修改后分发"。因此个人使用、企业内部使用、以及不分发二进制的服务端（SaaS）使用，通常不落在这条条款的射程内。但反过来，如果你打算改它的代码、打包进自己的客户端产品再发给客户，那基本就是派生作品了。
以上为通用许可常识梳理，非法律意见，具体条款以仓库 LICENSE 原文与你方法务的判断为准。 场景涉及分发时，这一步别省。
九、避坑三：那张对比表已经过时，以及三个官方自述数字
README 自带一张四家对比表：Claude Cowork / OpenClaw / Hermes Agent / OpenHuman，维度含 Open-source、Simple to start、Cost、Memory、Integrations、Auto-fetch、Orchestration、Workflows、Meetings、Messaging channels、Local-only mode。表有用，但已经过时，而且过时得正好压在关键维度上。
表里把 OpenClaw 标为 Memory: Plugin-reliant（依赖插件）、Orchestration: Single loop（单循环）、Auto-fetch: None（无主动拉取）；许可证一行写 OpenClaw 为 MIT、Hermes 为 MIT、OpenHuman 为 GNU、Claude Cowork 为 Proprietary。问题在于：OpenClaw 2.0 于 2026-08-30/31 发布，刚引入 Shared Cloud Sessions（多机、多人协作与接管）和 Active Memory（后台记忆整合）。也就是说，这张表反映的是 2.0 之前 的 OpenClaw——它在记忆与编排两条线上给 OpenClaw 的判语，恰好是 2.0 这次更新的主攻方向。
所以这张表不能当现状结论读。想看 OpenClaw 2.0 改了什么，请翻同批的 OpenClaw 2.0 发布热点 与配套的 2.0 升级迁移 SOP。三篇对着看，你会得到比任何单方 README 都可靠的坐标系：OpenHuman 押本地优先的压缩记忆与图式编排，OpenClaw 2.0 押云端共享会话与后台主动记忆，两条路在"记忆归谁、在哪算"上正面分岔。
另外几个数字必须标注口径：90,000+ Skills、5,000+ MCP servers、80% token 压缩，加上前面那句 trending 第一，全部来自项目方自述，本站未见任何第三方核验，请一律按"官方声称"对待。集成数量尤其容易失真——注册表条目数和真正被维护的可用条目数通常差一个量级。
十、谁该用，谁不该用
该用：你想要一份能读、能改、能 grep 的本地记忆档案，而不是又一个向量黑箱；任务需要长周期托管、中断后恢复、人在环审批；你在意推理不出本机，愿为架构级强制付配置成本；你已在用 Claude Code / Cursor / Codex / OpenCode，想让它们共用一份持久记忆。
不该用：你需要 MIT 许可，或打算把代码并入闭源产品分发——GPL-3.0 是硬墙；你要生产级 SLA，Early Beta 加 382 个 open issue 撑不住；你不愿做本地运维，托管产品更省心；你只想要写代码的副驾，它功能过剩。
一句话选型：它卖的是"记忆归你、编排可控、推理不出门"，代价是 Early Beta 的完成度与 GPL-3.0 的约束，这两笔账你得自己算清。
十一、安装与上手
两条路：从 https://tinyhumans.ai/openhuman 或 GitHub Releases 下载安装包；或在终端按 INSTALL.md 走，README 列了 Homebrew、Debian/Ubuntu 的 .deb、AUR 与安装脚本四种方式。
上手顺序建议：先在非主力机跑通，接一两个只读型账号看 auto-fetch 与 Memory Tree 的实际产出，打开镜像出的 Obsidian vault 检查压缩得对不对，再决定接更多账号、开工作流。工作流务必先小范围试跑，确认审批闸门真能拦住副作用，再放开权限。
参考来源
- tinyhumansai/openhuman GitHub 仓库（39,264 星 / 3,855 fork，Rust，GPL-3.0，创建 2026-02-18，最近 push 2026-09-01，382 open issue）：https://github.com/tinyhumansai/openhuman
- OpenHuman 文档站：https://tinyhumans.gitbook.io/openhuman/
- README 简体中文版：https://github.com/tinyhumansai/openhuman/blob/main/docs/README.zh-CN.md
- 下载页与 Releases：https://tinyhumans.ai/openhuman
- 本站相关：OpenClaw 2.0 发布热点 ｜ Agent 凭证与权限治理横评 ｜ 2.0 升级迁移 SOP ｜ OpenClaw 资源盘 ｜ Hermes Agent 资源盘
常见问题
Q1：OpenHuman 的许可证到底有什么坑？ A1：GitHub API 实测为 GPL-3.0（README 徽章写 GNU），属强 copyleft。仅运行使用不触发传染，触发的是修改后分发——并入闭源产品再分发，派生作品通常也须以 GPL-3.0 开源。个人使用、企业内部使用、不分发二进制的服务端使用通常不在射程内。以上为通用许可常识梳理，非法律意见，以 LICENSE 原文和法务判断为准。
Q2：README 那张四家对比表可信吗？ A2：可用但已过时。它把 OpenClaw 标成 Plugin-reliant memory 与 Single loop，而 OpenClaw 2.0 在 2026-08-30/31 已引入 Shared Cloud Sessions 与 Active Memory，改的正是这两条。这张表反映的是 2.0 之前的 OpenClaw，不能当现状结论读，同批的发布热点与升级迁移 SOP 才是当前口径。
Q3：90,000+ Skills、5,000+ MCP servers、80% token 压缩，这些数字能信吗？ A3：全是官方自述口径，未见第三方核验，按"官方声称"对待。集成类数字尤其容易失真，注册表条目数与真正被维护的可用条目数通常差一个量级。80% 是官方给出的压缩上限而非实测均值，别当成本模型基准值，建议自己抓实际调用的 token 数据。
Q4：Early Beta 到底能不能上生产？ A4：不建议。README 徽章明写 Early Beta，原文"Expect rough edges"，382 个 open issue 未清，2026-02-18 创建仍在活跃开发中。功能版图铺得极开（17 个消息渠道、会议接入、图像视频、agent 集群、工作流），集成面越广、上游变动的破碎率越高。适合个人试点，不适合扛生产 SLA。
Q5：它和我在用的 Claude Code / Cursor / Codex 会冲突吗？
A5：不冲突，还能共用记忆。在 config.toml 里设 memory.backend = "agentmemory"，即可把 Memory backend 代理到开源的 agentmemory，与 Claude Code / Cursor / Codex / OpenCode 共用同一套持久存储。二者不是替代关系：它管跨会话的持久记忆与长任务编排，编程 agent 管编辑器里的活。