从智能眼镜到云端工作流：Rokid AI旅游搭子的设计与实现

原创已于 2026-07-15 16:44:18 修改 · 290 阅读

5 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

于 2026-07-15 16:43:40 首次发布

作品名称：Rokid AI旅游搭子
一句话介绍：戴上眼镜，让每一次出发都有懂你的向导。

前言

旅行中真正让人手忙脚乱的，往往不是“查不到信息”，而是需要不停地掏出手机：看路线、搜附近、确认天气、识别眼前的建筑，再把几个应用里的结果拼在一起。

Rokid AI旅游搭子想解决的正是这个问题。它以智能眼镜作为入口，通过语音、定位和摄像头感知用户当下的需求，再把识景问答、周边推荐、天气查询、步行/驾车规划等能力组织成一条完整工作流。用户不需要理解背后的插件和模型，只要自然地说一句“附近有什么值得逛的”“带我走到刚才那个景点”或者“帮我看看眼前这栋建筑”，系统就会选择对应能力并给出适合眼镜端展示的结果。

本文主要分享项目的工作流设计、端侧与云端插件协同方式，以及实现过程中几个比较关键的技术取舍。

一、整体技术架构

项目采用“端侧负责感知与呈现，云端负责理解与编排”的方案。

眼镜端负责采集当前对话、历史对话、GPS 坐标和相机画面，并通过语音或 GPASS 卡片向用户反馈结果。
云端工作流负责坐标转换、意图识别、参数提取、知识检索、天气查询、POI 搜索、路线规划和回答生成。
大模型不直接包办所有任务，而是承担语义理解、分流、结构化提取和自然语言组织；实时位置、天气和路线等事实由插件返回。

整体链路可以概括为：

这种拆分的好处是比较实际：模型擅长理解“用户想做什么”，插件擅长返回“现在真实发生了什么”，两者各做自己更可靠的部分。

详细的工作流

二、工作流设计

1. 输入与上下文处理

开始节点接收两类对话信息：当前输入和历史对话。当前输入用于判断本轮任务，历史对话则用来理解“那里”“第二个”“刚才那个地方”等指代。

工作流同时读取眼镜端提供的经纬度。由于设备坐标与地图插件使用的坐标系可能不同，流程前部加入了经纬度格式化和坐标转换节点。转换后的坐标再用于逆地理编码、天气查询和周边搜索，避免出现“地图上的位置与用户实际位置偏移”的问题。

2. 条件分支与意图路由

预处理完成后，条件节点会根据设备状态或场景标识选择执行链路。工作流中主要存在两类任务：

拍照、知识问答和普通聊天等轻量任务；
依赖当前位置、天气或地图能力的旅游服务任务。

旅游服务意图进一步细分为：

周边查询；
步行路线；
驾车路线；
眼前场景拍照识别；
其他旅游问答。

这里没有让大模型直接自由调用全部工具，而是先用意图节点做明确分流。这样既降低了误调用概率，也让每条分支的输入输出更容易调试。

3. 参数提取

意图确定后，工作流通过专门的大模型节点提取插件需要的参数。例如：

周边搜索提取 keyword、当前位置和返回数量；
路线规划提取 origin、destination 和出行方式；
知识问答提取景点或地标关键词；
卡片生成提取半径、路线模式、标题和展示文本。

参数提取节点尽量只做结构化输出，不负责回答用户。一个简化的数据结构如下：

{
  "intent": "walking_route",
  "origin": "current_location",
  "destination": "象鼻山",
  "keyword": "",
  "need_clarification": false
}

如果目的地、关键词等必要信息缺失，流程不会让模型随意补全，而是进入提示节点，请用户补充。例如：“你想去哪个景点？”或者“你更想找美食、酒店还是景点？”

4. 工具执行与结果汇总

不同分支调用不同插件：

天气查询：结合位置与时间，补充当前天气和出行环境；
周边搜索：根据当前位置和关键词返回 POI 列表；
步行路线规划：生成适合步行的路线方案；
驾车路线规划：生成驾车路线、距离和预计耗时；
知识库：检索景点背景资料，减少模型凭空生成；
眼镜拍照采集：获得当前画面，交给多模态模型进行识别。

地图插件返回的数据通常较长，而且字段结构不适合直接播报。因此，周边、步行和驾车结果会先进入“数据处理”节点，提炼出地点名称、距离、时间和关键路线，再由参数提取节点整理成卡片所需字段。

三、端侧插件的运用

眼镜端并不只是一个显示器，它提供了整个智能体最关键的现场上下文。

1. GPS 与设备变量

系统经纬度变量让智能体知道用户“现在在哪里”。有了位置，用户不必每次都说完整地址，可以直接问：

“附近有什么值得逛的？”
“最近的地铁站怎么走？”
“这里今天会下雨吗？”

端侧只负责提供原始坐标，坐标转换、地址解析和地图调用放在云端完成，便于统一维护。

2. 眼镜摄像头

当意图识别结果为拍照或识景时，工作流调用“眼镜设备拍照采集”插件。插件返回拍照状态和图片数据地址，多模态模型读取实际画面后，再识别建筑、景点、菜单、路牌或文字。

这一分支尤其需要控制幻觉：如果画面模糊或模型置信度不足，回复应使用“可能是”“看起来像”等表达，而不是仅根据位置猜测建筑名称。

3. GPASS 卡片输出

眼镜的交互空间比手机更有限，因此输出不能简单复制一段长文本。项目将结果分成语音结论和视觉卡片：

语音先给出一句最重要的信息；
卡片展示地点、距离、时间或路线摘要；
导航场景只呈现当前关键动作，避免一次显示整条复杂路线。

工作流末端通过卡片参数提取和大模型整理，将插件结果转换为 GPASS 信息卡片或路线相关卡片，实现从云端数据到眼镜端界面的闭环。

四、云端插件与模型协作

1. 插件负责事实，大模型负责表达

实时天气、附近地点和路线属于强时效信息，不能依靠大模型记忆。因此项目坚持一个原则：事实由插件提供，模型只负责理解和组织。

例如用户问“附近有什么适合拍照的地方”，模型先识别“周边推荐”意图并提取“适合拍照的景点”作为关键词；周边插件返回实际 POI 后，最终模型最多选择三个结果，并说明推荐理由，但不会补写插件没有提供的营业时间或评分。

2. 不同模型承担不同任务

工作流中的 Qwen、DeepSeek 等模型节点并不是重复堆叠，而是按任务复杂度分工：

意图识别和参数提取强调速度与结构化稳定性；
知识问答和最终回复强调语言组织能力；
拍照识别使用支持图片输入的多模态模型；
卡片生成强调固定格式和字段完整性。

这种分工比“一个大模型从头做到尾”更容易定位问题，也便于单独替换和调优。

3. 知识库补充景点信息

对于景点历史、文化背景和游览提示，工作流先提取关键词，再查询知识库。模型基于检索结果生成简短介绍，可以减少事实错误，也便于后续扩展更多城市和景区资料。

五、提示词与输出控制

这个项目里，提示词最重要的并不是写得长，而是把每个节点的职责限制清楚。

意图识别节点只选择类别；目的地节点只提取起终点；最终大模型只消费本轮非空的插件结果。核心约束包括：

1. 当前问题优先，历史对话只用于解析指代。
2. 只使用本轮真实返回且非空的工具结果。
3. 不虚构地点、距离、时间、路线、营业状态和图片内容。
4. 信息不足时提出一个简短问题，不自行猜测。
5. 回复适合智能眼镜播报：先说结论，默认控制在 2～4 句话。
6. 不向用户暴露工作流、节点、变量、JSON 或插件状态。

对于周边搜索，默认最多推荐三个地点；对于路线规划，先说距离和时间，再给出关键方向；对于驾车场景，避免要求用户观看或操作屏幕。