OpenHuman、OpenClaw 与 Hermes Agent：三种“个人智能体”的分叉

基于 2026-05-17 UTC 对公开资料、GitHub 仓库、官方文档与项目代码的核对。

OpenHuman 最近在 GitHub 上很显眼。它的口号是“Personal AI super intelligence”，主张把 Gmail、Slack、GitHub、Notion 等个人数据接进一个本地优先的记忆系统。它也在 README 里直接拿 OpenClaw、Hermes Agent 做对照。这种对照值得拆开看，因为三者都在做“个人智能体”，但其实解决的问题不一样。

一句话概括：OpenHuman 想先把你的世界喂给一个桌面智能体；OpenClaw 更像一个可运行在多渠道里的个人助手底座；Hermes Agent 则更偏向一个长期可进化、可远程、可工具化的智能体运行时。

先把事实摆清楚

• OpenHuman：仓库为 tinyhumansai/openhuman，GPL-3.0，主语言 Rust。GitHub API 在 2026-05-17 10:17 UTC 显示约 11.3k stars、993 forks、116 open issues，最近一次 push 为 2026-05-17 09:38 UTC。README 和 GitBook 都把它定义为 Rust + Tauri 桌面应用，强调 UI-first、118+ OAuth 集成、Memory Tree、Obsidian-style wiki、TokenJuice 压缩、20 分钟 auto-fetch。
• OpenClaw / 小龙虾：仓库为 openclaw/openclaw，MIT，主语言 TypeScript。GitHub API 同一时间显示约 372.5k stars、77.2k forks、6908 open issues。官方 README 把它描述为“run on your own devices”的个人 AI 助手，支持 WhatsApp、Telegram、Slack、Discord、Feishu、WeChat、QQ 等大量渠道；VISION 明确说当前是 terminal-first，核心保持 lean，能力尽量走 plugin / ClawHub。
• Hermes Agent：仓库为 NousResearch/hermes-agent，MIT，主语言 Python。GitHub API 同一时间显示约 154.0k stars、24.6k forks、11740 open issues。官方 README 和文档强调 self-improving、skills、persistent memory、multi-platform gateway、provider-agnostic、profiles、cron、webhooks、MCP、Kanban、多 agent 调度。

产品逻辑：OpenHuman 是“先同步你的生活”，OpenClaw / Hermes 是“先给智能体行动能力”

OpenHuman 的核心产品假设很直接：大多数智能体不好用，是因为它们从第一天起就不了解你。解决方案不是让用户一点点告诉 AI，而是连接账户，定期同步，再把数据压缩成可检索、可浏览、可摘要的本地知识结构。它的文档把 Memory Tree 描述为从 source adapter 到 canonical Markdown、≤3k-token chunks、SQLite、summary tree、retrieval 的流水线；同一批内容还会落到 Obsidian 兼容的 wiki 目录里。

OpenClaw 的假设不同。它更像一个多平台个人助手骨架：你可以从 Telegram、Feishu、WeChat、Slack 等渠道喊它，让它跑任务、调用工具、接入插件。它的 VISION 里反复强调插件边界、安全默认值、terminal-first setup、ClawHub、MCP，以及“core stays lean”。这不是“先把所有个人资料吸进来”的路线，而是“把一个可以做事的助手接到你的渠道和设备上”。

Hermes Agent 的出发点又不同。它把重点放在智能体自身的长期进化：遇到复杂任务后沉淀 skills，跨 session 记住用户偏好和环境事实，能在 Telegram、Feishu、Discord、Slack 等消息平台里使用同一套工具；还支持 cron、webhook、profiles、provider 切换和子 agent。它不是主要靠 20 分钟全量拉取来建立人格，而是通过任务、工具调用、技能和记忆逐步积累“怎样替这个用户把事情做完”。

逻辑差异：OpenHuman 的大赌注是自动摄入

OpenHuman 最鲜明，也最有争议的设计，是 auto-fetch。官方文档写得很清楚：一个全局 scheduler 每 20 分钟 tick 一次，遍历每个 active connection，检查 per-connection 的 sync_state、last sync、daily budget、dedup set、cursor，然后调用 provider.sync。文档还解释过，原设计是 60 秒，后来改成 20 分钟，是为了减少 laptop 上持续 HTTP fetch 和 DB write 的负担。

这说明你观察到的风险并不是误读。OpenHuman 确实把“主动拉取并沉淀上下文”作为产品主路径。项目自己也意识到增长问题，所以设计了几道闸：

• 每个 connection 有自己的 cursor、dedup set、daily budget；
• Memory Tree 的 chunk ID 是内容确定性的，重复 ingest 相同输入不应产生重复 chunk；
• chunk 会经历 pending_extraction、admitted、buffered、sealed、dropped 等生命周期；
• TokenJuice 会在工具输出进入模型前做规则压缩；
• provider_surfaces 的临时 respond queue 代码里有 500 条 in-memory soft cap。

但这些闸并不等于没有成本。20 分钟一轮带来的本地存储、SQLite 索引、Markdown vault 文件、摘要树、embedding / summarization 成本，会随着连接数、邮件量、Slack/Discord/GitHub 活跃度一起增长。daily budget 和 dedup 能控制请求与重复写入；TokenJuice 能降低上下文 token；但如果用户把高流量数据源长期打开，系统仍然必须有 retention、冷热分层、过期策略、源级限额、摘要替代原文、可视化审计等机制，才能防止“本地越来越肥”。

记忆对比：三者不是同一种 memory

OpenHuman：资料库式记忆

OpenHuman 的 memory 更像一个可读、可搜索、可摘要的个人资料库。它把邮件、聊天、文档、代码平台事件 canonicalize 成 Markdown，分块，入 SQLite，做 source tree、topic tree、global tree，并导出到 Obsidian-style vault。这种方式适合解决“AI 不知道我的历史资料”的问题，尤其适合 inbox、docs、Slack、GitHub、Notion 等已经存在的大量文本。

OpenClaw：插件槽式记忆

OpenClaw 在 VISION 中明确说 memory 是特殊 plugin slot，一次只能启用一个 memory plugin。结合你当前本地 OpenClaw + TencentDB Memory + QMD 的运维实践，它更像“可替换的记忆后端 + 多渠道执行入口”。它重视插件边界和运行时生效，不要求核心自己吞掉全部外部数据。

Hermes Agent：经验式记忆 + 技能沉淀

Hermes 的 memory 更偏“让 agent 以后少犯同样的错”。它保存用户偏好、环境事实、工具坑点；复杂任务完成后可以沉淀为 skill。也就是说，Hermes 记的不只是内容，还包括做事方法。对长期智能体运维来说，这种 memory 的价值不在于“我有多少 Gmail 历史”，而在于“下一次类似任务能否更快、更稳、更符合用户习惯”。

你的两个担忧：本地爆炸与 token 爆炸

第一，本地内容越来越多。 这个风险存在。OpenHuman 文档提供了 dedup、cursor、daily budget、chunk lifecycle、dropped 状态、summary trees 等缓解手段，但它的方向仍然是“多源持续摄入”。如果没有明确 retention policy，几年尺度上本地库会越来越大；即使有摘要树，原始 chunk、索引、frontmatter、Obsidian 文件和 embedding 元数据都可能累积。

第二，AI 上传 token 使用量越来越大。 也存在，但要分阶段看。OpenHuman 的 ingest hot path 文档称不跑 LLM，只做 canonicalize、chunk、fast-score、persist、enqueue；重活在后台 worker。TokenJuice 能在工具输出进模型前压缩，README 声称可显著降低成本。但摘要、embedding、实体抽取、topic routing、daily digest 仍然可能消耗模型资源。真正的问题不是“20 分钟一定很贵”，而是“高流量源 + 长期开启 + 摘要策略不受控”会把成本从一次性变成持续性。

能不能和 Hermes、OpenClaw、小龙虾结合？

可以，但最好不要把 OpenHuman 当成另一个“大脑”直接叠上去。更合理的结合方式有三种。

方向一：把 OpenHuman 当作本地资料摄入层

OpenHuman 负责连接 Gmail、Slack、Notion、GitHub、Drive 等，把内容整理成 SQLite + Markdown vault。OpenClaw / Hermes 只读它的摘要、搜索结果或经过裁剪的 Obsidian vault，而不是每次把全量资料塞进上下文。这条路的目标是：OpenHuman 负责“知道资料在哪里”，Hermes / OpenClaw 负责“执行任务”。

方向二：通过 agentmemory / TencentDB Memory 做桥

OpenHuman 已有可选 agentmemory backend 文档：设置 memory.backend = "agentmemory" 后，它可以把 Memory trait 调用代理到本地 agentmemory REST 服务。Hermes 和 OpenClaw 也都能围绕外部 memory provider / plugin 做集成。如果要与你当前的 OpenClaw + TencentDB Memory + QMD 体系结合，最稳的思路不是互相复制记忆，而是定义一个中间层：OpenHuman 输出“已筛选的摘要/实体/事项”，OpenClaw/Hermes 只存可操作、可长期保留的结构化记忆。

方向三：把 auto-fetch 变成可审计的事件源，而不是默认全吞

如果直接照搬 OpenHuman 的 20 分钟拉取，和你对上下文卫生、session 隔离、历史记忆保护的原则会有冲突。更适合的结合方式是：每个数据源必须有预算、保留期、重要性阈值、手动 pin、自动 forget、同步日志和可回滚策略。换句话说，OpenHuman 的“拉取器”可以用，OpenHuman 的“默认一直变大”不能不加治理地用。

如果方向不一致，结合后可能变成什么？

如果把三者强行揉在一起，最差情况是三个系统都在记忆、都在同步、都在摘要，最后得到三份相似但不一致的上下文。那会带来三个问题：存储重复、token 重复、判断冲突。

更好的方向，是把边界切清楚：

• OpenHuman 做个人数据摄入、文档化、源级检索和可视化记忆；
• OpenClaw / 小龙虾 做多渠道入口、插件运行、设备/平台动作执行；
• Hermes Agent 做长期工作流、skill 沉淀、跨平台任务执行和运维自动化；
• 共享 memory 层 只保存经过筛选的事实、偏好、项目状态和行动线索，不保存所有原始内容。

这样结合出来的产品方向会很清晰：不是“一个无限吸收个人数据的 AI”，而是“一个本地可审计的个人情报层 + 一个能做事的多渠道智能体 + 一个可进化的技能系统”。这比单纯扩大 memory 更接近长期可用的个人 AI 基础设施。

核心结论

• OpenHuman 的价值在于 day-one context：通过 OAuth、auto-fetch、Memory Tree 和 Obsidian vault，快速让 AI 拥有大量个人背景。
• OpenHuman 的风险也在同一处：持续摄入会天然制造存储、索引、摘要、embedding 和 token 成本，需要强治理。
• OpenClaw 更像插件化、多渠道、terminal-first 的个人助手运行环境；它不应该被迫承担全量资料库职责。
• Hermes 更像会积累经验和技能的 agent runtime；它的 memory 更适合存偏好、流程和稳定事实，而不是无边界吞入外部资料。
• 三者可以结合，但正确方式是分层：OpenHuman 摄入和整理，OpenClaw/Hermes 执行，memory 中间层负责筛选、压缩、去重、保留和审计。

参考资料

• tinyhumansai/openhuman GitHub 仓库
• OpenHuman GitBook 文档
• OpenHuman Auto-fetch 文档
• OpenHuman Memory Tree 文档
• OpenHuman TokenJuice 文档
• OpenHuman 官方网站
• OpenHuman Product Hunt 页面
• OpenClaw GitHub 仓库 与 VISION.md
• Hermes Agent GitHub 仓库 与 官方文档