OpenHuman 第三方集成全解析118 OAuth 连接器、Triggers 事件管线与 MCP/Skills 生态【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhumanOpenHuman 以「本地优先local-first」的方式提供对 118 第三方服务的接入能力无需手填任何 API Key在应用内完成一次 OAuth 授权即可把 Gmail、Notion、GitHub、Slack、Stripe 等服务变成 Agent 的工具、记忆源、画像信号与实时触发源。本文基于 gitbooks/features/integrations/README.md 及其关联文档深入讲解连接器层Composio的托管模式与直连模式、四种落地形态、Triggers 实时事件管线与 triage 分类机制、MCP/Skills 开放生态以及贯穿始终的隐私边界并结合仓库源码给出可验证的实现依据。连接器层Composio 与两种路由模式OpenHuman 的第三方集成由连接器层Composio驱动参见 gitbooks/features/integrations/README.md。整条链路由 Rust 核心实现代码集中在src/openhuman/integrations/composio/目录模块级说明见 src/openhuman/integrations/composio/README.md。托管模式backend默认在默认的托管模式下OpenHuman 后端持有 Composio API Key负责 OAuth token 代理、速率限制与 trigger webhook 分发Rust 核心从不直接调用第三方 API而是通过后端代理api.tinyhumans.ai/agent-integrations/composio/*完成 toolkit 列表、连接、授权、工具执行与 trigger 订阅。该模式在源码中被描述为COMPOSIO_MODE_BACKEND见 src/openhuman/config/schema/tools/integrations.rs。直连模式direct / BYO Key若你希望完全自持数据主权可以切换到直连模式核心将使用你自己的 Composio API Key直接请求backend.composio.dev的 v2/v3 API底层客户端见src/openhuman/integrations/composio/tools/direct.rs同步的工具调用synchronous tool calls完全可用但实时 trigger webhook 无法开箱即用——由于异步推送面由后端通过 socket.io 中介直连模式下你必须自行在 Composio 控制台配置 webhook 端点与转发设施。模式与密钥管理通过 RPC 暴露composio.get_mode/composio.set_api_key/composio.clear_api_key实现在 src/openhuman/integrations/composio/ops/direct_mode.rs。值得注意的实现细节直连模式的 API Key不写入 TOML 配置而是通过加密 keychaincrate::openhuman::security::credentials的composio-direct槽位保存模式本身才持久化在配置中见 src/openhuman/config/schema/tools/integrations.rs。ComposioConfig还提供了triage_disabled全局关闭 trigger 分类与triage_disabled_toolkits按 toolkit 逐个关闭例如[gmail, slack]两个开关。RPC 面连接全生命周期Composio 域以openhuman.composio_*命名空间暴露整套 JSON-RPC 方法清单见 src/openhuman/integrations/composio/README.md方法用途composio.list_toolkits/composio.list_capabilities查看后端放行的 toolkit 与本地能力矩阵composio.list_connections/composio.authorize列出连接、发起 OAuth 并返回connectUrlconnectionIdcomposio.delete_connection删除连接可选按源清理记忆composio.list_tools/composio.execute获取 OpenAI function-calling 工具 schema、执行某个 actioncomposio.create_trigger/enable_trigger/disable_trigger/list_triggers/list_trigger_historytrigger 全生命周期管理composio.get_user_profile/refresh_all_identities/sync身份归一化、刷新与后台同步composio.get_user_scopes/set_user_scopes按 toolkit 设置读/写/管理权限偏好composio.get_mode/set_api_key/clear_api_key路由模式与直连密钥管理一次 OAuth四种落地形态一旦某个服务连接成功它会同时出现在四个位置Agent 工具模型可以直接调用该服务的能力记忆源由 auto-fetch 机制 每 20 分钟拉取汇入 Memory Tree画像信号跨服务的活动数据持续喂养个人化personalization触发源实时事件新邮件、新扣款、新私信流入 Triggers 管线可自动触发 Agent 动作。Native vs proxied两种能力形态并非所有服务都以相同方式落地原生提供方native providers存在专门的 Rust 模块能直接把服务数据摄入 Memory Tree典型如 Gmail 的原生摄入路径。原生 provider 的实现与同步状态机位于src/openhuman/memory/sync/composio/providers 与 bus 订阅者、periodic 周期同步的代码即在此处src/openhuman/integrations/composio/下仅保留兼容性转发 shim仅代理工具proxied toolsAgent 可以调用但还没有自动摄入管线。新原生提供方会随功能迭代逐步加入。连接状态与撤销每个集成在界面上显示三种状态Not connected尚未配置Connected已激活并进入同步Manage已激活可重新配置或断开。任何时刻都可以从Connections页面撤销某个连接。源码侧连接生命周期事件ComposioConnectionCreated/ComposioConnectionDeleted/ComposioConfigChanged会发布到进程内事件总线见 src/openhuman/integrations/composio/README.md 的 Events 一节composio_authorize还会通过ComposioConnectionCreatedSubscriber主动预热集成缓存。目录抽样118 服务覆盖哪些领域原文档给出的非穷举目录详见 gitbooks/features/integrations/README.md类别示例Email calendarGmail、Outlook、Google Calendar、Apple CalendarDocs storageGoogle Docs、Google Drive、Notion、Dropbox、AirtableCode devGitHub、Linear、Jira、FigmaCommsSlack、Discord、Microsoft Teams、Telegram、WhatsAppCRM salesSalesforce、HubSpotCommerce paymentsStripe、ShopifyProject managementAsana、TrelloSocialTwitter / X、Spotify、YouTube注意这些数字与具体目录以当前仓库与后端实时状态为准属于持续扩展的开放生态而非固定清单。消息通道Messaging Channels不只是读取目录中有三个集成是特殊的——OpenHuman 用它们向你回话而不仅是读取Telegram主消息通道双向通信。可收发消息、管理会话、搜索历史、创建群组支持 80 种替你执行的动作所有动作都运行在你自己的加密凭据之下Discord收发消息连接账户后可在 Discord 里接收 OpenHuman 消息Web桌面应用内置的浏览器聊天界面消息完全留在本地。在Connections → Channels中设置默认通道活动路由状态会显示当前正在使用的通道。Telegram 提供两种凭据模式通过 OpenHuman 一键连接加密托管或提供你自己的凭据以获得最大控制权。消息通道的轮询侧Auto-fetch 每 20 分钟同步「收到请求才回答」的被动助手模型之外OpenHuman 会持续主动拉取你的服务栈让「我邮箱里昨晚到了什么」这类问题的答案提前躺在 Memory Tree 里详见 gitbooks/features/obsidian-wiki/auto-fetch.md。一个全局调度器每 20 分钟 tick 一次遍历每个活动连接 → 查找对应的原生 provider → 检查该连接是否到了同步间隔 → 调用provider.sync(ctx, SyncReason::Periodic)。关键设计点单一全局 tick而非每个连接一个任务——连接数量少单 tick 记账更简单状态按(toolkit, connection_id)隔离每个连接拥有自己的 cursor、上次同步时间戳、去重集合与每日预算重启后从本地 KV 重建漏掉一次周期性同步是无害的重启后的下一次 tick 会补上原生同步与事件驱动路径共享当 webhook 或on_connection_created触发非周期同步时会写入同一份 sync_state避免调度器重复触发错误只记录不抛出调度器绝不能 panic 出循环否则周期同步会静默停止。为什么是 20 分钟最初设计为 60 秒多个 provider 连接时会造成持续的 HTTP 拉取与数据库写入笔记本上可见地繁忙。20 分钟用少量延迟换取了显著更低的前台负载。每个 provider 的sync_interval_secs仍约束实际同步之间的最小间隔高流量的 Gmail 可以比低流量的 Stripe 同步更频繁全局 tick 只放宽上限此外每个连接还有每日请求预算以控制 API 成本与限流。Triggers实时事件管线连接一个集成不只是给 Agent 一个「按需读取」的地方它同时是一个实时事件源有人给你发邮件、编辑 Notion 页面、在你的仓库上开 issue、在 Stripe 上扣款、或在 Slack 私信你OpenHuman 都会近实时地收到事件并决定要不要做点什么完整说明见 gitbooks/features/integrations/triggers.md。典型触发事件集成示例触发事件GmailGMAIL_NEW_GMAIL_MESSAGE收件箱新邮件SlackSLACK_NEW_MESSAGE被提及的频道/私信消息NotionNOTION_PAGE_UPDATED被跟踪页面发生变化GitHubGITHUB_ISSUE_OPENED、GITHUB_PULL_REQUEST_OPENEDStripeSTRIPE_CHARGE_SUCCEEDED账户发生成功扣款CalendarGOOGLE_CALENDAR_EVENT_CREATED日历新增事件连接激活后相关的 trigger 订阅会自动接通。对 Gmail 有一个特殊前提trigger 订阅要求对 Google 账户具备 message-read 权限新版授权会请求https://www.googleapis.com/auth/gmail.readonly以启用GMAIL_NEW_GMAIL_MESSAGE并让原生 Gmail 同步路径读取新消息元数据。如果旧连接是在该 scope 加入之前创建的需先在 Settings 中重新连接 Gmail再启用 Gmail triggers。端到端数据流┌────────────────────┐ │ third-party API │ Gmail / Slack / Notion / GitHub / ... └─────────┬──────────┘ │ webhook ▼ ┌────────────────────┐ │ OpenHuman backend │ HMAC 校验 webhook、归一化 payload └─────────┬──────────┘ │ Socket.IO event (composio:trigger) ▼ ┌────────────────────┐ │ Rust core (本机) │ 在进程内事件总线发布 DomainEvent::ComposioTriggerReceived └─────────┬──────────┘ │ ▼ ┌────────────────────┐ │ Trigger Triage │ 分类drop / acknowledge / react / escalate └─────────┬──────────┘ │ ▼ ┌────────────────────┐ │ 四种结果之一 │ │ - 无动作 │ ← drop │ - 记忆笔记 │ ← acknowledge │ - Trigger Reactor │ ← react1-2 次工具调用 │ - Orchestrator │ ← escalate完整多步规划 └────────────────────┘webhook永远不会以原始形态到达你的机器。后端持有 OAuth token 并直接从第三方接收 webhook完成 HMAC 校验、payload 归一化后通过既有认证 socket 转发到你的 Rust 核心。本机看到的只是事件总线上一个干净、已校验的ComposioTriggerReceived事件。源码侧该链路有明确对应后端在 socket 上发出composio:trigger后由 src/openhuman/platform/socket/event_handlers.rs 解析并发布DomainEvent::ComposioTriggerReceived总线订阅者ComposioTriggerSubscriber归档事件并驱动记忆摄入订阅者注册代码见 src/openhuman/memory/sync/composio/bus_part_01.rs同一文件还定义了 OAuth 连接就绪的轮询超时与退避参数。Triage每个触发事件先过一遍分类器任何动作执行之前每个 trigger 都必须经过trigger_triageAgentagent 定义见 src/openhuman/agent/registry/agents/trigger_triage/agent.toml——它的唯一职责是决定系统接下来做什么。它只会选择四种动作之一动作发生什么适用场景drop什么都不做静默记录后丢弃垃圾、重复、无关噪声默认处理不关心的事物acknowledge持久化一条简短记忆笔记不运行 Agent值得记住的被动通知如「archive 里新建了一个页面」reacttrigger_reactorAgent 运行 1-2 次工具调用小型单步副作用存一条记忆、发一个快速确认、把线程标记为已读escalate完整orchestratorAgent 接管具备规划能力需要推理、多步骤或多技能的事起草回复、更新多个 Notion 页面、判断如何 triage 一个入站 issuetriage Agent 拥有与主 Agent 相同的记忆与工作区上下文因此能判断触发事件是否与你当前工作相关、涉及哪些人、以及是否属于你以前要求过 OpenHuman 处理的那类事。决策契约与宽容解析分类器的输出是一个结构化 JSON 决策契约定义在 src/openhuman/agent/triage/decision.rs{ action: drop|acknowledge|react|escalate, target_agent: trigger_reactor|orchestrator|null, prompt: task for the target agent, or null, reason: one-sentence justification }由于 triage 允许运行在gemma3:1b-it-qat这类 1B 级本地小模型上其输出经常带有 json 围栏、内嵌 JSON、尾逗号、甚至action: Drop大小写错误因此解析器parse_triage_decision对这些形态刻意宽容解析失败时调用方会在远端 provider 上重试整轮。从trigger_triage/agent.toml可以看到分类器刻意保持扁平named []零工具、sandbox_mode read_only、temperature 0.2、max_iterations 2并且保留 profile 与 MEMORY.md同一封入站邮件对不同用户画像可能是紧急或噪声因为模型不可靠的嵌套工具调用会破坏分类质量。而react路径的trigger_reactor见 src/openhuman/agent/registry/agents/trigger_reactor/agent.toml则是一个窄面专家工具面只有memory_store、read_workspace_state、spawn_subagent三个sandbox_mode none写路径模型 hint 固定为远端agentic档——反应性动作需要可靠的工具调用1B 级本地模型不满足。它保留 PROFILE.md让替用户发出的小消息带上用户的名字、角色与语气与 MEMORY.md让跟进内容与既有上下文连贯。为什么要 Triage 一步跳过分类器、把所有 trigger 直接灌进 orchestrator 是个坏主意原因有二大多数 trigger 是噪声一个已连接的 Gmail 账户每小时会触发几十个事件绝大多数用户并不关心每个都跑 orchestrator 会烧掉预算并制造持续的后台活动流不同 trigger 应有不同的成本上限一张自动化 Stripe 收据和一条私人 Slack 私信不该花相同的 token 来处理。Triage 让廉价路径保持廉价把 orchestrator 留给真正值得的事件。Triage 运行在快速模型档位参见 Automatic Model Routing因此分类本身是亚秒级的。配置、审计与退出开关默认开启集成一旦连接其 trigger 自动进入管线退出开关triage 路径受OPENHUMAN_TRIGGER_TRIAGE_DISABLED环境变量门控常量定义在 src/openhuman/memory/sync/composio/bus_part_01.rs设为1/true/yes会关闭 Agent 分类、退化为仅被动记录——集成本身保持连接只是抑制了自动动作按 trigger 设置在Settings中管理评估哪些集成与事件类型底层 RPC 为update_composio_trigger_settings/get_composio_trigger_settings审计日志每个 trigger 无论结论如何都会写入 trigger 历史持久化实现见 src/openhuman/integrations/composio/trigger_history.rs按 UTC 日分区为workspace/state/triggers/YYYY-MM-DD.jsonl的 JSONL 归档你可以看到什么到了、分类器判断了什么、最终跑了什么。决策与升级还会作为TriggerEvaluated/TriggerEscalated事件发布到进程内总线核心内任何组件都可订阅。精选目录之外MCP 服务器与 Skills 目录118 个 OAuth 连接器是精选路径在这之外 OpenHuman 还开放了更广的开源工具生态详见 gitbooks/features/integrations/mcp-and-skills.md。MCP数千台服务器可反向暴露自身内置MCP registry并行扇出到两个上游注册中心Smithery 与官方registry.modelcontextprotocol.io并合并结果可浏览数千台服务器搜索 → 安装 → 连接本地安装以 stdio 子进程方式拉起服务器已部署的服务器走 HTTP 连接受监督的连接已安装服务器持久化在本地 SQLitemcp_clients/mcp_clients.db见 src/openhuman/mcp/registry/README.md记录 command、args 与 transport。一个监督循环每 ~60s 探测一次启用的服务器采用逐服务器指数退避后台重连循环实现见 src/openhuman/mcp/registry/mod.rs可观测性每次非正常探测结果响应慢、transport 断开、重连成功或失败都会出现在Settings → Developer → Event Log的mcp徽标下——健康的服务器保持安静持续宕机、失败后恢复、或因 launcher 运行时缺失而无法启动的服务器会触发通知工具即插即用连接后MCP 服务器的工具与原生工具一样直接对 Agent 可用。反过来OpenHuman 也可以把自己暴露为 MCP 服务器openhuman-core mcp通过 stdio 提供只读工具记忆搜索/召回、Memory Tree 浏览、可选 web 搜索给 Claude Desktop 等客户端配置见 MCP Server。Skills约 9 万条目的元数据目录Skills是聚合多个上游来源HermesHub、ClawHub、LobeHub 等的 Agent 技能目录SKILL.md能力包单一聚合目录来源可经OPENHUMAN_SKILL_REGISTRY_CATALOG_URL配置规模约9 万条目每条含 id、名称、描述、来源、作者、版本、标签、平台、下载 URL 与许可证缓存与速度目录在启动时后台拉取不阻塞启动本地缓存于~/.openhuman/skill-registry/cache.json约 1 小时 TTL采用 stale-while-revalidatesingle-flight 门控防止大目录被重复下载元数据优先旧版应用内 skills 运行时QuickJS 沙箱已移除Skills 现在是你在Connections → Skills标签页浏览与安装的元数据目录而不是在应用内执行的代码不同条目的可用性各异——有的直接提供SKILL.md下载有的指向外部托管。原生语音与原生工具还有两个能力是原生内置而非集成因为它们是桌面体验的承重墙Voice语音转文字STT进、文字转语音TTS出外加一个实时 Google Meet Agent——加入会议、转录进 Memory Tree、还能在通话中说话详见 VoiceNative tools内置 web 搜索、web-fetch 抓取器以及完整的文件系统/git/lint/test/grep 编码工具集Agent 开箱即用详见 Native Tools。隐私边界凭据永不落在本机明文OpenHuman 的核心从不直接调用任何第三方 API。所有请求都经过 OpenHuman 后端由后端处理 OAuth token 与速率限制你的 token 从不以明文躺在机器磁盘上Agent 只看到工具调用的结果而看不到凭据完整边界见 Privacy Security。如果选择直连 Composio 模式边界随之改变本地核心使用你自己的 Composio API Key你需要自行负责 Composio 账户、速率限制、计费关系以及 trigger 投递所需的任何 webhook 端点。Triggers 管线同样遵循该边界第三方 token 在后端、webhook 由后端 HMAC 校验后才到达本机、分类与反应动作跑在本地核心与本地 Memory Tree 上、acknowledge/react/escalate写入的记忆笔记存储在本地 SQLite memory tree 与 Markdown vault与其他来源无异。开发者实现索引对想深入源码的读者原文档给出了如下实现指针均已在本仓库确认存在Triage Agentsrc/openhuman/agent/registry/agents/trigger_triage/agent.tomlprompt.mdReactor Agentsrc/openhuman/agent/registry/agents/trigger_reactor/决策契约与宽容解析器src/openhuman/agent/triage/decision.rsComposio 总线订阅者src/openhuman/memory/sync/composio/bus.rs与bus_part_01.rsComposioTriggerSubscriberTrigger 历史持久化src/openhuman/integrations/composio/trigger_history.rs领域事件DomainEvent::ComposioTriggerReceived/TriggerEvaluated/TriggerEscalatedTrigger 设置 RPCupdate_composio_trigger_settings/get_composio_trigger_settingsComposio 模块总览RPC 表、Agent 工具、事件、持久化、依赖src/openhuman/integrations/composio/README.md相关文档链路Auto-fetch 的轮询侧见 Auto-fetch from Integrations所有数据终点的 Memory Tree以及使用 trigger 上下文与记忆做前瞻规划的 Subconscious Loop。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenHuman 第三方集成全解析：118+ OAuth 连接器、Triggers 事件管线与 MCP/Skills 生态
OpenHuman 第三方集成全解析118 OAuth 连接器、Triggers 事件管线与 MCP/Skills 生态【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhumanOpenHuman 以「本地优先local-first」的方式提供对 118 第三方服务的接入能力无需手填任何 API Key在应用内完成一次 OAuth 授权即可把 Gmail、Notion、GitHub、Slack、Stripe 等服务变成 Agent 的工具、记忆源、画像信号与实时触发源。本文基于 gitbooks/features/integrations/README.md 及其关联文档深入讲解连接器层Composio的托管模式与直连模式、四种落地形态、Triggers 实时事件管线与 triage 分类机制、MCP/Skills 开放生态以及贯穿始终的隐私边界并结合仓库源码给出可验证的实现依据。连接器层Composio 与两种路由模式OpenHuman 的第三方集成由连接器层Composio驱动参见 gitbooks/features/integrations/README.md。整条链路由 Rust 核心实现代码集中在src/openhuman/integrations/composio/目录模块级说明见 src/openhuman/integrations/composio/README.md。托管模式backend默认在默认的托管模式下OpenHuman 后端持有 Composio API Key负责 OAuth token 代理、速率限制与 trigger webhook 分发Rust 核心从不直接调用第三方 API而是通过后端代理api.tinyhumans.ai/agent-integrations/composio/*完成 toolkit 列表、连接、授权、工具执行与 trigger 订阅。该模式在源码中被描述为COMPOSIO_MODE_BACKEND见 src/openhuman/config/schema/tools/integrations.rs。直连模式direct / BYO Key若你希望完全自持数据主权可以切换到直连模式核心将使用你自己的 Composio API Key直接请求backend.composio.dev的 v2/v3 API底层客户端见src/openhuman/integrations/composio/tools/direct.rs同步的工具调用synchronous tool calls完全可用但实时 trigger webhook 无法开箱即用——由于异步推送面由后端通过 socket.io 中介直连模式下你必须自行在 Composio 控制台配置 webhook 端点与转发设施。模式与密钥管理通过 RPC 暴露composio.get_mode/composio.set_api_key/composio.clear_api_key实现在 src/openhuman/integrations/composio/ops/direct_mode.rs。值得注意的实现细节直连模式的 API Key不写入 TOML 配置而是通过加密 keychaincrate::openhuman::security::credentials的composio-direct槽位保存模式本身才持久化在配置中见 src/openhuman/config/schema/tools/integrations.rs。ComposioConfig还提供了triage_disabled全局关闭 trigger 分类与triage_disabled_toolkits按 toolkit 逐个关闭例如[gmail, slack]两个开关。RPC 面连接全生命周期Composio 域以openhuman.composio_*命名空间暴露整套 JSON-RPC 方法清单见 src/openhuman/integrations/composio/README.md方法用途composio.list_toolkits/composio.list_capabilities查看后端放行的 toolkit 与本地能力矩阵composio.list_connections/composio.authorize列出连接、发起 OAuth 并返回connectUrlconnectionIdcomposio.delete_connection删除连接可选按源清理记忆composio.list_tools/composio.execute获取 OpenAI function-calling 工具 schema、执行某个 actioncomposio.create_trigger/enable_trigger/disable_trigger/list_triggers/list_trigger_historytrigger 全生命周期管理composio.get_user_profile/refresh_all_identities/sync身份归一化、刷新与后台同步composio.get_user_scopes/set_user_scopes按 toolkit 设置读/写/管理权限偏好composio.get_mode/set_api_key/clear_api_key路由模式与直连密钥管理一次 OAuth四种落地形态一旦某个服务连接成功它会同时出现在四个位置Agent 工具模型可以直接调用该服务的能力记忆源由 auto-fetch 机制 每 20 分钟拉取汇入 Memory Tree画像信号跨服务的活动数据持续喂养个人化personalization触发源实时事件新邮件、新扣款、新私信流入 Triggers 管线可自动触发 Agent 动作。Native vs proxied两种能力形态并非所有服务都以相同方式落地原生提供方native providers存在专门的 Rust 模块能直接把服务数据摄入 Memory Tree典型如 Gmail 的原生摄入路径。原生 provider 的实现与同步状态机位于src/openhuman/memory/sync/composio/providers 与 bus 订阅者、periodic 周期同步的代码即在此处src/openhuman/integrations/composio/下仅保留兼容性转发 shim仅代理工具proxied toolsAgent 可以调用但还没有自动摄入管线。新原生提供方会随功能迭代逐步加入。连接状态与撤销每个集成在界面上显示三种状态Not connected尚未配置Connected已激活并进入同步Manage已激活可重新配置或断开。任何时刻都可以从Connections页面撤销某个连接。源码侧连接生命周期事件ComposioConnectionCreated/ComposioConnectionDeleted/ComposioConfigChanged会发布到进程内事件总线见 src/openhuman/integrations/composio/README.md 的 Events 一节composio_authorize还会通过ComposioConnectionCreatedSubscriber主动预热集成缓存。目录抽样118 服务覆盖哪些领域原文档给出的非穷举目录详见 gitbooks/features/integrations/README.md类别示例Email calendarGmail、Outlook、Google Calendar、Apple CalendarDocs storageGoogle Docs、Google Drive、Notion、Dropbox、AirtableCode devGitHub、Linear、Jira、FigmaCommsSlack、Discord、Microsoft Teams、Telegram、WhatsAppCRM salesSalesforce、HubSpotCommerce paymentsStripe、ShopifyProject managementAsana、TrelloSocialTwitter / X、Spotify、YouTube注意这些数字与具体目录以当前仓库与后端实时状态为准属于持续扩展的开放生态而非固定清单。消息通道Messaging Channels不只是读取目录中有三个集成是特殊的——OpenHuman 用它们向你回话而不仅是读取Telegram主消息通道双向通信。可收发消息、管理会话、搜索历史、创建群组支持 80 种替你执行的动作所有动作都运行在你自己的加密凭据之下Discord收发消息连接账户后可在 Discord 里接收 OpenHuman 消息Web桌面应用内置的浏览器聊天界面消息完全留在本地。在Connections → Channels中设置默认通道活动路由状态会显示当前正在使用的通道。Telegram 提供两种凭据模式通过 OpenHuman 一键连接加密托管或提供你自己的凭据以获得最大控制权。消息通道的轮询侧Auto-fetch 每 20 分钟同步「收到请求才回答」的被动助手模型之外OpenHuman 会持续主动拉取你的服务栈让「我邮箱里昨晚到了什么」这类问题的答案提前躺在 Memory Tree 里详见 gitbooks/features/obsidian-wiki/auto-fetch.md。一个全局调度器每 20 分钟 tick 一次遍历每个活动连接 → 查找对应的原生 provider → 检查该连接是否到了同步间隔 → 调用provider.sync(ctx, SyncReason::Periodic)。关键设计点单一全局 tick而非每个连接一个任务——连接数量少单 tick 记账更简单状态按(toolkit, connection_id)隔离每个连接拥有自己的 cursor、上次同步时间戳、去重集合与每日预算重启后从本地 KV 重建漏掉一次周期性同步是无害的重启后的下一次 tick 会补上原生同步与事件驱动路径共享当 webhook 或on_connection_created触发非周期同步时会写入同一份 sync_state避免调度器重复触发错误只记录不抛出调度器绝不能 panic 出循环否则周期同步会静默停止。为什么是 20 分钟最初设计为 60 秒多个 provider 连接时会造成持续的 HTTP 拉取与数据库写入笔记本上可见地繁忙。20 分钟用少量延迟换取了显著更低的前台负载。每个 provider 的sync_interval_secs仍约束实际同步之间的最小间隔高流量的 Gmail 可以比低流量的 Stripe 同步更频繁全局 tick 只放宽上限此外每个连接还有每日请求预算以控制 API 成本与限流。Triggers实时事件管线连接一个集成不只是给 Agent 一个「按需读取」的地方它同时是一个实时事件源有人给你发邮件、编辑 Notion 页面、在你的仓库上开 issue、在 Stripe 上扣款、或在 Slack 私信你OpenHuman 都会近实时地收到事件并决定要不要做点什么完整说明见 gitbooks/features/integrations/triggers.md。典型触发事件集成示例触发事件GmailGMAIL_NEW_GMAIL_MESSAGE收件箱新邮件SlackSLACK_NEW_MESSAGE被提及的频道/私信消息NotionNOTION_PAGE_UPDATED被跟踪页面发生变化GitHubGITHUB_ISSUE_OPENED、GITHUB_PULL_REQUEST_OPENEDStripeSTRIPE_CHARGE_SUCCEEDED账户发生成功扣款CalendarGOOGLE_CALENDAR_EVENT_CREATED日历新增事件连接激活后相关的 trigger 订阅会自动接通。对 Gmail 有一个特殊前提trigger 订阅要求对 Google 账户具备 message-read 权限新版授权会请求https://www.googleapis.com/auth/gmail.readonly以启用GMAIL_NEW_GMAIL_MESSAGE并让原生 Gmail 同步路径读取新消息元数据。如果旧连接是在该 scope 加入之前创建的需先在 Settings 中重新连接 Gmail再启用 Gmail triggers。端到端数据流┌────────────────────┐ │ third-party API │ Gmail / Slack / Notion / GitHub / ... └─────────┬──────────┘ │ webhook ▼ ┌────────────────────┐ │ OpenHuman backend │ HMAC 校验 webhook、归一化 payload └─────────┬──────────┘ │ Socket.IO event (composio:trigger) ▼ ┌────────────────────┐ │ Rust core (本机) │ 在进程内事件总线发布 DomainEvent::ComposioTriggerReceived └─────────┬──────────┘ │ ▼ ┌────────────────────┐ │ Trigger Triage │ 分类drop / acknowledge / react / escalate └─────────┬──────────┘ │ ▼ ┌────────────────────┐ │ 四种结果之一 │ │ - 无动作 │ ← drop │ - 记忆笔记 │ ← acknowledge │ - Trigger Reactor │ ← react1-2 次工具调用 │ - Orchestrator │ ← escalate完整多步规划 └────────────────────┘webhook永远不会以原始形态到达你的机器。后端持有 OAuth token 并直接从第三方接收 webhook完成 HMAC 校验、payload 归一化后通过既有认证 socket 转发到你的 Rust 核心。本机看到的只是事件总线上一个干净、已校验的ComposioTriggerReceived事件。源码侧该链路有明确对应后端在 socket 上发出composio:trigger后由 src/openhuman/platform/socket/event_handlers.rs 解析并发布DomainEvent::ComposioTriggerReceived总线订阅者ComposioTriggerSubscriber归档事件并驱动记忆摄入订阅者注册代码见 src/openhuman/memory/sync/composio/bus_part_01.rs同一文件还定义了 OAuth 连接就绪的轮询超时与退避参数。Triage每个触发事件先过一遍分类器任何动作执行之前每个 trigger 都必须经过trigger_triageAgentagent 定义见 src/openhuman/agent/registry/agents/trigger_triage/agent.toml——它的唯一职责是决定系统接下来做什么。它只会选择四种动作之一动作发生什么适用场景drop什么都不做静默记录后丢弃垃圾、重复、无关噪声默认处理不关心的事物acknowledge持久化一条简短记忆笔记不运行 Agent值得记住的被动通知如「archive 里新建了一个页面」reacttrigger_reactorAgent 运行 1-2 次工具调用小型单步副作用存一条记忆、发一个快速确认、把线程标记为已读escalate完整orchestratorAgent 接管具备规划能力需要推理、多步骤或多技能的事起草回复、更新多个 Notion 页面、判断如何 triage 一个入站 issuetriage Agent 拥有与主 Agent 相同的记忆与工作区上下文因此能判断触发事件是否与你当前工作相关、涉及哪些人、以及是否属于你以前要求过 OpenHuman 处理的那类事。决策契约与宽容解析分类器的输出是一个结构化 JSON 决策契约定义在 src/openhuman/agent/triage/decision.rs{ action: drop|acknowledge|react|escalate, target_agent: trigger_reactor|orchestrator|null, prompt: task for the target agent, or null, reason: one-sentence justification }由于 triage 允许运行在gemma3:1b-it-qat这类 1B 级本地小模型上其输出经常带有 json 围栏、内嵌 JSON、尾逗号、甚至action: Drop大小写错误因此解析器parse_triage_decision对这些形态刻意宽容解析失败时调用方会在远端 provider 上重试整轮。从trigger_triage/agent.toml可以看到分类器刻意保持扁平named []零工具、sandbox_mode read_only、temperature 0.2、max_iterations 2并且保留 profile 与 MEMORY.md同一封入站邮件对不同用户画像可能是紧急或噪声因为模型不可靠的嵌套工具调用会破坏分类质量。而react路径的trigger_reactor见 src/openhuman/agent/registry/agents/trigger_reactor/agent.toml则是一个窄面专家工具面只有memory_store、read_workspace_state、spawn_subagent三个sandbox_mode none写路径模型 hint 固定为远端agentic档——反应性动作需要可靠的工具调用1B 级本地模型不满足。它保留 PROFILE.md让替用户发出的小消息带上用户的名字、角色与语气与 MEMORY.md让跟进内容与既有上下文连贯。为什么要 Triage 一步跳过分类器、把所有 trigger 直接灌进 orchestrator 是个坏主意原因有二大多数 trigger 是噪声一个已连接的 Gmail 账户每小时会触发几十个事件绝大多数用户并不关心每个都跑 orchestrator 会烧掉预算并制造持续的后台活动流不同 trigger 应有不同的成本上限一张自动化 Stripe 收据和一条私人 Slack 私信不该花相同的 token 来处理。Triage 让廉价路径保持廉价把 orchestrator 留给真正值得的事件。Triage 运行在快速模型档位参见 Automatic Model Routing因此分类本身是亚秒级的。配置、审计与退出开关默认开启集成一旦连接其 trigger 自动进入管线退出开关triage 路径受OPENHUMAN_TRIGGER_TRIAGE_DISABLED环境变量门控常量定义在 src/openhuman/memory/sync/composio/bus_part_01.rs设为1/true/yes会关闭 Agent 分类、退化为仅被动记录——集成本身保持连接只是抑制了自动动作按 trigger 设置在Settings中管理评估哪些集成与事件类型底层 RPC 为update_composio_trigger_settings/get_composio_trigger_settings审计日志每个 trigger 无论结论如何都会写入 trigger 历史持久化实现见 src/openhuman/integrations/composio/trigger_history.rs按 UTC 日分区为workspace/state/triggers/YYYY-MM-DD.jsonl的 JSONL 归档你可以看到什么到了、分类器判断了什么、最终跑了什么。决策与升级还会作为TriggerEvaluated/TriggerEscalated事件发布到进程内总线核心内任何组件都可订阅。精选目录之外MCP 服务器与 Skills 目录118 个 OAuth 连接器是精选路径在这之外 OpenHuman 还开放了更广的开源工具生态详见 gitbooks/features/integrations/mcp-and-skills.md。MCP数千台服务器可反向暴露自身内置MCP registry并行扇出到两个上游注册中心Smithery 与官方registry.modelcontextprotocol.io并合并结果可浏览数千台服务器搜索 → 安装 → 连接本地安装以 stdio 子进程方式拉起服务器已部署的服务器走 HTTP 连接受监督的连接已安装服务器持久化在本地 SQLitemcp_clients/mcp_clients.db见 src/openhuman/mcp/registry/README.md记录 command、args 与 transport。一个监督循环每 ~60s 探测一次启用的服务器采用逐服务器指数退避后台重连循环实现见 src/openhuman/mcp/registry/mod.rs可观测性每次非正常探测结果响应慢、transport 断开、重连成功或失败都会出现在Settings → Developer → Event Log的mcp徽标下——健康的服务器保持安静持续宕机、失败后恢复、或因 launcher 运行时缺失而无法启动的服务器会触发通知工具即插即用连接后MCP 服务器的工具与原生工具一样直接对 Agent 可用。反过来OpenHuman 也可以把自己暴露为 MCP 服务器openhuman-core mcp通过 stdio 提供只读工具记忆搜索/召回、Memory Tree 浏览、可选 web 搜索给 Claude Desktop 等客户端配置见 MCP Server。Skills约 9 万条目的元数据目录Skills是聚合多个上游来源HermesHub、ClawHub、LobeHub 等的 Agent 技能目录SKILL.md能力包单一聚合目录来源可经OPENHUMAN_SKILL_REGISTRY_CATALOG_URL配置规模约9 万条目每条含 id、名称、描述、来源、作者、版本、标签、平台、下载 URL 与许可证缓存与速度目录在启动时后台拉取不阻塞启动本地缓存于~/.openhuman/skill-registry/cache.json约 1 小时 TTL采用 stale-while-revalidatesingle-flight 门控防止大目录被重复下载元数据优先旧版应用内 skills 运行时QuickJS 沙箱已移除Skills 现在是你在Connections → Skills标签页浏览与安装的元数据目录而不是在应用内执行的代码不同条目的可用性各异——有的直接提供SKILL.md下载有的指向外部托管。原生语音与原生工具还有两个能力是原生内置而非集成因为它们是桌面体验的承重墙Voice语音转文字STT进、文字转语音TTS出外加一个实时 Google Meet Agent——加入会议、转录进 Memory Tree、还能在通话中说话详见 VoiceNative tools内置 web 搜索、web-fetch 抓取器以及完整的文件系统/git/lint/test/grep 编码工具集Agent 开箱即用详见 Native Tools。隐私边界凭据永不落在本机明文OpenHuman 的核心从不直接调用任何第三方 API。所有请求都经过 OpenHuman 后端由后端处理 OAuth token 与速率限制你的 token 从不以明文躺在机器磁盘上Agent 只看到工具调用的结果而看不到凭据完整边界见 Privacy Security。如果选择直连 Composio 模式边界随之改变本地核心使用你自己的 Composio API Key你需要自行负责 Composio 账户、速率限制、计费关系以及 trigger 投递所需的任何 webhook 端点。Triggers 管线同样遵循该边界第三方 token 在后端、webhook 由后端 HMAC 校验后才到达本机、分类与反应动作跑在本地核心与本地 Memory Tree 上、acknowledge/react/escalate写入的记忆笔记存储在本地 SQLite memory tree 与 Markdown vault与其他来源无异。开发者实现索引对想深入源码的读者原文档给出了如下实现指针均已在本仓库确认存在Triage Agentsrc/openhuman/agent/registry/agents/trigger_triage/agent.tomlprompt.mdReactor Agentsrc/openhuman/agent/registry/agents/trigger_reactor/决策契约与宽容解析器src/openhuman/agent/triage/decision.rsComposio 总线订阅者src/openhuman/memory/sync/composio/bus.rs与bus_part_01.rsComposioTriggerSubscriberTrigger 历史持久化src/openhuman/integrations/composio/trigger_history.rs领域事件DomainEvent::ComposioTriggerReceived/TriggerEvaluated/TriggerEscalatedTrigger 设置 RPCupdate_composio_trigger_settings/get_composio_trigger_settingsComposio 模块总览RPC 表、Agent 工具、事件、持久化、依赖src/openhuman/integrations/composio/README.md相关文档链路Auto-fetch 的轮询侧见 Auto-fetch from Integrations所有数据终点的 Memory Tree以及使用 trigger 上下文与记忆做前瞻规划的 Subconscious Loop。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考