SparkLive Studio

把 NVIDIA DGX Spark 变成主播身边的本地 AI 直播运营团队：实时看懂现场、协同多个专长 Agent、把建议交给主播确认，并把直播后的高光变成可复用资产。

SparkLive Studio 面向游戏主播、虚拟主播、聊天/知识主播、直播带货团队以及管理多位主播的 MCN。它不是又一个推流器，也不是把一个通用聊天机器人塞进直播间；它是一个以本地推理为核心的直播控制面，把声音、画面、弹幕、商品事实、OBS 状态和设备健康组织成同一条可追溯的工作流。

SparkLive Studio 的故事很简单：主播把注意力放在观众和内容上，DGX Spark 在本地承担繁重的感知、整理和复盘，Multi-Agent 把每一个建议交给正确的岗位，Policy 和 Audit 让企业敢于把它接进真实流程。这样，直播不再依赖一个人同时记住所有事情，而成为一套可以部署、度量、复制和持续改进的生产系统。

项目版本：1.0.0
运行平台：NVIDIA DGX Spark（GB10，Linux ARM64）+ Windows 11 Qt 主播工作台
许可证：项目自研代码采用 Apache License 2.0；第三方源码、模型权重、字体、音乐、角色与声音素材不因本项目许可证而重新授权，详见 NOTICE 和模型、服务、外部仓库与许可证。

---

项目亮点

直播行业的难题不是“没有一个能回答问题的 AI”，而是主播在同一秒要表演、看评论、记流程、守合规、盯设备、切场景、记高光，还要在延迟和故障中保持自然。SparkLive Studio 的价值是把这些分散的注意力任务压缩成少数有来源、有时效、可确认的提示，同时不把原始直播内容交给云端 API。

项目的三项核心亮点：

1. DGX Spark 本地多模态算力。 Qwen3.5、Whisper、VAD、视觉和实时重绘模型都从 Software/ 的固定权重加载；默认不调用任何云端大模型 API，不运行时下载。128 GB 统一内存让大模型、媒体缓冲和编解码共享一个可治理的内存池，GB10 的 CUDA/NVENC/NVDEC 让本地推理和后期媒体处理可以放在主播团队自己的设备上。
2. Multi-Agent，而不是一个“大而全”的助手。 导播、互动、商品、安全、运维、虚拟人和 Clip Agent 各有职责和证据边界。它们只生成 ActionProposal，所有 OBS、商品卡、公开内容和文件动作都经过 Policy Gateway -> Tool Registry -> Audit。这样既能并行扩展，也能在一个 Agent 出错时保住直播主链路。
3. 主播真正用得上的工作台。 Windows Qt Quick 客户端把高频操作做成置顶主播提示窗、OBS 观众字幕窗、可调 VAD、弹幕重点、人工确认、应急接管和可恢复切片；复杂参数集中到参数中心，运行日志是只读的，任何按钮都对应真实 API 行为。

当前可复现实测

---

1. 为什么现在需要直播 AI 助理

1.1 市场已经足够大，现场仍然高度人工

公开数据说明了两个事实：观众和商业预算都在增长，而直播现场的“第二注意力”没有被基础推流软件解决。

• CNNIC 第 55 次《中国互联网络发展状况统计报告》显示，截至 2024 年 12 月中国网民规模达到 11.08 亿，互联网普及率 78.6%；网络购物用户 9.74 亿。这意味着直播内容、互动和交易已经是大规模数字消费基础设施，而不是小众娱乐。
• IAB《2025 Creator Economy Ad Spend & Strategy Report》预计美国 2025 年创作者经济广告投入达到 370 亿美元，同比增长 26%。品牌愿意把预算放到主播身边，前提是内容质量、合规和可衡量性能够稳定交付。
• Streamlabs 与 Stream Hatchet 直播报告持续追踪 Twitch、YouTube、Kick 等平台的观看时长、活跃频道和创作者竞争，说明多平台分发已经让“一个人看一个聊天窗”成为低效做法。
• 人力资源社会保障部《互联网营销师国家职业技能标准（2021 年版）》将直播销售拆为脚本和彩排、商品介绍、展示、下单引导、气氛管理、反馈调整、评论管理、设备故障、数据采集和复盘。直播助理实际上是一组岗位，而不是单一“回复弹幕”的工作。

1.2 主播在直播中的真实痛点

共同痛点是高并发信号、低可用注意力：弹幕速度、平台事件、音画质量和流程时钟同时变化，但主播只能把注意力放在一个画面上。真正有用的 AI 不应再开一个聊天窗口，而应把一百条事件压成“现在最该看哪两件事”。

1.3 专职直播助理解决了什么，又带来什么问题

人工场控很重要，但不是无限扩张的答案：

• 成本随场次和主播线性增长。 每位主播至少需要一名能看 OBS、平台后台和脚本的现场人员；夜间、跨时区和多平台同时开播还要轮班。
• 信息处理不一致。 不同助理对“重要弹幕”“高光”“风险词”的判断不同，交接时也很难复盘为什么做了某个动作。
• 工具操作不可审计。 助理可能直接改场景、发消息、改商品状态，出了问题只能靠聊天记录和口头回忆追责。
• 隐私和权限集中。 助理需要看到原始画面、麦克风、订单和后台凭据；外包、临时人员和离职交接扩大了数据暴露面。
• 无法规模化复用。 一位优秀助理的经验难以复制到十位主播；新人需要长时间熟悉每个主播的流程、禁区和商品目录。

SparkLive Studio 的定位不是替掉所有人，而是把“监看、整理、提示、记录和可回放的判断”软件化，让一个场控可以服务更多主播，把人的时间留给最终表达、敏感判断和对外确认。

1.4 竞品地图：为什么还需要 SparkLive

竞品并非“做得不好”，而是各自优化一个环节。SparkLive 的商业机会在于把这些环节接成本地、可审计、可替换、面向团队规模化运营的一套控制面。

---

2. SparkLive Studio 的产品答案

2.1 一条直播工作流

摄像头 / 游戏 / 麦克风 / 弹幕 / 商品目录 / OBS / 设备指标
                              |
                       Capture Gateway
                              |
                    Perception 结构化事实
                              |
                 Event Bus + SQLite 时间线
                              |
               窄职责 Agent 并行分析与排序
                              |
                       ActionProposal
                              |
                Policy Gateway -> Tool Registry -> Audit
                         / allow | confirm | block
                              |
             OBS / 字幕 / 商品卡 / Clip / Avatar / 系统降级

媒体面和控制面分离：原始音视频走受认证、有界的媒体通道；Event Bus 只传 URI、PTS、帧索引、检测框、文本、分数和证据引用。这样可以让模型和媒体 Worker 更换，而不让业务层、审计表或外部 Agent 接触原始字节。

2.2 亮点一：DGX Spark 本地部署，隐私和成本都可控

NVIDIA DGX Spark 官方规格给出的 GB10 平台包含 128 GB coherent unified memory、最高 1 petaFLOP FP4 AI 性能、273 GB/s 带宽、NVENC/NVDEC，并支持本地运行最多约 200B 参数级别的 Agent 工作负载。SparkLive 按直播优先级使用它：

• 低延迟链路使用确定性 VAD、Whisper 窗口和 Qwen3.5-9B BF16；模型结果只做复核，不阻塞字幕和提示。
• 低频复杂任务使用 Qwen3.5-27B FP8；统一内存容纳模型和媒体缓存，单并发预算避免挤占推流。
• 录播链路先用音频/场景/弹幕等低成本证据筛候选，再把 Top-K 窗口交给多模态模型，最后由 FFmpeg/NVENC 输出短视频。
• 实时重绘通过 StreamDiffusionV2 staged pipeline 使用最新帧队列；模型切换有完整 lease，故障时释放 GPU，不把旧画面冒充新模型输出。

本地化带来三项直接收益：

1. 数据主权。 主播原话、未公开商品、未发布脚本和视频不需要上传第三方 API；审计中保存结构化引用和 artifact URI，而不是原始内容。
2. 可预测的边际成本。 模型下载和环境位于 Software/，推理不按 token、分钟或并发向云服务计费；成本变成可预算的设备折旧、电力和维护。
3. 可组合的模型池。 同一台 DGX 可以按时序运行 ASR、聊天重点、VLM、切片和重绘；模型通过 Adapter 隔离，新增模型不会改变主播端操作契约。

2.3 亮点二：Multi-Agent 把复杂现场拆成可负责的岗位

每个 Agent 有 owner、触发事件、证据范围和工具白名单：

高风险动作的生命周期是 proposed -> allowed/confirm/blocked -> executed/failed。每次调用保留 correlation_id 和 idempotency_key；策略不可用或审计不可写时，外部状态改变动作自动 fail closed。这个设计把“AI 很聪明”转换成企业能接受的“出了问题知道谁建议、依据什么、是否执行”。

2.4 亮点三：从主播视线出发的交互设计

• 置顶主播窗只显示当前流程、人数/互动趋势、问题和最多两条重要提示；主播不必盯完整后台。
• 观众窗独立于主工作台，可被 OBS Window Capture 采集；字幕是主播明确授权的音频事实，私有提示不会泄露给观众。
• 弹幕重点先用确定性排序即时展示，再以 Qwen3.5-9B 异步复核；界面区分“即时筛选”“模型复核中”和“确定性降级”，不会把模型延迟伪装成实时采集延迟。
• 参数中心把 250/500/1000/2000 ms 音频块、2--30 秒识别窗、VAD 起止阈值、rundown、提示冷却、Clip 片段边界等可理解参数集中管理；采集中锁定会影响时序的值。
• 人工确认和应急接管固定在顶栏；L2/L3 动作显示风险、理由、参数和来源，确认瞬间再次检查 emergency 状态，避免竞态。
• 内置只读运行日志合并 stdout/stderr、Qt/QML 消息和 DGX 诊断，按模块着色并自动脱敏；它不是 Shell，不会给主播一个绕过策略的命令入口。

---

3. 模块与技术实现

SparkLive 采用 Python 模块化单体：先用清晰契约保证断网演示和单机回放，再按媒体采集、感知、控制面和异步 Worker 拆进程。下面的模块边界对应上面的现场需求。

外部仓库的复用和适配

项目优先复用成熟引擎，自己实现直播领域的契约、治理和适配：

• 复用 OBS WebSocket v5 的控制/状态协议；自研三条隔离 lane、有界事件队列、重连、Tool 映射和审计。
• 复用 StreamDiffusionV2 staged API、时序缓存和 Wan2.1 1.3B；自研多模型 registry、Wan 5+4 帧适配、GPU lease、加载进度、参考图能力校验、8787 relay 和 Windows 工作流。
• 复用 Diffusers 的 IP-Adapter/FLUX 接口语义；按基础模型的 cross-attention 和图像编码器匹配，拒绝把不兼容的 Wan 或 SD2 权重强载。
• 复用 whisper.cpp、ModelScope Whisper、Silero VAD、PyAV、PySceneDetect、FFmpeg/NVENC；自研 VAD 前门、窗口合并、证据融合、原子输出和降级。
• 借鉴 NVIDIA DGX Spark playbooks 的本地 VLM、多 Agent、VSS 组织方式；SparkLive 额外加入直播动作风险、平台事实、OBS 和主播 UI。
• 复用 Vite、React、Qt Quick、Lucide 图标；前端交互、状态轮询、观众层和参数 schema 是项目自研。

---

4. 部署与使用

4.1 目录和环境原则

Software/python-venv/       Python/CUDA 推理环境
Software/frontend/          React/Vite/Lucide 依赖
Software/playwright/        浏览器自动化与浏览器缓存
Software/models/             Whisper、Qwen、VAD、重绘权重
Software/source-cache/      固定 revision 的外部源码
runtime/                    SQLite、artifact、checkpoint、基准和日志

根目录 requirements.txt 汇总 DGX 推理、媒体、OBS、Qt 桌面和平台 bridge 的直接 Python 依赖，便于审计、IDE 和离线制品准备。正式安装仍优先使用下述 make 目标：它们会把依赖放入 Software/python-venv，并完成 CUDA、SM121 扩展、模型和本地缓存检查。

4.2 DGX Spark 快速启动

# 1. Python/媒体/ASR/剪辑依赖（首次执行）
make autoclip-install
make autoclip-install-inference
make console-install

# 2. 下载并校验本地模型（按磁盘和用途选择）
make autoclip-download-models
make chat-model-download
make chat-model-verify
make qwen-fastpath-install

# 3. 运行确定性演示和测试
make demo
make verify

# 4. 启动 DGX 控制面 + 7860 重绘 Worker
export SPARKLIVE_API_TOKEN='replace-with-a-long-random-secret'
export SPARKLIVE_HOST='0.0.0.0'
make api

API 默认端口 8787，实时重绘媒体 Worker 默认 7860。8787 是控制面和受认证 relay；原始 JPEG/音频不经过 JSON API、Event Bus 或 Audit。跨机器连接应使用受管 LAN/VPN，并配置 SPARKLIVE_TLS_CERT 与 SPARKLIVE_TLS_KEY。

4.3 Web Console

make console-dev                 # 开发端口，默认 Vite 代理 8787
make console-build               # 生产构建，由 API 同源托管
make browser-install             # 项目内 Playwright 浏览器
SPARKLIVE_VISUAL_URL=http://127.0.0.1:8787 make visual-test

Console 的主要操作：运行 demo、查看 Agent/事件/高光/审计、确认或拒绝 L2/L3 proposal、切换应急接管、打开实时重绘和复制 OBS Browser Source。断线时保留最后快照，重新连接后以服务端 revision 为准。

4.4 Windows 主播工作台

Linux ARM64 生成 Windows 源码包：

make desktop-package-source

在 Windows 11 x64 + Visual Studio 2022 Build Tools 上：

powershell -ExecutionPolicy Bypass -File .\apps\desktop\scripts\build_windows.ps1

4.5 主播的一次完整操作

1. 开播前在参数中心选择 gameplay、virtual_avatar、commerce、talk 或 general rundown，核对 OBS、音频设备、商品目录和模型健康。
2. 打开“直播助手”，开始场次；置顶主播窗显示当前环节、互动速率、问题、礼物和最多两条提示。
3. 选择 Windows 麦克风、采集卡或 OBS 监听虚拟声卡。开启转写后，客户端先预热 Whisper，模型 ready 前不采集 PCM；会话创建时固化 VAD、分块和识别窗。
4. 弹幕窗口先显示即时确定性排序，Qwen 复核完成后更新摘要；模型不可用时仍保留同一窗口的确定性结果。
5. 商品卡、观众消息、TTS、虚拟人台词等 L2 动作在确认队列中显示理由、风险和事实来源；主播可确认、拒绝或稍后处理。任何时候都可点击应急接管。
6. 用热键 Ctrl+Shift+H 记录人工高光；下播时先停止音频并等待最后 ASR 窗口排空，再导出匿名 5 秒互动桶、转写和 marker sidecar。
7. 在“智能切片”选择本地录播和 profile；Worker 逐阶段显示 probe、ASR、证据、选段、字幕和渲染进度，可恢复 checkpoint，输出 9:16 本地草稿和计划 JSON。

4.6 常用配置参数

完整 schema 在 config/default.json；Windows 参数中心只暴露主播能理解且确实影响链路的字段\。

4.7 API 示例

# 健康检查
curl http://127.0.0.1:8787/api/health

# 读取统一快照
curl -H "Authorization: Bearer $SPARKLIVE_API_TOKEN" \
  http://127.0.0.1:8787/api/snapshot

# 运行离线演示（会产生结构化事件、proposal、审计和高光草稿）
curl -X POST -H "Content-Type: application/json" \
  -H "X-Idempotency-Key: demo-20260721-001" \
  http://127.0.0.1:8787/api/demo/run

版本化模块 API 位于 /api/v1/<module>；所有控制 POST 都支持 X-Idempotency-Key。外部事件入口只接受白名单结构化事件，不能注入内部 agent.proposal 或 tool.result。

---

5. 主播操作手册

本章面向主播、场控和直播技术负责人。它把安装说明、现场操作和故障处置放在一条工作流里：主播只需要掌握场次、提示、音频和确认；技术负责人负责 DGX、OBS、模型和网络边界。

5.1 双机部署与数据位置

推荐一台 Windows 主播机配合一台 DGX Spark：

关键数据保存在项目目录内：

runtime/sparklive.db                         运行状态、时间线、pending 和审计
runtime/live-assistant/<session_id>/         transcript、平台 sidecar 和 marker
runtime/live-audio/<audio_session>/windows/  受限 ASR 短窗，默认处理后删除
runtime/uploads/<upload_id>/                 可续传录像临时文件
runtime/autoclip/<job_id>/                   checkpoint、阶段指标、证据和计划
runtime/clips/                               本地 MP4 草稿
Software/                                   模型、venv、Node、浏览器和媒体工具

原始媒体、Cookie、Token、OBS 密码和完整平台 payload 不进入事件总线。控制动作保留 correlation_id 与 idempotency_key，重试不会重复执行 OBS 或上传动作。

5.2 连接 Windows 工作台

在 DGX 上启动服务：

export SPARKLIVE_API_TOKEN='replace-with-a-long-random-secret'
export SPARKLIVE_HOST='0.0.0.0'
export SPARKLIVE_PORT='8787'
make api

跨不可信网络时同时配置 SPARKLIVE_TLS_CERT、SPARKLIVE_TLS_KEY，或使用受管 VPN。Windows 工作台中填写 http(s)://<DGX-LAN-IP>:8787 和相同 Token；Token 仅保存在当前进程，不写入 QSettings。

连接成功后，工作台提供五个工作区：

• 直播助手： 场次、流程、转写、弹幕、礼物、健康、模型任务和人工审批。
• 实时重绘： 摄像头、七模型选择、Prompt、参考图、输入/生成预览、性能指标和 OBS 输出窗。
• 智能切片： 本地录像预览、续传、sidecar、七阶段进度、计划和草稿下载。
• 运行日志： 可搜索、筛选和复制的只读诊断，不提供 Shell。
• 参数中心： ASR/VAD、直播助手和 Clip 的完整可调参数，以及只读安全边界。

主播可使用以下快捷键：

开播前应在目标 Windows 全屏游戏中测试快捷键冲突、麦克风权限、DPI 和 OBS Window Capture。

5.3 接入 OBS 控制与观众窗口

OBS 28+ 已内置 obs-websocket v5。技术负责人按以下顺序配置：

1. 打开“工具 -> WebSocket 服务器设置”，启用服务，保留默认端口 4455 并设置强密码。
2. 防火墙仅允许 DGX 固定 IP 在专用网络访问 TCP 4455。
3. 预先创建 SparkLive 需要控制的场景和来源，例如 商品特写、休息画面、limited-offer 和 screen-capture。
4. 在 DGX 当前 Shell 中设置 OBS 凭据并启动真实 Adapter：

export SPARKLIVE_OBS_ADAPTER=websocket
export SPARKLIVE_OBS_HOST=192.168.1.50
export SPARKLIVE_OBS_PORT=4455
export SPARKLIVE_OBS_PASSWORD='set-only-in-this-shell'
make api-obs

5. 打开 /api/snapshot，确认 obs.adapter=obs-websocket-v5、obs.connected=true，并检查 command/event/telemetry lane。

SparkLive 已注册 obs.set_scene、obs.show_overlay 和 obs.hide_source。逻辑 overlay 可以在 config/default.json 映射到既有 OBS 来源：

"overlays": {
  "limited-offer": {
    "scene": "商品讲解",
    "source": "SparkLive 优惠层",
    "text_input": "SparkLive 优惠文案",
    "transform": {"positionX": 1320.0, "positionY": 120.0}
  }
}

主工作台顶部的广播按钮会打开两个独立窗口：

• SparkLive 主播提示：约 470x410，置顶，只显示主播私有信息。
• SparkLive 观众提示层：约 720x180，供 OBS Window Capture 使用。

OBS 只采集观众提示层。该窗口优先显示主播明确授权的 live_caption；普通公开提示必须先创建 L2 proposal，再由操作者确认展示。问题队列、礼物列表和私有建议不会出现在观众窗口。

实时重绘使用另一个纯画面窗口 SparkLive Studio - StreamDiffusionV2 OBS Output。它不显示 Prompt、参数、日志或参考图。运行中可以热更新 Prompt；模型、分辨率和步数等需要重建 pipeline 的参数在停止前锁定。

5.4 接入麦克风、OBS 混音与实时字幕

工作台读取 Windows 录音设备，可选择两种接线：

1. 只识别主播： 直接选择麦克风或采集卡音频输入，链路最短。
2. 识别 OBS 混音： 将需要识别的 OBS 来源设置为“监听并输出”，监听设备指向虚拟声卡播放端；SparkLive 选择配对的录音端。例如 OBS 写入 CABLE Input，工作台读取 CABLE Output。

使用耳机检查双声、回声和啸叫，避免把桌面音频再次监听回扬声器或麦克风。完整处理链如下：

麦克风 / OBS 虚拟录音端
  -> Qt QAudioSource
  -> PCM16 下混与重采样
  -> 20 ms 自适应 VAD、双阈值、前后留白
  -> 语音块 + 场次 PTS + VAD gap 的认证 PUT
  -> DGX 静音兜底与重叠增量窗口
  -> 本地 Whisper
  -> interim/final speech.transcript
  -> 主播看板、sidecar、OBS live_caption 和窄职责 Agent

主播操作步骤：

1. 先开始直播助手场次，再点击顶部麦克风图标。
2. 选择实际麦克风、采集卡或 OBS 虚拟录音端；采集中先停止才能换设备。
3. 开启“语音转写”；需要公开字幕时再开启“OBS 观众字幕”。两个授权相互独立。
4. 首次使用建议保持 1000 ms 分块 / 8 s 识别窗 / -42 dB 开始 / 600 ms 句尾静音。
5. 点击“开始采集”。DGX 返回一致的模式、字节数、VAD 参数和 base_pts_ms 后，Windows 才打开设备。
6. 观察 RMS、说话状态、发送、静音跳过、延迟和丢弃。持续讲话约每 4 秒产生一版中间字幕，自然停顿后同一 utterance_id 合并为最终句。
7. 下播前点击“停止采集”。客户端补齐短尾并排空 PUT，DGX 完成最后窗口后从 stopping 进入 stopped，再结束助手场次。

VAD 与增量参数：

5.5 开始和管理一场直播

1. 确认 DGX、工作台、OBS、录制和音频健康。
2. 选择直播类型并输入场次名称。
3. 点击“开始”；系统冻结当前 settings revision、profile 和 rundown 边界。
4. 按需开启音频、字幕、平台 Adapter、专注模式和人工高光。
5. 暂停时流程计时停止，已经收到的数据保留；恢复后继续当前阶段。
6. 结束时先排空音频，随后原子导出 transcript、sidecar 和 marker。

五类默认流程：

阶段结束前默认 60 秒提示。流程修改从下一场生效；提醒、互动和健康阈值保存后立即生效。

提示卡支持“稍后”“已处理”和“申请送入观众层”。主看板显示服务端允许的 1--5 条提示，置顶窗最多显示两条；专注模式只过滤主播窗，不关闭安全告警、数据采集或主看板。

互动区保留滚动弹幕速率、主题、重复问题和礼物待谢。勾选礼物只标记主播已感谢。Ctrl+Shift+H 生成权威人工 marker，进入实时 Clip 候选和下播 sidecar，但仍经过素材、边界、隐私和版权检查。

5.6 接入平台事件

首次部署使用 Mock/replay 验证流程：在平台 Adapter 中选择平台、Mock / 离线 和合法房间标识。该模式不访问网络，可以稳定演练弹幕、礼物、人数、gap 和审批。

显式学习环境可安装隔离 bridge：

make platform-adapters-install
export SPARKLIVE_ENABLE_COMMUNITY_ADAPTERS=1
make api

启动 community 模式需要同时满足服务端开关、UI“已取得主播授权”的二次确认和合法房间号。bridge 输出最小化 NDJSON，Connector 负责匿名引用、去重、gap、进程监督和健康快照；Cookie、WBI key 和设备标识不离开 bridge 进程。

平台指标始终保留原语义：只有 concurrent_viewers 表示同时在线；popularity、cumulative_views、room_entries 分别表示热度、累计观看和进房。

5.7 下播证据与自动切片

结束场次后生成：

runtime/live-assistant/<session_id>/transcript.json
runtime/live-assistant/<session_id>/platform-sidecar.json

sidecar 保存匿名 5 秒互动桶、平台指标原语义、duplicate ratio、gap、transcript URI、自动/人工 marker、profile、settings revision 和实际 rundown 边界。建议在开始 OBS 录制时同步开始助手场次，使录像、转录和 marker 共用时间轴。

桌面端智能切片流程：

1. 选择 .mp4/.mkv/.mov/.m4v/.webm/.ts/.flv 录像。
2. 选择 auto/gameplay/talk/virtual_avatar/general profile 和 1--3 条输出。
3. 选择“仅生成计划”或“本地渲染草稿”，按需关联刚结束场次的 sidecar。
4. 工作台按 4 MiB 分块上传；断线后查询服务端确认偏移并续传，finalize 时重新计算 SHA-256。
5. DGX 依次执行 probe、audio、ASR、subtitles、evidence、plan、render，并显示阶段/总进度和 ETA。
6. 下载 WorkflowPlan JSON、ASS 字幕和本地 MP4 草稿，人工复核隐私、版权和字幕后再发布。

七阶段产物：

高光选择先用 15 秒窗口/5 秒步长召回，再融合语义、画面、游戏、声音和观众反应。单纯弹幕、关键词、响度或镜头变化不能独立过线；重复刷屏、黑帧、静音、BRB 和观众快速下跌属于负证据。最终片段吸附句子/话题/镜头边界，并重新检查隐私和版权。

DGX 本地 CLI 同样可用：

make autoclip-run RECORDING=/path/to/live.mkv
make autoclip-run RECORDING=/path/to/live.mkv EXECUTE=1

第一条只生成计划，第二条是操作者明确授权的本地渲染。

5.8 现场参数调优

Clip 默认输出 9:16 / 1080x1920 / 60--180 s / -14 LUFS，编码优先 NVENC、回退 x264。字幕、画面、编码和模型预算的完整默认值统一位于 config/default.json，服务端会重新校验所有 Windows 覆盖值。

5.9 故障处理

故障时系统保留确定性提示、mock/replay 和本地计划能力。Policy、Audit、授权或事实源不可用时，高风险动作关闭；模型失败不自动切云，也不伪造结果。

5.10 一场直播的推荐清单

开播前

• DGX API 在线，Windows 工作台连接成功，远程链路受 Token + TLS/VPN 保护。
• OBS 28+ WebSocket、密码、场景、来源和观众 Window Capture 已核对。
• 麦克风或 OBS 虚拟录音端可见，RMS、VAD、Whisper 模式和观众字幕符合本场授权。
• 已选择 profile，确认 rundown、提醒、互动、健康和高光阈值。
• 模型权重、内存预算和 Worker 模式通过探测；OBS 录制已准备。

直播中

• 开始场次并确认当前/下一环节；需要字幕时启动音频。
• 优先处理 high/critical 健康与安全提示，必要时启用应急接管。
• 公开提示先申请再确认；商品价格、库存、优惠和功效只采用事实源。
• 重要时刻按 Ctrl+Shift+H，平台 gap 记录为未知而不是零互动。

下播后

• 先停止实时音频并等待最后句，再停止录制和结束助手场次。
• 确认 transcript、sidecar 和 marker 已生成并与录像时间轴对应。
• 在 Clip 页选择录像、profile、数量和 plan/render，按需关联直播证据。
• 人工复核计划、字幕、隐私/版权提示和 MP4 草稿后再发布。
• 按团队保留策略清理录像、短窗和 runtime artifact。

---

6. 模型、服务、外部仓库与许可证

6.1 已纳入模型清单

6.2 外部服务与源码

6.3 外部仓库总表

下表区分“随项目缓存/直接适配”和“架构参考/预留端口”。所有实际下载由 make 目标触发并落在 Software/。

6.4 SparkLive Studio 许可证边界

SparkLive Studio 原创业务代码以 Apache License 2.0 开源。该许可证允许个人和企业使用、修改、分发及商业部署，同时要求保留版权声明、许可证文本、NOTICE 内容和适用的修改说明；Apache-2.0 还提供明确的贡献者专利授权，但不授予项目名称、标识或第三方资产的商标权。

根许可证只覆盖本项目贡献者有权授权的原创代码，不改变任何外部组件的许可：

• Software/ 中按需下载的外部仓库、Python/Node 依赖和工具继续遵循各自上游许可证；发行包只应携带实际分发组件对应的完整许可和署名文本。
• 模型实现与模型 checkpoint 分别判断。模型权重、数据集、字体、音乐、数字人形象、声音样本及生成内容继续遵循精确模型卡、平台条款、素材授权和适用法律。
• DouyinLiveWebFetcher 的 AGPL-3.0 源码保持进程与分发隔离，不作为 Apache-2.0 核心的一部分；bilive-danmaku 的 MIT 版权与许可声明必须保留。
• PySide6/Qt、FFmpeg、OBS、编解码器和 Windows 运行库的分发义务独立适用。项目内标记为 nonfree 的 FFmpeg 开发构建不得直接作为公开二进制制品重新分发。

项目级署名和边界声明见 NOTICE，Windows 桌面发行涉及的开发期清单见 apps/desktop/THIRD_PARTY_NOTICES.md。商业发行方仍应按照实际装入制品的精确版本生成最终第三方许可证清单。

---

7. 可靠性、合规与数据边界

• Agent 永远只生成 ActionProposal；不能直接调用 OBS、平台、文件、网络或发布接口。
• 价格、库存、优惠、功效、资质来自商品目录/平台事实源；模型不能补全缺失事实。
• L0 读取/排序/草稿可自动执行；L1 预设 OBS/降级动作可按策略执行；L2 商品卡、公开消息、TTS、虚拟人台词默认确认；L3 改价、改库存、发布和敏感公开回复确认或阻断。
• 审计不可写、策略不可用、凭证/授权状态不明确时，高风险动作 fail closed。
• 原始音视频不进 Event Bus、ToolResult 或 Audit；事件只传 URI、PTS、frame_ref、检测框、文本、分数和结构化信号。
• API 非 loopback 访问必须配置 SPARKLIVE_API_TOKEN；跨不可信网络启用 TLS 或受管 VPN；Token 不写入 QSettings。
• 直播 sidecar 默认匿名化 5 秒互动桶、transcript URI、marker 和 rundown revision；原始短窗 WAV 处理后删除策略由部署保留期决定。
• 社区平台 bridge 只在显式学习模式打开，并保留 gap、重复、乱序和健康状态；生产接入以平台官方授权能力为事实源。

---

8. 商业价值与落地路径

8.1 价值模型

SparkLive 的直接买单者可以是三类客户：

1. 职业主播和小型工作室： 用一台 DGX Spark 取代“每场都要同时盯聊天、OBS、剪辑”的重复工作，主播和场控把时间放回内容。
2. MCN/品牌直播团队： 用统一 profile、商品事实、权限和审计，把一位优秀场控的经验复制到多间直播间；同一台 DGX 按策略排队运行多个模型和多场低频任务。
3. 平台、硬件和园区客户： 以本地部署、白标控制面或 DGX Spark 方案打包，满足素材不出域、内网运行、模型可替换和企业审计要求。

8.2 一份可审计的成本测算方法

公开市场数据能证明预算存在，但不能替项目承诺具体 ROI：

年度人工节省 = 每场被自动整理/提示的助理小时数 × 场次 × 助理综合时薪
年度云推理节省 = 每月音频分钟×ASR 云价 + 每月视频分钟×VLM/剪辑云价
新增收益 = 高光复用带来的可归因播放/转化增量
项目净价值 = 三项收益 - DGX 折旧/电力 - 运维和授权成本

项目实测说明本地化确实能把重任务放进同一设备：Qwen 9B 的确定性即时路径不等待模型；27B 只在有预算的低频窗口运行；70 秒录播已完成本地 ASR/语义/渲染闭环。商业试点应以 10 场主播基线记录以下指标：主播被打断次数、未回答问题比例、错误商品事实次数、人工高光整理分钟数、Clip 出片时长、GPU/网络故障恢复时间和观众/转化变化。这样 ROI 来自真实运营数据，而不是泛化的“AI 提效百分比”。

8.3 可行的 90 天试点路线

试点结束后可以选择按设备销售、按工作室订阅、按本地 Worker 节点授权或与硬件/平台联合交付。

---

9. 目录速览和进一步阅读

apps/api/                 控制面 HTTP API + 7860 媒体 relay
apps/console/             React/Vite Web 操作台
apps/desktop/             PySide6/Qt Quick Windows 主播工作台
apps/redraw/              StreamDiffusionV2 多模型 Worker
src/sparklive/            contracts/capture/perception/agents/policy/...
config/default.json       运行时配置和风险边界
config/autoclip-models.json  模型、来源、SHA-256、资源策略
requirements.txt          完整 Python 直接依赖与 DGX/Windows 平台标记
tests/                    契约、策略、Agent、API、桌面结构和 Clip 回归
Software/                 所有依赖、浏览器、源码缓存和模型
runtime/                  本地数据库、artifact、checkpoint、基准和截图

建议阅读顺序：

1. 本 README 的产品背景、架构与模块和主播操作手册。
2. Desktop README：Windows 构建、Qt Multimedia、音频和重绘细节。
3. Live Assistant README：设置、事件、模型任务和降级。
4. Clip Pipeline README：证据融合、Worker、渲染和恢复。
5. 其余模块 README：输入、输出、失败降级、外部仓库适配与下一步。

验证命令

make test                  # Python 单元/契约回归
make verify                # test + Console production build
make visual-test           # API 启动后执行 Web desktop/mobile/output 回归
make desktop-visual-test  # Qt Quick 离屏窗口矩阵