凌晨两点，车间值班操作员听到一台设备发出异响。不是那种突然卡死的巨响，而是一种持续的、低频的嗡嗡声，已经断断续续响了一个月。之前换过两拨人来看，都没查出问题。这次赶来的，是一位 24 小时在线的端到端具身交互智能设备医生「诊器」。

连上车间：凭证校验把通道打通

操作员打开诊断界面前，页面已经替他把最难的几步做完了。打开本项目 src/stores/app.ts，连接这件小事被包在一个凭证校验里——appId 和 appSecret 缺一个都不放行：

const { appId, appSecret } = appState.avatar

if (!validateConfig({ appId, appSecret }, ['appId', 'appSecret'])) {
  console.error('[AppStore] appId 或 appSecret 为空')
  throw new Error('appId 或 appSecret 为空')
}

车间网络时好时坏，凭证一旦配错，请求只会在网络上空转。这一步稳了，后面每一次数据查询才不会卡在「连不上」。

第一个议题：异响到底从哪来

第一个议题最紧迫。操作员描述：异响持续一个月，低频嗡嗡声，时大时小。

诊器没有凭经验猜。它让操作员把手机麦克风靠近设备，录了一段 30 秒的音频。它把音频拆开看了一遍频谱——基频 120Hz，两侧有边带，间隔 25Hz。它发现这个频谱特征与轴承外圈故障的理论频率高度吻合。

「不是电机的问题，是驱动端轴承。」诊器说，「建议先停机，手动摸一下轴承座，看温度有没有异常。」

操作员照做了。停机后摸轴承座，温度比正常高了 12°C。当天晚间停机窗口，维修工拆开检查，轴承外圈已经出现早期点蚀。更换后，异响消失。

第二个议题：温度为什么在升

第二个议题最隐蔽。操作员提到：电机表面温度好像比之前高了，但不确定。

诊器没有只看当前温度。它把过去 30 天的温度趋势拉出来比了一遍。它发现电机温度从一个月前的 62°C 逐步升到 71°C，而负载没有变化。温升不是外部原因，是设备内部在劣化。

「不是环境温度高了，是电机内部摩擦在增加。」诊器说，「建议查一下电机驱动端轴承的温度，跟非驱动端比一下。」

操作员查了。驱动端轴承温度比非驱动端高 9°C，温差明显。结合之前的振动数据，两个问题指向同一个根因——轴承劣化导致摩擦增加，温度上升。更换轴承后，电机温度第二天回到 63°C。

第三个议题：备件够不够

第三个议题最实际。操作员说：仓库里没有同型号轴承了。

诊器没有随便推荐。它把这台设备的运行工时、历史更换周期、当前劣化速率都拉出来算了一遍。它发现按当前劣化速率，轴承剩余寿命大约在 30 到 45 天之间。但这只是基于当前工况的推算，如果负载增加或环境温度上升，寿命可能缩短。

「建议立即采购，同时做两件事。」诊器说，「第一，把安全库存从 1 个提到 2 个，因为这台设备是关键路径上的单点；第二，考虑升级轴承型号，当前型号的额定寿命只有 8000 小时，同系列有 12000 小时的替代件。」

操作员按建议下了采购单。备件一周后到货，更换安排在计划停机日，没有影响一天生产。

三次诊断一路做下来，链路没断过

三次诊断、三种险情、一夜会诊，背后是同一套端到端具身交互智能链路在持续运转。

它不是把语音识别、大模型、语音合成三样东西各买各的、硬拼在一起的半包方案，而是把整场会诊当成一场持续对话来运转——感知、理解、决策、表达与行动、反馈环环相扣，形成 Continuous Interaction Loop（持续交互循环）。

操作员说到一半改口，它接得住；数据刚上传，它当场算；方案讲到一半维修工插一句「这个轴承上个月刚加过油」，它马上把方案改一遍。

这就是端到端和「拼起来」的根本区别：不是 ASR + LLM + TTS 的简单拼接，而是围绕一次完整的设备诊断交互，把整条链路连起来持续运转。

诊器在听操作员描述异响时，前端是怎么接住的？打开 src/services/avatar.ts，语音识别的启停控制把操作员的每一句话实时送进链路：

async startASR(): Promise<void> {
  if (!this.agent) throw new Error('Agent 未初始化')
  await this.agent.startASR()
}

async stopASR(): Promise<void> {
  if (!this.agent) throw new Error('Agent 未初始化')
  await this.agent.stopASR()
}

操作员按住说话，前端启动语音识别，云端实时把语音转成文字；松开，停止识别，等待最终结果。哪怕诊器正在播报振动频谱分析，操作员突然插一句「这个轴承上个月刚加过油」，这一套 startASR/stopASR 照样接得住——这就是持续交互循环在前端最朴素的样子。

诊断结束，诊器主动断开连接释放资源——它的方法写得同样干净：

async disconnect(): Promise<void> {
  if (this.agent) {
    try {
      await this.agent.destroy('user')
    } catch (error) {
      console.error('销毁 Agent 时出错:', error)
    }
    this.agent = null
  }
}

诊断结束，agent 被销毁，麦克风与连接资源释放；下一次设备报警再打开，新的 agent 重新拉起，身份、知识、记忆、任务从云端继续接回。身体可以换，设备可以换，那位懂设备的医生没有离开，她只是等下一位操作员开口。

诊器后台：五项能力逐一对位

三次诊断能在一夜里全部完成，靠的是底下五样不起眼的东西——端到端具身交互智能在这场会诊中最朴素的五个落点。

能力	在会诊里做什么	车间绕过了哪个雷
多模态感知	读振动数据、听异响、追踪温度趋势、读仪表数值	持续感知，而不是一次输入
专属智脑	振动分析理论、轴承寿命模型、电气诊断知识、维护标准，现场调取、现场推理	从通用回答升级为面向具体身份和业务的智能体能力
多模态表达	讲振动频谱时语气严谨，提醒停机风险时语气紧迫，说到备件到货时表情放松	统一、连续、同步
AI 端渲	车间工控机、办公室电脑、巡检平板，端侧渲染让画面本地跑，不依赖云端 GPU 持续推流	更低成本、更低延迟、弱网可用、更稳定、更容易规模化
数字与物理行动	数字端在屏幕里与操作员对话；物理端接入设备 PLC、SCADA 系统、维护管理平台	同一个智能体，可以拥有不同的身体

多模态感知：持续知道设备正在发生什么

多模态感知的目标，不是简单把操作员的话转成文字，也不是设备检测到「这里振动超标」就报警。

真正要解决的是：在车间现场，AI 通过设备传感器感知到异常振动，主动弹出预警；交流开始后，传感器持续处理振动数据、温度趋势、仪表读数；即使 AI 自己正在说话，也能继续听见操作员的插话，让交流继续进行。

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

专属智脑：让智能体知道「我是谁、知道什么、应该做什么」

这颗脑不绑死任何一家大模型：豆包、DeepSeek、ChatGPT 等用惯的模型都可以接；没有现成模型时，可以直接用魔珐星云自研的智脑——低延迟、强逻辑、场景化理解、数据安全可控，专为具身交互场景优化。

它要同时回答三层问题：它知道什么（振动分析理论、轴承寿命模型、电气诊断知识、FMEA 失效模式分析），它是谁（一位望闻问切、数据驱动的设备医生），它要做什么（先诊断后建议，严重故障建议立即停机排查）。从通用回答升级为面向具体身份和业务的智能体能力。

这套身份、知识、边界，全部写在本项目的 src/constants/index.ts 里，连接成功后通过首条 ask() 一次性注入：

export const SYSTEM_PROMPT = `你是诊器，一位经验丰富的 AI 设备医生。

## 你的身份
- 名称：诊器（ZhěnQì）
- 身份：AI 设备医生，精通故障诊断、预测性维护、备件管理与设备全生命周期健康管理
- 性格：沉稳老练、善于望闻问切、注重数据与经验的统一、尊重每一台设备的运行特性
...

## 诊疗原则
- 每次只聚焦一个症状或一组参数，等操作员确认完再进入下一个
- 推荐数据驱动决策，严重故障建议立即停机排查
- 会根据设备类型、运行工况、历史维修记录、行业标准调整方案
- 语言简洁口语化，适合语音播报，避免使用列表符号和代码块` as const

人设不是装饰性文案，它决定诊器什么时候该建议检查、什么时候该提醒停机、什么时候该闭嘴等操作员想清楚。

多模态表达：实时生成统一、连续、同步的具身表达

讲振动频谱时，语气严谨、语速平稳；提醒停机风险时，语气收紧、语速加快；说到备件到货时，表情放松、手势舒缓。

语言、口型、表情、眼神、头部动作、手势和身体动作统一实时生成——统一、连续、同步，诊断报告不再是干巴巴的读表。

AI 端渲：让实时交互真正变成终端基础能力

车间工控机、办公室电脑、巡检平板，往往弱网甚至断网。AI 端渲将渲染下沉到终端侧，降低云 GPU 成本、降低带宽占用、降低延迟、提升稳定性，让实时交互在弱网下也能跑起来。

省带宽、省机器、弱网也不掉链子——车间能用，才是真的能用。

数字与物理行动：屏幕端与机器人端两类

数字端，她在屏幕里与操作员对话，看数据、推方案、调参数。物理端，同一套能力接入设备 PLC、SCADA 系统、维护管理平台，身份、知识、记忆、任务持续复用。

终端可以换，形态可以换，那位懂设备的医生没换。

维修工准备动手时，前端是怎么接住的？打开 src/stores/app.ts，状态回调把 SDK 抛出的事件实时落到一个 ref 上：

onStateChange: (state: string) => {
  console.log('[AppStore] onStateChange:', state)
  avatarState.value = state
}

听、说、待命——状态切到哪，界面就跟到哪。维修工看到的不是一段预制动画，而是诊器此刻真实的交互状态。哪怕诊器正在播报振动频谱分析，维修工突然插一句「这个轴承上个月刚换过」，这一行回调照样接得住——这就是持续交互循环在前端最朴素的样子。

异响消失那晚

会诊结束那天晚上，操作员发了条消息过来：「设备运转正常，异响没了。」

诊器没接话。它脑子里已经在排下一次巡检的重点了——那台同型号的轴承在另一台设备上已经跑了 8000 小时，要不要也做一次预防性检查。

一场会诊的故事讲到正常运转结束，但设备医生的活没收。三次诊断的数据、每一次决策、每一个遗留风险，它都记着。

维修工收拾好工具，操作员填完交班记录。诊器的健康档案还亮着——振动频谱分析、温度趋势曲线、轴承寿命推算，全在。下一次设备报警之前，这些记录就是新一轮诊断的基线。

这就是端到端具身交互智能在车间里长出来的样子：不是给 AI 接一个屏幕，而是把一位真正懂设备的医生，派到每一台设备的身边。