人体状态感知如何接入设备，并服务于机器人、座舱与室内空间？

集成的起点：希望改变哪一段服务？

如果目标只是让用户通过语音开灯，语音与设备控制可能就足够。人体状态感知更值得参与的，是需要结合人的变化组织任务、生活辅助、持续关注或个性化服务的过程。

设计接入方案时，先明确使用者的目标，再梳理信息由谁采集、如何解释、谁安排任务、哪些设备执行，以及后续反馈由谁接收。根据这些环节的实际需要选择指标。

把设备接入与空间应用分成两层

设备接入层关注已有摄像头、处理平台、模组与软件之间的配合。空间或业务应用层关注多个入口产生的信息怎样被正确理解，怎样与用户选择和任务进度联系起来，以及服务怎样继续。

科思创动的SDK、明眸、明镜和边缘计算设备，对应不同的产品接入形态。^[1] 这些名称说明了接入形态；是否具备完整的跨设备状态平台，还需核对具体方案。

图示可在框内左右滑动查看。

一个室内空间中的可能分工

这是概念分工表，不是正式API或当前产品的统一功能清单。具体哪些环节由客户系统、科思创动产品或合作方承担，应在实际方案中分别明确。

输入不只是图像，还包括时间与情境

对于生理节律，连续视频变化具有意义，单帧外观本身不足以构成脉搏周期。^[2] 在系统中，还要知道输入来自哪个设备、对应哪段时间、是否属于当前服务对象，以及用户当时在做什么。

这些背景不一定全部送进感知算法，也不一定由SDK提供。可以由应用在允许范围内组织最少必要信息，但需要避免把多个时段、多个对象的记录混在一起。

输出应当说明“是什么”，而不只传一个分数

用户选择与任务记录通常由应用侧管理，是否由SDK提供相应字段，需要核对版本资料。具体接口、编码和更新方式也以该版本的正式技术资料为准。

服务可以跨入口，但生理记录不应直接无条件拼接

用户在智能镜前选择了后续关注安排，机器人或智能屏可以在适当权限下接续任务。此时延续的是明确选择和必要进度，不代表所有设备都需要获得用户完整历史。

若还需要比较不同入口取得的生理值，就要另行处理指标含义、设备差异和可比条件。任务能够接续，并不能说明不同设备的测量结果已经一致。

身份归属不明时，应暂停跨人关联；输入缺失时，应保留信息不足的状态，而不是把旧值包装为当前结果。

三类系统各有约束，不应套用同一个响应模板

室内空间可以协调环境、任务与不同设备，使服务在入口变化后仍可接续。机器人承担移动感知、自然交互和自身真实支持的辅助执行，不必包办所有空间决策。健康座舱同样可以使用状态信息，但必须优先服从驾驶任务与整车安全要求。

一台主动使用的终端可以提供较完整的说明，行驶中的驾驶员则不适合接受额外操作负担。相同信息进入不同场景时，使用方式必须重新结合任务判断。

部分信息不可用时，基础服务仍应继续

人离开画面、输入中断或光照变化时，状态模块可能暂时不能提供某类信息。应用仍可执行清楚的用户指令，保留正常任务与求助通道，不应把额外感知变成所有服务的前置条件。

同时，感知模块不负责替代机械安全、车辆控制或业务授权。风险需要结合实际用途、错误后果和分工管理，NIST AI风险管理框架也强调这种情境化原则。^[3]

产品资料与系统方案应该分别回答什么？

产品资料说明实际支持的输入、功能、平台和接口；系统方案说明它们怎样进入空间服务，哪些能力来自其他设备，如何组织权限、任务与运行责任。接入时，应核对产品接口能否满足方案中的信息需求。

软件调用成功后，还要确认状态信息用于哪项服务，以及感知模块、应用和执行设备分别承担哪些工作。 产品形态见《人体状态智能SDK、明眸、明镜与边缘计算设备如何选择？》，室内整体架构见《当室内空间成为物理AI系统，人体状态智能能带来什么？》，计算位置见《人体状态感知为什么要区分端侧、边缘和云端？》。