你做 AI Agent 的时候，一定碰过这个场景：Agent 说”我需要查一下你的 Gmail”，然后你花了二十分钟去 Google Cloud Console 申请 OAuth 应用、填 redirect URI、拷 client secret、写回调逻辑。等一切搞定，你已经忘了 Agent 原本要干什么。
这就是 OpenConnector 要干掉的摩擦。它把自己定位为 Pipedream 和 Composio 的开源替代方案，核心做的事就一件：连接一次你的 SaaS 账号，然后让任何 AI Agent 都能通过统一接口调用这些服务。截至 2026 年 8 月，它已经覆盖了 1000 多个 provider，预置了超过 10000 个 Action，从 GitHub 到 Gmail、从 Notion 到 BigQuery，全在同一个 catalog 里。
OpenConnector 是 OOMOL 实验室的开源项目，和它自家的 oo CLI、Wanta 桌面 Agent 组成了一套完整生态。但跟 Composio 最大的不同在于：它开源的不仅是 SDK 和 CLI，而是整个认证网关本身。你可以把它跑在自己的 Docker 里、部署到 Cloudflare Workers 上，或者直接用 OOMOL 的托管版——三种路径共享同一套 provider 和 Action 契约。
说白了，这东西能不能让你的 Agent 真正变成”万能员工”，还是只是一个精美的连接器目录？往下看。
打动我的几个地方
OpenConnector 做的不是”又一个 MCP server”，它在试图重新定义 Agent 和应用之间的认证边界。我翻了它的源码和文档，有四个设计点让我觉得这东西不是随便糊出来的。
第一个是凭证安全边界。所有 provider 的 API key、OAuth token 全部留在 runtime 后端，Agent 进程永远碰不到原始凭据。Agent 拿到的只是本次运行需要的 metadata、脱敏后的账号标签和执行结果。这个设计在处理敏感权限时尤其重要——你不需要把 Gmail 的完整读写权限交给一个刚写了三天的 Agent。
第二个是 inspectable Action 契约。每个 Action 都带着请求/响应的 JSON schema、所需的 OAuth scope、以及可审查的 executor 源码。这意味着你不再需要盲猜”调用 github.create_issue 到底需要什么权限”。打开对应的 TypeScript 源文件，从参数校验到 API 调用，每一步都有迹可循。
第三个是多接口统一暴露。同一个 catalog 可以同时通过 TypeScript SDK、MCP 协议、HTTP API、OpenAPI 和 oo CLI 五种方式访问。你用 Claude Code 就挂 MCP，用自研 Agent 就调 SDK，用 curl 测试就直接打 /v1/actions/*。所有路径的 Action id、参数 schema 和返回值结构完全一致，不需要为不同入口维护不同的胶水代码。
第四个是部署灵活度。本地 Docker 一行 docker compose up 就能跑起来；Cloudflare Workers 部署让你能用边缘节点处理请求，延迟更低；Fly.io 提供持久化 SQLite 的托管 Docker runtime。想省事直接用 OOMOL 托管版，每月赠送的 Connect 点数约能支撑 15000 到 20000 次免费调用。最关键的是，四条路径用的是同一套 provider id 和 Action 契约，后续从托管切到自托管不需要重写任何集成代码。
这张图把它的分层结构说得很清楚。Agent 或应用通过 SDK、CLI、MCP 或 HTTP 四种入口进入 Gateway，Gateway 内部把凭证管理、provider 路由、Action 执行、权限策略和运行日志拆成了五个独立模块。Provider 的真正秘钥永远留在 Gateway 右侧的运行时边界之后。
跑起来看看
自托管 OpenConnector 的前提只有一个：本地有 Docker。一条命令就能把 runtime 和 Web 控制台拉起来：
docker compose up
这条命令会从 GHCR 拉取 ghcr.io/oomol-lab/open-connector:latest 镜像，启动 runtime 和 Web 控制台。浏览器打开 http://localhost:3000，就能看到一个 Dashboard，浏览 connector catalog、配置 credential、查看运行日志。这也是 OpenConnector 比纯 CLI 工具更友好的地方——你不用记住所有 Action 的名称，在控制台里搜索、测试、看 schema，效率高得多。
跑起来之后，用一条不需要鉴权的 Action 验证 runtime 是否正常：
curl -s -X POST http://localhost:3000/v1/actions/hackernews.get_top_stories \
-H 'content-type: application/json' \
-d '{"input":{}}'
如果返回了 HackerNews 的热门文章列表，说明 runtime 已经完全可用了。接下来连接一个真正的 provider——GitHub 是最简单的起手选择，personal access token 就能走通：
curl -s -X PUT http://localhost:3000/api/connections/github \
-H 'content-type: application/json' \
-d '{"authType":"api_key","values":{"apiKey":"github_pat_..."}}'
从 clone 到跑通第一个 Action，五分钟足够了。但体验上的顺畅不代表你能无脑上生产，这里有三个常见的卡点。第一，OAuth provider 需要你自行去对应平台申请 OAuth 应用，Google 和 Slack 的审批可能需要几天到几周，这个前置成本经常被忽略。第二，当前开源 catalog 覆盖了 840 多个 provider，比托管版的 1000+ 少了一截，有些服务只在托管版可用。第三，如果你走 Cloudflare 部署，D1 和 R2 的迁移步骤比 Docker 多不少，建议先用 Docker 尝鲜再考虑上云。
对于还在选部署方案的人，三种路径的取舍值得单独摆出来看看：
简单说：追求控制权选 Docker 自托管，追求低延迟选 Cloudflare Workers，追求零运维选 OOMOL 托管。三条路之间可以随时切换——因为用的是同一套 provider id 和 Action 契约，迁移成本比大部分人想得低得多。
但选好部署方案只是第一步。真正决定要不要用的，是你的场景跟它匹不匹配。
什么时候用，什么时候别用
| 场景 | 典型用户 | 优势 | 局限 |
|---|---|---|---|
| 多 SaaS 工作流的 Agent 产品 | AI 应用开发者 | 一次连接，多 Agent 复用；凭证不入 Agent 进程 | 部分 provider 的 OAuth 审批周期长 |
| 自托管安全合规要求高的团队 | 企业 infra 团队 | 凭据全留本地，运行日志可审查 | 需要自己管理加密密钥和备份 |
| 快速原型验证 | 独立开发者 | Docker 一行起跑，五分钟接入 MCP | 开源 catalog 比托管版服务少 |
| 边缘部署 Agent 服务 | Cloudflare 用户 | Workers 运行时延迟低，D1 零运维 | 部署步骤比 Docker 多，需 wrangler 经验 |
不适用的情况：
-
你只需要连接一两个服务，而且不介意手动管理 OAuth——那直接写个简单的 MCP server 更省事，OpenConnector 的网关层对单体集成来说是杀鸡用牛刀。 -
你需要的是工作流自动化而不是 Agent 工具调用——这种情况应该去看 Pipedream 或 n8n，它们的事件触发和条件分支更适合”if-this-then-that”模式。 -
你的应用有严格的毫秒级延迟要求——OpenConnector 在 Agent 和 provider 之间多了一层网关，这个额外的网络跳数对实时场景可能有影响。
场景匹配度说清楚了，但还有一个更底层的问题：这个项目自己能不能活下来？
社区怎么样了
| 指标 | 数据 | 说明 |
|---|---|---|
| Stars | 约 4200（截至 2026 年 8 月） | 开源约 5 周即达到，增速很快 |
| 核心维护者 | 2-3 人 | Bus Factor 中风险，主要提交者为 Kevin Cui 和 l1shen |
| Open Issues | 2 个 | 维护节奏极快，但项目太新，技术债尚不明确 |
| 协议 | Apache 2.0 | 商业友好，允许闭源商用 |
项目在 2026 年 6 月底首次提交，到 8 月初已经迭代了 389 次 commit，发布了 v1.3.4。这个节奏在开源项目里算得上冲刺级别。两位核心维护者几乎每天都在提交，从飞书集成、Home Assistant 支持到 Web 控制台改进，commit 的覆盖面很广。尤其值得一提的是，v1.3.4 版本已经包含了 OAuth 安全加固和 Docker 部署优化，说明团队在快速铺功能的同时也在稳住基础设施。
但这也意味着 Bus Factor 是 2 到 3——如果 Kevin Cui 突然消失，项目的推进力会受重创。没有大公司背书，纯靠一个小团队高速运转，可持续性需要观察。
项目刚开源时在 V2EX 上有过一篇介绍帖，作者对比了它和 Nango、Composio 的差异：Nango 只提供 proxy 层，没有 Action 级别的粒度；Composio 开源了 SDK 和 CLI，但网关本身没开源。
这一点确实是 OpenConnector 最硬的差异牌：它是市面上唯一把整个 auth gateway 完全开源的同类产品。从 Star 增长曲线来看，前两周就涨到了 2000+，后三周又翻了一倍，说明口碑传播正在起作用。GitHub Issue 区的讨论目前还很少，毕竟项目才五周大，真正的社区声音要再等几个月才会成型。
值不值得跟
我对 OpenConnector 的核心判断是：它做对了一件所有 AI Agent 产品迟早要面对的事——凭证与 Agent 的分离。方向没错，但时间是它最大的变量。
翻完它的源码和 commit 历史，我最深的感受是节奏太快了。389 个 commit 在五周内完成，平均每天 10 个以上。这种速度在早期可以快速铺开 provider 覆盖，但也很容易留下技术债。比如 provider 的 Action 质量参差不齐——有些 service 的 Action 覆盖了几乎所有 API endpoint，有些只有三四个基础操作，这种不均衡在 catalog 里一目了然。
另一个需要关注的点是性能。目前没有任何公开的 benchmark 或压测数据。当你的 Agent 同时调用 10 个 provider 时，网关层的延迟会叠加到什么程度？Cloudflare Workers 的冷启动对首次调用影响多大？这些在生产环境里是关键问题，但文档里一个字都没提。
但我也不会因为这些问题就判它死刑。五周做到 4200 Stars、326 forks，这说明抓到了真实的痛点。我在它的 commit 历史里泡了半个下午，发现了一个细节：provider 的引入不是机械搬运，每个新 service 的 PR 都带着至少一个完整的 OAuth flow 实现。这意味着维护者不是在堆数量，而是在保证每个 provider 的认证路径是真正可用的。这在同类项目里并不常见。
OOMOL 的商业模式也很清晰：开源版提供核心能力，托管版收方便钱。从早期的 pdf-craft 到现在的 OpenConnector 和 Wanta 桌面 Agent，OOMOL 实验室的产品线正在从”单点工具”向”Agent 基础设施平台”演进。这种定位在商业上是合理的——开源建生态，托管做营收。对用户来说，你不需要担心某天代码突然闭源，Apache 2.0 协议保证了这一点。
只要团队不散，按现在的迭代速度，三个月后的 OpenConnector 大概率是一个可以认真考虑上生产的东西。现在的话，我建议先 Docker 跑起来玩玩，关注两个信号：Issue 数量是否开始明显增长（说明有人真正在用），以及是否有第二位核心维护者之外的活跃贡献者出现（说明社区在自生长）。
资源地址
| 资源 | 地址 |
|---|---|
| GitHub | https://github.com/oomol-lab/open-connector |
| 官方文档 | https://oomol.com/docs/openconnector-self-hosting/ |
| OOMOL 托管版 | https://oomol.com/apps |
| Connector SDK | https://github.com/oomol-lab/connector-sdk |
| oo CLI | https://github.com/oomol-lab/oo-cli |
前面的分析都在说”这个项目怎么样”，最后聊聊最实际的：你该做什么。
先跑起来，再谈生产
如果你正在做一个需要连接多个 SaaS 的 Agent 产品，花一下午把 OpenConnector 跑起来，比花一个月自己写 OAuth 胶水代码划算得多。从 GitHub 和 Gmail 开始——这两个 provider 的接入最顺畅，文档也最完整。
如果你还在观望，关注两个指标：核心维护者数量和 provider Action 质量的一致性。这两点决定了 OpenConnector 是能从一个”看起来很酷的开源网关”变成”Agent 基础设施层标配”的关键。Apache 2.0 协议没有商业隐患，等它长出第一个生产用户案例，再做决定不迟。
开源五周的东西，别急着下结论。但它正在做的事，大概率是 2026 年下半年 Agent 基础设施领域最重要的方向之一。说到底，当每个 Agent 都需要访问几十个 SaaS 工具的时候，你不可能给每个工具都手写一套 OAuth 逻辑。OpenConnector 的赌注是：这件事迟早需要一个标准化的中间层，而它想成为那个层。