淘宝直播数字人进化之路：从静态流程到动态Agentic架构
直播间里的数字人主播，怎么才能更“聪明”地跟观众互动？这个问题，淘宝直播团队给出了一个相当硬核的答案。从传统的静态Workflow架构，到如今基于强化学习的动态Agentic系统，这背后是一条从“能说话”到“会思考、能反思、能协作”的进化路径。本文完整披露了这一过程中的技术演变、关键算法与工程实践。
核心看点包括：
- 从静态Workflow到动态Agentic架构的升级
- AgentTuning蒸馏与RLVR在延迟和幻觉优化上的工程实践
- 针对业务挑战研发的Multi-Agent RL解决方案
简单来说，场景是这样的：观众在数字人直播间发送弹幕，数字人主播需要基于直播间商品信息、商家预设问答等综合信息，实时做出弹幕和口播回复。而算法，则要控制数字人主播的互动行为——包括回复什么、是否要调整讲品顺序，以满足观众需求。
框架升级：旧架构的瓶颈与破局点
原有的“意图识别—检索—生成”静态Workflow架构，已经暴露出三大瓶颈：
- 系统灵活性差，迭代周期长：依赖人工标注，新增一个意图需要2个月时间，预置FAQ利用率不足2%。
- 上下文感知弱，缺乏回退机制：无法联动“宝贝口袋/讲解文案/历史弹幕”等多源信息，一旦意图误判，只能机械抛给人工客服，陷入死胡同。
- 并发调度缺失，能力触顶：无法处理直播间高频的多弹幕并发，扩展更高阶的动作或语气交互极其困难。
破局点在哪？得益于Agentic技术的爆发。30B MoE模型在单卡H20上部署后，吞吐已达140 tokens/s，基座模型的Agentic能力大幅提升。这为将静态工作流升级为动态决策、具备反思与上下文感知能力的Agentic架构，提供了技术时机。
架构优化：从Workflow到Agentic
升级的核心变化体现在三个维度：
- 感知域：从单维度匹配 → 全局上下文感知（弹幕+历史+商品信息融合）
- 决策域：从单次死板分类 → 多次按需工具调用与自我纠错（反思机制）
- 执行域：从单意图话术 → 多模态响应（调图、调顺序、融合讲解文案）
| 原Workflow架构 |  |
| Agentic架构 |  |
为了更直观地理解Agent的执行流程，这里给出一个脱敏后的完整trajectory示例：
// 注：本示例为脱敏版本。
[{
"role": "system",
"content": "## 指令\n你是一名淘宝数字人主播，你现在正在运营这个直播间，并且你有很多工具可以调用，请选择调用一些工具获取更多信息用于更好的回复观众的问题。\n## 要求\n1. 你需要理解观众的问题，明确观众想问什么，你需要显示的补全观众想问的真实问题\n2. 如果观众问的问题能够调用工具搜集资料来回答那么就调用工具搜集资料\n3. 如果信息已经搜集完毕或者信息不足需要向观众进行多轮澄清，就调用回复规则查询工具来查询不同意图类型问题的回复规则，根据查询到的规则回答问题\n4. 同一个工具不要使用两次以上，如果在历史中已经调用了两次相同的工具那么不应该继续调用了，你需要保持使用工具的高效性，因为需要实时对观众进行回复\n5. 在进行最终回复前**必须**先查询回复规则\n"},
{...}]
架构升级带来的优势是明显的。以实际用户query为例，从通用能力和直播特色能力两方面来看：
直播特色优势：
- 支持多弹幕回复：Agentic架构支持高并发自适应工具调用与多维信息逻辑聚合，将碎片化提问转化为结构化、高质量的统一回复。面对刷屏提问，Agent可以“一脑多用”，一次性汇总回复多个不同用户的商品问题（补贴政策、赠品详情、物流时效等）。
- 融合文案信息回复：直播间用户问题往往与直播正在讲解的内容高度相关。Agentic架构的灵活性，使得系统能够实时感知当前数字人口播文案，结合上下文更深刻地理解用户真实意图，给出更准确的回复。
模型优化：AgentTuning与RLVR双管齐下
直播互动对延迟要求极高，同时还要保证回复的正确性与帮助性，避免“乱回复、乱承诺”的幻觉问题。为此，团队自研了一套Agent模型优化方案：
- 攻克延迟（AgentTuning蒸馏）：引入大教师模型生产思维链路（Trajectory），蒸馏至30B-A3B小模型。单次工具调用耗时压缩至0.3秒，单卡H20部署下解码吞吐达140 tokens/s。
- 攻克幻觉（互动回复模型RLVR）：构建直播互动域的测评Metric，通过设计正确的逻辑奖励模型，引导回复模型学习生成更具“正确性”与“帮助性”的回复。
AgentTuning蒸馏：
Agent具备多轮反思机制，这带来了额外的延迟挑战。通过蒸馏，小模型具备了接近千亿参数大模型的Agent能力。
- 教师模型在Agent推理过程中与环境多轮交互，采样出完整的执行trajectory。大模型的工具调用及回复能力被分别蒸馏至两个Qwen3-30B-A3B小模型中。
- 为了追求低延迟，学生模型均采用Instruct模型，蒸馏时剔除掉了教师模型的思考部分序列：工具调用模型仅蒸馏工具调用生成部分；回复生成模型仅蒸馏最终回复生成部分。
回复模型RLVR：
AgentTuning训练后的模型已具备较优秀的自主规划能力，但回复的事实正确性和帮助性仍有优化空间。以AgentTuning后的模型作为基模型，对回复模型进行强化学习训练，使用正确性、帮助性以及长度奖励进行GRPO强化学习，直接在回复阶段优化正确性、帮助性，降低幻觉风险。
- 输入数据为教师模型预先打标好的工具调用链，对于一条前缀工具调用链，模型rollout出多条回复组成一组。
- 每个回复进行事实正确性和帮助性打分，并在组内计算均值与标准差，算出组内优势，根据优势计算loss优化模型。
- 整体目标：回复模型尽可能减少幻觉，按照工具调用结果进行回复；同时避免模型过于保守，增加帮助性，鼓励模型满足观众实际需求。
TAKEAWAY：基于ROLL实现上述算法流程，取教师模型采样出的trajectory截去最后回复，保留前缀messages[:-1]作为训练数据，rollout时仅需生成最后一步回复，RLVR也仅针对最后回复进行优化。
评测指标与效果：
评测数据集来自对线上流量的脱敏、筛选和清洗，指标采用事实正确性以及回复帮助性。
可以看到，Agent模型在互动回复的正确性和帮助性上，对比Workflow方案有显著提升，同时也超过了顶尖开闭源模型（Gemini-2.5-pro和Qwen3-235B-A22B）在互动回复场景下的效果，证实了自研优化方案的有效性。
业务效果：延迟与质量的双重提升
人工对比：使用Agent线上流量在workflow服务上进行流量回放，产出相同输入下的回复结果进行对比。
延迟对比：
Agentic架构采用全Instruct模型，原Workflow最终生成回复模型为Thinking模型。Agentic架构由于前置已经执行了多次大模型推理决策，具有规划和工具选择能力，最终生成模型不需要像Workflow那样为前置未知情况兜底。因此，无论是平均延迟还是P99长尾延迟，都相较于Workflow大幅降低。
Agentic RL：在仿真环境中驯化更聪明的Agent
模型上线后，团队进一步探索了Agentic RL端到端优化。在ROLL框架下，仿真环境的构建逻辑被解耦为训练侧与远程沙盒环境侧：
- 训练集群训练侧：负责驱动Rollout线程生成轨迹、利用奖励模型评分、对非训练Token掩码处理，并将处理后的序列与分数传输至训练阶段。
- 远程沙盒环境侧：负责承载复杂的外部环境交互，包括访问受限接口、维护有状态的容器等。
整体训练与交互流程包含四个关键步骤：
- 环境初始化与连接建立：每个Rollout线程独立映射一个仿真环境实例，完成直播间环境搭建和工具链初始化。
- 多轮交互与轨迹生成：训练线程调用推理引擎，在解析出工具调用请求后，跨网络访问沙盒服务获取执行结果，形成多轮闭环交互，直至达到最大轮次或触发特定规则工具。
- 奖励评估与数据处理：系统调用内部大模型作为LLM Judge，对Agent全流程表现进行评估并给出标量Reward，同时对轨迹进行精细化的Mask处理。
- 优势计算与模型更新：自定义代码将处理后的序列、Mask序列以及Episode Score返回给ROLL框架，框架底层计算优势函数与损失，调用Megatron后端进行分布式模型参数更新，并同步到推理引擎。
TAKEAWAY：得益于ROLL良好的封装性，算法仅需自行实现rollout部分并给出mask好的序列与reward打分，即可跑通Agentic RL的基本训练。
TAKEAWAY：早期阻碍训练收敛的最大因素，并非算法设计，而是环境稳定性与reward设计。模拟环境不稳定时几乎无法拿到任何正向结论，reward则需要足够有区分度——这在业务落地中反而是最“脏”且困难的部分。
Multi-Agent RL：解决单Agent训练的“奖励混杂”难题
初期使用Agentic RL进行端到端训练，并没有取得良好效果。原因在于：
- 最终的正确性、帮助性奖励偏向于回复模型，而模型的Agentic能力并未得到清晰反馈，反而因不恰当的奖励变差。
- 在最终奖励中加入基于LLM Judge的工具调用奖励后，由于LLM Judge的不稳定性，奖励变得更加模糊，训练难以收敛。
- 工具调用与回复所需能力截然不同——前者要求意图理解、工具调用准确度和反思能力，后者关注低幻觉、意图满足和回复自然度。
为解决这一问题，团队将原有的单Agent系统拆分为工具调用模型与回复模型，设计并实现了Multi-Agent RL算法：
- 工具调用模型在模拟环境中进行多轮交互，得到K条Agent工具调用路径，以获取回复规则作为结束标识。
- Rollout阶段：工具调用模型和环境交互后，回复模型以工具调用链作为前缀生成回复。基于完整trajectory分别为工具调用阶段与回复阶段计算reward，并分别计算组内优势。
- 训练阶段：对工具调用模型截取最终回复前最后一轮工具调用的trajectory，mask掉工具调用返回结果部分；对回复模型取完整trajectory，mask掉非最终回复前置部分。两个模型分别采用各自的初始化reference model计算KL散度。
TAKEAWAY：Multi-Agent RL如果没有bug，会比Agentic RL更容易训练收敛，相当于把一个端到端任务划分为了多个近似于RLVR的子任务。
TAKEAWAY：Multi-Agent RL的算法实现与Step-Reward高度类似，不考虑不同模型参数差异时，可以直接用Step-Reward实现。
TAKEAWAY：多模型checkpoint自动上传是一个难点，使用cluster_name以ckpt_id维度区分不同模型的checkpoint，并复用ROLL中的自动上传机制来实现。
奖励函数设计
模型训练效果
- 单Agent对4个奖励进行加权求和，多Agent的回复模型采用正确性和帮助性的加权求和，工具调用模型采用规则遵守和工具调用的加权求和。
- 受限于多奖励混杂问题，单Agent Agentic-RL很难有效提升并收敛。而Multi-Agent RL在机制上解决了这个问题，达到了良好的训练效果。
实验结果与消融
- 本实验与第2章中的实验为独立设计，主要改动来自对事实正确性、回复帮助性LLM Judge的迭代升级，以及蒸馏教师模型采用更强大的glm 4.7模型。
- 为解决此前系统仅关注最终回复效果而导致工具调用能力下降的缺陷，单独将工具调用合理性作为测试集指标。
- Multi-Agent RL方法最终训练了两个模型，回复模型相较于SFT模型正确性提升4.1pt，帮助性提升23.6pt，工具调用合理性提升18.2pt，有效提升了多智能体系统整体性能。
消融实验：
- 使用固定住工具调用模型，仅对最终回复模型进行RLVR的方法作为对照组。Multi-Agent RL方法相较于对照组，在事实正确性上提升5.6pt，在帮助性上提升6.6pt，工具调用合理性保持了对SFT模型的优势（+18.2pt）。
总结与未来展望
总结：
- 为了解决原有Workflow架构的不灵活、感知弱以及能力瓶颈，团队将数字人互动架构升级为Agentic架构。为解决Agent多次调用大模型带来的高延迟，通过蒸馏将千亿参数级大模型的能力转移至更小规模的MoE模型，实现了亚秒级回复延迟。为解决Agent回复的幻觉问题，使用RLVR对模型回复能力进行优化，有效提升了事实正确性与帮助性，并在AB实验中带来了有效的业务提升，最终成功推全上线。
- 上线后，团队进行了Agentic RL端到端优化探索，完成了仿真环境搭建和算法实现。针对最终回复奖励难以衡量Agentic能力的问题，设计了基于LLM Judge的工具调用合理性奖励。为利用这些更模糊的奖励来优化不同模块的能力，将单Agent系统改造为工具调用+回复的Multi-Agent系统，设计并实现了Multi-Agent RL算法，使得整个Agent系统能在模拟环境中对各模块协同优化，最终得到稳定且显著的提升。
当前局限与未来展望：
- 整体架构已完成基础能力闭环，后续需重点扩充直播数字人专属工具，设计高阶交互功能，充分释放Agentic架构及LLM的潜能。
- 当前Multi-Agent基本来自于单Agent ReAct架构的阶段性解耦策略，更接近于串行Multi-Agent，类似于sub-agent、agent-swarm等并行化Multi-Agent的优势仍未体现出来。
- 目前的训练方式（包括监督微调或强化学习）都是task-specific的，无法在新增工具或信息后直接使用原模型。后续一方面需要优化出更通用的模型，另一方面将考虑skill的方式接入工具，使新工具可以通过渐进式披露的方式被自然接入。