企业官网建设流程全解析

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/openhuman

OpenHuman 的 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 模块，它对外暴露五类能力：

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 中存在两种形态：

• 原生 provider（native provider）：Rust 模块知道如何把该服务直接摄取进 Memory Tree，例如 Gmail 的原生摄取路径；
• 仅代理工具（proxied tools）：Agent 可以调用它的动作，但还没有自动摄取（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”的管线，三段各自有独立文件与测试：

1. 参数准备（execute_prepare.rs）：对 action 调用做本地预检式参数校验与整形。其中 googlecalendar_args.rs 是典型例子：为 Google Calendar 的 list/find slug 注入时区与singleEvents默认值，避免模型漏填参数导致空结果。
2. 重试策略（auth_retry.rs）：针对 OAuth 授权后的令牌传播间隙（上游报 “Connection error, try to authenticate”）做单次重试——这是“刚连上就不能用”这一类时序问题的专门补丁。
3. 错误分类（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 read），OpenHuman 同时为已连接服务提供了“推”与“周期同步”两条补充路径，文档的 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 & Skills：118+ OAuth 连接器只是策展路径；在此之外，内置 MCP 注册表与约 9 万条SKILL.md技能目录让 Agent 的工具面可以继续向外扩张。
• 隐私与安全：上文隐私边界的完整定义。

小结

OpenHuman 的第三方集成体系可以概括为三层设计：统一工具面（模型只面对 function-calling schema，不关心后端服务身份）、双路径摄取（native provider 直供 Memory Tree，proxied 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