OpenConnector、Composio、Nango 与 Pipedream：开源要看到哪一层？

OpenConnector、Composio、Nango 与 Pipedream 官方品牌标识组成的文章封面

给 AI Agent 接上 Gmail、Notion 或 Slack，第一次跑通往往很让人兴奋。原本只能回答问题的助手，终于可以查邮件、更新文档、完成实际工作。

接下来，问题就具体了。

某个操作少了一个参数，能不能自己补？接口调用失败，能查到哪一步出了问题？客户要求账号凭据放在自己的环境里，这套服务能不能搬过去？

这时，连接工具开放了哪些代码、允许你控制哪些环节，就开始影响日常开发。

OpenConnector、Composio、Nango 和 Pipedream 都能用于应用集成，但它们公开代码的范围、自部署方式和许可证并不相同。选型时，值得把这些差别拆开看。

先看清楚：公开的是哪一部分代码？

SDK、连接器和运行时经常一起出现，但各自负责的事情不同。

SDK 帮你的应用组织参数、发出请求，再接收结果。SDK 开源后，你可以查看和修改客户端的调用行为。
连接器执行代码 把某个操作落实为第三方 API 请求，例如参数怎样转换、返回结果怎样处理。这部分公开后，操作本身的实现更容易检查和修改。
连接运行时 负责让这些操作实际运行起来，通常还会处理凭据、授权、操作权限和执行记录。运行时源码公开并提供部署方式，团队才有机会接管这些环节。

工具调用关系图：Agent 通过 SDK、CLI 或 MCP 调用连接运行时，运行时执行连接器代码并访问第三方 API，同时管理凭据、权限和执行记录

图 1：一次工具调用的概念示意。连接器执行代码位于运行时内；具体产品的实现可能不同。

这几层分别解决不同的问题。SDK 公开，不能直接说明网关源码也公开；连接器可以修改，也不能直接说明它背后的整套平台可以自行部署。

四个产品，放在一起看

产品	公开代码的主要范围	自部署情况	需要留意的边界
OpenConnector	Connector SDK、oo CLI、连接网关、连接器定义、操作执行代码和 Web 控制台	提供 Docker、Node.js 等公开部署方式，也支持 Cloudflare	核心仓库采用 Apache-2.0；配套 SDK 与 CLI 采用 MIT；具体操作仍需检查执行器和授权要求
Composio	公开主仓库包含 SDK、CLI 和框架适配器	官方提供企业自托管与私有环境部署选项	SDK 仓库的 MIT 许可证不能直接延伸到网关实现
Nango	集成平台源码与集成函数相关代码	提供免费自托管和企业自托管	主仓库采用 Elastic License 2.0；免费自托管的功能范围有限
Pipedream	组件代码、文档和相关软件包	常规组件执行依赖 Pipedream 托管环境	主仓库采用 Source Available 许可证；组件公开不代表整个平台可按相同方式自行部署

表中范围可在 OpenConnector 仓库、Composio 仓库、Composio 部署说明、Nango 自托管文档和 Pipedream 组件文档中核对。

业务需要一个新的 provider，怎么办？

假设团队新接入了一套客户管理系统，希望 Agent 能查询客户、更新跟进记录，但现有目录里还没有这项服务。

对使用者来说，最有用的是能在网关侧增加一个 provider，也就是接入一个新的服务提供商，把业务需要的操作提供给 Agent。SDK 和 CLI 继续沿用现有的调用方式，通常不需要修改它们的源码。

OpenConnector 提供了三种参与方式：

自己做：在自部署的网关中新增 provider，定义授权方式、操作参数和执行逻辑，按自己的业务节奏使用。
提交 PR：把实现贡献给 OpenConnector，让其他使用者也能接入这项服务。
提出 issue：如果不打算自己开发，可以把需要的服务和操作告诉我们，由团队补充支持。

对于这类新增 provider 或操作的需求，我们通常会在 24–36 小时内完成相关功能的合并。这是团队通常的处理节奏；具体需求仍会受接口复杂度、测试账号和第三方授权条件影响。

这样，目录暂时没有覆盖的服务，也有继续接入的办法。团队可以自行实现，也可以与项目维护者一起补齐，不必为了一个新服务重写整套调用工具。新增 provider 的贡献指南 · 提交需求

OpenConnector 的开源范围覆盖从调用入口到连接服务的整条链路：应用代码使用的 Connector SDK、命令行和本地 Agent 使用的 oo CLI，以及连接网关、操作定义与执行器、Web 控制台，都有公开源码。

它的 README 在开发者工具一栏列出了这些入口：SDK 用于在代码中调用操作；oo connector 可以搜索、查看和执行操作；Agent 也可以通过 MCP 接入，其他客户端可以使用 HTTP / OpenAPI。SDK 和 CLI 都支持连接 OOMOL 托管服务或自部署的 OpenConnector。OpenConnector 开发者工具说明

这些代码分别维护在 OpenConnector、Connector SDK 和 oo CLI 的公开仓库中。团队可以从客户端调用一路查看到服务端执行，也可以在自己的环境里管理连接身份、允许或禁止的操作，并查看脱敏后的执行记录。

OpenConnector 中文控制台的提供商目录，展示应用连接和 OAuth 配置入口

图 2：OpenConnector 官方仓库提供的中文控制台截图，展示应用连接与 OAuth 配置入口。图片中的界面名称及数量反映截图时的版本，不作为当前覆盖数量承诺。原图来源。

新增 provider 之后，应用和 Agent 仍然通过同一套调用入口使用它。团队也可以在网关中限制允许执行的操作、管理连接账号，并查看执行记录。

当然，目录里能找到一个操作，不应直接当作它已经满足全部需求。正式接入前，仍然需要确认对应执行器是否可用、参数是否覆盖业务场景，以及第三方服务要求什么授权。

Composio 的公开主仓库则明确定位为 SDK 仓库，包含 Python、TypeScript SDK、CLI 和适配器。对于主要通过它的托管工具完成接入的团队，这些代码有助于理解和调整客户端行为。但如果需要检查或修改网关内部实现，就不能仅凭 SDK 开源得出结论。Composio 仓库说明

这里也要区分源码和部署。Composio 官方已经提供企业自托管及私有环境部署选项，因此，把它概括成“只能用云端”并不准确。更有意义的比较是：你能否直接从公开代码开始部署，哪些能力需要企业方案，以及部署以后允许修改哪些部分。Composio MCP Gateway

Nango 又是另一种情况。它公开了集成平台源码，也提供自托管，所以不能把它归为只有 SDK 的产品。不过，Nango 的免费自托管主要覆盖授权和 API 代理；函数执行、同步、Webhook、MCP 等完整平台能力，需要查看其企业自托管或云服务方案。评估时，要把自己需要的功能逐项放进部署方案里核对。Nango 官方自托管介绍

Pipedream 则很适合用来理解“组件代码公开”这一层。开发者可以阅读组件实现、编写自己的组件，并通过社区流程贡献代码；这些组件通常运行在 Pipedream 的无服务器基础设施上。因此，能够修改一个操作，和能够独立运行它背后的整套平台，是两项需要分别确认的能力。Pipedream 组件文档

看得到代码，还要看它的使用条件

OpenConnector 核心仓库采用 Apache-2.0，配套的 Connector SDK 和 oo CLI 采用 MIT；Composio 的公开 SDK 仓库采用 MIT；Nango 主仓库采用 Elastic License 2.0；Pipedream 主仓库采用自己的 Source Available 许可证。这些名称对应不同的使用条件，不能因为代码都能在 GitHub 上看到，就把它们视作同一种许可。

需要核对的对象	当前公开许可证
OpenConnector 核心仓库覆盖的源代码	Apache-2.0
OpenConnector 配套 Connector SDK	MIT
OpenConnector 配套 oo CLI	MIT
Composio 公开 SDK 仓库	MIT
Nango 主仓库	Elastic License 2.0
Pipedream 主仓库	Pipedream Source Available License

如果计划长期维护分支、重新分发，或把相关能力做成对外服务，应该提前核对对应条款。同时，OpenConnector 的开源许可覆盖项目自身代码，并不会替代 Gmail、Notion 等第三方服务的 API 条款、授权要求和品牌权利。

接管运行时以后，日常维护也由你决定

能自己部署以后，排查问题也多了一条路径：检查运行时状态，查看最近失败和执行记录，再决定是否需要调整配置或代码。

OpenConnector 中文控制台概览，展示运行时状态、可执行操作、调用趋势和最近调用

图 3：OpenConnector 官方仓库提供的运行时概览截图。图中的统计数据是界面示例，不能作为当前服务规模或可靠性指标。原图来源。

自部署也有实际工作量。服务器、升级、备份、密钥管理，以及部分服务的 OAuth 应用申请，都需要有人负责。团队获得更多控制权，也要承担相应的维护工作。

先用 SaaS，业务做大后再迁移到自部署

OOMOL 的 SaaS 版本与开源 OpenConnector 在连接器调用层保持同构：沿用相同的 provider 标识、操作标识和参数契约。同一个操作放在托管环境还是自己的服务器上，应用和 Agent 使用的是同一套调用约定。OpenConnector 使用方式

这让团队可以先用 SaaS 完成接入，由 OOMOL 运行连接服务。等业务规模扩大，或客户要求把连接服务放到自己的环境里，再部署 OpenConnector，并把 SDK、CLI 的连接地址切换过去。已有的操作调用和参数组织可以继续复用，无需为这些操作重新编写一套集成。

具体到两个入口：

调用入口	切换到自部署时怎么做	可以继续复用什么
Connector SDK	使用 SDK 提供的 `OpenConnector` 客户端，将 `baseUrl` 指向自部署地址，并配置对应运行时令牌	已支持操作的标识、输入参数，以及 `execute` 等调用方式
oo CLI	将 `OO_CONNECTOR_URL` 指向自部署地址，按需配置 `OO_CONNECTOR_TOKEN`	`oo connector search`、`schema`、`run` 等连接器命令及其操作参数

配置方式见 SDK 自部署说明与 CLI 自部署指南。

迁移时仍需在新环境中配置第三方账号连接、OAuth 应用和凭据；如果用到了 SaaS 的团队管理、项目用户或其他托管能力，也需要核对对应支持范围。同构带来的便利主要在连接器调用层：部署位置可以随业务调整，已经写好的操作调用能够保留下来。

实际评估时，可以先选一个业务中常用的操作，在 SaaS 上跑通，再通过同一个 SDK 或 CLI 连接自部署实例，验证相同操作和参数能否继续使用。如果还缺一个服务，再看看新增 provider 或提交需求的流程是否顺手。

对既希望尽快接入、又希望保留自部署选择的团队，OpenConnector 提供了一条可以逐步推进的路径。可以先通过 OOMOL 连接应用，也可以按自部署指南运行一个实例，从自己最常用的操作开始验证。

本文中的品牌标识和产品截图来自各项目官方网站或官方仓库，用于产品识别与比较说明；相关权利属于各自权利人。图示为本文绘制。