小红书 X Rokid 智能眼镜：让 Personal Agent 走进真实世界
REDtech约 12 分钟导读
AI 正在重塑人机交互，从过去回答问题，到如今走向真实生活中的持续协作。这要求 AI 既能理解眼前的情境、跟上事情的进展，也能在相处中越来越懂你。
小红书社区里，人们不断分享亲身尝试后的感受与发现。这些真实、鲜活的经验，如果能在你探索生活的当下，结合眼前的情境和个人需要提供帮助，就能从“别人的分享”变成“与你有关的建议”。围绕这一目标，我们打造了小红书蜜薯——你的 AI 生活搭子，陪你边看边聊，找好店、尝新品、挑好物。把大家的好经验，变成你的好生活。
为了让这样的陪伴自然融入生活现场，小红书 2049 Lab 与 Rokid 展开合作，以随身佩戴、看你所看、听你所听的智能眼镜为载体，在用户授权下按需感知现场，将大模型能力、社区经验与个人情境连接起来。
本文将结合我们的合作实践，介绍小红书蜜薯的整体架构，以及实时多模态全双工、Proactive 与 Memory 各部分如何协同支撑这一体验，并探讨通向 Personal OS 的技术路径。
01
交互演进：从屏幕走向真实世界
AI 正在改变人们表达意图、获取帮助的方式，智能眼镜则让这种变化走进生活现场。过去，找餐厅需要打开应用、输入条件、浏览评价，再把信息带回现场。现在，用户可以直接表达目标，并借助眼镜提供的第一视角画面，围绕“这家餐厅适合我们吗”“这两款有什么区别”继续交流。真实世界开始成为交互界面。
图 1：交互演进。AI 让用户直接表达目标，眼镜连接现场情境，大模型与小红书社区经验共同参与个人帮助。
智能眼镜随身佩戴的特点，让 AI 能够在用户发起任务时，更便捷地智能采集所需信息，并结合现场情境提供及时、自然的帮助，减少用户主动输入和手动操作的负担。
小红书社区提供带有具体情境与实践细节的生活经验，比如使用后的取舍、做成一件事的方法和探索新生活方式的经历。新品的尝鲜感受、新店的到访体验、近期展览与市集的见闻，还在不断为当下补充新鲜参考。
大模型提供通用知识、理解与推理能力，小红书社区则不断补充来自真实生活的新体验、新反馈与新口碑。将两者结合，Agent 才有机会把通用知识转化为更贴近此时、此地、此人的建议。
小红书 X Rokid 的合作实践
Rokid 在光学显示和智能眼镜软硬件研发方面的积累，提供了连接真实世界的产品载体；开放的生态和 AIUI 开发框架，支持合作伙伴共同打磨应用体验。
小红书 2049 Lab 将社区经验与 Agent 技术带入双方的合作实践，以“真经验，正当时”为理念，展开四类贴近日常的应用故事：
真好吃：初到一座城市，找一家本地人爱去的小店；到店后接着看菜单，结合人数与口味讨论怎么点。
真会挑：面对两件商品或两款美妆，边看边比较，把使用需求与买过、用过的人的体验结合起来。
真新鲜：遇到刚上新的食品或饮料，看看最近尝过的人怎么说，再与熟悉的经典款比较。
真会玩：为周末寻找新店、新展或市集，结合近期到访体验、时间与偏好，继续筛选合适的去处。
这些场景共同要求小红书蜜薯衔接画面、对话与个人背景，按需调用社区经验和工具。这也是整体架构设计的出发点。
02
Personal Agent：小红书蜜薯的整体架构
以本地生活中最日常的“吃什么”为例，小红书蜜薯需要从选餐厅延续到到店点餐，结合当次需求与个人背景，推荐菜品搭配和用餐位置。关注点从选店时的位置、环境，转向到店后的人数、菜量，任务上下文也随之更新。
我们采用渐进式的感知设计，随着任务推进获取必要的信息：开始自然的进行语音对话、了解需求；用户询问“这家怎么样”时，按需拍摄眼前店铺；到店后的菜单陪看与用餐位置选择，则在用户开启并授权的任务范围内持续观察。采集内容、频率与时长随任务调整，用户停止陪看或任务结束时，相关采集也应停止，减少不必要的信息采集与隐私暴露。
交互主链路与独立支撑
架构由交互主链路与独立支撑能力组成：端侧体验、实时会话与 Agent 协作串联输入、任务推进和交付；能力服务与 Memory 独立提供外部依据、行动能力和个人背景。
图 2：小红书蜜薯整体技术框架。端侧、实时会话与 Agent 协作构成交互主链路；Memory 与能力服务独立支撑任务推进。
整体上，小红书蜜薯从端侧按需获取现场信息，通过多模态全双工会话连接用户与 Agent。主 Agent 组织任务，Proactive 结合共享的任务状态持续观察、判断回应时机；社区经验与工具提供外部依据和行动能力，独立的 Memory 子系统提供可持续更新的个人背景。结果通过语音播报与结构化界面协同交付，围绕同一任务保持一致。
这条链路承接从选店到点餐的连续体验，而自然协作能否成立，还取决于三个关键环节：实时交互能否跟上用户的插话与变化，Proactive 能否在任务中适时提供帮助，以及 Memory 能否让每次相处积累为更深入的理解。下文我们将依次展开。
03
实时交互：多模态全双工与可靠交付
小红书蜜薯介绍一道菜时，用户补充“想吃清淡一点”，随即翻到下一页。语音、画面与意图持续变化，输入接收、响应生成和语音播放在时间上交叠。我们的设计围绕任务对齐、跨链路取消和交付确认展开，让展示、播报与行动跟上当前意图。
图 3：多模态全双工与可靠交付。输入、生成与交付在时间上交叠；用户插话更新有效任务，跨链路取消与交付回执保障体验一致。
多模态输入与任务对齐
同一句话尚未结束，识别结果可能已多次修订；用户说“这个”时，眼前对象也可能变化。系统区分临时识别结果与确认输入，结合用户原话、可见对象和有效上下文更新任务条件，避免把每次识别变化当成独立指令。
视觉输入按当前任务组织，综合对象变化、信息有效性与传输推理成本选择采集策略。任务结束或失效时，停止相关采集并释放设备资源，使视觉输入的有效范围与任务保持一致。
跨链路打断与取消
取消操作关联到当前响应，分别管理生成、播放和动作执行的状态，区分已经发出、仍在排队和尚未执行的工作。服务端停止生成后，传输中的内容与端侧播放队列仍需同步处理，避免旧回答继续占用当前交流。
用户说“先等等，换一个”时，这一机制需要覆盖正在生成的回答、排队语音和待执行动作，而不止停止模型输出。连接恢复或迟到结果到达时，系统还会结合恢复状态与执行记录检查任务有效性，避免失效动作因消息重放再次执行。
交付回执与有序执行
“翻到下一家，再介绍它”要求页面切换与语音介绍按序交付。在餐厅与笔记浏览等动作中，我们分别记录服务端提交、端侧呈现、语音播放和动作完成状态，让存在顺序依赖的步骤依据相应回执推进。
需要完成展示或播报的步骤，还要结合最终文本呈现、语音正常播放完成等信号确认进度。服务端提交、端侧呈现与用户听完回答属于不同阶段，后续步骤应使用与其依赖相对应的回执，接续用户实际看到、听到的内容。
交互验证需要覆盖翻页、插话、改口、连接恢复与迟到结果，分别检查生成、发送和端侧交付中的对象与执行顺序。
实时交互接住当前表达；当相关信息稍后才出现时，Proactive 需要延续关注目标，随现场变化判断回应时机。
04
Proactive：持续观察与任务协作
用户交代“我们有 5 个人，想尝特色，也要照顾口味和分量”后继续翻看菜单。Proactive 与主 Agent 协作，会延续这一目标，随着新画面补充理解并适时提供建议，用户无需每翻一页就重新发问。
图 4：Proactive 持续观察与任务协作。关注目标随任务延续，后续画面进入分层上下文；回应时机与后台结果是否适用分别判断。
任务状态与 Agent 协作
任务状态连接主 Agent 与 Proactive，记录关注目标、已确认条件、当前对象与进展。用户补充“还想搭配一道蔬菜”后，新条件进入后续观察与判断；已讨论的选项也保留在上下文中，主 Agent 据此结合社区经验与个人背景组织建议。
关注目标随任务生命周期管理。用户调整需求、暂停提示或结束陪看时，后续观察与回应同步调整，避免继续围绕过期目标提供帮助。
分层上下文与历史压缩
我们按时间组织上下文：近期多帧保留现场细节，较早片段整理为视觉摘要，更早历史压缩为带时间线索的文本。后续判断同时参考眼前内容与此前过程，理解新选项如何承接用户的关注点。
摘要可提前异步生成，相邻推理复用帧编码与已转换消息，减少应用侧重复处理。摘要粒度、压缩周期与保留范围按任务选择，在细节保留、上下文规模和响应节奏之间取舍。
这部分维护当前陪看任务中的连续上下文；跨会话的个人背景由独立的 Memory 子系统提供。
持续观察与回应时机
控制层提供任务启动门控，通过连续输入采样管理视觉语言推理的节奏；语义层结合用户目标、现场证据和已有上下文，判断回应或保持静默。观察频率与回应时机分别管理，新画面到达并不直接触发播报。
例如，新一页出现适合分享、能补充当前搭配的选项时，可以简短提示；信息不足或没有新增价值时，则继续观察。同一关注目标既可依据当前画面即时回答，也可等待后续证据再回应，或随着任务推进多次补充建议。
异步委派与事件回传
框架支持将社区检索、候选整理等工作委派给后台任务，以任务标识关联提交、完成或失败事件。前台继续接收现场信息，后台完成后以事件回传结果。
用户可能在等待期间翻页或改变要求，因此还需检查结果与当前目标的相关性及呈现时机。计算完成与适合回应是两个独立状态，任务关联与事件回传负责将后台处理接回现场交互。
Proactive 让一次交代在任务中持续有效；下一次交流如何带上相关背景、减少重复解释，则由 Memory 进一步解决。
05
Memory：经历积累与用户理解
在这次 5 人聚餐中，用户补充“特色菜可以试试，搭配还是希望清爽一些”。这既是点餐条件，也为后续理解提供线索。下一次用餐，人数与场景可能变化：例如，用户此前在交流中主动提到偏好安静、有氛围感的餐厅，当下一次询问双人用餐推荐时，小红书蜜薯便可以结合这一偏好，推荐更符合需求的餐厅，让每一次交互都更贴近用户的实际需要。
Memory 希望让这样的延续成为日常能力：减少重复解释，理解需求背后的情境，并随新反馈调整认识，让“越来越懂你”体现在具体的帮助中。
图 5：Memory 从经历积累到个人理解。经历与反馈形成可更新的理解；异步积累与召回只为当前任务提供已经就绪且仍然有效的材料。
分层记忆与证据溯源
PersonOS 记忆框架分层组织原始证据、情节记录、检索线索与个人背景，分别承接观察依据、事件过程、检索定位和从经历中形成的理解。
“这次有 5 个人”是当次条件，“希望搭配清爽一些”是带有情境的用户表达，进一步形成的口味倾向则包含系统解释。保留表达、情境与解释的来源关系，才能判断历史信息在新任务中是否适用，并依据新反馈修订理解。
Mneme 在单个视频会话中分离事件观察与身份判断、随新线索修订解释，也为持续更新个人理解提供了方法参考。
记忆召回与个性化应用
新任务开始后，Memory 检索相关背景，带着来源进入上下文，与现场信息、当前对话和社区经验共同参与判断。此前清爽口味的表达可供参考，上次聚餐人数则需重新确认；本次明确提出的要求优先，用户想尝试不同风味时，建议也应随之调整。
我们分别观察历史信息是否被召回、是否进入 Agent 上下文、是否被回答实际使用。开发阶段的受控样例已验证部分跨会话召回与历史事实使用路径；长期评价仍需检验是否减少重复询问、准确理解不同场景，并根据反馈修正认识。
异步读写与响应解耦
写入时，主流程复制原始互动并放入有界队列，后续持久化和记忆生产在后台完成。读取时，根据当前任务异步检索已有记忆，在既有的上下文组装边界使用已就绪的材料；当前响应无需等待本次互动完成记忆加工，也不等待后台召回返回。
请求结束或被替代后，迟到的召回结果被丢弃。相关性、就绪时间与使用时机共同决定记忆能否参与当前帮助，即时响应与后台处理解耦后，仍需持续优化这些环节。
Memory 为个人理解提供可积累、可追溯、可更新的基础。我们希望进一步衔接个人背景、任务与能力，让每次相处成为下一次帮助的起点，走向持续服务个人的 Personal OS。
06
Personal OS：持续服务个人的系统愿景
Personal OS 是支撑长期个人服务的系统愿景：围绕同一个人的背景、偏好和正在进行的事情组织能力，让小红书蜜薯的交流与协作跨场景、跨设备延续。
图 6：Personal OS 系统愿景。围绕同一个人的背景与任务，探索跨场景、跨设备的持续服务，与伙伴及人才共同建设。
未来，用户可以在手机上规划复杂任务，佩戴眼镜时获得现场帮助，结束后再回顾和整理经历。我们希望任务进展与必要背景能随用户选择接续，让不同设备共同服务同一段生活过程。社区经验为个人处境提供参考；用户愿意保留的经历支持回顾和创作，自主选择分享的内容再为社区补充新经验。两者相互补充，让帮助持续贴近生活。
小红书 2049 Lab 与 Rokid 的合作，是在真实设备和生活任务中打磨这些能力的实践。长期服务可靠性、跨场景上下文延续，以及日常佩戴的体验与资源约束，仍需持续投入。我们期待与智能硬件、生活服务及技术生态伙伴共同探索，在更多真实场景中验证和完善。
我们也欢迎对实时多模态、Agent、Memory 与智能穿戴充满兴趣的优秀人才加入 2049 Lab，一起解决从技术机制到日常体验之间的具体问题，让长期理解并帮助个人的 AI 成为生活中可靠的一部分。
///
作者简介
本文作者：梓瑜，小红书 2049 Lab 产品工程师；天香，小红书 2049 Lab 负责人。
本项目成员：索隆、百灵、妮娜、罗梭、叶瑄、温家懿、朱晨媛及 2049 Lab 全员。
///
关于团队
小红书交互技术实验室（2049 Lab）致力于探索并定义 AI 时代智能软硬件的下一代交互范式。依托小红书真实、鲜活且持续更新的生活经验，团队围绕多模态实时交互、长期记忆与主动智能，开展从前沿技术研究、核心系统研发到软硬件产品落地的探索。
我们以真实经验为基础、以智能交互为核心，通过 AI 眼镜等智能硬件合作，将技术带入真实生活场景，以产品体验和用户反馈推动持续迭代，让 AI 从回答问题走向理解真实世界、持续服务个人生活。
招聘链接：
团队 GitHub主页：
https://github.com/2049lab
Memory 开源项目主页：
personosai.com