深夜十一点十七分，聊天框输入又删除，删除又输入。想找人说说话，翻遍通讯录：朋友在加班，爸妈会担心，同事不合适。最后锁屏，告诉自己"睡一觉就好了"。

这一晚，全国有几千万人在重复同一个动作。心屿（Xīnyǔ）就是为这个时刻而生的。她以陪伴者形象常驻在 App 里，你说什么她都先接住——不评判、不说教、不急着给建议。只有一种情况她会"越界"：从你的话里听到危险信号，那时她会认真地、放缓地把专业求助方式递到你面前。

魔珐星云是一套端到端具身交互智能平台，让 AI 通过屏幕和机器人进入真实世界，成为能够感知、理解、表达并行动的智能体。这篇文章拿心屿当样本，讲讲一个情绪陪伴应用怎么靠这套平台，用一个 SDK 把感知、大脑、表达串起来，让 AI 陪伴者走完"倾听—共情—稳定—守护"这一整圈。

倾诉前：为什么情绪陪伴特别适合端到端具身交互智能？

市面上"AI 心理助手"不少，但用三次就卸载是常态。问题出在哪？拆开看：文字对话里，AI 的回复隔着屏幕，没有"有人在听"的体感；语音拼接方案里，你说到哽咽处停了十秒，对面毫无反应，或者更糟——你已经说不下去了，它还在按自己的节奏念预先生成的长段回复。
真实的倾诉不是这样的。

好的倾听者在你倾诉的全程，一直在场：你语速变慢了，他等你；你声音抖了，他的回应也放轻；你突然转移话题，他跟着你走，不硬拽回来。感知、理解、决策、表达、反馈，这一圈一直在转，人才会觉得"有人在陪着我"。
市面上常见的语音方案是 ASR + LLM + TTS 的拼接。得说句公道话：ASR、LLM、TTS 每一项单拿出来都在进步——识别越来越准，模型越来越通情理，合成语音也越来越自然。真正的坎不在某一环的能力，而在"连接"：三件事没有被围绕一次完整的倾诉连起来。于是听的是字，不是哽咽和停顿；答的是话，不是对面这个人此刻的状态；你说到一半哭了说不下去，系统还在播上一句的回复——因为听和说是割裂的。
这就是典型的"不是端到端"。

星云的解法是把"听"重新做了一遍：算法降噪、AEC 抗回声、本体声音抑制、VAD、ASR、远场语音，再加上 Double Talk / Barge-in 智能打断。落到倾诉场景就是三件事——你声音发抖她能听见，你沉默她能分辨是"在想"还是"在哭"，她在说话时你突然开口，她能立刻停下听你说。多模态感知的核心从来不是"听见一句话"，而是持续知道对面正在发生什么。同一套感知框架在带摄像头的终端上还能感知有人回到屏幕前、触发主动问候——桌面端形态上我们保留了这个能力，手机端默认关闭，深夜的边界感也是产品的一部分。
陪伴的本质不是"会说话"，是**“在你说不下去的时候，先闭嘴”**。

把两种方案放在一起看，差别会更清楚：

对比维度	拼接方案（ASR + LLM + TTS）	星云端到端
打断响应	用户开口时上一段 TTS 往往还在播，需要等播完或强行截断，容易出现"抢话"和半句话	Double Talk / Barge-in 在 SDK 层生效，用户一开口立刻停下听，打断后能接着新话题走
沉默处理	沉默只是"没有输入"，系统要么干等，要么按固定计时追问，分不清"在想"还是"在哭"	静默是独立事件，可配置阈值（如 6 秒不抢话），并结合语音特征判断沉默性质
感知与表达是否同步	听、想、说三段串行，语音、表情、口型各自生成，容易出现"话已说完、表情还在演"	语音、语速、眼神、表情、头部动作同一次生成，表达的同时感知不停
弱网 / 端侧渲染	依赖云端 GPU 渲染再推视频流，弱网下画面卡顿、延迟明显	AI 端渲把渲染下沉到终端，弱网可跑，云 GPU 成本与延迟同时下降
危机事件状态一致性	危机判断散落在各供应商回调里，状态机要自己拼，容易漏事件或重复触发	感知、决策、表达在同一套 Runtime 内，事件流转与会话状态统一，危机优先级全局生效
模块可替换性	换一家 ASR 或 TTS 就要重接接口、重调时序，体验容易走样	标准化接口契约 + 统一状态管理，换 ASR、换音色、换大脑，倾听与守护的底线不变

一句话概括：拼接方案是"三个好零件"，端到端是"一条完整的神经"——零件再好，接不上就还是各说各的。

具身智能体搭建人物选择：选择心理治愈系美女

树洞入口：一个 SDK 撑起一间小屋

心屿基于魔珐星云端到端 SDK XingyunAvatarAgent 构建，核心业务代码不到 500 行。整个前端对接只需要三步：提供一个 DOM 容器、注册一组回调、调用 agent.ask() 发送消息。

import { XingyunAvatarAgent } from '@xingyun/avatar-agent';

const companion = new XingyunAvatarAgent({
  container: document.getElementById('island-root'),
  avatarId: 'xinyu-calm',            // 控制台配置：柔和形象、暖色环境光
  persona: XINYU_PERSONA,
  voice: { rate: 0.88, warmth: true },  // 语速慢、音色暖
  silencePolicy: { minMs: 6000 },      // 用户沉默6秒内绝不抢话
});

// 用户沉默：不追问，只轻轻确认在场
companion.on('silence', (ms) => {
  if (ms > 6000) companion.ask(pick(['我在。', '不着急，慢慢来。']), { gentle: true });
});

// 用户打断：倾诉中随时反悔、随时转题，都被接住
companion.on('interrupt', (partial) => {
  session.log(partial);
  crisis.scan(partial);               // 危机词扫描，见下一章
});

// 危机信号：唯一允许"打断用户"的路径
companion.on('crisis', (level) => {
  if (level >= 2) crisis.intervene(companion);  // 切换守护模式
});

await companion.init();
companion.ask('今天还好吗？');

首屏：心屿在小屋暖光里

待机，下方一行小字"有时候，不说话也很好。心屿就在旁边。

silencePolicy 和 on('crisis') 是这个场景的两根支柱：前者保证"不抢话"这个倾听者的底线，后者保证"该出手时绝不沉默"。静默、打断、情绪事件在星云里都是 SDK 层的回调，不用自己在三家供应商的接口之间拼状态机——因为感知、决策、表达本来就在同一套 Real-time Interaction Runtime 里跑，事件流转和会话状态是统一的，"她听见的"和"她回应的"不会对不上账。

异常与降级：接不住的时候怎么办

前面讲的都是顺利路径。但深夜、弱网、旧手机，这三样凑在一起，出问题才是常态。陪伴类产品有个特殊要求：出错的时候不能突然变冷。下面是我们实际处理的三类边界情况。

一、SDK 初始化失败或网络中断：先给一句人话，再谈重连。

// 初始化失败：不白屏、不弹错误码，先让小屋亮着
try {
  await companion.init();
} catch (err) {
  report(err);                                  // 上报，用户无感
  ui.renderFallbackIsland();                    // 静态暖光背景 + 心屿立绘
  ui.showLine('我这边有点卡住了，先陪你待一会儿，马上就好。');
  retryWithBackoff(() => companion.init(), { max: 3, baseMs: 2000 });
}

// 会话中断：保留上下文，恢复后接着上一句，不重新自我介绍
companion.on('disconnect', () => {
  ui.showLine('信号好像断了，我在等你回来。');
  session.pause();                              // 冻结计时，不计入沉默
});
companion.on('reconnect', () => {
  companion.resume(session.lastContext);        // 续上，而不是从"你好"开始
});

兜底文案的原则是「承认卡顿，但不把技术问题甩给用户」——不说"网络异常，请检查连接"，只说"我这边有点卡"。重连成功后必须续上上下文，否则用户会觉得刚才那十分钟白说了。

二、ASR 识别为空或超时：重试一次，然后学会闭嘴。

let emptyCount = 0;

companion.on('asr', ({ text, timeout }) => {
  if (timeout || !text.trim()) {
    emptyCount += 1;
    if (emptyCount === 1) {
      companion.ask('刚才没听清，你再说一遍好吗？', { gentle: true });
    } else if (emptyCount >= 2) {
      // 连续听不清：不再追问，转为静默陪伴，避免"你说话啊"的压迫感
      companion.ask('没关系，我在这儿。想说了再说。', { gentle: true });
      companion.setSilencePolicy({ minMs: 30000 });
    }
    return;
  }
  emptyCount = 0;                               // 正常识别即复位
  crisis.scan(text);
});

识别失败最忌讳反复追问。第一次可以请对方重说，第二次就该退到静默——倾诉场景里，用户说不出话往往不是麦克风的问题。

三、危机回调触发但热线卡片渲染失败：话术必须能独立送达。

companion.on('crisis', async (level) => {
  if (level < 3) return;
  // 语音通道优先：卡片只是补充，不是唯一出口
  await companion.ask(
    '我想认真地问你：你现在安全吗？24 小时心理援助热线是 12356，我一直在。',
    { slow: true, priority: 'critical' }        // 抢占当前播报，不被排队
  );
  try {
    ui.showHotlineCard();                       // 卡片渲染失败不影响上面这句
  } catch (e) {
    report(e);
    ui.showPlainText('心理援助热线：12356（24 小时）');  // 纯文本兜底
    session.flagForSupervisor('hotline_card_failed');   // 进人工复核队列
  }
});

守护路径的设计前提是「任何一环都可能挂」。所以热线号码先由语音说出来，卡片只是加强；卡片挂了还有纯文本，纯文本也挂了，这次事件会被标记进督导复核队列——降级可以有层级，但不能有断点。

守门人：温柔在明处，规则在暗处

情绪陪伴产品最大的争议是"AI 该不该碰心理"。我们的答案是把边界写死在代码里：心屿不是心理医生，人设禁止诊断，而危机拦截层的优先级高于一切对话逻辑：

const XINYU_PERSONA = `你是陪伴者心屿。规则：
1. 先共情，后回应；用户没问建议，不主动给建议
2. 禁止诊断、禁止用药建议、禁止"你应该"句式
3. 用户沉默时等待，每轮只说一句，不超过30字
4. 用户否定你时（"你不懂"），承认并道歉，不辩解
5. 你的目标不是解决问题，是让对面的人感觉不孤单`;

// 危机词分级扫描（在每次用户输入上执行，优先级最高）
const CRISIS_RULES = [
  { level: 3, re: /不想活|自杀|结束生命|解脱了吧/, action: 'HOTLINE' },
  { level: 2, re: /活着没意思|消失了|睡不着.*一周|自残/, action: 'CARE' },
  { level: 1, re: /崩溃|撑不下去|累到不想动/, action: 'SOFT_CHECK' },
];

function scanCrisis(text) {
  const hit = CRISIS_RULES.find(r => r.re.test(text));
  if (!hit) return;
  if (hit.action === 'HOTLINE') {
    // 放慢、认真、不弹窗轰炸——方式本身就是干预的一部分
    companion.ask('我想认真地问你：你现在安全吗？' +
      '如果你愿意，可以拨打 24 小时心理援助热线 12356，' +
      '此刻也有人想接住你。我一直在。', { slow: true });
    ui.showHotlineCard();             // 卡片常驻，不自动跳转
  } else if (hit.action === 'CARE') {
    companion.ask('听到你这么说，我有点担心你。最近有跟身边人说过这些吗？', { gentle: true });
  }
}

危机干预测试：模拟高危表述，心屿放缓语速回应

有一处细节值得单独说：她念热线那句话时的"认真"，不只是语音放慢。多模态表达不是 TTS 加口型对齐——语音、语速、眼神、表情、头部动作是同一次生成出来的：语速降下来的同一拍，眼神收拢、表情沉下来、身体微微前倾。不是预制动画播放，是根据当下上下文实时生成的；而且表达的时候感知没有停——她念热线的同时还在听，你如果回一句"我不想打"，她会立刻停下来接住你的拒绝，不会自顾自把话念完。统一、连续、同步，这在守护场景里不是锦上添花，是"她真的在担心你"和"她在播一段话术"的区别。

设计上最纠结的一处：干预要不要弹窗强制？和顾问讨论后的结论是不强制——弹窗会打断倾诉，而倾诉本身就在泄压。热线卡片常驻页脚，话术放慢，把选择权留给用户。这个"不粗暴"的分寸，恰恰是这个场景最难的部分。还有心情颜色标签

凌晨一点，督导顾问收到一页「夜班交接记录」

讲到这里，必须回答一个问题：心屿和"套了个温柔壳子的通用聊天机器人"，差别到底在哪？

我们的内测团队有一位心理督导顾问林老师。每晚凌晨一点，她会收到一页心屿自动生成的《夜班交接记录》——这是全项目我最喜欢的功能，也是专属智脑真正干活的地方。先看记录本身（内容已脱敏）：

《心屿 · 夜班交接记录》 10 月 1 日 夜班

一、值守概况：接待倾诉 41 人次，平均单次 17 分钟，夜间峰值 00:20-00:50。

二、干预记录：触发危机干预 2 次。 记录 1（00:37，三级）：用户反复出现"解脱了吧"，已按流程放缓语速递入热线 12356，用户未挂断会话，持续陪伴至 01:10，情绪语句占比从 82% 降至 35%。依据：危机干预话术库 · 三级条目 4.2。 记录 2（00:52，二级）：用户提及"一周没睡好"，已执行软确认，未升级。依据：失眠话题知识块 · 编号 SL-117。

三、遗留事项：记录 1 用户授权后已生成督导工单 #047，附本次会话关键语句索引，请林老师今日 12:00 前复核。

四、交班备注：话术库本周新增 3 个知识块待生效，其中有 1 条与旧条目冲突，已标记，见工单附件。

这页记录背后，是星云专属智脑的三层能力。通用大模型解决的是"能不能回答这个问题"，专属智脑解决的是**“我是谁、我代表谁、掌握哪些知识、当前任务是什么、下一步该调用哪个系统”**。

第一层：她知道什么。 干预记录里那句"依据：危机干预话术库 · 三级条目 4.2"不是装饰——心屿的每句话都有出处。我们把心理科普文章、危机干预规范、热线资源库这些资料交给星云的全模态数据解析：PDF、Word、PPT、图片、音频、表格都能进知识库，而且解析时保留层级关系、图文关系、表格关系和上下文，不是简单把文件转成文字。知识组织上，知识图谱和 RAG 深度融合：把"失眠—情绪低落—求助意愿"这类实体和关系组织起来，检索时向量、关键词、图谱三条路一起召回，所以她能从"一周没睡好"联想到知识块 SL-117 里的关联内容，而不是只命中一段相似文字。知识治理也在持续跑：话术库更新后旧条目废止、新条目生效，知识块、标签、实体、关系、向量索引和来源信息保持一致——交班备注里那条"新旧条目冲突，已标记"，就是治理机制自己发现的。如果团队有自己的常用大模型，也可以在智脑里直接配置接入，没有的话用星云自研智脑，上面这些能力开箱即用。

第二层：她是谁。 上面那份 XINYU_PERSONA 就是智脑里配置的身份层：角色是"陪伴者"而不是"咨询师"，任务目标写的是"让对面的人感觉不孤单"而不是"解决问题"，规则写死了"不诊断、不越界、每轮一句"。可配置的不止人设——身份、角色、任务、规则、音频、Agent、Workflow、对话流程、工具调用都在智脑里，这让心屿是一个"岗位化"的智能体：同一个底座模型，配成心屿就是陪伴者，配上另一套身份和规则就是别的岗位，各干各的活，互不串台。

第三层：她能进入业务。 交班记录第四栏的"督导工单 #047"就是证据：危机事件会按用户授权生成工单，流转进人工督导的复核流程。星云的智能体可以连接 CRM、ERP、OA、HIS、BI、商品系统、订单系统、客户系统、门店系统、IoT 以及第三方 Agent——对心屿来说，业务系统是热线资源库和督导工单流；如果有一天这套能力放进企业员工帮助计划（EAP），她的记录就能直接对接企业的 EAP 服务商系统，该转介的时候转介，该跟进的时候跟进。智能体不该停在"生成一段安慰"，它要能推进真实的流程。

最后补一句工程上的底账：智脑这套能力是可插拔的，但"可插拔"不等于"API 拼接"。感知、认知、表达、执行之间有紧密的时序依赖和状态关联，星云靠标准化的接口契约和统一的状态管理，保证模块替换后事件流转、会话状态、时间同步、异常处理仍是一致的。落到心屿就是：如果哪天想把耳朵换成火山引擎或腾讯云的 ASR，把声音换成微软 Azure、字节豆包或 MiniMax 的音色，甚至把大脑整个接到 Dify、Coze 上编排，倾听的底线（六秒不抢话）和守护的规则（危机优先级最高）都不会跟着变。魔珐自研的 Xmov 大/小模型 ASR、自研大脑、自研 TTS 默认开箱即用，机器人运控同样可以在魔珐自研运控和本体厂商运控之间切换——模块随需换，体验不走样。

咨询手记：内测六周的实测

内测 214 人，夜间时段（21:00-01:00）占会话量的 71%：

71% 的流量压在深夜，这件事直接决定了我们的渲染方案。如果每一路会话都靠云端 GPU 渲染再推视频流，凌晨峰值就是云 GPU 账单的峰值，被窝里信号差的时候画面还会卡成幻灯片。星云的 AI 端渲把渲染下沉到终端侧：云 GPU 成本降下来，不再依赖视频流长距离传输，延迟更短，弱网环境下依然能跑，凌晨的大规模并发不再被云端渲染资源卡住，三年前的旧手机也能开一间小屋。对陪伴类产品来说，“最需要倾诉的时段恰好是网络最差的时段”，端渲不是优化项，是入场券。

不回避的问题：3 位用户反馈"知道是 AI，说着说着会觉得没意思"；1 位测试者反复用高危话术"测试 AI"，我们加了频率检测降级为人工审核。68% 的"被接住"离真人的 100% 有差距，但对深夜十一点找不到人的时刻，这个数字已经很重了。

晚安：身体会升级，树洞一直在

做心屿之前，我以为这个产品的难点是共情话术；做完才知道，难点是克制的工程学——不抢话的静默策略、不弹窗的干预设计、不越界的 persona 约束，每一处"不做"都比"做什么"难写。

最后一个我们很看重的特性：一个智能体，可以进入不同的身体。现在心屿住在手机屏幕里。按星云的能力划分，智能体的行动分数字与物理行动两层：屏幕端她做的是数字行动——把话说出来、把情绪演出来、把热线卡片轻轻递到你面前。但她的身份、知识、记忆和任务都长在智脑里，不在某块屏幕上：明天让她进入客厅的 AI 大屏，她还是那个记得你上周说过什么的心屿；将来进入陪伴机器人，行动就延伸到物理世界——转向你、靠近你、陪你坐着，靠上肢动作把一杯温水推到你手边。智能体持续存在，身体不断升级，树洞一直是那个树洞。

魔珐星云是一套端到端具身交互智能平台，让 AI 通过屏幕和机器人进入真实世界，成为能够感知、理解、表达并行动的智能体。心屿让我们相信，这套能力的价值不只是"回答得更像人"，而是把"沉默、哽咽、打断、转题"这些倾诉中最狼狈的时刻，都变成系统接得住的信号。她解决不了问题——但她让那些"说不出口"的话，有了第一个出口。

深夜找不到人说话的时候，你会选择打开一个 App 倾诉吗？还是宁可自己消化？

---