远程协助
本文档描述的是 Servify 的差异化增强方向，不是第一版产品的交付前提。
V1 产品目标已收敛为 Web 独立站智能客服：
Web 接入 -> AI 首答 -> 人工接管 -> 转接协作 -> 工单全流程。远程协助保留架构与实时能力基础，但不作为 V1 验收中心。本文用于说明它的产品意图、当前基础和后续演化边界。
远程协助是 Servify 后续值得继续投入的差异化方向之一。
很多客服系统可以做到：
- 在线聊天
- FAQ 或机器人问答
- 工单流转
但在真实服务过程中，很多问题光“回复一段话”解决不了，还需要：
- 一步步指导客户完成操作
- 和客户一起定位问题
- 在同一个上下文里持续协作
Servify 把这类能力理解成产品层面的 远程协助，而不是只把它视为底层实时通信能力。
一句话定义
在 Servify 里，远程协助指的是：
- 客服在同一条会话里，把服务从“文字解释”升级到“实时指导、联合排查和继续接管”
- 协助结束后，上下文还能继续留在人工协作、转接和工单全流程里
它强调的是连续服务链路，而不是单独强调某个协议名词。
远程协助解决什么问题
典型场景包括：
- 客户不会操作某个功能，需要被引导完成
- 客户描述不清楚问题，需要边看边确认
- 售后支持或技术支持需要协助排查
- 内部服务台场景中，需要协助同事完成配置或定位故障
如果系统只能聊天，客服流程就会停留在“发消息解释”；如果有远程协助，客服就能进入更接近真实服务过程的状态。
在 Servify 里的位置
Servify 的 V1 产品主链路是：
Web 接入 -> AI 首答 -> 人工接管 -> 转接协作 -> 工单全流程
远程协助不在这条 V1 主链路里，而是挂在 人工接管 之后的一个可选升级方向。这意味着：
- V1 先保证网站接入、AI 首答、人工接管和工单全流程成立
- 当文字沟通足够时，可以停留在 AI 或人工回复
- 当问题需要演示、指引或联合排查时，未来可以升级到远程协助
- 当前仓库已保留 WebSocket / WebRTC 等实时能力基础，但未承诺已交付完整远控产品
也就是说，远程协助是 人工接管 之后的增强层，而不是 V1 必须验收的能力。
当前产品表达
在产品层面，远程协助应该被表达为：
- 帮助客户更快完成操作
- 让客服从“解释问题”变成“带着解决问题”
- 让复杂问题仍然留在同一条服务链路里，而不是跳到别的工具中断上下文
在技术实现层面，Servify 当前已经具备与远程协助相关的实时能力基础，包括 WebSocket / WebRTC 相关链路，但文档和产品表述不应把重点只放在协议名词上。
当前仓库里已经有什么
当前可以明确对外表达的基础包括：
- Web 会话、消息和实时接待链路已经存在
- AI 首答、人工接管、转接协作和工单流转都已纳入同一产品主链路
- WebSocket / WebRTC 相关 runtime、统计和连接视图已经在代码与验收中出现
- 文档与 README 已明确把远程协助归入 V1 之后的增强方向，而不是 V1 主链路
AI 首答 -> 人工接管 -> 工单全流程中的必经节点
当前不应超前承诺的内容包括：
- 已交付完整的 co-browsing / 屏幕共享产品界面
- 已完成客服管理端的专门远程协助工作台
- 已完成端到端的标准化演示剧本和产品验收口径
这些属于后续 Gap C 继续收口的范围，而不是当前仓库已经兑现的事实。
当前入口与缺口盘点见：
与 AI、人工、工单的关系
远程协助和其他核心能力一起工作：
- AI 可以先做首答和澄清，减少人工介入成本
- 人工在需要时接管，并发起远程协助
- 协助后仍可继续转接给更合适的处理人
- 无法即时收口的问题可以沉淀为工单继续推进
这样，客服系统才不只是“聊天工具 + 工单工具”，而是一套连续的服务产品。
当前阶段的判断
Servify 在这件事上已经有方向和基础，但在 V1 阶段应主动收敛范围，避免让远程协助压过网站客服主链路：
- V1 不把远程协助作为用户可见的交付承诺，先保证 AI 首答、人工接管和工单全流程稳定
- 保留实时能力基础和后续扩展入口，而不是提前透支成熟度
- 在文档、官网和产品叙事中如实表达为“增强方向”，而不是已交付的核心能力
后续当 V1 主链路稳定后，再继续补三件事：
- 管理端和服务端当前到底有哪些可直接使用的远程协助入口
- 最小可交付链路应该如何从 Web 会话升级到人工协助再进入工单
- 一条可以复用的演示和验收口径，而不是只验证底层 WebRTC / WebSocket 可用