OpenConnector、Composio、Nango 與 Pipedream：開源要看到哪一層？

OpenConnector、Composio、Nango 與 Pipedream 的原始碼、部署與維護比較

替 AI Agent 接上 Gmail、Notion 或 Slack，第一次成功執行總是令人期待。原本只能回答問題的助手，終於能查郵件、更新文件，完成實際工作。

接著，問題會變得具體：業務需要的操作還沒支援，能不能新增？請求失敗時，可以查到哪一步？客戶要求把憑證留在自己的環境裡，連接服務能不能一起搬過去？

這時，平台公開哪些程式碼、哪些部分能由自己管理，就會影響日常開發。OpenConnector、Composio、Nango 和 Pipedream 都能處理應用程式整合，但原始碼範圍、部署方式與授權條款各有不同。

先看清楚公開的是哪一部分

SDK、連接器與執行環境負責不同的工作。

SDK 整理參數、送出請求並接收結果。公開 SDK 原始碼，讓你能檢查用戶端的呼叫行為。
連接器執行程式碼 將操作轉成第三方 API 請求，包括參數轉換與結果處理。這部分公開後，就能檢查與擴充操作的實作。
連接器執行環境 負責執行操作，通常也處理憑證、授權、操作權限與執行紀錄。公開原始碼並提供部署方式，團隊才有機會自行管理這些環節。

工具呼叫概念圖：用戶端經由連接器執行環境存取第三方 API

圖 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、Composio 儲存庫、Composio 部署方案、Nango 自行託管、Pipedream 元件文件。

業務需要新的 provider，怎麼辦？

假設團隊導入一套客戶管理系統，希望 Agent 查詢客戶、更新跟進紀錄，但目錄尚未支援這項服務。

對使用者來說，實用的擴充點是在閘道端新增 provider：接入新的服務提供者，將所需操作交給 Agent 使用。SDK 與 CLI 沿用原本的呼叫方式，通常不需要修改它們的原始碼。

OpenConnector 提供三種參與方式：

自行實作：在自己部署的閘道加入 provider，定義授權方式、參數與執行邏輯，依照業務時程使用。
提交 PR：貢獻實作，讓其他使用者也能接入這項服務。
提出 issue：描述需要的服務與操作，由我們的團隊補上支援。

對這類新增 provider 或操作的需求，我們通常會在 24–36 小時內合併相關功能。這是團隊一般的處理節奏；API 複雜度、測試帳號與第三方授權條件仍可能影響時程。

目錄暫時沒有涵蓋的服務，因此有了繼續整合的途徑。可以自行實作，也可以與維護者合作，並沿用既有的呼叫工具。新增 provider 貢獻指南 · 提出需求

OpenConnector 公開的程式碼涵蓋呼叫入口與連接服務，包括 Connector SDK、oo CLI、閘道、操作定義與執行器、Web 控制台。應用程式可用 SDK，命令列可用 oo connector 搜尋、查看及執行操作；Agent 可透過 MCP 接入，其他用戶端可使用 HTTP/OpenAPI。SDK 與 CLI 都支援 OOMOL 託管服務和自行部署的執行環境。開發者工具說明

相關程式碼分別維護於 OpenConnector、Connector SDK 與 oo CLI 儲存庫。團隊可檢查從用戶端到執行端的流程，也能在自己的環境管理連接身分、操作權限與已遮蔽敏感資訊的執行紀錄。

OpenConnector 控制台的服務目錄與 OAuth 設定入口，介面為簡體中文

圖 2：來自官方儲存庫的簡體中文介面截圖。名稱與數量反映截圖當時的版本，不代表目前的涵蓋數量。

新增 provider 後，應用程式與 Agent 仍透過相同入口使用它。正式採用某項操作前，應確認執行器可用、參數符合需求，也能完成第三方要求的授權。

Composio 的公開主儲存庫定位為 SDK monorepo，包含 Python、TypeScript SDK、CLI 與轉接器。它們有助於檢查用戶端行為，但不能據此認定閘道內部原始碼也能自由檢查與修改。Composio 儲存庫

Composio 已有企業自行託管與私有環境部署選項，不能概括成「只能使用雲端」。更實際的比較，是哪些部署路徑能從公開原始碼開始、哪些需要企業方案，以及部署後能修改哪些部分。Composio MCP Gateway

Nango 公開了平台原始碼，也支援自行託管。免費版本主要包含授權與 API 代理；函式、同步、Webhook 和 MCP 等完整平台功能，需要核對 Cloud 或企業自行託管方案。Nango 自行託管說明

Pipedream 的開發者可以閱讀元件實作、撰寫元件並提交 PR。元件通常在 Pipedream 的無伺服器環境執行，因此能修改操作與能自行運行整個平台，仍是兩個不同問題。Pipedream 元件文件

看得到程式碼，也要看授權條款

原始碼都能在 GitHub 上看到，不代表使用條件相同。

程式碼範圍	公開授權
OpenConnector 核心儲存庫	Apache-2.0
Connector SDK	MIT
oo CLI	MIT
Composio 公開 SDK 儲存庫	MIT
Nango 主儲存庫	Elastic License 2.0
Pipedream 主儲存庫	Pipedream Source Available License

若要長期維護分支、重新散布程式碼，或以此提供對外服務，應先確認相關條款。OpenConnector 的授權涵蓋專案自身程式碼；第三方 API 條款、授權要求與品牌權利仍各自適用。

自行運行，也需要日常維護

自行部署後，可以查看執行環境狀態、最近的失敗與呼叫紀錄，再決定是否調整設定或程式碼。

OpenConnector 執行環境概覽，包含狀態、呼叫趨勢與最近呼叫，介面為簡體中文

圖 3：來自官方儲存庫的介面截圖。數字僅展示介面，不是目前規模或可靠性的指標。

自行部署也代表有人需要負責升級、備份、金鑰、伺服器，以及部分服務的 OAuth 應用程式申請。團隊取得控制權，也承擔相應的維護工作。

先用 SaaS，業務成長後再自行部署

OOMOL SaaS 與開源 OpenConnector 在連接器呼叫層保持同構，沿用相同的 provider 標識、操作標識與參數契約。執行環境由 OOMOL 託管或放在自己的伺服器上，應用程式使用的是同一套操作約定。部署方式

團隊可以先使用 SaaS，等業務成長或客戶要求私有部署，再把 SDK、CLI 指向自行部署的 OpenConnector。已支援操作的呼叫與參數可以繼續沿用，無須重新開發這些整合。

呼叫入口	切換方式	可以沿用的內容
Connector SDK	使用 `OpenConnector` 用戶端，設定自己的 `baseUrl` 與執行環境權杖	已支援的操作標識、輸入參數與 `execute` 等呼叫方式
oo CLI	設定 `OO_CONNECTOR_URL`，並視需要設定 `OO_CONNECTOR_TOKEN`	`search`、`schema`、`run` 等連接器命令及操作參數

詳見 SDK 自行託管說明及 CLI 指南。

新環境仍需設定第三方帳號連接、OAuth 應用程式與憑證。若使用 SaaS 團隊管理、專案使用者或其他託管能力，也要另外確認支援範圍。同構讓連接器呼叫能保留下來，並不表示所有帳號與平台功能都會自動搬移。

評估時，可以先在 SaaS 執行常用操作，再讓同一套 SDK 或 CLI 連接自行部署的執行個體，核對相同操作與參數能否繼續使用。若還缺少服務，再試試新增 provider 或提交需求的流程。

希望快速完成整合，又保留自行部署選擇的團隊，可以先透過 OOMOL 連接應用程式，或依照部署指南建立執行個體，從每天都會使用的操作開始驗證。

品牌標識及產品截圖來自各專案官方網站或儲存庫，用於識別與比較，權利歸各自權利人所有。概念圖為本文繪製。