线下门店 Agent落地：门店里需要的不是答案机器，而是拥有“面对面沟通”能接话的具身交互服务员

dvlinker

5057人浏览 · 2026-07-28 16:44:44

dvlinker · 2026-07-28 16:44:44 发布

上周我去一家家电卖场做调研，站在一排智能屏前看了十分钟。那一刻我突然发现，门店里的 AI 不是输在“不会回答”，而是输在顾客临时改口、追问、打断时，系统有没有像真人导购一样接得住。

三个屏幕，三种体验。第一个是纯文字客服，问冰箱容量，回一行参数；第二个是传统数字人，形象挺好看，但顾客开口时它还在按脚本播欢迎语；第三个是我们后来用魔珐星云搭的导购原型：顾客说预算、家庭人数、省电需求，它能讲推荐理由；顾客听到一半问“有没有更薄的”，它能停住原来的播报，切到新的导购方向。

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

这句话让我重新理解了门店 Agent：真正落地不是多一个问答窗口，而是让 AI 服务拥有“面对面沟通”的节奏。

一、门店里需要的不是答案机器，而是能接话的服务角色

商品查询、库存检索、推荐生成这些能力，Agent 已经可以完成。

但线下服务真正难的是交互过程：顾客不按脚本问，也不会等系统把一段话说完。

门店导购、政务接待、展厅讲解、教育陪练这些终端场景，都要求 AI 能边听边反馈、能用语音和动作表达、能在用户打断后切换上下文。纯文本交互太生硬，也缺少让用户判断“它正在服务我”的拟人反馈。

魔珐星云数字人作为可实时交互的具身智能体，补齐的正是这层服务界面：Agent 负责查询和推荐，具身交互智能负责让这些结果以可看、可听、可追问的方式被用户接收。

所以具身 Agent 不是换一个漂亮界面，而是把 AI 从“给答案”推进到“能沟通”。后面的 Demo 就从门店导购这个真实场景开始拆。

二、魔珐星云解决的是“服务发生在终端上”的问题

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

很多方案卡在两头：只有数字人形象，问答不灵活；只有 Agent 能力，表达又回到聊天框。两者简单拼接时，任务流、语音流、动作流不同步，用户一打断，体验就很容易散掉。

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

魔珐星云把 Agent 任务执行、3D 多模态表达、行业业务系统和终端呈现放进同一条链路里。开发者通过 SDK 接入后，可以让门店、展厅、咨询等场景里的 Agent 具备实时反馈、自然表达和可打断交互能力。

几个能力会在后面的 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 中验证过的点，顺带提一下（不展开堆参数）：