摘要
RideGuard 是一款面向 Rokid 智能眼镜的骑行导航 Agent。用户只需说出“导航去橘子洲，尽量走绿道，不要爬坡”，系统即可识别目的地与骑行偏好，自动搜索 POI、提取终点坐标、调用高德骑行路线服务，并从多条候选路线中综合比较距离、预计时间和绿道路段，最终输出适合眼镜端阅读的骑行导航摘要。
本项目基于 GPASS 百宝箱完成 Agent 工作流编排，采用“自然语言理解 + 云端插件调用 + 确定性代码决策 + Rokid 端结果呈现”的技术路线。
关键词：Rokid、GPASS、智能眼镜、骑行导航、Agent、工作流、高德地图、POI、AR 导航
一、项目背景
现有智能眼镜导航通常以固定 HUD 形式显示：
前方左转 距离路口500米 剩余3.2公里这种方案解决了骑行时频繁低头看手机的问题，但其本质仍是将手机导航信息搬到眼镜屏幕上，缺少对骑行场景的进一步理解。
对于骑行者而言，除了能否到达目的地，还会关注：
- 是否有绿道或骑行友好道路；
- 路线距离和预计骑行时间；
- 是否尽量少爬坡；
- 是否符合个人的骑行偏好；
- 是否可以用一句自然语言直接完成路线规划。
因此，本项目尝试在传统 HUD 导航之上增加一层骑行 Agent，使系统不仅显示路线，还能够理解骑手意图、比较候选路线并作出路线决策。
二、项目目标
RideGuard 的核心目标是建立以下完整链路：
用户自然语言指令 → 骑行意图识别 → 导航参数提取 → 目的地搜索 → 终点坐标获取 → 骑行路线规划 → 多路线比较 → Rokid眼镜端结果输出典型输入：
导航去橘子洲，尽量走绿道，不要爬坡典型输出：
目的地：橘子洲 推荐路线：路线2 全程距离：14.7公里 预计时间：77分钟 主要道路：奋勉路、神农路、王家垄路 绿道路段：4.1公里 起步指令：向北骑行35米左转 路线说明：优先选择绿道路段较长的路线；坡度信息暂无法验证。三、系统总体架构
RideGuard 采用端云协同架构。
┌───────────────────────┐ │ Rokid眼镜 / 手机端 │ │ 语音输入、结果显示、定位 │ └───────────┬───────────┘ │ ▼ ┌───────────────────────┐ │ GPASS Agent │ │ 意图识别、参数提取、流程编排 │ └───────────┬───────────┘ │ ┌──────┴──────┐ ▼ ▼ ┌─────────┐ ┌─────────────┐ │ POI搜索 │ │ 高德骑行API │ └────┬────┘ └──────┬──────┘ │ │ └──────┬────────┘ ▼ ┌───────────────────────┐ │ 路线候选精简代码节点 │ │ 路线比较、绿道统计、格式转换 │ └───────────┬───────────┘ ▼ ┌───────────────────────┐ │ Rokid端导航结果卡片 │ └───────────────────────┘端侧职责
当前版本中，Rokid 眼镜主要承担：
- 用户语音交互入口；
- 导航结果卡片显示；
- 起步方向、距离、时间等信息呈现；
- 后续接入手机实时 GPS 定位。
云端职责
GPASS 云端工作流主要承担：
- 骑行指令意图识别；
- 目的地和路线偏好提取；
- POI 搜索；
- 高德骑行路线 API 调用；
- 多路线比较；
- 结果结构化与异常处理。
四、GPASS 工作流设计
完整工作流如下：
开始 → 意图识别 → 导航参数提取 → JSON反序列化 → 判断是否提供目的地当目的地为空时：
未提供目的地 → 结束节点 → 提示用户补充目的地当目的地有效时：
根据关键词搜索POI → JSON序列化 → 提取终点坐标 → HTTP请求 → 路线候选精简 → 判断路线是否有效成功分支：
骑行导航结果失败分支：
路线规划失败五、意图识别与导航参数提取
系统首先通过意图识别节点判断用户当前操作，例如：
- 开始导航；
- 查询导航进度；
- 修改路线偏好；
- 暂停或继续导航；
- 停止导航；
- 查找附近维修点；
- 退出骑行助手。
对于开始导航指令，系统会将自然语言转换为结构化参数：
{ "action": "START_NAVIGATION", "destination": "橘子洲", "routeMode": "BICYCLE", "preferBikeLane": true, "preferSafeRoute": false, "avoidSteepSlope": true }运行字段说明：
| 字段 | 含义 |
|---|---|
| action | 当前用户操作 |
| destination | 用户目的地 |
| routeMode | 出行方式，当前固定为 BICYCLE |
| preferBikeLane | 是否优先骑行道或绿道 |
| preferSafeRoute | 是否启用安全偏好 |
| avoidSteepSlope | 是否希望少爬坡 |
布尔字段必须使用 Boolean 类型，不能使用字符串，否则后续分支和代码判断容易出现错误。
六、目的地 POI 搜索
自然语言中的“橘子洲”不能直接作为骑行路线接口的终点，需要先转换为经纬度。
工作流使用高德 POI 搜索插件完成目的地匹配。
主要参数：
keywords = 用户目的地 region = 长沙市 city_limit = true page_size = 10 page_num = 1插件返回多个 POI 候选结果，例如：
[ { "name": "橘子洲风景名胜区", "address": "长沙市岳麓区橘子洲头", "location": "112.963081,28.196505" } ]随后通过 JSON 序列化和字段提取节点，得到：
destinationCoord = 112.963081,28.196505高德接口坐标格式必须为：
经度,纬度不能使用：
纬度,经度也不能直接传入“导航去橘子洲”等自然语言。
七、高德骑行路线接口调用
路线获取通过 GPASS 的 HTTP 请求节点完成。
请求地址
GET https://restapi.amap.com/v5/direction/bicycling请求参数
key = 高德Web服务Key origin = 113.081600,28.179300 destination = destinationCoord show_fields = cost,navi alternative_route = 3 output = json说明：
origin为当前骑手位置；- 演示阶段使用固定长沙测试坐标；
- 真机版本将由手机或 Rokid 端实时上传；
alternative_route=3表示请求多条候选路线；- 当前不请求
polyline，避免大量坐标数据增加模型和工作流负担。
接口业务成功判断不能只看 HTTP 200，还需要检查：
status = 1 infocode = 10000 route.paths 不为空HTTP 200 仅代表服务器成功响应，并不代表路线规划成功。
八、路线候选精简与决策
高德原始返回数据包含大量路段、指令和坐标信息，直接交给大模型容易产生以下问题：
- 输入数据过长；
- 路线字段提取不稳定；
- 数值换算错误；
- 默认选择第一条路线；
- 出现字段为空或虚构内容。
因此，RideGuard 使用 GPASS 代码节点完成确定性路线决策。
精简后的路线结构
{ "status": "1", "infocode": "10000", "routeCount": 2, "routes": [ { "routeIndex": 1, "distanceMeters": 14592, "durationSeconds": 4783, "hasGreenway": false, "greenwayDistanceMeters": 0, "mainRoads": [ "奋勉路", "神农路", "王家垄路" ], "startInstruction": "向北骑行35米左转" }, { "routeIndex": 2, "distanceMeters": 14668, "durationSeconds": 4623, "hasGreenway": true, "greenwayDistanceMeters": 4133, "mainRoads": [ "奋勉路", "神农路", "王家垄路", "浏阳河北岸绿道" ], "startInstruction": "向北骑行35米左转" } ] }运行路线选择规则
当用户启用绿道偏好时：
选择 greenwayDistanceMeters 最大的路线绿道距离相同时：
选择 durationSeconds 更小的路线用户没有绿道偏好时：
选择预计时间最短的路线核心逻辑可以概括为：
if (preferBikeLane) { selectRouteByMaxGreenwayDistance(); } else { selectRouteByMinDuration(); }距离转换：
distanceKm = distanceMeters / 1000;时间转换：
durationMinutes = Math.round(durationSeconds / 60);九、为什么不完全依赖大模型
本项目早期版本使用大模型直接解析高德路线 JSON，但出现过：
- 距离和时间字段为空；
- 将提示词本身输出到结果中；
- 找不到实际存在的 routes；
- 将成功结果误判为失败；
- 绿道优先时仍默认选择路线1。
路线选择属于确定性逻辑，更适合通过代码节点完成。
因此最终采用：
大模型负责理解用户 代码负责计算和决策 工作流负责插件编排 眼镜负责结果呈现这种设计比完全依赖大模型更稳定，也更适合现场演示和产品落地。
十、异常处理设计
系统设置了两个主要分支。
目的地为空
当用户输入：
开始导航系统返回：
请告诉我您想骑行前往的目的地。 例如：导航去橘子洲。此时不会继续调用 POI 和高德 API。
路线规划失败
代码节点输出：
{ "ok": false, "error": "具体失败原因" }分支节点判断：
ok 为真成功时输出导航结果，失败时返回：
暂时无法生成有效骑行路线，请检查目的地后重试。避免出现“骑行路线规划失败：OK”等相互矛盾的结果。
十一、端侧与云端插件运用
云端插件
1. 意图识别
用于区分开始导航、暂停、继续、停止和查询等不同操作。
2. POI 搜索插件
将“橘子洲”等自然语言地点转换为具体 POI 和经纬度坐标。
3. HTTP 请求节点
调用高德骑行路线接口，获取真实路线数据。
4. JSON 序列化与反序列化
用于在大模型文本输出、插件对象和代码节点之间完成数据转换。
5. 代码节点
完成：
- 多路线解析；
- 绿道长度统计；
- 时间和距离换算；
- 路线筛选；
- 眼镜端导航文案生成。
端侧能力
当前版本的 Rokid 端负责显示：
- 目的地；
- 推荐路线；
- 全程距离；
- 预计时间；
- 主要道路；
- 绿道路段；
- 起步指令。
下一阶段计划接入：
- 手机 GPS 实时位置；
- 当前位置持续更新；
- 路口级导航指令；
- 偏航检测；
- 自动重新规划；
- 摄像头与道路环境识别。
十二、项目测试结果
测试一：普通导航
输入：
导航去橘子洲结果：
推荐路线：路线2 全程距离：14.7公里 预计时间：77分钟因为路线2预计时间比路线1更短。
测试二：绿道优先
输入：
导航去橘子洲，尽量走绿道结果：
推荐路线：路线2 绿道路段：4.1公里测试三：绿道优先并少爬坡
输入：
导航去橘子洲，尽量走绿道，不要爬坡结果：
路线说明：优先选择绿道路段较长的路线；坡度信息暂无法验证。由于高德当前返回结果没有海拔和坡度字段，系统不会虚构“低坡度路线”，而是明确提示数据边界。
测试四：未提供目的地
输入：
开始导航结果：
请告诉我您想骑行前往的目的地。十三、当前版本能力边界
当前 RideGuard 已经完成：
- 自然语言骑行导航；
- 目的地提取；
- 骑行偏好识别；
- POI 搜索；
- 高德真实路线调用；
- 多路线比较；
- 绿道路段统计；
- Rokid 眼镜端结果展示。
当前版本还不是完整的实时实景 AR 导航。
尚未完成：
- GPS 持续更新；
- 当前路段识别；
- 转弯倒计时；
- 偏航重算；
- 真实道路空间锚定；
- 箭头与现实道路的空间对齐。
因此，当前产品更准确的定位是：
面向 Rokid 眼镜的骑行路线规划与导航决策 Agent。
而不是已经完成的厘米级实景 AR 导航系统。
十四、下一阶段技术路线
下一阶段将分为三个层级推进。
第一阶段：动态起点
由手机或 Rokid 获取实时经纬度：
longitude + "," + latitude替换当前固定origin。
第二阶段：逐路口导航
保存高德返回的 steps，并根据当前位置判断当前所在路段：
当前GPS → 匹配最近路线段 → 获取当前step → 输出下一步转向指令第三阶段：偏航重算
当用户位置与规划路线距离超过阈值时：
检测偏航 → 更新起点 → 重新调用路线API → 刷新眼镜端导航信息第四阶段：视觉 AR 辅助
结合 Rokid SDK、摄像头和姿态传感器，实现：
- 路口识别；
- 道路方向辅助；
- 虚拟导航箭头；
- 路线与现实场景叠加。
十五、总结
RideGuard 并不是简单地将手机地图投射到眼镜上，而是在传统 HUD 导航之上增加了一层面向骑行场景的 Agent 决策能力。
项目通过 GPASS 将自然语言理解、POI 插件、高德路线 API、代码决策节点和 Rokid 眼镜显示串联起来，实现了：
一句话输入 → 自动理解目的地与偏好 → 获取真实骑行路线 → 比较多条候选方案 → 输出适合眼镜端阅读的导航结果最终形成一套可解释、可扩展、可演示的骑行导航 Agent 技术方案。
