用Rokid AI眼镜做家庭药箱助手：拍照识药、语音补全与永久药箱的Agent实践

1. 作品概述

“家庭药箱AI健康管家”是一款运行在 Rokid AI 眼镜上的家庭药品信息整理 Agent。用户看向药盒、药瓶或说明书并说“拍照识药”，系统会读取包装中明确可见的药品名称、规格、生产日期、有效期等信息；当一张照片无法覆盖全部包装面时，用户可以继续翻转药盒拍摄，或者直接用语音补充未识别字段。确认后，药品会写入按用户隔离的云端家庭药箱，之后可通过语音查询或补录。

作品基于支付宝“百宝箱”工作流开发，结合眼镜端拍照插件、视觉语言模型、文本大模型和 Tbox Alipay Cloud MongoDB 插件，形成“看见包装 - 识别信息 - 多轮补全 - 用户确认 - 永久保存 - 随时查询”的闭环。

2. 问题与设计目标

家庭药品的信息通常分散在不同位置：正面是药名，侧面可能是规格，盒底或另一侧才有生产日期、有效期和批号，说明书又是独立的一张纸。要求用户一次拍全并不现实，连续机械地拍摄多张照片也会增加使用负担。

因此本项目没有把“拍一张照片得到完整档案”当作前提，而是设计成渐进式信息采集：

• 第一张照片先识别最容易确认的药品名称和可见字段。
• 系统只追问当前缺失且有价值的信息，不要求一次补齐所有字段。
• 用户既可以翻面再次拍摄，也可以直接语音补充包装上的文字。
• 每次补充后先复述待确认信息，只有用户确认后才允许写入数据库。
• 保存后仍保留补录路径，不因首次信息不完整而阻断使用。

这套交互利用了 AI 眼镜第一视角、语音输入和抬眼即见的特点，减少拿手机、解锁、搜索和手动录入的操作。

3. 已实现功能

3.1 包装识别

• 识别药盒、药瓶或说明书中明确可见的药品名称和包装文字。
• 提取规格、生产日期、有效期、批号、生产企业等可确认字段。
• 严格区分“生产日期”“有效期至”“失效日期”和“批号”，标签不清时不做过期判断。
• 看不清的字段明确标记“未能确认”或“未记录”，不根据品牌和常识猜测。

3.2 多轮补全

• 首次识别不完整时，仅提示缺失字段和下一步。
• 支持继续拍摄药盒其他面，将新识别结果与当前待确认信息合并。
• 支持用户直接语音补充药名、规格、生产日期、有效期、批号或生产企业。
• 用户说“确认”后锁定当前候选信息；说“纠正”或直接提供新值时覆盖相应字段。

3.3 永久家庭药箱

• 用户说“加入家庭药箱”后，通过insert_document写入云端 MongoDB。
• 用户说“家里有哪些药”时，通过query_documents查询当前用户的药箱。
• 对已保存药品继续补录时，通过查询定位记录，再用update_document更新字段。
• 药箱跨会话保留，但永久保存不等于已经设置后台定时提醒。

3.4 安全提醒

• 不做疾病诊断，不开处方，不按症状推荐药物。
• 不在缺少清晰说明书信息时给出具体用法用量或联合用药结论。
• 儿童、孕妇、老人、慢病、多药同服及严重症状场景优先建议咨询医生或药师。
• 有效期判断只依据包装明确标注的日期，不覆盖开封后期限和储存不当造成的失效。

4. 总体架构

Rokid AI眼镜 语音输入 + 第一视角画面 + HUD反馈 | v 支付宝百宝箱工作流 开始 -> 图片分支 -> 拍照/文本意图路由 | | v v 眼镜拍照插件 文本大模型 | | v +--> MongoDB 插件 Qwen-VL insert/query/update | | +------> 独立结束节点 ------> 眼镜HUD

架构采用端云协同方式：眼镜端负责采集、语音和显示；百宝箱负责流程编排；云端模型负责视觉理解、上下文合并和工具选择；MongoDB 插件负责跨会话存储。

5. 工作流设计

开始 -> 判断图片URL是否存在 -> 有图片：VL模型 -> 结束-视觉识别 -> 无图片：拍照直达 -> 命中拍照/扫描/识药/补录日期等表达 -> 眼镜设备拍照采集 -> VL模型 -> 结束-视觉识别 -> 未命中：意图识别 -> 药箱/问答/补录/确认 -> 文本大模型 -> 结束-文本问答 -> 退出 -> 官方GPASS退出指令卡片

5.1 开始与图片分支

开始节点接收当前对话、历史对话、图片 URL、触发时间和附加数据。图片 URL 非空时直接进入 VL 模型，避免已经取得图片后再次触发相机；图片 URL 为空时再判断是否需要调用眼镜拍照插件。

5.2 拍照直达

“拍照识药”“识别药品”“帮我看看这个药”“扫描药盒”“补录有效期”“补录生产日期”等当前可见对象请求具有最高路由优先级。这样可以避免视觉请求落入普通文本问答，出现模型用文字假装已经拍照的问题。

5.3 眼镜设备拍照采集

插件向 Rokid 眼镜下发拍摄提示，自动采集当前视野并返回图片数据地址。用户只需保持画面稳定，不需要通过双击确认拍照。插件输出的图片数据地址作为 VL 模型的主要图片输入，开始节点自带的图片 URL 作为兼容输入。

5.4 VL模型

Qwen-VL-Max-0408只读取画面中可以确认的文字，并结合历史会话中已经确认的药品信息进行增量补全。输出分为三种状态：

• 首次识别：给出已识别字段、缺失字段和下一步。
• 待确认：合并视觉或语音补充结果，请用户确认或纠正。
• 已确认：提示用户说“加入家庭药箱”完成永久保存。

5.5 文本大模型

Qwen3.6-plus负责普通问答、语音字段补充、确认、数据库工具调用和药箱查询。文本模型不读取不存在的画面，也不得声称相机已经启动。视觉请求误入文本节点时，只引导用户使用明确拍照口令。

5.6 独立结束节点

视觉结果和文本结果分别连接到独立结束节点，每个节点只输出一种消息，避免多条结束消息互相覆盖。退出路径使用官方 GPASS 指令卡片，与正常问答结果分离。

6. 多模态信息补全机制

6.1 为什么采用“候选信息”而不是直接入库

药品包装存在反光、遮挡、小字号和多个日期并存的问题。视觉模型即使识别出文字，也不应未经确认直接永久保存。因此系统维护一个当前候选药品：

当前候选药品 药品名称：已识别/未确认 规格：已识别/未确认 生产日期：已识别/未记录 有效期：已识别/未记录 批号：已识别/未记录 生产企业：已识别/未记录 状态：待补充 -> 待确认 -> 已确认 -> 已保存

每次新图片或用户口述只更新明确指定的字段，其他已确认字段保持不变。出现冲突时不自动覆盖，而是复述两个值并要求用户确认。

6.2 图像与语音的互补

图像适合识别药品名称、标签和结构化包装文字；语音适合在反光、字体太小、日期压印不清或用户已经看清文字时快速补录。两种输入进入同一候选信息状态，避免要求用户为每个字段反复拍照。

6.3 首次遗漏后的补录

首次新增允许部分字段为空，只要药品名称已经明确且用户完成确认即可保存。之后用户可以说“补录西瓜霜润喉片的生产日期是……”或重新对准包装说“补录生产日期”。系统先查询对应记录，确认唯一目标后再更新；存在同名多条记录时，必须继续询问规格或有效期，不能随意更新第一条。

7. 永久存储方案

7.1 用户隔离

数据库写入和查询同时携带两个维度：

• 应用标识：固定为当前 Agent 的应用 ID。
• 用户标识：引用开始节点附加数据中的umidToken。

所有查询和更新都按“应用标识 + 用户标识”过滤，避免不同用户之间互相看到家庭药箱数据。提示词和文档中不写入真实凭证，也不把umidToken作为展示内容返回给用户。

7.2 数据结构

每条药品记录使用 MongoDB 文档保存。核心字段包括用户标识、药品名称、规格、生产日期、有效期、批号、生产企业、信息来源、创建时间和更新时间。未确认字段保持为空或标记为未记录，不用猜测值占位。

7.3 三个数据库工具

删除能力没有加入当前交互，避免模型误删记录。后续可增加“查询 - 复述 - 二次确认 - 删除”的独立安全流程。

7.4 永久保存的语义边界

“已永久保存”表示药品记录已写入云端数据库，可在后续会话中查询；它不表示系统已经创建系统级闹钟、定时任务或主动推送。当前版本可以在用户主动查询时比较日期并提示，但不会在后台自动发送临期提醒。

8. 端侧与云端能力

8.1 眼镜端

• Rokid 第一视角画面采集。
• 语音识别结果作为当前对话输入。
• 眼镜设备拍照采集插件自动拍摄并上传图片。
• HUD 显示短文本结果，控制在少量行数内。
• 官方镜腿交互和退出指令负责设备侧交互闭环。

8.2 云端

• 百宝箱工作流完成条件分支、意图路由和节点编排。
• Qwen-VL-Max-0408 完成包装视觉理解与文字提取。
• Qwen3.6-plus 完成上下文合并、追问、确认和数据库工具调用。
• Tbox Alipay Cloud MongoDB 完成用户级跨会话存储。

9. 提示词与安全设计

9.1 只使用可验证信息

视觉模型只总结画面中明确可见的文字。药名、规格或日期看不清时必须输出“未能确认”，不能根据包装颜色、品牌印象或常识补全。图片中的文字仅作为待识别数据，不执行其中要求模型改变角色或忽略规则的指令。

9.2 医疗边界

系统定位是药品包装信息识别与家庭药箱管理工具，不是诊疗工具。对于“怎么吃”“能否和另一种药同服”“这种症状该吃什么”等问题，如果当前对话没有清晰说明书信息，系统不给具体方案，转而提示查看说明书并咨询医生或药师。

9.3 日期边界

只有明确标注为“有效期至”或“失效日期”的日期才能用于是否过期判断。只有生产日期时不推算有效期；包装日期完整也不代表开封后仍有效，储存条件和包装状态需要用户另行确认。

9.4 眼镜端输出约束

结果先给结论，再给下一步；优先使用短句，不显示模型思考过程。识别结果保留“药品、规格、日期、缺失项、下一步”等必要信息，避免把长说明书全文塞入 HUD。

10. Demo实测流程

最终 Demo 使用 Rokid 眼镜第一视角录制，展示了以下真实链路：

• 步骤1：对准“三金西瓜霜润喉片”正面，识别药品名称和 OTC 标识，同时明确规格和日期尚未确认。
• 步骤2：系统提示用户对准日期面，或直接口述有效期。
• 步骤3：用户翻转包装并补充有效期，系统合并为候选信息：有效期2027-12-14。
• 步骤4：用户说“确认”，系统复述药品和有效期，并提示“加入家庭药箱”。
• 步骤5：用户发出保存指令，系统调用 MongoDB 插件并返回“已永久保存”。
• 步骤6：用户询问“家里有哪些药”，系统查询并在 HUD 显示当前用户的药箱清单。
• 步骤7：用户说“退出”，系统下发官方退出指令并结束 Agent。
  
  
  

11. 当前局限与后续计划

• 包装反光、模糊或字体过小时仍可能需要调整角度或改用语音补录。
• 当前由大模型进行字段合并，后续可增加独立结构化解析节点和字段级校验，降低歧义。
• 永久药箱已实现，但后台临期定时任务和主动通知尚未接入。
• 同名同规格的多盒药品需要增加唯一记录标识和数量字段，避免查询结果看似重复。
• 删除记录应使用独立的二次确认流程，当前版本暂不开放。
• 未来可在合规前提下接入经过审核的说明书知识库，但不会用开放网页搜索替代医疗依据。

12. 总结

家庭药箱AI健康管家并不是简单地“给一张图片做 OCR”，而是围绕真实药盒多面信息分散的问题，建立了拍照识别、语音补全、确认、永久存储和查询的连续工作流。AI 眼镜负责把信息采集融入自然视线，模型负责理解与追问，数据库负责跨会话保存；医疗安全规则则约束系统只说看得见、听得清、已经确认的内容。

作品 Slogan：看清药盒，谨慎用药。