OpenConnector

为什么需要

做海外 SaaS 产品的 AI Agent 功能时，最大的一道坎是「让 Agent 安全访问用户已有的工作账号」。每个 SaaS 各家有各家的 OAuth、scope、限流和回调，结果就是一款 AI 产品上线光做集成就能搭进去半年。

OpenConnector 把这一堆脏活封装成一张可搜索的目录：用一次配置帮用户绑定一次 GitHub / Gmail / Notion / Supabase 等账号，Agent 只调用统一的 Action ID 和请求/响应 schema 就能用，主程序不必再为每个 SaaS 手写一遍 OAuth 客户端。

怎么用

1. 本地起一个运行时：克隆仓库后跑 docker compose up 或 pnpm dev，默认监听 http://localhost:3000，自带 Dashboard。
2. 连接第一批应用：在 Web Console 里选 SaaS 厂商、填 OAuth Client，走一次标准授权流程。凭据存在运行时本地的加密存储里，Agent 进程拿不到明文 token。
3. 从 Agent 调用：
   • 脚本：import { OpenConnector } from '@oomol/connector-sdk'; await client.run('gmail.send', { to: 'a@b.com', subject: 'hi' })
   • MCP：从 MCP 客户端连接 http://localhost:3000/mcp，立刻获得所有 Action 的工具列表
   • CLI：oo connector run gmail.send --input '{"to":"a@b.com"}'，把连接能力赋给本地 Agent
4. 生产部署：推到 Fly.io + 持久化 SQLite，或部署到 Cloudflare Workers + D1/R2，或者直接用 OOMOL 官方托管版跳过运维。

界面

自带一个本地 Dashboard 用于浏览 Connector 目录、配置凭据、签发 Runtime Token、查看运行记录。所有 action 都允许先 dry-run 后再 commit。

使用案例

• 一个人做海外 SaaS 的客服 Agent：连接 Intercom + Zendesk + Notion，从一个 runtime 输出三套 Action；比每个 SaaS 都自己实现 OAuth 节省大约 4-6 周开发时间。
• 小团队做内部 AI 助理 Slack Bot：一次部署 OpenConnector，团队成员在自己的 Slack/GitHub/Linear 账号上授权一次，Bot 用 Runtime Token + scope policy 控制每条 Action 的访问范围，省去 Bot 自己维护凭据的成本。
• 做 MCP 工具市场的早期产品：直接拿 OpenConnector 的 Action schema 当底层目录，再包装一层 MCP 转接就能上线，省去自己对接 100+ SaaS 的工作量。

注意事项

• 完全开源（Apache-2.0），不需要付费。但如果你用 OOMOL 官方托管，会按 connection / action 调用计费。
• OAuth flow 仍然要求你为每个 SaaS 厂商注册开发者 Client ID，首次使用得去对应厂商的开发者后台申请。
• 一些偏小众的 SaaS 暂时只支持 API Key 模式，没有 OAuth；这类连接的安全完全取决于你 Runtime Token 的策略。
• 海外 SaaS 是默认库（GitHub / Slack / Linear / Salesforce…），国内厂商需要自己再二次封装。