从集成中自动获取

每隔二十分钟，OpenHuman 会遍历所有 सक्रिय 集成，并将新数据折叠进你的记忆树。无需提示，也不用你编写轮询循环。

大多数“AI 助手”都是被动的：你提问，它们思考，然后回答。OpenHuman 则相反。它会持续从你的技术栈中拉取内容，所以等你问“我昨晚收件箱里来了什么？”时，答案已经在记忆树.

工作原理

一个统一的周期调度器每二十分钟触发一次。每次触发时，它会遍历每个活跃的集成，查找匹配的原生提供方，并且如果自该连接上次同步以来已经过去足够时间，则调用 provider.sync(ctx, SyncReason::Periodic).

每 20 分钟
    |
    v
针对每个活跃连接（Gmail、Notion、GitHub，……）
    |
    +--> 检查 sync_state (toolkit, connection_id)
    |       - 上次同步时间戳
    |       - 每日预算
    |       - 去重集合
    |       - 游标
    |
    +--> 如果间隔已到 -> provider.sync()
            |
            +--> 成功后 -> record_sync_success(ts)

这里有几件事很重要：

一个全局触发，不是每个连接一个任务。 每个用户的连接数量很少；一个 20 分钟的统一触发就足够了，而且能让状态管理变得很简单。
状态按 (toolkit, connection_id). 每个连接都有自己的游标、自己的上次同步时间戳、自己的去重集合、自己的每日预算。重启后会从本地 KV 重新构建这些状态；漏掉一次周期同步也无妨，因为重启后的下一次触发会把它重新捞起。
原生同步与事件驱动路径共享。 当 webhook 或 on_connection_created 事件触发一次非周期同步时，它会写入相同的 sync_state，因此调度器不会重复触发。
错误会被记录并吞掉。 调度器绝不能在循环中 panic 跳出，否则在进程剩余生命周期内，周期同步都会静默停止。

哪些内容会进入记忆树

每个提供方都负责塑造自己的摄取流程。例如，Gmail 提供方会抓取一页新消息，运行邮件规范化器，并将结果通过同一个 摄取 手动 UI 所使用的路径；数据块会落入 SQLite，摘要桶会被填充，任何被触及的实体都会让主题树变脏。

其他提供方（GitHub、Slack、Notion，……）遵循相同的形态：从游标之后抓取新条目 → 规范化 → 摄取到记忆树.

为什么是 20 分钟一次触发

最初的设计是每 60 秒运行一次。随着接入多个提供方，这意味着持续不断地进行 HTTP 拉取和数据库写入，在笔记本上会明显占用资源。改成 20 分钟是用一点点陈旧度换来明显更低的前台负载。按提供方的 sync_interval_secs 仍然限制着最小实际同步之间的延迟；全局触发只会放宽上限。

调优与可见性

每个提供方的间隔。每个原生提供方都会声明自己的 sync_interval_secs，因此高流量工具包（Gmail）可以比低流量的（Stripe）同步得更频繁。
每日预算。每个连接都有每日请求预算，以保持 API 成本和速率限制在可控范围内。
日志。同步活动会以 debug 级别记录在核心日志中。

另请参阅

第三方集成。连接器层的自动抓取运行于……之上。
记忆树。所有内容最终都会落到这里。
智能 Token 压缩。这就是让“抓取一切”保持低成本的原因。

最后更新于 8天前