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 与成本问题. 所以视觉与语音判定全部在本机完成, 只把"提炼后的事件"往上抛.

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