3D球场项目 (四)

Sat, 30 May 2026 20:23:44 +0800

项目终于来到了落地环节。在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 流水线：

TRPC-Go on Last Stand

3D球场项目 (四)

一、网球数据是怎么进来的