硅基铁匠AI / 系统 / 写作
← 返回全部文章
技术与 AI约 7 分钟

OpenConnector：让 AI Agent 一次接入 1400+ 个 SaaS 服务

接 GitHub、Gmail、Notion、Slack 这类服务时，不必每次都重写 OAuth 和 API。OpenConnector 把账号、权限、Action 和执行接口放到一个网关里。

让 AI Agent 调用 Gmail 、 GitHub 、 Notion 或 Slack，麻烦往往不在模型，而在接入这些服务的重复工作：OAuth 、 Token 、权限范围、请求参数、返回结果，每家服务都不一样。

OpenConnector 想处理的就是这一层。它提供一个连接器网关，用户把 SaaS 账号接进去，Agent 再通过统一的 Action 调用外部服务。

项目目录当前显示约 1400 多个服务和 15000 多个预置 Action 。这个数字会随着目录更新变化，但它说明了一件事：你面对的已经不是“再写一个 API 适配器”，而是一套可复用的连接层。

它到底接在什么位置

可以把一次调用想成这样：

AI Agent / 应用
       ↓ SDK、CLI、MCP 或 HTTP
OpenConnector Gateway
       ↓ 账号、权限、Action 策略
GitHub、Gmail、Notion、Slack 等服务

Agent 不需要拿着所有平台的原始密钥到处跑。 OpenConnector 在网关里保存连接信息，检查这次调用能不能做，再执行对应的 Action，把结果返回给 Agent 。

仓库把同一套 provider id 、 Action id 、请求响应结构同时暴露给几种入口：

  • Connector SDK：从 TypeScript 应用里调用；
  • oo CLI：给本地 Agent 搜索、查看和执行 Action；
  • MCP：给支持 MCP 的 Agent 主机使用；
  • HTTP / OpenAPI：给脚本、自定义客户端和其他系统接入；
  • Web Console：浏览连接器、配置账号、查看运行记录。

这比单独给每个 Agent 加插件更容易管理。 Agent 看到的是可检查的 Action 说明、参数结构和权限范围，账号密钥留在运行时边界内。

能做什么

先查，再执行

每个 Action 都有自己的输入输出结构，通常还会标明需要哪些权限。 Agent 可以先搜索“发送邮件”这样的能力，再查看具体 Action 的参数，最后执行请求。

这一步很重要。让模型直接猜接口字段，失败时很难判断是权限错了、参数错了，还是服务本身返回了错误。可检查的 schema 和 Action guide，至少把这部分信息摆在明面上。

一次连接，多种调用方式

同一个 GitHub 连接，可以从 SDK 、 CLI 、 MCP 或 HTTP 入口调用。换 Agent，或者把一次性脚本改成后台任务时，不必重新实现整套认证逻辑。

例如，仓库提供的 CLI 路径大致是：

oo connector login http://localhost:3000
oo connector search "send an email"
oo connector schema gmail.send_email
oo connector run gmail --action send_email --data '@payload.json'

这几行展示的是调用路径，不代表接上 Gmail 后就能无条件发邮件。你仍然需要正确配置 Gmail 的 OAuth 应用、回调地址和权限范围。

管理不同账号

一个服务可能有多个账号，比如个人 GitHub 和公司 GitHub 。 OpenConnector 支持给连接设置名称，Action 调用时选择对应的连接。

MCP 使用 connectionName，HTTP 可以用连接别名。运行时不会因为你指定的账号不存在，就悄悄切换到另一个账号。这种“宁可报错，也不替你换账号”的行为，对自动化任务很有用。

给 Token 限制范围

运行时 Token 可以限制能执行哪些 Action 、能访问哪些 provider，以及能使用哪些连接。比如，一个只负责读取工单的 Agent，没有必要同时拿到发邮件、改仓库和访问财务系统的权限。

项目还提供 allow/block 策略和 provider proxy 权限。权限配置要分开看，能执行某个 Action，不等于能访问所有上游服务。

本地跑起来要准备什么

仓库支持用 Docker Compose 启动，也支持 Node.js 开发模式。最短的本地开发路径是：

npm install
npm run dev

开发环境默认使用 Node.js 22 或更新版本。启动后可以打开：

http://localhost:3000
http://localhost:3000/docs

首次验证可以调用 Hacker News 的无账号 Action，不需要先配置 OAuth：

curl -s -X POST http://localhost:3000/v1/actions/hackernews.get_top_stories \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

也可以直接用 Docker Compose：

docker compose up

要接入 GitHub 、 Gmail 这类需要登录的服务，就要继续配置 API Key 或 OAuth 。自托管模式下，OAuth 服务通常需要你自己在对应平台创建 OAuth App，并把正确的回调地址填回去。

账号和数据放在哪里

这部分比“支持多少服务”更值得先看。

Node.js 运行时默认把连接、 OAuth 配置、运行 Token 、最近的运行记录等状态放进 SQLite，也可以切换到 PostgreSQL 。临时文件可以使用本地目录或 S3 兼容存储。 Docker 部署时，数据目录需要挂载持久化卷，否则重建容器可能丢状态。

项目支持设置 OOMOL_CONNECT_ENCRYPTION_KEY，用 AES-256-GCM 加密凭据、 OAuth 配置和一部分幂等响应数据。如果不设置这个密钥，运行时仍然可以启动，但敏感记录会以明文保存。密钥丢失后，加密记录也无法恢复。

另外，服务默认绑定在 127.0.0.1。只有在确实需要外部访问时，才考虑改成 0.0.0.0，并同时配置管理员 Token 、运行时 Token 、 HTTPS 和网络访问限制。

适合谁，不适合谁

如果你在做一个需要访问用户工作软件的 Agent，OpenConnector 很有吸引力。你可以把“账号授权”和“Action 执行”从业务代码里拆出去，先用 MCP 或 SDK 接入，后面再换成 HTTP 或自定义客户端。

如果你只是想偶尔查一次 GitHub，或者只需要调用一个固定 API，直接使用官方 SDK 往往更简单。 OpenConnector 的收益要在多个服务、多个账号、多个 Agent 或需要权限管理时才会显现。

还要留意三个现实边界：

  1. 连接器数量多，不等于每个 Action 都适合生产环境。仍然要检查权限、输入参数和错误处理；
  2. 自托管不等于没有运维。数据库、加密密钥、 OAuth App 、 Token 、备份和公网暴露都需要自己负责；
  3. Agent 获得了执行接口，不代表它应该自动执行高风险动作。发邮件、改仓库、删除数据这类操作，最好单独限制权限，并保留人工确认。

OpenConnector 的价值在于把大量 SaaS 接入工作收拢到一个可以检查、限制和替换的运行时里。对刚做第一个 Agent 的人来说，先用无账号 Action 跑通流程，再接一个低风险账号，会比一次性把所有服务都连上更稳。

项目地址：

https://github.com/oomol-lab/open-connector