小丹尼DannyData用一句话概括这个项目：我把一个叫 OpenClaw 的开源智能体框架（社区里都喊它“龙虾”）部署到了自己电脑上，然后基于它搭了一套“AI 防盗门”——摄像头持续盯着屏幕前有没有人，发现不是我就自动锁屏、语音警告、推送通知。整个过程没有用云服务，人脸特征全部本地处理，决策逻辑交给大模型 Agent 来做。这篇文章记录的就是完整搭建过程、架构思路和一周实测下来的坑。
先说清楚，这套东西不是给你的电脑装一个传统的密码锁。密码锁解决的是“别人拿到密码也进不去”，但解决不了“你离开工位忘了锁屏”“同事趁你倒水顺手翻你桌面”“合租室友趁你睡觉打开你笔记本”这类场景。AI 防盗门的核心不是增加验证强度，而是让电脑学会认人——它知道屏幕前坐着的人是不是你，不是就直接锁上。
1. 所谓“AI防盗门”，防的不是密码，是那几分钟的信任真空
1.1 传统锁屏解决不了的两个真实场景
第一个场景是我自己遇到的。在公司开放工位，我去楼下拿外卖，来回大概十分钟。回来一看，屏幕被人切到别的窗口翻了几页，虽然没动文件，但那种“被窥探”的感觉非常难受。问了一圈，同事承认说是想借我计算器用一下，看我不在就直接摸了。问题在于我根本没锁屏——不是没有锁的习惯，是有时候赶时间真的会忘记。
第二个场景更有意思。我一个朋友做独立开发，笔记本放在工作室，平时门不锁。邻居家小孩有时候跑来玩，会趁他上厕所去点他的电脑，虽然不知道密码进不了系统，但锁定界面会被反复折腾，有一次还把他外接硬盘里的开发日志给删了。这已经不是密码能解决的问题了，电脑需要自己判断“现在该不该让这个人碰我”。
这两个场景本质上是同一件事：你在物理上离开了设备，但设备还处于“信任默认状态”。传统锁屏默认信任任何人，直到验证失败才拒绝；AI 防盗门应该反过来——默认不信任任何人，直到识别出是你才放行。
1.2 为什么这事得让 AI Agent 来干
如果只是做人脸识别锁屏，OpenCV 加一个人脸识别库就够了，根本不需要 Agent。但实际做起来你会发现，场景比想象中复杂得多：
- 你戴帽子、换眼镜、光线从左边变成头顶，人脸相似度直接从 0.9 掉到 0.6，怎么办？
- 你只是去倒杯水，三秒钟就回来，系统一看到相似度低于阈值就直接锁屏，每次回来都要重新解锁，烦不烦？
- 朋友临时要用你电脑查个资料，你怎么在不关防护的情况下给他开五分钟权限？
- 摄像头如果能检测到“屏幕前根本没有人”，那锁屏动作是不是其实可以晚几秒？
这些都不是“是不是本人”这种二值判断，而是 带上下文的决策。要处理上下文和策略，单纯写 if-else 也能写，但会非常僵硬——每个条件都要提前想到，一旦场景变了就要改代码。而用 AI Agent 来做决策，你可以把规则变成自然语言策略，Agent 根据输入信号动态判断。
我把 OpenClaw（社区昵称“龙虾”）装好之后，发现它还带工具调用和消息通知能力，这不就是一个现成的“门卫大脑”吗？人脸特征我用本地模型比对，得到的是一个客观相似度分数；但“分数低到什么程度该锁屏”“连续多少帧异常才触发告警”“临时授权怎么放行”这些决策，全部交给 Agent。硬判断交给机器，软策略交给 AI，这是整套架构里最核心的设计。
1.3 这套方案适合谁、需要什么底子
先说技术前提：你需要能跑通 Python 脚本，懂一点命令行，能用过大模型 API（OpenAI 格式兼容的都可以，或者本地跑一个 Ollama 也行）。不要求你会写多复杂的代码，但至少要知道怎么创建虚拟环境、改配置文件、启动一个进程。
硬件上要求很低：一台带摄像头的电脑，内存 16G 就够跑得很舒服。人脸特征提取用的是 CPU 就能跑的轻量模型，不需要 GPU；Agent 决策我会用本地 7B 模型处理，你直接用云端 API 也没问题，但要注意人脸视频帧不要传上去，隐私风险太大。
如果你满足这些条件，这套东西大概一个下午就能搭完。我现在这台主力笔记本已经连续跑了 7 天没关，日常办公、写代码、开会都不受影响。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先把“龙虾”架起来：OpenClaw 的基本盘
2.1 “龙虾”到底是个什么框架
OpenClaw 严格来说是一个通用 AI Agent 运行时框架，作者在 GitHub 上开源，内部模块负责模型接入、工具调用、对话记忆和任务编排。社区里喊它“龙虾”主要是因为项目代号和图标，用着用着就传开了。
它解决的问题很直接：你不想每次想做个自动化任务都从零写一遍模型调用代码。框架把模型接口屏蔽掉之后，你只需要注册一堆工具函数，然后告诉 Agent“什么时候该调哪个工具”，它自己会决定调用顺序和参数。
拿防盗门场景来说，摄像头识别模块是我写的工具，系统锁屏命令是我写的工具，消息通知也是我写的工具。Agent 拿到这些工具后，就像一个门卫拿到了对讲机、电棍和电话——它能自己决定先看监控画面，再决定要不要锁门。
2.2 安装前我只关心三件事
第一，Python 版本。OpenClaw 依赖比较新，我建议直接用 Python 3.10 以上，我本机是 3.11.9，全程没遇到依赖兼容问题。
第二，模型接口。推荐先准备一个 OpenAI 兼容格式的 API 地址和 Key，放在环境变量里。如果你想全部本地化，那就把 Ollama 先装好，拉一个 qwen2.5:7b 之类的模型，说实话决策任务 7B 模型完全够用。
第三，摄像头权限。你要确保运行 Agent 的这台电脑能正常调起摄像头。Windows 上记得在“隐私-相机”里允许应用访问；macOS 要给终端软件授权；Linux 上要确保当前用户有 video 组权限。
2.3 安装步骤与首次启动
克隆项目、建虚拟环境、装依赖、配置环境变量，四步走：
bash复制git clone https://github.com/openclaw-project/openclaw.git
cd openclaw
python -m venv .venv
source .venv/bin/activate # Windows 下执行 .venv\Scripts\activate
pip install -r requirements.txt
依赖装完，复制环境变量模板并编辑：
bash复制cp .env.example .env
vi .env
.env 里我主要改了这几项：
ini复制OPENAI_API_KEY=sk-xxxxxx
OPENAI_BASE_URL=https://api.xxxxxx.com/v1
AGENT_MODEL=qwen2.5-7b-instruct
CAMERA_INDEX=0
TZ=Asia/Shanghai
CAMERA_INDEX 被 OpenClaw 调起来之后，通过框架传给我自己写的视觉模块，告诉它初始化哪个摄像头。TZ 这个字段看起来不起眼，但审计日志的时间全指望它，后面我会专门讲时区坑。
启动命令很简单：
bash复制python main.py
看到控制台输出 Agent 初始化完成，并且你可以在终端里跟它对话，就算是跑通了。
2.4 验证框架能干活
先别急着做防盗门，先让 Agent 执行一个最简单的任务，验证工具调用链路是通的。我在框架里注册了一个 echo_tool，然后在终端里对 Agent 说“帮我调用 echo 工具，参数写 hello guard”。如果它正确返回结果，说明 Agent 已经具备“听懂指令并调用指定工具”的能力，这是后续一切的基础。
我当时卡在一步：注册工具后 Agent 完全不调用，一直凭空回答。后来发现是工具描述写得不够细，OpenClaw 对工具的 function calling 依赖描述里的参数格式，参数名和类型都要按 JSON Schema 写清楚。类比一下就是：门卫知道你有对讲机，但你得告诉他按哪个按钮是对讲、按钮按了之后说什么话，他才会用。
3. 防盗门的整体架构：一只眼睛、一个大脑、一套锁具
3.1 三个模块的分工
整套系统我拆成了三层，各管各的，互不干扰：
感知层负责采集原始信号。摄像头每隔一段时间抓一帧画面，用本地人脸识别模型提取特征向量；同时系统模块会记录键盘鼠标的空闲秒数。这些信息不直接触发任何动作，只是作为 Agent 的输入信号。
决策层是 OpenClaw Agent 本身。它接收感知层送来的数据，按照我定义的策略 prompt 判断当前应该处于什么状态。它的输出是动作指令——继续监视、切换成告警模式、直接锁屏。
执行层接收动作指令，执行锁屏、播放警告音、推送通知等操作。这一层跟感知层完全隔离，Agent 说锁屏就锁屏，锁屏函数本身不掺任何判断逻辑。
这三层结构的好处是每一层都能单独测试。我可以先把人脸模块跑起来确认相似度数值合理，再把锁屏函数单独调一次确认命令能生效，最后再把 Agent 接进来做端到端测试。如果一上来全部串通，出了 bug 根本不知道是哪个环节的问题。
3.2 人脸识别为什么不能只听大模型的
我最初的设想很天真：直接把摄像头画面发给大模型，让它判断“这个人是不是电脑的主人”。结果被现实教育了——模型对陌生面孔的描述确实准确，但当我和我室友长得都有点像、又都在画面里的时候，它的判断开始飘忽，一会儿说“置信度中等”，一会儿给出完全相反的结论。
后来我把架构调整成混合模式：人脸特征提取和相似度计算完全由传统视觉模型本地完成，大模型只负责基于相似度分数和其他上下文信号做策略决策。视觉模型输出的是一个 0 到 1 的 cosine 相似度分数，这是客观数字；大模型拿这个分数以及空闲时间等信号，判断“现在要不要锁屏”。
为什么这样设计？因为人脸识别这种任务本质上不适合用语言模型来做——它需要像素级别的判别能力，这是 CNN 系模型的强项。而“相似度 0.62 且空闲 40 秒的情况下要不要打断当前会话”这种问题，需要权衡和上下文理解，恰恰是语言模型的强项。各用其长，系统才稳。
3.3 决策链路上的两级判断
实际运行的时候，决策链路是这样的：
- 摄像头采样，提取当前人脸特征向量；
- 与本地存储的“主人特征库”计算相似度，得到一个分数和一个是否检测到人脸的标志；
- 同时获取系统 idle 秒数、当前时间、最近是否有键盘输入；
- 把以上所有信息打包成一条结构化消息，交给 Agent；
- Agent 根据策略 prompt 输出一个状态码，可能是
monitor、warn、lock中的一种； - 执行层根据状态码执行对应动作。
这一条链路走完通常需要 1 到 3 秒，主要耗时在大模型推理上。所以我没有让 Agent 每帧都参与决策，而是每两秒采样一帧，但只有当人脸相似度低于阈值或者状态发生切换时，才真正调用 Agent。平时一个人正常坐着办公，Agent 完全不需要参与，CPU 占用可以忽略不计。
4. 接线实操：把视觉模块和系统锁屏工具挂进 OpenClaw
4.1 第一步：本地人脸特征库
人脸特征提取我选的是 InsightFace 的 buffalo_l 模型，轻量、CPU 可跑、对戴口罩和偏转脸鲁棒性不错。安装：
bash复制pip install insightface onnxruntime
首次运行会下载模型权重，大概 300MB，之后就在本地缓存。提取特征的核心代码长这样：
python复制import insightface
import numpy as np
import cv2
face_app = insightface.app.FaceAnalysis(name='buffalo_l')
face_app.prepare(ctx_id=-1) # -1 表示用 CPU
def extract_embedding(frame):
faces = face_app.get(frame)
if not faces:
return None
return faces[0].normed_embedding # 已经归一化的 512 维向量
录入主人人脸时，我采集了 10 张不同光线、不同角度的照片，提取 10 个向量取平均，作为标准特征向量存到本地 owner_embedding.npy。以后每来一帧画面，提取当前向量，计算它和标准向量的 cosine 相似度：
python复制def similarity(embedding):
owner = np.load('owner_embedding.npy')
return float(np.dot(embedding, owner)) # 都是归一化向量，点积就是 cosine
实测下来，正常人脸相似度在 0.75 到 0.9 之间；完全陌生的脸在 0.4 以下；光线特别差的时候本人可能跌到 0.55。这个 0.5 到 0.7 之间就是灰色地带，交给 Agent 去判断。
4.2 第二步：把系统状态变成 Agent 能读的信号
系统空闲时间在 Windows 上可以调 Win32 API，macOS 用 CGEventSourceSecondsSinceLastEventType，Linux 读 /proc/uptime 配合 X11 idle 命令。我这里给出 Windows 版本（因为我主力机是 Windows，其他平台你搜一下就有现成方案）：
python复制import ctypes
def get_idle_seconds():
class LASTINPUTINFO(ctypes.Structure):
_fields_ = [('cbSize', ctypes.c_uint), ('dwTime', ctypes.c_uint)]
info = LASTINPUTINFO()
info.cbSize = ctypes.sizeof(LASTINPUTINFO)
if ctypes.windll.user32.GetLastInputInfo(ctypes.byref(info)):
millis = ctypes.windll.kernel32.GetTickCount() - info.dwTime
return int(millis / 1000)
return 0
锁屏函数同样分平台，Windows 用 rundll32.exe user32.dll,LockWorkStation，macOS 用 pmset displaysleepnow，Linux 用 loginctl lock-session。我用 Python 的 subprocess 包统一封装成一个工具函数：
python复制import subprocess, sys
def lock_screen():
if sys.platform == 'win32':
subprocess.run('rundll32.exe user32.dll,LockWorkStation', check=True)
elif sys.platform == 'darwin':
subprocess.run(['pmset', 'displaysleepnow'], check=True)
else:
subprocess.run(['loginctl', 'lock-session'], check=True)
4.3 第三步：给 Agent 注册“门卫工具”
OpenClaw 里注册工具的方式很直接。核心是把函数名、参数 schema 和描述信息暴露给框架。我的工具列表有三个：
get_screen_status()：返回{face_similarity, face_detected, idle_seconds, has_input_recently}；lock_screen()：执行锁屏；send_alert(message)：推送本地通知或钉钉/Server 酱消息。
注册的时候有一个关键点：工具描述要写清楚每个参数的含义和取值范围。比如：
python复制tools.register(
name='get_screen_status',
description=(
'获取当前屏幕前的安全状态。'
'face_similarity 是 0 到 1 的浮点数，越高代表越像电脑主人；'
'face_detected 表示画面中是否检测到人脸，纯背景场景为 False；'
'idle_seconds 表示键盘鼠标空闲秒数；'
'has_input_recently 表示最近 3 秒内是否有键盘或鼠标输入。'
),
parameters={
'type': 'object',
'properties': {},
}
)
描述写得越具体，Agent 在决策时就越不会瞎猜。你想想，一个刚上岗的门卫，如果连“什么信号代表什么”都不清楚，他怎么知道什么时候该锁门。
4.4 第四步：门卫策略的 Prompt 设计
这是整套系统里我迭代次数最多的地方。Prompt 写得不好，Agent 就会乱锁屏或者形同虚设。我最终稳定下来的版本大概是这个思路：
code复制你现在是一台个人电脑的 AI 门卫。
你每 2 秒会收到一次 get_screen_status 的结果，根据以下规则决策：
1. 如果 face_detected 为 False，说明屏幕前暂时没人，保持 monitor 状态，不要锁屏，给主人留出离开座位的时间。
2. 如果 face_similarity 大于等于 0.70，说明是本人，保持 monitor。
3. 如果 face_similarity 在 0.50 到 0.70 之间，并且 idle_seconds 小于 5 秒，说明可能是本人出现在摄像头前但角度或光线不佳，保持 monitor，等待下一帧确认。
4. 如果 face_similarity 低于 0.50，且连续 3 次采样都如此，执行 lock_screen，然后调用 send_alert 通知主人。
5. 如果 detect 到画面有陌生人但没有异常操作（idle_seconds 小于 10），先调用 send_alert 发送警告，不立即锁屏，再等待后续采样；如果后续仍相似度低，再锁屏。
注意：不要根据单次采样做最终判断，至少要看到当前状态和前两次状态。
这个 prompt 里最关键的设计是“连续 3 次”和“灰色地带缓冲”。如果没有这两条，我在工位上稍微歪个头、或者同事路过摄像头边缘，都会触发锁屏，那这套系统就没法用了。
4.5 第五步：常驻运行参数
视觉采样器我单独写了一个线程，每 2 秒抓一帧、提取特征、更新共享状态；主线程运行 OpenClaw 循环，每 2 秒读取一次共享状态并调用 Agent 做判断。为了防止每 2 秒都调用一次大模型烧 API，我在代码里做了事件驱动：只有当相似度从正常掉到灰色地带、或者灰色地带掉到红色区域时，才真正触发 Agent 决策。如果状态一直稳定，Agent 完全休眠。
运行起来之后：
bash复制python main.py --mode guard --interval 2 --stability 3
--interval 2 是采样间隔，--stability 3 是需要连续确认的帧数。这两个参数就是误报率和响应速度之间的旋钮——想要反应快就调小 interval，想要更稳就调大 stability。
5. 把误报降到最低：冷静期、临时授权和审计日志
5.1 误报的三个主要来源
跑了三天之后，我开始统计误报次数。问题主要集中在三种情况：
光线突变。下午三点到四点，阳光从窗户斜照进来，人脸相似度会突然从 0.78 掉到 0.58，如果不加缓冲区，这一下就会触发警告。解决方案是 prompt 里那条“灰色地带但 idle 小于 5 秒保持 monitor”，实际上就是把光线突变当作短暂干扰忽略掉。
背影和半张脸。我有时候站着写代码，背对摄像头，模型检测到一个人体轮廓但提取不到完整人脸，face_detected 变成 False。如果按早期的策略——没人就锁屏，那我每天要被锁十几次。后来改成“face_detected 为 False 时不锁屏”，问题就解决了。
戴着口罩喝饮料。一次我戴着口罩端着咖啡走回工位，相似度 0.45，触发了锁屏。这也是误报里最有争议的一次——你说它不是本人，其实是我；但严格来说它的判断逻辑没错，一个戴着口罩的人坐到你工位上，确实该警惕。后来我把行为信号加进去，如果检测到键盘输入并且后续几帧相似度回升，就判定为“本人在戴口罩”。
5.2 连续帧+冷静期的双重确认机制
误报一多，我就把确认逻辑改成了两道闸门：
第一道是连续帧确认。单次相似度低不算数，连续 3 次（大概 6 秒）都低，才认为有可疑人员。系统内部维护一个长度为 3 的滑动窗口，只有窗口内全部为异常状态，才进入告警流程。
第二道是冷静期。即使在滑动窗口全部异常之后，Agent 第一反应也不是直接锁屏，而是先调用 send_alert 播放一段语音警告：“检测到当前用户非本人，请在 10 秒内输入主人授权口令，否则系统将锁定屏幕。”
冷静期的威慑价值比技术价值更高。我实测下来，陌生人听到语音警告后绝大多数会直接收手离开，真正走到锁屏步骤的反而是少数。如果一开始就直接锁屏，反而会惊吓到借电脑的朋友，搞得关系尴尬。
5.3 临时授权接口，解决“借电脑给同事”的尴尬
这是被同事吐槽出来的需求。有次我同事想用我电脑查个资料，我刚走开，系统锁屏加语音警告二连击，把他吓了一跳。后来我在系统里加了一个 authorize 命令：通过 OpenClaw 对话接口输入“授权 userA 使用 15 分钟”，Agent 会在白名单文件里记录一条带有效期的授权记录。在有效期内，这个人脸特征会被标记为“临时可信”，锁屏阈值自动下调到 0.2。
这个功能用起来非常顺。授权指令不需要通过复杂的界面，直接在 Agent 对话框里打一句话就行，Agent 会解析时间参数并调用授权工具。白名单文件是 JSON 格式，每一条都包含人脸特征向量、授权开始时间、授权过期时间和备注，方便追溯。
5.4 审计日志的字段设计和时区坑
审计日志必须记录每一次判断和每一次动作，不然出问题的时候无从查起。我用的格式是 JSON Lines，一行一个事件，字段如下：
json复制{
"timestamp": "2025-06-18 14:33:21",
"event_type": "face_detected",
"similarity": 0.76,
"idle_seconds": 2,
"decision": "monitor",
"reason": "similarity above threshold"
}
每个事件的 decision 字段对应最终状态，reason 是 Agent 给的理由——这个字段帮了我大忙，因为如果哪天系统莫名其妙锁了屏，我能直接从日志里看到当时 Agent 是依据什么条件做的决定。
时区这个坑，我必须单独说。最初我没给 timestamp 指定时区，结果 Python 的 datetime.now() 返回的是系统本地时间，而框架内部有些日志用的是 UTC，两个时间戳混在一起，排查问题时前后对不上。后来我统一改用 zoneinfo 指定 Asia/Shanghai，所有日志时间戳一律用同一个时区，问题彻底消失。
6. 实测结果与踩坑记录
6.1 三个典型场景的实测表现
我把这套系统带到真实的办公环境里跑了一周，挑三个典型场景说说。
场景一：离开工位。我从座位上站起来，走到饮水机接水，耗时大概一分钟。系统在我离开约 4 秒后检测到 face_detected 为 False，进入 monitor 状态；8 秒后摄像头检测到隔壁工位同事从我身后经过，get_screen_status 输出相似度 0.35、idle 大于 30 秒，Agent 触发语音警告，但没有锁屏——因为警告发出后，同事根本不会碰我电脑，他正常走过去了。等我坐回来，相似度回升到 0.81，系统自动恢复 monitor。整个过程中只有一次警告，没有一次误锁。
场景二：陌生人接触电脑。我特意请一个和我长得一点都不像的朋友坐到我工位上，模拟趁我离开翻电脑。系统在 3 帧异常后直接锁屏，同时推送了一条 Server 酱通知到我手机。从朋友坐下到锁屏完成，全程大约 8 秒。这个响应速度在可接受范围内——毕竟我离开工位通常都超过半分钟，8 秒足够拦住绝大多数情况。
场景三：我自己戴着帽子从背光处走回来。系统识别到人脸但相似度只有 0.52，绿色状态没有锁定，只是记录了一笔“similarity below normal but under threshold”，Agent 判断为光线干扰继续 monitor。等我走近，恢复到 0.74。这个场景如果换成写死阈值的脚本，大概率要误锁一次。
6.2 性能开销
之前担心摄像头常开会占用太多 CPU，实测下来比我预想的好：
| 项目 | 实测数值 |
|---|---|
| 采样器 CPU 占用 | 6% 到 10% |
| Agent 决策 CPU 占用 | 仅在状态切换时出现，峰值 18%，平均低于 2% |
| 内存占用 | 约 1.2GB（主要来自模型加载，可接受） |
| 单次人脸识别延迟 | 80ms 到 150ms |
| 单次 Agent 决策延迟 | 1.2 秒到 2.5 秒（本地 7B 模型） |
内存 1.2GB 看着高，但实际上模型常驻是值得的，因为如果每次识别都重新加载模型，单次延迟会飙升到几秒，门卫就形同虚设了。如果你内存紧张，可以把人脸模型换成 MobileFaceNet，内存能降到 500MB 以内，识别精度差一些但我日常用完全够。
6.3 踩过的坑和修复方案
第一个坑：摄像头被其他应用占用。我连续两次遇到系统莫名卡死，最后发现是 Zoom 开会后没有完全释放摄像头，我的采样线程一直初始化失败。后来给采样器加了 5 秒超时和自动重试，并且捕获摄像头初始化异常后降级成“只用 idle 信号判断”——反正人脸拿不到，至少还有键盘鼠标空闲时间可以作为粗略判断信号。
第二个坑：笔记本合盖再掀开之后，摄像头设备索引偶尔会变。有时是 0 有时是 1，导致系统切换失败。我的处理是启动时动态枚举摄像头设备，不写死索引，选第一个能正确打开的设备。这个修复非常关键，我一度因为这个原因把防盗门挂起了一整天。
第三个坑：Agent 偶尔会抽风。大模型本质上还是概率模型，遇到 prompt 模糊时会给出匪夷所思的决策。比如有一次我测试，人脸相似度 0.85 明确是本人，Agent 却因为 idle_seconds 太大而强行判定为“可疑行为”。后来我给 prompt 加了一条最高优先级规则：“无论其他信号如何，只要 face_similarity 大于 0.70，一律放行不告警。”同时用日志里的 reason 字段持续观察，逐步把这类边界问题磨平。
第四个坑：语音警告音太突兀。我一开始用系统默认提示音，结果每次警告都像火灾警报一样吓人，连我自己都会被吓一跳。后来换成了 80ms 的柔和提示音文件，并把音量控制在 40%，既能引起注意又不至于让全办公室的人都回头看。
写在最后的操作心得
这套系统到现在已经稳定跑了三周，最大的体会是：AI 防盗门真正的价值不在于“防盗”，而在于它给了我一种确定性——不管我在不在电脑前，这台设备都不会被我不信任的人打开。那种“随时可以起身离开”的底气，是用多少个密码锁都换不来的。
如果你想复刻这个项目，我建议从最简单版本起步：先把摄像头采样和人脸识别跑通，再让 Agent 学会调用锁屏工具，最后再逐步加语音警告、临时授权和复杂策略。不要一上来就追求完整，分阶段推进能省掉大量调试时间。
最后分享一个小技巧：把这套 Agent 的决策日志全部打开，跑个三天，然后翻一遍日志。你会清晰地看到哪些策略产生了误报、哪些点赞了又删了，这个过程比任何调参教程都有用。你的防盗门会越用越懂你，这大概就是“让 AI 接管门口”这件事最迷人的地方。