识友记：基于 Rokid AI 眼镜的人脉记忆智能体设计与实现-平芜编程栈

参赛赛道：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_id`	String	当前用户标识
`entity_id`	String	人物唯一编号，同时关联人脸库实体

主要属性：

字段	说明
`name`	人物姓名
`note`	职业、关系、交流内容等备注
`profile_status`	`PENDING_PROFILE`或`ACTIVE`
`face_id`	人脸服务返回的人脸编号
`quality_score`	录入照片质量分
`cover_oss_key`	OSS 中封面照片路径
`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.1`recognize_face`输入

参数	类型	必填	来源
`image_url`	String	是	眼镜拍照节点输出
`access_key_id`	String	是	隐藏参数
`access_key_secret`	String	是	隐藏参数

7.2`recognize_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 保存最后录入人物 → 返回 ENROLLED

8.1`enroll_person`输入

参数	类型	必填
`image_url`	String	是
`access_key_id`	String	是，隐藏
`access_key_secret`	String	是，隐藏

8.2 主要输出

参数	说明
`code`	`ENROLLED`、`LOW_QUALITY`、`DUPLICATE_FACE`等
`entity_id`	新人物唯一编号
`face_id`	人脸编号
`quality_score`	图片质量分
`profile_status`	初始为`PENDING_PROFILE`
`cover_oss_key`	OSS 封面照片路径

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_mode`	`LAST_ENROLLED`或`ENTITY_ID`
`entity_id`	指定人物时必填
`name`	新姓名，可为空
`note`	新备注，可为空

姓名和备注至少提供一项。未传入的字段保留原值，不会因为本次只修改备注而清空姓名。

9.3 资料状态

人物有姓名或备注后，profile_status更新为ACTIVE，并同步刷新updated_at。

10. 人物库浏览与分页

用户说“打开人物库”后，工作流调用browse_person。

10.1 输入参数

参数	默认值	说明
`status_filter`	`ALL`	`ALL`、`PENDING_PROFILE`、`ACTIVE`
`page_size`	`5`	每页人物数量
`cursor`	空	下一页时传入上次返回的`next_cursor`

10.2 输出参数

参数	说明
`display_text`	可直接展示的文字列表
`persons_json`	本页人物 JSON 数据
`count`	本页数量
`next_cursor`	下一页游标
`has_more`	是否还有下一页
`first_entity_id`	第一个人物编号
`first_name`	第一个人物姓名
`first_note`	第一个人物备注
`first_cover_url`	临时签名照片 URL

OSS 照片为私有对象，浏览工具只在需要展示时生成短期有效的签名 URL，不将 Bucket 设置为公共读。

10.3 眼镜端翻页

MVP 版本优先使用语音“下一页”或工作流按钮触发分页。后续可以将镜腿滑动事件映射为分页变量，再把next_cursor传回browse_person，实现卡片式浏览。

图 11 人物库在 Rokid AI 眼镜端的列表展示效果

11. 安全删除流程

删除属于高风险操作，因此不能在用户第一次说出“删除张三”时直接执行。delete_person采用“查询—展示—二次确认—执行删除”的安全流程。

11.1 三阶段动作

动作	作用
`LOOKUP`	根据姓名查询人物，不执行删除
`DELETE`	读取待确认目标并执行删除
`CANCEL`	取消删除并清理待确认状态

11.2 删除流程

用户说“删除张三” → 意图识别进入删除分支 → delete_person(action=LOOKUP, name=张三) → 查询 persons → 返回张三的人物卡片 → user_context 暂存待删除 entity_id，设置短时有效期 → 系统询问“是否要删掉这个人？” ├── 用户说“删掉” → action=DELETE └── 用户说“取消” → action=CANCEL

11.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 眼镜的第一视角输入、低代码工作流编排和云端人脸识别能力结合起来，解决用户“见过但想不起来”的高频问题。

项目的核心价值不在于单次人脸匹配，而在于建立一套可以持续录入、补充、回忆、浏览和删除的人物记忆系统。通过用户主动触发、录入确认、删除二次确认、私有照片存储和统一人物标识，系统在可用性与数据安全之间取得平衡。

见过的人，不再忘记。

摘要