Zoom RTMS vs 会议 Bot：实时媒体流改变了什么（以及没改变什么）

Zoom 在 2026 年持续调整开发者获取会议数据的方式。首先是 3 月份推出的 OBF token 要求，收紧了 bot 加入外部会议的机制。随后，Zoom 推出了实时媒体流（RTMS）：一条通过安全 WebSocket 传输实时音频、视频、每位参与者媒体内容及转写数据的数据 pipeline——完全无需任何 bot 出现在会议中。

Zoom 的目标很明确："不再有可疑、令人困惑的 bot 加入你的会议。"那么 bot 模式已经走到尽头了吗？远远没有——但实际情况比任何一个极端都更耐人寻味。

RTMS 究竟是什么

RTMS 让应用直接获取 Zoom 会议的结构化媒体流：包括每位参与者的音频和视频、转写数据以及参与者事件，在会议进行期间通过 WebSocket 实时传输。整个过程无需任何自动化客户端加入通话——数据直接来自 Zoom 的基础设施。

这在以下几个方面确实优于 bot 方案：

• 无可见参与者：无需从等待室接受任何人，也不会占用画廊视图中的位置——不过 Zoom 仍会显示标准的「此会议内容正在与一个或多个应用共享」声明，并可能在应用访问会议时显示应用活动通知
• 按参与者分流：比对混合录像进行说话人分离更清晰
• 无加入可靠性问题：不存在可能加入失败的客户端

RTMS 无法解决的问题

• Zoom 的无参与者模型独树一帜。 Google Meet 有处于开发者预览阶段的 Media API，Microsoft Teams 有实时媒体平台（Real-Time Media Platform）——两者都提供原始流访问，但都仍需要一个类似 bot 的客户端加入通话；Microsoft 明确将 AI 智能体用例引导至其他方向。Zoom 的 RTMS 是三者中唯一无需任何人加入即可直接提供流的方案。纯粹基于无参与者捕获构建的产品目前只覆盖一个平台；而 会议 bot API 通过一次集成即可覆盖全部三个平台。
• 需要在 Zoom 端进行应用配置。 RTMS 通过具有相应权限范围和账户级启用的 Zoom 应用运行——这类按租户配置正是 bot 访客模型所规避的。
• 录像文件由你自行处理。 RTMS 提供原始流；将其组装成录像、转写文本和可搜索归档，是你需要自行构建和运维的基础设施。
• 你受邀参加的会议。 bot 模型的核心用例——录制你的用户在其他组织参加的会议——无论如何都取决于主持人的平台和设置。在 Zoom 上，这也是各实现方案产生分歧之处：基于 Zoom Meeting SDK 构建的 bot 需要 OBF 授权才能加入外部会议，且授权用户须全程在场。特定供应商受该限制影响的程度，取决于其 bot 实际加入通话的方式——以及你的产品是否需要构建 Zoom 授权页面，这个问题值得直接询问，因为并非所有实现方案都有此要求。

现实架构：两者兼用

2026 年构建会议产品的团队正逐渐趋向混合方案：在可用且已启用的场景下使用 RTMS，其余情况使用 bot。这也是 Meeting BaaS 的立场——同一套 API 让你今天就能获得适用于 Zoom、Google Meet 和 Microsoft Teams 的 bot，随着 Zoom 逐步推出 RTMS，基于 RTMS 的采集功能也将无缝接入，无需更改你的集成方式。

如果你现在就需要跨三个平台获取会议实时数据，实时流式传输已经能够通过 bot 本身的 WebSocket 提供实时音频和转写内容——数据格式与 RTMS 所承诺的一致，且不受单平台限制。

今天该怎么做

1. 只构建 Zoom、面向企业、需要租户控制？ 密切关注 RTMS；这是官方支持的路径，Zoom 也在持续投入。
2. 构建跨平台产品？ bot 模式仍是你的主要集成方式——一套 API，三个平台，无需为每个租户单独部署 Zoom 应用。
3. 已在 Zoom 上运行 bot？ 确保你已满足 OBF 要求——该变更已有硬性截止日期（2026 年 3 月 2 日），且已过期。

下一步

• 会议 bot API — 立即实现跨平台采集
• 实时会议转写与流式传输 — 三个平台的 WebSocket 实时数据
• Zoom OBF token 要求详解
• Zoom RTMS 文档