← 回總覽

淘宝直播数字人 AgenticRL 实践:从 RLVR 到 MultiAgent RL

📅 2026-07-13 16:29 大淘宝技术 人工智能 16 分鐘 19016 字 評分: 92
AI Agent 强化学习 大模型蒸馏 RLVR Multi-Agent RL
📌 一句话摘要 本文介绍淘宝直播数字人从 Workflow 升级到 Agentic 架构,通过 AgentTuning 蒸馏降低延迟、RLVR 减少幻觉及创新 Multi-Agent RL 算法,实现低延迟高拟真互动,事实正确性提升 4.1pt。 📝 详细摘要 文章详细阐述了淘宝直播数字人互动架构的演进:首先从传统静态 Workflow(意图识别―检索―生成)升级到动态 Agentic 架构,实现全局上下文感知、多次按需工具调用与自我纠错以及多模态响应;随后通过 AgentTuning 蒸馏将千亿参数教师模型的思维链迁移至小模型,使单次工具调用耗时压缩至 0.3 秒,端到端延迟降至 1.7

Title: 淘宝直播数字人 AgenticRL 实践:从 RLVR 到 MultiAgent RL | BestBlogs.dev

URL Source: https://www.bestblogs.dev/article/a91a414388?amp%3Butm_medium=feed&%3Butm_campaign=resources&%3Bentry=rss_article_item

Published Time: 2026-07-13 16:29:00

Markdown Content:

!Image 1: 图片

本文介绍了淘宝直播数字人互动从传统静态 Workflow 架构向动态 Agentic 架构的升级实践。通过融合 LLM 与 Agent 自主规划能力,利用 AgentTuning 蒸馏降低延迟、RLVR 减少幻觉,并针对业务挑战研发 Multi-Agent RL 算法,将工具调用与回复模型分离进行协同强化学习优化。最终实现了低延迟(1.79秒)、高拟真度的深度互动,显著提升了事实正确性、帮助性及多轮对话用户比例,打造了下一代数字直播范式。

!Image 2: 图片

摘要

针对目前数字人交互深度不足,以及传统 Workflow 互动方案灵活度差、泛化能力弱、维护成本高的问题,我们致力于融合LLM的世界知识与 Agent 的自主规划决策能力,赋予数字人“Agent 大脑”,实现极具情绪价值和专业度的深度互动。长期愿景是希望构建一个具备感知、思考、表达与执行闭环的类真人主播 Agent ,使其不仅能精准理解复杂语境,更能基于实时反馈自主生成高质内容,打造行业领先的高拟人、强交互、高增长的下一代数字直播范式。

* 第二章——Workflow 架构升级到 Agentic 架构所做的工作:重新设计了新的Agentic 架构,使用 AgentTuning 监督微调(sft)将大模型能力迁移到低延迟的小模型、使用 RLVR 降低模型基于工具调用信息回复幻觉从而达到可靠上线的标准,通过这样的优化手段,在 AB 实验中,Agent 的平均端到端延迟降低到了 1.79 秒(相对下降 1.36 秒),多轮对话用户比例提升 2.76%;

* 第三章——基于阿里自研 infra 在 Agentic RL 下的探索与实践,基于 ROLL 实现 Agentic RL 算法优化 Agent 模型在环境中进行多轮工具调用并基于调用结果进行回复的能力,该章详细介绍了我们在 AgenticRL 搭建过程中的工程细节以及在业务落地时遇到的现实挑战;

* 第四章——针对在 Agentic RL 在业务场景下落地所遇到的问题,我们研发了适配业务的 Multi-Agent RL 算法:工具调用相关奖励不适合用于优化回复能力、回复质量相关奖励同样也不适合完全拿来优化工具调用能力,为了应对该挑战,我们针对业务特点设计了 Multi-Agent RL 多智能体强化学习算法,将工具调用模型与最终回复模型区分为两个 Agent,并使用不同的奖励对这两个模型进行在线协同强化学习优化,Multi-Agent RL 良好解决了单 Agent GRPO 在复杂奖励下难收敛的问题,最终在回复指标中相较于监督微调模型事实正确性提升 4.1pt,帮助性提升 23.6pt,工具调用合理性提升 1 8.2pt。

!Image 3

从Workflow到Agentic的升级

### ▐业务场景介绍

!Image 4

* 观众在数字人直播间发送弹幕时,数字人主播会基于直播间商品信息、商家预设问答对等信息对观众进行弹幕和口播的回复;

* 我们的算法在这个场景下控制数字人主播对观众的互动行为,包括要回复什么、要不要调整讲品顺序到观众想听的商品等。

### ▐框架升级背景介绍

面对快速变化的直播业务,原有“意图识别—检索—生成”的静态 Workflow 架构*已遭遇严重瓶颈,主要体现在三大维度:

* 系统灵活性差,迭代受限:依赖人工标注,新增1个意图需2个月时间进行迭代,预置 FAQ 利用率不足2%,难以适应业务的快速迭代。

* 上下文感知弱,易死胡同:无法联动“宝贝口袋/讲解文案/历史弹幕”等多源信息,一旦意图误判无法反思回退,只能机械抛给人工客服。

* 并发调度缺失,能力遇颈:无法处理直播间高频的多弹幕并发,扩展更高阶的动作/语气交互极其困难。

破局点: 依托 Agentic 技术爆发(30B MoE 模型在 单卡 H20 上部署后的吞吐已达 140 tokens/s,基座模型的 Agentic 能力大幅提升),我们具备了将静态工作流升级为动态决策、具备反思与上下文感知能力的 Agentic 架构的技术时机,全面推动数字人向 Agent 化迈进,提高数字人智能化的天花板。

### ▐架构优化

完成了从 Workflow 架构到 Agentic 架构的升级:

* 感知域:单维度匹配 → 全局上下文感知(弹幕+历史+商品信息融合)

* 决策域:单次死板分类 → 多次按需工具调用与自我纠错(反思机制)

* 执行域:单意图话术 → 多模态响应(调图、调顺序、融合讲解文案)

* 为了让大家更好的了解我们的agent的执行流程,这里给出一个,Agent 完整 trajectory 的示例: // 注:本示例为脱敏版本。系统提示词与样例输入保留;真实检索结果(商家名/价格/库存/条形码)及后续完整 trajectory 已替换/省略 [ { "role": "system", "content": "\n## 指令\n你是一名淘宝数字人主播,你现在正在运营这个直播间,并且你有很多工具可以调用,请选择调用一些工具获取更多信息用于更好的回复观众的问题。\n## 要求\n1. 你需要理解观众的问题,明确观众想问什么,你需要显示的补全观众想问的真实问题\n2. 如果观众问的问题能够调用工具搜集资料来回答那么就调用工具搜集资料\n3. 如果信息已经搜集完毕或者信息不足需要向观众进行多轮澄清,就调用回复规则查询工具来查询不同意图类型问题的回复规则,根据查询到的规则回答问题\n4. 同一个工具不要使用两次以上,如果在历史中已经调用了两次相同的工具那么不应该继续调用了,你需要保持使用工具的高效性,因为需要实时对观众进行回复\n5. 在进行最终回复前必须先查询回复规则\n" }, { "role": "user", "content": "\n## 真实输入\n{\n\"当前商品名\":超市定制伊利金典纯牛奶250ml*24盒整箱儿童学生高端营养礼盒,\n\"对话历史\":[],\n\"观众问题\":索尼xm4和5哪个降噪好呢,\n\"相关预置FAQ\":[]\n}\n\n## 现在开始\n请先按照要求进行一步一步思考,通过调用工具收集更多信息用于回答观众问题\n", }, { "role": "assistant", "content": "\n<tool_call>\n{\"name\": \"search_product_by_keyword\", \"arguments\": {\"keyword\": \"索尼xm4\"}}\n</tool_call>\n\n<tool_call>\n{\"name\": \"search_product_by_keyword\", \"arguments\": {\"keyword\": \"索尼xm5\"}}\n</tool_call>\n" }, { "role": "tool", "content": "已找到相关商品:[{\"商品名\": \"<示例商品名>\", \"商家名\": \"某商家\", \"券后价\": , \"库存\": \"\", \"商品条形码\": \"***\", \"链接号\": <编号>}](注:真实检索返回的多条商家/价格/库存/条形码数据,以及后续查询回复规则、最终回复等 trajectory 内容,为对外脱敏已省略)" } ]

架构的升级带来的优势是明显的,我们以实际用户 query 为例,从以下几个方面进行对比:

* 通用优势

!Image 5

* 直播特色优势

* 支持多弹幕回复:得益于 Agentic 架构的升级,数字人互动能够支持高并发自适应工具调用与多维信息逻辑聚合,从而将碎片化的用户提问转化为结构化、高质量的统一回复。因此面对刷屏提问,Agent 能一脑多用,一次性汇总回复多个不同用户的商品问题(补贴政策+赠品详情+物流时效等)。

!Image 6

* 融合文案信息回复:直播间用户问题往往与 直播正在讲解的内容高度相关。得益于 Agentic 架构的灵活性和全局上下文感知能力,我们能够实时感知当前数字人口播文案,结合文案上下文更深刻地理解用户真实意图并给出更准确的回复。

!Image 7

### ▐模型优化:AgentTuning与RLVR

我们自研了一套 Agent 模型优化方案,来满足直播互动极低的延迟要求,并提升互动回复的正确性与帮助性:

* 攻克延迟(AgentTuning 蒸馏):引入大的教师生产思维链路(Trajectory),蒸馏至 30B-A3B 小模型。单次工具调用耗时压缩至 0.3s,单卡 H20 部署下解码吞吐达 140 tokens/s,满足直播互动时效性要求。

* 攻克幻觉(互动回复模型 RLVR):构建直播互动域的测评 Metric,通过设计正确的逻辑奖励模型,引导回复模型学习生成更具“正确性”与“帮助性”的回复,杜绝直播带货中的“乱回复、乱承诺”幻觉问题。

* AgentTuning蒸馏

Agent 具备多轮反思机制,会带来额外的反思时间开销,这在数字人互动中带来极大的延迟挑战。我们通过 AgentTuning 蒸馏的方式使得小模型具备接近千亿参数大模型的互动 Agent 的自 主规划、工具调用、反思决策能力。

!Image 8

* 教师模型在 Agent 推理过程中与环境进行多轮交互,采样出完整的 agent 执行 trajectory,其中,我们将大模型的工具调用及回复能力分别蒸馏至两个 Qwen3-30B-A3B 的小模型中;

* 为了追求低延迟,学生模型均采用 Instruct 模型,在蒸馏时剔除掉了教师模型的思考部分序列:

* 工具调用模型仅蒸馏教师 Agent 的工具调用生成部分,截取最后一轮工具调用前的 trajectory,并 mask 掉工具调用结果;

* 回复生成模型仅蒸馏教师 Agent 最终回复生成部分,mask 掉回复前的所有序列。

* 回复模型RLVR

AgentTuning 训练后的模型已具备较优秀的自 主规划、工具调用和反思决策能力,但由于训练为监督学习范式,模型回复的事实正确性和帮助性仍有不少优化空间。我们以 AgentTuning 后的模型作为基模型对其中的回复模型进行强化学习训练,对 最终回复使用正确性、帮助性以及长度奖励进行 GRPO 强化学习。目的是直接在回复阶段优化正确性、帮助性,降低幻觉风险并拟合我们希望引导的偏好,最终产出满足上线条件的 Agent 链路模型。

!Image 9

* 输入数据为教师模型预先打标好的工具调用链,对于一条前缀工具调用链模型 rollout 出多条回复组成一组;

* 对于每个回复进行事实正确性和帮助性的打分(可以参考 section 2.3.3),并在组内计算均值与标准差算出组内优势,根据优势计算出 loss 对模型进行优化;

* 整体目标:

* 回复模型尽可能减少幻觉,按照工具调用结果进行回复;

* 为避免模型为了降低幻觉变得过于保守,增加帮助性鼓励模型更多的满足观众实际需求;

!Image 10TAKEAWAY:我们基于 ROLL 实现上述算法流程,取教师模型采样出的 trajectory 截去最后回复保留前缀 messages[:-1]作为训练数据,tokenizer.apply_chat_template 会将 message 格式的数据进行 format,rollout 时仅需生成最后一步回复,而 RLVR 也仅针对最后回复进行优化。

* 评测指标

!Image 11

* 测评数据集

测评数据集来自于对线上流量的脱敏、筛选和清洗,测评指标采用事实正确性以及回复帮助性。

* 模型优化效果

!Image 12

可以看到 Agent 模型在互动回复的正确性和帮助性上对比 Workflow 方案有显著提升,同时也超过了顶尖开闭源模型在我们互动回复场景下的效果(Gemini-2.5-pro 和 Qwen3-235B-A22B),进一步也表明了我们自研 Agent 优化方案的有效性。

### ▐业务效果

* 人工对比:使用 Agent 线上流量在 workflow 服务上进行流量回放产出相同输入下的回复结果进行对比:

!Image 13

* 延迟对比:耗时统计(单位:秒)

* Agentic 架构采用全 Instruct 模型,原 Workflow 最终生成回复模型为 Thinking 模型,Agentic 架构由于前置已经执行了多次大模型推理决策,具有规划和工具选择能力,不再是一股脑的检索信息进行回复,最终生成模型不需要像 Workflow 那样为前置未知情况兜底;

* 同时得益于之前延迟优化上所做的工作,不管是平均延迟还是 P99 长尾延迟都相较于 Workflow 大幅降低。

!Image 14

!Image 15

Agentic RL实践

### ▐背景

第2章中所上线的 Agent,工具调用模型采用 AgentTuning 的方式进行监督微调蒸馏训练,这种方式尽管直接有效,但是也会带来一个根植于其机制的缺点,学生模型的工具调用乃至于意图理解能力始终将受制于教师模型,因此,我们希望对于 Agentic RL 算法进行探索,使得工具调用能力能够在仿真环境中得到训练,达到超越教师模型的新上限。

### ▐端到端Agentic RL方法

!Image 16

Rollout 阶段:

  • Policy 模型在模拟环境中进行多轮工具调用交互,最终以获取回复规则并产生非工具调用回复为结束标志;
  • 针对每个 rollout 计算工具调用与最终回复奖励,并计算组内优势;
训练阶段:
  • 仅针对包含工具调用和最终回复的模型生成部分序列计算 loss,其余包含输入数据、工具返回序列均 mask 掉;
  • 采用初始化 reference model 计算 KL 散度,重要性采样部分与基础 GRPO/PPO 设置无异;
  • 参数由训练模型更新至推理模型继续下一轮 AgenticRL 训练,Agent 模型在训练过程中同时优化工具调用与回复能力。

### ▐仿真环境搭建与工程实现

在 ROLL 框架下,Agentic RL 仿真环境的构建逻辑可被解耦为两大块,训练侧与远程沙盒环境侧:

* 训练集群 训练侧: 负责模型训练的核心闭环。主要职能包括:驱动 Rollout 线程生成用于训练的完整轨迹(Trajectory)、利用奖励模型进行评分(Reward Scoring)、对非训练 Token 进行掩码处理(Token Masking),并将处理后的序列与分数传输至训练阶段。

* 远程沙盒环境侧: 负责承载复杂的外部环境交互。主要职能是处理 训练集群 线程无法直接模拟的任务,包括访问受限接口(如 内部 RPC 服务)、维护有状态的容器(如 Computer Use 环境)、或运行即时模拟器(如游戏环境)。

整体训练与交互流程包含以下四个关键步骤:

* Step 1:环境初始化与连接建立:训练进程部署于 训练集群,每个 Rollout 线程在初始化阶段会独立映射一个仿真环境实例,通过向 仿真环境平台 服务发送请求以建立直播间环境,并拉取基础信息完成语义向量库构建等远程工具链的初始化。

* Step 2:多轮交互与轨迹生成 (Rollout):进入 Rollout 阶段,训练线程调用部署于进程内的 vLLM 或 Sglang 引擎进行推理生成,并在解析出工具调用请求后,跨网络访问沙盒服务获取执行结果。这一过程构成了训练线程与远程环境之间的多轮闭环交互,模型根据环境反馈不断调整策略,直至达到最大交互轮次或触发特定规则工具(如“获取最终回复”)从而结束当前Rollout。

* Step 3:奖励评估与数据处理:Rollout 结束后,系统通过 云访问协议 调用 内部大模型 作为 LLM Judge,对 Agent 在模拟环境中的全流程表现进行评估并给出标量 Reward。与此同时,算法侧需要对生成的 Trajectory 进行精细化的 Mask 处理,将非模型生成的工具调用结果、系统提示词及输入 Token 等部分进行掩码屏蔽,确保后续的训练梯度仅作用于模型策略生成的有效 Token。

* Step 4:优势计算与模型更新:最终,自定义代码将处理好的 Token 序列、Mask 序列以及该 Trajectory 的整体 Episode Score 返回给 ROLL 框架。框架底层会自动基于这些数据计算优势函数(Advantage)与损失(Loss),并调用 Megatron 后端进行分布式的模型参数优化更新,并在更新完成后同步参数到推理引擎(vLLM/Sglang),完成一次完整的训练迭代。

!Image 17TAKEAWAY:得益于 ROLL 良好的封装性与灵活的可拓展性,算法仅需自行实现 rollout 部分并给出 mask 好的序列(决定哪些 token 会被训练)与 reward 打分部分既可跑通 Agentic RL 的基本训练。(tokenizer.apply_chat_temlate 的 mask 不一定能满足需求,最好是自己写 mask 去 mask 掉不希望被训练的 token)

!Image 18TAKEAWAY:早期阻碍训练收敛的最大因素并非算法的设计,而是环境的稳定性与 reward 的设计,模拟环境不稳定时几乎无法拿到任何正向结论,reward 则需要足够有区分度且确实能有效区分好的 rollout 与不好的 rollout,这在业务落地中反而是最为 dirty 且困难的部分。

### ▐业务落地的局限与挑战

我们初期使用 Agentic RL 进行端到端训练并没有能够训练出具备良好效果的模型,主要是因为以下原因:

* 最终的正确性、帮助性奖励更多的是偏向回复模型而设计的,而模型的 Agentic 能力并没有在其中得到清晰反馈而良好的训练,反而因为不恰当的奖励而变得更差;

* 直接在最终奖励中加上基于 llm judge 的工具调用奖励后,虽然能带来对于工具调用的反馈,但由于 llm judge 不稳定的特点,奖励也变得更加模糊,强化学习训练变得更加难以收敛;

* 同时,工具调用与回复所需要的能力截然不同——工具调用更多要求模型对于观众弹幕以及上下文的意图理解能力、工具调用准确度以及观察工具返回结果后的反思能力,而回复模型更多关注的是低幻觉、对于观众真实意图的满足以及回复自然度。

!Image 19

Multi-Agent RL多智能体协同强化学习

* 基于如上挑战与发现,我们采用了多智能体强化学习算法 Multi-Agent RL ,针对业务特点,将工具调用模型与最终回复模型区分为两个 Agent ,并使用不同的奖励对这两个模型进行在线协同强化学习优化,由单模型效果优化改进为整系统协同优化。

### ▐多智能体协同强化学习优化方法

* 目前我们的互动 Multi-Agent RL 实现如下,人为的分为了工具调用模型以及回复(总结)模型,在训练中,工具调用模型仅优化工具调用部分,回复模型仅优化回复部分:

!Image 20

* 工具调用模型在模拟的直播互动环境中进行多轮交互,得到 K 条 Agent 工具调用路径,工具调用阶段以获取回复规则作为结束标识,如果工具调用阶段未获取回复规则则不会产生回复;

!Image 21

Rollout阶段:

  • 工具调用模型和环境服务(内部仿真环境平台)进行多轮交互,在环境判断是否工具调用结束进行回复(以超过调用轮次限制以及调用获取回复规则工具作为终止符号);
  • 工具调用模型调用结束后,回复模型以工具调用链作为前缀,按照回复规则生成回复;
  • 基于完整 trajectory 分别为工具调用阶段与回复阶段计算 reward;
  • 并基于计算好的 reward 分别为工具调用模型与回复模型赋值组合加权 reward 并计算组内优势。
训练阶段:
  • 对于工具调用模型:截取最终回复前最后一轮工具调用的 trajectoy,mask 掉其中工具调用返回结果部分,采用对应计算出的工具优势计算 loss;
  • 对于回复模型:取完整 trajectory,mask 掉非最终回复前置部分,采用对应计算出的回复优势计算 loss;
  • 对于这两个模型都采用各自的初始化 reference model 计算 KL 散度,重要性采样部分与基础 GRPO/PPO 设置无异。
  • 针对两个模型分别将参数由训练模型(megatron)更新至推理模型(vllm),并继续下一轮训练。
!Image 22TAKEAWAY:Multi-Agent RL 如果没有 bug 的话,会比 Agentic RL 更容易训练收敛,相当于把一个端到端的 Agentic RL 任务划分为了多个近似于 RLVR 的子任务。

!Image 23TAKEAWAY:Multi-Agent RL 的算法实现与 Step-Reward 的实现高度类似,如果不考虑不同 Agent 模型参数不同,可以直接使用 Step-Reward 来实现 Multi-Agent RL。如 GiGPO 算法已在 ROLL 中有现成实现。

!Image 24TAKEAWAY:多模型 checkpoint 自动上传 OPENLM MOS 是一个难点,我们使用cluster_nameckpt_id维度区分了不同模型的 checkpoint,并复用了 ROLL 中的自动上传 MOS 机制来实现的多模型自动 checkpointing。

### ▐奖励函数设计

!Image 25

### ▐模型训练效果

!Image 26

* 图中使用相同的奖励对于单 Agent Agentic RL 和多 Agent Agentic RL 进行了训练实验,均使用 GRPO 作为模型优化算法:

* 单 Agent 对4个奖励进行加权求和的方式计算组合 reward;

* 多 Agent 的回复模型采用正确性和帮助性的加权求和,工具调用模型采用规则遵守和工具调用的加权求和;

* 受限于多奖励混杂问题,单 Agent Agentic-RL 很难有效提升并训练收敛,而 Multi-Agent RL 在机制上解决了这个问题从而达到了良好的训练效果:

* 事实正确性和回复帮助性的奖励更多的是针对回复模型测评的奖励,而根据最终回复是否出现幻觉去给工具调用能力打分是极不合理的;

* 工具调用合理性仅衡量工具调用模型的能力,用该奖励来给最终回复打分同样也是极不合理的。

### ▐实验结果*

!Image 27 本实验与第2章中的实验为分别设计的独立实验,主要改动来自于对事实正确性、回复帮助性 LLM Judge 的迭代升级以及蒸馏教师模型采用了更加强大的 glm 4.7 模型;

* 为了解决此前系统仅关注最终回复效果而导致工具调用能力在优化后下降的缺陷,我们单独将工具调用合理性这一LLM Judge 指标作为测试集指标以监控模型的工具调用能力。

* Multi-Agent RL 方法最终训练了两个模型,回复模型相较于 sft 模型正确性提升 4.1pt,帮助性提升 23.6pt,工具调用模型的工具调用合理性提升 18.2pt,有效提升多智能体系统整体性能。

### ▐消融实验

!Image 28

* 使用固定住工具调用模型,仅对最终回复模型进行 RLVR 的方法作为对照组进行消融实验,以验证提升不仅仅来自于回复模型风格对奖励函数的拟合,同样受益于前置工具调用模型的提升;

* 在实验中,Multi-Agent RL 方法相较于固定工具调用模型仅 rlvr 训练回复模型的方法在事实正确性上提升 5.6pt,在帮助性上提升 6.6pt,而工具调用合理性保持了对 sft 模型的优势(+18.2pt)。

!Image 29: 图片

总结与未来展望

* 总结:

* 为了解决此前所搭建的 Workflow 互动架构的不灵活、感知弱以及前两个劣势带来的能力瓶颈的问题,我们将数字人互动架构由 Workflow 升级为了 Agentic,为了解决 Agent 多次调用大模型延迟高的问题,我们将千亿参数级大模型的能力蒸馏至了更小规模的 MoE 模型,实现了亚秒级的回复延迟,为了解决 Agent 回复过度承诺等幻觉问题,我们使用 RLVR 对模型回复能力进行优化,有效提升了模型的事实正确性与帮助性,并在 AB 实验中带来了有效的业务提升最终成功推全上线。

* 上线后我们进行了 Agentic RL 端到端优化 Agentic 系统的探索,完成了仿真环境的搭建并基于我们的场景完成了 Agentic RL 算法实现,针对最终回复奖励难以衡量模型 Agentic 能力的问题,我们设计了基于 llm judge 的工具调用合理性奖励,为了利用这些更模糊的奖励来优化 Agent 系统中不同模块的能力,我们将原有的单 Agent 系统改造为了工具调用+回复的 MultiAgent 系统,设计并实现了 Multi-Agent RL 算法,使得整个 Agent 系统能在模拟环境中对各模块协同优化最后得到了稳定且显著的提升。

* 当前互动算法局限与未来展望:

* 整体架构由 Workflow 升级为 Agent,基础能力已完成闭环,后续需重点扩充直播数字人专属工具,设计高阶交互功能,以充分释放 Agentic 架构及 LLM 的强大潜能;

* 当前 MultiAgent 基本是来自于单 Agent ReAct 架构的阶段性解耦策略,更接近于 Dr.MAS 这样的串行 MultiAgent,类似于 sub-agent、agent-swarm 等并行化 MultiAgent 优势仍未体现出来;

* 目前的训练方式(包括监督微调或是强化学习)都是 task-specific 的,没办法新增工具或者新增信息后直接使用原模型,后续一方面需要想办法优化出更通用的模型,另外一方面将考虑 skill 的方式接入工具,使得新工具可以通过渐进式披露的方式被自然接入。

!Image 30

团队介绍

本文作者语瀚,来自淘天集团-直播AIGC团队。作为直播电商智能化领域的先行者,始终致力于通过AI原生技术创新重构电商直播场景中的人货场交互范式。团队基于对大语言模型研发、多模态语义理解、语音合成、数字人形象建模、AI工程化部署及音视频处理技术的深厚沉淀和积累,已搭建起覆盖直播全链路的AI技术矩阵。自主研发的数字人直播解决方案通过商业化验证,成功实现从技术研发到商业变现的完整闭环,累计服务上千家商家。

查看原文 → 發佈: 2026-07-13 16:29:00 收錄: 2026-07-13 20:00:38

🤖 問 AI

針對這篇文章提問,AI 會根據文章內容回答。按 Ctrl+Enter 送出。