OpenConnector 中文指南：自部署 AI Agent 的 OAuth、MCP 与 1000+ 应用连接

结论

OpenConnector 适合需要自己掌控第三方凭据、OAuth 应用、动作策略和执行日志的 Agent 产品或内部工具。只想快速让 Codex、Claude Code 或 Cursor 使用 Gmail、GitHub、Notion 时，OOMOL 托管连接成本更低；自部署价值来自控制权，不是免运维。

优缺点

优点

Apache-2.0 开源，可审查并自部署
同时提供 MCP、HTTP、OpenAPI、SDK 和 Web Console
凭据、OAuth、连接身份、动作策略与日志位于自己的运行时
与 OOMOL 托管路径共享 provider 和 action 概念

缺点

OAuth 提供方通常需要自行注册开发者应用
需要维护数据库、加密密钥、备份、升级和监控
公网部署必须认真配置管理令牌、运行时令牌和动作策略

说明：OpenConnector 是 OOMOL 团队维护的开源项目。本文同时链接其 GitHub 仓库和 OOMOL 托管方案，方便按部署责任选择。

两条部署路径

要控制权，还是要更快上线？

OpenConnector 把凭据和运行时留在你的环境；OOMOL 托管版负责 OAuth、凭据刷新和连接器基础设施。

查看 GitHub 源码 → 不想自建？看 OOMOL 托管版

OpenConnector 解决什么问题

Agent 调用公开天气 API 很简单；调用用户的 Gmail、GitHub、Notion 或 Slack 完全是另一回事。系统必须知道：

用户授权了哪个账号；
当前 token 是否过期，能否刷新；
哪些 scope 和动作被允许；
这次调用由哪个 Agent 或终端用户发起；
输入、结果和失败原因如何审计；
临时文件如何传输并按时清理。

给每个 Agent 分别塞 API key，会把这些问题散落到环境变量、提示词、MCP Server 和脚本中。OpenConnector 把它们收敛为一个连接器网关：Agent 只看到服务、动作、输入结构和安全的连接身份；原始凭据由运行时使用。

它不是一个新的 AI Agent

OpenConnector 不负责写代码、规划任务或生成答案。它位于 Agent 和第三方服务之间：

Codex / Claude Code / Cursor / 自研 Agent
                     ↓ MCP / SDK / HTTP / OpenAPI
               OpenConnector Gateway
                     ↓ OAuth / API key / policy
       GitHub / Gmail / Notion / Slack / 其他服务

因此它可以同时服务多个 Agent 宿主。你可以继续使用熟悉的模型和界面，只把外部账号连接交给同一个运行时。

OpenConnector 提供的核心层

Provider 和 Action 目录

第三方服务使用稳定的 service id，例如 github、gmail、notion。每个动作有自己的输入、输出、权限范围和执行器。Agent 可以先检索动作，再读取 schema，最后构造最小输入。

这种“先检查契约再调用”的方式比让模型猜 API 参数可靠，也更适合在动作层做允许/禁止策略。

凭据与连接身份

运行时支持 API key、OAuth2、自定义凭据和无需认证的服务。一个服务可以有多个命名连接，例如个人 GitHub 和公司 GitHub；调用方应明确选择身份，而不是依赖“最近登录的账号”。

MCP、HTTP 与 OpenAPI

MCP 适合 Codex 等支持工具发现的 Agent；HTTP 和 OpenAPI 适合自研后端；Connector SDK 适合 TypeScript 应用。它们面对的是同一套动作模型，区别主要是调用入口。

Web Console 和执行记录

控制台用于浏览 provider、配置凭据、创建运行时令牌、查看动作 schema 和近期调用。生产环境需要保护控制台和管理 API，不能直接暴露一个没有管理令牌的实例。

本地启动：先验证无认证动作

官方仓库提供 Docker Compose：

git clone https://github.com/oomol-lab/open-connector.git
cd open-connector
docker compose up

启动后：

控制台：http://localhost:3000
API 文档：http://localhost:3000/docs

先调用一个不需要账号的动作，确认 runtime、catalog 和 executor 正常。随后再接入测试账号。这个顺序能把“运行时部署问题”和“OAuth 配置问题”分开排查。

接入真实账号前必须配置什么

管理令牌

只要控制台或 /api 可以从本机之外访问，就应设置管理令牌。否则任何能访问地址的人都可能修改连接和策略。

凭据加密密钥

没有加密密钥时，运行时仍可以工作，但凭据会保存在敏感数据库中。生产环境应把加密密钥放在 secret manager，不要提交进仓库。

公开 Origin

OAuth 回调必须指向浏览器能够访问的稳定域名。通过公网域名、隧道或 Workers 部署时，需要配置正确 origin，并把精确回调地址登记到 GitHub、Google、Slack 等开发者后台。

动作策略

先只允许读取类动作，再逐步开放创建、发送和更新。删除、覆盖、权限变更与公开分享应保持更严格的审批。

三种部署方式怎么选

部署方式	适合场景	主要责任
Docker / 单机	本地开发、内部小团队、快速验证	主机安全、卷备份、升级、域名与 TLS
Node.js + PostgreSQL	多实例、需要独立数据库的服务	迁移、连接池、备份、监控和滚动升级
Cloudflare Workers	已使用 Workers/D1/R2 的轻量边缘部署	D1 迁移、R2 生命周期、Secrets 和 Worker 限制

如果团队没有明确的自部署需求，先用 OOMOL 托管连接会更快。托管方案的价值不是“代码更少”这句口号，而是 OAuth 应用、token 刷新、凭据存储和运行基础设施有人负责。

OpenConnector、OOMOL Connector 和 Connector SaaS

方案	账号属于谁	运行时由谁维护	典型用途
OpenConnector	自己或内部团队	你	内部 Agent、自有基础设施、私有网络
OOMOL Connector	你的个人/团队连接	OOMOL	在多个 Agent 中快速使用已授权应用
Connector for SaaS	你的终端用户	OOMOL	SaaS 产品让每位用户连接自己的账号

SaaS 多租户场景不能简单共用一个个人连接。每个终端用户需要独立的外部用户标识、授权请求和连接记录，这也是 Connector for SaaS 与个人连接的关键区别。

与 Pipedream Connect、Composio 的比较方法

不要只比较 provider 数量。更有用的问题是：

你需要的具体 action 是否存在，输入输出是否稳定？
OAuth 应用、凭据、刷新和审计由谁负责？
是否支持多个连接身份与终端用户隔离？
能否限制 Agent 看到和执行的动作？
是否能从托管迁移到自有运行时？
触发器、工作流编排和自定义代码是否属于你的需求？

OpenConnector 的优势是开源运行时和多种调用入口。Pipedream 或其他平台可能在事件触发、可视化工作流和既有生态上更成熟。最终选择应由具体工作流和运维能力决定。

适合与不适合

适合 OpenConnector：

企业内部 Agent 需要访问私有账号和系统；
团队要求凭据、日志和策略留在自己的环境；
产品需要 MCP 与普通 HTTP 客户端共享同一套动作；
已经有平台工程能力维护数据库、Secret、OAuth 和升级。

更适合托管方案：

个人开发者只想让 Codex 读取 Gmail 或操作 GitHub；
产品还在验证阶段，连接器不是核心差异化能力；
团队不想维护 OAuth 应用和 token 刷新；
当前目标是几天内跑通，而不是长期控制运行边界。

最终建议

先把一个只读工作流跑通，例如“读取本周 GitHub PR 并生成摘要”。如果这个工作流值得长期使用，再决定由 OOMOL 托管，还是把 OpenConnector 部署进自己的环境。安全边界、运维责任和连接身份比 provider 数量更值得优先确认。

开始验证

用一个测试账号和只读动作开始

先检查动作 schema、连接身份与返回结果，再逐步开放写操作。

打开 OpenConnector 仓库 → 查看 OOMOL Connector 产品地图

FAQ

OpenConnector 和 MCP Server 有什么区别？

MCP Server 是 Agent 调用工具的一种协议入口；OpenConnector 是连接器运行时，除 MCP 外还负责凭据、OAuth、连接身份、动作策略、日志，并提供 HTTP、OpenAPI 和 Web Console。

OpenConnector 可以部署到 Cloudflare 吗？

可以。官方仓库提供 Workers、D1、R2 和 Static Assets 路径。团队需要自行创建资源、应用迁移、设置加密与管理令牌，并配置 OAuth 回调域名。

自部署后还需要 OOMOL 账号吗？

运行开源 OpenConnector 本身不依赖 OOMOL 托管账号。你需要自己配置运行环境和第三方服务凭据；若改用 OOMOL 托管连接，则通过 OOMOL Console 管理授权。

OpenConnector 能直接替代 Composio 或 Pipedream 吗？

它覆盖连接器网关、动作目录、凭据与 OAuth、MCP/HTTP 接口等核心场景，但产品范围、现成触发器、工作流编排和托管体验并不完全相同。应按具体动作、认证方式和部署责任逐项比较。

OpenConnector 中文指南：给 AI Agent 自建 OAuth 与 MCP 连接层

结论

优缺点

优点

缺点