前陣子幫團隊搭一個內嵌式 AI Agent，最頭痛的不是模型選型或 prompt engineering，而是「Agent 要怎麼連使用者的 Gmail、GitHub、Notion」。傳統做法是讓使用者在 App 裡填 API Key，或者走一輪 OAuth2 流程，把 token 存在自己的資料庫。每加一個服務提供者，就要多寫一套認證邏輯、token 重新整理機制、許可權管理。做三個服務還勉強撐得住，做到十個以上就是維護噩夢。
OpenConnector 解決的就是這個問題。它是一套開源的「聯結器閘道」，定位跟 Composio 類似，但走的路線不太一樣——憑證、許可權範圍、執行記錄全都留在閘道層，Agent 只拿到中繼資料和結果，不用碰金鑰。
它到底在做什麼
OpenConnector 讓你「連一次帳號，就能讓 Agent 隨處使用」。
你部署一臺 OpenConnector Gateway（跑在本機 Docker、Fly.io、Cloudflare Workers，或者直接上 OOMOL SaaS），然後在儀錶板裡把 Gmail、GitHub、Slack 這些服務一一連線。之後你的 Agent 透過 SDK、CLI、MCP 或 HTTP API 呼叫 Action，閘道自動處理憑證注入、token 重新整理、許可權檢查，最後回傳結果。
Agent 永遠不知道 OAuth token 長什麼樣子。金鑰只存在閘道內。
Agent 和使用者應用程式之間多了一層「憑證邊界」。這在 SaaS 產品裡特別好用——不用把每個使用者的 API Key 存在自己的資料庫，也不用擔心 token 過期時 Agent 卡住。閘道自動處理 refresh token、重新授權。
部署選項
OpenConnector 有四條路可以走。
最輕量的是跑在本機 Docker 上。docker compose up 一行指令就起來了，儀錶板在 localhost:3000，MCP endpoint 也在同一個 port。適合開發階段或內部工具用。
Fly.io 和 Cloudflare Workers 也有支援。Cloudflare 那套值得注意——Workers 負責執行階段、D1 存狀態、R2 處理檔案傳輸，整個跑在 Cloudflare 全球網路上。如果你已經在用 Cloudflare 生態系，整合幾乎零摩擦。
最後一種選擇是不自己部署，直接用 OOMOL 的代管服務。它跟開源版共用同一套 provider ID、action ID 和合約定義，今天用 SaaS、明天換私有部署，程式碼不用改。對於受限於 OAuth 核准流程或產品上市時程的團隊來說，這是一條務實的捷徑。
MCP：跟 Agent Host 的整合
如果你用的是支援 MCP（Model Context Protocol）的 Agent Framework——Claude Desktop、Continue、自建的 agent runtime 都行——OpenConnector 直接暴露了 /mcp endpoint。Agent 可以呼叫 list_apps 看有哪些服務可用，用 search_actions 搜尋特定功能，然後透過 execute_action 執行。
舉個例子。你在本地起好 OpenConnector 後，把 Gmail 連上去：
curl -s -X PUT http://localhost:3000/api/connections/gmail \
-H 'content-type: application/json' \
-d '{"authType":"oauth2","values":{"redirectUri":"http://localhost"}}'
然後 Agent Host 連到 http://localhost:3000/mcp，就能直接看到 Gmail 的 Action 列表。Agent 要讀一封郵件？呼叫 execute_action 傳入 action ID 和引數就好。OAuth token 存在閘道裡，Agent 完全無感。
好處是「一次部署、多 Agent 共用」。公司可能有 Claude Desktop、Cursor Agent、Slack Bot 三種不同的 agent runtime，它們都能連到同一臺 OpenConnector Gateway，讀取同一組已連線的服務帳號。不需要每個 agent 各自跑一輪 OAuth2。
幾個實際應用場景
情境一：內嵌式 AI 助手的 SaaS 產品
做一個專案管理工具，想塞進一個 AI 功能——讓使用者用自然語言說「把上週 Slack 裡提到 bug 的訊息整理成 Jira ticket」。
傳統做法是讓使用者在 App 設定頁分別連 Slack 和 Jira，各自走 OAuth2、存 token、處理重新整理。OpenConnector 的做法是：Agent 呼叫閘道的 slack.search_messages 拿到結果，再叫 jira.create_issue 建立 ticket。兩邊憑證都存在閘道，你的 App 只需要知道 action ID 和輸入輸出格式。
閘道支援「具名連線」（named connections）。如果使用者有兩個 Slack 帳號——一個工作用、一個興趣社團用——透過 x-oo-connector-alias header 指定要讀哪個帳號的資料。Agent 程式碼裡寫個 alias 引數就搞定，不用改邏輯。
情境二：開發者工具的 AI 外掛
很多開發者工具現在都在加 AI 功能，最麻煩的就是 GitHub、GitLab、Bitbucket 這些版本控制服務的整合。每個平臺的 API 格式不同、認證方式也不同。
OpenConnector 的聯結器目錄內建了 1,000 多個服務提供者——GitHub、GitLab、Bitbucket、Supabase、BigQuery、Airtable 都有。不需要自己寫每家的 API wrapper，action 的請求和回應 schema、必要許可權範圍，閘道都定義好了。
開發者工具只要對接 MCP endpoint 或 HTTP API，就能讓 Agent 讀取 repo 資訊、建立 pull request、查詢 CI/CD 狀態。未來要加新服務提供者（比如新出了個什麼平臺），去目錄裡搜尋 action ID，確認 schema 符合需求，然後在儀錶板連上帳號就行。
情境三：資料分析 Agent 的長期執行
做一個每週自動跑的 AI Agent——從 Google Analytics 抓流量資料、從 BigQuery 跑查詢、把結果寫入 Notion dashboard。Agent 可能每天跑一次，連續好幾個月。
OAuth token 通常有有效期限。傳統做法是要有個 cron job 定期重新整理 token，或者在 agent runtime 裡處理 token 過期重試的邏輯。OpenConnector 的閘道層自動管理 refresh token，agent 只需要專注在業務邏輯。token 過期了，閘道自動換新的，agent 完全不知道中間發生什麼事。
OpenConnector 有執行記錄（run logs）功能。每個 action 呼叫都會留下紀錄——輸入引數、回應結果、耗時、使用的許可權範圍。debug 和審計的時候很有用：你知道 Agent 上週三下午兩點執行了哪些 action、用了哪個帳號、回傳了什麼資料。
情境四：團隊共享的連線池
團隊有五個人，都要用同一套 AI Agent 操作公司的 Google Workspace。傳統做法是每人各自連自己的 Gmail 和 Drive，或者共用一個服務帳號（service account），但後者會失去「以個人身分執行」的能力——發郵件時顯示的是 [email protected] 而不是使用者的名字。
OpenConnector 的做法是：每個人在閘道裡各連自己的 Google 帳號，Agent 透過指定 connection alias 來選擇要用誰的帳號執行 action。連線和存取範圍只需設定一次，團隊成員不用各自配置，金鑰、權杖及憑證也不外露。
Action 合約：對 Agent 友好的介面設計
OpenConnector 有一個比較少見的設計是「Action guide」——每個 action 都有一份本地生成的 Markdown 檔案，包含輸入 schema、必要許可權範圍、服務提供者許可權說明、當前連線身分，以及請求範例。Agent 可以直接讀取這份檔案來理解某個 action 該怎麼呼叫。
curl -s http://localhost:3000/api/actions/github.get_current_user/agent.md
這個設計對 LLM-based agent 友善。傳統 API 需要查 Swagger 檔案或看程式碼才知道怎麼用，OpenConnector 的 action guide 直接給 Agent 一份人可讀的說明書。Agent 在執行前可以先讀 guide、確認許可權夠不夠、輸入格式對不對，減少無效呼叫。
每個 action 還支援冪等性（idempotency）。透過 Idempotency-Key header，相同的請求只會真正執行一次，後續重複呼叫會回傳原始結果。對於需要重試機制的 agent workflow 來說很實用——不用自己追蹤哪些請求已經成功、哪些失敗了。
缺點與限制
任何東西都有 trade-off。OpenConnector 目前比較明顯的限制：
本地 executor 覆蓋率有限。目錄裡列出的 action 會標記 locallyExecutable 或 catalogOnly，後者表示只有 schema 和 metadata，實際執行器還沒接好。需要的 action 剛好是 catalog only，可能要等上游貢獻或者自己寫 executor。
Cloudflare Workers 部署酷歸酷，D1 的效能跟傳統資料庫比還是差一截。agent 一天跑幾千次 action，D1 可能成為瓶頸。Fly.io + SQLite 的方案在資料量大的時候也面臨同樣問題——需要考慮分片或遷移到 PostgreSQL。
生態系依賴也是個事。OpenConnector 背後是 OOMOL 這個平臺，決定用他們的代管服務後，未來搬離時雖然合約一致、程式碼不用改，但 OAuth2 的 client ID 和 redirect URI 可能跟自有部署不同，需要做一些設定調整。不算大問題，值得留意。
結語
OpenConnector 解決的問題很明確：Agent 連網時，憑證管理、token 重新整理、許可權控制這些瑣事該放哪裡。「放在閘道層」——Agent 只管呼叫 action，剩下的交給 OpenConnector。
正在做 AI Agent 產品的團隊值得關注。特別是需要讓使用者長期授權第三方服務、不想自己維護一坨 OAuth token 管理程式碼的場景。部署簡單、合約開放、MCP 原生支援，這些特點加起來，讓它成為目前開源領域裡相當實用的選擇。
如果你也在處理「Agent 怎麼連網」這個問題，花十分鐘在本機用 Docker compose 跑起來試一下。docker compose up，瀏覽器開啟儀錶板連線一個 GitHub 帳號，五分鐘後就能看到 Agent 讀取 repo 資訊了。比寫程式碼快多了。