本文介绍从 RTC 友商（声网 Agora、即构 Zego 等）迁移至腾讯云 TRTC 的整体方案，按方案设计、代码迁移、上线测试、上线切量、线上运营五个阶段说明具体做法，以及每个阶段可以调用 WorkBuddy 专区中的哪位专家、哪项能力。各能力的开通步骤、提问示例和输出说明，请参见对应的能力文章。
方案概述
双通道并存
不同 RTC 服务商的 SDK 采用各自的私有协议传输音视频，使用不同 SDK 的用户之间无法互相推拉流。因此迁移期间，同一房间内的所有用户必须使用同一家 SDK，切换服务商以房间为单位整体进行。
基于这一前提，推荐采用双通道并存方案：在保留原服务商通道的基础上接入 TRTC SDK，由服务端调度服务决定每个房间使用哪一家通道。该方案具备以下特点：
平滑迁移：新版本 App 先具备双通道能力，再按比例逐步放量，全程灰度推进。
放量可控：放量节奏由调度配置控制，可按区域、房间类别等维度逐步推进，无需发版。
方案架构
方案由三层组成，各层职责如下。
层级 | 职责 |
服务端调度层 | 提供服务商调度服务。用户进房前先请求调度，获取当前房间应使用的 SDK。 |
业务层 | 保留原有业务逻辑，通过 SDK 接入层调用音视频能力，无需感知底层使用哪一家 SDK。 |
SDK 接入层 | 同时集成原服务商 SDK 与 TRTC SDK，按调度结果进入对应通道。 |
可参考以下示例工程快速搭建双通道并存方案：
示例工程 | 说明 | 地址 |
RTCSwitchServer | 服务端调度示例（Go），提供房间创建、销毁、列表接口，创建房间时按比例分配 RTC 通道。 | |
RTCSwitchDemo | Android 客户端示例（Java），包含房间创建、房间列表、按调度结果进房等流程。 |
涉及的专家与能力
迁移全程会用到专区的腾讯实时音视频专家和 SDK 日志分析专家。下图上排是迁移的五个阶段和主要工作，下排是每个阶段可以调用的专家能力。
腾讯实时音视频专家
覆盖方案设计、代码迁移、上线测试、上线切量、线上运营全部五个阶段。
能力 | 使用阶段 | 在迁移中的作用 |
方案问答 | 方案设计 | 梳理业务场景在 TRTC 上的实现方案，如语聊房幽灵麦、应用保活、自动播放被拦截、系统电话中断等，给出可执行步骤和关键接口。 |
迁移辅助 | 代码迁移 | 将一段友商代码交给专家，逐行给出对应的 TRTC 接口、参数替换方式和回调差异。 |
云端巡检 | 上线测试 | 对指定 SdkAppId 发起巡检，扫描 UserSig、SDK 版本、TRTCParams 等配置项，在放量前集中列出隐患并给出修复建议。 |
通话详情分析 | 上线切量、线上运营 | 切量阶段每一档放量后查询 TRTC 通道上的房间、用户和通话指标，作为继续放量的依据；线上运营阶段根据用户报障给出结论、根因和修复方向。 |
SDK 日志分析专家
提供终端日志排障能力，用于线上运营阶段需要结合客户端日志分析的问题。把 SDK 产出的
.clog / .xlog 日志文件交给专家，专家解码日志、还原调用时间线，定位到具体的错误码和根因。分阶段实施
方案设计
方案设计阶段需要确认两件事：迁移架构如何落地，以及业务场景中的常见问题在 TRTC 上如何实现。迁移架构可参见 双通道并存。业务场景方面，可以直接向腾讯实时音视频专家提问，专家结合官网的场景化、模块化方案，给出可执行步骤、关键接口和注意事项。
适用能力：方案问答。以语聊房为例，常见的提问场景如下。
场景 | 提问示例 | 官网方案 |
幽灵麦 | 语聊房里有用户不在麦位列表中，却能在房间内发言，怎么处理？ | |
应用保活 | 通话过程中 App 切到后台，如何避免被系统回收？ | |
其他疑难场景 | 自动播放被拦截、系统电话中断、弱网重连等场景怎么处理？ | 专家结合对应的官网方案给出实现步骤。 |
代码迁移
代码迁移阶段的工作是将原服务商的接口调用替换为对应的 TRTC 接口，并处理参数与回调的差异。
适用能力：迁移辅助。例如将一段友商代码交给腾讯实时音视频专家，并说明原服务商，专家逐行给出对应的 TRTC 接口、参数替换方式和回调差异，研发对照修改即可。
这是一段声网的代码，帮我迁移到 TRTC：（粘贴代码片段）
除专家对话外，也可以根据团队的开发习惯，选用以下两种官方迁移工具。
智能顾问· TRTC 云助手控制台迁移辅助
登录 智能顾问 > TRTC 云助手控制台，进入 TRTC 云助手 > 迁移辅助页面，支持代码片段分析和代码压缩包分析两种方式。选择文件和已识别的友商 API 后，右侧给出对应的 TRTC 接口、参数替换方式和示例代码。详见 迁移辅助。
TRTC 迁移助手 MCP
在 CodeBuddy、Cursor、VSCode 等支持 MCP 的 AI 工具中配置 TRTC 迁移助手后，发送友商代码并说明需要迁移到 TRTC，工具识别其中的友商接口调用，返回对应的 TRTC 接口、参数说明和迁移指引，由 AI 完成代码改写。详见 MCP。
上线测试
上线测试阶段：业务侧对接入 TRTC 测试之后，对接入配置的隐患进行检查。
适用能力：云端巡检。例如对指定 SdkAppId 发起巡检后，专家扫描 UserSig、SDK 版本、TRTCParams 等配置项，巡检完成后列出过期、异常、参数错误等隐患，并给出修复建议。
对 1400000001 这个 SdkAppId 发起一次云端巡检
上线切量
上线切量分为预埋和双通道共存两个阶段，目标是在用户无感知的前提下，将流量从原服务商逐步切换到 TRTC。
预埋阶段
预埋阶段让 App 先具备 TRTC 通道能力，用户实际仍使用原通道。
步骤 | 做法 |
1. 集成 TRTC SDK | 在工程中集成 TRTC SDK，与原服务商 SDK 共存。 |
2. 上线调度服务 | 服务端发布调度服务，调度结果暂时全部指向原服务商。 |
3. 发布双通道版本 | 发布同时集成两家 SDK 的新版 App，提示用户更新。 |
4. 等待版本覆盖 | 用户更新后仍使用原通道，等待新版本覆盖率达到业务设定的阈值。 |
双通道共存阶段
新版本覆盖率达到阈值后，通过调度服务按比例将房间分配到 TRTC 通道。主播创建房间时由调度服务分配通道，观众通过房间列表进入房间时使用该房间对应的 SDK。
旧版本用户只集成了原服务商 SDK。旧版本用户进入 TRTC 通道的房间时，该房间内所有成员整体切换至原服务商通道，此后该房间保持原服务商通道，不再切回 TRTC。
推荐按以下节奏分档放量，每一档确认指标稳定后再进入下一档。
档位 | 放量比例 | 做法 |
第一档 | 5% | 向小比例新版本用户开放 TRTC 通道，观察通话指标。 |
第二档 | 20% | 扩大放量范围，可按区域、主播类别、房间类别精细化灰度。 |
第三档 | 50% | 两个通道流量持平，对比两边的通话指标。 |
第四档 | 全量 | 引导剩余旧版本用户升级，调度全部切换到 TRTC。 |
线上运营
用户报障定位
适用能力：通话详情分析。
用户反馈听不到声音、画面卡顿、进房失败等问题时，把现象、SdkAppId、房间号和时间段告诉专家，专家完成整套排障流程，给出结论、根因和修复方向。
user_111 反馈听不见对方说话，1400000001 房间 3333，昨晚 21-23 点排查下
专家的诊断结论按问题类别区分，对应不同的处理方式。
问题类别 | 处理方式 |
网络问题 | 引导用户切换网络后重试。 |
设备问题 | 引导用户检查麦克风、摄像头权限或更换设备。 |
接入用法问题 | 参数配置、UserSig 生成方式、接口调用顺序、SDK 版本等，由研发对照根因调整接入代码。 |
SDK 内核或服务端问题 | 由腾讯云原厂技术支持处理，同步现象、SdkAppId、房间号即可。 |
适用能力： 终端日志排障。
需要结合客户端日志分析的问题，可将 SDK 产出的
.clog / .xlog 日志文件交给 SDK 日志分析专家，专家解码日志、还原调用时间线，定位到具体的错误码和根因。应急处理与原厂支持
放量过程中如出现通话指标波动或用户集中反馈，可先通过调度服务暂缓放量，同时借助通话详情分析定位问题。腾讯云原厂技术支持团队始终在线，可随时直接对接，协同完成排查和处理。
