诗途·TraceMuse：AI 眼镜旅游智能体设计方案

作品一句话：让 AI 住进眼镜，陪你走过山河、写下诗篇、记住每一次相遇。

2026/7/14   7:00修改：基于 OpenCLaw 的应用，系统的高风险安全警报已通过真实后端接口实现自动推送——当检测到极高风险场景时，警报信息即时送达后端服务，触发紧急响应链路，打通了从感知到推送的完整闭环。

旅游中的 AI 不应该只是一个“随身问答框”。真正有价值的体验，是用户抬眼看见一座建筑时，系统能识别并讲出它的人文故事；想去某地时，系统能定位、规划并生成诗意描述；遇到危险时，系统能立即停止普通任务并进入安全响应；旅程结束后，还能把真实发生的地点、情绪和故事整理成一首诗或一篇回忆录。这正是“诗途·TraceMus”想解决的问题。

一、为什么“识别图片”还不够

传统旅游助手常见的问题，不是功能数量少，而是功能之间没有连续关系。用户可能先问：“眼前这是什么？”随后追问：“它有什么来历？”走到路口又问：“附近有地铁站吗？”如果每句话都被当成全新问题，AI 就很难成为真正的旅行伙伴。旅游中的核心痛点归纳为五类：抬头看不懂（缺少即时可信的人文解释）、边走边操作困难（不适合持续低头操作）、任务容易断裂（识别、导航、记录分散在不同工具中）、安全优先级不足（普通系统在人遇险时仍输出泛化建议）、旅程结束后没有沉淀（图片、地点、感受没有形成可回顾的记忆）。因此，“目遇”的目标是让系统始终回答三个问题：用户此刻真正想完成什么？当前最应该调用哪个能力？本轮结果是否应该进入后续记忆？

二、产品定位与服务对象

“目遇”是一套面向 AI 眼镜场景的旅游陪伴智能体，以语音为主要交互方式，以眼镜摄像头和定位信息作为环境入口，以百宝箱企业版工作流作为任务中枢。主要服务对象包括：自由行用户、深度旅行者、需要路线和翻译支持的游客、希望自动整理旅行足迹的内容记录者、对复杂界面不熟悉但能用自然语言表达需求的用户。设计中坚持六项原则：视觉优先（用户说“这个”“眼前”时优先结合画面）、语音优先（回答短、自然、适合播报）、安全优先（现实风险永远高于讲解、导航、创作）、事实优先（视觉事实和可靠知识优先于抒情，不虚构）、不伪造执行结果（未接通存储时只提示“可打卡”，不说“已保存”）、最小化采集（定位按任务触发，不做持续性轨迹监控）。

三、总体技术架构

系统被划分为端侧感知层、工作流编排层、云端能力层和未来的数据服务层。

flowchart LR
A[AI 眼镜或手动上传] –> B[语音 图片 经纬度 会话参数]
B –> C[百宝箱企业版开始节点]
C –> D[任务目标识别]
D –> E1[理解与追问]
D –> E2[前往与定位]
D –> E3[解决与安全]
D –> E4[表达与陪伴]
D –> E5[记录与回顾]
E1 –> F1[VL 模型 + 人文知识库]
E2 –> F2[高德地图与天气插件]
E3 –> F3[风险识别与安全分流]
E4 –> F4[文本大模型与翻译能力]
E5 –> F5[结构化整理与打卡判定]
F1 –> G[语音友好回复]
F2 –> G
F3 –> G
F4 –> G
F5 –> G
G -.后续接入.-> H[TraceMuse 云端存储服务]

百宝箱企业版的核心作用是：接收眼镜和会话环境参数、判断任务类别、控制节点执行顺序、按需调用模型和插件、将复杂结果整理成适合语音播报的回答。

四、工作流设计：先判断任务，再调用能力

4.1 九类任务路由

任务路由器必须结合历史对话，但不能被历史内容“绑架”。安全任务拥有最高优先级——如果历史中存在尚未解除的高风险，即使用户提出导航或聊天请求，系统也要继续处理安全问题，直到用户明确表示已安全。

4.2 推荐的主干流程

开始
└─ 任务目标识别
├─ 解决 → 异常类型提取 → 旅行阶段提取 → 风险分流
├─ 前往 → 导航出行助手 → 地图工具调用 → 导航结果
├─ 理解 → 执行参数提取 → 图片来源判断 → 视觉链路或追问链路
├─ 表达 → 创作与翻译模型
├─ 陪伴 → 旅行陪伴回答
├─ 记录 → 手账 JSON 整理 → 保存状态提示
├─ 回顾 → 行程回顾生成
├─ 退出 → 结束
└─ 其他 → 能力说明与重新引导

重要优化：不要让所有参数提取节点并行运行。异常类型只在“解决”分支需要，导航动作只在“前往”分支需要，视觉执行参数只在“理解”分支需要。按分支执行可以减少延迟、模型调用量和无效变量。

五、双视觉链路：兼顾无眼镜调试与真实设备

为了在没有眼镜硬件时仍能开发和测试，系统保留了两条视觉入口：手动图片路线（当前对话图片 → VL 识别 → 知识库检索 → 讲解生成 → 打卡判定 → 最终回复），适用于网页端或调试阶段；眼镜拍照路线（用户要求重新查看 → 拍照采集插件 → 返回图片地址 → VL 识别 → 知识库检索 → 讲解生成 → 打卡判定 → 最终回复），面向真实 AI 眼镜。用户说“再讲讲它的来历”时，依赖的是上一轮已识别的主体，应进入“人文追问回答”而非重新触发摄像头；只有“再看一眼”“看看旁边这个新的”等明确要求新画面的请求，才需要再次拍照。这一区分既减少设备调用，也避免追问时出现上下文丢失问题。

六、视觉识别与人文讲解如何分工

“目遇”没有让一个模型同时完成识别、考据、诗词推荐和最终表达，而是将任务拆成三层。

第一层：VL 模型只做事实观察。输出主体、类别、候选名称、可见特征、环境与光线、可能地点、置信度和检索关键词等固定字段，不能写诗、讲典故或补充画面中不可见的细节。

第二层：知识库提供可核验依据。采用结构化字段（记录 ID、类型、标题、别名、视觉线索、事实、来源等级等），不只存地点，也可以存诗词、人物、建筑类型和地方文化。检索策略采用智能检索、最大返回 5 条、最低匹配度约 0.40、开启语义精排、精排保留约 3 条高相关结果，具体阈值根据测试集调整。

第三层：讲解模型负责组织语言。综合用户问题、视觉结果和知识库结果，输出 80—180 字左右的语音友好回答：先说明眼前主体，再给一至两个最相关的人文知识点，诗词高度匹配时再自然引用，不确定时使用“可能是”“看起来像”，不向用户展示 JSON、字段名和内部计算过程。这种“观察—检索—表达”的分层，比让单一模型自由发挥更容易控制事实边界。

七、端侧能力与云端插件如何协同

端侧负责采集语音或文本请求、获取眼前图片、提供经纬度、设备型号等环境参数、播放云端返回的语音文本。云端负责：文本大模型（任务理解、讲解、陪伴、回顾）、VL 模型（图片识别，收到有效图片后调用）、人文知识库（由视觉或用户关键词触发）、眼镜拍照插件（仅在需要新画面时调用）、逆地理编码（“我现在在哪”或定位打卡时调用）、周边搜索（需要当前位置和设施类型）、路线规划（根据用户指定方式选择）、天气查询、翻译能力、HTTP 请求（对接独立存储服务）。编排原则：先确定任务，再选择最少且足够的工具。例如“我现在在哪”只需要坐标和逆地理编码，不应触发图片识别；“帮我看看眼前这是什么”也不应该默认调用路线规划。

八、导航与定位：把“当前位置”归入前往任务

“我现在在哪”曾被错误路由到视觉识别。优化后统一将位置相关请求划入“前往”：定位问询、附近设施搜索、路线规划、回酒店等。导航回复可保留简短过程提示（如“我先确认你的位置，再搜索附近的地铁站”），避免用户误以为系统卡死，但最终以地图工具返回数据为准。

九、安全分流：危险情况必须打断普通流程

安全响应是整个系统的最高优先级保护层。当用户请求或当前状态涉及现实风险时，系统必须立即停止正在进行的讲解、导航、创作或陪伴任务。

工作流的“解决”分支内置了三个关键节点：异常类型提取（识别身体不适、人身安全、物品丢失、紧急求助等风险类别）、风险评估与分级（极高风险如胸痛伴冷汗、遭遇暴力威胁→立即建议拨打急救电话并给出最近医院位置；高风险如轻微受伤、被跟踪→优先安全响应，不允许返回普通任务；中风险如轻微头晕、钱包丢失→安全响应优先，确认状态后可引导导航；低风险→正常流程）、安全响应生成（第一句话必须是明确的行动指引，避免冗长解释，跨国场景中可提供当地紧急号码，结尾可包含安抚但不能影响核心信息传达）。安全状态具有持续性——历史中记录了高风险但未确认解除时，即使下一轮用户说“帮我查个景点”，系统也应先追问安全状态。在原型实现中，风险判断和分级由大模型在“解决”分支内完成，确保响应延迟最短；高风险警报的推送通过 OpenCLaw 接入真实后端接口，实现从检测到推送的自动化闭环。

十、闭环与后续规划：从原型到完整服务

前九节分别拆解了任务路由、双视觉链路、分层讲解、端云协同、导航定位和安全分流。将这些模块串联起来，才能构成真正的旅行陪伴闭环——从“识别”到“回顾”：用户戴上眼镜游览时，系统识别景点并讲解，用户可追问、收藏诗句、回顾行程，旅程结束后系统根据真实打卡记录生成贴合经历的行程叙事或诗文。

打卡采用三段式流程：定位（获取当前可读地点，不保存）、打卡资格判定（讲解完成后自动校验识别置信度、知识库匹配结果和讲解生成状态，给出“可打卡”提示）、正式保存（用户明确说“收藏”“记下来”后，将地点、时间、讲解摘要等打包发送至 TraceMuse 存储服务）。三段分离的核心原因：前端不能伪造后端能力（存储服务未部署时只说“可打卡”，不说“已保存”）、用户应有最终确认权、定位和打卡是两类不同意图。

当前原型实现状态：已完成九类任务路由、双视觉链路、分层讲解体系、安全分流与 OpenCLaw 高风险警报推送、导航与定位插件接入、打卡资格判定。尚未完成的是 TraceMuse 云端存储服务（后端数据库和 API 正在设计）、回顾生成（依赖打卡记录的持久化数据）、多语言紧急求助（计划作为安全响应增强插件）。

TraceMuse 后端存储规划：核心数据实体包括 Trip（行程）、Place（地点）、Checkin（打卡）、Note（手账）、SafetyEvent（安全事件）、Review（回顾）。数据流向遵循“端侧采集→工作流处理→存储服务落盘→回顾服务读取”的路径，存储服务独立部署，通过 HTTP 请求插件通信，确保工作流升级不影响已有数据、存储可独立扩展备份、未来可复用同一套数据接口。

结语

从“眼前这是什么”到“帮我把这次旅行写成一首诗”，诗途·TraceMus 试图回答的始终是一个问题：AI 眼镜能不能不止于“看见”，还能“懂得”和“记住”？本文拆解的十条设计——从任务路由、双视觉链路、分层讲解、端云协同，到导航定位、安全分流、创作回顾、打卡分离与存储规划——并非孤立的技术选型，而是一套围绕“旅行陪伴”这个核心场景逐步收敛出来的系统方案。原型已经跑通了从识别到讲解再到打卡判定的核心链路，剩下的存储落地和回顾生成，有待后端服务补齐。让 AI 住进眼镜，不是为了让技术变得更炫目，而是为了让每一段旅程，都有人陪你走过山河、写下诗篇、记住每一次相遇。