一、项目背景

在出行和日常生活中，用户经常需要查询铁路乘车规定、民航携带物品要求、实时天气、附近餐饮、酒店和景点等信息。传统手机查询需要经历解锁、打开应用、输入关键词和筛选结果等步骤，在双手被占用或身处陌生环境时并不方便。

本项目基于 Rokid AI 眼镜打造了一款多模态智能 Agent。用户可以直接通过眼镜拍摄当前看到的物体或场景，并结合文本问题发起查询。系统优先从铁路、民航等专业知识库中检索可靠信息，再根据问题类型调用实时天气、高德周边搜索、本地生活、食物营养分析、计算器和知乎热榜等插件，最后由多模态大模型综合图片、文本、知识库结果与插件结果，生成简洁、自然且符合当前场景的回答。

项目的核心目标是：

将“看到问题—查找信息—理解结果—获得答案”的过程压缩为一次自然交互。

二、核心功能

1. 铁路与民航规定查询

系统内置铁路、民航等出行规定知识库，可以回答：

• 充电宝是否可以带上飞机；
• 行李尺寸、重量和数量限制；
• 液体、化妆品和食品携带规定；
• 高铁禁止、限制携带物品；
• 儿童票、行李托运等常见问题。

系统优先匹配知识库内容，减少大模型凭借通用知识直接作答可能产生的信息偏差。

2. 图片与文本联合理解

Rokid AI 眼镜可以拍摄用户当前看到的物品或场景，例如：

• 拍摄充电宝并询问能否登机；
• 拍摄食品并询问营养成分；
• 拍摄景区周边环境并查询附近餐厅；
• 拍摄商品包装并进行数值换算。

图片负责提供真实场景信息，文本负责表达用户意图，两者共同发送给多模态大模型进行理解。

3. 实时信息及生活服务查询

对于知识库无法覆盖、需要实时数据的问题，Agent 会自动选择相应插件，例如：

• 查询实时天气；
• 搜索附近景点、美食、酒店和运动场所；
• 获取本地生活店铺；
• 查询食材营养信息；
• 完成精确数值计算；
• 获取知乎实时热榜。

三、系统总体架构

系统采用“端侧感知 + 云端检索与推理 + 插件能力扩展”的架构。

整体可以划分为四层：

1. 感知交互层：获取 Rokid AI 眼镜拍摄的图片和用户文本。
2. 任务编排层：识别查询意图，决定调用知识库、插件或直接使用大模型。
3. 能力服务层：提供知识库检索、实时数据插件和多模态推理能力。
4. 结果呈现层：将回答转换为适合眼镜端阅读或播报的内容。

四、工作流设计

1. 输入采集

端侧将以下信息组合为一次 Agent 请求：

• 用户拍摄的图片；
• 用户输入的文本问题；
• 经用户授权后获取的当前位置；
• 当前时间等必要上下文；
• 多轮对话历史。

示例：

{
  "question": "这个充电宝可以带上飞机吗？",
  "image": "Rokid AI 眼镜拍摄的充电宝图片",
  "location": "上海市浦东新区",
  "timestamp": "2026-07-15 10:30:00"
}

2. 意图识别

Agent 首先判断问题属于哪一种任务：

• 铁路规定查询；
• 民航规定查询；
• 天气查询；
• 周边地点搜索；
• 本地生活服务；
• 食物营养分析；
• 数值计算；
• 知乎热榜查询；
• 普通图片问答。

意图识别结果决定后续的知识库与插件调用路径。

3. 知识库优先检索

对于铁路、民航等专业规定问题，系统首先对用户问题进行语义检索，获得最相关的知识库内容。

基本流程如下：

用户问题
  ↓
问题规范化与关键词提取
  ↓
向量检索/关键词检索
  ↓
相关性排序
  ↓
获取高相关知识片段
  ↓
作为大模型回答依据

例如，用户询问“这个充电宝能否上飞机”，系统会重点检索：

• 充电宝额定能量限制；
• 充电宝是否可以托运；
• 超过规定容量时的处理方式；
• 标识不清晰产品的相关要求。

如果知识库命中结果达到设定阈值，模型必须优先依据知识库回答；如果未命中，则明确提示用户当前没有检索到可靠规定，避免生成过度确定的结论。

4. 图片信息提取

多模态模型分析 Rokid AI 眼镜拍摄的图片，提取回答所需的信息，例如：

• 充电宝外壳上的容量、电压和额定能量；
• 食品或食材类别；
• 商品包装上的单位和数值；
• 用户所在场景和可见物体。

对于充电宝，可以通过以下公式计算额定能量：

额定能量（Wh）= 电池容量（mAh）× 标称电压（V）÷ 1000

涉及计算时交由计算器插件完成，避免大模型直接计算造成数值错误。

5. 插件路由与调用

当问题需要外部实时数据或专业服务时，Agent 根据意图自动调用插件。插件返回结构化结果后，系统再交给大模型进行整理，而不是让大模型自行生成实时信息。

6. 上下文组装

系统将以下内容统一组织成模型上下文：

• 用户文本问题；
• 用户拍摄的图片；
• 知识库检索结果；
• 插件返回结果；
• 用户位置与时间；
• 回答格式要求；
• 安全和真实性约束。

模型回答时遵循以下优先级：

权威知识库/插件实时数据
        ↓
图片中能够明确识别的信息
        ↓
用户提供的文本信息
        ↓
大模型通用知识

当不同来源之间存在冲突时，优先采用知识库或实时插件结果，并向用户说明信息来源和适用条件。

7. 答案生成

智能眼镜的显示空间和用户注意力有限，因此最终回答采用“结论优先”的方式：

1. 第一行直接给出结论；
2. 第二部分说明关键依据；
3. 必要时补充条件或风险提示；
4. 内容较长时先给摘要，再允许用户继续追问。

例如：

可以随身携带，但不能托运。图片中显示该充电宝额定能量为 74Wh，处于一般可携带范围内。实际执行以航空公司及机场安检现场要求为准。

五、端侧能力设计

Rokid AI 眼镜端主要承担感知、交互和轻量预处理任务。

1. 图片采集

通过眼镜摄像头获取第一视角图像。拍摄时可引导用户：

• 将文字或物体放置在画面中央；
• 保持画面稳定；
• 确保容量、规格等关键信息清晰可见；
• 信息模糊时重新拍摄。

2. 图片预处理

在上传前可进行：

• 图片尺寸压缩；
• 清晰度检查；
• 图像方向校正；
• 敏感信息遮挡；
• 无效图片过滤。

这样既能降低网络传输压力，也能减少无效的云端推理请求。

3. 文本与上下文采集

端侧将用户问题与图片绑定，防止连续拍摄时发生图片和问题错位。同时维护必要的会话标识，用于支持多轮追问。

例如：

用户：这个能带上飞机吗？
Agent：图片中像是一个充电宝，但容量标识不够清晰，请靠近后重新拍摄。
用户：现在可以看清吗？
Agent：可以，标识显示为 20000mAh、3.7V，换算约为 74Wh……

4. 结果呈现

回答可根据设备能力通过文字、语音或二者结合的方式呈现。对于眼镜端，内容应尽量短句化，避免一次显示大段文字。

六、云端能力与插件运用

1. 实时天气插件

用于获取指定地区的实时天气信息，适合以下场景：

• “我这里今天会下雨吗？”
• “去机场路上需要带伞吗？”
• “明天适合户外运动吗？”

插件提供温度、天气状况、风力等实时数据，大模型负责将其转换为自然的出行建议。

2. 高德服务／周边搜索插件

根据指定地点和关键词搜索附近地点，包括：

• 景点；
• 美食；
• 酒店；
• 商场；
• 医院；
• 运动场所；
• 交通设施。

示例：

“帮我找附近的面馆。”

Agent 获取当前位置后，以“面馆”为关键词调用周边搜索，并结合距离、店铺类型等信息生成推荐结果。

3. 本地生活插件

用于获取本地生活相关店铺与服务，例如：

• 当地特色美食；
• 酒店住宿；
• 特产商店；
• 生活服务门店。

高德周边搜索偏重位置与地点检索，本地生活插件偏重店铺和消费服务信息。Agent 可以根据问题类型选择其中之一，必要时组合调用。

4. “知食”食物营养分析插件

该插件根据食材名称关键词查询匹配的食材列表，返回最多 30 项结果，其中包含：

• 食材 ID：foodCode；
• 食材名称：foodName。

第一次调用示例：

{
  "keyword": "牛肉"
}

返回结果示例：

[
  {
    "foodCode": "FOOD_001",
    "foodName": "牛肉（瘦）"
  },
  {
    "foodCode": "FOOD_002",
    "foodName": "牛肉（肥瘦）"
  }
]

当返回多个相似食材时，Agent 不直接猜测，而是结合图片进行判断，或者请用户确认具体类别，再获取后续营养信息。

典型问题包括：

• “这是什么食材？”
• “牛肉的蛋白质含量怎么样？”
• “减脂期间适合吃这个吗？”

营养分析结果仅作为日常饮食参考，不替代医生或专业营养师建议。

5. 计算器插件

用于完成准确的数值运算，例如：

• 充电宝 Wh 换算；
• 单位换算；
• 营养摄入量计算；
• 距离、时间和价格计算；
• 多项费用合计。

设计原则是：凡是能够表达为明确公式的计算任务，优先调用计算器插件，不依赖大模型直接计算。

6. 知乎热榜插件

用于获取知乎实时热榜列表，可以回答：

• “今天有什么热门话题？”
• “现在大家都在关注什么？”
• “帮我总结一下今天的知乎热榜。”

插件负责提供实时榜单，大模型负责对榜单进行分类、摘要和口语化表达。对于热点事件，Agent 会区分“热榜内容”和“已经核实的事实”，避免把讨论热度直接等同于事实结论。

七、插件路由策略

用户意图	首选能力	是否需要位置	是否需要图片
铁路、民航规定	专业知识库	否	可选
当前天气	实时天气插件	是或提供城市	否
附近景点、酒店、餐厅	高德周边搜索	是	可选
本地店铺、特产、美食	本地生活插件	是	可选
食材识别与营养查询	多模态模型 + 知食插件	否	推荐
单位或公式计算	计算器插件	否	可选
当前热门话题	知乎热榜插件	否	否
场景或物体识别	多模态大模型	否	是

如果用户同时提出多个需求，系统可以进行任务拆分。例如：

“看看这是什么食物，分析一下营养，再帮我找附近可以吃到它的店。”

系统会拆分为：

1. 使用图片识别食物；
2. 调用“知食”插件查询营养信息；
3. 调用高德周边搜索或本地生活插件查找附近店铺；
4. 由大模型整合为一份回答。

八、技术方案说明

1. RAG 知识库方案

铁路和民航规定具有专业性，并且可能随时间调整，因此系统采用检索增强生成，即 RAG 方案。

知识库建设流程包括：

1. 收集铁路、民航等规定文件；
2. 按标题、条款和语义进行文本切分；
3. 为文档添加来源、发布日期、适用范围等元数据；
4. 将文本转换为向量并写入向量数据库；
5. 根据用户问题召回相关内容；
6. 将召回结果交给大模型生成回答。

推荐保存的元数据包括：

{
  "category": "民航规定",
  "title": "旅客携带充电宝相关规定",
  "source": "规定来源",
  "publishDate": "发布日期",
  "effectiveDate": "生效日期",
  "region": "适用地区",
  "content": "具体条款内容"
}

通过记录来源和更新时间，可以在回答中提示规定的适用范围，也方便后期更新知识库。

2. 混合检索

单纯使用关键词检索可能无法识别“充电宝”和“移动电源”等近义表达，单纯使用向量检索又可能召回语义相近但不够准确的内容。因此可以采用：

• 关键词检索；
• 向量语义检索；
• 结果重排序；
• 相似度阈值过滤。

混合检索可以提升专业条款的命中率。

3. 多模态推理

多模态模型主要承担三个任务：

• 理解图片中的物体、文字和场景；
• 理解用户问题及其真实意图；
• 综合知识库与插件结果生成自然语言回答。

图片识别结果如果不够清晰，模型必须说明不确定性。例如使用“图片中疑似”“当前无法确认”等表达，并引导用户重新拍摄，而不是强行判断。

4. Agent 工具调用

系统将每个插件封装为标准化工具，描述其名称、输入参数、返回结构和适用场景。Agent 根据用户意图选择工具，并对调用结果进行检查。

伪代码如下：

def handle_request(question, image=None, location=None):
    intent = classify_intent(question, image)

    knowledge = None
    plugin_result = None

    if intent in ["railway_rule", "aviation_rule"]:
        knowledge = search_knowledge_base(question)

    if intent == "weather":
        plugin_result = query_weather(location)

    elif intent == "nearby_search":
        plugin_result = search_nearby(location, extract_keyword(question))

    elif intent == "local_life":
        plugin_result = search_local_service(location, question)

    elif intent == "food_nutrition":
        food_name = recognize_food(image, question)
        plugin_result = search_food(food_name)

    elif intent == "calculation":
        expression = build_expression(question, image)
        plugin_result = calculator(expression)

    elif intent == "zhihu_hot":
        plugin_result = get_zhihu_hot_list()

    return multimodal_model_generate(
        question=question,
        image=image,
        knowledge=knowledge,
        plugin_result=plugin_result
    )

5. 回答约束

系统提示词中应明确要求：

• 知识库命中时必须以知识库内容为主要依据；
• 实时信息必须来自插件结果；
• 不得编造未返回的店铺、天气、榜单或规定；
• 无法识别图片时主动说明；
• 专业规定应提示适用范围和更新时间；
• 涉及安全、健康时给出必要风险提示；
• 回答适合眼镜端快速阅读。

九、典型应用流程

场景一：拍摄充电宝并查询登机规定

Rokid AI 眼镜拍摄充电宝
  ↓
用户询问“这个可以带上飞机吗”
  ↓
模型识别容量和电压
  ↓
计算器换算额定能量
  ↓
检索民航规定知识库
  ↓
综合容量、规定和图片可信度
  ↓
输出是否可携带及注意事项

场景二：查询附近餐厅

用户询问“附近有什么好吃的”
  ↓
获取授权后的位置
  ↓
识别用户偏好或继续询问关键词
  ↓
调用高德周边搜索/本地生活插件
  ↓
按照距离和类型整理结果
  ↓
返回适合用户选择的店铺列表

场景三：食物营养分析

用户拍摄食物
  ↓
多模态模型识别食材
  ↓
调用知食插件搜索候选食材
  ↓
结合图片选择或请用户确认
  ↓
获取并整理营养信息
  ↓
给出日常饮食参考

十、异常处理与隐私保护

1. 知识库未命中

当相关性不足时，系统不会将低相关内容强行作为依据，而是提示：

当前知识库中没有检索到足够可靠的对应规定，建议以铁路、航空公司或现场工作人员的最新要求为准。

2. 图片不清晰

如果容量、包装文字等关键信息无法识别，系统引导用户靠近、调整角度或重新拍摄。

3. 插件调用失败

实时插件不可用时，应明确说明暂时无法获得实时结果，不使用历史信息伪装成当前数据。

4. 隐私保护

眼镜图像可能包含人脸、车牌、票据和位置信息，因此系统应：

• 仅采集完成当前任务所需的数据；
• 在获得授权后使用位置；
• 对传输数据进行加密；
• 尽量缩短图片保存周期；
• 支持敏感信息遮挡和请求记录清理；
• 避免在回答中暴露无关个人信息。

十一、项目亮点

1. 知识库优先：铁路、民航等专业问题先检索可靠资料，降低大模型幻觉。
2. 多模态交互：将 Rokid AI 眼镜的第一视角图片与用户问题结合，实现“看到什么就问什么”。
3. 插件化扩展：天气、地图、本地生活、营养、计算和热榜能力可以独立升级。
4. 任务自动路由：用户不需要手动选择功能，Agent 自动判断应该调用哪项能力。
5. 适配眼镜场景：采用结论优先、短句表达和多轮追问，减少用户阅读负担。
6. 实时与专业兼顾：知识库解决专业规定问题，云端插件补充实时生活信息。
7. 结果可解释：回答不仅给出结论，还说明依据、条件和不确定性。

十二、总结

本项目通过 Rokid AI 眼镜获取用户第一视角图片与文本问题，利用知识库检索、插件调用和多模态大模型推理，为用户提供铁路民航规定、天气、周边地点、本地生活、食物营养、数值计算和热点资讯等查询能力。

它不只是将普通聊天机器人放入眼镜，而是通过“端侧感知、知识库检索、工具调用和云端推理”的协同工作，让 Rokid AI 眼镜真正成为一个能够理解现场、查询信息并辅助决策的随身 Agent。