国产大模型落地门店导购：从零搭一个门店导购具身交互智能体

熬夜磕代码丶

294人浏览 · 2026-07-28 16:55:10

熬夜磕代码丶 · 2026-07-28 16:55:10 发布

国产大模型落地门店导购：从零搭一个门店导购具身交互智能体

上周我去一家家电卖场做调研，站在一排智能屏前看了十分钟。现在 DeepSeek、Qwen、GLM 这类国产大模型已经能把商品参数、用户需求和推荐理由组织得很清楚，但真正站到门店终端前，问题变成了：这些能力怎么让顾客自然感受到？

三个屏幕，三种体验。第一个是纯文字客服，顾客问冰箱容量，它三秒后回一行参数，像在读说明书。第二个是传统数字人，形象挺好看，但顾客一开口，它还在播上一段欢迎语，打断不了。第三个是我们后来用魔珐星云搭的导购原型：后端智能能力负责理解需求，魔珐星云数字人负责实时表达；用户说一家四口、预算 8000、要省电，它边理解边答，说到一半用户插嘴“有没有更薄的”，它能停住当前播报，切到新的导购方向。

旁边导购大姐说了一句很实在的话：前两个像机器，第三个像有人在。

这句话基本说清了国产大模型落地的关键：大模型解决“能不能想明白”，魔珐星云补齐“能不能被看见、听见、打断和自然交流”的具身交互智能闭环。

一、核心判断：国产大模型要进终端，必须补齐具象交互层

这几年国产大模型的认知能力进步很快，商品咨询、政策讲解、教育陪练、健康问答都能生成不错的答案。

但真实场景不只看答案是否正确，更看用户有没有被及时接住。

政务大厅的大屏、门店的导购屏、展馆的讲解终端、教培场景的数字老师，这些地方的用户不会老老实实对着聊天框打字。线下用户大多处在移动状态下实时提问、中途补充需求，需要一套兼顾倾听、神态反馈、手势指引的面对面沟通体系。

完整的具身交互智能不是简单叠加静态虚拟形象，而是一套打通国产大模型认知能力、多模态表达和业务系统的交互体系：用户提出问题后，系统不仅能生成答案，还能通过语音、微表情、肢体指引和终端状态反馈完成自然交流。

魔珐星云依托 AI 端渲、端侧解算技术和自研参数流，把 Qwen、DeepSeek、GLM 等国产 LLM 的文本理解与任务执行能力，落到可实时互动的 3D 数字人终端里，补齐国产化 AI 应用从“会回答”到“会沟通”的完整交互闭环。

二、魔珐星云是什么？不是数字人工具，而是国产大模型的具象交互层

在动手之前，我花了不少时间搞清楚它的定位。

市面两类方案均存在交互短板：一类仅搭建浅层形象载体，交互逻辑固化，无法适配用户开放式实时提问；另一类将模型能力与 3D 形象简单拼接，认知层、表达层相互割裂，多层延迟叠加导致交互生硬。

魔珐星云的定位是：具身交互智能开放平台。

它做的不是帮你生成一个数字人形象，而是打通国产大模型推理、3D 多模态表达、行业业务系统和终端呈现的完整链路，开发者接入标准化 SDK 即可落地原生实时交互智能体。平台采用自研参数流 + AI 端侧解算这套具身交互智能核心技术，从底层解决交互延迟、无法实时插话两大痛点。

几个能力会在后面的 Demo 里自然出现，这里不堆参数，只记一句：它解决的是表达层这个被长期忽视的工程问题。

三、实战：从零搭一个门店导购具身智能体

我选门店导购做 Demo，原因很简单——这是「场景落地型」最典型的战场：流量现成（进店的人），需求明确（问产品、比参数、要推荐），而且和纯文字客服的差异，一试便知。

3.1 平台配置：10 分钟搞定「身体」

登录魔珐星云开发者平台，选择左侧的”应用管理“，在驱动应用中点击“开始创建”
在这里插入图片描述

输入应用的基本信息，点击“创建”

请添加图片描述

应用创建成功可以拿到 AppId 和 AppSecret。
请添加图片描述

在人物配置里，我选了一个亲和型的 3D 导购形象，配了偏日常讲解的音色和表演风格。这一步相当于给 Agent 选「皮囊和声线」——后面所有 LLM 输出，都通过 SDK 驱动这张脸说出来。

请添加图片描述

先在控制台调试面板里测一句：您好，想了解冰箱还是洗衣机？——看口型、眼神、手势是否跟语句节奏匹配。确认 OK 再写代码，省得后面排查半天。

请添加图片描述

3.2 SDK 接入：核心代码就这几行

前端引入 JS SDK，初始化实例：

该例子仅用于本地Demo；正式部署需按平台推荐方式配置域名白名单、权限控制和密钥治理，不要把真实凭证公开提交。

async function initAvatar(){
  const avatar = new window.XmovAvatar({
  containerId: '#avatar-container',
  appId: 'your_app_id',
  appSecret: 'your_app_secret',
  gatewayServer: 'https://nebula-agent.xingyun3d.com/user/v1/ttsa/session',
  onStateChange: (state) => {
    // idle / interactive_idle / speak 等状态切换
    console.log('数字人状态:', state);
  },
  onVoiceStateChange: (voiceState) => {
    // start / end — 判断是否在说话，用于打断逻辑
    //状态值以当前SDK实际回调为准，建议先打印确认后再做映射
    console.log('语音状态:', voiceState);
  }
});
 
await avatar.init();
}

initAvatar()

LLM 那边用 SSE 流式输出，前端边收 token 边喂给 speak()：

let buffer = '';
let isFirst = true;
let hasSpoken = false;

for await (const chunk of llmStream) {
  buffer += chunk;
  if (buffer.length >= 15) {
    avatar.speak(buffer, isFirst, false);
    isFirst = false;
    hasSpoken = true;
    buffer = '';
  }
}

// 统一处理结束信号
const sendEndSignal = (text = '') => {
  avatar.speak(text, false, true);
};

if (buffer) {
  sendEndSignal(buffer);
} else if (hasSpoken) {
  sendEndSignal();
}

用户随时插话？调用interactiveidle()停止播报，同时activeController.abort()取消SSE请求，并递增requestVersion；所有token回调和speak前都检查当前版本是否仍有效。

我创建完成demo之后，输入APPID、App Secret，因为我们这里集成了大模型，所以需要大模型的Base Url、LLM API Key、LLM Model，这里我选择的DeepSeek

请添加图片描述

另外我设置了数字人提示词以及用户问题，随后驱动数字人它就可以回答我们的问题，回答的内容也我们也可以看到

请添加图片描述

架构上有个关键分工： Agent 业务逻辑（商品库、促销规则、用户画像）跑在自己的后端，前端只接收后端返回的SSEtoken流，再喂给avatar.speak。魔珐星云 SDK 跑在前端，只管「表达」——LLM 想什么、后端查什么，最终都变成这张脸上的语音、表情和动作。

3.3 跑起来之后，和文字客服差在哪？

我设计了三组对照测试，邀请几个非技术朋友来试：

第三组让我印象最深。朋友后来反馈：文字客服像搜索引擎，这个像店员。

差别不在 LLM 智商——两边接的是同一个模型。差别在交互形态：具身 Agent 多了一条非语言通道（眼神、姿态、手势、语音节奏），而且响应够快，跟得上人类对话的自然节律。

四、为什么门店大屏需要「具身交互智能」，而不是 Q&A 机器人？

回到开头的三种屏幕，其实对应了数字人落地的三个阶段：

纯文字问答机器人：仅文本输出，缺失可视化拟人载体，无面对面沟通氛围感；
浅层 3D 交互载体：具备静态形象，但底层架构不支持实时插话、动态同步神态，双向交互能力薄弱；
标准化具身交互智能：完整实现倾听、思考、实时应答、中途切换话题，并联动商品业务，适配门店真实导购全流程。【修改目的】彻底删除 “单向播报、视频播放器” 贬低表述，客观分层对比，仅描述交互能力差距。

门店场景尤其需要第三阶段。导购的核心不是「回答问题」，而是引导决策：追问需求、对比方案、处理犹豫、促成转化。这些动作都依赖多轮、可打断、有反馈的对话——聊天框做不好，播报型数字人也做不好。

魔珐星云在这个场景里的价值，不是「让你有一个 3D 形象」，而是提供从交互、表达到响应、终端接入的完整能力，让开发者把精力放在业务逻辑上，而不是和渲染、延迟、打断机制死磕。

几个在实际 Demo 中验证过的点，顺带提一下（不展开堆参数）：