OpenConnector - 开源 AI Agent 认证网关

解决什么

AI Agent 调用用户的 GitHub、Gmail、Notion、Slack 等 SaaS 应用时,传统方案要么把 API Key 直接交给 Agent 进程(安全风险),要么每个应用单独实现 OAuth 流程(重复造轮。OpenConnector 提供统一的认证网关:用户在网关完成一次授权,Agent 通过标准化的 Action ID 调用,凭据和权限范围(Scope)留在网关内,Agent 只拿到执行结果和安全的账号标识,既保护隐私又简化集成。

为何火

项目上线12天即获 1200+ stars,核心原因是踩中 AI Agent 产品化的痛点:Composio 等商业方案按调用量收费且数据托管在第三方,开发者需要开源替代。OpenConnector 提供 Apache-2.0 协议的完整方案,包含 1000+ 预置连接器、OAuth 处理、MCP 协议支持(可直接接入 Claude Desktop 等 Agent 宿主)、可视化控制台,且兼容 Cloudflare Workers 边缘部署,满足从本地开发到生产自部署的全链路需求。

核心功能

统一认证层:支持 API Key、OAuth2、自定义凭据和无认证类型,用户在 Web 控制台完成授权,网关生成连接别名(Connection Alias)供 Agent 引用,凭据加密存储在 SQLite 或 Cloudflare D1。

标准化 Action 合约:每个操作(如"发送 Slack 消息""查询 BigQuery")都有固定的 Action ID、请求/响应 JSON Schema、所需 Scope 清单,Agent 通过 ID 调用无需关心底层 API 差异。

多协议接入:提供 Connector SDK(TypeScript HTTP 客户端)、oo CLI(本地 Agent 中继)、MCP 服务器(暴露为 /mcp 端点)、原生 HTTP API 和 OpenAPI 文档,覆盖不同技术栈。

运行时管控:支持 Runtime Token 鉴权、Action 白名单/黑名单策略、临时文件中转、脱敏日志记录,控制台可查看调用趋势和失败详情。

灵活部署:本地 Docker/Node.js、Fly.io 持久化 SQLite、Cloudflare Workers + D1/R2,或使用 OOMOL 官方托管服务(商业版)。

安装

Docker Compose(推荐):

git clone https://github.com/oomol-lab/open-connector.git
cd open-connector
# 编辑 docker-compose.yml 填入环境变量:
# OOMOL_CONNECT_ORIGIN=http://localhost:3000
# OOMOL_CONNECT_ENCRYPTION_KEY=生成32字符随机密钥
# OOMOL_CONNECT_ADMIN_TOKEN=管理员令牌
docker compose up -d

访问 http://localhost:3000 打开控制台,用 ADMIN_TOKEN 登录。

Node.js 源码运行:

npm install
npm run build
OOMOL_CONNECT_DATA_DIR=./data npm start

Cloudflare Workers 部署:项目提供 wrangler.toml 配置,需创建 D1 数据库和 R2 存储桶,适合需要全球边缘节点的场景。

适合谁

AI Agent 产品团队:需要让 Agent 安全调用用户的工作应用(Notion、Jira)、开发工具(GitHub、Linear)、数据平台(Supabase、Airtable)的 SaaS 产品,避免每个集成单独处理 OAuth。

企业私有化部署:金融、医疗等行业要求 API 凭据不出内网,可自部署 OpenConnector 网关,用户授权和调用日志留在本地 SQLite。

开源项目集成:需要 MCP 协议支持的 Agent 框架(如 Claude Desktop、Continue.dev),可直接将 OpenConnector 作为 MCP 服务器挂载。

不适合:纯单机 Agent 工具(无需多用户凭据管理)、已有成熟 OAuth 基础设施的大厂(迁移成本高)。

社区评价

暂无足量社区公开讨论,以下为基于项目本身的中立评估:

项目在 GitHub 快速积累关注度,topics 覆盖 ai-agents、mcp、oauth、self-hosted 等热门标签,显示开发者对 Agent 工具链标准化的需求。Apache-2.0 协议降低商用顾虑,TypeScript 技术栈和 Cloudflare Workers 兼容性吸引前端和 Serverless 开发者。

潜在争议点:1) 项目仅上线12天,生产稳定性待验证;2) 1000+ 连接器的维护成本高,部分冷门 SaaS 的 Action 可能滞后于官方 API 更新;3) 自部署需手动申请各应用的 OAuth Client ID,初始配置门槛不低。

正面信号:提供 Web 控制台降低使用门槛,MCP 协议支持顺应 Anthropic 推动的 Agent 互操作标准,Cloudflare Workers 部署方案适合国内开发者(Workers 在国内可访问)。

选型对比

vs Composio(对标商业工具):

• Composio 按 API 调用量收费,数据托管在其服务器,提供更多开箱即用的 AI 框架集成(LangChain、CrewAI)和预置 Workflow。
• OpenConnector 开源免费,数据自控,但需自行部署和维护,连接器更新依赖社区贡献,缺少商业支持。
• 取舍:预算有限或数据敏感选 OpenConnector;追求省心和企业 SLA 选 Composio。

vs Zapier/n8n(工作流自动化):

• Zapier/n8n 面向业务人员的可视化工作流,OpenConnector 面向开发者的 API 网关,后者更适合嵌入 Agent 产品而非独立自动化场景。
• OpenConnector 提供 JSON Schema 和 OpenAPI 规范,便于 LLM 动态生成调用代码;n8n 的 Node 定义更偏人类可读。

vs 自建 OAuth 代理:

• 自建需处理每个 SaaS 的 OAuth 流程差异、Token 刷新、Scope 管理,OpenConnector 提供统一抽象和预置连接器库。
• 自建灵活度更高,但开发和维护成本是 OpenConnector 的数倍。

已知坑

OAuth 应用审核:部分 SaaS(如 Google Workspace、Microsoft 365)要求 OAuth 应用通过安全审核才能访问用户数据,自部署时需以企业身份申请 Client ID,个人开发者可能卡在审核环节。

连接器覆盖度:虽宣称 1000+ 提供商,但 Action 数量和质量参差不齐,冷门 SaaS 可能只有基础 CRUD 操作,复杂业务逻辑需自行扩展 Executor 源码(项目支持自定义 Action)。

加密密钥管理:OOMOL_CONNECT_ENCRYPTION_KEY 用于加密存储的凭据,丢失后已授权连接无法解密,生产环境需接入密钥管理服务(如 Vault)而非环境变量硬编码。

MCP 协议版本:项目支持 MCP 但未明确协议版本号,Anthropic 的 MCP 规范仍在演进,可能存在与特定 Agent 宿主的兼容性问题,建议先在测试环境验证。

中国网络环境:OAuth 授权流程中的回调地址(Redirect URI)需能被 SaaS 提供商访问,自部署在内网时需配置公网入口或使用 Cloudflare Tunnel;部分国外 SaaS 的 OAuth 端点在国内访问不稳定,建议部署节点选择境外或使用代理。