伴眸-居家养老AI 眼镜智能体 技术方案

伴眸 CompanionEye 技术方案

CompanionEye"伴眸"是一款面向居家养老场景的 AI 眼镜智能体。方案的重点不是把手机 App 搬到眼镜上，而是把 AI 眼镜的第一视角、自然语音、用户画像、生活记录和家属端维护能力串成一套可运行的照护工作流。老人侧只需要自然说话，系统侧完成意图判断、图像采集、状态管理和接口调用，家属侧负责维护长期资料并回看关键记录。

完整工作流：

1. 项目定位与设计目标

伴眸定位为居家适老生活守护智能体，主要面向独居老人、轻度认知衰退老人和家庭照护者。居家照护中的很多问题发生在日常细节里：早上的药是否已经吃过，桌上的点心能不能吃，钥匙刚才放在哪里，照片里的人是谁。传统手环、固定摄像头和普通语音助手能解决一部分问题，但它们很难同时理解"老人正在看什么"和"这位老人自己的生活记录是什么"。

我们将能力边界聚焦在五类老人侧场景：

场景	典型问题	系统目标
用药防错	“我今天早上的药吃了吗？”“这个药现在能吃吗？”	结合计划、记录和当前画面，提醒漏服、重复服药或疑似错服
饮食提醒	“这个我能吃吗？”“这瓶饮料适合我吗？”	结合食物画面、慢病标签和忌口信息，给出生活级饮食提醒
生活找物	“帮我记住钥匙在这里”“我的眼镜在哪？”	保存老人主动记录的位置摘要，后续用语音提示最近一次有效位置
人物识别	“这是谁？”“照片里这个人是谁？”	在家庭人物库范围内识别姓名和关系，低置信度时明确不确定
陪伴问答	“今天冷不冷？”“我有点无聊”	结合画像、插件和大模型能力，提供日常生活问答与智能陪伴

这些场景共享同一套用户画像、图像状态、后端记录和家属端资料维护机制，围绕老人日常生活形成连续的照护能力。

2. 系统总体架构

我们采用"AI 眼镜端 + 百宝箱/GPASS 工作流 + 后端服务 + 家属管理端"的整体架构。四个部分分工明确，并围绕老人侧一次语音请求形成完整数据流。

2.1 AI 眼镜端

眼镜端负责采集老人语音和第一视角画面，并通过语音播报返回结果。老人无需在眼镜端进行复杂配置，用药、饮食、找物、识人等操作都尽量通过一句自然语言触发，例如"帮我看看这个能不能吃"“我今天药吃过了吗”。

AI 眼镜的关键价值在第一视角。固定摄像头能看见房间，手环能看见体征，眼镜则能看到老人正在看的药盒、食物、照片和人物。我们的工作流围绕这一点设计：只有当任务需要当前画面时才调用图像能力，不把眼镜端设计成持续录像设备。

2.2 百宝箱/GPASS 工作流

GPASS 工作流是系统中枢，负责把老人一句话转成可执行任务。它处理的是一条完整链路：判断是否在和智能体对话，读取用户画像，判断是否需要第一视角图像，进入对应场景，调用后端接口，生成老人侧短语音回复，必要时写入记录。

2.3 后端服务

后端是工作流和家属端之间的生活记忆层。GPASS 适合做流程编排和语音交互，但不适合长期保存用药计划、服药记录、饮食历史、物品位置和人物关系。后端负责把这些信息结构化保存，并以插件形式接入工作流。

数据对象	支撑能力	说明
用户画像	饮食、用药、陪伴问答	保存年龄、健康标签、饮食忌口、专属记忆等信息
用药计划	用药防错	保存药品、剂量、服用时段和饭前饭后要求
用药记录	用药防错	保存老人确认过的服药时间、药品、剂量
饮食记录	饮食提醒	保存食物内容、时段和时间，支持家属回看
物品位置	生活找物	保存老人主动记录的物品名称和位置描述
人物档案	识人辅助	保存人脸特征、姓名、关系和备注

2.4 家属管理端

家属管理端是资料维护和事件回看入口。家属在这里维护用药计划、饮食忌口、健康标签和人物关系；老人侧在眼镜端触发任务后，系统把关键结果写回后端，家属再查看整理后的记录。这种分工降低了老人端操作负担，也避免把照护做成持续音视频监控。

3. 智能体激活流程与图像状态管理

本节说明智能体如何从一段自然语音进入稳定工作流，核心是判断是否应该响应、是否需要当前画面，以及如何管理多轮对话中的图像上下文。

3.1 对话触发控制

老人居家环境中会出现大量非指令语音。我们在总控节点先判断当前语句是否在对眼镜智能体说话，再决定是否进入业务流程。如果不是对智能体发起请求，流程直接结束，不读取图像、不调用后端。

例如老人和家属聊天时提到"今天药吃了吗"，系统不应自动进入用药判断；只有当语义中间出现"帮我看看"“我今天是不是吃过药”"这个能不能吃"等明确请求时，才继续处理。

完成触发判断后，工作流进入场景意图识别。这里采用语义路由方式，根据老人语音、历史上下文和当前图像状态共同判断下一步路径。

3.2 图像触发与变量复用

第一视角图像是伴眸的优势，但持续拍照会带来延迟、隐私问题和上下文混乱。当前工作流把图像处理拆成三种状态：

图像状态	判断依据	工作流动作
拍照	用户指向眼前对象，例如"这个药能吃吗"“这是谁”	调用眼镜设备拍照节点，并将图片地址写入 tmp_image
维持	用户围绕上一张图继续追问，例如"那它能不能吃"	不重复拍照，沿用上一轮 tmp_image
清空	话题切换，上一张图不再相关	清空或更新图像变量，避免旧图干扰

这个机制让多轮对话更自然。老人先问"这个点心我能吃吗"，系统拍照并判断；老人接着问"那我吃一小口行吗"，系统可以复用上一张图，并结合刚才的饮食判断继续回复。这样既减少了重复视觉调用，也更贴近真实使用习惯。

4. 核心场景实现

4.1 饮食健康

当老人问"这个我能吃吗"时，系统不能只识别画面里的食物，还要读取用户画像中的慢病标签、饮食忌口、过敏项、用药信息和近期饮食记录。对糖尿病老人，高糖点心和含糖饮料需要更谨慎；对高血压老人，咸菜、腌制食品和浓汤需要提醒；如果近期已经记录吃过某些食物，则会在推荐时避免重复推荐。

当前饮食工作流先读取用户用药和忌口信息，再进行二级意图识别。饮食问题被拆成五类：饮食信息询问、饮食能否食用判断、饮食推荐、饮食记录新增和饮食记录查询。

这套拆分可以避免无意义图像调用。例如，"这个饮料能喝吗"通常需要第一视角图像和包装信息；"我今天晚饭吃什么好"主要依赖用户画像和饮食偏好；"帮我记一下中午吃了面条"直接进入记录新增；"我刚吃过蛋糕，还能吃水果吗"需要读取历史饮食记录。

在能否食用判断中，第一视角图像提供食物、包装或配料表信息，用户画像提供个人化规则。系统提取高糖、高盐、高油、高嘌呤、酒精、过敏原等风险标签，再生成老人侧短语音提醒。输出必须保守，例如"这个可能偏甜，少吃一点更稳妥"，不能写成医疗诊断。

饮食记录则把一次提醒沉淀为后端数据。工作流先从语音中提取食物名称和食用时间，缺失时轻量追问；信息完整后调用后端写入记录。这样家属端后续能看到整理后的饮食事件，无需保存连续餐桌画面。

饮食场景把提前提醒和长期记录结合起来。提醒发生在老人准备吃之前，记录则用于后续追问和家属回看，使第一视角、用户画像和生活记录形成关联，而不只是单次识别食物。

4.2 用药管理

用药场景的技术重点是"计划"和"记录"分离。家属端维护用药计划，后端保存药品、剂量、服用时段和饭前饭后要求；老人侧每次确认服药后，再写入当天记录。系统判断"今天药吃了吗"时，必须同时读取这两类信息。

当前工作流进入用药场景后，先获取计划。如果没有计划，直接提示当前没有维护用药计划，不继续做无依据判断。计划存在时，再获取当天记录，并将计划和记录序列化为变量供后续判断。

用药场景主要处理以下任务：

任务	处理依据	输出策略
查询是否已服药	当前时间、今日记录、用药计划	提醒已服、未服或记录缺失
查询用药计划	结构化计划	用短句说明药品、剂量和时段
新增服药记录	老人确认、药品名称、时间	二次确认后写入记录
分析眼前药品	当前图像、计划信息、老人问题	核对可见药盒、药瓶或药片信息
药品常识问答	大模型或插件能力	只做通用常识提示，不给处方建议

用药防错这件事，主要盯的是几类最常见、也最容易出问题的情况。先看漏服提醒：如果当前这个时段原本有计划要吃的药，但当天一直没有服药记录，系统就会提示老人先核对一下药盒。再看重复服药：要是当天同一时段已经有过记录，就会明确提醒，不要再重复服用。至于疑似错服的兜底场景，如果眼前的药品和既定计划对不上，或者图像本身没法确认，系统会直接说明"不确定"，并建议查看药品标签，必要时联系家属。除此之外，系统也能回答一些常见用药问题，但定位始终很明确——只提供通用常识提醒，不会去调整处方。

4.3 生活找物

找物这件事，整体上其实就是两条路径：一条是记录位置，另一条是查找位置。比如老人说“帮我记住钥匙在这里”或者“帮我记一下我的钥匙放床头柜了”，系统会先识别出物品名称，再结合当前的第一视角画面，或者用户口头提供的描述，把这个位置信息记录下来。等到老人之后再问“我的钥匙在哪”时，系统就会根据物品名称调取对应记录，并通过语音把位置告诉老人。

找物场景强调主动记录。系统不做无差别录像，也不长期保存无关画面。后端保存物品名称、用户编号、位置描述和更新时间，并采用更新式记录策略：同一用户同一物品重复记录时更新位置，查询时先精确匹配，再模糊匹配。

4.4 人物识别与关系提示

人物识别定位为认人辅助，帮助老人在脸盲或遗忘人物关系时提供提醒。老人问"这是谁"时，系统能够给出姓名和关系以及人物记忆，并支持家属端持续维护。

人物场景先进行意图分类，分为新增人物、身份识别、信息查询和人物信息更新。底层 companioneye_face 负责人脸检测、向量提取、入库和识别；GPASS 工作流负责组织对话、选择目标人脸、生成老人侧口播和二次确认。

识别时，后端调用人脸识别能力，返回画面中检测到的人脸、姓名、关系和人物备注。之后大模型结合用户问题判断老人指向或描述的是哪一个人，再组织成适合语音播报的关系提示。

新增人物时，如果画面中有多人，工作流需要判断录入哪一个人。当前设计通过第一视角图像和大模型节点分析老人语音中的指向或方位表达，例如"左边这个"“中间这位”，或者结合手指指向选择目标人脸。方位和指向选择由 GPASS 中的多模态大模型完成，底层 Face API 负责检测、裁剪、入库和识别。

人物信息查询和更新让识别结果可以持续修正。老人或家属可以补充姓名、关系、备注；下一次识别时，播报内容随之更新。这样，人脸识别结果和家庭人物档案可以持续关联和修正。

4.5 陪伴问答

陪伴问答承担日常生活服务的陪伴和智能问答能力。老人问天气、周边服务、简单生活问题时，系统可以通过大模型和插件能力处理。同时也能陪老人聊天、讲故事或讲笑话，缓解独居时的孤独感。

当前工作流中已经接入天气查询、Bing 搜索、票务查询、周边搜索等插件入口，能够支持日常生活问答。

5. 后端技术方案：后端数据库、人脸服务与家属协同

后端技术方案的重点，是把 GPASS 工作流需要的数据、算法能力和家属维护能力组织起来。后端负责生活记忆，人脸服务负责识别能力，家属端负责长期资料维护，它们共同支撑眼镜端的即时判断。

5.1 后端生活记忆层设计

后端在方案中承担"生活记忆层"的角色。老人侧的语音交互通常很短，例如"药吃了吗"“这个能吃吗”“钥匙在哪”。如果只依赖当轮对话，系统很难给出可靠回答。后端把家属维护的长期资料、老人产生的短期记录和算法服务返回的识别结果整理成可查询数据，供 GPASS 工作流按需调用。

这层设计有几个考虑。长期资料和当轮对话分离，避免让大模型记住所有个人信息。记录以结构化摘要为主，便于后续查询和家属回看。后端只提供数据和算法结果，最终老人侧话术仍由 GPASS 工作流根据场景组织。

数据类别	设计用途	进入的工作流
用户画像	记录健康标签、忌口、偏好和专属记忆	饮食、陪伴、用药提醒
用药计划与记录	计划回答"该吃什么"，记录回答"是否吃过"	用药防错
饮食记录	沉淀饮食事件和历史追问依据	饮食提醒、家属回看
物品位置	保存老人主动记录的短期生活记忆	生活找物
人物档案	保存家庭关系和备注	人物识别、陪伴问答

5.2 插件化后端与算法服务接入

我们通过后端插件层解耦业务数据、算法接口和 GPASS 工作流。GPASS 负责流程编排和老人侧交互，后端负责保存数据、查询记录、封装算法能力，并将结果以结构化方式返回。这样后续替换数据库、人脸服务或通知插件时，不需要重写整个智能体流程。

这套结构让工作流更清晰。饮食场景不需要知道数据库表结构，只需要拿到用户忌口和饮食记录；用药场景不需要处理计划字段细节，只需要拿到计划项和今日记录；人物识别不直接接触底层人脸库，只读取后端整理后的姓名、关系和识别结果。

5.3 人脸识别服务设计

人脸识别由独立的 companioneye_face 服务承担，使用人脸检测和特征匹配完成入库、识别、搜索和更新。我们把它定位为家庭范围内的关系提示服务，而不是开放场景身份鉴定。

这里的关键在于把算法结果转成老人能理解的关系提示。老人侧需要听到"左边这位是小丽，您的女儿"这样的短句，而不是相似度、检测框和调试字段。家属端则维护姓名、关系和备注，保证识人结果能跟家庭语境保持一致。

5.4 家属端资料维护与事件级协同

家属端承担资料维护和记录回看。我们把复杂录入留给家属端，把自然语音交互留给老人端。家属维护画像、忌口、用药计划和人物关系；老人侧触发场景后，工作流读取这些资料并写回关键事件；家属再查看整理后的记录并修正资料。

家属端当前以移动端风格 Web 页面实现，主要入口包括主页、饮食、用药、关系和设置。它的定位是资料维护台和事件回看台，不作为实时监控入口。

6. 总结与创新点

我们的方案围绕 AI 眼镜第一视角和居家适老场景构建了一套工作流系统，把老人侧低负担交互、GPASS 流程编排、后端生活记忆和家属端维护连接起来。

方案的创新点集中在几个方面：

第一视角与按需图像状态管理结合：工作流会判断拍照、复用或清空图像变量，减少无效视觉调用，也避免持续采集带来的隐私压力。GPASS 工作流驱动的系统化场景联动：用药、饮食、找物、识人和陪伴问答共用用户画像、历史记录和后端记忆层，避免各场景各自运行。个性化生活记忆支撑即时判断：饮食判断读取慢病和忌口，用药判断读取计划和今日记录，人物识别读取家庭人物档案，使回答围绕具体老人展开。家属端事件级协同：家属端维护长期资料并查看整理后的关键记录，不会变成连续音视频监控，兼顾照护协同和隐私边界。

视频演示

演示视频如下：

伴眸-演示视频