参赛赛道AI 眼镜助力生产办公提效作品名称识友记AI 眼镜人脉记忆助手作品 Slogan见过的人不再忘记摘要在商务会议、行业展会、客户拜访、团队协作和日常社交中用户经常会遇到“见过这个人但想不起姓名、身份或上次交流内容”的问题。手机通讯录只能在用户已经知道对方姓名时提供检索而普通人脸识别工具通常只完成“识别是谁”无法继续承载人物关系、交谈内容和后续维护。“识友记”是一款运行于 Rokid AI 眼镜上的人脉记忆智能体。用户通过眼镜主动拍摄面前的人系统调用云端人脸识别服务判断该人物是否已经录入若匹配成功则返回姓名、身份和历史备注若未匹配则在用户明确确认后将该人物录入人物库。用户还可以通过语音补充人物信息、浏览人物库以及在二次确认后删除人物。系统由百宝箱低代码工作流、Rokid 端侧拍照能力、自研人脸记忆插件以及阿里云人脸识别、对象存储和表格存储共同组成。该方案不是把手机应用简单迁移到眼镜而是利用第一视角、随身佩戴和免手持交互让用户在真实见面场景中即时获得人物记忆辅助。1. 项目背景与用户痛点1.1 现实问题在高频社交和商务场景中用户需要同时记住大量人物信息例如对方姓名和所属公司对方的职位与合作方向上次见面的时间和地点已经讨论过的话题后续需要跟进的事项。这些信息通常分散在通讯录、聊天记录、备忘录和个人记忆中。再次见面时用户很难在短时间内完成检索容易出现叫错姓名、忘记身份或重复询问的尴尬。1.2 为什么需要 AI 眼镜传统手机方案要求用户掏出手机、打开应用、输入姓名或翻找记录。但在面对面交流中这类操作会打断沟通也要求用户预先知道对方是谁。AI 眼镜具备三个天然优势第一视角输入用户正在看谁眼镜就可以拍摄谁。免手持交互用户可通过镜腿操作或语音触发不需要拿出手机。即时信息呈现识别结果可以在真实交流现场返回减少检索时间。因此“人物记忆”并不是普通手机功能的简单迁移而是适合由 AI 眼镜承担的原生场景。图 1 Rokid AI 眼镜第一视角人物识别实机效果2. 产品定位与核心功能“识友记”的产品定位是面向商务会议、展会、客户拜访和日常社交的 AI 眼镜人脉记忆助手。系统围绕“认识—记住—补充—回忆—管理”构建完整闭环。2.1 核心功能功能用户表达示例系统行为识别人物“看看他是谁”拍照并搜索人脸库返回姓名和备注录入人物“记住这个人”经确认后录入人脸、照片和人物档案补充信息“他叫张三是产品经理”更新刚录入或指定人物的姓名和备注浏览人物库“打开人物库”分页展示已录入人物删除人物“删除张三”先查询并展示人物卡片二次确认后删除2.2 产品边界当前比赛版本采用“用户主动触发拍照”的方式不进行后台持续拍摄也不做实时视频流框选。这样可以降低功耗和延迟同时避免在用户未感知的情况下采集他人影像。当前版本主要处理一张照片中的主要人脸。多张人脸同时出现时建议用户靠近目标人物后重新拍摄。3. 系统总体架构系统由端侧、工作流层、插件层和云服务层四部分构成。Rokid AI 眼镜 │ │ 主动拍照 / 语音输入 / 镜腿操作 ▼ 百宝箱智能体工作流 │ │ 意图识别、变量传递、条件分支、结果展示 ▼ 自研“人脸记忆服务”插件 │ ├── recognize_face ├── enroll_person ├── update_person ├── browse_person └── delete_person │ ▼ 阿里云服务 ├── 人脸人体服务上海人脸录入、搜索与删除 ├── OSS 对象存储北京保存人物封面照片 └── Tablestore北京保存人物资料、上下文和业务索引3.1 端侧端侧由 Rokid AI 眼镜和 Rokid App 中的智能体调试/预览入口共同组成。手机端不是独立的小程序或独立 App而是用于启动、调试和预览百宝箱智能体核心使用动作仍由眼镜完成。3.2 工作流层百宝箱工作流负责获取用户语音或文字输入判断用户意图调用端侧拍照能力将图片 URL 传入自研工具根据工具返回的状态码进入不同分支生成文字或人物卡片接收用户二次确认。3.3 插件层自研插件将云服务封装为面向业务的工具。工作流不需要直接处理阿里云签名、SDK 调用、数据库主键或 OSS 对象路径只需要调用统一工具并读取标准化输出。3.4 云服务层人脸人体服务维护人脸数据库完成录入、搜索和删除。OSS保存人物封面照片默认使用私有读写权限。Tablestore保存结构化人物信息和跨会话上下文。图 2 识友记系统总体架构4. 插件与工具设计比赛版本共接入两类能力GPASS/Rokid 官方端侧能力负责眼镜拍照和输入交互。自研“人脸记忆服务”插件封装人物识别、录入、更新、浏览和删除。将多个业务动作拆成不同工具而不是全部写入一个超大接口主要有以下原因每个工具职责单一便于单独调试工作流可以按意图选择工具减少不必要调用输入输出更加明确删除等高风险操作可以单独加入确认流程后续新增功能时不需要重写整个插件。图 3 自研插件及五个核心人物管理工具5. 数据模型设计系统使用统一的entity_id作为人物唯一标识。姓名、备注、照片和人脸特征都通过entity_id关联而不是使用姓名作为数据库主键。5.1 人物档案表persons主键字段类型说明owner_idString当前用户标识entity_idString人物唯一编号同时关联人脸库实体主要属性字段说明name人物姓名note职业、关系、交流内容等备注profile_statusPENDING_PROFILE或ACTIVEface_id人脸服务返回的人脸编号quality_score录入照片质量分cover_oss_keyOSS 中封面照片路径created_at创建时间updated_at最近更新时间5.2 用户上下文表user_context该表用于保存跨工作流上下文例如字段说明owner_id当前用户标识last_enrolled_entity_id最后一次成功录入的人物last_enrolled_at最后录入时间pending_delete_entity_id等待二次确认删除的人物pending_delete_expires_at删除确认状态的过期时间通过last_enrolled_entity_id用户即使关闭当前流程也可以继续说“给刚才认识的人补充信息”。5.3 业务索引或日志数据为支持按姓名查询、操作追踪和异常排查系统可以维护人物索引或操作日志记录。删除人物时需要同步清理与该entity_id关联的业务记录避免出现人物已删除但索引仍存在的情况。图 4user_context表保存最后录入人物等跨会话状态图 5persons表保存人物编号、照片、姓名和备注6. 核心工作流设计6.1 意图入口用户进入智能体后系统先获取用户表达再由意图识别节点分流。主要意图包括意图示例表达识别人物“识别这个人”“看看他是谁”录入人物“记住这个人”“把他加到人物库”补充信息“给刚才那个人补充信息”浏览人物“打开人物库”“看看我记住的人”删除人物“删除张三”“把这个人删掉”意图未匹配时系统提示用户可以执行识别、录入、补充、浏览或删除人物而不是直接进入某个工具。图 6 百宝箱智能体完整工作流总览图 7 意图识别入口及人物识别、补充、浏览等路由配置7. 人物识别流程人物识别是系统的主入口。用户说“看看他是谁” → 提示用户看向目标人物 → 用户单击镜腿触发拍照 → 获取 image_url → 调用 recognize_face → 根据 code 分支 ├── MATCH展示姓名和备注 ├── MATCH_PENDING提示资料待补充 ├── UNKNOWN询问是否录入 └── ERROR提示重新拍照或稍后重试7.1recognize_face输入参数类型必填来源image_urlString是眼镜拍照节点输出access_key_idString是隐藏参数access_key_secretString是隐藏参数7.2recognize_face输出参数说明success技术调用是否成功code业务状态码message返回说明entity_id匹配人物编号name姓名note备注confidence匹配置信度profile_status人物资料状态cover_oss_key封面照片路径has_profile是否已有姓名或备注7.3 状态处理MATCH展示人物卡片。MATCH_PENDING说明系统见过该人物但尚未补充姓名或备注。UNKNOWN只表示没有找到可靠匹配需要用户确认后才能录入。ERROR表示技术调用失败不应误进入录入分支。图 8 人物识别工具与MATCH、UNKNOWN、MATCH_PENDING、异常分支图 9 人物识别成功后在眼镜端显示姓名与身份信息8. 陌生人物录入流程系统不会自动保存陌生人的人脸。只有在识别结果为UNKNOWN且用户明确回答“记住他”后才调用enroll_person。recognize_face 返回 UNKNOWN → 系统询问“没有找到这个人是否加入人物库” → 用户确认 → 复用同一张照片的 image_url → 调用 enroll_person → 创建 entity_id → 上海人脸库录入人脸 → 北京 OSS 保存封面照片 → persons 写入人物档案 → user_context 保存最后录入人物 → 返回 ENROLLED8.1enroll_person输入参数类型必填image_urlString是access_key_idString是隐藏access_key_secretString是隐藏8.2 主要输出参数说明codeENROLLED、LOW_QUALITY、DUPLICATE_FACE等entity_id新人物唯一编号face_id人脸编号quality_score图片质量分profile_status初始为PENDING_PROFILEcover_oss_keyOSS 封面照片路径8.3 一致性与回滚录入过程会依次写入多项云资源。如果中间步骤失败工具会尽量回滚已创建的资源例如人脸已创建但 OSS 上传失败删除本次人脸实体OSS 已上传但人物表写入失败删除 OSS 对象和人脸实体人物表已写入但上下文保存失败删除本次人物档案、OSS 对象和人脸实体。这种设计可以避免“人脸库有记录但人物表没有资料”或“OSS 留有孤立照片”等半成功状态。图 10 未知人物录入及ENROLLED、DUPLICATE_FACE、LOW_QUALITY状态处理9. 人物信息补充与更新新录入的人物初始状态为PENDING_PROFILE。用户可以在交谈后通过自然语言补充信息例如“他叫张三是某公司的产品经理上次在深圳展会认识。”系统将姓名和备注传入update_person。9.1 两种目标定位方式方式一更新最后录入的人target_mode LAST_ENROLLED entity_id 空工具从user_context读取last_enrolled_entity_id。方式二更新指定人物target_mode ENTITY_ID entity_id recognize_face 或 browse_person 返回的编号9.2 输入参数参数说明target_modeLAST_ENROLLED或ENTITY_IDentity_id指定人物时必填name新姓名可为空note新备注可为空姓名和备注至少提供一项。未传入的字段保留原值不会因为本次只修改备注而清空姓名。9.3 资料状态人物有姓名或备注后profile_status更新为ACTIVE并同步刷新updated_at。10. 人物库浏览与分页用户说“打开人物库”后工作流调用browse_person。10.1 输入参数参数默认值说明status_filterALLALL、PENDING_PROFILE、ACTIVEpage_size5每页人物数量cursor空下一页时传入上次返回的next_cursor10.2 输出参数参数说明display_text可直接展示的文字列表persons_json本页人物 JSON 数据count本页数量next_cursor下一页游标has_more是否还有下一页first_entity_id第一个人物编号first_name第一个人物姓名first_note第一个人物备注first_cover_url临时签名照片 URLOSS 照片为私有对象浏览工具只在需要展示时生成短期有效的签名 URL不将 Bucket 设置为公共读。10.3 眼镜端翻页MVP 版本优先使用语音“下一页”或工作流按钮触发分页。后续可以将镜腿滑动事件映射为分页变量再把next_cursor传回browse_person实现卡片式浏览。图 11 人物库在 Rokid AI 眼镜端的列表展示效果11. 安全删除流程删除属于高风险操作因此不能在用户第一次说出“删除张三”时直接执行。delete_person采用“查询—展示—二次确认—执行删除”的安全流程。11.1 三阶段动作动作作用LOOKUP根据姓名查询人物不执行删除DELETE读取待确认目标并执行删除CANCEL取消删除并清理待确认状态11.2 删除流程用户说“删除张三” → 意图识别进入删除分支 → delete_person(actionLOOKUP, name张三) → 查询 persons → 返回张三的人物卡片 → user_context 暂存待删除 entity_id设置短时有效期 → 系统询问“是否要删掉这个人” ├── 用户说“删掉” → actionDELETE └── 用户说“取消” → actionCANCEL11.3 执行删除时清理的资源确认删除后系统按entity_id清理上海人脸数据库中的人物实体和人脸特征OSS 中对应的人物封面照片persons中的人物档案user_context中指向该人物的最近人物或待删除状态与该人物相关的业务索引或日志记录。待删除状态设置短时有效期过期后即使用户再说“删掉”系统也会要求重新查询人物避免误删上一次对话中的目标。11.4 同名人物处理当存在多个同名人物时工具不直接删除而是返回候选人物列表要求用户通过备注、照片或人物编号进一步确认。12. 端侧与云端插件协同12.1 端侧负责什么接收语音或镜腿操作主动拍照将图片转换为工作流可用的 URL展示文本或人物卡片接收用户确认、取消和翻页操作。12.2 云端负责什么调用人脸识别 SDK完成签名和鉴权生成及维护entity_id读写人物档案和上下文保存、签名和删除 OSS 照片处理跨资源事务与回滚将复杂错误转换为工作流可以判断的状态码。这种划分让眼镜端保持轻量不需要在端侧部署大型人脸识别模型同时让百宝箱工作流专注于用户交互和业务编排。13. 状态码与异常处理系统不依赖大模型猜测工具结果而是使用明确状态码进行条件分支。13.1 识别相关状态码含义MATCH匹配成功且资料完整MATCH_PENDING人脸存在但资料待补充UNKNOWN未找到可靠匹配ERROR调用异常13.2 录入相关状态码含义ENROLLED录入成功LOW_QUALITY照片质量不足DUPLICATE_FACE可能重复录入INVALID_IMAGE图片不可读取OSS_SAVE_FAILED照片保存失败PROFILE_SAVE_FAILED人物档案保存失败CONTEXT_SAVE_FAILED上下文保存失败13.3 更新相关状态码含义UPDATED更新成功NO_RECENT_PERSON没有最近录入人物PERSON_NOT_FOUND目标人物不存在MISSING_UPDATE没有提供姓名或备注INVALID_TARGET目标模式错误13.4 浏览和删除相关状态码含义OK查询成功EMPTY人物库为空CANDIDATE_FOUND找到待删除人物等待确认MULTIPLE_MATCHES存在多个同名人物DELETED删除完成CANCELED已取消删除PENDING_EXPIRED删除确认已过期14. 隐私、安全与合规设计人脸数据属于高度敏感的数据类型因此项目在产品和技术层面均加入约束。14.1 用户主动触发系统不在后台持续拍摄只有用户主动点击镜腿或明确发出识别指令时才采集照片。14.2 明确确认后录入识别为陌生人时系统只询问是否录入不自动保存。用户明确同意后才调用enroll_person。14.3 删除前二次确认删除操作先展示目标人物信息用户再次说“删掉”后才执行。14.4 私有对象存储OSS 中的人物照片保持私有权限浏览时只生成短期签名 URL不公开整个 Bucket。14.5 密钥保护AccessKey 通过工具隐藏参数注入不写入普通业务参数、提示词、截图或公开博客。公开技术文档中不展示真实密钥、完整 Endpoint、账号 ID 和内部签名。14.6 用户数据隔离数据模型预留owner_id。比赛演示阶段使用固定测试用户正式产品化时应将 Rokid 平台用户身份映射为独立owner_id保证不同用户的人物库完全隔离。15. 性能与部署考虑当前云服务部署为人脸识别服务上海OSS 和 Tablestore北京。一次识别的主要耗时通常来自眼镜照片上传云端下载或转发图片人脸推理结果返回眼镜。Tablestore 读取单条人物资料的耗时占比较小。比赛阶段优先保证功能稳定不进行跨地域迁移。后续可通过以下方式优化将 OSS、Tablestore 与人脸服务部署到同一地域压缩眼镜拍摄图片但保留足够人脸清晰度记录各阶段耗时定位真正瓶颈对临时签名 URL 和人物资料进行短时缓存避免在一次流程中重复下载同一张图片。16. Demo 演示流程建议比赛 Demo 按以下顺序录制能够完整展示产品闭环。场景一识别已知人物用户启动智能体说“看看他是谁”单击镜腿拍照系统显示姓名和历史备注。场景二录入陌生人物拍摄一个未录入的测试人物系统提示“没有找到这个人是否加入人物库”用户回答“记住他”系统返回“已录入”。场景三补充资料用户说“他叫张三是产品经理”系统更新最后录入人物再次识别显示姓名和备注。场景四浏览人物库用户说“打开人物库”系统展示人物列表或卡片用户说“下一页”或滑动镜腿完成翻页。场景五安全删除用户说“删除张三”系统展示张三的人物卡片系统询问是否确认删除用户回答“删掉”系统返回删除成功再次识别该人物时返回未知。17. 项目创新点17.1 从“识别人脸”升级为“记忆关系”系统不仅返回姓名还保存身份、关系、交谈内容和后续备注形成可持续维护的人物记忆。17.2 AI 眼镜原生交互用户面对真实人物时即可触发识别无需先知道姓名也无需掏出手机检索。17.3 低代码工作流与云服务组合百宝箱负责意图理解和流程编排自研工具负责云端能力封装使复杂的人脸识别、存储和事务逻辑可以被低代码节点调用。17.4 跨会话上下文user_context保存最后录入人物使“给刚才那个人补充信息”在工作流重新打开后仍然可用。17.5 高风险操作保护录入必须明确同意删除必须二次确认同名人物必须再次选择降低误录入和误删除风险。18. 商业价值与应用场景18.1 行业展会销售或创业者在展会中认识大量客户眼镜可以帮助记录对方身份、需求和跟进事项。18.2 客户拜访再次见到客户时系统可以提示上次讨论内容帮助销售人员快速进入沟通状态。18.3 企业会议与接待新员工、跨部门成员或大型活动参与者可以通过眼镜辅助回忆对方姓名和职责。18.4 高频社交职业适用于投资人、记者、咨询顾问、活动组织者、社区运营人员等需要管理大量弱关系的人群。未来可探索企业订阅、私有化部署、CRM 对接和团队共享人物库等商业模式。19. 当前边界与后续规划当前比赛版本已经形成“识别—录入—补充—浏览—删除”的完整闭环但仍有以下扩展方向将固定演示用户升级为正式多用户隔离支持一个人物录入多张不同角度照片增加标准头像裁剪和图片质量增强支持姓名模糊搜索和标签筛选将镜腿滑动与卡片分页深度结合增加操作日志和分阶段延迟监控对接 CRM、企业通讯录和日程系统加入数据导出、授权共享和定期清理功能。20. 总结“识友记”围绕真实见面场景将 Rokid AI 眼镜的第一视角输入、低代码工作流编排和云端人脸识别能力结合起来解决用户“见过但想不起来”的高频问题。项目的核心价值不在于单次人脸匹配而在于建立一套可以持续录入、补充、回忆、浏览和删除的人物记忆系统。通过用户主动触发、录入确认、删除二次确认、私有照片存储和统一人物标识系统在可用性与数据安全之间取得平衡。见过的人不再忘记。