
作品一句话让 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 住进眼镜不是为了让技术变得更炫目而是为了让每一段旅程都有人陪你走过山河、写下诗篇、记住每一次相遇。