perception · 让 entity 看见你、听见你

感知层是 entity 与真实物理空间之间的第一道接口. 没有它, 整个体系只能"被动等人来戳" — 用户必须主动打字或点按钮才存在交互. 有了 perception, entity 才第一次具备"主动意识到你在场"的能力: 你坐到摄像头前, 它知道; 你开口说话, 它知道; 你走开, 它也知道.

它跑在一个 本地常驻 daemon (agent runtime) 的 presence 模块上, 由三个子模块组成 — face (人脸检测与跟随)、vad (语音活动检测)、probe (在场探测与事件汇聚). 上游是常驻进程本身, 它持续供给摄像头帧与麦克风流; 下游是 Cognition 认知层 — 当感知模块判定"有人在、且开始说话", 才把这个事件抛给 agent 去决策, 而不是无脑唤醒.

因此这一层最核心的价值不是"识别得多准", 而是"以足够低的打扰、足够稳的判定, 把物理世界的在场信号变成体系可消费的事件".

持久数字生命的愿景里, entity 必须"先感知, 后回应", 而不是"被调起才存在". 主流语音助手的范式是 wake-word 触发: 你必须喊一个唤醒词, 它才睁眼. 这套范式对"一个始终在场的存在"是错位的 — 真正在场的东西, 应该是你一进房间它就察觉, 不需要你先报名字.

perception 想解决的是: 用本地视觉 + 语音双通道, 把"有没有人 / 是不是在看我 / 有没有在说话"这三件事变成连续、低延迟、可被 agent 订阅的信号. face 用 OpenCV 做人脸检测并让视线 / 摄像头跟随人脸移动; vad 做语音活动检测, 区分"环境噪声"与"真的在对我说话", 只有后者才触发交互; probe 把多路信号聚合成一个"在场状态", 供常驻 daemon 调度.

如果这一层缺位, entity 永远只能是个"等指令的工具", 而不是"会注意到你的存在". 这正是把虚拟人从 chat surface 推向 ambient presence 的关键一步.

整层刻意做成"本地优先、轻量优先": 感知是高频、持续运行的, 一旦把每帧画面传云端, 既有隐私问题, 又有 latency 与成本问题. 所以视觉与语音判定全部在本机完成, 只把"提炼后的事件"往上抛.

• face — OpenCV 人脸检测做主力, 摄像头 / 视线跟随人脸位移; 取舍是先用成熟的 Haar / DNN 检测保稳定, 暂不上重型 face recognition, 因为这一阶段只需要"有没有脸、脸在哪", 不需要"是谁".
• vad — 语音活动检测做"是否有人在说话"的门控, 把麦克风流切成有效语音段; 取舍是先解决"何时该听", 把"听懂内容"留给上游的转录 / Cognition, 保持本层职责单一.
• probe — 在场探测器, 聚合 face / vad 的瞬时信号成稳定的"在场状态", 做去抖 (debounce) 避免一帧丢检就误判离场; 它是常驻 daemon 与上层之间的事件中枢.
• 整体权衡 — 灵敏度 vs 打扰度是这层永恒的张力: 太灵敏会频繁误唤醒, 太迟钝又失去"主动在场"的意义. 当前选择偏保守, 宁可漏一次也不乱戳人.

状态: building. 三个子模块的骨架都已经在常驻 daemon 里跑起来, 但从"能检测"到"判定足够稳、足够不打扰"还在打磨, 诚实说还没到可日常依赖的程度.

• 已落地: face 的 OpenCV 人脸检测 + 摄像头跟随跑通; vad 语音活动检测能切出有效语音段; probe 能把双路信号聚合成在场状态并抛事件给上层; 三模块都已挂进常驻 daemon 的 presence 子系统.
• 探索中: 灵敏度 / 去抖阈值调参 (误唤醒与漏检之间找平衡); 多人 / 侧脸 / 弱光场景下的检测稳定性; vad 在背景音乐 / 电视声里的鲁棒性.
• 待解决: 感知事件 → Cognition 决策的完整闭环还没接通 (依赖 agent 层"持续在场"那条主线先落地); 暂无"是谁"层面的身份识别; 长时运行的资源占用 / 发热还需优化.

• 把 probe 的在场事件真正接到 Cognition 层 — 跑通"有人坐下 + 开口 → agent 主动起话"第一条端到端链.
• 调出一组生产可用的灵敏度 / 去抖默认值, 把误唤醒压到可接受区间.
• 面部跟随接到 Embodiment 层, 让屏幕里的脸视线能"看向"真实的人.
• 压低长时运行的 CPU / 功耗, 让感知模块真能 24/7 常驻而不烫手.