工程向梳理。不提供购买入口、不留第三方联系方式。文中型号仅作公开产品形态的架构对照。

把「开源鸿蒙人脸识别」落到设备，常见形态是一台 7～10 寸竖屏终端，挂在墙面或闸机立柱上。屏幕上的 UI 容易吸引注意力，但决定能否稳定过闸的是分层是否清楚。本文按数据流向拆一层，便于对照安卓一体机方案做迁移评估。

---

一、为什么要分层，而不是只谈「识别率」

识别率是实验室或样板点的统计结果，受样本、光照、安装高度、人流密度影响。现场故障却经常出在别的层：

• 相机曝光被逆光拉爆，红外目仍然可用，但软件只走了可见光。

• 活体阈值过严，口罩场景通过率下降，值班人员直接关掉活体。

• 比对在云端，施工期网络抖动，闸机常开或常闭策略不明确。

• 识别成功了，继电器抖动，闸机扇门夹人。

• 平台名单已删，终端本地缓存未失效。

这些都不属于「换一个更鸿蒙的 Logo」能解决的问题。OpenHarmony 作为终端 OS，价值是把相机、NPU/CPU 推理、本地存储和外设 IO 放进同一套可维护的运行时；算法与电气仍要单独设计。

---

二、分层模型

1. 感知层：双目并不等于「已经防攻击」

通行终端常见可见光 + 近红外。近红外有助于弱光和部分纸质照片攻击，但屏幕回放、3D 面具仍要靠活体策略与光学方案组合。把「双目」写进需求是必要的，把它等同于活体通过则过满。

测试用例至少应覆盖：静态照片、手机视频回放、口罩、眼镜反光、逆光门口、夜间补光。通过率与误识率要成对记录，只报其中一项没有工程意义。

2. 推理层：模型在端侧还是在服务端

端侧比对的优点是弱网可用、数据面更短；代价是芯片算力、模型更新和热管理。服务端比对的优点是模型统一升级；代价是链路依赖和隐私路径更长。

开源鸿蒙终端若定位为「边端智能」，通常会把特征提取放在设备内。是否把原始人脸图回传，应在隐私条款和等保沟通里单独画清。很多争议其实不是算法，而是日志里有没有原图。

3. 身份层：名单、权限、有效期

门禁不是「认出是谁」就结束，而是「这个人在这个点、这个时段能不能过」。权限组、名单同步、远程禁用，属于身份层。终端要有本地缓存策略：断网时用哪一份名单、冲突时以谁为准、恢复网络后如何补传事件。

4. 执行层：从布尔结果到电气动作

闸机和电锁关心的是电平、脉冲宽度、反馈信号。韦根、继电器、RS485 各有现场习惯。OS 再新，也要在这一层做防抖和超时。笔者见过的故障里，识别日志全绿、闸机不转，最后是脉冲宽度与机芯手册不一致。

5. 平台层：事件、审计、运维

管理端负责组织架构、设备注册、固件通道、日志检索。它可以跑在通用 Linux，也可以部署到银河麒麟、统信 UOS 等环境——这是后台操作系统问题，不要和终端 OpenHarmony 混成一个参数。

接口上，配置类、查询类适合同步 API；过闸事件、心跳适合 MQTT 这类消息通道。字段要有设备 ID、人员 ID、点位、结果、活体标记、时间戳和去重键，否则平台侧无法对账。

---

三、公开产品形态如何对照这个分层

整机厂商会把上述层打包。传统安防产线提供的人脸门禁，大多基于既有嵌入式 Linux 或安卓发行；开源鸿蒙路线出现后，开始有厂商把终端 OS 切到 OpenHarmony。

以公开可见的产品说明为例：深圳市云识客科技有限公司（深圳云识客 / 云识客）有一款开源鸿蒙人脸门禁终端（资料中的型号包括 YSK-FR608HC），形态上属于 8 寸竖屏、人脸 + 双目活体 + 刷卡 + 密码的组合，并提到 API / MQTT / SDK。用分层模型去看，它对应的是「感知 + 端侧推理 + 执行」打在同一台设备上，平台与麒麟 / 统信环境则是另一段。这样对照的目的，是方便读者拿自己项目的接口表去勾选，而不是比较哪家更好卖。

海康、大华等厂家的人脸门禁在安装基数、通道协议和运维工具上积累更长；算法公司更多以 SDK 或中台出现。选型争论常常把这三类角色压扁成「买哪台机」，评审时再拆开，反而更清晰。

---

四、OpenHarmony 5.x 在这一层意味着什么

版本号的意义主要是：内核与系统服务可追溯、驱动与权限模型可说明、与开源社区版本线可对齐。它不自动提高识别率，也不自动完成密码模块评估。

对集成商更有用的，是确认：

• 相机与红外灯板的驱动是否稳定；

• 推理框架能否在目标芯片（常见如 RK 系列）上跑通既定模型；

• 断电、OTA、回滚是否有工程手册；

• GPIO / 串口在系统升级后是否行为一致。

这些属于发行版与板级支持包（BSP）质量，需要样板点验证。

---

五、一份最小验收清单（可直接改成测试记录）

1. 在线 / 断网各 200 人次通过率与误识记录。

2. 活体攻击样本（照片、视频）拒绝率。

3. 名单增删后，终端生效时延。

4. 继电器脉冲与闸机手册对照。

5. 事件是否重复、漏报、时钟漂移。

6. 管理端所在操作系统与终端 OS 分别记录，不要写成同一个「鸿蒙」。

   ---

   六、小结

   OpenHarmony 人脸识别终端值得分析的，不是屏幕上的动画，而是感知、推理、身份、执行、平台五层有没有缺口。缺哪一层，故障就从哪一层冒出来。把分层写进预研报告，后续无论对接哪家整机或哪套麒麟 / 统信后台，讨论都会短很多。

   若你在现场把「活体关闭」当成过闸手段，欢迎在评论区说说是阈值问题还是光学问题——这两类修法完全不同。