--- author: OOMOL author_url: https://oomol.com/zh-tw/about/ datePublished: 2026-09-17 title: OpenConnector、Composio、Nango 與 Pipedream：開源要看到哪一層？ description: 比較四種 Agent 整合方案的原始碼範圍、自行部署與授權條款，了解如何新增 provider，以及從 OOMOL SaaS 遷移時能沿用哪些呼叫。 lang: zh-TW canonical_url: https://oomol.com/zh-tw/blog/openconnector-comparison/ markdown_url: https://oomol.com/zh-tw/blog/openconnector-comparison.md --- ![OpenConnector、Composio、Nango 與 Pipedream 的原始碼、部署與維護比較](/blog/openconnector-comparison/zh-tw-cover.webp) 替 AI Agent 接上 Gmail、Notion 或 Slack，第一次成功執行總是令人期待。原本只能回答問題的助手，終於能查郵件、更新文件，完成實際工作。 接著，問題會變得具體：業務需要的操作還沒支援，能不能新增？請求失敗時，可以查到哪一步？客戶要求把憑證留在自己的環境裡，連接服務能不能一起搬過去？ 這時，平台公開哪些程式碼、哪些部分能由自己管理，就會影響日常開發。OpenConnector、Composio、Nango 和 Pipedream 都能處理應用程式整合，但原始碼範圍、部署方式與授權條款各有不同。 ## 先看清楚公開的是哪一部分 SDK、連接器與執行環境負責不同的工作。 - **SDK** 整理參數、送出請求並接收結果。公開 SDK 原始碼，讓你能檢查用戶端的呼叫行為。 - **連接器執行程式碼** 將操作轉成第三方 API 請求，包括參數轉換與結果處理。這部分公開後，就能檢查與擴充操作的實作。 - **連接器執行環境** 負責執行操作，通常也處理憑證、授權、操作權限與執行紀錄。公開原始碼並提供部署方式，團隊才有機會自行管理這些環節。 ![工具呼叫概念圖：用戶端經由連接器執行環境存取第三方 API](/blog/openconnector-comparison/zh-tw-layers.webp) *圖 1：連接器執行程式碼位於執行環境內；各產品的實際實作可能不同。* SDK 公開，不代表閘道原始碼也公開；連接器可以修改，也不能直接推論整個平台都能自行部署。 ## 四個產品放在一起看 | 產品 | 主要公開程式碼 | 自行部署 | 需要確認的範圍 | | --- | --- | --- | --- | | **OpenConnector** | Connector SDK、oo CLI、閘道、provider 定義、操作執行器與 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**：貢獻實作，讓其他使用者也能接入這項服務。 - **提出 issue**：描述需要的服務與操作，由我們的團隊補上支援。 對這類新增 provider 或操作的需求，我們通常會在 **24–36 小時內合併相關功能**。這是團隊一般的處理節奏；API 複雜度、測試帳號與第三方授權條件仍可能影響時程。 目錄暫時沒有涵蓋的服務，因此有了繼續整合的途徑。可以自行實作，也可以與維護者合作，並沿用既有的呼叫工具。[新增 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、oo CLI、閘道、操作定義與執行器、Web 控制台**。應用程式可用 SDK，命令列可用 `oo connector` 搜尋、查看及執行操作；Agent 可透過 MCP 接入，其他用戶端可使用 HTTP/OpenAPI。SDK 與 CLI 都支援 OOMOL 託管服務和自行部署的執行環境。[開發者工具說明](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：來自[官方儲存庫](https://github.com/oomol-lab/open-connector/blob/main/assets/open-console-zh.jpg)的簡體中文介面截圖。名稱與數量反映截圖當時的版本，不代表目前的涵蓋數量。* 新增 provider 後，應用程式與 Agent 仍透過相同入口使用它。正式採用某項操作前，應確認執行器可用、參數符合需求，也能完成第三方要求的授權。 Composio 的公開主儲存庫定位為 SDK monorepo，包含 Python、TypeScript SDK、CLI 與轉接器。它們有助於檢查用戶端行為，但不能據此認定閘道內部原始碼也能自由檢查與修改。[Composio 儲存庫](https://github.com/ComposioHQ/composio) Composio 已有企業自行託管與私有環境部署選項，不能概括成「只能使用雲端」。更實際的比較，是哪些部署路徑能從公開原始碼開始、哪些需要企業方案，以及部署後能修改哪些部分。[Composio MCP Gateway](https://composio.dev/mcp-gateway) Nango 公開了平台原始碼，也支援自行託管。免費版本主要包含授權與 API 代理；函式、同步、Webhook 和 MCP 等完整平台功能，需要核對 Cloud 或企業自行託管方案。[Nango 自行託管說明](https://nango.dev/blog/best-self-hosted-api-integration-platforms-for-ai-agents) Pipedream 的開發者可以閱讀元件實作、撰寫元件並提交 PR。元件通常在 Pipedream 的無伺服器環境執行，因此能修改操作與能自行運行整個平台，仍是兩個不同問題。[Pipedream 元件文件](https://pipedream.com/docs/components) ## 看得到程式碼，也要看授權條款 原始碼都能在 GitHub 上看到，不代表使用條件相同。 | 程式碼範圍 | 公開授權 | | --- | --- | | OpenConnector 核心儲存庫 | [Apache-2.0](https://github.com/oomol-lab/open-connector/blob/main/LICENSE.txt) | | Connector SDK | [MIT](https://github.com/oomol-lab/connector-sdk/blob/main/LICENSE) | | 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 的授權涵蓋專案自身程式碼；第三方 API 條款、授權要求與品牌權利仍各自適用。 ## 自行運行，也需要日常維護 自行部署後，可以查看執行環境狀態、最近的失敗與呼叫紀錄，再決定是否調整設定或程式碼。 ![OpenConnector 執行環境概覽，包含狀態、呼叫趨勢與最近呼叫，介面為簡體中文](/blog/openconnector-comparison/overview-zh.webp) *圖 3：來自[官方儲存庫](https://github.com/oomol-lab/open-connector/blob/main/assets/overview-page-zh.jpg)的介面截圖。數字僅展示介面，不是目前規模或可靠性的指標。* 自行部署也代表有人需要負責升級、備份、金鑰、伺服器，以及部分服務的 OAuth 應用程式申請。團隊取得控制權，也承擔相應的維護工作。 ## 先用 SaaS，業務成長後再自行部署 OOMOL SaaS 與開源 OpenConnector 在連接器呼叫層保持同構，沿用相同的 provider 標識、操作標識與參數契約。執行環境由 OOMOL 託管或放在自己的伺服器上，應用程式使用的是同一套操作約定。[部署方式](https://github.com/oomol-lab/open-connector#usage-paths) 團隊可以先使用 SaaS，等業務成長或客戶要求私有部署，再把 SDK、CLI 指向自行部署的 OpenConnector。已支援操作的呼叫與參數可以繼續沿用，無須重新開發這些整合。 | 呼叫入口 | 切換方式 | 可以沿用的內容 | | --- | --- | --- | | **Connector SDK** | 使用 `OpenConnector` 用戶端，設定自己的 `baseUrl` 與執行環境權杖 | 已支援的操作標識、輸入參數與 `execute` 等呼叫方式 | | **oo CLI** | 設定 `OO_CONNECTOR_URL`，並視需要設定 `OO_CONNECTOR_TOKEN` | `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 或提交需求的流程。 希望快速完成整合，又保留自行部署選擇的團隊，可以先[透過 OOMOL 連接應用程式](https://console.oomol.com/connections)，或依照[部署指南](/zh-tw/docs/openconnector-self-hosting/)建立執行個體，從每天都會使用的操作開始驗證。 --- *品牌標識及產品截圖來自各專案官方網站或儲存庫，用於識別與比較，權利歸各自權利人所有。概念圖為本文繪製。*