智能锁行业这几年的内卷，大家有目共睹：从指纹识别到人脸识别，从猫眼摄像头到远程视频通话，硬件堆料已经到了瓶颈。德施曼2026新品发布会提出“AI agent时代”和“情感化服务新范式”，确实让行业眼前一亮——因为智能锁终于不再只是“一把锁”，而是一个能感知、能理解、能主动服务的家庭智能体。这篇内容我准备从技术拆解和落地实操两个角度聊聊，AI agent到底是什么、它跟大模型有什么区别、为什么智能锁这种终端设备恰恰是AI agent最好的载体，以及如果你想自己动手做类似的端侧agent，有哪些坑需要提前避开。
不管你是产品经理、嵌入式开发，还是单纯对智能家居感兴趣的人，这篇内容都适用。我会尽量把概念讲得“接地气”，也会给出一套从0到1搭建智能锁agent的参考思路，方便你照着复现或改进。
1. AI agent凭什么能改变智能锁
1.1 传统智能锁的“伪智能”困境
先说一个很反直觉的事实：市面上绝大多数智能锁，本质上就是“带传感器和联网模块的机械锁”。所谓的AI功能，基本局限在指纹识别算法、人脸识别算法、逗留侦测算法这几个固定模块。它们都是预设好的单点能力，没有上下文、没有记忆、不能推理。比如你早上出门，锁会播报“门已反锁”，但不会根据你今天的日程提醒你“今天有会议，别忘了带工牌”——因为这需要把门锁数据跟日历、天气、出行习惯打通，需要agent，而不是单个算法模型。
传统智能锁的另一个问题是“被动响应”。用户按指纹、人脸识别、App远程开锁，锁才工作；用户不问，锁永远沉默。这种模式解决的是“开锁”这个动作，而不是“居家安全与生活服务”这个完整场景。而AI agent恰恰相反，它可以主动感知环境变化，结合历史数据和用户画像，在用户没开口之前就做出判断和动作。
1.2 agent、LLM和AI模型到底有什么区别
很多热搜词都在纠结“agent、LLM、AI模型有什么区别”，这里我直接说结论：
- AI模型（model）是一个“函数”，输入一个东西输出一个东西。比如输入人脸图片，输出“是不是主人”的得分；输入一段语音，输出文字。它没有记忆，也不主动行动。
- LLM（大语言模型）是基于海量文本训练的AI模型，它的核心能力是“理解和生成自然语言”，比如deepseek、GPT这类。LLM本身也只接受输入、输出文本，不会自己去调用门锁的开锁接口。
- AI agent则是在“模型”外面套了一层“决策和执行机制”。它由一个“大脑”（通常是LLM）加上工具调用能力、记忆系统、规划能力、反馈闭环构成。举例说明：你说“帮我查下外卖到哪了”，传统LLM只会回答“我无法访问你的外卖App”；但agent会自己“想”——先调用外卖App的查询接口，拿到数据后再组织语言告诉你结果。
所以agent = 大模型 + 规划 + 工具调用 + 记忆。deepseek在这里扮演的是“大脑”的角色，它负责理解用户意图、拆解任务、生成操作序列，但真正去操作系统、读取门锁传感器、控制电机开锁，需要agent框架和硬件接口配合。德施曼这次的升级，本质就是把原来“固定算法直接响应”的架构，改成了“大模型决策+工具执行+记忆沉淀”的agent架构。
1.3 智能锁为什么是agent的最佳载体之一
智能锁有三个天然优势，这些优势决定了它是AI agent落地的绝佳场景：
- 数据密度高：门锁每天记录大量事件——谁在什么时间进门、出门，访客何时到访，门是否异常虚掩，门口是否有陌生人在徘徊。这些数据是agent学习用户习惯、提供主动服务的原料。
- 交互触点多：智能锁不再只有指纹头，还有摄像头、麦克风、扬声器、红外传感器、门磁、屏幕（部分产品）。这意味着agent可以“看听说”全感知。
- 场景价值明确：家是最高频、最私密、最强调安全感的场景。用户愿意为“懂我”和“安全”付费，这比通用助理（如手机语音助手）有更清晰的商业闭环。
我甚至觉得，这次德施曼发布会最值得关注的不是参数，而是“架构切换”。把智能锁从“规则引擎+模型调用”切换到“agent决策”，这会带来整个产品逻辑的重构。
2. 德施曼AI agent的技术架构拆解
2.1 整体分层：感知、记忆、决策、执行、反馈
根据发布会公开的信息和行业内常见的agent架构设计，我帮你梳理出一套典型的智能锁AI agent系统框架，大致可以分为五层：
| 层级 | 职责 | 典型实现 |
|---|---|---|
| 感知层 | 采集环境与用户数据 | 指纹模块、3D结构光摄像头、微波雷达、门磁、麦克风阵列、光敏/温湿度传感器 |
| 记忆层 | 存储短期与长期上下文 | 本地SQLite/嵌入式数据库 + 云端的用户画像数据库 |
| 决策层 | 理解意图、规划动作 | 端侧轻量模型 + 云端大语言模型（LLM）协同决策 |
| 执行层 | 调用智能锁功能与其他IoT设备 | 开锁/闭锁电机驱动、门铃响铃、语音播报、消息推送、监控录像截取 |
| 反馈层 | 验证动作结果并迭代记忆 | 用户确认、传感器回读、异常事件纠正 |
你细品一下，这个五层结构跟一般AI Agent框架（比如AutoGPT、LangChain里的Agent组件）是一一对应的。区别在于，智能锁的感知层和执行层跟硬件深度耦合，不能像纯软件agent那样“只发API请求”。
2.2 感知层：多模态融合是重点
智能锁的感知层比手机还丰富：指纹是生物特征识别，摄像头做人脸和行人检测，雷达可以捕捉微小动作（比如有人在门前停留但不伸手），麦克风能听见5米外的说话声和楼道脚步声。AI agent要做的是把这些异构数据融合成结构化事件，而不是单独处理每一路信号。
举个例子，以往“门前有陌生人逗留”是依靠摄像头的AI人形侦测触发的，经常会被路过的人、宠物、光线变化误触发。在agent架构里，系统会同时读取三路信息：
- 摄像头画面中的轮廓和停留时间；
- 雷达测距得到的10秒内目标位移轨迹；
- 麦克风采集到的环境声音（是否在撬锁、是否在打电话）。
决策层接到的不是三组孤立信号，而是一条高层语义描述——“14:32到14:47，一名身高约170cm的成年人，在门前2米处徘徊，期间靠近门锁3次，未做按压动作”。接下来agent会结合记忆层判断这条事件的重要性：如果是快递员正在找门牌，就标记为普通事件；如果是在户主一般不在家的时段，就升级为风险事件。
2.3 记忆层：从“事件存储”到“用户习惯建模”
传统智能锁也有“记录”功能，但只是日志，没有人格化。agent的记忆要有两层：
- 短期记忆：最近5分钟发生了什么。比如主人刚出门，门锁正处于“离家警戒模式”，这个状态下agent不会因为猫咪触碰门锁而触发误报警，因为它记得主人刚走，且室内有人形移动物体（猫咪）。
- 长期记忆：过去30天里家庭成员的生活规律。比如检测到老人每周二上午9点会出门买菜，11点回家。某个周二上午10点门磁显示“大门未关好”，agent就会基于长期记忆推断“老人可能没走远或忘记关门”，直接调用语音提示“奶奶，门好像没关严，我帮你语音提醒一下”，同时给子女推送一条低优先级提醒。
这种长期记忆不能只存在云端，本地也要存一份脱敏摘要。中央要求隐私保护，且断网时也要有基本智能。所以德施曼如果做得扎实，一定会在本地就完成事件类型分类、人物识别结果、情感状态标签（高兴、焦虑、平静）等结构化摘要，连云端的用户ID、门锁ID、时间戳，不传原始指纹和人脸裸数据。
2.4 决策层：云端大模型和端侧小模型如何分工
这里要细说。因为智能锁算力有限，你不可能把完整版的deepseek跑在锁里。合理的方案是“端侧小模型做实时判断，云端大模型做复杂决策”。
端侧小模型肩负的活儿包括：
- 活体检测（判断人脸是真脸还是照片/视频）；
- 指纹特征比对；
- 本地语音关键词识别（比如“你好小德”“芝麻开门”作为唤醒词）；
- 离家/归家场景识别（根据门磁+人体传感器的序列判断）。
这些任务需要极低延迟（通常要求0.5秒内完成），也需要在断网时可用，所以必须在端侧模型里跑。云端大模型则负责：
- 理解用户语义（比如“明天早上6点帮我提醒我妈出门带药”）；
- 复杂场景推理（比如“门铃响起，但门口画面无人”——此时结合雷达数据判断是否有蹲守者）；
- 生成个性化回复与动作序列（多轮对话、解释开除策略）；
- 规划跨设备联动（比如“离家模式”需要关窗帘、开摄像头、启动扫地机，涉及多个IoT平台）。
决策层还有一个关键机制叫“意图置信度”。如果端侧模型对“用户想开门”的置信度达到99%，就直接执行开锁，不经过云端，延迟最低；如果置信度只有60%（比如人脸识别光线不佳、指纹不清晰），就自动升级到云端，结合更多上下文来验证身份。这个分级决策逻辑其实是agent里常用的“一次规划、分级执行”思想，只不过在硬件产品里，你得用C/C++实现一个策略引擎，而不是纯Python调框架。
2.5 执行层：agent的双手和四肢
执行层不只是开锁。一个成熟的智能锁agent可以调用的工具包括：
- 开锁/反锁控制（电机驱动）；
- 门铃与摄像头联动（开启/关闭监控、抓拍、录制视频）；
- 语音播报（这里支持自然语言生成，能用不同语气说话）；
- 消息推送（给家人的App发通知，支持选择通知等级）；
- 智能家居联动（通过Matter/HomeKit，把事件转发给灯光、空调、窗帘）；
- 锁具状态诊断（比如电量低、门缝卡阻、指纹模块脏污）。
在agent框架里，执行层的每个动作都要注册成“工具函数”，并给大模型提供清晰的描述。例如工具定义可能是：
{ "name": "open_lock", "description": "通过验证后打开门锁。仅在用户身份验证通过时调用", "parameters": { "type": "object", "properties": { "reason": { "type": "string", "description": "打开门锁的原因" }, "by_voice": { "type": "boolean", "description": "是否同时进行语音提示" } } } }大模型不会直接执行代码，而是决策“该调用哪个工具、参数填什么”，真正的执行由硬件驱动层完成。这也是agent安全的唯一可行思路——大模型永远只能发起“工具调用请求”，实际权限要通过独立的权限模块来校验。
3. 情感化服务新范式：从被动响应到主动关怀
3.1 情感化不是“卖萌”，而是精准理解用户状态
业界一提“情感化”，容易滑向“可爱的语音包”“节日问候弹窗”这类表层设计。但德施曼发布会说的“情感化服务新范式”，既然要和AI agent绑定，那一定要落到“情绪感知”和“意图揣测”上。
情绪感知意味着agent要能识别当前家庭成员的情绪状态。这怎么做到？可以通过多模态信号来综合推断：
- 语音语调：老人回家后叹气、呼吸急促，可能身体不适；
- 进门动作的节奏：指纹解锁后长时间没有关门，可能是酒后、疲劳或分心；
- 时间上下文：凌晨2点开门，不是加班就是心情烦躁；
- 面部微表情（如果有可视门铃对着人脸）：愤怒、悲伤、惊慌。
agent不是“读心术”，它只是把这些信号综合成“情绪概率”，然后按不同情绪状态匹配服务策略。比如检测到主人回家时明显疲惫，语音播报就不会机械地说“已开锁”，而会说“今天辛苦了，室内温度已经提前调好了，加湿器也开了”。
3.2 典型场景之一：老人守护
老人独自在家，家属最担心的就是意外。传统设备能做的是“跌倒报警”，但那需要在室内装摄像头或佩戴手环，成本很高、侵入感强。智能锁agent给出了一个新解法：它不监控室内，只监控“门”这个出入口。
通过长期记忆，agent清楚老人的正常出门频率和时间窗口。如果某天早上10点，门磁检测到开门，但一直到10点半都没有再次关门/反锁，agent就触发一个“疑似外出未返回”事件。此时agent不会急着报警，而是先用摄像头确认老人是否还在门口，再尝试通过门锁对讲呼叫老人，如果10秒内无回应，才通知子女。
情绪化服务体现在哪里？在于agent会“温柔地问”，而不是“生硬地报”。它会用比平时更缓的语速说：“奶奶，门还没关好，外面风大，你还在家吗？如果出去了，记得带上钥匙。”这种语气是通过策略模板生成的，不是固定语音，更接近真人关怀。
3.3 典型场景之二：孩子放学回家
孩子放学时，agent做了三件事：
- 通过人脸识别确认是小主人，此时不开门禁告警；
- 检测到孩子身后没有成年人跟随，且在门外停留超过10秒，自动提醒“欢迎回家，今天作业多吗？要给妈妈打电话吗？”；
- 把“孩子已在17:05安全到家”这条消息推送给父母，但推送等级设为“低”，避免打扰。
这里有个细节：如果孩子是一个人回家，agent会自动将门锁状态从“布防”切换到“在家”，并通知室内摄像头进入“儿童在家模式”（不监控孩子卧室，只监控入口区域）。这个动作可以提前由家长在App里配置好，但agent会根据情景动态调整，而不是死板地定时切换。
3.4 典型场景之三：访客与陌生人管理
访客场景最考验agent的“人性化”。传统智能锁收到门铃只知道推送一条“有人按门铃”的通知，然后用户打开摄像头看是谁，再决定要不要远程开门。agent则会主动处理：
- 识别到访客，先和通讯录比对：如果匹配到常联系人（比如孩子的同学），自动播放“果果，我爸爸在家吗？”，并通知主人；如果主人5分钟未接听，agent会礼貌地请访客留下姓名和电话，并录制短视频；
- 遇到不认识的人，agent会用雷达和摄像头分析对方停留位置、是否有绕行行为，如果感觉风险高，会主动开启监控补光灯，以示威慑，同时降级推送“急”通知到所有家庭成员。
这些动作背后不是一套if-else规则，而是agent结合视觉模型、语音模型、知识图谱（家庭成员关系树）做出的“多步规划”。你把它想象成人脑——人在大门口听到门铃，会先听声音、看猫眼、回忆来访者身份、和自己的推测对比，再决定微笑开门还是谨慎应对。agent做的就是把这套流程数字化。
3.5 情感记忆：让服务有“连续性”
德施曼发布会特别提到“情感化服务新范式”，我的理解是，agent除了感知当下情绪，还应该具备“情感记忆”。比如：
- 上个星期主人和伴侣吵了架，agent通过门口语音捕获过激烈对话（只保留语义摘要，不存录音）；
- 从此之后，当agent检测到主人独自回家时，会减少主动搭话的频次，播报音量降低、语气变得温和；
- 当伴侣再次回家时，agent可能会给主人推送“需要我帮忙调节灯光吗”这类低打扰的辅助建议。
这就比“智能家居自动化”高了一级：不是用户设定条件，agent就能给出条件动作，而是agent通过记忆构建出一个“用户情感状态模型”，再选择是否服务以及如何服务。这里的隐私压力很大，所以必须是“本地摘要+云端不存原文”，而且所有情感标签都要让用户能在App里查看、修改、删除。
4. 从0到1搭建一个智能锁AI agent的参考流程
这一部分写给开发者。即使你不做智能锁硬件，也可以把这套思路迁移到门禁、猫眼、智能传感器上。我尽量按实际开发顺序来写。
4.1 确定端侧能力和云侧能力边界
第一步不是写代码，而是盘点硬件资源。以一款典型的旗舰级智能锁为例：
- MCU：控制电机、采集指纹头数据、读取门磁电压，通常用Cortex-M4/M7级别的芯片，跑不了大模型；
- AP（应用处理器）：运行Linux或RTOS，有1~4GB内存，可以跑轻量神经网络（如MobileNet、TinyML之类），也可以跑一个量化后的对话语音识别模型；
- 云端：GPU资源充足，可运行大语言模型（如deepseek、qwen、chatglm等）和复杂视觉模型。
你必须在AP上规划出实时任务和agent任务的资源占比。我的建议是：把指纹识别、人脸验证、活体检测、门磁逻辑放进MCU或AP的实时操作线程中，保证关键开锁流程小于400毫秒；把agent的对话理解、决策规划放到云端或本地的一个高算力模块中，响应时间允许1~3秒。
4.2 定义工具集和权限模型
这是整个agent安全的关键。我在前面提过，agent的大脑需要知道“它能干什么”。你可以维护一个工具清单：
| 工具名 | 所需权限 | 说明 |
|---|---|---|
| unlock_door | 需身份验证 | 执行开锁，必须二次校验 |
| lock_door | 无特殊权限 | 执行反锁/闭锁 |
| capture_image | 家庭管理员 | 拍摄门口照片或短视频 |
| send_message | 家庭管理员 | 推送消息到指定家庭成员 |
| call_voice | 无特殊权限 | 使用语音播报与用户对话 |
| query_sensor | 无特殊权限 | 读取门磁、雷达、温度等状态 |
| set_scene | 需授权 | 触发“离家/在家/睡眠”场景 |
权限模型要做到两点：第一，agent即使被“提示注入攻击”操控，也不能突破权限边界去开锁；第二，高权限操作必须强制走一次“本地信任链”验证。比如大模型说“调用unlock_door”，执行层会拒绝直接执行，而是通过硬件侧的活体检测、指纹验证、安全芯片签名三重确认后，才真正给电机通电。
4.3 端侧集成大模型的Agent框架选择
在嵌入式Linux环境里，我没法直接用LangChain这种重框架，因为依赖太复杂、内存开销大。更稳的做法是自研一个轻量agent执行器，核心模块就三块：
- 意图解析器：把用户语音或文本转成结构化指令（比如“谁在门口” → {intent: "query_visitor", target: "front_door"}）；
- 状态管理器：当前门锁状态、传感器最新数据、最近事件序列、活跃用户索引；
- 执行引擎：一个死循环，读取新的意图，查询工具描述，调用工具，收集结果，再送到大模型或规则引擎生成后续动作。
这里有个面试题里常考的“agent组成结构”：你完全可以告诉面试官，智能锁agent就是由“感知模块、状态管理模块、决策引擎、工具模块、记忆模块”组成，它们之间的数据流是单向闭环的，漏掉任何一环都会变成玩具demo。
4.4 实战：用deepseek做一个“门锁管家”小实验
追求低门槛，我们用纯软件模拟一个智能锁agent，也可以跑在开发板上。假设我们选deepseek作为大脑，并用Python定义一个简单的Agent类。
核心逻辑：
import json class LockAgent: def __init__(self, memory_path="memory.json"): self.memory = self.load_memory(memory_path) self.sensors = { "door_open": False, "human_detected": False, "time": "08:30" } def load_memory(self, path): # 读取本地记忆文件，保存家庭成员作息、事件记录 pass def perceive(self, sensor_data): self.sensors.update(sensor_data) # 将传感器原始数据转换为结构化描述 event_prefix = "门处于打开状态" if self.sensors["door_open"] else "门已关闭" return f"{event_prefix}，当前时间{self.sensors['time']}，门口人体检测{'识别到' if self.sensors['human_detected'] else '未识别到'}" def invoke_tool(self, tool_name, params): # 注意：这里必须经过权限校验 print(f"[执行] {tool_name}，参数={json.dumps(params, ensure_ascii=False)}") # 假设大模型只是决定工具调用，实际工具在这里执行 return {"success": True, "tool": tool_name} def decide(self, instruction): # 此处简化为调用云端LLM接口，构造prompt让deepseek决定动作 prompt = f"""你是一个智能门锁管家agent。你的记忆：{self.memory} 当前感知信息：{self.perceive({})} 用户指令：{instruction} 请返回需要执行的一个工具调用，格式为JSON。可选工具：open_lock、close_lock、voice_tip、send_msg。 """ # 实际开发中，调用deepseek的API并把返回结果解析为json response = "{\"tool\": \"voice_tip\", \"params\": {\"content\": \"好的，已为您记录，请带好钥匙\"}}" action = json.loads(response) return self.invoke_tool(action["tool"], action["params"]) if __name__ == "__main__": lock = LockAgent() print(lock.decide("我要出门了，请提醒我拿伞"))这只是一个骨架，但它体现了agent的基本闭环：感知输入 → 构造语义 → 大模型决策 → 工具执行。实际产品中，你还需要加上多轮对话管理、嵌入向量检索、异常回滚等。不过这个demo已经能解释“deepseek在agent里到底干嘛”了——它不是直接回答你“提醒你拿伞”，而是决定调用voice_tip工具，并通过参数把提醒内容传出去。
4.5 云端与端侧的通信协议设计
智能锁agent涉及在线服务和本地硬件的异步交互。别用弱实时性的HTTP轮询来做，建议采用MQTT over TLS，并且本地设备作为消息发布者，云端agent作为订阅者。典型消息结构：
{ "event_id": "uuid-xxxx", "device_id": "lock_001", "event_type": "door_opened", "occurred_at": 1760000000, "context": { "user_id": "u123", "confidence": 0.99, "by": "fingerprint" } }云端agent收到事件后，会结合长期记忆触发一个策略链：是否需要更新习惯模型？是否要推送消息？是否要调整布防状态？最终生成指令消息（比如开启夜景模式）发回设备。通信必须做幂等和去重处理，防止因断网重发而导致重复提醒。
4.6 安全与隐私的底线设计
这部分是智能锁agent的生命线。如果处理不好，再好的情感化都是灾难。我的经验是三条硬性规则：
- 数据不出网关：所有的原始生物特征（指纹图、人脸图）只存在设备安全芯片中，云端和agent只能拿到“特征向量”或“脱敏标签”，例如“人脸向量距离0.82，判定为主人”。即使云端被拖库，也无法还原人脸。
- 大模型没有直接控制权：大模型永远只能“建议”，实际控制必须经过本地权限服务。可以理解成大模型是参谋部，硬件安全芯片才是司令官。
- 被遗忘权必须实现：用户应当能一键查看agent储存的“关于我”的所有数据，并支持删除某时间段的历史记忆。智能锁卖的不是“数据矿”，而是“安全与安心”。
5. 常见问题与排查技巧实录
5.1 大模型幻觉导致误操作怎么办
最常见的失败案例是：agent错误地理解了用户意图，把“打开门”理解为“打开监控”，甚至触发反锁。我的排查思路是三层校验：
- 意图置信度阈值：当大模型返回的执行意图置信度低于0.7时，进入人工确认流程，让用户说“确认”或按键确认；
- 工具参数校验：比如开锁工具要求必须传reason参数，且reason不能为空；执行前会检查门磁状态，如果门已打开，则拒绝执行；
- 执行后验证：动作执行后，读取传感器回读状态，确认门锁状态和预期一致，否则立即执行“回滚”动作（比如重新上锁）并通知用户。
5.2 延迟太高：用户说了“开门”3秒才有响应
大模型推理速度再快，走云端也会有200~800毫秒延迟，加上语音识别和工具调用，很容易突破2秒。解决办法是“意图预判”。
在端侧用一个小型文本分类器（甚至一个关键词规则集合）先把高频意图（开门、关门、查询电量、查询状态）识别出来，直接用预定义流程执行，不走大模型。只有当端侧识别置信度低，或者意图涉及多步骤规划（比如“如果我不在家，你看到陌生人就报警”）时，才触发云端大模型。这一招能把平均响应时间降到800毫秒以内。
5.3 离线环境怎么保证agent可用
断网不等于agent死亡。你可以设计一套“降级策略”：
- 离线时使用端侧小模型完成动作识别、开锁、警报；所有云端交互都替换成本地日志；
- 语音对话降级为预先录制的提示音或本地规则问答（比如“谁在门口”这种固定问候）；
- 恢复网络后，端侧会上传事件摘要到云端，云端agent再补全长期记忆更新。
这种设计虽然会让体验有些“打折”，但关键安全功能在断网时永远稳定，这符合产品底线。
5.4 数据隐私争议如何应对
这是很多人最关心的部分。我的个人建议是：在产品说明书和App里开一个“思维链展示”的开关，让用户能看到agent的决策路径，比如“你说了‘开门’，由于你的指纹特征已验证，执行开锁”。透明化能减少焦虑，也让用户知道哪些数据被使用了。另外要提供“纯本地模式”，在该模式下agent不连接云端，只在网关内运行，牺牲部分AI能力换最大隐私。实测下来，老年人反而更愿意使用纯本地模式，接受度很高。
6. 德施曼之后，智能锁产品往哪走
这次发布会的真正信号，不只是德施曼这一家的事。整个行业会从“单品智能”走向“场景智能”。当你家的门锁、门铃、摄像头、灯光、空调、窗帘都能被同一个agent调度时，产品边界就模糊了。
我个人的体会是：AI agent在智能锁上的价值，不是替你做几个酷炫的演示，而是它第一次把“物理安全”和“情感关怀”这两个完全不同的维度，装进了同一个系统。做这类产品最忌讳的就是为了“智能化”而智能化。我在实际参与类似项目后最大的心得是：先老老实实把传统功能（开锁、报警、防拆、低功耗）做到极致，再往上加agent能力。因为agent是“锦上添花”，安全才是“地基”。
最后再分享一个小技巧：设计agent的提示词时，千万别用太“机器”的语气，比如“请确认是否开锁”，家庭场景里太生硬。试着用人际沟通的语言，比如“好的，我正在为您开门，外面下雨，记得拿伞”。用户感受到的不是“AI功能”，而是一个住在门上的、懂生活的助手。想测试自己的agent够不够“情感化”，你就让一个陌生人连续使用五分钟，看他会不会产生“这锁真贴心”的感觉——能达到这个标准，你才算是真的进入了AI agent时代。
