Windows 本地真实 RTC 联调
该覆盖层只用于本机联调，不访问阿里云服务器。它把 API 的 RTC Token 签发器和 Worker 的语音供应商切换到火山引擎，同时保留数据库、Redis、MinIO、Keycloak和告警模拟器在本地 Docker 中运行。
1. 生成本地凭据
在项目根目录运行：
.\deploy\local-rtc\configure.ps1
如果还要同时验证方舟大模型总结，可改用：
.\deploy\local-rtc\configure.ps1 -EnableArkSummary
该模式会额外隐藏读取方舟API Key和内容模型Endpoint ID，并通过只读密钥文件传给Worker。
如果 RTC 配置已经存在，只需要补充大模型总结，不必使用-Force重录全部密钥。先在方舟 API Key 控制台创建密钥，再运行：
.\deploy\local-rtc\configure-ark-summary.ps1
该脚本只更新ark-api-key、CONTENT_GENERATOR和ARK_CONTENT_MODEL，不会修改已有RTC、语音或设备凭据。当前Chat API既支持模型Model ID，也支持Endpoint ID；脚本默认使用doubao-seed-2-0-lite-260215，如果账号未开通该模型，可在提示中填写已开通的Model ID或Endpoint ID。
脚本会以隐藏输入方式依次读取：
- RTC AppKey；
- 火山引擎 AccessKey ID / Secret AccessKey；
- 豆包端到端语音 APP ID / Access Token；
- 豆包音色 ID。
密钥文件只生成到deploy/local-rtc/runtime，该目录不会提交到 Git。当前首轮联调使用豆包 S2S-O 纯端到端模式（OutputMode=0），平台本地路由仍沿用s2s_hybrid模板槽位；这是为了只依赖豆包端到端语音凭据，先验证真实双向音频。后续接入火山方舟 Endpoint 后再切换真正的混合编排模式。
2. 启动本地后端
.\deploy\local-rtc\start.ps1
首次构建需要下载 Docker 基础镜像。脚本会等待http://localhost:58080/health/ready可用。
3. 启动模拟器
双击device-simulator-windows/release/voice-device-simulator-0.1.0-windows-x64.exe，然后：
- 保持默认本地平台地址、设备 ID 和本地测试设备密钥；
- 点击“检测平台和音频设备”；
- 选择麦克风和扬声器；
- 确认同一个RTC AppID已在RTC控制台的“实时字幕”功能中启用流式语音识别；
- 点击“开始语音聊天”；
- 看到“RTC 实时字幕已启动”和“豆包语音任务已激活”后直接说话；
- 确认“实时字幕与上传”区域同时出现长者和豆包话轮；
- 点击“结束通话”验证字幕补交、
StopVoiceChat和RTC离房。
实时字幕要求先在豆包语音控制台创建服务类型为“流式语音识别”的应用，再在RTC控制台的实时字幕配置中填写该应用的APP ID、Access Token和Cluster ID。未开通或配置不匹配时SDK返回ServiceAccessDenied；这与“实时对话式AI > 回调设置”无关，不需要为字幕上传填写回调URL。
通话结束后，Worker会根据最终话轮生成通话摘要、关键词、开放话题和待审核故事。只有人工确认故事后才会进入长期记忆，这是既有授权与审核边界，模拟器不会绕过审核自动写入长期记忆。本地默认CONTENT_GENERATOR=local仅用于确定性闭环验证；要验证真实大模型总结，必须另外为Worker配置CONTENT_GENERATOR=ark、ARK_API_KEY_FILE和ARK_CONTENT_MODEL。
当新通话冻结快照中的story_extraction和personalized_memory授权均有效时，平台会把最近3次已完成通话的就绪摘要作为短期连续上下文注入豆包；S2S-O模式使用dialog.system_role，无需开启供应商侧dialog_id历史留存。长者档案中的“避免主动提及”话题也会从下一次开房起一并生效。
RTC AppKey、火山 AK/SK 和豆包 Access Token 均不进入模拟器安装包，也不会通过渲染页面读取。