企业官网建设流程全解析

用户发来一张设备故障截图，附带一条语音说"这里闪红灯是什么情况"——我盯着界面想了很久，之前做的Agent只能处理文字，这一下就哑火了。那段时间我意识到，当 Agent 需要处理多模态输入时，它面对的根本不是"能不能识别"的问题，而是整条数据处理链路、上下文管理逻辑和交互策略都要重新设计。这篇文章就围绕这件事展开：多模态输入有哪些真实形态、三条主流技术路线怎么选、接入后哪些坑避不开、以及怎么验证它真的"看懂了"，希望对正在给Agent加"眼睛"和"耳朵"的你有点帮助。

1. 当用户直接发来一张图：Agent多模态输入的四种真实形态

纯文本Agent看到的世界，是已经被压缩过一轮的"二手世界"。用户把想说的东西先转成文字，Agent再在文字上做推理。多模态输入打破了这层约束，用户直接把原始世界丢过来：一张照片、一段录音、一份带排版的PDF、一段录屏。处理这些输入，难点不在识别，而在识别出来之后Agent根本不知道该把注意力放在哪。

1.1 截图与照片：最普遍也最容易翻车的一类

截图在客服、运维、产品反馈场景里出现频率最高。用户不会写"我的页面布局乱了"，他会直接甩一张截图告诉你"你看这个"。图像是非结构化数据，没有固定的行文顺序，Agent要先判断图里谁是前景谁是背景、哪块是重点哪块是装饰，这个能力比很多人想象中难。

实操中照片类的坑比截图更多。设备故障照片往往有光线问题、拍摄角度倾斜、目标物占比小，还有镜像翻转。之前我们测试时，用户拍了一张设备面板，因为手机拿反了，左右镜像，Agent居然把左排的故障灯状态理解成了右排，回头对原图才发现不对劲。照片里的多目标也容易让Agent抓错重点，画面里有三台设备，用户想问的是最右边那台，Agent却对着最显眼的那台分析了一堆。

对截图和照片，比较可靠的做法是：先做一次分块理解，把图像切成若干区域，然后提取"版面线索"和"文字线索"两类信息，再合成为结构化的图像描述。不要让Agent直接对着"一整张大图"做开放式的"你看到了什么"，而是带着任务去读图，比如"请描述画面中所有红色指示灯的位置和状态"。任务化的读图比开放式的效果好一个量级。

1.2 语音与音频：被"转文字"掩盖的时序信息

语音输入最容易被低估，因为大多数人默认"语音转文字再丢给Agent就完事了"。这个方案能跑通基础对话，但会漏掉两类关键信息：一是语气和停顿，用户说"这个功能真的能用吗"和"这个功能真的能用吗"，重音位置不同，态度完全两样；二是同音字和专有名词，维修场景里"主板"和"主板上"之间，转写经常会错。

更好的做法是让语音转写和文本理解走两路。一路是ASR输出的文字内容，用于提取语义信息；另一路是音频的一些声学特征，比如语速、能量变化、停顿时长，用于判断用户情绪的紧急程度。售后场景里，用户语气急促的时候，Agent应该优先给出安抚性话术，而不是按部就班地列排查步骤。

有一个很实际的细节：语音输入要带"断句感知"。用户说了一长段语音，转写完成后是一大坨没有标点的文字。如果Agent直接把这段文字丢进上下文，效果会明显变差。建议在预处理时做一次句子切分，并且保留每句话之间的时间间隔信息，时间间隔长的地方往往是话题切换点。

1.3 PDF与Office文档：披着文本外衣的复杂版面

PDF是另一个重灾区。很多人第一反应是"PDF不就是文本吗，直接抽出来就好"。实际上PDF里的信息是排版决定的，页眉页脚、表格、图表、分栏、文本框，纯抽文本会把一个三列对比表格抽成一行行毫无关联的文字，原文的对照关系荡然无存。

我处理PDF的经验是：小文件用版面分析模型先识别结构，再按"标题—段落—表格—图片"分块提取；大文件要结合检索，不能全塞给Agent。有一个很典型的bad case：用户上传了一份产品说明书，想查某个型号的最大负载。说明书里有一段是历史版本对比表，Agent把参数抽出来后，把上一代产品的数值当成了当前型号的。原因是表格抽取时表头和行没有对齐，数字虽然识别出来了，但绑定错了对象。

Office文档（Word、PPT）比PDF更隐蔽，它们有真实的层级信息但大多数抽取工具只取纯文本。尤其是PPT，一页幻灯片的核心信息往往藏在备注里、图示里、排版的相对位置上，纯文本抽取基本等于把金矿当沙子筛了。

1.4 视频与录屏：高成本的时间维输入

视频和录屏是多模态里成本最高的输入。画面在一秒里有十几帧到几十帧，整段视频全分析不现实，必然要做抽帧。但抽帧策略直接决定了Agent能读到什么。之前某团队做过一个故障排查Agent，用户录了一段20秒的设备启动视频，Agent只在视频第1秒和第19秒抽了帧，结果中间的报错日志完全没看到，判断出来的是"设备正常启动"。

对Agent来说，视频输入要拆成三层理解：画面层抽关键帧做视觉描述；文字层把视频里出现的字幕和界面文字OCR出来；动作层判断操作顺序，比如"用户先点了设置，再点了网络，然后停留在Wi-Fi列表"，这其实比画面上有什么更重要。

后面我会提到，多模态输入一旦混合出现，上下文管理的复杂度会指数级上升，这也是很多Agent项目卡住的真正原因。

2. 三条主流改造路线：借工具、换模型、拆分工

给Agent加多模态能力，业内目前有三种主流做法。我把它们称为"借工具""换大脑""拆分工"，分别对应附加解析工具、原生多模态模型和多Agent协作三条路线。三条路线都需要改造数据链路，但改造成本、效果上限和踩坑点完全不同。

2.1 附加解析工具：纯文本Agent的中间人方案

这是最轻量的一种。保持原有文本Agent主链路不变，在入口处加一个多模态解析服务，把图像、音频、文档统一转换成文本描述，再喂给Agent。图像走视觉描述模型输出"图上有什么"，语音走ASR转文字，PDF走版面解析出结构化文本，然后全部以文本形式进入原有对话流。

这个方案最大的优点是几乎不改变下游逻辑，Prompt、知识库检索、对话管理全部复用。缺点是信息损耗非常严重。视觉描述模型输出的描述性文本，本质上是一次"有损压缩"，描述里不会包含图片里所有像素信息。比如用户发来一张错误代码截图，描述模型可能只写了"屏幕上有一串红色文字"，具体错误码被压缩掉了。为了补救，通常把OCR结果作为补充文本一并送入，也就是"描述文本+原始识别文本"双保险。

这个方案适合多模态请求占比不超过20%、单次请求对准确率要求没那么极端的场景。我自己的实践感受是：它最大的价值不是效果，而是让一个已经跑了一段时间的文本Agent可以快速获得感知外部世界的能力，后面再逐步升级。

2.2 原生多模态模型：一次性替换的利与弊

第二条路线更彻底，直接换成本身就支持图像、音频、文本混合输入的大模型。这类模型在多模态推理上有明显优势：它能直接看到"图里的关键信息"和"用户的话"之间的关联，不需要先经过一层描述转换。比如用户指着截图里某个按钮说"这里的文案改一下"，原生模型能建立"指代"关系，而借工具方案需要先猜测用户指的是哪里。

但原生多模态模型也有三个实际问题。第一是历史上下文里的图像存储问题，每轮消息都带图，token消耗会非常快，运营成本直线上升；第二是图像细节的感知上限，即便是当前比较强的多模态模型，对于小字号文字、低对比度区域、密集表格，依然会看漏看错，所以通常还要叠加OCR工具来弥补；第三是系统提示词的适配，原有文本系Prompt中的一些技巧，比如"请基于以下文本回答"，在多模态场景下要重新调整，得改成"请同时结合图片和文字信息"。

从选型上看，原生多模态模型投入产出比最高的场景是：交互频次高、单次交互信息密集、对指代理解要求高的产品。它也是最接近"人类助理"体感的一条路线，只是成本也最接近"人类助理"。

2.3 多Agent分工：视觉Agent+规划Agent的解耦思路

第三条路线是把多模态能力拆成多个Agent协同完成。一个视觉Agent专门负责"看"和"描述"，一个规划Agent负责"想"和"决策"，一个文本Agent负责知识检索和话术生成。用户上传图片后，先由视觉Agent产出结构化信息，再交给规划Agent决定下一步动作。

这条路线解耦清楚、每个Agent的职责单一，效果上往往最好。但工程复杂度确实最高：链路变长了，延迟会叠加，每个Agent之间的输出格式要约定，协调成本明显增加。调试的时候经常出现这种情况——视觉Agent描述对了，规划Agent理解错了，或者规划Agent决策对了，知识检索Agent没找到对应的文档，你很难判断问题到底出在哪个环节。

我在一个售后场景项目里试过这条路线，直观感受是：能不出问题的时候一切都很顺，一出问题排查难度成倍增加。所以除非团队有足够的调试工具和耐心，否则不建议一上来就搞多Agent。

2.4 选型决策表与我的建议

我这里整理了一张决策表，你可以根据自己项目的状态直接对照：

如果是已经有了文本Agent、想快速验证多模态刚需，先走附加工具路线；如果产品本身就是交互型的，用户提问里频繁出现"这里""这个区域"，直接上原生多模态模型；只有当你明确知道不同模态需要不同处理策略时，才考虑多Agent分工。

3. 多模态接入后的四个深层坑：从输入到上下文管理的实战复盘

选型只是第一步。真正让我熬夜的，是接入一个多模态API或者换完模型之后遇到的那些"理论上不该有问题"的异常。下面这四类问题，我在实际项目中都踩过，单独拿出来讲讲排查链路。

3.1 图像压缩与分块：清晰度问题的排查链路

第一个坑是"模型明明支持图片，但小字就是看不清"。用户上传一张管理后台的全屏截图，截图里有一个表格，表格里的字号非常小，Agent回答的时候把某一个数值看错了。一开始我以为是模型能力不够，后来排查发现，问题出在上传环节的自动压缩。

很多Agent框架在接收图片时会默认做尺寸压缩，比如超过一定像素就等比缩小，压缩比例一大，小字彻底糊了。排查链路是这样的：

先确认上游有没有做尺寸压缩，检查上传接口的图片处理逻辑（比如是否经过thumbnail处理）；再确认调用多模态模型时图片的输入尺寸是什么，是base64原始图还是已经被改写的图；最后单独把这张图喂给视觉模型，不带任何Prompt，只看它能不能读出小字。

我最终采用的方案是"原图+局部放大"双路径。全图用于把握大局，同时把用户可能关心的区域（通过坐标或滑动窗口裁剪）放大后再送一次。代价是请求数增加，但准确率提升非常明显。

3.2 多模态消息历史的存储与按需回溯

文本对话的历史消息很好处理，每轮存字符串就行。但多模态会话里，历史消息可能包含图片、语音、文档附件，如果全部原样保留，上下文窗口会迅速被撑爆。

我碰到过的最典型问题：一次会话里用户发了三张图，每张图都做了详细描述，加上中间的文本往返，上下文已经接近模型的上下文上限。到第三轮的时候，Agent开始"遗忘"第一张图的内容，后来再问，它干脆回答"没有收到过该图片"。实际原因不是模型记忆差，而是图片在历史消息里被压缩或者被移除了。

我的处理思路是分层存储+按需回溯。会话中保留两种内容：一是每张图片的高质量文本描述（在图片进入上下文时实时生成并缓存）；二是图片本身，放在外部存储里，通过引用ID标识。每次发起模型调用时，默认只带文本描述；当判断到用户正在追问某张具体图片的细节时，再把原图注入上下文。控制逻辑可以是一个简单的判断规则：如果用户消息里出现了"刚才那张图""这个细节"，就把对应图片重新注入。

3.3 模态时序：先看图还是先读字对结果的影响

第三个坑非常隐蔽。用户的输入是多模态的，但不同模态进入Agent的先后顺序不一样，最后的行为也会不一样。我做过对比实验：同一次请求，一种是"图片在前、文字在后"，另一种是"文字在前、图片在后"，结果Agent的回答侧重点有明显差异。

场景是这样的：用户上传一张产品外包装实拍图，配文"帮我确认这个批次是不是有问题"。图片在文字之前时，Agent倾向于先说"我看到包装上有一些磨损"，然后去分析批次；文字在图片之前时，Agent会先关注"批次问题"，再去看图片里有没有批次信息。结果是后者明显更贴合用户意图。

这说明用户的文本指令应该作为优先级最高的"任务锚点"。多模态数据是原料，文本指令才是加工要求。在构造Prompt时，应该把用户文本指令放在显眼位置，并显式要求模型"先理解任务，再检查图片中与任务相关的区域，忽略无关内容"。系统提示词里加一句话，效果立竿见影："在回答前先明确用户的任务目标，再决定观察图像中的哪些部分。"

3.4 工具回传多模态结果的二次理解断层

第四类问题出现在Agent调用外部工具、工具返回的结果本身是多模态数据时。很多Agent支持调用图像生成、语音合成、图表绘制工具，工具有结果后，Agent还需要对结果做一次"理解"，然后向用户转述。这个转述环节经常出现断层。

举例：Agent调用了一个绘图工具，生成一张柱状图，然后它对用户说"图表已生成"。它并不知道图里数据的高低关系，因为绘图工具返回的是图片文件，Agent看不到内容，只能"假装看到了"。

解决办法是在工具结果返回时，主动附带上"机器可读的结构化数据"。比如绘图工具返回图片时，同时返回数据源JSON：

{ "chart_type": "bar", "series": [ {"label": "方案A", "value": 68}, {"label": "方案B", "value": 42}, {"label": "方案C", "value": 87} ], "insight": "方案C数值最高，方案B最低" }

这样Agent就可以基于结构化数据向用户转述，而不是对着图片瞎猜。工具结果的多模态和输入的多模态一样重要，都要保证Agent能真正"读取"到数据信息，而不是只拿到一个文件引用。

4. 改造实录：售后Agent多模态升级的完整过程

前面讲的都是方法，这部分讲一个具体项目。我们给某设备厂商做了一个售后支持Agent（就叫它"售后助手"），最开始是纯文本FAQ问答，后来用户需求越来越多，很多人直接拍设备照片、录报错视频来问，我们花了三周时间完成了多模态升级。整个过程可以分成四步。

4.1 原架构和改造目标

原架构很简单：用户文本消息进来，先做意图识别，然后在FAQ知识库里检索，最后拼接Prompt调用文本模型生成回答。局限很清楚：用户上传的照片、语音一概收不了，只能提示"请用文字描述"。数据统计了一下，大约有25%的会话在"请用文字描述"这一步就流失了。

改造目标定为三个：能接收并理解用户上传的设备图片和故障截图；能接收语音描述并区分紧急程度；能处理PDF版的说明书，从里面检索到检修参数。

4.2 输入侧预处理与校验清单

升级正式开始后，第一件做的是输入侧管线。我们对四种输入类型分别做了处理：

• 图片：先校验格式和大小，最大限制在10MB内；调用OCR提取图中文字，同时调用视觉描述模型产出结构化信息（图中对象、状态灯颜色、可见异常）；两者合并成"图片理解报告"。
• 语音：ASR转文字后做断句切分；通过声学特征判断语速和停顿标记紧急程度（分为常规、着急、非常着急三档）。
• PDF：小文件直接走版面分析，抽标题、段落、表格；大文件先分章节再检索，不整体进上下文。
• 视频：默认每2秒抽1帧，先跑一遍画面描述和文字识别，如果识别到报错字段就多抽几帧进行确认。

这一步没有太多技术含量，但很关键。很多项目后面效果差，不是模型问题，而是输入侧已经丢了信息。管线里每一层都在做取舍，取舍的依据要记录清楚，后面出现bad case时能追溯到是哪一层丢了关键信息。

4.3 路由策略与Prompt调整

输入侧做完了，第二步是设计路由策略。我们没有让所有多模态内容都直接灌到模型里，而是根据输入类型分流：

Prompt也做了针对性调整。我们增加了一条系统级指令："用户的文字消息始终是最高优先级任务。请先明确用户要解决的问题，再观察相关图像内容，忽略与任务无关的图像元素。"就这一句话，让原先"看什么都想说"的毛病改掉了大半。

4.4 上线后实测：成功率、成本与bad case

上线跑了两周，数据效果比预期好，但成本比预期高。文本类会话的单次成本大约是0.008元，图片类会话直接飙升到0.18元，翻了二十多倍，语音类居中在0.05元左右。换算到整体，多模态请求占比25%，但成本占了总成本的70%以上。优化策略是前面提到的"按需回溯"：默认只带图片的文字描述进入上下文，只有用户追问细节时才注入原图，图片类的单次成本降到了约0.07元。

bad case主要集中在三类：一是暗光环境下拍摄的设备照片，视觉模型经常把"正常"识别成"故障"；二是镜像翻转的截图，左右逻辑错位；三是PDF扫描件里表格结构复杂时，参数绑定错对象。第三类问题后来通过在版面分析后增加一个"表头-行-列绑定校验"步骤得到了改善。暗光和镜像问题只能靠提示词兜底，比如明确要求"检查图片是否存在镜像翻转迹象"以及增加一句"在不确定时，不要猜测故障状态，直接引导用户提供更多信息"。

整个改造过程最难的不是接API，而是让每一个环节的人（产品、算法、标注）对"多模态理解到什么程度算合格"达成一致，这直接引出最后一个大问题：多模态Agent怎么评测，才算真的靠谱。

5. 多模态Agent效果评测：别被"它看到了"骗了

文本Agent的评测相对成熟，BLEU、ROUGE、人工打分，大家都跑过。多模态Agent的评测会难一个层级，因为"看到了"不等于"看懂了"，更不等于"按用户意图做出了正确动作"。我在项目里吃过亏，一开始只测了"图片识别准确率"，结果上线后用户满意度并没有提升多少，因为Agent识别出了内容，但不知道用户要拿这个内容干什么。后来我们改成了三层评测。

5.1 逐模态基线：先保证单类不塌

第一层是逐模态基线测试。图像、语音、PDF分别单独测，不给Agent任何其他模态的信息干扰。图像这块我建议按"文字识别、物体识别、状态判断（正常/故障）、空间关系判断"四个子维度分别测；语音按"转写准确率、意图识别准确率、紧急程度判断准确率"三个子维度测；PDF按"检索召回率、参数抽取正确率、表格绑定正确率"测。

这一步的作用是建立底线。如果单模态基线都没有达到可用水平，就不要指望多模态混合的表现会突然变好。我们当时给自己定了及格线：图像状态判断不低于90%，PDF参数绑定不低于85%，语音紧急程度判断不低于80%，达不到就回去调管线，不进入下一步。

5.2 复合条件与冲突输入测试

第二层是复合条件测试，模拟真实场景里多模态混合出现的情况。构造测试题的思路是：给一张图，一个文字指令，但文字指令里附带一个图片里没有的信息，看Agent会不会为了迎合文字描述而编造图片里不存在的东西。

典型案例：图片里是一台设备面板，两个指示灯正常亮着，第三个指示灯没有亮。文字指令是"三个指示灯都亮了，这是什么状态"。合格的Agent应该指出"图片中第三个指示灯未亮，与描述不符，请确认"。不合格的Agent会顺着文字指令回答"三个指示灯亮表示设备运行正常"。

这类"冲突输入"测试是检验Agent是否真正理解多模态信息一致性的关键。我们把它作为上线前的必过测试，要求冲突检测的通过率不低于95%，因为一旦在这个问题上翻车，用户信任度会断崖式下降。

5.3 我的评测小技巧：打分制加"欺骗图"

最后分享两个评测里比较实用的小技巧。

第一个是"打分制"。很多人评测多模态Agent时用二分类（回答对/错）记录通过率。我强烈建议改成四分制打分：0分是事实错误（识别错了）；1分是识别对了但结论编造（图片没有的信息说出来了）；2分是结论正确但过程粗糙（漏掉了一些相关细节）；3分是事实、结论、过程全部正确。0分和1分之间差异巨大，如果不区分，你很难判断瓶颈是模型能力问题还是上下文管理问题。

第二个是构造"欺骗图"。这是我自己起的名字。就是故意设计一些视觉上容易误判的东西来测试Agent的鲁棒性。比如镜像翻转的截图、低对比度的文字、一张图里同时出现正常设备和故障设备、故意加了水印或遮挡的图片。测试的时候观察两个点：Agent会不会主动表示"这个不确定"；Agent会不会在没有足够信息时强行给出结论。大多数多模态Agent在"识别不出来"时的表现比"识别错误"更危险，前者可以引导用户补充信息，后者直接给错误答案。

评测体系搭好之后，整个多模态改造才算真正闭环。回过头看，给Agent接入多模态输入这件事，技术选型只是最表层的题目，真正难的是让整条链路在信息损耗、成本和准确性之间找到稳定的平衡。

我现在的体会是：多模态Agent做得好不好，核心不在模型，而在数据链路的设计。谁来决定哪部分信息需要原样保留、哪部分可以压缩成描述、什么时候该回溯原图、用户指令的优先级怎么维护，这些问题比选哪个模型更重要。如果你准备给自己的Agent加多模态能力，建议先从一两个高价值的输入类型切入（比如图片加语音），把链路里的取舍逻辑跑通，再逐步铺开到更多模态。不要一上来就追求"什么都能处理"，那样大概率每个模态都处理不好。