我给门店导购Agent做了个3D身体：他不是聊天框，而是可交流能上岗的具身交互Agent

热爱编程的小白白

176人浏览 · 2026-07-28 20:27:35

热爱编程的小白白 · 2026-07-28 20:27:35 发布

上周我去一家家电卖场做调研，站在一排智能屏前看了十分钟。真正让我印象深的不是屏幕有多大，而是同样能回答问题的系统，为什么给人的感觉完全不同。

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

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

这句话也点出了我对 Agent 的一次认知变化：Agent 能规划任务、调用工具、组织答案，但如果只停留在聊天框里，它和真实用户之间还缺一个自然交流的表达界面。

一、核心判断：Agent 不只需要会执行，也需要会被人自然理解

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

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

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

这正是具身交互智能要补齐的部分：Agent 解决任务执行，具身交互智能解决人如何自然地与 Agent 交流。它不是简单给 Agent 包一层 3D 外观，而是让任务结果通过语音、表情、动作、状态反馈和终端界面被用户自然接收。

魔珐星云依托 AI 端渲和解算 + 自研参数流，为各类 Agent 补齐 3D 具身拟人交互形态，把后端任务执行、3D 多模态表达和业务系统接成完整链路，让 Agent 从“会做事”进一步变成“能在现场服务人”。

二、魔珐星云是什么？不是 Agent 皮肤，而是具身交互智能表达界面

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

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

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

它做的不是帮你生成一个数字人形象，而是打通大模型推理、3D 多模态表达、行业业务系统完整链路，开发者接入标准化 SDK 即可落地原生实时交互智能体。平台采用自研参数流 + AI 端侧解算这套具身交互智能核心技术：云端仅下发轻量化表情、骨骼驱动参数，终端本地完成全部 3D 渲染计算，摒弃传统全帧画面传输架构，从底层解决交互延迟、无法实时插话两大痛点，补齐行业长期缺失的标准化拟人表达层。

几个能力会在后面的 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 跑起来之后，和文字客服差在哪？

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

测试场景	文字客服	魔珐星云导购
用户中途改需求	等它播完，重新提问	直接打断，立刻切换话题
问「有没有更便宜的」	回链接或 SKU 列表	边指侧边商品卡片 widget，边口头解释差异
用户沉默 5 秒	无反应	数字人微微前倾，主动问「还在考虑尺寸吗？」

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

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

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

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

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

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

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

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