Xthings 基于 Amazon Bedrock AgentCore 与 Amazon Nova Lite 构建智能家居自然语言控制的实践
内容提要
Xthings 为智能家居平台引入自然语言控制，基于 Amazon Bedrock AgentCore 与 Nova Lite，采用上下文预加载加异步下发的四段式架构，将模型调用从两轮减至一轮，受理延迟 P95 控制在 1 秒内，MVP 两三周投产。文章还分享了 UUID 白名单校验、别名权威来源、长期记忆写入治理等经验，并指出敏感动作执行层校验仍待补齐。
延伸解读
从设备分布出发的功能定位
文章披露，Xthings 在立项前统计了约 1 万个家庭的设备数分布，中位数为 2 台，P90 为 5 台。这一数据直接影响了功能定位：大量只有一两个设备的家庭并不需要自然语言控制，真正需要“一句话控制”的是设备数在 5 台以上的家庭。因此首轮灰度按家庭设备数不少于 5 台圈选，而非全平台推广。这提示我们，功能设计应基于用户实际使用场景的分布，而非平均值。
预加载优化与成本权衡
文章指出，通过上下文预加载，模型调用从两轮减至一轮，省去约 300 毫秒的工具查询往返，受理延迟 P95 目标控制在 1 秒内。但预加载让每次请求都携带完整设备清单，input token 增加，与调用轮次减半带来的成本下降方向相反。因此净成本效果需按 token 级账目计算，不能简单按调用次数推断。这提醒我们，优化延迟时需同步评估 token 成本变化。
长期记忆的写入治理经验
文章分享了 Memory 写入治理的教训：上线初期每次开关灯都写一条偏好，两周后发现无区分度的样本淹没了真实习惯。随后确立三条原则：只存显式偏好（非默认参数才写入）、去重覆盖（同类偏好只保留最新）、自动老化（三个月未触发则淘汰）。作者总结“存得多不如写得挑”，强调写入入口的判断力。这对设计长期记忆系统具有参考价值。
敏感动作的执行层缺口
文章明确，当前对门锁等敏感动作的防护仅在提示词层面约束，执行层尚未实现独立的敏感动作校验。现有的 UUID 白名单和 commands[] 范围校验只能确保设备存在和动作合法，无法判断动作是否敏感。作者将“执行层敏感动作校验”列为已知缺口，并计划在后续版本补充拦截与授权机制。这提示我们，安全底线需要代码级硬约束，而非仅依赖模型自律。
Q&A
Xthings 为什么选择 Amazon Nova Lite 而不是更大的模型？
因为 IoT 控制指令生成本质上是基于用户语句、设备清单和历史偏好做语义匹配并输出结构化结果，属于浅层推理，不需要多步规划或长链条工具编排。轻量模型单次调用成本低，延迟更容易落在 1 秒的受理预算内。
Xthings 的四段式架构具体指什么？
四段式架构指：接入层路由、转发到会话管理、上下文预加载、托管推理、校验后并行下发、返回受理响应。核心是上下文预加载和异步下发，把模型调用从两轮减到一轮。
上下文预加载是如何优化延迟的？
在调用模型之前，Lambda 先从 ElastiCache 读取该用户的设备列表、可用指令集与状态集，连同会话上下文一起交给 Runtime。这样 Agent 不必在推理过程中再发起一轮工具查询去拿设备清单，模型调用从两轮减到一轮，省下约 300 毫秒。
Xthings 在长期记忆写入上踩过什么坑？
上线初期每次用户开关灯都写一条偏好，两周后发现 Memory 被无区分度的样本淹没，老用户真实习惯反而被埋没。后来改为只存显式偏好、去重覆盖、自动老化，并推翻重写了写入逻辑。
Xthings 如何防止模型编造设备 UUID？
在 Lambda 层做硬校验：校验模型输出的 uuid 是否在预加载的白名单内，不在的直接过滤；校验 action 是否落在该设备 commands[] 定义的范围内；JSON 解析失败时返回固定兜底提示并后台记 warning，模型原始输出只进排障日志。
Xthings 当前在敏感动作执行层校验上有什么缺口？
当前只在提示词中规定门锁类设备需谨慎操作、睡觉场景不应自动开锁，并强制模型把放弃的设备写入 skipped[]。执行层尚未实现独立的敏感动作校验，UUID 白名单和 commands[] 范围校验管的是设备存在性和动作合法性，不管动作是否敏感。计划后续补充执行层校验及拦截授权机制。
