别让你的 Agent 只会打字了：手把手教你用魔珐星云 SDK 给 AI 装上“3D身体”

对话框真的够吗？聊聊 Agent 规模化落地最缺的“表达层”

楔子:Agent 生态缺了一块,没人愿意先说

最近 MCP 协议（Model Context Protocol）确实火得不行，大家都在卷 Agent 怎么调工具、怎么接数据。但作为一个在一线折腾 Agent 落地的开发者，我总觉得缺了点什么。

你看，不管背后的 LLM推理多强、工具链多顺，用户最后面对的还是那个冷冰冰的对话框。智能体（Agent）如果没有一个能和人自然互动的“身体”，它永远只能是一个好用的工具，而不是一个有温度的角色。

这就是我最近开始折腾「具身智能」的原因。我深测了一个叫“魔珐星云”的 SDK，原本以为就是个普通的数字人平台，结果写完几个 demo 我彻底改观了：它更像是 Agent 生态里的“具身表达层”。

** 实测下来的几个爽点：**

1. 首包响应极快：实测端到端延时 1420ms 左右，比那些要等 5-10 秒首包的传统视频流方案快了一个数量级。

2. 开发者太友好：一行 <script> 接入，speak 接口原生对齐大模型流式输出。

3. 真正的“具身”：动作接口直接能封装成 LLM 的 Function Tool，让 AI 边说边动。

这篇文章不整虚的，我会带你从 10 行代码上屏开始，一直到对接 OpenAI/Claude 的流式实战，全是干货。

---

一、为什么以前的数字人方案根本没法给 Agent 用？

先把敌人看清楚。

主流开源数字人方案长这样(我梳理了 2024-2025 年几套代表方案:LiveTalking、Linly Talker、MuseTalk 链路、awesome-digital-human-live2d):

用户语音 → ASR 识别 → LLM 生成文本 → TTS 合成语音 → THG(Talking Head Generation)生成唇形视频 → ffmpeg 合成 MP4 → HTTP/WebRTC 推流 → 浏览器播放

5 个模型 + 一次视频合成 + 一次推流。每一环都有代价:

• 延时:THG 模型(Wav2Lip、MuseTalk、VideoRetalking)都需要一段音频上下文才能推理唇形,首句话没个 2-5 秒出不来

• 视频拼接:TTS 输出是音频流,THG 输出是视频帧,得用 ffmpeg 合成 ts/mp4,多队列多线程调度才能做到"边推理边播放"

• 扩散系(EMO、Echomimic、Vasa-1):效果确实惊艳,但推理以分钟为单位,实时对话场景直接 pass

• GPU 成本:THG 推理每路占一张卡,10 路并发就是 10 张 A10——企业级部署光显卡一年烧百万级

但这些都是表象,真正的根因只有一个:

这套架构是"视频流架构"。视频,作为传输单元,从一开始就不是为 Agent 实时对话设计的。

视频流的麻烦在于:它是合成后的最终产物。前面任何一段链路(TTS 的语调、THG 的口型、表情的微调)想做变更,整个视频都得重新合成。而 Agent 对话场景的特点是流式的、可打断的、强交互的——LLM 输出一个词、一个短语就要出声,用户随时可能插话,数字人要立即响应。用视频流表达这种交互,就像用 JPEG 做动画——不是不能用,是根本不是一回事。

所以你看 2024 年国内外最活跃的开源数字人项目,技术选型都在同一个坑里反复优化:怎么让队列更快、让拼接更准、让延迟再低一点。每个方案都在做 10% 的优化,但架构天花板在那。

一句话:缝合怪的原罪,不是缝得不够好,是不该缝。

---

二、星云的另一条路:把"视频流"换成"参数流"

2.0 别被官方话术绕晕了：其实就是这三件事

展开技术之前,先还原一下星云团队自己给产品的三层架构定位(官方表述,我做了技术解读):

官方层级	做什么	我的技术解读
云端大脑	接入 LLM / KA 动作库 / 业务逻辑编排	Agent 推理内核(可接任意 LLM)
多模态感知	摄像头视觉、麦克风听觉、触屏手势等输入	把物理世界的信号解析成结构化意图
表达引擎	语音合成、面部表情、身体动作、3D 渲染	把 Agent 的决策转为"人类可感知"的表达

这套分层,在具身智能语境下非常清晰:

• "感知" = 让 Agent 看见/听见真实世界

• "大脑" = 让 Agent 理解与决策

• "表达" = 让 Agent 被人看见/听见/感受到

一个容易忽略的事实:国内外 Agent 生态在"感知"(多模态模型)、"大脑"(LLM / MCP)这两层卷得飞起,但"表达"这一层其实长期是短板——要么是播一段冷冰冰的文本,要么是用传统数字人方案拼一段延迟高、不可打断的视频。

星云的根本差异化,就押在"表达引擎"这一层。我把它概括为一句话:用参数流架构,解决 Agent 表达层的所有遗留问题。

接下来这一章的剩余部分,完全围绕"表达引擎"展开——因为这是星云最硬的技术护城河,也是开发者接入时最容易踩到价值的点。(感知层和大脑层会在章四、章五以 SDK 视角展开。)

2.1 四路参数流:表达引擎的底层协议

我第一次翻魔珐星云 JS SDK 文档时,最先注意到的不是功能列表,是这几个字段名:

看懂这四个字,就看懂了星云为什么能跑得比传统方案快一个数量级。

星云的服务端根本不下发视频。它下发的是四路并行的参数流:

• audio — 语音波形(PCM 或编码后的音频帧)

• body — 身体动作参数(骨骼旋转、位移)

• face — 面部表情参数(morph target / blend shape 系数)

• event — 交互事件(字幕开关、Widget 触发、KA 语义)

这些参数到了浏览器端,由 XmovAvatar SDK 本地渲染——WebGL 画布 + Canvas 层叠 + 硬件加速(prefer-hardware)。数字人是在你的设备上实时渲染出来的,服务端只负责算"下一帧应该是什么姿势、什么表情、什么声音"。

为什么这个架构能跑?因为它对应了三个根本差异:

维度	传统视频流	星云参数流
下行数据量	1080P@30fps ~5Mbps	参数流约 100-300Kbps
首帧延时	2-5 秒	1.3 秒(实测)
单机并发	~10 路/GPU	百路级(CPU 调度)
变更灵活性	视频合成后不可变	随时插入 event

工作台实测截图如下——一次 speak 指令从点击发送到数字人开口,1314 毫秒:

这 1.3 秒里,包含了:

1. SSML 从浏览器发到服务端

2. 服务端 TTS 合成音频

3. 服务端生成 body/face 参数轨

4. 参数流回传到浏览器

5. 浏览器本地渲染首帧

传统视频流方案做完同样的事,至少还要加一步视频合成,一般 +2 秒起步。

更妙的是端侧渲染带来的并发成本解放。视频流方案,10 路并发就是 10 张 GPU 的开销;参数流方案,服务端只是算参数(不做渲染),同样的 GPU 可以支撑几十路,渲染压力分散到终端——每台终端自己画自己的。这就是"存量屏幕不换硬件升级 AI 终端"这句话在星云体系里是成立的:屏幕有个浏览器就能跑。

星云文档里写的兼容性让我印象很深:

已测试通过:macOS 15.6、Win10(Dell/华为/华硕多款)、iOS 16.6-18.6 全系 iPhone / iPad、小米 HyperOS、Oppo、Vivo、Android RK3588(1080P)/ RK3566(720P)。

注意到 RK3588 / RK3566 了吗?这是国产嵌入式 SoC,广泛用于教培一体机、门店大屏、政务查询终端——存量屏的硬件底座。星云把自己的 Android SDK 铺到这些芯片上,意图非常明确:不做视频流数字人,做"具身显示协议",像 HDMI 一样成为一个行业标准。

一句话:魔珐星云不是一款数字人,是"具身表达层协议 + 渲染 SDK"。

---

三、10 行代码上屏:从注册到数字人显示

理论讲够了,动手。这一节,我带你40 分钟内把一个 3D 数字人放进你自己的 HTML 页面。

3.1 控制台:创建你的第一个驱动应用

打开 xingyun3d.com,注册开发者账号 → 进入控制台 → 应用管理 → 创建驱动应用。

创建流程按引导走:

• 形象:目前有几十款预置形象(从业务人员到游戏感风格)

• 场景:背景画面(淡彩渐变、办公室、演播厅等)

• 音色:超过 30 款,覆盖主播、客服、教师、博主,甚至有韩语和俄语音色

• 表演:动作风格(活泼 / 稳重 / 专业)

我这次选的配置是"智能导购员 Demo":

• 形象:和合

• 音色:温柔小欣(青年对话 / 温柔暖心)

• 场景:淡彩渐变

• 动作:活泼

• 表情:开心、严肃、疑惑

创建成功后点 "App 密钥" 按钮,拿到两串关键字符串:

• App ID

• App Secret

妥善保存,等会儿代码里要用。

3.2 最小可运行 HTML(真·10 行主逻辑)

新建一个 index.html,贴如下代码:

真的就是这些。浏览器本地打开(或挂一个静态服务器,因为 SDK 要求 localhost 或 https 域名)——等进度条跑完,数字人就在画面里了。

3.3 三个容易踩的坑

第一次跑建议先避开这几个:

坑 1:容器比例必须和控制台选的应用类型一致 横屏应用用 16:9(如 800×450),竖屏应用用 9:16(如 450×800)。比例不对的话数字人画面会变形或跑偏。

坑 2:不能用 IP 访问 SDK 内部用了 WebGL / WebCodecs / WebWorker 一些只在 localhost 或 https 下才开放的 API。开发时用 localhost:xxxx,部署时上 HTTPS,用 IP 直连会静默失败。

坑 3:init() 返回 Promise,别忘了 .catch 资源下载、鉴权失败都会让 Promise 被 reject。加上 .catch(error => console.error(error)),排障速度快 10 倍。

3.4 让它开口说话(加 5 行代码)

上一段只是把数字人"挂"出来,现在让它说话。在 sdk.init() 之后加:

speak() 的签名是 (ssml, is_start, is_end)——这三个参数看起来朴素,但下一章你会看到,它们就是为 LLM 流式输出设计的。

到这一步,已经完成了。

下一章,我们让它对接大模型。

---

四、让 Agent 开口说话:对接 LLM 流式输出

这一章是全文技术密度最高的一段。如果你跳过前面都可以,这段一定要仔细看——它决定了你的 Agent 会不会像个"真人"。

4.1 聊聊这个 speak 接口：解决流式交互“顿挫感”的解药

先看签名：

三个参数看起来平平无奇。但你把它和 LLM 流式输出的数据形状放在一起看:

一对一映射。is_start=true 告诉 SDK "开始新的一轮说话",is_end=true 告诉 SDK "这段说完了"。中间所有 chunk 只管往里喂。

这意味着什么?意味着你从 OpenAI SSE、Anthropic Stream、任何一个 LLM 流式接口拿到的 delta,可以几乎零逻辑转换直接丢给 SDK。LLM 边生成,数字人边说——不等 LLM 输完整段。

4.2 工程最佳实践:按标点切片

直接按 chunk 喂会有个小问题:LLM 的 token 切分和语义单元不一致,有时候一个 chunk 就 1-2 个字,会让 TTS 节奏发飘。

我的最佳实践是按标点/句子切片,再喂给 SDK,40 行不到,就把"LLM 流式 → 具身表达"这座桥搭好了。

4.3 三套大模型对接示例

对接 Anthropic Claude(推荐,代码最简洁)

import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY });

async function talkWithClaude(userInput, bridge) {
  const stream = await client.messages.stream({
    model: "claude-sonnet-4-6",
    max_tokens: 1024,
    messages: [{ role: "user", content: userInput }],
  });

  for await (const event of stream) {
    if (event.type === "content_block_delta" &&
        event.delta?.type === "text_delta") {
      bridge.feed(event.delta.text);
    }
  }
  bridge.end();
}

对接 OpenAI GPT

import OpenAI from "openai";
const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

async function talkWithGPT(userInput, bridge) {
  const stream = await client.chat.completions.create({
    model: "gpt-4o",
    messages: [{ role: "user", content: userInput }],
    stream: true,
  });

  for await (const chunk of stream) {
    const text = chunk.choices[0]?.delta?.content;
    if (text) bridge.feed(text);
  }
  bridge.end();
}

对接国产大模型(以 DeepSeek 为例,通义/豆包同理)

async function talkWithDeepSeek(userInput, bridge) {
  const resp = await fetch("https://api.deepseek.com/v1/chat/completions", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.DEEPSEEK_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      model: "deepseek-chat",
      messages: [{ role: "user", content: userInput }],
      stream: true,
    }),
  });

  const reader = resp.body.getReader();
  const decoder = new TextDecoder();
  let buf = "";
  while (true) {
    const { done, value } = await reader.read();
    if (done) break;
    buf += decoder.decode(value, { stream: true });
    const lines = buf.split("\n");
    buf = lines.pop();
    for (const line of lines) {
      if (!line.startsWith("data: ")) continue;
      const data = line.slice(6);
      if (data === "[DONE]") continue;
      const delta = JSON.parse(data).choices[0]?.delta?.content;
      if (delta) bridge.feed(delta);
    }
  }
  bridge.end();
}

三个 LLM,同一个 bridge.feed() 入口。切换模型只改一个函数,不改数字人端任何代码。

4.4 状态机:让 Agent 生命周期可见

星云的 5 个状态天生对应 Agent 的生命周期:

星云状态	Agent 生命阶段	用户感知
idle	空闲待命	数字人做微表情、等候
interactive_idle	等待过渡	可被打断、可切走
listen	接收输入	数字人侧耳倾听
think	LLM 推理中	数字人思考表情(关键!消除 Agent 沉默感)
speak	流式输出中	数字人边说边做动作

think 状态特别重要。传统数字人方案,LLM 在推理的那 1-3 秒,屏幕上就是一个"尴尬静止"——用户以为卡了。星云在这段给你一个"思考中"的动画表情,体验差距是降维的。

4.5 终极武器:能被打断的 Agent

真实对话里,用户会插话、改口、纠正——这是 ChatGPT 对话框体验永远赶不上真人的原因之一。

星云给了一个"排队式打断"的优雅方案,把它封装成 SpeechManager:

这段代码是星云在 Agent 场景真正的杀手锏。它解决了一个多轮对话 Agent 最尴尬的工程问题——"指令冲突",而它的思路不是互斥锁,是一个异步的"状态监听+指令消费"。

一句话:MCP 让 Agent 有了手,speak+SpeechManager 让 Agent 有了可被打断的嘴。

---

五、动作指令：像调用函数一样让数字人“动起来”

到这里,数字人已经会边思考边说话、还能被打断。但它还缺一件事——动作。

光说不做,还是"脱实向虚"。让数字人在说"请看左边大屏"的时候真的指向左边,这篇文章才算对得起"具身"两个字。

5.1 KA 接口到底是什么

KA = Knowledge Action,魔珐星云的动作语义库。文档里叫 "具身驱动 KA 查询接口"。

一句话:GET /user/v1/external/lite_ka_summary 会返回当前应用可用的所有动作清单,每个动作有英文名、中文名、类型、预览图、预览动画。

这就是后面要把动作变成 LLM function tool 的金矿。

5.2 鉴权:MD5 签名五步法

星云 API 用一套相对少见的 MD5 签名方案(X-APP-ID + X-TIMESTAMP + X-TOKEN)。完整 Python 实现:

关键细节:

• JSON 必须 sort_keys + 去空格 — 不然签名对不上

• 时间戳 60 秒内有效 — 客户端和服务端时钟偏差要注意

• url 全部小写 — query string 也要小写

5.3 动作清单长这样

使用时只取 name 最后一段(如 PointingSelf),塞到 SSML 里:

数字人会先做"指向自己"动作,然后说话同时手势配合。

5.4 把 KA 列表转成 LLM function tools

核心来了。我们要让 LLM 在生成回复时,自动从动作库里挑一个合适的动作搭配文本。这里我用 Anthropic 的 Tool Use 演示(Claude 的 tool 定义和 OpenAI 的 function calling 几乎一样):

现在用户说一句话,LLM 就会返回一个结构化的 {action, dialogue}。

5.5 组装 SSML,送进数字人

跑起来的效果是这样的:用户问"给我介绍下这款产品"——LLM 选择 PointingRight 动作 + 说"来,看这里,我给您介绍一下",数字人手势一指、语调一扬、内容一接,完整的具身表达。

5.6 为什么这是"类 MCP"的设计?

MCP 的核心哲学是:把 Agent 能调用的一切(API、数据库、文件系统、第三方服务)抽象成统一的 tools 协议。LLM 看到一个工具目录,自己决定什么时候调、怎么调。

我们这节做的事本质上是一样的——把星云的动作库暴露成 LLM 的 tools,让 LLM 决定"说什么的时候做什么动作"。

如果进一步把这个能力封装成 MCP Server,那任何支持 MCP 的 Agent(Claude Desktop、Cursor、VS Code、自建 LangGraph Agent)都能天然具身化——它们原本只会打字,接入后马上多一个会说会做的 3D 表达端。

这是个巨大的想象空间。具身输出,也可以是一个标准的 MCP 工具类型。

一句话:星云 KA 接口 + MCP = 具身输出即服务。

---

六、Widget 系统:把 Agent 的工具输出可视化

到这里还差最后一块拼图——Agent 调完工具,结果怎么给用户看?

举个场景:用户问"查一下明天上海的天气",Agent 调 MCP 的 weather 工具,拿到一张 JSON 数据。如果只是让数字人念一遍,体验是 60 分;如果数字人边说边在画面里弹出一张天气卡片,体验是 95 分。

星云的 Widget 系统就是解决这个的。

6.1 Widget 事件一览

SDK 内置支持的 widget 事件:

事件	作用	数据字段
subtitle_on / subtitle_off	字幕	{ text }
widget_pic	显示图片	{ image } (注意字段是 image 不是 url)
widget_video	播放视频	{ src, action: "play"/"stop" }
widget_slideshow	PPT 展示	{ url, page }
widget_text	文本卡片	{ text }

这些事件从服务端通过参数流里的 event 通道下发——记得上面说的 ttsa 四路参数流吗?Widget 就是 event 通道的具体应用。

6.2 接管字幕样式 / 展示天气卡片

用 proxyWidget 局部接管事件,既保留 SDK 默认的视频/图片渲染,又能自定义字幕样式:

避坑提醒:proxyWidget 是"局部覆盖"——没配的事件走 SDK 默认行为。但如果配了 onWidgetEvent 回调(哪怕只打一行日志),SDK 会认为你要完全接管 UI,默认背景、默认字幕会全失效。看到背景突然消失,先检查是不是意外配了 onWidgetEvent。

6.3 端到端:Agent 返回工具结果 → Widget 展示

我在 Demo 里把这条链路跑通了:

SSML 片段长这样(服务端 TTSA 会把 image_url 转为 widget_pic 事件):

一段 SSML,一次请求,触发:动作 + 语音 + 图片展示三通道同步。

---

七、真实体验、延时数据、场景落地

7.1 我的实测延时

把工作台调试面板打开,发送一条 Welcome KA 意图的 SSML:

• speak 指令首帧耗时:1314 ms

• 状态切换耗时:715 ms

• 连接稳定:3.5 分钟无断线

对比参考:

• MuseTalk 类开源方案首包:2-5 秒

• 扩散模型类(EMO/Vasa):分钟级

• 商用 API 数字人(某些主流厂商):2-4 秒

星云的 1.3 秒,目前在我实测过的方案里是领先的。这个数字还没算上可以通过 onNetworkInfo 回调拿到的实时 rtt,可以做网络感知动态降级。

7.2 别嫌弃老设备：存量屏升级才是大生意

文档里我特别注意到两件事:

一、JS SDK 全面覆盖主流终端

• iOS:16.6 - 18.6 全测(含 iPhone、iPad)

• Android:小米 HyperOS、Oppo、Vivo

• PC:macOS 15.6、Win10(Dell / 华为 / 华硕)

这意味着几乎所有装了现代浏览器的设备,都能直接跑。

二、Android SDK 适配国产嵌入式 SoC

• RK3588 → 1080P 可用

• RK3566 → 720P 可用

这是一个极重要的信号。RK3588 / RK3566 是教培一体机、连锁门店大屏、政务终端、工业显示屏的核心 SoC——全国几千万台存量屏幕的硬件底座。星云这一层往下铺,目标很明确:让存量屏不换硬件,通过升级"安装一个 SDK"变成 AI 服务终端。

7.3 场景速写:四条可立即落地的商业路径

按"存量屏 + 星云 SDK"这个公式推演,我能看到的立刻能跑通的场景:

① 教培一体机 → 24h AI 辅导老师 线下教培机构有大量教师机、班级一体机,原本只能播课件。接入星云,晚间自习无老师值班时段,一键切换到"AI 陪伴老师",答疑、讲题、打气,全部具身交互。

② 零售门店大屏 → 3D 智能导购 传统门店大屏只能循环播广告。星云接入后变成会主动搭话、按需介绍、边说边展示的虚拟导购。对接后端的 CRM / 商品库,每个用户看到的介绍都是个性化的。

③ 政务服务终端 → 具身接待员 政务大厅的自助查询机常年面对不会用的老年人。具身数字人可以主动询问需求、引导办事流程、用方言交互——降低数字鸿沟的最直接姿势。

④ 机器人上肢/头显表达 这个更远,但方向清晰。人形机器人、服务机器人的"上肢表达"层,完全可以复用星云的参数流协议——机器人的胸口屏、面板屏挂一个具身数字人,机器人的"脸"就是数字人。

7.4 成本细节:被我忽略但实际很重要的设计

调研时发现两个"看似小但实则非常省钱"的设计:

• 离线模式(offlineMode):长时间无人互动时进入,不消耗积分,画面上依然显示一个循环的待机动画。商用部署 24 小时开机,这个设计省下的成本相当可观。

• 基础音色 vs Pro 音色:30+ 音色里"基础"档免费,"Pro"档消耗更多积分但音质更好。开发调试阶段全程用基础档,上线后再切 Pro,开发期积分可以省一个数量级。

---

八、Agent 生态视角:星云到底是哪一层?

写到这里,我想回到开头那个问题:魔珐星云在 Agent 生态里的位置到底是什么?

为了讲清楚魔珐星云到底在哪一层，我拆解了一个 Agent 的‘四层架构’。大家可以对照下面看，现在的 Agent 生态其实已经卷完了‘大脑’和‘手脚’，最缺的其实是那个‘脸面’。

• 功能： 把冰冷的文字 Chunk 变成 3D 形象、情绪化口型和具身动作。

• 地位： Agent 的“皮肤”和“嘴巴”，决定了交互的温度。

• 推理层（GPT / Claude / DeepSeek） —— [核心大脑]

• 功能： 逻辑推导、文本生成、意图识别。

• 地位： 决定 Agent 的智商。

• 工具层（MCP / Function Calling） —— [手脚能力]

• 功能： 查数据库、调 API、控制外部设备。

• 地位： 决定 Agent 的办事能力。

• 载体层（各类屏幕 / 机器人） —— [物理外壳]

• 功能： 运行环境，无论是老旧的 1080P 屏还是最新的机器人。

为什么我把星云看作“具身表达协议”而不是单纯的数字人？

很多人把数字人看成是“做个模型、对个口型”。但我实测星云 SDK 后的感觉是：它在尝试定义一套 “动作语义标准”。

就像我们需要 HTTP 协议来传网页、HDMI 接口来接显示器一样，Agent 走进现实世界，也需要一套通用的 “身体指令集”。星云这套参数流架构，本质上是把复杂的 3D 驱动简化成了几个语义化的 API。这种“把底层渲染封装成高层语义”的操作，才是它跳出传统数字人坑位的核心竞争力。

MCP 把"工具层"推到了标准化,接下来最可能被标准化的就是表达层——因为这是 Agent 走到"用户可见层"的最后一米。

魔珐星云的定位,我的判断是:它不是争"数字人产品"这个赛道,它是争"具身表达协议"这个身份。就像 HDMI 之于显示、USB 之于接口、HTTP 之于网页——一旦表达层被某个协议占住,生态就开始围绕它长出来。

参数流架构 + KA 动作语义 + SSML + UE4Event + Widget,这套组合拳,看起来像一个"SDK 文档",但你把它抽象一下,本质上是一份具身表达层协议规范。

当你看到这个层次,就会明白为什么官方反复强调"星云是 AI 屏幕 OS,不是数字人平台"——数字人是一个产品,星云是一套协议 + 渲染底座。一字之差,天壤之别。

---

九、写在最后：让 Agent 走出对话框

折腾完这一圈，我最大的感悟是：数字人不再是那个只能录录视频、播报新闻的“展示品”了，它正在变成 Agent 的“具身皮肤”。 一个会思考、有情感、能互动的 3D 形象，带给用户的冲击力是文本框永远给不了的。

欢迎来体验一下：xingyun3d.com?utm_campaign=daily&utm_source=jixinghuiKoc41

---