我把 Gmail、GitHub 和 Notion 接进 OpenHuman 后发生了什么？

2026 年 6 月 1 日 · Nuvcloud 技术博客 · 约 8 分钟阅读

OpenHuman 接入 Gmail、GitHub、Notion 后 Memory Tree 与 auto-fetch 数据流示意 — 三个最常见的「工作三角」数据源接入后，OpenHuman 的 Memory Tree 会在本机持续生长——关键不在聊天，而在后台那条 auto-fetch 流水线。

装完 OpenHuman 之后，我刻意没有一口气把 118 个集成全打开。官方文档（GitBook）里列了 Gmail、Notion、GitHub、Google Calendar、Slack……对独立开发者或小团队来说，真正构成「日常上下文」的往往是三个：邮件谈需求、Notion 写约束、GitHub 看交付。我就只接了这三样，然后观察 72 小时里本机到底发生了什么。

结论先说：OpenHuman 不是「把三个 Tab 合成一个聊天框」。接完 OAuth 之后，你会看到磁盘上的 Memory Tree（记忆树） 开始自己长——默认大约 20 分钟 一轮的 auto-fetch（见官方说明）把新邮件、页面更新、提交记录压成 Markdown，写进 SQLite 和类 Obsidian 的本地仓库。对话质量的变化是滞后且累积的：头几小时几乎无感，第二天起跨应用问题突然变准，第三天你开始意识到磁盘和噪音也是成本。

Beta 提示：项目仍标 Early Beta，连接器行为可能随版本变。本文基于 2026 年 5 月前后的公开 Release 行为撰写；生产使用前请锁定 GitHub Releases 版本号。

1. 为什么先接 Gmail、GitHub、Notion

这三个源覆盖了我 80% 的「可被 AI 引用的上下文」：

Gmail：客户改需求、deadline 口头确认、合同附件——往往只存在于邮件线程，Notion 里未必同步。
Notion：PRD、接口约定、会议纪要——结构化，但和代码库、邮件时间线脱节。
GitHub：谁 merge 了、CI 红没红、issue 里承诺了什么——交付真相，却和商务邮件不在同一界面。

ChatGPT 或 Copilot 可以单次粘贴其中一段，但无法持续对齐三处变更。OpenHuman 的卖点正是把这三条管道接到同一套本机记忆库。若你还没装，仓库在 tinyhumansai/openhuman；若已在考虑常在线部署，可先读姊妹篇 OpenHuman 养在云端 Mac 上。

2. 接入当天：OAuth 之后的第一轮 fetch

三个集成的 OAuth 都是浏览器跳转，整体比自建 API Key 省心。实际顺序我建议：

先 Gmail——授权范围务必克制，不要勾选「同步全部历史邮件」；选最近 30 天或「仅重要标签」即可，否则首轮索引会拖很久。
再 Notion——只勾选工作区里真正在用的几个 database / 页面，Marketing 归档页别选。
最后 GitHub——按 org / repo 粒度授权，个人 pet 项目可以先不接。

点完最后一个「允许」之后，界面不会立刻变得多聪明。后台会先跑一轮全量拉取：Gmail 线程被拆成摘要块，Notion 页面转成 Markdown 节点，GitHub 的 commit、PR、issue 活动写入对应分支。CPU 和磁盘 I/O 会明显跳一下——在 Activity Monitor 里能看到 OpenHuman 进程持续读写。

第一轮结束后，打开 Memory Tree（或 Obsidian 风格 wiki 目录，见文档），你会看到类似这样的顶层结构——名称因版本略有差异，但逻辑一致：

记忆库目录示意（接完三集成后）

memory/
├── gmail/
│   ├── threads/          # 按线程压缩的邮件摘要
│   └── contacts/         # 发件人 ↔ 项目映射（若有）
├── notion/
│   ├── pages/            # 页面 Markdown 镜像
│   └── databases/        # 数据库行快照
└── github/
    ├── repos/            # 按仓库分目录
    ├── commits/
    ├── pull-requests/
    └── issues/

此时若立刻问「总结我上周的工作」，回答往往泛而空——模型还没建立跨源关联，只是各自有一堆文本。别失望，这是正常现象。

3. 三个源各自「落库」时长什么样

数据源	auto-fetch 主要拉什么	Memory Tree 里长什么样	常见噪音
Gmail	新邮件、线程回复、标签变更	按 thread 的 Markdown 摘要，保留发件人、时间、主题、正文要点	Newsletter、GitHub 通知邮件与真人邮件混在一起
Notion	页面编辑、database 行增删改	页面级 .md 文件，database 常展平为表格块	模板页、空页面、已归档文档仍被索引
GitHub	push、PR review、issue comment、release	按 repo 分目录；commit 带 hash、message、作者	dependabot、lint bot、fork 同步产生大量低价值 commit

官方会把 HTML 邮件、Notion 块、GitHub API JSON 都压成 Markdown再入库——这是 Memory Tree 可读、可 diff、可全文检索的前提。你在 Finder 里直接打开某个 .md，能看到比聊天窗口里更「原始」的摘录；这也方便你判断：是模型理解错了，还是 fetch 进来的摘要本身就有偏差。

4. 第二天起：跨应用问题突然能问了

大约经过 4–6 轮 auto-fetch（即 roughly overnight），我开始问一些以前必须手动复制粘贴才能答的问题。下面几类确实变准了（项目名已 anonymize）：

「客户 A 在邮件里把上线日从 6/15 改到 6/22，Notion PRD 和 GitHub milestone 对齐了吗？」——分身能引用邮件线程日期 + Notion 页面版本 + GitHub milestone 标题，给出不一致清单。
「这周我在 repo X 上 merge 了哪些 PR，有没有和邮件里承诺的 scope 对不上？」——GitHub 活动与 Gmail 关键词能交叉，但依赖邮件里是否出现 repo 名或 PR 号。
「Notion 会议纪要说接口要加 rate limit，代码里 merge 了吗？」——若纪要写进 Notion 且 GitHub 有对应 PR description，命中率较高。

注意这些回答的共同点：都是「对齐与差异检测」，不是替你写代码或发邮件。OpenHuman 在这个阶段更像一个读过你三个 inbox 的实习生，而不是全自动 agent。若你期待它自动改 Notion、在 GitHub 开 PR，那是 OpenClaw 的执行面该干的事——记忆聚合与动作执行要分开想。

5. 没预料到的三件事

5.1 磁盘长得比聊天体验快

三个集成跑满 48 小时后，我本机记忆库从不足 200MB 涨到约 1.2GB（个人用量，含 3 年 Gmail 若全量会夸张得多）。GitHub monorepo 的 commit 历史和 Notion 大 database 是主因。建议从第一天就：

用 du -sh ~/…/memory 建 baseline，每天看一眼增速；
Notion 侧关掉不再维护的 workspace 授权；
GitHub 只接 active repo，archived 项目断开。

5.2 噪音会污染「上周工作总结」

Gmail 里的 GitHub 通知、Notion 里的空模板页、dependabot commit——都会进 Memory Tree。问「总结我上周工作」时，分身可能把 bot 活动也算进去。缓解办法：Gmail 侧用标签过滤只同步「Important / 客户」；GitHub 用 org 级忽略 archived repo；问话时加约束，例如「只统计带 feat: 或客户名的 commit」。

5.3 笔记本合盖 = 记忆停摆

我把 OpenHuman 跑在 MacBook 上时，周三下午合盖去开会，再打开已是两小时后——auto-fetch 日志里明显缺了一截，周四早上问「昨晚客户有没有回信」就答不准。这不是 bug，是主机睡眠导致定时任务暂停。若三集成是你工作流核心，要么改「合盖不休眠 + 插电」，要么把分身迁到常在线机器——后文会回到这点。

6. 一周后我的用法变了什么

稳定跑满 7 天后，行为模式从「偶尔问 OpenHuman」变成固定三个 ritual：

晨间 5 分钟：「过去 24 小时客户邮件 + 阻塞 PR + Notion 里标 urgent 的条目」——替代手动刷三个 app。
写回复前：「根据 thread X 和 Notion 接口页，起草一封确认 scope 的邮件」——仍要人工发送，但草稿质量可用。
周五复盘：「本周三处源里关于项目 Y 的不一致」——比单开 Excel 对账快，但我会 spot-check 引用的 md 文件。

我没有把 Calendar、Slack 接进来——不是不需要，而是想先证明「三集成闭环」值得维护成本。对你而言，若会议密度高，第四个接 Calendar 往往比接 Slack ROI 更高；Slack 线程噪音比 Gmail 还大。

7. 若你正要接：四条实操建议

分批授权，每接一个新源观察 24 小时磁盘与 CPU，别一次全开。
Memory Tree 当真相源——模型说错了，先打开对应 .md 看是 fetch 摘要问题还是推理问题。
模型路由单独想——记忆在本机，但若对话走云端 API，敏感邮件摘要仍会出网；公司邮箱走 DLP 的别接个人分身。
备份 SQLite + Markdown——这台机器上的库等于你的职业副本，Time Machine 或定期 rsync 到加密盘。

快速体检（接完 48 小时后跑一次）

du -sh ~/Library/Application\ Support/OpenHuman/memory 2>/dev/null \
     || du -sh ~/Documents/OpenHuman/memory 2>/dev/null
# 路径因安装方式而异；看 memory 总体积与 gmail/github/notion 子目录占比
find . -name "*.md" -mtime -1 | wc -l   # 近 24h 新增 md 数量

8. FAQ

Q1：只接这三个够吗？
对很多知识工作者够用来验证价值。接满 10+ 源之前，先优化噪音和磁盘，否则 Memory Tree 会臃肿到检索变慢。

Q2：和 Gmail 内置 Gemini 或 Notion AI 重复吗？
不重复。那些是单应用内问答；OpenHuman 的价值是跨源持久索引，且数据默认落在本机库。

Q3：GitHub 私有库安全吗？
OAuth token 存在本机；风险在于整库备份泄露。用 FileVault、独立用户、别把记忆库同步到公有云盘。

Q4：72 小时够判断要不要继续用吗？
够。若跨应用问题仍经常 hallucinate 且你不愿维护 Memory Tree hygiene，可能不如维持现状；若晨间 ritual 已节省时间，值得考虑常在线部署。

Q5：一定要云端 Mac 吗？
不必。但若合盖断 sync 已经影响你两次以上，见下一节。