--- author: OOMOL author_url: https://oomol.com/zh-cn/about/ datePublished: 2026-09-17 title: OpenConnector、Composio、Nango 与 Pipedream：开源要看到哪一层？ description: 比较四种 Agent 应用集成方案的开源范围、自部署与许可证，了解如何新增 provider，以及从 OOMOL SaaS 迁移到自部署时能复用什么。 lang: zh-CN canonical_url: https://oomol.com/zh-cn/blog/openconnector-comparison/ markdown_url: https://oomol.com/zh-cn/blog/openconnector-comparison.md --- ![OpenConnector、Composio、Nango 与 Pipedream 官方品牌标识组成的文章封面](/blog/openconnector-comparison/zh-cn-cover.webp) 给 AI Agent 接上 Gmail、Notion 或 Slack，第一次跑通往往很让人兴奋。原本只能回答问题的助手，终于可以查邮件、更新文档、完成实际工作。 接下来，问题就具体了。 某个操作少了一个参数，能不能自己补？接口调用失败，能查到哪一步出了问题？客户要求账号凭据放在自己的环境里，这套服务能不能搬过去？ 这时，连接工具开放了哪些代码、允许你控制哪些环节，就开始影响日常开发。 OpenConnector、Composio、Nango 和 Pipedream 都能用于应用集成，但它们公开代码的范围、自部署方式和许可证并不相同。选型时，值得把这些差别拆开看。 ## 先看清楚：公开的是哪一部分代码？ SDK、连接器和运行时经常一起出现，但各自负责的事情不同。 - **SDK** 帮你的应用组织参数、发出请求，再接收结果。SDK 开源后，你可以查看和修改客户端的调用行为。 - **连接器执行代码** 把某个操作落实为第三方 API 请求，例如参数怎样转换、返回结果怎样处理。这部分公开后，操作本身的实现更容易检查和修改。 - **连接运行时** 负责让这些操作实际运行起来，通常还会处理凭据、授权、操作权限和执行记录。运行时源码公开并提供部署方式，团队才有机会接管这些环节。 ![工具调用关系图：Agent 通过 SDK、CLI 或 MCP 调用连接运行时，运行时执行连接器代码并访问第三方 API，同时管理凭据、权限和执行记录](/blog/openconnector-comparison/zh-cn-layers.webp) *图 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 仓库](https://github.com/oomol-lab/open-connector)、[Composio 仓库](https://github.com/ComposioHQ/composio)、[Composio 部署说明](https://composio.dev/mcp-gateway)、[Nango 自托管文档](https://nango.dev/docs/guides/platform/self-hosting)和 [Pipedream 组件文档](https://pipedream.com/docs/components)中核对。 ## 业务需要一个新的 provider，怎么办？ 假设团队新接入了一套客户管理系统，希望 Agent 能查询客户、更新跟进记录，但现有目录里还没有这项服务。 对使用者来说，最有用的是能在网关侧增加一个 provider，也就是接入一个新的服务提供商，把业务需要的操作提供给 Agent。SDK 和 CLI 继续沿用现有的调用方式，通常不需要修改它们的源码。 OpenConnector 提供了三种参与方式： - **自己做**：在自部署的网关中新增 provider，定义授权方式、操作参数和执行逻辑，按自己的业务节奏使用。 - **提交 PR**：把实现贡献给 OpenConnector，让其他使用者也能接入这项服务。 - **提出 issue**：如果不打算自己开发，可以把需要的服务和操作告诉我们，由团队补充支持。 对于这类新增 provider 或操作的需求，我们通常会在 **24–36 小时内完成相关功能的合并**。这是团队通常的处理节奏；具体需求仍会受接口复杂度、测试账号和第三方授权条件影响。 这样，目录暂时没有覆盖的服务，也有继续接入的办法。团队可以自行实现，也可以与项目维护者一起补齐，不必为了一个新服务重写整套调用工具。[新增 provider 的贡献指南](https://github.com/oomol-lab/open-connector/blob/main/CONTRIBUTING.md#adding-providers) · [提交需求](https://github.com/oomol-lab/open-connector/issues) OpenConnector 的开源范围覆盖从调用入口到连接服务的整条链路：应用代码使用的 **Connector SDK**、命令行和本地 Agent 使用的 **oo CLI**，以及连接网关、操作定义与执行器、Web 控制台，都有公开源码。 它的 README 在开发者工具一栏列出了这些入口：SDK 用于在代码中调用操作；`oo connector` 可以搜索、查看和执行操作；Agent 也可以通过 MCP 接入，其他客户端可以使用 HTTP / OpenAPI。SDK 和 CLI 都支持连接 OOMOL 托管服务或自部署的 OpenConnector。[OpenConnector 开发者工具说明](https://github.com/oomol-lab/open-connector#developer-tools) 这些代码分别维护在 [OpenConnector](https://github.com/oomol-lab/open-connector)、[Connector SDK](https://github.com/oomol-lab/connector-sdk) 和 [oo CLI](https://github.com/oomol-lab/oo-cli) 的公开仓库中。团队可以从客户端调用一路查看到服务端执行，也可以在自己的环境里管理连接身份、允许或禁止的操作，并查看脱敏后的执行记录。 ![OpenConnector 中文控制台的提供商目录，展示应用连接和 OAuth 配置入口](/blog/openconnector-comparison/catalog-zh.webp) *图 2：OpenConnector 官方仓库提供的中文控制台截图，展示应用连接与 OAuth 配置入口。图片中的界面名称及数量反映截图时的版本，不作为当前覆盖数量承诺。[原图来源](https://github.com/oomol-lab/open-connector/blob/main/assets/open-console-zh.jpg)。* 新增 provider 之后，应用和 Agent 仍然通过同一套调用入口使用它。团队也可以在网关中限制允许执行的操作、管理连接账号，并查看执行记录。 当然，目录里能找到一个操作，不应直接当作它已经满足全部需求。正式接入前，仍然需要确认对应执行器是否可用、参数是否覆盖业务场景，以及第三方服务要求什么授权。 Composio 的公开主仓库则明确定位为 SDK 仓库，包含 Python、TypeScript SDK、CLI 和适配器。对于主要通过它的托管工具完成接入的团队，这些代码有助于理解和调整客户端行为。但如果需要检查或修改网关内部实现，就不能仅凭 SDK 开源得出结论。[Composio 仓库说明](https://github.com/ComposioHQ/composio) 这里也要区分源码和部署。Composio 官方已经提供企业自托管及私有环境部署选项，因此，把它概括成“只能用云端”并不准确。更有意义的比较是：你能否直接从公开代码开始部署，哪些能力需要企业方案，以及部署以后允许修改哪些部分。[Composio MCP Gateway](https://composio.dev/mcp-gateway) Nango 又是另一种情况。它公开了集成平台源码，也提供自托管，所以不能把它归为只有 SDK 的产品。不过，Nango 的免费自托管主要覆盖授权和 API 代理；函数执行、同步、Webhook、MCP 等完整平台能力，需要查看其企业自托管或云服务方案。评估时，要把自己需要的功能逐项放进部署方案里核对。[Nango 官方自托管介绍](https://nango.dev/blog/best-self-hosted-api-integration-platforms-for-ai-agents) Pipedream 则很适合用来理解“组件代码公开”这一层。开发者可以阅读组件实现、编写自己的组件，并通过社区流程贡献代码；这些组件通常运行在 Pipedream 的无服务器基础设施上。因此，能够修改一个操作，和能够独立运行它背后的整套平台，是两项需要分别确认的能力。[Pipedream 组件文档](https://pipedream.com/docs/components) ## 看得到代码，还要看它的使用条件 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](https://github.com/oomol-lab/open-connector/blob/main/LICENSE.txt) | | OpenConnector 配套 Connector SDK | [MIT](https://github.com/oomol-lab/connector-sdk/blob/main/LICENSE) | | OpenConnector 配套 oo CLI | [MIT](https://github.com/oomol-lab/oo-cli/blob/main/LICENSE) | | Composio 公开 SDK 仓库 | [MIT](https://github.com/ComposioHQ/composio/blob/next/LICENSE) | | Nango 主仓库 | [Elastic License 2.0](https://github.com/NangoHQ/nango/blob/master/LICENSE) | | Pipedream 主仓库 | [Pipedream Source Available License](https://github.com/PipedreamHQ/pipedream/blob/master/LICENSE) | 如果计划长期维护分支、重新分发，或把相关能力做成对外服务，应该提前核对对应条款。同时，OpenConnector 的开源许可覆盖项目自身代码，并不会替代 Gmail、Notion 等第三方服务的 API 条款、授权要求和品牌权利。 ## 接管运行时以后，日常维护也由你决定 能自己部署以后，排查问题也多了一条路径：检查运行时状态，查看最近失败和执行记录，再决定是否需要调整配置或代码。 ![OpenConnector 中文控制台概览，展示运行时状态、可执行操作、调用趋势和最近调用](/blog/openconnector-comparison/overview-zh.webp) *图 3：OpenConnector 官方仓库提供的运行时概览截图。图中的统计数据是界面示例，不能作为当前服务规模或可靠性指标。[原图来源](https://github.com/oomol-lab/open-connector/blob/main/assets/overview-page-zh.jpg)。* 自部署也有实际工作量。服务器、升级、备份、密钥管理，以及部分服务的 OAuth 应用申请，都需要有人负责。团队获得更多控制权，也要承担相应的维护工作。 ## 先用 SaaS，业务做大后再迁移到自部署 OOMOL 的 SaaS 版本与开源 OpenConnector 在连接器调用层保持同构：沿用相同的 provider 标识、操作标识和参数契约。同一个操作放在托管环境还是自己的服务器上，应用和 Agent 使用的是同一套调用约定。[OpenConnector 使用方式](https://github.com/oomol-lab/open-connector#usage-paths) 这让团队可以先用 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 自部署说明](https://github.com/oomol-lab/connector-sdk#self-hosted-runtime)与 [CLI 自部署指南](https://github.com/oomol-lab/oo-cli/blob/main/docs/self-hosted-connector.md)。 迁移时仍需在新环境中配置第三方账号连接、OAuth 应用和凭据；如果用到了 SaaS 的团队管理、项目用户或其他托管能力，也需要核对对应支持范围。同构带来的便利主要在连接器调用层：部署位置可以随业务调整，已经写好的操作调用能够保留下来。 实际评估时，可以先选一个业务中常用的操作，在 SaaS 上跑通，再通过同一个 SDK 或 CLI 连接自部署实例，验证相同操作和参数能否继续使用。如果还缺一个服务，再看看新增 provider 或提交需求的流程是否顺手。 对既希望尽快接入、又希望保留自部署选择的团队，OpenConnector 提供了一条可以逐步推进的路径。可以先通过 [OOMOL 连接应用](https://console.oomol.com/connections)，也可以按[自部署指南](/zh-cn/docs/openconnector-self-hosting/)运行一个实例，从自己最常用的操作开始验证。 --- *本文中的品牌标识和产品截图来自各项目官方网站或官方仓库，用于产品识别与比较说明；相关权利属于各自权利人。图示为本文绘制。*