使用模型适配器，不要把供应商逻辑写进界面
可靠的架构应让浏览器只负责采集和交互，由服务端网关负责身份验证、供应商选择、请求标准化和日志。浏览器绝不能获得长期有效的模型密钥。
为创建会话和请求回答定义一套精简的内部协议，统一转写文本、图像帧、语言、会话 ID、时序信息和安全标记。供应商适配器可以把它映射到当前 API Mart，未来也能映射到获批的 SeedRealtime 正式接口。
- 浏览器：权限、媒体预览、语音控制和取消操作
- 服务端：参数验证、频率限制、密钥和供应商适配器
- 模型适配器：模型名称、请求映射和错误标准化
- 可观测性：延迟、失败、用量和用户结果
先设计会话生命周期，再决定是否全量流式传输
第一版产品不一定要发送每一帧原始视频。可以先创建会话、获取语音、抽取一张相关画面，然后发送边界明确的请求。这样更容易控制隐私、成本，并验证核心使用场景。
获得真正的流式接口后，可以沿用同一协议增加会话令牌、增量媒体、服务端事件、打断信号和明确的关闭流程。开始、重连、超时和结束状态都应对用户可见。
- 空闲 → 请求权限 → 预览 → 已连接 → 已结束
- 新一轮问题出现时取消已经过期的旧请求
- 限制图像尺寸、采样频率、转写长度和会话时长
- 明确区分可重试与不可重试错误
延迟、隐私与迁移的上线检查表
分别记录采集、上传、供应商处理、首个输出和整轮完成时间。模型很快并不能弥补图片过大、区域过远、麦克风被阻止或连接状态不透明的问题。
把迁移设计成配置与适配器的切换。不要让供应商特有字段进入共享界面状态；用相同场景对比两个供应商，并逐步放量。处理真实用户媒体前，要确认官方条款、数据保留和地区路由。
- 密钥只保存在加密的服务端环境变量中
- 加入来源校验、频率限制、请求大小限制和滥用控制
- 记录同意、保留、删除和人工复核政策
- 修改默认模型前进行并行评估
FAQ
常见问题
可以把 API Mart 密钥写在浏览器 JavaScript 中吗？
不可以。供应商凭证应只保存在服务端，并通过带验证、限流和必要身份认证的应用接口访问。
第一版一定需要 WebRTC 吗？
不一定。转写文本加抽样画面的边界请求就能验证体验。只有使用场景和正式模型接口确实要求持续媒体时，才需要流式传输。
以后如何切换到正式接口？
保持供应商无关的内部请求协议，新增一个服务端适配器，对比输出和延迟，再通过逐步放量切换默认适配器。