名片记忆助手开发全记录：Rokid AI Glasses 智能体从架构设计到功能落地

---

一、Rokid AI Glasses 能力全景与名片记忆助手的产品定位

1.1 行业背景：国补政策开启 AR 眼镜新纪元

2026 年，智能眼镜正式纳入国家消费品以旧换新补贴范围，成为继手机、平板之后又一进入国补序列的消费电子品类。这一政策信号的意义远不止于降低购买门槛——它标志着 AR+AI 可穿戴设备从早期采用者市场向大众消费市场的正式迈进，也意味着智能眼镜的潜在用户规模将在未来两到三年内迎来跨越式增长。

从市场数据来看，2025 年全球 AR 眼镜出货量已突破 500 万台，国内市场同比增速超过 60%。随着国补政策落地，业内普遍预测 2026 年国内智能眼镜市场规模将突破百亿元。硬件普及的加速，直接带动了对智能体应用生态的强烈需求——设备卖出去之后，用户需要真正有价值的应用才能让设备从"新鲜玩具"变成"日常工具"。

对于开发者而言，这是一个难得的时间窗口。平台用户基数正在快速增长，但生态内的优质应用还处于相对稀缺的阶段。在这个节点入场，做好一个垂直场景的智能体，远比在成熟平台上做同质化竞争更有价值。正是基于这样的判断，选择在 Rokid 灵珠平台上开发名片记忆助手。

1.2 设备能力概述

Rokid AI Glasses 是一款集 AI 助手、视觉感知与日常交互于一体的智能眼镜设备。从硬件层面来看，设备内置摄像头、扬声器与麦克风阵列，支持拍照、录像等视觉输入能力；从软件层面来看，用户通过唤醒词"乐奇"即可激活 AI 助手，底层对接了 DeepSeek、通义千问、豆包、智谱等主流大语言模型，具备较强的自然语言理解与生成能力。

在原生功能方面，Rokid AI Glasses 已覆盖实时翻译、提词器、高德导航、支付宝支付、直播推流、慧眼辅助（面向视障人群）等核心场景。这些能力构成了设备的基础功能层，也是第三方开发者规划智能体时需要明确区分的边界——已有的功能不应重复开发，开发者的价值在于发现系统尚未覆盖的真实需求，并通过智能体形式将其落地。

1.3 痛点发现：社交场合的认知负荷

商务社交是一个高频却低效的场景。在会议、行业展会、沙龙活动等场合，一天之内遇见十几位初识面孔并不罕见。名片可以快速交换，但记忆无法同步更新。一个月后在另一个场合再次遇到同一个人，大脑往往只能检索出模糊的轮廓——"这个人好像在哪见过"——却想不起对方的姓名、公司，更无从提及上次谈到的合作方向。

这种"忘名尴尬"不仅影响社交体验，在某些场合还会造成实质性的商务损失。现有的解法通常是手机通讯录备注或名片管理 App，但这类工具存在一个共同的缺陷：需要用户主动打开设备查阅，而在面对面交谈的当下，掏出手机翻找联系人本身就是一种失礼。

智能眼镜的形态天然契合这一场景。佩戴设备的用户可以在保持眼神接触的同时，通过语音低调地唤起助手，获取对方信息。整个过程对外无感知，对内效率极高。这正是名片记忆助手的产品立足点。

1.4 产品定位与功能边界

基于上述分析，名片记忆助手的核心定位可以用一句话概括：运行在 Rokid AI Glasses 上的社交记忆增强系统，帮助用户在面对面场合实现联系人信息的快速检索与持续积累。

在功能边界上，本智能体明确聚焦以下三个核心能力：

快速查询：用户说出联系人姓名，智能体从知识库中检索并以简洁的语音格式播报对方的公司、职位及上次会面话题。

名片录入：用户通过语音触发工作流，逐步录入新联系人的姓名、公司、职位、会面话题等结构化信息，写入数据库持久存储。

语义理解：基于大语言模型的语义理解能力，用户无需使用固定指令格式，自然语言描述即可完成查询与录入操作。

需要特别说明的是，本智能体有意回避了翻译、导航、支付等设备原生已具备的功能，聚焦在"人脉记忆"这一系统尚未覆盖的细分场景，以实现差异化的产品价值。

---

二、智能体工程架构拆解：知识库、Prompt、工作流三模块协作逻辑

2.1 平台选型：为什么选择灵珠平台

在开始开发之前，对几种主流的智能体开发路径进行了评估：

自建方案：基于主流大模型 API 自行搭建后端服务，配合向量数据库实现知识库检索。优点是灵活度高，缺点是开发成本大、与 Rokid 设备的集成需要额外工作量，且需要自行维护服务器与 API 调用链路。

通用智能体平台：如 Coze、Dify 等，提供了较为完整的智能体构建能力，但与 Rokid 眼镜设备的集成需要额外的适配层，且平台上架流程不在 Rokid 生态内，影响用户触达效率。

灵珠平台（Rizon）：Rokid 官方的智能体开发与分发平台，原生支持与 Rokid AI Glasses 设备的无缝集成，内置知识库、工作流、多模态输入等开发工具，且智能体完成后可直接在平台上架，面向 Rokid 眼镜用户分发。

对于目标是在 Rokid 设备上落地运行的智能体而言，选择灵珠平台是自然而然的结论——它在开发便利性、设备集成深度和用户触达路径上的综合优势，其他方案难以替代。

2.2 三模块架构总览

灵珠平台为开发者提供了从模型选择、知识库管理到工作流编排的完整工具链。对于名片记忆助手而言，平台提供的三类核心能力构成了整个智能体的技术骨架：

• 知识库（表格类型）：提供结构化数据的存储与语义检索能力，是联系人信息的核心载体
• Prompt 工程：通过人设与回复逻辑的配置，约束模型的行为模式与输出格式
• 工作流：通过可视化节点编排，实现多步骤的自动化业务逻辑

2.3 三模块协作逻辑

知识库承担的是数据层职责。联系人的姓名、公司、职位、会面话题等信息以表格形式存储在知识库中，模型在处理用户查询时会自动检索相关记录，并将检索结果作为上下文参考。

Prompt 承担的是行为约束层职责。通过在人设与回复逻辑中定义角色定位、输出格式、边界限制等规则，开发者可以精确控制模型在不同输入场景下的响应方式。对于运行在眼镜设备上的语音交互场景，Prompt 的核心目标是确保输出简洁、格式固定、适合语音播报。

工作流承担的是流程自动化层职责。对于需要多步骤交互的操作（如分步收集用户输入并写入数据库），单纯依靠对话模型难以保证数据的完整性，工作流通过定义明确的节点序列与数据流向，将复杂的多步骤逻辑结构化处理。

三者的协作关系如下：用户发起查询请求时，Prompt 约束模型行为，知识库提供数据支撑，模型综合输出结果；用户触发录入操作时，Prompt 识别意图并调起工作流，工作流完成数据收集与写入，最终由模型播报确认结果。

---

三、联系人数据建模：基于灵珠表格知识库的结构化存储设计与实现

3.1 知识库与数据库：两个容易混淆的核心概念

在正式进入字段设计之前，有必要厘清灵珠平台中两个容易被混淆的概念：知识库与数据库。

知识库是面向语义检索场景设计的存储系统。当用户发起自然语言查询时，模型会自动检索知识库中的相关内容，将检索结果作为上下文参考来生成回复。知识库支持文本、表格、图片等多种内容形式，适合存储需要被模型"理解"和"引用"的信息。

数据库是面向结构化写入场景设计的存储系统。它更接近传统意义上的关系型数据库，支持精确的字段写入、查询、更新和删除操作，适合在工作流中进行程序化的数据管理。

两者的核心区别在于：知识库的调用是由模型驱动的（模型根据语义相关性决定是否检索），数据库的操作是由工作流节点驱动的（按预定的逻辑精确执行）。

在名片记忆助手的架构中，两者分工明确：知识库负责支撑"张伟是谁"这类自然语言查询，数据库负责在 add_contact 工作流中接收并持久化新录入的联系人数据。

3.2 数据建模的核心原则

知识库的设计质量对智能体的检索效果有直接影响。基于实践经验，在设计表格知识库时遵循以下原则：

字段粒度最小化：每个字段只存储一类信息，避免将多种属性合并存储在同一字段中。例如，"公司"与"职位"分开存储，这样模型在生成回复时可以精准引用每个字段的值。

语义描述显式化：灵珠平台支持为每个字段添加描述，这些描述会作为模型理解数据结构的上下文参考。为每个字段添加清晰的语义说明，可以帮助模型在检索时做出更准确的字段映射。

检索索引明确：将"姓名"字段设置为索引字段，确保模型在接收到包含人名的查询请求时优先基于此字段进行匹配。

3.3 表格字段设计

经过分析，名片记忆助手的知识库表格最终确定为以下四个核心字段：

表格 还在加载中，请等待加载完成后再尝试复制

字段数量控制在四个，是经过权衡的结果。姓名、公司、职位是社交场合识别一个人的最核心三要素；上次话题则是本产品差异化的核心字段——它承载的不只是静态的个人信息，而是动态的关系上下文，能够帮助用户在重逢时快速找到对话的切入点。

其他可能的字段（如电话、邮箱）被有意省略。一方面，这类信息在语音播报场景下价值有限，且存在旁听隐私风险；另一方面，保持数据结构的精简有助于提升模型的检索效率与输出聚焦度。

3.4 测试数据录入

在完成字段结构定义后，录入了六条测试数据用于功能验证：

表格 还在加载中，请等待加载完成后再尝试复制

3.5 知识库挂载与调用方式配置

完成数据录入后，需要在智能体编辑页面将知识库与智能体关联。灵珠平台提供"按需调用"与"自动调用"两种知识库调用模式。

本项目选择"按需调用"模式，即模型根据用户输入的意图判断是否需要检索知识库，而非对每条消息都触发检索。这一设置能够有效降低不必要的检索开销，同时保证在用户明确提出查人需求时准确触发。

一个容易忽视的细节是：知识库添加完成后，必须在智能体编辑页面中手动将其挂载到当前智能体。仅完成数据录入而未完成挂载，模型在对话时将无法访问知识库数据，查询请求会统一返回兜底回复。这一步骤在初次配置时容易被遗漏，是调试阶段需要重点检查的配置项。

---

四、从零搭建：Prompt 调优与工作流节点的完整实现

4.1 Prompt 工程：从初版到最终版的演进

Prompt 是决定智能体行为质量的核心变量。对于名片记忆助手而言，一个好的 Prompt 需要同时满足以下几个目标：让模型清晰理解自己的角色与职责；约束输出格式使其适合语音播报；定义边界条件防止模型在无数据时编造信息；保持指令简洁以控制 Token 消耗，降低响应延迟。

初版 Prompt 的问题

最初的 Prompt 设计较为简单，只描述了角色和基本任务：

暂时无法在飞书文档外展示此内容

在测试阶段，这个 Prompt 暴露了三个明显问题：

第一，输出格式不稳定。模型有时会生成"根据我的知识库，张伟是字节跳动的产品总监，上次你们聊到了短视频推荐算法的合作..."这样的冗长回复，不适合语音播报场景。

第二，知识库无记录时行为不可预测。在找不到对应联系人时，模型偶尔会基于训练数据生成似是而非的"默认答案"，这在实际使用中是非常危险的行为。

第三，缺乏工作流触发逻辑的描述，模型不知道"添加联系人"这类输入应该触发工作流。

优化方向与最终版本

针对上述三个问题，对 Prompt 进行了针对性的迭代，最终确定的人设 Prompt 如下：

暂时无法在飞书文档外展示此内容

两版 Prompt 对比效果：

表格 还在加载中，请等待加载完成后再尝试复制

4.2 Prompt 效果验证

完成 Prompt 配置后，通过预览与调试面板进行了多轮测试：

测试用例一：标准姓名查询

• 输入：张伟是谁
• 实际输出：张伟，字节跳动产品总监，上次聊过短视频推荐算法合作。 ✅

测试用例二：无记录查询

• 输入：张三是谁
• 实际输出：暂无此人记录，需要帮你添加吗？ ✅

测试用例三：自然语言变体

• 输入：李娜在哪家公司
• 实际输出：李娜，阿里巴巴运营经理，上次聊过双十一电商活动策划。 ✅

测试用例四：模糊场景处理

• 输入：字节那个产品总监叫什么
• 实际输出：张伟，字节跳动产品总监，上次聊过短视频推荐算法合作。 ✅

---

4.3 工作流开发：add_contact 节点设计

名片录入需要收集多个字段的用户输入并将其结构化写入数据库，属于多步骤的有状态交互，更适合通过工作流引擎来实现。

在灵珠平台创建工作流，名称设置为 add_contact（平台工作流名称仅支持英文字母、数字和下划线，不支持中文），描述配置为：

暂时无法在飞书文档外展示此内容

工作流的整体节点序列如下：

暂时无法在飞书文档外展示此内容

节点一：开始节点

开始节点是工作流的入口，包含两个默认输入变量：USER_INPUT（用户的文字输入）和 USER_INPUT_IMAGE（用户的图片输入）。

节点二：问答节点

问答节点承担用户交互的职责，是整个工作流中最关键的数据收集环节。

节点配置：

• 提问内容：请依次告诉我联系人的姓名、公司、职位和上次见面话题。
• 问答类型：直接回答
• 输出变量：USER_RESPONSE

该节点的输出变量 USER_RESPONSE 包含了用户对提问的完整自然语言回复，例如"张三，腾讯，产品经理，聊过小程序开发合作"，将作为大模型节点的输入来源。

节点三：大模型节点

问答节点收集到的 USER_RESPONSE 是一段完整的自然语言字符串，无法直接拆分写入数据库的各个字段。因此在问答节点和新增数据节点之间插入一个大模型节点，专门负责结构化解析。

节点配置：

• 输入变量：input → 引用问答节点 USER_RESPONSE
• 系统提示词：

暂时无法在飞书文档外展示此内容

• 输出格式：选择输出格式JSON，变量类型设为 Object，并添加四个子字段：name、company、title、last_topic，类型均为 String

节点四：新增数据节点

新增数据节点负责将大模型节点解析后的结构化信息写入数据库。数据表选择 contacts，字段结构如下：

表格 还在加载中，请等待加载完成后再尝试复制

字段映射配置改为引用大模型节点的结构化输出：

表格 还在加载中，请等待加载完成后再尝试复制

这样每个字段写入的是经过模型解析后的精确值，而不是整条用户输入字符串。

节点五：输出节点

输出节点配置固定的确认文案：

暂时无法在飞书文档外展示此内容

节点六：结束节点

结束节点选择返回文本模式，回答内容填入：

暂时无法在飞书文档外展示此内容

4.4 开场白与预置问题配置

开场白文案：

暂时无法在飞书文档外展示此内容

预置问题配置：

暂时无法在飞书文档外展示此内容

三条预置问题覆盖了查询与录入两种核心交互路径，帮助新用户快速上手。

---

五、真实场景下的三幕交互：查询、新增与语音播报的完整演示

5.1 第一幕：社交场合的实时查询

场景描述： 在一场行业沙龙活动中，用户遇到一位面熟的联系人，隐约记得此人来自一家大公司，但一时想不起具体信息。用户通过眼镜低声唤起助手进行查询。

用户输入：张伟是谁

智能体响应：

暂时无法在飞书文档外展示此内容

多种查询方式验证：

表格 还在加载中，请等待加载完成后再尝试复制

5.2 第二幕：会后名片录入

场景描述： 活动结束后，用户希望将今天新认识的联系人录入系统，以便下次见面时快速检索。

用户输入：添加联系人

工作流触发，问答节点向用户发起收集请求：

暂时无法在飞书文档外展示此内容

用户输入：

暂时无法在飞书文档外展示此内容

智能体响应：

暂时无法在飞书文档外展示此内容

整个录入流程在两轮对话内完成，工作流引擎自动完成字段解析与数据库写入。工作流各节点运行时间：问答节点约 14.7 秒（含用户输入等待时间），新增数据节点约 0.03 秒，输出节点约2.6 秒，总体响应流畅。

触发方式多样性验证：

除"添加联系人"外，以下触发词均可激活录入工作流：

• 新增名片
• 帮我记录一下
• 我认识了一个新朋友
• 刚才换了名片，帮我存一下

这得益于工作流描述中对多种触发意图的覆盖，模型能够灵活识别用户的录入意图，而不局限于固定的触发词。

5.3 第三幕：无记录场景的兜底处理

用户输入：李四是谁

智能体响应：

暂时无法在飞书文档外展示此内容

兜底回复明确告知用户当前状态（无记录），同时主动引导下一步操作（建议添加），形成完整的用户交互闭环。这一设计使用户能够在当下场合立即决定是否录入新联系人，显著降低了认知负担。

5.4 交互设计的关键细节

回复的极度简洁性。 眼镜设备的语音播报场景与手机屏幕阅读场景有本质区别。用户在面对面交谈时注意力资源极为有限，过长的回复会造成信息干扰。三个场景中的所有回复均在两句话以内，确保用户能在不打断正常交谈节奏的情况下获取关键信息。

姓名前置原则。 在所有查询回复中，姓名始终作为第一个信息单元出现。用户查询时本身就是带着"确认这是不是某人"的预期，第一时间听到姓名的确认可以快速验证查询结果是否符合预期。

隐私保护设计。 Prompt 中明确限制了不主动播报电话、邮箱等隐私信息，防止在公共场合语音播报时造成信息泄露。

---

六、总结与展望

6.1 开发过程的核心收获

产品边界的取舍比技术实现更难。 在最初的构思阶段，曾尝试规划更复杂的功能，包括基于照片的人脸识别、多维度联系人标签体系等。但随着对平台能力的深入理解以及对真实使用场景的反复推敲，最终将产品收敛到三个核心能力。这种克制不是能力上的妥协，而是对用户场景的尊重——在眼镜上，简单可靠的功能比复杂但不稳定的功能更有价值。

Prompt 工程的精确度决定了产品体验的上限。 影响输出质量最大的变量不是知识库的数据量，而是 Prompt 中对输出格式和边界条件的约束精度。从初版到最终版，输出的稳定性和适配度有了质的提升。Prompt 的打磨需要大量的测试用例覆盖，这是开发周期中最容易被低估的环节。

平台能力的分层理解是高效开发的基础。 知识库与数据库的分工关系——前者面向语义检索，后者面向结构化写入——是设计工作流时最关键的认知基础。理解这一分层关系后，整个技术路径的设计变得清晰而自然。

6.2 后续功能规划

视觉辅助识别。 利用 doubao-seed-1-6-vision 模型的图像理解能力，尝试通过拍照结合知识库中的人物特征描述，实现更接近自然的"见人识人"交互方式。当前 Vision 模型已具备多模态输入能力，设备侧拍照功能也已就位，这一方向在技术路径上是可行的，核心挑战在于设计一套符合隐私规范的特征匹配机制。

会面记录的动态更新。 当前版本的上次话题字段在录入后不会自动更新。后续可以通过新增 update_topic 工作流，允许用户在每次会面结束后快速更新对应联系人的最新会面信息，使知识库随时间持续丰富。

场景化的主动推送。 结合活动签到或日历信息，在用户到达某个场合前主动推送今天可能遇到的联系人列表，从被动查询演化为主动提醒，进一步降低社交记忆的认知负荷。

6.3 对 AR+AI 可穿戴赛道的思考

2026 年智能眼镜纳入国家补贴政策，标志着这一品类从早期采用者市场向大众消费市场的正式迈进。对于开发者而言，这个节点的到来意味着智能体生态将迎来真正的规模化用户基础。过去，一个运行在眼镜上的智能体的潜在用户可能只有数万人；随着国补政策落地和设备普及加速，这个数字可能在两到三年内增长一个数量级。

名片记忆助手只是一个起点。它试图回答的问题是：当 AI 能力被嵌入一副眼镜，哪些人类认知局限可以被优雅地补足？记忆是其中最显而易见的一个答案。但随着设备能力的持续演进和开发者生态的不断丰富，这个问题的答案空间将远比今天所能想象的更加宽广。

AR 眼镜的终极形态，或许不是一个功能更强大的手机，而是一个能够感知情境、理解需求、适时介入的认知伙伴。名片记忆助手，是朝着这个方向迈出的一小步。

---

Rokid 开发者社区：https://forum.rokid.com/index

灵珠 AI 平台：https://rizon.rokid.com/space/home

参考文档：https://rokid.yuque.com/ub8h5n/hth52o