产品体验编辑组很多打着“全屋智能、多端联动”旗号的产品，拆开看会发现手机App、车机小程序、音箱技能其实是三套独立开发的界面，各自连着自己的一份设备状态缓存，谁先收到指令谁先执行，彼此并不知道对方刚做了什么。这种架构下所谓“跨设备”只是同一套控制面板被复制粘贴了三次，不是同一个大脑在不同身体上做事——一旦其中一端离线或者数据没同步及时，用户在手机上看到的“空调已开启”和音箱回答的“空调还没开”经常对不上，这类体验上的割裂,恰恰暴露了背后根本不是一套系统在运转。百家乐想解决的不是“每个终端都能控制家”，而是“每个终端说的都是同一件事，因为背后是同一个持续运行的家庭Agent”。
案例：车里一句话，家里开始动作
一个具体场景：晚上下班开车回家，快到小区时对车机说“我20分钟后到家”。这句话不是设备指令，车机本身也控制不了家里的任何东西，但它会把“预计20分钟后到达”这个结构化信息连同当前位置一起交给家庭Agent。家庭Agent接下来做的不是立刻执行什么，而是先生成一份带时间轴的预判计划：现在启动卧室空调制冷或制热到接近目标温度但不满载运行（避免到家前就已经稳定在设定温度导致的能耗浪费）；查询热水器当前水温和加热状态，如果距离设定的洗浴水温还有较大差距就提前启动；新风系统在到家前8分钟左右启动，让室内空气在到家时已经完成一轮置换；玄关及入户动线的灯光则设置为到家前2分钟自动进入待机感应状态，人一靠近门口就能立刻亮起，而不是全程常亮浪费电。这一整套动作，用户在车里只说了一句话，而且这几项动作的启动时机并不是同时的——空调和热水器涉及能耗和加热周期，需要更长的提前量；新风和灯光调整几乎是即时生效，可以安排在临到家前才启动，这种“谁该提前多久做”的判断也是预判计划里需要单独建模的部分，不是一句话触发的所有设备都用同一个倒计时。
位置信息怎么变成家里的执行计划
这条链路里最关键的技术环节是把“正在移动中的一个人”转成“家里可以据此规划的时间窗口”。车机上报的不只是一次性的“20分钟”，而是持续更新的位置和路况估算，家庭Agent订阅的是这个持续的ETA流，而不是一个静态数字。如果路上遇到拥堵导致ETA从20分钟变成35分钟，家庭Agent会重新调整执行计划——已经启动的空调转入更节能的维持模式而不是持续满载，新风系统的启动时间点也相应顺延，避免“提前置换好的新鲜空气”在人到家前又变得沉闷。这种基于持续事件流而不是一次性触发的设计，是应对真实通勤场景里各种不确定性的必要基础，也是多个家庭Agent协同工作时经常需要处理的动态重规划问题。
不同设备能做的事，从一开始就不一样
车机在这个场景里只承担了“捕获意图和位置”的角色，它没有能力也不需要能力去控制家里的空调——这是有意为之的分工，而不是技术限制导致的妥协。百家乐把参与协同的终端按角色划分：车机和手机偏重输入捕获与移动场景下的轻量反馈；智能音箱偏重语音交互和到家后的即时响应；家庭中控屏和电视承担需要视觉呈现的复杂信息，比如展示热水器加热进度、新风系统的空气质量曲线；真正的设备执行则统一由家庭本地的Agent服务完成，不依赖某个具体终端在线与否。换句话说，用户在哪个设备上说话只决定了“意图从哪里进来”，不决定“动作在哪里发生”，这样即便车机应用当天出现故障，只要意图能通过其他渠道（比如手机App）传达，家庭端的执行链路完全不受影响。这种角色划分还带来一个额外的好处：新增一种终端类型时，不需要重新实现一整套设备控制逻辑，只需要让新终端接入统一的意图上报接口，执行层完全复用已有的能力——这也是百家乐后续接入更多车型、更多品牌音箱时能保持体验一致的原因。
上下文怎么“跟着人走”
如果到家之后用户又对着音箱补了一句“客厅再暖一点”，系统需要知道这句话是在延续车里那次请求的上下文，还是一次全新的独立指令。百家乐的做法是把“回家”这类多步骤场景当成一个具有生命周期的任务会话，从车机发起到执行完成前，这个会话的状态在家庭Agent这一层是统一维护的，任何终端接入时读取的都是同一份会话状态，而不是各自维护一份本地记录。这意味着用户不需要跟音箱重新解释一遍“我刚才说要到家了”，音箱能直接接续判断这句话是对当前进行中的回家流程做微调。这种会话延续能力依赖的正是自然语言处理链路里对上下文的持续追踪，只是这里的“上下文”跨越了设备边界。
一致性问题：两个设备同时给出不同指令怎么办
跨设备协同真正的难点不在于单个场景顺利执行，而在于并发和冲突。设想一种情况：家里另一位成员在客厅用中控屏把空调临时调高了2℃，与此同时车机那边的自动化流程仍在按原计划推进降温动作，两个指令方向相反。百家乐的处理原则是任何设备状态变更都携带时间戳和来源标记，家庭Agent以“最近一次人为主动操作”为最高优先级，自动化流程一旦检测到同一设备在计划执行窗口内出现了人为干预，会立刻放弃后续按原计划推进的动作，转为尊重当前的人为设定，而不是几秒钟后又把温度改回去打一场“拉锯战”。这类冲突解决逻辑必须在系统设计阶段就明确谁的状态是权威的，如果没有统一的裁决规则，多端协同带来的往往不是便利，而是设备互相“打架”的糟糕体验。更复杂的情况是两个人几乎同时通过不同终端下达矛盾指令，比如一人在客厅中控屏调低亮度，另一人几乎同时对着App说“亮一点”，这种情况下系统不会试图“猜”谁更对，而是把两条指令都执行为一次性的即时调整，不触发任何自动化联动的覆盖判断，避免让某一方的操作被系统以“更权威”的名义悄悄撤销，这类涉及人与人之间协商的场景，本来就不该由AI替人做决定。
网络不稳定时，协同要退到哪一层
车机联网状况本身就不稳定，隧道、地下车库都可能导致位置更新中断。百家乐的容错策略是把“车里一句话触发的家庭预判”当成锦上添花的优化项，而不是必须完成的关键任务——一旦位置流中断超过设定时长，家庭端会按最后一次可信的ETA估算继续执行已经启动的计划，但不再做进一步的动态微调，等到用户实际接近家门被本地的门禁或Wi-Fi探测重新确认位置后，再恢复正常响应。这和离线场景下端侧Agent的降级逻辑是同一套思路：协同越复杂，越需要想清楚退化路径，而不是假设网络和设备永远在线。
共享的不是数据，是同一套决策上下文
把这几层拆开看会发现，“多端联动”真正值钱的部分不是让手机、车机、音箱都能显示同一组设备状态——那只是数据同步，做起来并不难。难的是让这几个终端在同一套决策上下文里协作：谁的输入优先、谁的能力负责执行、谁的状态是当前权威版本、网络中断时该退到什么程度。这套上下文本质上属于同一个家庭Agent，而手机、汽车、音箱、家庭中控都只是它伸出去的不同触角。
