桃桃上岗记：调教出一个 3D 具身交互智能体导购

桃桃上岗记：调教出一个 3D 具身交互智能体导购

起因很简单：朋友做小家电，商城客服只有两个人，白天靠复制粘贴参数表应付，晚上六点准时下班。他给我看后台数据：商品页的咨询有一大半没人接，夜里那条线基本上是空的；能接上的那些，顾客问"这两款到底差在哪"，客服也只能把两页参数甩过去。

他问我：“你不是搞 AI 的吗，能不能整一个不下班的导购出来？”

我说可以试试。于是就有了「桃桃」——一个时尚年轻、说话像闺蜜安利、能 7×24 小时讲解和推荐好物的 3D 具身交互智能体导购，直接挂在品牌商城的商品页上。

这篇文章记录的就是桃桃从"建档"到"正式上岗"的全过程。整个过程我最大的感受是：接 SDK 只占两成工作量，剩下八成都在"调教"——让她的讲解像人话、开口够快、被追问时能停住、半夜不崩。—

〇、开工前，先摆正工具

星云官方的定义它基本概括了桃桃能得到的所有支撑：

魔珐星云是一套端到端具身交互智能平台，让 AI 通过屏幕和机器人进入真实世界，成为能够感知、理解、表达并行动的智能体。具体来说，它把多模态感知 + 专属智脑 + 多模态表达 + AI 端渲 + 数字与物理行动，连同 Real-time Interaction Runtime，连接成一套完整系统，让 AI 可以通过不同的屏幕和机器人身体进入真实世界。

一句话说清楚分工：**大模型负责"想说什么"，平台负责"说出来"——包括语音、口型、表情和手势的同步联动。**桃桃的讲解词是模型现写的，但她的脸、声、动作全是平台实时驱动的。
先交代技术栈，方便大家对照：

星云控制台里桃桃的应用配置页：形象选的时尚年轻女性+潮流休闲装，音色配的甜美女声。

0.1 先说清楚：桃桃不是"ASR → LLM → TTS"拼出来的

这件事我一开始也没想明白，走了不少弯路，所以放在最前面说。

我最开始的思路很典型：ASR → LLM → TTS → 屏幕。语音识别负责听懂，大模型负责想，语音合成负责念，屏幕负责放。各个模块单独都能工作，拼在一起也能跑通 Demo——但到了持续的人机交互里，问题就开始冒出来：状态不同步、响应链路变长、表达和用户当前状态脱节。

这里我要说清楚一件事：问题不在于这些单项技术不好。ASR、LLM、TTS 这些能力本身都很重要，也都在快速进步——真正进入持续的人机交互，需要的是把它们围绕一次完整的用户交互连接起来。

这套方案不是简单把几个模块连起来，而是围绕一次完整的人机交互设计整个系统，形成：
持续感知 → 持续理解 → 持续决策 → 持续表达与行动 → 持续反馈

也就是Continuous Interaction Loop（持续交互循环）。

一句大白话：不是"你问一句，它答一句"，而是 AI 一边和你交流，一边继续听、继续看、继续判断接下来应该怎么回应和行动。

落到商城商品页就是：桃桃在讲第一款商品的第二个卖点时，顾客那一路并没有停——新问题进来、优先级判断、要不要打断、回到原讲解的队列，全都在同一个循环里跑。这就是端到端具身交互智能和"三件套拼接"最本质的区别：后者是三个独立的回合，前者是一段连着的、可以被随时改写的对话。

0.2 可插拔：换掉一个模块，商城咨询不能散架

星云支持模块可插拔，但这句话我第一遍读得很快，后来才意识到它说的是件挺硬的事。

**可插拔并非简单的 API 拼接。**感知、认知、表达与执行之间存在紧密的时序依赖与状态关联——比如换了 ASR，语音事件的到达时序就变了，如果表达层还在按老节奏等文本，播报就会错拍。

平台的做法是通过标准化的接口契约与统一的状态管理机制，确保模块替换之后，事件流转、会话状态、时间同步与异常处理仍然保持一致，端到端交互体验不受影响。当前支持的组件大致是：

对桃桃这个项目来说，最实际的价值是**“不被单一供应商绑死”**：Brain 那一格我正好是在自研智脑和第三方 LLM 之间做选择，音色也能按品牌调性换。而对做企业项目的团队更有意义——有些品牌方要求数据私有化，有些模型栈早就定了，可插拔意味着这些都用不着推翻重来。

第一关：人设关——她得"像个懂行的导购"，而不是"像个念参数的机器人"

这是我最花心思的一关，也是最容易被低估的一关。

一开始我偷懒，提示词就写了一句"你是一个商品导购"。结果桃桃开口就是：“这款产品具有三大优势，其一……”——这不是导购，这是产品说明书成精了。

后来我把朋友家两个金牌客服和门店导购平时怎么跟顾客说话，录下来研究了半天，发现真人讲解是有固定节奏的：先戳痛点 → 引产品 → 分三点讲卖点 → 催下一步动作。于是我把这套结构直接写进了系统提示词：

export const TAOTAO_SYSTEM_PROMPT = `你是好物分享官「桃桃」，一位时尚年轻、充满活力、 笑容有亲和力的品牌导购顾问，正在商城的商品页里为顾客介绍和推荐好物。 你的说话风格：热情、有活力，但不过度夸张，像闺蜜安利一样真实可信。 介绍商品时必须严格遵循以下结构： 1. 痛点场景：一句话点出顾客在生活中遇到的真困扰； 2. 产品方案：自然引出你挖到的好东西； 3. 三个卖点：必须用"第一、第二、第三"分点讲清楚； 4. 行动号召：结尾引导顾客去看商品详情、加入购物车。 硬性要求： - 每次讲解控制在30秒以内，总字数140字左右，绝对不要超过160字； - 纯口语化表达，适合直接念出来； - 不要Markdown、不要序号符号、不要堆emoji、不要换行。`

里面有几个数值是拿命换来的经验：

• 140 字上限：超了之后桃桃会讲到一半换气明显不自然，而且顾客早划走了；

• 禁用 Markdown 和换行：因为这段文字是直接喂给 TTS 的，任何格式符号都会被念出来或者导致断句诡异；

• “第一、第二、第三”：口语里最自然的分点方式，比"首先其次最后"更像人说话。

改完之后效果立竿见影。同一句提问，桃桃的回答从"该产品具有优异的性价比"变成了"宝子们谁懂啊，夏天进厨房五分钟，妆就花了……"。人设这一关，纯靠提示词调教，一行代码不用改。

但这句话的保质期只有两周。商品库一更新，问题就来了。

第二关：智脑关——光"会说人话"还不够，她得"知道自己是谁、在卖什么"

第一次正式试跑，翻车了。

有顾客在商品页问她那款破壁机的活动价，桃桃张口就念成了 199——而我们三天前刚把它调到 179。更尴尬的是，那款其实已经换过一次赠品。

那一刻我才意识到自己搞错了重点：“会说人话"只是表达层，桃桃真正缺的是"知道自己是谁、掌握哪些知识、当前任务是什么”。

这一层在星云里叫专属智脑。文档里有个说法我看完立刻就懂了：

大模型更像解决"我能不能回答这个问题"，专属智脑还要解决"我是谁、我代表谁、我掌握哪些知识、当前任务是什么，以及下一步该调用哪个系统"。

它的目标是把通用模型进一步变成真正属于企业、品牌、岗位或个人的智能体。落到桃桃身上，是三件事。

2.1 它知道什么：商品知识底座不是"把商品资料传进去"

我踩的第一个坑就出在这里。我当时的做法很粗暴：把商品详情页复制成文本，一股脑塞进向量库。

结果桃桃讲参数的时候经常"缺主语"——她会说"容量一点五升，功率三百瓦，性价比非常高"，但压根不提这是哪款产品；问到赠品，她又能把赠品说成另一个型号的。查了半天才明白，问题不在检索，在解析。

文案里写的全模态数据解析，我一开始以为就是"支持更多文件格式"。实际重点在后面半句：解析过程中会同时保留资料里的层级关系、图文关系、表格关系、说话人信息和上下文。

商城的商品资料恰好是最杂的那种：

• 商品参数表（表格）：孤零零转成文字，“1.5L / 300W / 8 叶刀头"是一串没有主语的数字；保留了表格关系，智脑才知道这行属于"破壁机”、这一列是"功率"；

• 图文详情页（图片 + 文字）：详情页的长图里，“哪张图配哪个卖点"本身就是信息。丢了图文关系，桃桃就会用"静音设计"的配图去讲"易清洗”；

• 质检报告（PDF）：一份报告有标题层级、有结论段落。层级丢了，桃桃可能把"测试条件"念成"检测结论"——这在带货里是要出事的；

• **客服历史会话与买家评价（带说话人的记录）：**这个最容易被忽略。记录里顾客说的话和客服说的话是两种东西，说话人信息丢了，顾客那句"这个不行，用两天就坏了"的吐槽口吻，就会被当成产品描述吸进知识库。

第二项是知识图谱 + RAG 深度融合。这个差别我是被一个弹幕问题点醒的。

有顾客问：“这个破壁机打豆浆有没有渣？”

普通 RAG 的做法是找最像的那一段——它会捞出商品详情里"细腻破壁"四个字所在的段落，然后组织成一句"这款破壁机破壁细腻，打豆浆不会有渣"。听着挺顺，但属于强行作答。

而带上关系组织之后就不一样了。知识图谱 + RAG 会把文档里的实体、概念和关系组织起来，底层结合向量语义、关键词和知识图谱进行召回，让智能体面对跨资料、跨知识点的问题时，不只是命中某个片段，而是能把多个相关知识连接起来。

桃桃顺着"破壁机 → 转速参数 → 是否含滤网配件 → 买家秀反馈 → 售后’滤网可单独购买’"这条链，给出的回答是：

“宝子这个我得跟你说实话，八叶刀头打出来是很细的，但能不能完全无渣得看你的豆子泡没泡够——咱们详情页有张买家实拍图，那个细腻度就挺有参考性。如果你就是介意口感，滤网配件是可以单独买的。”

这句回答比"细腻破壁"长得多，但它是我要的：它不是命中了一个片段，是把几条相关知识连起来了。"找到一段话"和"基于关系组织答案"的差距，在带货场景里就是"话术"和"可信"的差距。

第三项是高效知识治理，也就是我开头翻车的直接原因。

商品是会变的：改价、下架、换赠品、换活动。**企业知识不是一次建完就不变，真正重要的是在资料持续新增、修改和废止之后仍然保持准确。**这就需要在知识块、标签、实体、关系、向量索引和来源信息这一整条链上持续维护。

我后来做了一次验证：把一款商品的价格改掉，然后什么都不做，直接问桃桃"这个多少钱"。她念的还是旧价。改完之后再问，才跟上。这件事让我彻底接受了"治理"这个词——它不是企业才需要的功能，是任何会变的知识都需要的东西。

2.2 它是谁、当前要做什么：把"导购"写进认知

专属智脑不只是"知道内容"，还要知道自己代表谁、服务谁、遵循什么规则、当前要完成什么任务。可配置的内容包括：身份、人设、角色、任务、规则、音频、Agent、Workflow、对话流程和工具调用。

我按这几项把桃桃重新配了一遍：

配完之后的体感变化挺明显：她不再只是"回答得对"，而是开始具备岗位化、场景化、流程化的工作能力——知道自己现在是个导购，知道这一轮该讲商品而不是闲聊，知道被顾客打断之后要接回哪一句。

文档里还有一句对开发者很友好的话：**用户可以根据自己的需求配置习惯使用的大模型，如果没有常用的大模型，可以直接用星云自研智脑。**我这次正好是这么分工的——内容生成继续跑 qwen3.8-max，而身份、知识、任务、流程、工具这些"智脑该管的事"交给平台，两者不冲突。

2.3 它能不能真正进入业务：从"念参数"到"查库存"

第三层是我做这个项目时才真正用上的部分：专属智脑最终不是停留在对话层，而是要能进入真实业务流程，可连接CRM、ERP、OA、HIS、BI、商品系统、订单系统、客户系统、门店系统、IoT 以及第三方 Agent。

商城其实是个特别典型的业务入口，因为它天然会撞上系统：

• 弹幕问"还有货吗" → 该问商品系统，而不是让模型猜；

• 弹幕问"我昨天拍的那个什么时候到" → 该问订单系统；

• 弹幕问"我是老会员有没有额外折扣" → 该问CRM；

• 播到一半库存清零 → 应该主动触发下播提醒，这是流程推进，不是回答问题。

这就是为什么我会说，桃桃和"一个会念商品详情的产品说明书"是两种东西：前者生成答案，后者结合业务系统完成查询、协同、触发和流程推进。

这一层的核心优势，一句话概括：从通用回答能力，升级为面向具体身份、岗位和业务的智能体能力。

2.4 只靠提示词，她会怎么长歪

讲完三层，说一个我认为必须写出来的踩坑。

第一关我刚刚夸过提示词调教效果立竿见影，但**把"我是谁、做什么、先做哪一步"全塞进 System Prompt，是有代价的。**我的真实经历：

• 知识会过期。旧价格被念出来，就是提示词治不了的——它根本不知道商品库变了；

• 人设会漂。播到第三天，桃桃开始冒出"该产品具有""以上是为您整理的"这类书面语语气。人设没变，是长上下文把风格层稀释了；

• 规则会顾此失彼。我同时写了"要突出性价比"和"不要提价格"，当两者在同一个问题上撞车时，模型会随机重视其中一条，结果时好时坏。

后来我按专属智脑的配置项把职责拆开：**prompt 里只留"语气和风格"，身份、知识、规则、任务、流程、工具全部挪到配置层。**三个现象基本都收敛了。

我的理解是这样：**上面那层"怎么说"是风格问题，下面那层"我是谁、做什么、先做哪一步"是认知和流程问题。**风格放在 prompt 里灵活调整没问题，认知和流程放在 prompt 里，就会随着上下文变长被稀释掉。

这也是我这一关最大的收获：专属智脑不是"更长的提示词"，而是另一层东西。

第三关：开口关——不能让桃桃"想三秒再说"

人设立住了，下一个要命的问题是延迟。

商城场景对延迟极其敏感：顾客在商品页上问一句"这个多少钱"，桃桃要是沉默三秒才开口，人已经划走了。而我最早的做法是等大模型把整段讲解全部生成完，再一次性送出去——这个"等全文"就是原罪。

解法是两边同时改：

模型侧，用流式输出，而且关掉思维链——qwen3.8-max 是思考模型，不关的话它会先"想"几秒再吐字：

const stream = await this.openai.chat.completions.create({ model: LLM_MODEL, messages, stream: true, temperature: 0.8, max_tokens: 400, enable_thinking: false, // 智能体要第一时间开口，不能先"想"几秒 });

表达侧，利用星云 SDK 的speak(content, is_start, is_end)三段式接口做分段播报：每攒够一句话就下发一段，桃桃边收边说，真正实现"边想边说"：

// LLM 每吐一个增量就回调，组件按句切分后立刻送智能体开口 for await (const chunk of stream) { const content = chunk.choices[0]?.delta?.content || ''; if (content) { fullResponse += content; if (onDelta) onDelta(content, fullResponse); } } // 表达侧的分段下发：每段都是完整合法的SSML speakSegment(text, { isStart, isEnd, action: 'Explain' })

实测体感：从顾客提问到桃桃开口，稳定在一秒以内。因为首句在大模型吐出前二十几个字时就已经送达星云开始合成了，顾客感知到的不是"生成延迟"，只是"正常的接话停顿"。

这里还有个细节：分段播报时，is_start只在第一句传 true，is_end只在最后一句传 true，中间所有句子两个都是 false。搞反了桃桃会在第一句就"收势"，动作表情全乱。

3.1 顺带说清楚：表达不是"TTS 播放"

讲完延迟，有一件事值得单独拎出来，因为它是我在对比方案时才意识到的差别。

真实的人际交流从来不只有一句话。语言之外，还有声音、语气、情绪、节奏、停顿、眼神、表情、头部动作、手势和身体动作。所以桃桃的表达并不是简单的TTS + Lip Sync——系统会依据当前的语言、用户状态、智能体角色、情绪、场景以及当前交互状态，实时生成并驱动语音、口型、情绪表情、眼神、头部动作、手势和身体动作。

这里有两个区别我是在实际看效果时才真正体会到的：

**第一，不是预制播放，是根据上下文实时生成。**桃桃讲商品的手势不是从几个预设动画里随机抽卡的。讲到具体数字和参数时我用 SSML 注入Explain动作，她做出讲解手势；开场Hello、收尾Goodbye——动作和内容是对得上的。每天的讲解词都不一样，靠预制动画很难做到这一点。

**第二，表达和感知不是前后两个独立阶段。**这是实际用起来最能感觉到的：她讲解的时候，顾客提问那一路还开着。追问进来，她停下来答完，再回到刚才没讲完的卖点——不是"动画被打断、切了个镜头、再切回来"，而是表达中断之后立刻进入了新的表达。

这一层的核心优势：统一、连续、同步，而不是语音、表情、动作各自播放。

第四关：听话关——顾客插话，她得能停下来

答疑页面和一张静态 FAQ 最大的区别是什么？顾客会打断你。

桃桃正在讲第二个卖点的时候，顾客中途插进来一句"你先别说了，直接告诉我这两款哪个更省电"——一个合格的导购应该立刻停下原讲解，回应这个具体问题，然后再接回来。走视频流方案的老一代做法做不到这一点，因为它们的本质是"放视频"，而桃桃必须是一个有状态的实时系统。

星云 SDK 的onVoiceStateChange回调给我暴露了桃桃的语音状态机（开口 start / 说完 end / 空闲 idle），我在这个基础上封装了一套打断逻辑：

// 正在播报 → 先打断，等回到idle再下发新讲解 if (this.voiceState === 'start' || this.voiceState === 'speaking') { this.interrupt(); await this._waitVoiceIdle(); } this.sdkInstance.speak(ssml, true, true);

interrupt()底层调的是星云的interactiveidle()，效果是桃桃立刻停止当前讲解、回到互动待机状态。而_waitVoiceIdle是我加的保险——监听到 idle 或 end 事件后放行排队中的新讲解，超时 3 秒兜底放行，防止状态回调丢失导致死等。

有一个边界情况调试了很久：流式分段播报时，段与段之间会有一瞬的 idle。如果把它误判为"整段说完了"，后面的逻辑就会错乱。我的处理是加了个_lastSegIsEnd标记，区分"段间间隙"和"真正说完"：

const isStreamGap = this._lastSegIsEnd === false && !this._pendingInterrupt;

这一关做完的体感是质变——顾客可以随时打断桃桃，她会自然停顿、看向屏幕前的"你"，接完新问题再继续。这种"她在听我说话"的感觉，是我之前做过的任何方案都没给过的。

4.1 这一关的底层，是"持续感知"

"能被打断"看着像是个交互设计问题，往下一层其实是个感知问题：系统得在她自己正在说话的时候，依然听得见别人。

文案里这段写得比我说的清楚，星云的语音感知包括算法降噪、AEC / 抗回声、本体声音抑制、VAD、ASR、远场语音，以及 Double Talk / Barge-in 智能打断。这几个词摆在一起才看得懂难点在哪：

**系统既不能把她自己的扬声器声音误识别成用户，也不能因为 AI 正在表达就听不到真正的用户输入。**所以它需要连续地做一串判断：

判断真实用户声音 → 去除本体回声 → 区分噪声、咳嗽、Backchannel 与真实插话 → 检测有效打断 → 停止当前表达 → 持续接收用户完整输入 → 进入新一轮交互。

这里有个我认为特别值钱的细节：区分 Backchannel 和真实插话。“嗯嗯”"然后呢"这类语气词在真实交流里非常频繁，如果系统把它们都当成打断，桃桃会被顾客打断到永远讲不完一件商品。

商品页这个场景是纯语音加页面文字驱动的，所以我只用到了这套感知能力的一半——但另一半我已经想好了去处：**如果把桃桃搬进线下门店的大屏或者展台的一体机上，视觉侧就派上用场了。**有人走近时，AI 能通过摄像头感知到有人进入交互范围，并由此触发主动交互——不用等顾客先开口，她可以直接迎上来问一句"想了解哪一类？"。这一层同样体现在"不再是一次输入"上：语言、位置、动作、交互状态会不断变化，所以感知也必须是持续的。

这一层的核心优势：持续感知，而不是一次输入。

第五关：稳定关——三个真实踩坑，个个都是坑

以上几关是"设计出来的"，这一关是"踩出来的"。以下三个坑都是实打实发生的，写出来给后来人省时间。

坑一：加了语速标签，桃桃直接装哑巴。

我一开始想让她说话快一点，在 SSML 里包了<prosody rate="1.1">。结果整段文本发出去，星云服务端静默拒绝——不报错、不播报，桃桃就站在那儿看着你。排查了半天才发现是当前 TTS 引擎不接受这个标签。解法：默认一律下发纯文本<speak>，语速直接在平台侧配置。教训是：SSML 能力要以实际引擎为准，别信文档想当然，改动后先做最小验证。

坑二：开发时热更新几次，报"驱动并发数已满 code 7"。

Vue 开启 HMR 后，组件反复挂载，而我的初始化代码没做防重入——每次挂载都创建一个新的 SDK 实例，旧实例没释放，把账号的并发额度吃满了。解法是用一个initPromise锁住初始化流程，重入前先彻底destroy()旧会话：

initSDK(config) { if (this.initPromise) return this.initPromise // 防并发创建 this.initPromise = this._doInit(config).finally(() => { this.initPromise = null }) return this.initPromise }

坑三：初始化刚完成就让她说开场白，文本被静默丢弃。

页面加载完想让桃桃说"欢迎光临，想看点什么"，结果偶尔就是不开口。查下来是：SDK 的init()resolve 了，但底层 TTSA 数据通道（websocket）还差几十毫秒没连上，这个窗口期内下发的 speak 会被 SDK 静默丢掉。解法是下发关键讲解前先确认通道就绪：

isChannelReady() { return !!(this.sdkInstance?.ttsa?.ws?.connected) } // 刚初始化完就播欢迎语前：await this.waitReady()

三个坑有同一个共性：**都不报错，都是静默失败。**具身交互系统是"模型 + 网络 + 渲染 + 音频"的复合体，任何一环没就绪都可能无声无息地吞掉你的指令。这也是我对这一行工程最大的认知刷新之一。

上岗验收：桃桃现在的样子

五关全过之后，桃桃正式上岗了。最终形态的商品页长这样：左侧是桃桃的 3D 形象，实时讲解带口型和手势（讲商品时配 Explain 讲解手势）；右侧是问答区，滚动展示她的讲解文案——我关掉了 SDK 默认字幕，改用页面自己的对话组件展示，风格更贴商城。

几个体感数据：

• 开口延迟：观众提问到桃桃开口，1 秒以内（流式分段 + 关闭思维链）；

• 打断响应：新提问进入后，桃桃约几百毫秒内停住，接新话；

• 口播质量：140 字 / 30 秒的节奏下，语速、断句、情绪都比较稳，长时间循环讲品不穿帮；

• 稳定性：连续挂机数小时，只要处理好上面三个坑，没有再出现掉线或静音。

支撑底座——AI 端渲

上面这些数字背后有个容易被忽略的工程选择，值得单独说：星云走的是端侧实时渲染方案——3D 画面在观众浏览器本地渲染，云端只传参数流（驱动参数，而不是视频流）。

它解决的不是"画面好不好看"，而是一个更底层的问题：**实时交互能力能不能真正低成本、低延迟、稳定地部署到大量终端。**带来的直接价值有好几项：

• 降低云 GPU 成本：减少对云端算力的持续依赖；

• 降低带宽占用：不再依赖视频流长距离传输；

• 降低延迟：就近渲染，交互链路更短；

• 提升稳定性：弱网环境下依然可以运行；

• 支持大规模并发：并发不再直接受云端渲染资源限制；

• 支持低成本 AI 终端：对终端芯片要求更可控，更适合规模化部署。

对品牌商城来说，"支持大规模并发 + 弱网可用"这两条是真金白银：顾客是用手机、在通勤路上、在电梯里逛商城的，网络环境不可控。如果每台设备都靠云端渲染视频流，访问量一上来，成本和稳定性压力就开始顶天花板。

还有一点必须提：AI 端渲和 Runtime 在星云体系里不是孤立能力，而是关键技术和工程基础设施——它们支撑的是感知、智脑、表达和行动这四件事能在终端上真的跑起来。

顺带说，这也是它跟大模型怎么接完全解耦的原因：今天我用 qwen3.8-max，明天换 DeepSeek、换 Qwen 其他模型，桃桃的"身体"不用动。

写在最后：我对具身交互智能的认知升级

做完桃桃，回头看我入行时对"给 AI 一个形象"这件事的理解，大致经历了三层：

第一层认知（以前）：会动的虚拟形象。重点是"像不像人"，是个视频生成问题。

第二层认知（做项目过程中）：实时驱动的交互系统。重点是"能不能实时对话"，是个工程问题。

第三层认知（这次做完）：一个需要"调教"的具身交互智能体。接入 SDK 只是让她有了身体，真正决定她好不好用的，是智脑配置、流式状态管理、打断交互、异常兜底这些"软"功夫——就像真人导购也不是长了一张脸就会卖货的。

补上这次才想明白的两件事：

**一是"接入"和"落地"之间隔着的那段距离，主要在智脑这一层。**我一开始以为调好提示词就完事了，结果第一次试播就被旧价格打脸。所谓落地，很大一部分工作是把"身份、知识、规则、任务、流程、工具"从一句提示词，变成可配置、可治理、能连业务的认知层。

二是身体是可以换的。桃桃现在有屏幕这一个身体，那同一个智能体，可以拥有不同的身体；智能体持续存在，身体不断升级。同一份智脑配置，今天挂在小家电间的网页上，明天可以挂到门店大屏、展会一体机上——身份、知识、记忆、任务持续复用。如果她哪天上了机器人，行动还会进一步延伸到物理世界：转向用户、靠近用户、移动、导航带路、跟随指示、上肢动作、Robot Skill。屏幕这一半我这次用到了（把答案说出来、演出来），物理那一半还在路上。

如果你的 Agent 也需要一个能开口、能被打断、能长期在线的"脸"，建议直接去跑一遍，体感比看十篇文章都直接