OpenConnector 自部署还是 OOMOL 托管？先让业务跑起来

准备把 Google、Zoom、monday.com 接入应用或 Agent 时，你可能会先想到：OpenConnector 已经开源了，要不要直接部署一个自己的网关？

自己的网关有明确价值。凭据存在哪里、允许哪些操作、怎样记录调用，都可以由团队掌控。但连接服务跑起来以后，还有一件容易低估的事：为各个应用准备授权配置。

对于大多数希望尽快上线的团队，我们建议先用 OOMOL 托管版，通过 SDK 完成业务接入。 如果已经明确要求连接服务和凭据留在自己的基础设施，或者需要修改网关和连接器实现，就选择自部署 OpenConnector。

也可以分阶段推进：先用托管版跑通业务，同时准备自己的 OAuth 应用，条件成熟后再迁移。

先看你现在需要什么

现在的需求	建议选择
希望尽快接入应用，允许使用外部托管服务	从 OOMOL 托管版开始
多人共享应用连接，需要集中管理成员和操作权限	使用 OOMOL 托管版的团队功能
计划使用自己的 OAuth 应用，目前仍在准备配置或等待审核	先托管，准备完成后再评估迁移
凭据、连接网关和执行记录必须留在自己的基础设施	自部署 OpenConnector
需要修改连接器代码、定制网关行为或控制出站网络	自部署 OpenConnector

企业规模可以影响这个决定，但更直接的问题是：你的团队现在需要多少控制权，又准备承担多少维护工作？

自部署的工作，往往从 OAuth 配置开始

通过 Docker 启动 OpenConnector 后，你已经有了连接网关。要让它访问需要 OAuth 授权的服务，还需要在对应服务的开发者后台创建自己的 OAuth 应用。

这里有两份不同的配置：OAuth 应用的 Client ID、Client Secret 用来识别你的应用；用户完成授权后取得的访问令牌，用来访问这个用户允许开放的资源。

前一份需要你先准备好，后一份才会在账号授权后产生。

以 Google 为例，你需要创建项目、启用所需 API、创建 OAuth 客户端、填写回调地址，并确定应用需要申请哪些权限。根据权限范围和使用方式，还可能涉及应用验证。Google OAuth 官方说明

其他 OAuth 服务也有各自的配置和分发规则。连接一个应用时，这些工作可能还容易处理；同时连接多个应用后，就需要分别维护各家的客户端配置、回调地址、授权范围和审核状态。

内部测试与面向大量客户开放，要求也可能不同。有些服务允许先连接自己的账号或测试用户，有些使用场景需要管理员批准或额外审核。具体要求应以服务商的后台和文档为准。

OpenConnector 提供了保存 OAuth 配置、连接账号和执行操作的能力。使用自己的 OAuth 应用时，创建应用和满足服务商要求的工作仍需要团队负责。具体步骤可以参考 OAuth 应用配置指南。

用托管版，把时间留给业务接入

如果当前目标是让一个功能上线，比如查询日历、整理邮件或更新项目记录，通常可以先把业务所需的连接跑通。

对于支持托管 OAuth 应用的集成，OOMOL 可以减少你逐家创建和维护 OAuth 应用的工作。你仍需连接自己的账号、批准所需权限；使用 API key 或其他认证方式的服务，也需要按要求提供相应配置。

账号连接完成后，OOMOL 托管服务负责凭据保存、令牌刷新和实际的应用调用。你的后端通过 SDK 选择连接、提交参数并接收结果，不需要把第三方账号的原始令牌放进业务代码或 Agent 提示词里。托管 Connector 使用说明

图：两种部署方式的调用关系。网关的位置和管理责任不同，访问外部应用仍受服务商授权与网络条件限制。

多人使用时，托管版的价值还包括团队管理。管理员可以集中管理成员，为每个连接设置允许执行的操作，再决定哪些成员能使用这个连接。

例如，同一个邮箱账号可以建立两个连接：一个只允许读取邮件，分配给需要查阅信息的成员；另一个允许发送邮件，只分配给负责对外沟通的成员。成员使用获准的操作，无需拿到邮箱的原始访问令牌。团队与连接权限说明

这些能力让团队在接入多个应用后，能够继续管理谁可以使用什么。具体数据能否访问，还受到原应用账号权限和授权范围的限制。

如果你的产品需要让每个终端用户连接自己的账号，托管侧应使用 Connector for SaaS 和对应的 ProjectConnector 客户端，按用户隔离连接。

需要自己掌控运行环境时，选择 OpenConnector

有些团队从一开始就有明确要求：第三方账号凭据必须由自己的密钥和存储保护，连接网关必须运行在企业网络中，执行记录也必须按内部规则保存。

这类要求直接决定了部署方式。自部署 OpenConnector 后，团队可以管理网关、凭据、操作策略和运行记录，也可以控制数据库、备份、升级和网络访问。

OpenConnector 的开源价值也体现在代码层面。连接运行时、连接器定义与操作执行代码、Web 控制台都有公开源码，配套的 Connector SDK 和 oo CLI 也开放源码。需要审查调用过程、增加集成或调整实现时，可以从现有项目开始。第三方服务的 API 授权和使用条款仍需单独遵守。

这些控制权同时意味着维护责任。团队需要有人负责密钥管理、访问保护、更新、备份和故障处理。安全效果取决于这些工作如何落实。

部署可以按环境选择：

• Docker Compose：在自己的服务器或企业网络中运行，适合需要自行管理存储和访问边界的团队。
• Cloudflare Workers：自行管理 OpenConnector 部署，使用 Cloudflare 的 D1、R2 等基础设施，适合接受云平台运行环境的团队。
• 源码运行：适合开发连接器、调试或修改 OpenConnector 实现。

Cloudflare 属于云部署方案。严格要求在企业内网运行时，应选择符合要求的服务器环境。

网关部署在内网，也需要按业务要求规划出站访问。调用 Google、Zoom 等外部 SaaS 时，仍需访问相应的 API 和授权端点；完全隔绝外网的环境，需要先确认目标服务是否存在可访问的内部接口。

部署步骤见 OpenConnector 自部署指南。

可以先托管，准备好后再迁移

如果你已经计划使用自己的 OAuth 应用，却还在整理配置或等待审核，可以先把两件事分别推进：用托管版验证业务，同时准备自部署需要的应用凭证和运行环境。

托管与自部署使用同一个 @oomol-lab/connector SDK 包。它提供面向托管服务的 Connector、面向产品终端用户的 ProjectConnector，以及面向自部署运行时的 OpenConnector。这些客户端共享操作类型和调用约定，但鉴权方式、账号边界和可用方法有所不同。TypeScript SDK 参考

迁移时，已支持操作的标识、输入参数和调用方式可以继续复用。例如，一段搜索邮件的业务逻辑，可以保留相同的操作名称和查询参数，改用连接自部署运行时的客户端执行。

迁移准备主要包括：

1. 在新环境部署并保护 OpenConnector，配置自己的 OAuth 应用。
2. 在新环境建立账号连接，确认需要的授权范围。
3. 调整 SDK 客户端、服务地址、运行时令牌和连接选择。
4. 核对目标操作的执行支持，以及业务依赖的团队、项目用户和权限功能。
5. 先验证一个常用操作，再逐步切换其他调用。

账号连接和托管管理功能需要分别处理。共用 SDK 带来的便利，是能够保留已经写好的操作调用与参数结构，减少重新接入各家 API 的工作。

迁移也不必成为每个团队的必经阶段。如果托管版持续满足业务和管理要求，可以继续使用；当控制运行环境成为明确需求时，再接管网关。

从一个真实操作开始

如果目前没有必须自部署的要求，先选一个你希望上线的功能：读取今天的日历，搜索客户邮件，或者查询项目进度。

在 OOMOL Console 连接应用，授权完成后，按照 SDK 接入指南从后端调用这个操作。先确认业务能跑通，再配置团队成员和连接权限。

已经明确需要自部署的团队，可以直接按 OpenConnector 部署指南准备环境，再完成 OAuth 应用配置。

选择适合当前需求的起点。托管服务帮助你尽快完成业务，开源 OpenConnector 则让你在需要时掌控连接服务的代码、凭据与运行环境。