判断一套“智能家居”成色如何，有一个很朴素的测试方法：把家里的路由器拔掉，看看还剩下什么能用。很多依赖云端大模型做全部决策的产品，断网之后语音助手直接变成哑巴，连开关灯这种最基础的操作都要转成手动按墙壁开关。这暴露的不是网络问题，而是架构问题——把所有智能都堆在云端，家庭AI的可靠性上限就被互联网稳定性卡死了。百家乐的端侧Agent想解决的正是这个问题：断网不应该让一套家庭AI退化成毫无智能的电子开关集合。更现实的情况是，家庭网络出问题的频率远比想象中高——运营商光猫故障、路由器固件升级重启、物业小区宽带临时中断，这些都是几乎每个家庭一年里都会遇到好几次的事，如果每次都意味着安防检查、门锁状态这类关系到安全的功能一并瘫痪，那这套系统在真正需要的时候反而是不可靠的。

先分清楚，哪些任务本来就不需要联网

设备控制类的指令，比如“客厅灯调到60%亮度”“空调设成26℃”，本质上是确定性很强的结构化任务——识别指令、匹配设备能力、下发参数，这套流程不需要理解世界知识，也不需要多步推理，完全可以由一个体积很小、专门针对家庭场景微调过的本地模型完成，这类模型参数规模通常只有云端旗舰模型的几十分之一甚至更小，但因为任务边界收窄到“家庭设备控制”这一个领域，反而能在小体积下保持很高的准确率。类似地，门锁状态判断（门有没有锁好、有没有被长时间开着）、基于传感器的场景触发（人离开客厅超过一定时间自动关闭无人房间的灯）、以及本地存储的固定场景执行（睡眠模式、离家模式），这些逻辑运行时依赖的都是本地传感器数据和本地存储的规则库，跟云端完全无关，理应在断网时保持完全正常。

案例：断网时你说“我出门了，帮我检查一下”

假设某天小区网络中断，用户临出门前对着音箱说了一句“我出门了，帮我检查一下”。端侧Agent会依次调用本地可获取的传感器状态：入户门锁是否处于锁定状态、各窗户传感器是否显示闭合、燃气阀传感器读数是否正常、主要电器（比如烤箱、电磁炉）是否处于待机而非工作状态。整个检查过程不需要访问任何云端服务，语义理解（把“检查一下”解析成这组具体检查项）和结果播报也都由本地模型完成。用户会听到类似“门已锁好，客厅窗户还开着，其他正常”这样的具体反馈，而不是网络异常导致的沉默或者报错音效。这类场景恰恰是家庭AI最需要在离线状态下保持可靠的部分，因为它关系到安全，而不是锦上添花的便利功能。如果这次检查发现客厅窗户没关，端侧Agent不会因为网络问题就放弃处理，而是先在本地记录这条异常状态，等网络恢复后再补发一条推送提醒，本地能做的响应不会因为等待云端同步而被卡住。

端侧模型能做规划，但做不了“旁征博引”

值得说清楚的是，本地运行的模型并不是简化版的“傻瓜规则引擎”，它依然具备基本的意图理解和任务规划能力，能处理“先关灯再锁门”这种带顺序依赖的多步指令，也能在指令有歧义时基于本地已知的设备清单做出合理判断。它欠缺的是两类能力：一是需要外部实时信息的判断，比如查天气预报决定要不要提前关窗；二是需要大量世界知识做背景支撑的复杂推理，比如解释某个陌生的设备故障代码具体代表什么。端侧模型的知识边界被压缩在“这个家里已知的设备和规则”范围内，这个范围内它足够聪明，一旦超出这个范围，它需要老实承认做不到，而不是强行给出一个可能错误的答案——这一点在断网场景下尤其重要，因为一个不懂装懂的本地模型给出的错误判断，用户当时根本没办法联网核实，后果比“答不上来”更麻烦。

云端负责什么：新知识和真正复杂的推理

云端大模型承担的是端侧无法覆盖的两类工作。第一类是时效性知识，比如实时天气、最新的设备兼容性数据库、社区里其他用户反馈过的常见故障模式，这些内容会持续更新，本地存一份静态快照很快就会过时。第二类是超出预设规则的复杂推理，比如用户描述一个此前从未出现过的异常现象（“空调声音变了，是不是要坏了”），需要模型调动更大的参数规模和更广的知识面去做诊断性推理，这类判断本地小模型的能力上限达不到。此外，模型本身的迭代升级——训练出更准确的新版本——这件事只能在云端完成，端侧设备只是被动接收更新后的模型文件，不具备自我训练的算力条件，这也是模型更新机制需要单独讨论灰度和回滚的原因之一。

一份对照：断网时仍可用 vs 断网时不可用

把功能拆开列出来会更直观：

  • 断网仍可用：已注册设备的开关、调节类控制；门锁、窗户、燃气阀等安全传感器状态查询；基于本地规则的场景执行（离家、睡眠、会客等预设模式）；不依赖外部数据的多步骤指令理解与执行；本地存储的历史操作记录查询。
  • 断网时不可用或降级：依赖实时天气、路况等外部数据的判断；涉及陌生故障诊断的复杂推理问答；跨家庭的社区经验参考；新设备接入时的云端能力库同步；模型版本更新与安全补丁下发；跨设备协同中依赖云端中转的部分，比如车机位置信息的远程同步。

为什么不能干脆把大模型整个搬到家里

有人会问，既然本地运行更可靠，为什么不干脆把一个能力更强的大模型直接部署在家庭网关里。现实的限制主要在三方面：一是算力和功耗，家用网关级别的芯片和数据中心级GPU之间存在数量级的差距，塞进一个参数规模足够大的模型意味着响应延迟明显增加、设备发热和电费成本都不现实；二是存储和更新成本，越大的模型文件意味着每次更新下载和校验的时间越长，对家庭网络也是负担；三是知识时效性，即便本地塞下一个很大的模型，它的知识依然定格在某次训练的时间点上，无法替代云端持续接入的实时数据源。端侧模型的定位从一开始就不是“弱化版的云端模型”，而是“专门针对家庭确定性任务优化过的小模型”，两者解决的是不同性质的问题。也正因为如此，评价一套端侧Agent好不好，不该看它能不能回答天文地理，而应该看它在自己该管的那部分任务上，响应是不是够快、够稳、够准——延迟通常要求在几百毫秒以内，因为设备控制类指令一旦感知到卡顿，用户体验的落差会非常明显，这也是端侧模型必须做得又小又准的现实原因。

离线能力是家庭AI的底线，不是加分项

把安全相关的判断和基础设备控制放在本地执行，本质上是在给家庭AI设一条最低限度的可信底线——不管小区网络出不出问题、云端服务会不会临时维护，门锁状态判断和基础控制永远应该在线。真正值得追求的“智能”不是云端模型参数量有多大，而是即便断了网，这套系统依然清楚自己能做什么、不能做什么，并且诚实地告诉用户当前处于哪种状态。