做一个能聊天、能写代码的 AI Agent 并不难。真正让它进入工作流程，难点往往出现在下一步：怎样连接 Gmail、Notion、Slack、GitHub、Google Sheets 和内部系统？
每接一个服务，都要处理 API、OAuth、Token 刷新、权限范围、参数结构、错误重试和日志。连接数量从几个增加到几十个之后，如果这些逻辑散落在不同 Agent 和脚本里，维护成本会迅速上升，凭据泄露风险也会随之增加。
OOMOL Lab 开源的 OpenConnector，就是为这层连接问题准备的。
一句话定位
OpenConnector 是一个面向 AI Agent 的开源连接网关：用户账号只连接一次，Agent 就能通过 SDK、CLI、MCP、HTTP 或 OpenAPI 调用统一的 SaaS Action。
它把凭据、OAuth、权限、Action 契约和运行日志集中放在一个可检查的运行时里。Agent 负责选择和调用工具，但不需要直接持有 Gmail、GitHub 或 Notion 的原始 Token。
基础信息
| 项目 | 信息 |
|---|---|
| 项目名称 | OpenConnector |
| 开源团队 | OOMOL Lab |
| GitHub | oomol-lab/open-connector |
| 项目定位 | 面向 AI Agent 的开源 Connector Gateway |
| Provider / Action | 1000+ Provider、10000+ 预置 Action |
| 接入方式 | SDK、CLI、MCP、HTTP、OpenAPI |
| 部署方式 | Docker、Node.js、Fly.io、Cloudflare、OOMOL 托管 |
| 技术栈 | TypeScript、Hono、SQLite / D1 / R2 |
| 开源协议 | Apache-2.0 |
| 最新版本 | v1.3.3（截至 2026 年 7 月 31 日） |
项目官方将它定义为 Composio 的开源替代方案。当前目录覆盖 GitHub、Gmail、Notion、BigQuery、Google Analytics、Supabase、Airtable、Slack 等常见服务。
它解决了什么问题
1. Agent 不应该直接保管所有账号凭据
最简单的工具接入方式，是把 API Key 或 OAuth Token 直接配置给 Agent。但这样做会让模型进程、插件和脚本接触大量敏感凭据，也很难统一控制某个 Agent 可以调用哪些服务、使用哪个账号。
OpenConnector 把 Provider Secret 留在运行时边界内。Agent 看到的是可用 Action、参数 Schema、所需 Scope、安全的账号标签和执行结果，而不是原始 Token。
2. 每个 SaaS 的接口差异太大
不同服务的鉴权方式、参数格式和返回结构差异明显。即使都支持 OAuth，申请应用、回调地址、Scope 和 Token 刷新方式也不完全一样。
OpenConnector 用统一的 Provider Catalog 和 Action 契约描述这些差异。Agent 可以先发现 Action、检查输入输出 Schema 与权限，再通过同一套调用方式执行。对上层 Agent 来说，连接新服务不再等于重新写一套完整适配层。
3. 工具接入需要可检查、可治理
当 Agent 可以发邮件、改文档、查询数据甚至操作生产系统时，“能调用”只是第一步。团队还需要知道：它用了哪个连接、执行了什么 Action、是否被允许、最近是否失败，以及调用记录能否追踪。
OpenConnector 提供运行时 Token、Scope、Action 允许/阻止策略、Provider Proxy 策略、临时文件中转和脱敏运行日志。这让工具访问从零散脚本变成一个相对集中的控制面。
核心功能
统一连接 1000+ Provider
官方目录提供 1000+ Provider 和 10000+ 预置 Action。除了常见的工作应用和开发者工具，还覆盖数据平台、营销系统、通信服务与 AI 服务。
每个 Provider 可以声明 API Key、OAuth2、自定义凭据或无需鉴权等连接方式，并公开对应 Action 的请求参数、返回结构和权限要求。
五种接入路径
OpenConnector 不要求所有 Agent 都采用同一种协议：
- 应用代码可以使用 Connector SDK；
- 本地 Agent 可以通过
oo CLI中继； - 支持 MCP 的 Agent Host 可以连接
/mcp； - 自定义服务可以直接调用 HTTP API；
- 其他客户端可以读取自动生成的 OpenAPI 文档。
同一套 Provider ID、Action ID 和 Schema 可以在开源自托管版本与 OOMOL 托管版本之间复用。
本地 Web 控制台
项目内置 Web Console，可以浏览 Provider、搜索 Action、配置 API Key 或 OAuth Client、创建运行时 Token、查看 Action Schema、调试调用并检查最近的运行记录。
对于需要运营和排查 Agent 工具调用的团队，这比只在配置文件里维护连接更直观。
多种部署方式
OpenConnector 可以在本地通过 Docker 或 Node.js 运行，也支持 Fly.io 和 Cloudflare：Workers 负责运行时，D1 保存状态，R2 处理中转文件，Static Assets 承载控制台。
如果不想自己申请和维护各平台的 OAuth 应用，也可以使用 OOMOL 托管连接器。需要注意的是，自托管版本虽然包含 OAuth 流程、凭据存储和 Token 刷新，但 OAuth 应用仍需要自行向各个 Provider 申请。
安全边界必须配置
OpenConnector 管理的是账号凭据和真实业务数据，不能把默认本地开发配置直接暴露到公网。
至少需要完成三项设置：
- 配置
OOMOL_CONNECT_ENCRYPTION_KEY，让本地凭据、OAuth Client 配置和部分敏感响应使用 AES-256-GCM 加密； - 配置
OOMOL_CONNECT_ADMIN_TOKEN，保护 Web Console、管理 API 和文档； - 使用运行时 Token、Action Allow/Block 和 Proxy 策略，把每个 Agent 的权限限制到真正需要的服务。
如果不设置加密密钥，项目仍能用于本地开发，但凭据和相关敏感记录会以明文保存在 SQLite 或 D1 中。加密密钥也不会由 OpenConnector 保存，丢失后已加密数据无法恢复。
适合谁
正在开发 Agent 产品的团队，可以用它统一管理用户对 Gmail、Slack、Notion、GitHub 等服务的授权。
需要私有化部署的企业，可以把凭据、运行日志和权限策略保留在自己控制的基础设施里。
使用 MCP 的开发者，可以把一套共享的 SaaS Action 目录暴露给多个 Agent Host，而不必为每个服务单独维护 MCP Server。
正在评估 Composio 等连接平台的团队，可以用 OpenConnector 验证自托管连接网关是否符合自己的成本、合规和扩展需求。
快速上手
最省事的方式是使用官方预构建镜像：
git clone https://github.com/oomol-lab/open-connector.git
cd open-connector
docker compose up启动后打开：
http://localhost:3000
http://localhost:3000/docs先运行一个不需要鉴权的 Hacker News Action，验证运行时：
curl -s -X POST http://localhost:3000/v1/actions/hackernews.get_top_stories \
-H 'content-type: application/json' \
-d '{"input":{}}'确认运行正常后，再配置加密密钥和管理 Token，并从 GitHub 这类支持 Personal Access Token 的 Provider 开始测试。涉及 OAuth2 时，需要先在对应平台创建 OAuth 应用，再把 Client ID、Client Secret 和回调地址写入 OpenConnector。
结论
OpenConnector 的核心价值，不只是提供了一个很大的连接器目录，而是把 Agent 与 SaaS 之间最容易失控的部分集中起来：凭据、OAuth、权限、Action 契约和运行记录。
当连接范围从少量固定 API 扩展到多个服务后，一个独立网关可以让多个 Agent 复用同一套能力，也让安全策略和运行排查有明确落点。
如果你正在构建需要访问大量外部服务的 Agent，OpenConnector 值得从本地 Docker 环境开始验证。先跑通无鉴权 Action，再连接测试账号；完成加密、鉴权和最小权限配置后，再进入真实业务。
