门店 Agent 只做文本问答等于半残废？靠 3D 具身交互才真正完成线下场景落地

主理人柚子

737人浏览 · 2026-07-29 10:53:01

主理人柚子 · 2026-07-29 10:53:01 发布

上周我去一家家电卖场做调研，站在一排智能屏前看了十分钟。真正让我印象深的不是屏幕有多大，而是同样能回答问题的系统，为什么一个像工具，一个像真的在服务顾客。

第一个是纯文字客服，顾客问冰箱容量，它三秒后回一行参数，像在读说明书。第二个是传统数字人，形象挺好看，但顾客一开口，它还在播上一段欢迎语，打断不了。第三个是我们后来用魔珐星云搭的门店导购具身 Agent：用户走近，数字人先给出状态反馈；用户说一家四口、预算 8000、要省电，它边理解边回答；说到一半用户插一句“有没有更薄的”，它能停住当前播报，切到新的导购方向。

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

这句话基本说清了 Agent 落地门店的关键：不是把聊天框换成一个 3D 界面，而是让 AI 服务更接近真实的人与人沟通方式。

一、核心判断：Agent 要进入场景，必须先解决交互落地

这几年 Agent 的任务执行能力进步很快，商品查询、库存检索、推荐生成、流程调度都能跑起来。

但真实门店不只看任务有没有执行，更看用户有没有被及时接住。

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

具身交互智能补齐的正是这个场景落地缺口：Agent 负责查询、推荐和流程执行，魔珐星云数字人作为可实时交互的具身智能体，负责把任务结果用语音、表情、动作和可打断反馈自然传达给用户。

在整套链路里，魔珐星云不是给 Agent 换一个界面，而是让门店导购、展厅大屏、咨询服务等场景里的 AI 拥有可看、可听、可互动的服务形态，补齐纯文本交互生硬、缺少拟人反馈的行业痛点。

二、魔珐星云是什么？是具身 Agent 的场景落地底座

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

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

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

它做的不是帮你生成一个数字人形象，而是打通 Agent 任务执行、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 中验证过的点，顺带提一下（不展开堆参数）：