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

作品名称：Rokid AI旅游搭子

一句话介绍：戴上眼镜，让每一次出发都有懂你的向导。

前言

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

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

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

一、整体技术架构

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

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

整体链路可以概括为：
#mermaid-svg-LNicWipuURPdksS4{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-LNicWipuURPdksS4 .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-LNicWipuURPdksS4 .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-LNicWipuURPdksS4 .error-icon{fill:#552222;}#mermaid-svg-LNicWipuURPdksS4 .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-LNicWipuURPdksS4 .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-LNicWipuURPdksS4 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-LNicWipuURPdksS4 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-LNicWipuURPdksS4 .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-LNicWipuURPdksS4 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-LNicWipuURPdksS4 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-LNicWipuURPdksS4 .marker{fill:#333333;stroke:#333333;}#mermaid-svg-LNicWipuURPdksS4 .marker.cross{stroke:#333333;}#mermaid-svg-LNicWipuURPdksS4 svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-LNicWipuURPdksS4 p{margin:0;}#mermaid-svg-LNicWipuURPdksS4 .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-LNicWipuURPdksS4 .cluster-label text{fill:#333;}#mermaid-svg-LNicWipuURPdksS4 .cluster-label span{color:#333;}#mermaid-svg-LNicWipuURPdksS4 .cluster-label span p{background-color:transparent;}#mermaid-svg-LNicWipuURPdksS4 .label text,#mermaid-svg-LNicWipuURPdksS4 span{fill:#333;color:#333;}#mermaid-svg-LNicWipuURPdksS4 .node rect,#mermaid-svg-LNicWipuURPdksS4 .node circle,#mermaid-svg-LNicWipuURPdksS4 .node ellipse,#mermaid-svg-LNicWipuURPdksS4 .node polygon,#mermaid-svg-LNicWipuURPdksS4 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-LNicWipuURPdksS4 .rough-node .label text,#mermaid-svg-LNicWipuURPdksS4 .node .label text,#mermaid-svg-LNicWipuURPdksS4 .image-shape .label,#mermaid-svg-LNicWipuURPdksS4 .icon-shape .label{text-anchor:middle;}#mermaid-svg-LNicWipuURPdksS4 .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-LNicWipuURPdksS4 .rough-node .label,#mermaid-svg-LNicWipuURPdksS4 .node .label,#mermaid-svg-LNicWipuURPdksS4 .image-shape .label,#mermaid-svg-LNicWipuURPdksS4 .icon-shape .label{text-align:center;}#mermaid-svg-LNicWipuURPdksS4 .node.clickable{cursor:pointer;}#mermaid-svg-LNicWipuURPdksS4 .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-LNicWipuURPdksS4 .arrowheadPath{fill:#333333;}#mermaid-svg-LNicWipuURPdksS4 .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-LNicWipuURPdksS4 .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-LNicWipuURPdksS4 .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-LNicWipuURPdksS4 .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-LNicWipuURPdksS4 .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-LNicWipuURPdksS4 .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-LNicWipuURPdksS4 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-LNicWipuURPdksS4 .cluster text{fill:#333;}#mermaid-svg-LNicWipuURPdksS4 .cluster span{color:#333;}#mermaid-svg-LNicWipuURPdksS4 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-LNicWipuURPdksS4 .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-LNicWipuURPdksS4 rect.text{fill:none;stroke-width:0;}#mermaid-svg-LNicWipuURPdksS4 .icon-shape,#mermaid-svg-LNicWipuURPdksS4 .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-LNicWipuURPdksS4 .icon-shape p,#mermaid-svg-LNicWipuURPdksS4 .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-LNicWipuURPdksS4 .icon-shape .label rect,#mermaid-svg-LNicWipuURPdksS4 .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-LNicWipuURPdksS4 .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-LNicWipuURPdksS4 .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-LNicWipuURPdksS4 :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 眼镜端语音/定位/图像
上下文与坐标预处理
意图识别
景点知识问答
周边搜索
步行或驾车规划
拍照识别
普通聊天
结果归一化
回答生成与卡片参数提取
眼镜端语音/GPASS卡片

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

二、工作流设计

1. 输入与上下文处理

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

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

2. 条件分支与意图路由

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

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

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

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

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

3. 参数提取

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

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

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

json 复制代码

{
  "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. 知识库补充景点信息

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

五、提示词与输出控制

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

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

text 复制代码

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

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

六、一次典型请求如何执行

以"附近有什么适合拍照的景点？"为例：

眼镜端上传当前语音文本、历史上下文和 GPS；
云端完成经纬度格式化与坐标转换；
意图识别命中"周边"；
参数节点提取关键词"适合拍照的景点"；
周边搜索插件返回附近 POI；
数据处理节点筛选距离和主要信息；
大模型生成简短推荐；
眼镜端播报结论，并展示包含地点与距离的 GPASS 卡片。

如果用户接着说"带我走到第二个"，历史对话会帮助系统确定"第二个"所指的地点，随后进入步行路线分支。这种连续交互，正是"旅游工具"和"旅游搭子"的区别。

总结

Rokid AI旅游搭子的核心并不是单独某个模型或插件，而是把眼镜端感知、云端工作流、地图服务、知识库和多模态能力组合成一条自然的交互链路。

在这套方案中，眼镜负责看见用户所处的现场，插件负责提供可信的实时事实，大模型负责理解意图并把结果说得像一个真正的旅行同伴。最终希望做到的是：用户少看一次手机、少切换一个应用，也能更专注地感受眼前的旅程。

关键词： Rokid、智能眼镜、AI智能体、工作流编排、多模态、旅游助手、地图插件、GPASS