新人笔记---最终版智能体图片分析完整方案，包括一些总结于经验,以及各种优化点讲解

前几篇我们不是做图片分析的内容吗，核心问题是解决视觉模型幻觉问题，这里我们就不再赘述，经过最近几天的研究，博主也是顺利做出了一个完整版的，拥有比较完善的功能，准确性也比较高。因为代码不好展示，博主也是让AI根据自己思路去生成，然后一点一点调试出来的。所以博主这次重点分享的是自己做这个的一些思路以及经验，因为本身对于视觉分析这方面找不到比较好的内容和文章，而且你自己直接问ai怎么去做这个功能，他很难给你一套完整的方案，这个链路是博主一点一点尝试，一点一点摸索，包括初次去了解各种这方面的工具，去亲自测试，接入项目，总结，加上不断优化，测试后实现的一个可用的功能，准确性也比较高，花费了挺大心血，希望决定有用的小伙伴还请点个赞(╭￣3￣)╭♡

一：回顾之前的做法

之前我们是通过serpAPI的反向搜图功能去做的，然后通过返回的帖子的名称，再设立一个专门的AI去进行主题词提取，举个例子：我们上传一张卡提西亚，那么根据以图搜图原则，serpAPI会返回类似图，然后这些类似图本身所在的帖子，很大概率会提及图片中的一些信息，换句话说，就是我们是通过反向搜图功能，基于谷歌引擎极大的数据库，我们能准确获取到相似图片的帖子，然后通过检索这些帖子来获取到图片中的主题信息
我们直接上图

这是博主自己的截图，理论上很难在网上找到一模一样的图片，因为本身就是我们自己的游戏截图

这里是我们调用谷serpAPI，选择google引擎去搜相似图，可以看见他会返回相似的图片的网站，这里我们观察到这些网页标题反复提及Wuthering Waves ,其实这就是鸣朝游戏,是不是就能初步告诉视觉模型，该图片来自鸣朝，初步减小搜索范围，提升精度

这里我们测试一下，随机打开一个相似图链接，可以发现这是其他玩家的截图，是不是和我们的很类似，这就是实现的基本原理。
核心点：上面这些只是演示测试搜索相似图的功能，因为我们上传的图片本身就是我们自己的截图，理论上很难找到一模一样的的，但是如果我们发送的是网络上找的一张图呢，会发生什么？我们测试一下

这就是厉害之处：因为谷歌本身搜索引擎很强大，加上数据很多，他甚至能帮你检索到我们的网上的图片出自哪篇帖子，可以看见他的返回结果就正是我们的图片来源的帖子

二：优化点一

这里我们直接上结论，长话短说，我们经过大量测试后会发现serpAPI的谷歌反向搜图功能，一般我们不指定模式，默认为all,他还有别的模式，不同模式会返回不同字段

经过我们大量实测下来，他极大概率会返回以下两个字段related_content,visual_matches,其中比较重要的是related_content，他就是会返回相关问题，比如我们上传"卡提西亚图片"，他会附加类似的问题，比如卡提西亚喜欢吃啥，卡提西亚爱好等等，他们对于我们提取主题人物很重要，visual_matches返回的就是相似图以及帖子,我们的核心思路是通过相关问题以及帖子名称，适当扩大他们的数量，结合判定AI来提取主题词。这里介意你们自己去阅读官方文档，博主这里只是自己实测后，接入自己项目的做法，他可能会有别的返回形式

这里简单提一下我们是怎么去做的，我们是将serpAPI返回的多个字段，按照可信度由高到低进行排序，这样AI可以明确知道哪些信息很重要，哪些内容可忽略，这么做的原因是因为实测下来，related_content的可信度远高于visual_matches，visual_matches返回的帖子名称来源及其不稳定，就会出现返回的前10个帖子，他们的标题全是无关信息，核心还是因为我们是通过他们的标题来抽取主题词的，及其不稳定，所以再返回给AI是标注他们可信度为low,但是如果帖子来源于高质量网站，比如官网啥的，则标注high，这一块不太好控制，可以适当问问ai的意见

二：优化点二

前面我们是只调用google_lens的API，即基于谷歌来搜索相似图，但是还是有缺点，就是消息来源太单一，我们应该新增其他搜索平台，来交叉验证提取的主题词，更加精确

serpAPI还集合了其他搜索平台的API,这里大家可以自行阅读官网，我们的项目是新增了Bing的搜索引擎

这里我们也是测试一张图片，这里需要说明一下，每个搜索引擎的返回结果不一样，但是测试下来，Bing的搜索效果我个人感觉比googlen强，因为他返回的内容绝大部分是related_content字段，它内部包含了相似图链接。他的好处是因为是相关问题，主题提取远远比我们谷歌依靠帖子名称提取稳定多了，从截图上就可以看见我们上面的两个相关问题都提及了胡桃，直接就确认了主体就是胡桃

这里也是提供一下思路，博主这里描述一下大题思路，就是我们将google和bing搜索的related_content字段收集起来，我们通过交叉验证来过滤和确认高置信度主题，比如bing搜索显示原神胡桃，google返回原神，那么就相互证明实体就是原神胡桃，因为related_content字段本身含金量比较高，所以我们是通过该字段进行交叉验证，这里博主只是提供一个思路，当然这肯定不是最好的办法，但是相比单信息来源已经靠谱一点了，这里大伙可以选取其他更好的方案

三：优化点三

前面我们通过google和bing已经提取了可能包含主题信息的所有信息，这里我们引入AI来进行筛选，根据我们设定的不同优先级的消息来合理提取最可能的主题词

这是我们项目中引入的一部分关于AI主题词提取的代码

java 复制代码

你是一个严谨的视觉线索分析专家，专门负责从复杂、多噪声的 Google Lens + Bing 双引擎反向搜图原始结构化数据中提炼高纯度实体主题词与检索句。

任务优先级（从高到低，必须遵守）：
1. [cross-validated] 标注的线索：双引擎交叉验证命中，可靠性最高
2. related_content.query
3. about_this_image
4. visual_matches.title
5. OCR（仅辅助，不可单独主导结论）

噪声过滤规则（必须执行）：
1. 剔除：口语、按钮文案、无意义数字、时间戳、价格/促销词（如"特价、原装、代购、包邮"）。
2. 隐私边界：禁止识别非公开普通人脸；可识别公开实体（动漫/游戏角色、公众人物、品牌产品、建筑地标、艺术作品）。
3. 若 visual_matches 指向多个明显不同实体，视为冲突，严禁主观猜测唯一答案，必须降置信度。

稳定性硬约束（必须执行）：
1. 主实体"高置信"条件：至少被 2 个不同来源支持；[cross-validated] 标注的线索算作 1 个独立来源；否则不得给 high。
2. 若仅单一来源命中实体，最高只能给 medium。但若该单一来源带 [cross-validated] 标注（即 Google Lens 和 Bing 双引擎均识别到该实体），可放宽给 medium，并在 evidence_check 中注明"双引擎交叉验证"。
3. 低频专有名词（只出现1-2次）只有在"能与图中其他文字/上下文（如所属游戏系列、作品背景）产生语义呼应"时才可入选主实体；若完全孤立且与其他噪声格格不入，则不得锁定。
4. searchQuery 必须包含 entities[0]，且不超过30字。
5. searchQuery 禁止包含价格词、促销词、按钮词、情绪词。

交叉验证线索说明（extraction_reasons 中的标注含义）：
- [cross-validated]：该实体在 Google Lens 和 Bing 两个独立搜索引擎中均被命中，可靠度高
- [high]：来自高权威来源（Wikipedia、IMDb、政府/教育网站等）
- [medium]：来自中等权威来源（新闻媒体、知乎、豆瓣等）
- [low]：来自低权威来源（社交媒体、电商、个人博客），仅供参考
- [bing_only]：仅 Bing 引擎命中，Google Lens 未识别，作为补充线索

输出格式（严格契约）：
你必须且只能输出一个合法 JSON 对象；不得输出 Markdown 代码块，不得输出任何解释文本。

JSON 结构必须严格为：
{
  "evidence_check": "字符串，在这里列出你发现的所有关键线索，并写明它们分别来自哪几个来源（不超过40字，用作思维链缓存）",
  "entities": ["字符串数组，核心公开实体名称；若无则为空数组"],
  "searchQuery": "字符串，用于下一步网页检索，格式通常为：[主实体] [关键属性/上下文]，不超过30字",
  "confidence": "枚举值，只能是 'high' | 'medium' | 'low'",
  "intent_tag": "枚举值，只能是 'ACGN' | 'Celebrity' | 'Product' | 'Landmark' | 'General'"
}

置信度标准（必须遵守）：
- high：核心线索一致，且满足多源支持，无明显冲突。
- medium：有有效线索，但噪声较高或仅单源命中；或低频实体通过弱呼应锁定。
- low：线索严重冲突、无法确认主实体、或输入信息不足。

失败处理（必须原样返回）：
{
  "evidence_check": "未找到任何有效交叉线索",
  "entities": [],
  "searchQuery": "",
  "confidence": "low",
  "intent_tag": "General"
}

这是我们设定的判定提示词，可用性比较高，它不仅严格控制主题词的提取，还会判定是否需要搜索，搜索的问题，这里会接上我们的网络搜索工具，简单说，他会提取出主题词，比如图片人物是胡桃，然后会判断是否要进行搜索，比如胡桃的爱好，胡桃背景等问题，会触发我们项目中的网络搜索工具进行网络搜索，来补充人物知识

四：优化点四（可选）

这一点可做可不做，主要是还是不稳定，博主是想，如果前面交叉验证还是没有提取主题，会有一定概率还是没有成功提取出来，那么我们还可以从返回的帖子中进行网页爬取，比如爬取前几个帖子，然后也交给判定AI,

好处是我们爬取的是完整帖子，搭配我们的候选主题词，那么精确性和成功率大大提高，
坏处是博主经过实测发现，帖子内容有点不稳定，可能全篇都是无用的信息，如果强行塞给判定AI那么可能会出现误判，怎么说呢，有好有坏吧，主要是博主真想不出别的方案了，所以这一块可以选择性去做，不是必须，也是出于性能和收益权衡。

五：优化点五

前面我们已经实现了主题词提取，但是核心问题是，主题词虽然确定了，但是如果直接丢给模型，那么他们还是不认识，因为如果本身模型数据匮乏，那么还是会产生幻觉。那么怎么解决呢，我们的思路就是接入搜索工具，比如Tavily,jina等

这里博主只是展示了一下我们项目中的部分联网搜索工具，基于tavily,分为普通搜索和深度搜索，都是tavily的官方API，博主进行封装后打包成本地工具

为了简洁讲解，我们只展示我们的普通模式的web搜索，可以看见我们是设定了什么时候触发搜索，返回什么信息等等，此外，我们的深度搜索deep-research只有在需要搜索深度网页或者复杂问题才会触发，当主题词确定为胡桃时，就会触发普通模式的联网搜索，来获取胡桃的信息
这里博主核心想说的是：对于网页搜索工具，博主推荐你们直接用tavily和jinaAI,这些博主研究了好久，因为博主项目就是接入他们，经过大量实测后发现真的好用，建议大伙接入他们时，打包成本地tool工具，然后设定工具描述，让AI决定什么时候调用,接入他们后，大伙再加点工具描述，比如主题词提取工具提取完主题词后，可以根据判定AI返回的查询问题来决定是否触发联网搜索, 这样的话就非常智能了，一定一定不要硬编码规则，全程由AI决定什么时候调用这些工具

六：优化点六

上面做完后，其实已经实现了大部分图片识别功能，但是还是有问题，见下图

java 复制代码

## ⚠️ 部分识别 --- 需要您的帮助

经过多轮深入搜索，这是我能确定和无法确定的内容：

| 项目 | 结果 |
|------|------|
| 🎮 **游戏** | ✅ **《鸣潮》（Wuthering Waves）** --- Google Lens + Bing 双引擎交叉验证 |
| 👤 **具体人物** | ❌ 未能识别 |
| 🎬 **场景时间** | ❌ 无法确定 |

---

## 🔍 我已尝试的所有方法

| 尝试 | 结果 |
|------|------|
| 🔍 反向图片搜索（Google Lens + Bing） | 确认游戏为《鸣潮》，未匹配到具体角色 |
| 👁️ 视觉场景分析 | 视觉模型未能返回有效结果 |
| 🌐 图片ID追踪（搜索 `18oAopM`） | 无匹配结果 |
| 🌐 鸣潮角色百科搜索 | 返回全角色列表但无法对应 |
| 🌐 鸣潮场景剧情搜索 | 无法确定与该图对应的具体场景 |

---

## 💡 需要您帮忙描述

由于工具无法解析这张图片中的角色具体特征，如果您方便的话，请告诉我：

- 🎨 **角色外观**：发色、瞳色、发型、服装风格？
- 🌿 **场景环境**：是在花田、海边、城市、森林、还是其他地方？
- ⚔️ **特殊标志**：有没有武器、翅膀、光环、特殊道具？

告诉我一两个关键特征，我就能帮您锁定角色和场景！

---

> ⚠️ 另外再次提醒：上下文中的「月见八千代 / 《超时空辉夜姬》」在现实中 **并不存在**，属于虚构内容，与您提供的任何图片都无关。

这里可以看见，我们发送的图片是鸣朝中的一段剧情,我们目前的功能只能提取主题，知道该图片主题是鸣朝,会触发有关鸣朝的搜索，但是如果用户问图片是哪段剧情，他是没办法获取到的，因为我们目前没法做到了解图片的内容，比如图片的人物，人物的衣服，人物动作，游戏画面等等视觉方面的东西,我们之前做的核心是用来确认图片的主题词，但是这种视觉内容获取不到，从他的返回内容可以看出来。所以这里接需要接入视觉模型

我们这里接入glm-5v-turbo视觉模型（这里只是测试用）

再设立一个新的工具提示词，专门用来做使视觉分析，

java 复制代码

你是一个图片场景分析专家，专门负责对用户上传的图片进行场景理解和视觉元素提取。
你的分析将作为 Agent 后续联网搜索的关键输入------场景信息与反向搜图实体（来自 Google Lens + Bing）互补，共同构成精准的搜索查询词。

【核心职责】
1. 判断图片的场景类型
2. 详细描述场景内容（环境、氛围、正在发生什么）
3. 提取关键视觉元素（物体、人物、文字、特效、标志性符号等）
4. 推测图片来源或背景设定
5. 结合已知实体和场景，生成 2-3 个可供联网搜索的具体查询词

【场景类型定义】
- game_screenshot：游戏画面截图（包含游戏UI、角色、场景等游戏元素）
- real_photo：真实拍摄的照片（自然光影、真实人物/场景）
- artwork：插画、绘画、CG作品、同人图等人工创作
- portrait：人物肖像/自拍（人物为画面绝对主体）
- product：商品图片（产品为画面主体，通常白底或展示背景）
- landscape：自然/城市风景（建筑、山川、街景等）
- other：无法明确归入以上类型的图片

【分析要求】
1. 仔细观察图片中的环境、光线、色彩、人物、物体、文字等所有视觉信息
2. 场景描述要具体、生动，包含环境细节和氛围感受，而非泛泛而谈
3. 如果用户消息中提供了"已知实体"，优先结合实体进行场景关联分析
4. 不要幻想图片中不存在的内容，不确定的信息宁可不说
5. 如果图片模糊、质量极差或完全无法识别，scene_type 设为 "other"，诚实说明

【场景搜索词生成规则】
1. 将已知实体与场景元素组合，生成 2-3 个具体、可检索的搜索查询词
2. 例如：实体"原神,胡桃" + 场景"墓地、夜晚、鬼魂" → "原神 胡桃 传说任务 墓地场景"
3. 搜索词要精确，避免过于泛化（不要生成"游戏 场景"这种无意义宽泛词）
4. 如果没有已知实体，则基于纯视觉线索生成搜索词

【输出格式（严格契约）】
你必须且只能输出一个合法 JSON 对象；不得输出 Markdown 代码块，不得输出任何解释文本。

{
  "scene_type": "game_screenshot",
  "scene_description": "场景的详细描述（环境、氛围、正在发生什么，100字以内）",
  "visual_elements": ["元素1", "元素2", "元素3"],
  "environment": "环境标签（如：夜晚、墓地、阴森、月光）",
  "image_source": "推测的图片来源（如：原神游戏截图、微博实拍、Pixiv插画）",
  "scene_search_queries": ["搜索词1", "搜索词2"]
}

【失败处理（必须原样返回）】
如果完全无法识别图片内容：
{
  "scene_type": "other",
  "scene_description": "无法识别图片内容",
  "visual_elements": [],
  "environment": "",
  "image_source": "",
  "scene_search_queries": []
}

这是我们设定的提示词，这里我们来解释一下执行流程

用户上传图片
主题词提取工具提取主题词
调用视觉分析工具，传入主题词，调用视觉模型分析
视觉模型根据主题词，可以推断出图片的主题来源，比如来源于鸣朝漂泊者，视觉模型分析图片场景等一堆视觉细节，然后视觉模型会将主题词与图片内容进行对应，比如人物是漂泊者，随后生成几个搜索词，调用搜索工具
搜索工具搜索后将最新消息返回给AI,AI进行判定是否需要进行再次搜索
AI进行总结

这里总结一下核心：这里我们是将所有操作打包成本地工具，由AI决定是否执行工具，执行什么工具，比如有了主题词，那么就调用视觉分析工具，有了分析内容，那么判断是否调用搜素工具，全程由AI决策，效果整体比较好，而不是硬编码决策，这里只是提供思路，大伙可以根据自己情况去修改

七：效果展示

java 复制代码

## ✅ 识别成功！图片人物与场景分析

---

## 👤 图片人物：漂泊者（女性）------《鸣潮》

图片中的黑衣女性背影是 **《鸣潮》的玩家主角------「漂泊者」（女性）**，这是游戏的主角，由玩家操控。

| 项目 | 详情 |
|------|------|
| **角色** | 漂泊者（女性 / Rover） |
| **共鸣属性** | 衍射（Aero） |
| **等级** | Lv.60 |
| **身份** | 玩家操控的主角 |
| **状态** | 正在执行主线任务中 |

> 📌 画面左上角 UI 明确标注了 **「漂泊者·衍射」**，确认其为玩家操控的女性主角。

---

## 🎬 场景发生时间

这是《鸣潮》主线剧情中的关键一幕：

| 项目 | 详情 |
|------|------|
| **游戏版本** | **2.2 版本**（2025年3月上线） |
| **任务章节** | 第二章 · 第四幕 |
| **任务名称** | **「圣者，忤逆者，告死者」** |
| **版本标题** | 「真伪倒悬于高塔」 |
| **地点** | 黎那汐塔 · **倒悬高塔** |
| **当前子任务** | 呼唤呼姆（距离目标 41米） |

---

## 🌌 场景描述

漂泊者正置身于黎那汐塔的 **倒悬高塔**之中------这是一座巨大、神圣且充满末世奇幻感的建筑。巨大的欧式钟楼式建筑倒悬于天穹，地面如镜面般反射着金橙色的光芒，两侧矗立着庄严的人形雕像，整个空间笼罩在黄昏般的金色光辉中，氛围肃穆而神秘。

这个场景正是 2.2 版本主线剧情的高潮部分：漂泊者与 **卡提希娅（Cartethyia）** 一同深入倒悬高塔，面对真相、做出抉择。任务描述写道：

> *「倒悬的高塔中，有真相、答案与选择。」*

此处的「呼唤呼姆」是卡提希娅传授给漂泊者的道具，用于在水域附近召唤她的伙伴贡多拉「呼姆」来穿行于高塔之间。

---

## 🔗 剧情关联

这也是之前识别的 **卡提希娅**（上一张图）的核心剧情篇章。在这个任务中，漂泊者将与卡提希娅/芙露德莉斯一同揭开岁主「英白拉多」与鸣式「利维亚坦」纠缠的真相。

---

**参考资料：**
- [任务回顾/圣者，忤逆者，告死者 - 鸣潮WIKI (BWiki)](https://wiki.biligame.com/wutheringwaves/%E4%BB%BB%E5%8A%A1%E5%9B%9E%E9%A1%BE/%E5%9C%A3%E8%80%85%EF%BC%8C%E5%BF%A4%E9%80%86%E8%80%85%EF%BC%8C%E5%91%8A%E6%AD%BB%E8%80%85)
- [呼唤贡多拉 - 鸣潮游戏指南 (Wuthering.gg)](https://wuthering.gg/zh-Hans/guide/adventure/requesting-a-gondola)
- [鸣潮 2.2 主线剧情 - B站](https://www.bilibili.com/video/BV13wZMYoEnK)
- [巴哈姆特 圣者，忤逆者，告死者 全剧情攻略](https://home.gamer.com.tw/creationDetail.php?sn=6116567)

前面是我们的AI的图片分析后的结果，下面是我们的豆包生成的分析结果，可以看见功能已经比较完善，视觉效果比较好了，也比较准确，做的这里博主是真的开心，图片分析终于开始像样了

八：后续优化

因为我们本身已经包含了相似图获取功能，因为本身是基于serpAPI的以图搜图功能实现了主题词提取。前面也验证了他们返回的确实是相似图，所以后续我们可以适当提取出相似图，返回给用户，就是个简易版的推送类似图功能，这一点就类似于豆包，你上传图片后，他会推送给你相似图

九：链路核心优点

1.基于google_len和bing以图搜图，他们本身内部就有庞大的数据库以及优秀的搜索引擎，理论上只要用户上传的是网页的图片，不是用户自己的图片，那么很高概率会成功检索到原图或者极其相似图
2.通过bing和google_len交叉验证主题词，比单一来源更加可靠
3.引入判定AI，并设立严格提示词来控制输入输出格式，主题词提取更加可靠
4.引入联网搜索工具，并设立普通和深度搜索功能，根据主题词提取以及建议的询问问题进行知识补充
5.引入视觉模型，并设立严格提示词，根据图片主题词和图片视觉内容分析进行更加可靠的图片识别，并生成可能的搜索词，再次调用搜索工具进行知识补充
6.将所有工具打包成本地工具，全程避免硬编码，由AI自主调用，自主编排，自主生成搜索词，自主调用各种工具，来实现整体的图片分析功能

这一套链路真的是博主研究了几个星期的，从啥也不会到摸索，到寻找工具，到研究工具API,到接入项目，优化，编排，再优化，测试等实现的一套可用的比较让博主满意的图片上传功能，整合了AI的建议以及不断优化，整体效果比较好
大伙可以自己适当选取自己关注的部分，本链路肯定会有更好的优化方案，但是博主已经尽力了，已经燃尽了