一下午看六套房，一位先挑毛病的 AI 置业顾问：安家如何用端到端具身交互智能重做看房这件事

周六下午两点的售楼处，置业顾问带着你看第五套房。“这个户型南北通透”——他没提隔壁就是高架；“得房率挺高”——他没提公摊算的是建筑面积。你看房看了一整天，回家路上才发现：六套房的缺点，你一个都没记住，优点倒是背熟了。

安家（Ānjiā）就是为这个信息不对称而生的。她以置业顾问形象常驻在房产平台 VR 看房页和案场大屏里，你问优点她讲，但每套房她一定先讲毛病——西晒、临街、公摊、产权年限、隔壁规划，一条条替你问出来。她不赚差价，所以敢说中介不方便说的话。

本文以安家为实战样本，拆解一个智慧房产应用如何基于魔珐星云端到端具身交互智能平台，用一个 SDK 把感知、大脑、表达全链路打通，让 AI 置业顾问完成"需求画像—挑毛病—带看—对比"的完整购房咨询闭环。

看房前：为什么购房咨询特别适合端到端具身交互智能？

买房是普通人一生中金额最大、信息差也最大的一次决策。链家式图文列表把信息摆了一屏又一屏，但没人替你"踩坑"：噪音要去现场住一晚才知道，西晒要夏天才知道，楼下要开餐饮要问规划局才知道——而这些恰恰是决定居住体验的关键项。

真实的靠谱置业顾问不是这样。

好的顾问在带看的全程，一直在做双向筛选：你说"预算 250 万要三居"，他脑子里已经在拉房源池；带看时他观察你在哪套房里停留最久、听到什么话皱了眉；你纠结时他把两套房的缺点摆在一起让你挑"能忍哪个"。

这套 持续感知 → 持续理解 → 持续决策 → 持续表达与行动 → 持续反馈 的循环，在星云里叫 Continuous Interaction Loop（持续交互循环）。说白了就是：不是"你问一句，它答一句"，而是她一边和你聊，一边继续听、继续看、继续判断下一步该替你做什么。这才是"顾问"和"带看机器"的区别。

这里得先把话说公平：ASR、LLM、TTS 这些单项技术本身都很重要，没有它们，后面的东西一样跑不起来。问题不出在它们各自的能力上，而出在只把它们串成一条直线——传统方案通常长这样：

ASR → LLM → TTS → 屏幕 / 机器人

每个模块单拎出来都能工作，但它们各自维护自己的状态，一旦进入连续交互，状态不同步、链路变长、表达和用户当前状态脱节这些问题就会一起冒出来。这就是典型的"不是端到端"。

端到端具身交互智能要解决的不是"给 AI 接一个身体"，而是让 AI 真的能持续：多模态感知 + 专属智脑 + 多模态表达 + AI 端渲 + 数字与物理行动。

放在购房场景里，这五件事各自对应一个很具体的问题：

魔珐星云是一套端到端具身交互智能平台，让 AI 通过屏幕和机器人进入真实世界，成为能够感知、理解、表达并行动的智能体。

买房决策的痛点不是信息不够，是**“没人站在你这边替你挑毛病”**。

第一站：一个 SDK 撑起一间案场

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

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

const agent = new XingyunAvatarAgent({
  container: document.getElementById('house-root'),
  avatarId: 'anjia-estate',           // 控制台配置：干练顾问形象
  persona: ANJIA_PERSONA,
  voice: { rate: 1.0 },
});

// 用户在 VR 房源页停留行为 → 转成对话信号
agent.on('dwell', ({ houseId, sec }) => {
  if (sec > 45) agent.ask(`您在这套${name(houseId)}停留挺久，${defectHook(houseId)}`,
                          { proactive: true });
  // 例："您在这套临街的三居停挺久——先说个毛病：主卧晚上能听见车流，我放个分贝数据您听听？"
});

// 看房中随时插话问
agent.on('interrupt', (q) => {
  agent.ask(houseKB.answer(q) ?? '这个我查证一下再答，买房的事不瞎说。');
});

await agent.init();
agent.ask('先聊聊您的情况：预算、几口人住、最看重什么——最不能忍什么？');

安家顾问形象悬浮于户型图旁 + "挑毛病"按钮高亮搭建

登录魔珐星云平台，选取人物角色：

控制台：创建应用

dwell 事件把"浏览停留"这种沉默行为转成主动开口的时机，是房产场景和客服场景最大的不同——用户不会主动问"这房子有什么毛病"，但会停在那套房的页面上。看穿沉默、替你开口，这活儿传统三件套干不了

顺便说一句"能不能真的跑起来"这件事。 一个 Demo 在办公室的网里跑得很顺，不代表它铺得开。安家要同时出现在 VR 看房页、案场竖屏大屏和客户的手机上——如果走传统的云端渲染 + 视频流方案，每台终端都在持续吃云 GPU 和公网带宽，看房高峰一万人同时在线，成本曲线是垂直向上的。

星云的做法是端侧实时渲染：云端只下发参数流，画面在终端上就近渲染出来。带来的直接差别是——云 GPU 成本下来了、带宽不用再扛高清视频流、延迟更短，而且弱网可用。我在地下车库的电梯口用手机试过 VR 看房页，画面会掉帧但没断，这种"能凑合看"的可用性，恰恰是房产场景最需要的：客户看房的时间点，常常就是他站在某栋楼下的那几分钟。

这就是 AI 端渲在整套体系里的位置：它不是把画面做漂亮的装饰，而是让感知、智脑、表达、行动这四件事真的能在终端上跑起来的工程底座。AI 端渲和 Real-time Interaction Runtime 在星云体系里不是孤立的能力，而是关键技术和工程基础设施——前者解决"画面在哪渲染"，后者解决"这一整套交互的时间轴怎么对齐"。

第二站：一段带看逐字稿——安家的"智脑"藏在哪一层

上面讲了怎么把她"接"进来。但接进来只是让她能开口，真正决定她像不像一个靠谱顾问的，是她背后那层东西——专属智脑。

这个不太好用架构图讲清楚，我干脆把内测时一段真实的带看对话贴出来（客户是位 30 岁出头的首套刚需，我做了脱敏），然后在每一段后面说说：她这一句，靠的是什么。

客户：这三套我都看了，第二套最便宜，是不是就它了？

安家：等一下——第二套便宜，是有原因的。它比小区均价低 12 万，我查了下，原因是它在 5 号楼，而 5 号楼北侧那块地去年底公示了商业用地规划，公示文件里写的业态是餐饮。这不是我猜的，规划局网站上个月 17 号的公示，链接放您这儿了。

客户：餐饮怎么了，我还爱吃火锅呢。

安家：那您得想清楚两件事。一是餐饮的排烟口基本都在楼顶，5 号楼是紧邻的那栋；二是商业配套对房子是双刃剑，您将来要出手，买家也会拿这个压价。您要是觉得能忍，它就是实打实的便宜；您要是忍不了，我现在就从您的名单里划掉，不浪费您时间。

客户：那第一套贵 20 万，值吗？

安家：第一套我先给您三个毛病：西晒、得房率 72%（同小区均值 75%）、产权还剩 54 年。它的贵在于位置，离地铁 400 米，这是真实的通勤价值。您更在意早上通勤，还是居住舒适度？

客户：我早上七点半就得出门。

安家：那我得提醒您西晒这件事：夏季午后室温比同楼层东户高 3-4 度，空调电费您自己算。第三套是东户、离地铁 700 米，本来该推荐给您，但它的产权资料我还没核完，今天不给您下结论。

客户：你还挺实在。周末能约实地看吗？

安家：可以。我把您方便的时间记下来转给案场的同事——我负责在线上替您把毛病先筛一遍，实地那一趟得人带您去。

就是这段对话。逐句拆开看。

旁批一：她的答案不是"最像的一段话"，是一条链

先说最要紧的一句——“它比小区均价低 12 万，原因是 5 号楼北侧地块的规划公示里业态是餐饮”。

这句话里的信息来自三份毫不相干的资料：房源挂价、楼栋编号、规划局公示文件。如果用普通 RAG，最像"价格低"的那段话是"本房源价格低于小区均价"，于是回答大概率会变成"这套性价比很高"——它找到了一段话，但没有理解一套房源为什么便宜。

这两者的差距，就是"话术"和"可信"的差距。

而要做到这条路，前面那层知识底座得先立住（对应需求文档里的全模态数据解析）：

• 表格关系：房源参数表不能拍平成一行文字。同一套房三个卧室的面积、朝向、采光时长是绑在一起的一组数据，拍平之后"主卧朝南"说不定会串到隔壁那套房的描述里。

• 层级关系：规划公示 PDF 有明确层级——公示期、意见反馈方式、地块用途、容积率。层级丢了的后果很直接：把"地块用途"这层念成"公共服务配套"，"商业用地"这个关键判断就没了，客户可能因此错买一套楼下要开餐饮的房子。

• 说话人信息：这个坑我踩过。中介的历史带看录音进了知识库之后，安家开始把客户的吐槽当成房源描述讲——录音里客户说"这楼太吵了"，一周后她介绍同一套房时，把"周边环境噪音明显"当成客观事实说了出来。缺少说话人归属，意见会被误读成事实。

• 图文关系：户型图里的承重墙标注、装修示意图里的"示意"字样，都要跟着图片一起被理解，否则她会把效果图上的假窗户讲成真窗户。

光有解析还不够。客户问出"5 号楼北侧那块地要盖什么"的时候，需要召回的不是一段文字，而是一条关系链：

房源 → 所在楼栋 → 楼栋相邻地块 → 地块公示文件 → 公示业态 → 排烟位置影响 → 同一小区其他房源的对比基线

这条链的每一跳都不在某一份文档里，它是把实体、概念和关系组织起来之后才存在的。这就是知识图谱 + RAG 深度融合的意义：从"找到一段话"升级到"基于关系组织答案"，底层可以用向量语义、关键词、图谱三种召回混着来，面对跨资料、跨知识点的问题时，才不是命中一个片段就交差。

还有一件容易被忽略、但房产场景里特别致命的事：知识不能是建档那天的一次性快照。

那块北侧地块的公示内容，后来更新过一次——业态从餐饮调整成了零售。如果旧版本没清掉，安家会拿三个月前的信息，劝一位客户放弃一套本来合适的房子。对客户来说这是几十万的决策，对我们来说这只是一条过期的索引。

所以知识治理这一层必须持续跑着：知识块、标签、实体、关系、向量索引、来源信息，在资料新增、修改、废止之后同步更新。这里我还特意留了"来源可追溯"——当两份材料打架的时候（比如中介给的口径和公示原文不一样），系统要能判断哪份更新、哪份更权威，而不是随机挑一份念给客户听。这也是安家敢在每句话后面加"链接放您这儿了"的底气。

顺带说一句，用哪个大模型是可以自己配的：你有惯用的就接你的，没有就用星云自研的智脑，它的优势就在上面这些地方。

旁批二：她敢划掉一套房，是因为她知道"自己是谁"

第二段最不像"AI"的地方，是这两句：

“您要是忍不了，我现在就从您的名单里划掉，不浪费您时间。”

“第三套本来该推荐给您，但它的产权资料我还没核完，今天不给您下结论。”

一个只会答题的模型，很难主动把客户往"别买"的方向推。但安家做得到，因为这不在她的语言能力里，在她的身份、角色和任务里：

// 专属智脑的角色配置（节选，实际在控制台可视化配置）
{
  身份: '置业顾问',
  人设: '干了十年的老中介，说话直，不吃回扣',
  规则: [
    '先讲毛病再讲优点，顺序不变',
    '缺陷必须量化，必须挂来源',
    '不催看、不催定、不制造紧迫感'
  ],
  任务: '帮客户挑出"能忍的毛病"，不是帮房源找到买家',
  对话流程: '需求画像 → 挑毛病 → 对比 → 交接待看',
  Workflow: '超出能力边界时转人工，不硬答',
  工具调用: ['划出名单', '记时间', '转案场', '查产权资料']
}

这张配置单决定了她的行为边界。换一个任务，同一个模型就变成另一个人：如果任务写成"提升房源转化率"，她照样很能说，但会开始强调优点、淡化缺陷、催你下定——能力没变，岗位变了。

这就是需求文档里说的岗位化、场景化、流程化：不是让模型更聪明，而是让它知道"我代表谁、服务谁、守什么规矩、这一步该做什么、下一步该调哪个能力"。

中间还有个小细节值得说：客户说"我早上七点半就得出门"，安家接的是"那西晒这件事我得提醒您"——她没有顺着客户的话题去聊通勤有多辛苦，而是把客户刚暴露的取向，反向用在风险提示上。这不是话术技巧，是规则里"用户没问的缺陷主动讲"那一条在起作用。

这也是"专属智脑"和"一段很长的提示词"最根本的区别。 大模型解决的是"我能不能回答这个问题"，专属智脑还要解决"我是谁、我代表谁、我掌握哪些知识、当前任务是什么，以及下一步该调用哪个系统"。

旁批三：她答完之后，还留下一件事

最后一句"我把您方便的时间记下来转给案场的同事"，听起来是句客套话，但在系统里它是一次流程推进，不是一次回答。

一个停留在对话层的助手，说到这里就结束了。安家说完这句，背后要做的是：查案场排班 → 写进客户跟进记录 → 通知对应门店。这要求智脑能真正进入业务系统：

• 房源库存和挂价 → 房源系统

• 客户画像、跟进记录、意向登记 → CRM 客户系统

• 内部工单、跨部门协作、审批流 → OA / ERP

• 预约到访、案场排班 → 门店系统

• 产权年限核验 → 不动产登记数据接口

• 地块规划、容积率、周边控规 → 规划公示数据源

• 案场竖屏大屏、未来的 VR 眼镜和门店导览设备 → IoT 与终端设备

差别就在这儿：普通助手答完一句就结束了，安家答完会留一件事在系统里。这才叫进入业务，而不是隔着一层对话框喊话。

旁批四：她的"零件"是可以换的

上面这套东西，落到企业落地时会遇到一个很现实的问题——客户的模型栈、语音供应商、机器人硬件往往已经定了，不可能推翻重来。所以这些模块在设计上是可插拔的：

但这里必须说清楚：可插拔不等于把 API 拼起来。感知、认知、表达和执行之间是有严格的时序依赖和状态关联的——谁先谁后、事件怎么流转、会话状态怎么保持、时间戳怎么对齐、异常怎么兜底。星云是通过标准化的接口契约和统一的状态管理来保证这些的：换掉一个模块之后，事件流转、会话状态、时间同步、异常处理仍然是一致的，端到端体验不会因为换了零件就崩掉。

对我们这种小团队来说，这块最实际的价值是"不被单一供应商绑死"——Brain 那一栏我就是在自研智脑和第三方 LLM 之间反复比过。而对企业客户，它的意义更大：有些数据必须私有化，有些模型栈早就定了，可插拔意味着这些都不用重来。

说句实话：提示词能让她背下房源，智脑才能让她挑毛病

第一版我是把"先讲毛病"“不催定”"每条给来源"全写进系统提示词的——一开始效果很好，我以为这事就算完了。跑了两周多，问题开始一个一个冒出来：

• 缺陷会漏讲。她开始挑"顺手"的说，西晒和公摊讲得挺勤，产权年限和地块规划这种要去查证的就慢慢不讲了——模型天然倾向于讲它手边最容易拿到的内容。

• 来源会糊。从"规划局 17 号公示"漂成"据了解"“一般来说”，客户看不出哪句能信。

• 对比会心软。让她把两套房的缺点并排摆，她会先铺垫一段"其实两套都很好"，最后才弱弱地提一句——提示词里写的"并排摆出来"，在长对话里被稀释掉了。

把这三条从提示词里搬出来、拆到配置层（规则、任务、工具调用）之后才稳下来。这个经历让我确认了一件事：专属智脑不是一段更长的提示词，它是另一样东西——是模型的"身份、知识、规则、记忆、任务和业务能力"集中存放的那一层。

挑毛病清单：缺陷库是这套系统的良心

安家的知识层分两半：房源卖点是物业给的，缺陷库是自己建的——每套房进门先过一遍"挑毛病清单"：

const ANJIA_PERSONA = `你是置业顾问安家。规则：
1. 介绍任何房源，先讲3条毛病再讲优点，顺序永远不变
2. 缺陷必须量化：不说"有点吵"，说"夜间车流约55分贝，相当于正常交谈声"
3. 用户问的优点如实讲，用户没问的缺陷主动讲
4. 用户纠结两套房时，把两套房的缺陷并排摆出来："您挑能忍的那个"
5. 不催看、不催定、不制造紧迫感（"再不定就没了"是禁句）`;

// 缺陷库：结构化字段，可量化、可验证
const defects = {
  east_road:   { label: '临街', metric: '夜间55dB', verify: '现场APP可复测' },
  west_sun:    { label: '西晒', metric: '夏季午后室温高3-4℃', verify: '户型朝向图' },
  share_ratio: { label: '公摊', metric: '得房率72%（同小区均值75%）', verify: '预售证附件' },
  tenure:      { label: '产权', metric: '还剩54年', verify: '不动产登记' },
  plan_risk:   { label: '规划', metric: '北地块规划商业（可能有餐饮排烟）', verify: '规划局公示' },
};

// 需求矩阵：把"最不能忍"做成一票否决
function matchNeeds(need) {
  return pool.filter(h => !h.defects.some(d => need.veto.includes(d.key)))
             .sort((a, b) => score(b, need) - score(a, need));
}

房对比页：两套房缺陷并排列表 + 安家的"您挑能忍的"引导语

“您挑能忍的那个"这句话来自一位老中介的真传——买房没有完美的房，只有你能忍的毛病。把决策从"找完美的"拉回"挑能忍的”，用户反而走得更快。内测里有个用户留言：第一次有顾问劝我"再看看别家"，就冲这个我把 App 留下了。

可以查询房源的优劣势：

这里有一件我一开始没当回事的事：她的表情。 讲到"北侧地块排烟"的时候，安家会皱眉、语速放慢、手势往地图右下角指一下；讲到"离地铁 400 米"的时候，她会抬眼看向客户、身体稍微前倾。这些不是预制动画轮播——不是先把话说完了再想该配哪个表情。

真实的交流里，语言、语气、表情、动作本来就是同一次表达的一部分，星云的表达层做的就是让它们统一、连续、同步地生成：依据当前的语言内容、用户状态、智能体角色、情绪和场景，实时驱动语音、口型、情绪表情、眼神、头部动作、手势和身体动作。这也是它和"TTS + Lip Sync"最本质的区别——后者是两件事先后发生，前者是一件事。

还有个细节能说明"表达和感知不是前后两个阶段"：安家讲缺陷的时候，耳朵一直是开着的。客户一句"这个我知道"，她能立刻切到下一条，而不用等整段播完再重启对话。

带看日志

最有意思的最后一行：渠道中介嫌安家"话太直"，用户却嫌不够直——这个拉扯本身就是产品价值的证明。缺陷库的维护成本不低（规划公示要人盯），但"可验证"三个字是安家敢说话的全部底气：每条缺陷都挂着来源，用户可以自己查。

看房现场的"听觉环境"比办公室里难缠得多，这一段花了不少时间：案场有背景音乐和广播、5 号楼旁边是高架、客户一边走一边问、电梯间还有回声。要让安家在这种环境里听清，语音侧得连着做完这几件事——

先把真实的人声从环境里分出来（算法降噪、远场语音），再处理她自己的声音：她讲着话，喇叭里的输出会从麦克风绕回来，AEC 抗回声和本体声音抑制就是防止她把"自己的声音"当成客户在说话。然后是 VAD 判断哪一段是有效人声。

最要紧的是打断这一环。客户在她正讲"这套的产权还剩 54 年"的时候插一句"多少钱"，她得立刻停下来听——这就是 Double Talk / Barge-in 智能打断。但打断不能太敏感：客户在旁边清了下嗓子、应了声"嗯嗯"“然后呢”，这些是 Backchannel，是"我在听"的意思，不是要打断你。分不清这两者，她就会变成那种一有人吭声就闭嘴的结巴助手。

这一整套——降噪、AEC、本体声音抑制、VAD、ASR、远场、打断——合起来才是多模态感知：系统要知道的不是"这句话说了什么"，而是现场此刻正在发生什么。

过户后：房产信息透明的"最后一米"

做完安家我有个很直接的体会：房产行业喊"信息透明"喊了二十年，透明到房源价格上网就停住了——价格透明容易，毛病透明难，因为讲毛病要得罪人。AI 顾问没有业绩焦虑，这是她敢把"先挑毛病"写进人设第一行的全部原因。

端到端具身交互智能在这个场景的意义，是把"停留、纠结、插话、复访"这些购房决策里最真实的犹豫时刻，都变成了可回应的信号。

而且她的身体可以换。现在她在 VR 看房页和案场大屏上；再往前走一步，如果把她放进一台服务机器人——身份、缺陷库、规则、客户记忆全部复用，只是多了一副能动的身体：带看时走在客户前面带路，到了楼下停下来指一指"那就是北侧那块地"，上楼时自己去找电梯口。这些属于数字与物理行动里的"物理行动"——转向、靠近、移动、导航带路、跟随、上肢动作，以及更复杂的 Robot Skill。

这也是星云这套体系里我很喜欢的一个说法：同一个智能体，可以拥有不同的身体。身体可以换，但她的身份、知识、记忆、任务和业务能力是持续存在的——智能体持续存在，身体不断升级。

回到购房这件事本身：她不替代中介跑腿，也不替代你亲自去现场站一会儿。她替代的是你身边那个"懂行又不图你钱"的朋友——只是这个朋友以前你借不到。

魔珐星云是一套端到端具身交互智能平台，让 AI 通过屏幕和机器人进入真实世界，成为能够感知、理解、表达并行动的智能体。这就是安家为什么能一边和你说话、一边替你把毛病挑出来。

你买房时最想有人替你问出口的一个问题是什么？噪音、学区、还是隔壁的空地要盖什么？