3D球场项目 (四)
项目终于来到了落地环节。 在3D球场项目 (三)里，我们用一段离线 PBP 数据 + 一次 LLM 调用，把"导演 Agent"的雏形跑了起来。Demo 阶段的脚本是离线生成、整段 导入的；那时的 LLM 既负责"想象画面"，又顺手把动作、镜头、音效、解说词都打包了。 但项目一旦从 Demo 推到线上，导演 Agent 立刻面对三件事： Opta 数据是按 Point 持续推过来的，不会一次性把一场比赛喂给大模型； 大模型 会失败、会延迟，一旦卡住，球员就只能停在 idle； 客户端会断流、会重连，需要一个"刚才那一拍发生了什么"的回放接口。 上一章末尾提到的三个坑——player 卡 idle、两人一直来回发球、长链断了客户端不知道 怎么补——本质都来自这三件事。线上版本的 livecast 服务（基于 tRPC-Go）做了一次完整的 工程化：导演 Agent 不再是单一 LLM，而是 确定性脚本层 + LLM 解说层 + 双重下发保险 的组合。本篇就讲这套组合怎么搭起来。 一、网球数据是怎么进来的 NBA 那边的 PBP 是 单条 投递：上游每发生一个篮球事件，就经 Kafka 推一条消息过来。 但网球数据天然是 按回合聚合 的——Opta 在一个 Point（一个回合）结束之后才会一次性 把这一拍涉及的所有事件下发，所以服务端也用了批量消费通道： Kafka topic: pbp_flow └─ FlowConsumer.BatchHandle(msgs []*sarama.ConsumerMessage) └─ livecastSvc.ProcessBatchPBPFlow(payloads [][]byte) 进入 ProcessBatchPBPFlow 之后，先按 mid（match id）做二级分组、过滤掉非网球的批次， 再交给真正的 pipeline。两道闸门决定一场比赛的事件能不能走 3D 流水线： ...