AI Agent 连接 1000+ 应用,不必把密钥交出去:OpenConnector 开源了

AI Agent 越来越会“思考”，但真正让它进入工作流，最麻烦的往往不是模型，而是连接。

让 Agent 读 Gmail、查 Notion、操作 GitHub、同步 Slack，看上去只是多接几个 API。真正动手后才会发现：每个平台都有不同的 OAuth 流程、权限范围、请求格式、返回结构和限流规则；凭据如何保存、哪些动作允许执行、出了问题怎么审计，也都不能靠几段临时代码糊过去。

当 Agent 从 Demo 走向生产，“连接能力”本身就会变成一套需要长期维护的基础设施。

最近，OOMOL 团队开源了 OpenConnector。它把自己定位为面向 AI Agent 的 connector gateway，也是 Composio 的开源替代方案：用户只需连接一次应用账号，就能把一个包含 1000+ Provider、10000+ 预置 Action 的共享目录暴露给 Agent 或应用。

更重要的是，它试图解决一个经常被忽略的问题：Agent 可以调用工具，但不必直接拿到用户的密钥。

OpenConnector 到底是什么？

可以把 OpenConnector 理解成 Agent 与外部应用之间的一层“统一插座”。

Agent 不再分别适配 GitHub、Gmail、Notion、BigQuery、Supabase、Airtable、Slack 等服务，而是通过 OpenConnector 发现可用 Action、读取输入输出 Schema、选择已经授权的连接，然后执行调用。

对于上层应用，它提供了四种入口：

●Connector SDK：适合 TypeScript 应用直接集成；

●oo CLI：适合本地 Agent 搜索、查看和运行 Action；

●MCP：可以把连接器能力暴露给支持 MCP 的 Agent Host；

●HTTP / OpenAPI：适合自定义客户端和其他语言调用。

这意味着，同一套连接能力可以同时服务于桌面 Agent、开发者工具、企业工作流和 SaaS 产品，而不需要为每种运行方式重新造一遍轮子。

真正重要的，不只是“连接数量”

1000+ Provider 和 10000+ Action 很吸引眼球，但 OpenConnector 更值得关注的部分，是它把几类生产问题放进了统一运行时。

1. 凭据留在运行时边界内

API Key、OAuth Token 和连接信息由 OpenConnector 管理。Agent 获得的是执行所需的元数据、安全的账号标签和调用结果，而不是直接接触 Provider Secret。

这条边界很关键。因为 Agent 一旦同时拥有自然语言指令、外部内容和长期凭据，提示词注入、越权调用与密钥泄露的风险就会被叠加放大。

2. Action 是可以审查的契约

每个 Action 不只是一个模糊的“工具名称”，还包含请求与响应 Schema、必需 Scope，以及可按需加载、可以检查和扩展的执行器源码。

对开发团队来说，这比让模型临场猜 API 参数可靠得多。Agent 知道自己能做什么、需要什么权限，平台也更容易做验证、测试和版本管理。

3. 权限与运行记录可管理

OpenConnector 提供 Runtime Token、Action Allow/Block Policy、连接身份、权限范围和脱敏运行日志。

换句话说，你不仅能让 Agent 调工具，还能回答这些更现实的问题：

●它使用的是哪个账号？

●这次调用需要哪些权限？

●哪些 Action 被允许，哪些必须禁止？

●最近失败在哪里？

●发生异常后能否回看执行记录？

这些能力决定了一个连接器项目能不能从个人实验进入团队和生产环境。

既能自托管，也给未来留了迁移空间

OpenConnector 没有把使用者锁在单一路径里。

你可以用 Docker 或 Node.js 在本地运行，把状态保存在 SQLite；也可以部署到 Fly.io，用持久卷保存数据；还可以使用 Cloudflare Workers、D1、R2 和 Static Assets 组成轻量托管运行时。若团队暂时不想处理 OAuth 申请与基础设施，也可以使用 OOMOL 托管服务快速上线。

这些路径共享相同的 Provider ID、Action ID、Schema 和调用契约。对于团队来说，这意味着可以先借助托管能力验证产品，再迁移到私有化或自托管环境，而不是重写整套接入层。

5 分钟跑起来看看

如果只是想体验本地 Runtime，最快的方式是使用 Docker Compose：

启动后，可以打开本地控制台与 API 文档：

接着调用一个不需要鉴权的 Hacker News Action，确认运行时正常：

如果要连接 GitHub，可以先保存 Personal Access Token，再调用 github.get_current_user。需要 OAuth2 的服务，则可以继续配置 OAuth 应用、命名连接、Token 刷新与权限策略。

内置 Web 控制台也很实用：它可以浏览 Provider、配置 Credential、创建 Runtime Token、检查 Action Schema、调试调用，并查看最近的运行记录和失败情况。对于第一次理解整个链路的人，比直接啃接口文档友好得多。

它适合谁？

如果你只是做一个一次性脚本，只连接一两个固定 API，直接调用官方 SDK 可能更简单。

但下面几类项目会更适合 OpenConnector：

●正在开发需要长期访问用户工作应用的 AI Agent；

●希望在多个 Agent 或产品之间复用同一接入层；

●需要统一管理 OAuth、Scope、凭据与运行日志；

●想快速上线，又希望以后能够私有化部署；

●不愿把用户 Token 直接交给 Agent 进程。

它并不会让第三方 API 的复杂性消失，但能把复杂性集中到一个可检查、可替换、可部署的边界里。

写在最后

过去一年，行业把大量注意力放在模型、提示词和 Agent 框架上。可当 Agent 真正开始替用户收邮件、改项目、查数据、发消息时，决定体验与安全性的，往往是模型背后的连接层。

OpenConnector 值得关注，不是因为它又增加了一套“工具调用协议”，而是因为它试图把 Catalog、凭据、权限、执行与审计 放进同一套开源运行时中。

对开发者而言，这提供了一种更清晰的分工：

模型负责理解意图，Agent 负责规划步骤，OpenConnector 负责安全、稳定地触达外部世界。

项目采用 Apache License 2.0 开源。如果你正在做能真正操作用户应用的 Agent，这个项目值得放进技术选型清单。

项目地址：

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