心路历程：从"能演示"到"敢上播"

最初构思 SparkLive Studio 时，我们思考的并不是"怎样再做一个 AI 直播工具"，而是一个更根本的问题：

当直播间同时涌入画面、声音、弹幕、商品信息、OBS 状态和设备告警时，AI 能不能真正理解现场，并成为主播可以信任的协作者？

今天的直播工具并不少。字幕、切片、数字人、弹幕分析、OBS 控制，每个方向都有成熟项目。但对主播来说，这些能力仍然是割裂的：一个工具听声音，一个工具看画面，一个工具处理弹幕，真正需要做决定时，仍然要由主播在多个窗口之间来回切换。
因此，我们决定把 NVIDIA DGX Spark 打造成直播现场的本地多模态 AI 控制中心：持续理解直播上下文，让多个窄职责 Agent 分别承担导播、互动、商品、安全、运维、剪辑和虚拟人等工作，再由统一控制面协调它们。

第一次重要取舍：不重复造轮子，而是解决"协作"问题

黑客松时间有限，最容易做出的选择，是把大量模型和开源项目拼接在一起，形成一个功能丰富的 Demo。
但我们很快意识到，真正有价值的并非重新实现 OBS、FFmpeg、Whisper、OCR 或数字人引擎，而是让这些能力共享同一份直播上下文，并能够安全地协作。
于是，我们把项目定位为一个 Agent 编排层。

摄像头、麦克风、弹幕和 OBS 状态先被转换为结构化事件；不同 Agent 根据各自职责生成建议；任何可能影响直播的动作，都不能由模型直接执行，而必须依次经过 ActionProposal → Policy Gateway → Tool Registry → Audit 的审计流程。
低风险提示可以自动完成，公开发言、商品卡和虚拟人台词需要人工确认，改价、改库存等高风险动作则在 MVP 阶段直接阻断。
这个决定让项目看起来没有那么"炫技"，却逐渐成为了 SparkLive Studio 最重要的灵魂：我们不是让 AI 获得无限权限，而是让它成为一个可解释、可确认、可中断、可审计的直播协作者。

从"功能能跑"到"结果可信"

项目早期，我们很快完成了模拟采集、事件总线、七类 Agent、策略系统、审计记录和 React 操作台。最小闭环已经能够运行，看起来似乎已经完成了一个不错的演示。

但我们并不满足。

我们给项目定下了一条有些"苛刻"的原则：

Mock 必须明确标注为 Mock；模型未加载不能显示生成结果；平台未授权不能声称已经接通；用户能够点击的按钮必须连接真实行为。

这意味着我们不能用一张预制图片冒充实时生成，也不能用一个漂亮的进度条掩盖后台停滞。README 中始终明确区分真实实现、学习模式、模拟能力和尚未完成的部分。
这种诚实让开发过程变得更慢，却也迫使我们不断从"演示思维"走向"产品思维"。

那些差点让我们停下来的时刻

最难忘的一次故障，发生在一段 49 分 16 秒的录播上。

自动切片任务长时间停留在 94%，超过 6389 秒没有产生新的 checkpoint。最简单的处理方式，是修改进度显示，或者把问题归因于"大模型太慢"。
但我们选择从 Worker、VAD 输入、Whisper 批处理、GPU 占用和系统换页开始逐层排查。最终发现，短音频会被 Whisper 填充到 30 秒，而原来的进度只是时间估算，并不能反映真实工作量。
我们重新设计了 ASR 小批次 checkpoint、心跳、停滞判断、有界重试和真实单元进度。修复后，同一段故障录像被拆分为 18 个批次，在 339.924 秒内完成 280 个语音片段的识别。
这次经历让我们明白：一个优秀的 AI 产品，不只是能够给出结果，还必须让用户知道它正在做什么、做到哪里、失败后能否恢复。

另一次挑战来自实时重绘。

StreamDiffusionV2 Worker 加载后会占用约 15.8 GiB GPU 显存。如果只追求演示效果，我们完全可以在每次演示结束后重启服务。但我们不希望主播在直播现场依赖这种解决方案。
因此，我们为 Worker 增加了惰性加载、媒体 lease、输入超时、控制超时、断连回收和父进程死亡清理。优化后，服务空闲时只占用约 50 MiB 内存；停止生成后约 1 秒即可释放 Worker；即使父进程被强制终止，GPU 子进程和 CUDA 资源也能够被完整回收。
我们逐渐意识到，真正困难的从来不是"调用一次模型"，而是让模型在摄像头断开、网络波动、用户取消、进程崩溃和资源竞争时，仍然表现得像一个可靠的软件系统。

我们开始真正站在主播的位置思考

随着项目推进，我们不再只关注后端架构，而是开始反复问自己：

• 主播正在说话时，能看多少条提示？
• 模型加载期间，是否应该开始采集麦克风？
• 直播已经结束时，最后一句字幕会不会丢失？
• 上传长视频中途断网，是否必须从头开始？
• OBS 只需要生成画面时，为什么要看到所有控制按钮？
• AI 给出了错误建议，主播能否立即接管？

这些问题推动我们完成了 Windows 原生主播工作台、紧凑主播提示窗、OBS 独立输出窗、实时语音转写、弹幕重点分析、断点续传、只读诊断终端和直播后自动切片流程。
直播过程中，系统可以协助主播管理流程、聚合问题、发现弹幕热点、生成字幕、提示风险并记录高光；直播结束后，同一份时间线、转写、弹幕趋势和人工 marker 又会成为自动切片的证据。

我们最终在 DGX Spark 真机上完成了 Whisper、Qwen3.5 文本与视觉模型的真实链路验证，并让一段 70 秒的真实输入生成了带字幕的 60 秒竖屏视频草稿。
在此基础上，我们又加入了 StreamDiffusionV2 实时重绘：摄像头画面可以进入本地生成管线，生成结果通过独立窗口交给 OBS 捕获；参考图、模型切换、Prompt 热更新、运行指标和失败回滚都被纳入同一个受治理的工作流。

我们学会了克制，也学会了对结果负责

开发过程中，我们遇到过很多"看起来可以绕过去"的问题。

某个实验模型生成黑图时，我们没有关闭 safety checker 来制造成功结果，而是把它明确标记为实验性能力。
Wan Causal DiT 不兼容现有 IP-Adapter 时，我们没有让"上传参考图"这个按钮继续可用，而是在前端和 API 中同时禁用。
平台社区接口连接成功后，我们也没有把它描述成官方接入，而是继续限定在授权的学习模式，并保留 mock/replay 作为默认路径。
Windows、OBS 真机联调、官方平台授权、实时多帧分析和长时间压力测试中尚未完成的部分，也都被完整写进了项目文档。

因为我们相信，黑客松作品的优秀，不应该建立在"假装一切已经完成"之上。

真正优秀的工程，是知道哪些已经完成、哪些经过验证、哪些仍有风险，以及下一步怎样继续演进。

从一个 Demo，成长为一套可以继续发展的系统

回头看整个过程，SparkLive Studio 已经从最初的架构草图，成长为包含十四个后端模块、Web 控制台、Windows 原生工作台、本地模型 Worker、实时媒体服务和自动切片流水线的可运行雏形。
自动化测试也从最初的几十项逐步增长到接近 200 项，并覆盖接口契约、策略权限、模型状态、断线恢复、进程生命周期、桌面交互和视觉回归。

但比功能数量更重要的，是我们的思考发生了变化。

一开始，我们问的是：

"AI 能不能进入直播间？"

后来，我们问的是：

"AI 能不能在不打断直播的情况下工作？"

再后来，我们开始问：

"当 AI 判断错误、模型不可用、网络中断或者资源不足时，主播是否仍然拥有最终控制权？"

SparkLive Studio 最终给出的答案，不是一个无所不能的"大模型助手"，而是一套本地优先、职责分离、人机协作、风险可控的直播智能系统。

它可能还不是一个已经完成商业化交付的产品，但它已经证明了一条可行的路线：

AI 不仅可以理解直播，也可以在明确边界、人工监督和完整审计之下，真正参与直播生产。

这就是我们一路开发 SparkLive Studio 最大的收获，也是我们希望带给黑客松评委的答案：

真正值得进入直播现场的 AI，不应该只是聪明，更应该可靠。