OpenHuman 第三方集成Agent 如何经由单一代理工具面调用 119 个 SaaS 服务【免费下载链接】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 的 Agent 通过一个统一的“代理工具面”proxied tool surface接入 Gmail、Notion、GitHub、Slack、Lark / Feishu、Stripe、Calendar 等 119 个第三方服务用户完成一次 OAuth 连接后这些服务的动作就会变成 Agent 可直接调用的工具请求经由 OpenHuman 后端路由、结果像普通工具输出一样返回。读完本文你将理解这一工具面在 Agent 视角下的形态、原生native与代理proxied两类数据摄取路径的区别、Lark / Feishu 的双通道设计以及“令牌永不落盘”这一隐私边界在 Rust 源码中的具体落点。第三方集成是什么119 服务的统一接入层OpenHuman 的 Agent 并不是为每个 SaaS 服务各写一套 SDK 调用而是把所有已连接服务的动作收敛到一个代理工具面上。其背后的连接器层由 Composio 驱动在默认的托管模式managed mode下OpenHuman 后端持有 Composio API 密钥负责 OAuth 令牌代理、限流与触发器 webhook 扇出本地 Rust 核心从不直接触碰 Composio API。用户也可以切换到直连模式composio.mode direct由本地核心持用户自己的 Composio API 密钥直接访问 Composio v3 API此时同步工具调用可用但实时触发器 webhook 需要用户自建 webhook 基础设施参见 第三方集成目录。从源码结构看整个连接器层的 Rust 实现集中在 composio 模块它对外暴露五类能力能力入口工具面发现与执行list_tools/executeRPC以及面向模型的composio_list_toolkits、composio_list_connections、composio_authorize、composio_list_tools、composio_execute等 Agent 工具连接管理authorize发起 OAuth 交接、delete_connection删除连接可选做按来源的记忆清理触发器管理create_trigger/list_triggers/enable_trigger/disable_trigger以及持久化触发器事件档案身份与同步get_user_profile归一化的每工具包用户档案、refresh_all_identities、sync派发到各工具包的本地 provider路由模式管理get_mode/set_api_key/clear_api_key直连模式密钥存于加密密钥链永不回显Agent 视角连接即工具调用即路由这是 官方集成文档 的核心主张一旦你通过 OAuth 连接了一个服务它的动作就变成了可调用的工具。Agent 不需要知道某个工具背后是 Gmail 还是本地文件——它只是调用工具代理将请求经由 OpenHuman 后端、携带用户的令牌路由出去结果像任何其它工具输出一样返回。文档给出了几个典型的自然语言到工具调用的例子“给 Slack 的 #engineering 发条消息。”“在 openhuman 仓库里建一个 issue。”“我明天日历上有什么安排”“拉取最近 20 笔 1000 美元以上的 Stripe 扣款。”这些句子之所以能被同一条执行路径消化是因为在模型看来它们都是对统一函数调用接口function-calling schema的普通调用。从源码可以印证这一点composio 模块的 Agent 工具集tools.rs注册了五个模型可见工具composio_list_toolkits、composio_list_connections、composio_authorize、composio_list_tools、composio_execute。当integrations_agent子代理携带某个工具包toolkit启动时还会动态生成ComposioActionTool——一个 action 对应一个Tool包装使每个具体动作如slack_send_message成为模型可直接调用的独立工具。工具的可见性与可执行性受两级门控按工具包策展的目录curated catalog加上按工具包的用户作用域偏好read / write / admin。作用域的提升刻意不做成 Agent 工具——它只能由用户在 UI 中切换不可解析的 slug 一律按Write处理fail-closed。直连模式另有独立的工具提供者tools/direct.rs用用户自己的密钥访问 Composio v2/v3 API并受SecurityPolicy/ 沙箱模式sandbox mode门控。一次执行完成后执行 op 会在进程内事件总线发布DomainEvent::ComposioActionExecuted携带工具名、成功标志、错误信息、cost_usd与耗时——这就是活动流、成本账本与 Agent 自身预算感知到的“工具调用发生过”的唯一来源。即使动作被拒绝只要模块以“成功响应 successful: false”形式回报事件同样会被记录用于如实呈现“发生了什么”而非“是否完成”。原生 vs 代理同一服务可以有两种存在方式文档明确指出第三方服务在 OpenHuman 中存在两种形态原生 providernative providerRust 模块知道如何把该服务直接摄取进 Memory Tree例如 Gmail 的原生摄取路径仅代理工具proxied toolsAgent 可以调用它的动作但还没有自动摄取ingest路径。新的原生 provider 随功能落地逐步增加。从源码结构看这两条路径的分工在目录上就很直观代理工具面在 src/openhuman/integrations/composio/模块注释说明其职责是“发现 执行 Composio 动作的模型侧工具”原生 provider 注册表实际位于 src/openhuman/memory/sync/composio/providers/integrations/composio/providers下的文件只是兼容转发 shim由all_composio_providers/get_composio_provider提供按工具包检索配合周期性同步循环start_periodic_sync把连接的数据定时汇入记忆树。这与 集成目录页 的表述一致每个已连接服务同时以四种身份出现——Agent 工具、记忆来源每 20 分钟一次 auto-fetch 同步、画像信号与触发器来源。Lark / Feishu 的特例文档特别说明 Lark / Feishu 当前有两个面——一个原生的实时消息通道send/receive以及一个 Composio 代理的工作区工具入口chat、docs、wiki、meeting 动作以后端 allowlist 是否暴露为准。而把历史聊天/文档回填进 Memory Tree 的路径还不是原生 provider需要与实时通道连接器分开看待。换言之实时对话走本地原生通道历史数据摄取尚未原生化的这一现状是评估 Lark 集成时最需要注意的边界。执行管线一次代理工具调用在源码里经过什么composio 模块文档 把每个动作的执行描述为“prepare → retry → error classification”的管线三段各自有独立文件与测试参数准备execute_prepare.rs对 action 调用做本地预检式参数校验与整形。其中 googlecalendar_args.rs 是典型例子为 Google Calendar 的 list/find slug 注入时区与singleEvents默认值避免模型漏填参数导致空结果。重试策略auth_retry.rs针对 OAuth 授权后的令牌传播间隙上游报 “Connection error, try to authenticate”做单次重试——这是“刚连上就不能用”这一类时序问题的专门补丁。错误分类error_mapping.rs把执行失败分类为稳定的ComposioErrorClass并产出[composio:error:class] …前缀串。执行 op 的源码 中保留了CLASSIFIED前缀常量并明确“已分类错误不再二次包装”以匹配前端 formatter 的解析契约。模块文档注明这套分类正是为了避免工具失败被前端笼统地归入网关 502。此外还有两处值得注意的实现细节模式感知路由authorize/execute/list_*均经由create_composio_client在每次调用时判断composio.mode保证 backend / direct 切换在单次调用粒度上生效direct 模式永远不会暴露后端租户的数据allowlist 为空只看到用户自己的连接。类型漂移容忍Composio 上游部分字段会在 string 与 object 两种形态间漂移域类型types.rs使用de_string_or_object这类反序列化器吸收差异避免上游 schema 抖动直接打断核心。隐私边界令牌在何处Agent 能看到什么文档的“Privacy boundary”一节给出了这条产品线的硬边界对 Composio 代理的集成而言核心从不直接调用任何第三方 API。所有请求都经过 OpenHuman 后端由后端持有 OAuth 令牌并负责限流你的令牌永不以明文形式落在本机磁盘上Agent 只看到工具调用的结果看不到凭据本身。这条边界在源码中的对应证据有三处integrations 共享客户端文档 明确写道“backend-proxied tools never see provider API keys; the backend holds them.”后端代理工具永远看不到 provider API 密钥后端持有它们。IntegrationClient负责后端 URL 净化、Bearer JWT、{success,data,error}信封解析与有界错误详情提取且未登录时build_client直接返回None——没有会话就没有代理面。直连模式是唯一改变这条边界的显式选择此时本地核心使用用户自己的Composio API 密钥密钥通过加密密钥链security::credentials存储composio.get_mode只报告“是否已设置”而永不返回密钥本身密钥也永不出现在日志中。原生通道如 Lark / Feishu使用自己的本地配置文档提醒它们应当与 Composio OAuth 边界分开审视——也就是说本地原生通道读取的是用户在本机保存的通道凭据而不是后端托管的 OAuth 令牌两者的信任模型不同配置审查不能混为一谈。关联机制触发器、auto-fetch 与 MCP / Skills集成工具面是“拉”on-demand readOpenHuman 同时为已连接服务提供了“推”与“周期同步”两条补充路径文档的 See also 指向它们Triggers连接的集成还是实时事件源。第三方 webhook 先到达 OpenHuman 后端做 HMAC 校验与负载归一化再以 Socket.IO 事件composio:trigger推送给本地核心核心将其转为进程内事件DomainEvent::ComposioTriggerReceived先经 trigger_triage 分类drop / acknowledge / react / escalate再决定是静默丢弃、记一条记忆还是派发到完整编排。所有触发器事件按 UTC 日分区持久化为 JSONL 档案workspace/state/triggers/YYYY-MM-DD.jsonl可通过composio.list_trigger_history查询——这是 composio 模块 中trigger_history.rs的职责。Auto-fetch / Memory Tree代理工具面之外的自动摄取路径见 集成目录页 中“memory source每 20 分钟同步一次”的说明以及原生 provider 注册表所在的记忆同步目录。MCP Servers Skills118 OAuth 连接器只是策展路径在此之外内置 MCP 注册表与约 9 万条SKILL.md技能目录让 Agent 的工具面可以继续向外扩张。隐私与安全上文隐私边界的完整定义。小结OpenHuman 的第三方集成体系可以概括为三层设计统一工具面模型只面对 function-calling schema不关心后端服务身份、双路径摄取native provider 直供 Memory Treeproxied tools 按需调用Lark / Feishu 是双面的现实案例、后端托管凭据令牌不落盘、Agent 只见结果不见密钥直连模式为显式退出该边界的唯一选择。对开发者而言src/openhuman/integrations/composio/ 目录下的模块文档是一张精确的地图从ops的 RPC 方法表、tools.rs的门控逻辑到execute_prepare/auth_retry/error_mapping三段式执行管线均配有同名*_tests.rs测试文件可供逐条验证是继续深入这一子系统的最佳起点。【免费下载链接】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），仅供参考