家庭AI编辑组把"关闭卧室窗帘"这样一句话送到几百公里外的云端服务器上跑一遍大模型，再把结果传回来执行，这件事本身就很荒谬——不是做不到，而是完全没必要。真正决定一个家庭AI系统好不好用的，往往不是模型参数量有多大，而是"这句话到底需不需要出门"这个架构层面的选择。百家乐把家庭AI拆成三层来处理这个问题：设备端、家庭边缘端和云端，各自负责不一样的事情。
为什么开灯这件事不该经过一次云端往返
一次典型的云端请求，从设备发出到服务器处理再返回结果，正常网络环境下也要一两百毫秒，遇到网络拥堵或者服务器负载高峰，延迟拉到一两秒都不稀奇。对于查天气、写一段文案这类任务，这点延迟无所谓；但对于开灯、关窗帘、判断门有没有关这类实时性很强的家庭任务，用户按下开关到灯真正亮起之间哪怕多等一秒，体验上的落差都很明显。更麻烦的是，这类任务本质上不需要多复杂的推理能力，用一个跑在本地的小模型就能可靠完成，绕远路去云端处理，纯粹是在为不必要的延迟和不必要的网络依赖买单。把简单任务留在本地，复杂任务才交给云端，这个分界原本应该是常识，只是过去几年"什么都上云"的惯性思路，让很多团队默认所有智能都得依赖远端服务器，很少真正回头核算这笔延迟和成本的账。
三级架构：谁该做什么事，一个深夜异响的例子
百家乐把家庭AI的计算任务分成三层。第一层是设备端AI，跑在传感器、摄像头、门锁这些终端设备自己的芯片上，负责最基础、最局部的识别任务；第二层是家庭边缘AI，跑在家庭本地的智能中控或家庭服务器上，负责实时任务的决策和涉及隐私的数据处理；第三层是云端AI，负责需要更强算力支撑的复杂推理、知识更新和大模型能力。这三层不是谁比谁更高级的关系，而是分工——设备端追求的是低功耗和即时响应，家庭边缘追求的是本地闭环和隐私安全，云端追求的是能力上限。把该留在本地的任务硬塞给云端，或者指望一个终端小芯片去干云端大模型的活，都是架构层面的错配。
用一个具体场景把三层拆开看会更清楚。假设凌晨一点，客厅传来一声较大的物品碰撞声。第一层，客厅摄像头和声音传感器自带的芯片先在本地完成初步判断：声音强度超出正常范围，同一时刻画面里没有检测到人形移动，这两个判断在几十毫秒内就在设备本地完成，不需要联网。第二层，家庭边缘AI接收到这两个信号后，结合当前时间、家庭成员的在家状态、以及最近是否有宠物活动的历史记录，判断这更可能是宠物碰倒了台面上的物品，而不是人员意外或者外部入侵，于是选择不惊动任何人，只是把这次事件记录进家庭状态历史；这个综合判断依赖的信息量已经超出单个设备的能力范围，但依然可以在本地几百毫秒内完成，不需要等云端。第三层云端AI在这个场景里完全没有被调用——因为本地边缘层已经有足够的信息和能力把这件事处理妥当。只有当边缘层遇到自己判断不了的复杂情况，比如需要结合更大范围的知识做安全评估时，才会真正用到云端这一层。
设备端AI：芯片上跑的是"看一眼就够了"的判断
门锁、摄像头、传感器这些终端设备通常配备的是低功耗NPU，算力有限，但足够完成一些非常局部的识别任务：判断画面里是不是有人形轮廓、判断这段声音是不是玻璃破碎、判断唤醒词有没有被说出来。这些任务的共同特点是输入简单、输出单一、不需要理解上下文，用一个几兆到几十兆大小的小模型就能在芯片本地跑完，既不用联网也几乎不耗电。设备端AI的角色更像是"过滤器"——把大量原始数据在源头就压缩成少量有意义的信号，只有真正值得关注的信号才会被送到上一层，而不是把摄像头拍到的每一帧画面都原样传出去，那样上一层根本处理不过来，也没必要处理。
家庭边缘AI：真正管家里事的那一层
家庭边缘AI跑在部署在家里的中控设备或者小型家庭服务器上，通常搭载参数规模适中、经过家庭场景专门优化的本地大模型。它承担两类核心工作：一类是需要实时响应的家庭任务，比如根据当前情境判断要不要关灯、要不要调整空调，这些判断依赖的信息量比设备端复杂得多，需要综合多个房间、多个设备的状态，但又必须在几百毫秒内给出结果，放在云端来回传输反而拖慢速度；另一类是涉及隐私的数据处理，比如摄像头画面里的人物识别、家庭成员的作息记录，这些数据本身就不适合默认上传，留在本地边缘处理，既满足了实时性要求，也避免了敏感数据在网络上大量传输的风险。我们在家庭世界模型里讨论的那套持续更新的情境记录，绝大部分的维护和查询工作都是在这一层完成的。
云端AI什么时候真的需要它，断网之后又能剩下多少功能
不是所有任务本地都能扛得住，复杂的多步推理、需要调用海量知识的问答、模型能力本身的迭代升级，这些还是要靠云端。比如用户提出一个从未出现过的复合型需求，涉及跨多个领域的权衡判断，本地的小模型可能给不出足够可靠的方案，这时候把匿名化处理后的必要信息发送到云端，借助能力更强的大模型完成一次深度推理，再把结论下发执行，是更合理的分工。云端还承担着模型知识更新的角色——设备和家庭习惯在变化，本地模型需要定期从云端获取增量更新，才能持续跟上，而不是装机那一刻的能力就是终身能力上限。关键在于，云端处理的应该是"需要更强能力"的任务，而不是所有任务默认的第一站。从模型规模上看，三层之间的差距也很直观：设备端跑的模型通常只有几兆到几十兆大小，专门针对单一识别任务裁剪过；家庭边缘端跑的本地大模型参数规模适中，经过家庭场景的数据做过专门优化，换来的是能在有限算力下覆盖大多数日常判断；云端大模型的参数规模和训练数据量则是另一个量级，换来的是更强的通用推理能力和更广的知识覆盖面。这三种规模的模型不是互相替代的关系，用小模型去解决只有大模型才能覆盖的复杂问题会力不从心，用大模型去处理简单的开关判断则是资源浪费，各自待在自己该待的位置，整体系统才跑得顺。
三级架构的一个直接好处，是断网不等于家庭AI瘫痪。家庭边缘AI本地保存着最近一段时间的家庭情境数据和常用任务的处理逻辑，即便完全断网，开关灯、调节空调、门锁验证、基础的语音控制这些高频任务依然可以正常运行，因为它们本来就不依赖云端。会受影响的是那些确实需要云端能力的场景，比如复杂的跨领域咨询、模型知识更新暂停、部分依赖外部服务的功能不可用。这种"核心功能不掉线，增强功能可以降级"的设计，比一旦断网整个系统全部失灵要务实得多，也更符合真实家庭对稳定性的要求——没有人愿意因为小区宽带临时故障，连灯都开不了。具体拆开看，断网状态下依然能正常工作的通常包括：基础的灯光空调窗帘控制、门锁验证与安防报警、语音控制高频指令、以及最近一段时间内的家庭状态查询；会暂时受限的则是模型知识更新、需要联网检索的复合型问答、以及依赖第三方云服务的扩展功能。把这两类边界提前想清楚并且对用户透明，比笼统地宣称"离线也能用"更负责任，用户也能对断网期间该期待什么、不该期待什么有一个准确的判断。
从速度、隐私、成本、安全算账，这层AI又该放在家里哪
把这套架构拆开算一笔账会更清楚为什么值得这么设计：
- 速度：本地处理的高频任务响应在几十毫秒量级，云端往返通常是本地的数倍到数十倍
- 隐私：涉及人物识别、作息记录的敏感数据留在本地，减少了长期在网络上传输和云端集中存储的风险
- 成本：大量高频但简单的判断在本地完成，不需要每次都消耗云端算力和带宽，长期运行成本更低
- 安全：本地闭环减少了对外部网络连接的依赖，即便云端服务出现问题，家庭核心功能也不会被连带拖垮
这四个维度没有哪一个是绝对优先的，实际权衡永远是具体任务具体分析——但默认把所有任务都推给云端，几乎在每一个维度上都不是最优解。反过来，把所有任务都硬塞进本地设备也不现实：本地算力和存储终究有限，一味追求"全部本地化"，要么牺牲响应速度去跑超出硬件能力的模型，要么干脆放弃一部分本来能提供的复杂能力，这同样是一种资源错配，只是方向相反。真正合理的架构设计，是让每一类任务都落在最适合它的那一层，而不是在"全部上云"和"全部本地"这两个极端之间选一个立场。
家庭边缘AI不是一个抽象的软件层，它总要跑在某个具体的硬件上——是塞进路由器旁边的一个小盒子，是集成进智能中控屏幕背后，还是干脆放进某个大家电的主板里，这是一个实实在在的产品选择问题，直接影响散热、扩展性和后续升级的难易程度。我们在家庭AI中枢应该装在哪里的讨论中详细比较过手机App、独立家庭服务器和智能中控这几种落地形态的取舍，这里只强调一点：不管最终选择哪种形态，它承担的都是本文所说的"家庭边缘"这一层职责，既要够得着家里每一个设备的实时状态，又不能把不该外传的隐私数据顺手就传上了云端。
架构选对了，上层的Agent才有地基可用
三级架构不是一个孤立的技术选择，它直接决定了家庭AI Agent的任务规划能不能又快又稳地执行下去，也决定了多个专业Agent协同工作时，彼此之间的状态同步是走本地局域网还是绕一圈云端。如果连开灯这种基础操作都要看云端服务器的脸色，再精巧的任务规划逻辑也会被网络延迟和服务波动拖累。判断一个家庭AI产品的架构是不是靠谱，不用看它宣传了多大的模型，而是看它有没有认真回答过一个朴素的问题：这个功能到底有没有必要联网才能用。愿意把这个问题拆开、认真给每一类任务分配合适的处理层级的团队，往往也是真正把"家庭AI能不能稳定运行"当回事的团队，而不是把所有计算都丢给云端、指望网络永远畅通无阻的省事做法。
