---
author: OOMOL
author_url: https://oomol.com/zh-cn/about/
datePublished: 2026-10-13
title: OpenConnector 自部署还是 OOMOL 托管？先让业务跑起来
description: 从 OAuth 应用配置、团队权限和运行环境出发，选择 OOMOL 托管版或自部署 OpenConnector，并了解先托管、后迁移时可以复用什么。
lang: zh-CN
canonical_url: https://oomol.com/zh-cn/blog/openconnector-hosted-or-self-hosted/
markdown_url: https://oomol.com/zh-cn/blog/openconnector-hosted-or-self-hosted.md
---

![OOMOL 托管与 OpenConnector 自部署两条应用连接路径：先完成业务，再按需要掌控运行环境](/blog/openconnector-hosted-or-self-hosted/zh-cn-cover.webp)

准备把 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 官方说明](https://developers.google.com/identity/protocols/oauth2/web-server)

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

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

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

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

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

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

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

![业务后端通过同一个 SDK 包接入两种网关：OOMOL 托管环境或自行管理的 OpenConnector；网关分别管理凭据与连接，再访问第三方应用 API](/blog/openconnector-hosted-or-self-hosted/zh-cn-architecture.webp)

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

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

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

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

如果你的产品需要让每个终端用户连接自己的账号，托管侧应使用 [Connector for SaaS](/zh-cn/docs/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 自部署指南](/zh-cn/docs/openconnector-self-hosting/)。

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

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

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

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

迁移准备主要包括：

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

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

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

## 从一个真实操作开始

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

在 [OOMOL Console 连接应用](https://console.oomol.com/connections)，授权完成后，按照 [SDK 接入指南](/zh-cn/docs/connector-client/)从后端调用这个操作。先确认业务能跑通，再配置团队成员和连接权限。

已经明确需要自部署的团队，可以直接按 [OpenConnector 部署指南](/zh-cn/docs/openconnector-self-hosting/)准备环境，再完成 [OAuth 应用配置](/zh-cn/docs/openconnector-oauth-apps/)。

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