★ FEATURED ARTICLE 很多朋友私信问我一个问题多模态大模型到底能不能直接帮我干活这里的干活不是指回答这张图里有什么而是指真正完成一个任务——比如从一张表格截图里提取数据、按条件汇总再画一张趋势图交给我。说实话只靠一个大模型本身做不到。多模态大模型擅长的是感知看懂图像、理解视频、描述内容。但当指令从告诉我这是什么变成帮我把它处理成那样时模型就卡住了——因为它没有手也没有操作外部环境的能力。这就是感知与认知的鸿沟在工程层的真实体现模型能读懂世界却无法改变世界。要跨越这道鸿沟工程上靠的是两样东西工具增强让模型学会调用外部工具和视觉Agent系统把感知、规划、执行串成一个自主循环。这篇文章我会用自己的实测经验把工具注册、Agent系统架构、端到端工作流、以及踩过的坑完整拆一遍。适合正在做多模态应用开发的工程师、研究Agent方向的同学以及想了解多模态模型能力边界的产品和技术负责人。1. 从看懂到做到多模态大模型必须打通行动层1.1 感知、认知与行动三层能力缺一不可如果把大模型的能力分层来看多模态大模型目前主要覆盖了两层感知层图像分类、目标检测、OCR、视觉问答回答图片里有什么认知层推理、规划、理解复杂指令回答这件事该怎么拆解。但真正要完成一个任务还缺第三层——行动层。行动层意味着模型能调用工具、读写文件、执行代码、操作外部系统并把每一步的结果拿回来继续决策。没有行动层模型就像一个知识渊博但双手被绑住的顾问什么都能分析什么都做不了。我接触过不少刚入门的朋友他们以为模型看图能力强就能自动处理图像结果一测就发现模型能告诉你表格里有多少行、哪个月份销售额最高但你让它把数据按季度汇总后生成一个Excel文件它就无能为力了。原因很简单生成Excel不是视觉任务是文件操作任务在图上画框标注不是描述任务是坐标输出加图像写入任务。这些都需要借助工具。1.2 三个答而不做的典型场景为了把这个边界说清楚我举三个我自己实测过的典型场景给一张PDF页面截图要求提取表格并生成Excel文件。纯多模态模型能描述表格内容但无法真的生成xlsx文件视觉Agent会调用表格解析工具提取结构再调用数据处理和文件写入工具最终交付一个真实可打开的文件。给一张园区监控截图要求统计画面中的人数并用方框标出每个人。纯模型会说画面中有5个人但拿不出带标注的图像Agent会调用目标检测工具获得坐标框列表再用图像绘制工具把框画上去并保存。给一张UI设计图要求生成这个页面的可交互原型。纯模型只能描述布局和配色Agent可以调用代码生成工具写出HTML/CSS代码再调用浏览器渲染工具截图自查。这三个场景的共同点在于任务里都有一串需要动手的步骤。而多模态模型的输出只是文本或图像无法自己推动任务前进。Agent系统的作用就是把这些动手步骤从模型的能力盲区里解放出来。1.3 工具增强的本质是一个感知-思考-行动闭环理解了上面这些工具增强的本质就很清楚了它把外部能力封装成一个个可被模型调用、可返回结果的函数让模型在推理循环中自主决定何时调用、调用哪个、如何处理返回值。这个循环在学术圈通常叫ReAct风格循环即Thought思考→ Action行动→ Observation观察的交替过程。用做菜来类比模型先看菜谱理解目标思考然后伸手拿菜刀和食材选择工具切菜下锅执行调用尝一口味道再决定加不加盐基于工具返回结果做下一轮决策。工具增强之所以能大幅提升多模态模型的任务完成能力是因为它把知识和操作分离了模型负责判断要做什么、怎么做工具负责精确完成操作。模型不需要知道Excel文件的二进制格式也不需要知道怎么在图像上画像素级方框它只需要学会调用对应的函数。2. 工具注册层把能力变成一份模型看得懂的菜单2.1 函数调用模型与工具箱之间的合同工具增强的第一步是让模型知道当前有哪些工具可用并且能用结构化的方式发出调用请求。这里最核心的机制就是函数调用Function Calling。大模型本身不执行任何外部程序但它可以输出结构化的调用请求。开发者在自己的进程里解析这个请求执行对应函数再把结果以文本形式塞回给模型。于是整个工具调用的链路变成了模型产出请求 → 程序执行函数 → 结果反馈模型 → 模型继续推理。为什么一定要用结构化请求而不是让模型自由写一段文字因为自由文本很难稳定解析。模型如果说帮我调用一下那个表格工具参数就是这张图的路径程序无法可靠地提取参数。而结构化调用请求相当于一份合同模型按约定的JSON格式输出工具名和参数程序按合同执行并验证双方都减少误解。2.2 工具注册表的写法直接影响模型的选择在实现上工具列表会作为系统提示词的一部分拼进上下文。每个工具都需要提供名称、功能描述、参数定义。我见过不少项目在初期就是把工具名和参数一写了之结果模型经常选错工具或编造参数。后来逐一调整描述语效果提升非常明显。一个典型的视觉工具注册定义长这样{ name: extract_table_from_image, description: 从图片中提取表格结构。当用户需要识别图片/PDF截图中的表格数据时使用返回二维数组和原始文本。, parameters: { type: object, properties: { image_path: { type: string, description: 待解析的图片文件路径支持PNG/JPG格式 }, has_header: { type: boolean, description: 表格是否包含表头行默认为true, default: true } }, required: [image_path] } }这里有两个细节容易被忽略。第一description必须写清楚什么时候用而不是只写这个函数做什么。比如从图片中提取表格数据当用户给出含表格的截图时使用模型就很容易理解。如果只写图像处理函数模型会在目标检测需求时也去调用它导致一连串错误。第二参数描述要用业务语言补充说明。比如has_header这个参数单看类型名很难判断加上表格是否包含表头行后模型才可能在用户说第一行是标题时正确地传true。我实测过一个小样本用20张不同类型表格图描述语泛泛而写时工具命中率约六成改成场景化描述后命中率接近九成。工具描述不是给开发者看的文档而是给模型看的说明书措辞直接影响行为。2.3 视觉Agent的工具集不止视觉工具视觉Agent听起来像是只有视觉工具但实际工程里任务链条往往需要混合工具。我通常会把工具集分成四类工具类别典型工具用途视觉感知类OCR、目标检测、图像分割、图像描述从图像中提取结构化信息数据处理类表格聚合、数据格式转换、统计计算对提取结果做进一步加工文件与代码类读写文件、执行Python代码、生成Excel产出用户要的最终交付物视觉创作类图像绘制、图表渲染、图像编辑生成和修改图像内容一个实际的视觉Agent系统中OCR工具负责看数据工具负责算绘图工具负责画文件工具负责存。模型在规划阶段会动态组合这些工具。所以工具注册层不仅要管理视觉工具还要把所有可能用到的能力纳入统一管理避免Agent跑到一半发现没有工具可用来写文件。另外还有一个经验工具数量不是越多越好。每多一个工具系统提示词就更长模型的选择空间更大但准确率会下降。建议同一时刻只注册当前任务可能需要的一小撮工具子集比如一开始只加载OCR、表格解析、文件写入三个工具等任务中途发现需要图表渲染再动态把绘图工具加入上下文。这种动态注册的方式比一次性塞30个工具更可控。3. 视觉Agent的系统骨架规划、执行与记忆如何协作3.1 规划器把一个大目标拆成可执行的工具链有了工具清单下一步是让Agent学会拆分任务。规划器是视觉Agent的决策中枢它接收用户指令结合视觉感知结果输出一串工具调用计划。在实现上规划器通常就是大模型本身。区别在于有的项目用多模态大模型直接看图并规划有的项目先把图像转成文本描述OCR、图像Caption、VQA结果再把文本喂给纯文本大模型做规划。两种方式各有优劣多模态模型能直接理解图像细节但成本更高文本化方案更稳定但会丢失部分视觉信息。我在实际项目里最常用的是混合感知目标检测、OCR等确定性视觉算子先跑一遍拿到结构化结果然后将这些结果交给具备认知推理能力的模型做规划。这样既利用了专业视觉模型的精度又发挥了语言模型的规划长处。用更强的模型做规划用更专的模型做视觉分工明确。3.2 执行器参数校验、错误回灌与重试机制规划器输出调用请求后执行器负责真正调用工具。执行器是Agent系统中容易被低估的组件它的健壮性直接决定系统是否可用。执行器要做的事情包括对模型输出的JSON参数做严格校验、捕获工具运行时的异常、把错误信息格式化成模型能理解的形式并回灌给模型、对失败的操作进行重试或降级。我见过很多Demo跑不通问题往往出在执行器上——模型的调用请求里参数名写错了执行器直接抛异常退出根本不给模型纠正的机会。正确做法是把校验失败或执行异常的消息作为Observation返回给模型提示工具调用失败错误为xxx请重新检查参数并再次调用。模型通常能自己修正参数重新尝试。这条错误回灌回路是Agent系统从玩具走向可用的关键设计之一。3.3 记忆体工作记忆与中间产物缓存Agent执行一个复杂任务时往往需要好几轮工具调用。每轮的工具返回结果如果全部堆在上下文里很快就会耗尽上下文窗口也让模型顾头不顾尾。因此记忆机制必不可少。工作记忆负责保存当前任务的关键信息比如用户原始指令、最新图像路径、已完成的步骤摘要。长期记忆则保存跨任务的知识比如用户偏好图表标题要包含项目名称、常用工具参数模板等。在视觉任务中中间产物检测框坐标、OCR文本、渲染出的图片路径需要统一管理通常做法是大体积结果写到文件只在上下文里保留文件路径和一段摘要。我在复现类似系统时有个体会上下文里保留的信息质量比数量重要。过度保留历史工具日志会让模型越来越糊涂而每轮只保留结论性信息反而能保持规划能力稳定。这就像人做复杂工作时不会把每一步都记在脑子里而是做完一步就清空一步只记住当前该往哪个方向走。3.4 视觉模型的本地部署与云端API怎么选视觉Agent的感知部分往往要落在一个具体的视觉模型上。是选本地部署的开源视觉模型还是直接用云端多模态API这是个典型的工程取舍。维度本地开源模型云端多模态API延迟依赖GPU但可控受网络影响整体偏高隐私数据不出内网需要考虑数据脱敏与合规成本硬件投入较高增量便宜按量付费低频任务更省复杂推理能力开源的相对弱一些通常更强确定性视觉算子集成容易和传统视觉库集成需要额外的网络封装我见过一个比较合理的搭配规划等认知密集型操作交给云端多模态API因为它的推理、指令跟随能力更强而OCR、目标检测这类确定性视觉算子尽量本地化用轻量模型或传统视觉库完成速度快、成本低、结果可控。视觉Agent要追求的是整体任务的成功率而不是某个环节的极致智能因此混用不同层级的能力是最务实的路线。4. 端到端复现让Agent自己完成抽取表格→汇总→画趋势图4.1 任务与工具清单前面讲了不少原理这一节我们直接复现一个完整流程。假设用户提问把这张销售数据表图片中的内容抽出来按季度汇总销售额然后画一张季度趋势折线图返回图片路径。我设计了一个最小可用的工具集共四个工具extract_table_from_image从图片中提取表格结构dataframe_transform对提取的数据执行聚合操作render_line_chart根据数据渲染折线图返回图片路径inspect_image对生成图片做一次视觉自检确认图表完整、标题正确。这四个工具正好覆盖视觉提取→数据处理→视觉生成→结果质检四个环节是视觉Agent最典型的一条任务链。4.2 完整交互过程拆解Agent内部的推理循环大致如下Thought用户要求先提取图片里的表格数据这一步应该调用extract_table_from_image。Actionextract_table_from_image({image_path: /data/sales_table.png, has_header: true})Observation提取到6行销售记录列包括月份和销售额。数据为1月120万、2月105万、3月98万、4月135万、5月142万、6月110万……Thought现在需要按季度聚合。1-3月是Q14-6月是Q2。调用dataframe_transform完成分组求和。Actiondataframe_transform({operation: groupby_quarter_sum, source: last_result, date_column: 月份, value_column: 销售额})Observation聚合完成Q1销售额323万Q2销售额387万。Thought用render_line_chart把季度数据画成折线图。Actionrender_line_chart({data: {Q1: 323, Q2: 387}, x_label: 季度, y_label: 销售额万, output_path: /tmp/quarterly_trend.png})Observation图片已保存到/tmp/quarterly_trend.png。Thought最后调用inspect_image检查图片是否有明显问题比如坐标轴缺失、标题错误。Actioninspect_image({image_path: /tmp/quarterly_trend.png, inspection: 检查图表标题和坐标轴是否完整})Observation图表正常标题为季度销售趋势坐标轴标签正确。Thought所有子任务完成可以把图片路径告诉用户了。这个循环看起来不复杂但每一步其实都在做决策先做什么、用什么工具、参数怎么填、结果是否合理。模型通过工具返回的Observation获得环境反馈再决定下一步行动。这正是Agent与普通问答的最大区别——它不再是一次性回答而是多轮尝试直至完成目标。4.3 可复现的Agent主循环骨架如果你要从零搭建一个最小的视觉Agent核心循环可以这样写Python骨架def run_agent(user_task, tools, llm, max_steps8): messages [{role: user, content: user_task}] for step in range(max_steps): response llm.chat(messages, toolstools) if response.tool_calls: # 1. 执行工具调用 result execute_tool(response.tool_calls) # 2. 将模型请求与工具结果追加到上下文 messages.append(response.to_message()) messages.append({role: tool, content: result}) else: # 模型不再调用工具直接返回最终回答 return response.content return max_steps exceeded任务未能完成这段代码只是骨架但包含了Agent主循环最核心的三件事把工具清单传给模型、执行模型发起的工具调用、把结果反馈回模型。实际生产中还需加上参数校验、超时控制、结果缓存、工具权限管理等机制。4.4 轮次与成本控制每一次思考-行动-观察循环都会消耗Token工具返回结果动辄几百上千字。如果任务复杂Agent可能循环十几次成本会快速累积。我通常会做三件事来控制设置最大循环轮次比如默认8次超过就停止并让模型报告进度对每个工具结果做摘要只把关键字段放回上下文在系统提示词里要求模型能用一步完成就不要用两步。此外Agent能执行工具意味着它拥有行动权这会带来安全隐患。尤其是图像写入、文件删除、执行代码这类工具必须在沙箱环境中运行并且按最小权限原则分配——Agent只能操作指定目录不能触碰系统关键路径。我在搭建时吃过一次亏Agent生成的临时文件把已存在的同名业务文件覆盖了从那以后再也不敢让Agent直接操作非隔离目录。5. 实测里的四个坑工具幻觉、死循环、上下文污染与评测盲区5.1 参数幻觉模型会编造不存在的工具参数我在刚开始做工具增强时遇到最频繁的问题是模型调用工具时编造参数。比如extract_table_from_image明明只定义了image_path和has_header两个参数模型却会在JSON里加上format: xlsx——这个参数根本不存在执行器一校验就抛错。出现这种情况的原因主要有两个一是工具的描述信息不够完整模型只能猜测二是指令遵循能力较弱模型在对话中听到用户说导出Excel就顺手把Excel映射成了参数。解决办法分三层第一层尽量把参数描述写全写明取值范围和默认值第二层执行器做严格JSON Schema校验校验失败把错误信息回灌给模型让它自行修正第三层如果模型多次编造同一类参数就在工具描述里显式加上本工具不支持此参数的说明。这三层叠加后参数幻觉的出现频率会明显下降。5.2 反思死循环越聪明的模型越容易钻牛角尖给Agent加上反思能力后任务完成率确实会提升但也带来了一个新问题反思死循环。模型遇到工具调用失败时会不断说我再试一次然后用完全相同的方式重试反复失败七八次也不换策略。这种情况在带自反思机制的Agent上尤其常见。我验证过一种有效的控制手段在提示词里写死如果连续两次工具调用返回错误请停止尝试改用备选方案或者如实告知用户当前无法完成的部分。另外要给最大轮次设硬上限超过后直接返回任务未完成和中间结果摘要而不是让Agent无限循环下去。有时候及时止损比硬磕到底对用户来说体验更好。5.3 上下文污染中间结果太多反而让模型失忆工具返回的Observation在本质上是模型上下文的一部分。如果每轮都把完整OCR文本、检测框坐标、数据处理日志塞进去几轮下来模型最初要执行的用户指令就会被淹没。我见过一个案例Agent在第八轮时居然根据某一次工具返回的文本猜测出一个新的操作指令完全偏离了用户的原始需求。这个问题我建议做两层防护上下文精简工具返回的内容先截取或摘要再回灌只在上下文里保留当前这一步的结论不保留完整噪音。原始指令锚定在每轮对话的系统提示词里始终固定插入用户的原始目标是xxx确保模型不会在长循环中迷失方向。我自己实测下来加了这两层防护后长任务的成功率提升明显而且Token消耗反而下降了因为不再传输大量冗余日志。5.4 评测Agent的四个指标与一个小实验最后聊一个重要但常被忽略的话题怎么客观判断一个视觉Agent是真的会干活而不是偶尔碰对了。只看模型有没有给出看起来合理的回答远远不够。我通常会从四个指标去测评测指标说明测量方法任务完成率是否产生用户要求的最终交付物人工检查Agent返回的文件/图片/答案是否符合要求工具选择准确率每一步是否选了正确的工具统计日志中工具调用与预期工具序列的匹配度步骤效率是否用最少步骤完成任务记录循环次数比较是否存在冗余调用错误恢复率遇到失败能否自行纠正人为制造参数错误或工具异常观察Agent能否恢复拿前面表格图片→汇总→画趋势图的任务来说我建议做一个小实验收集20张不同样式、不同方向的表格图片逐张跑一遍记录四个指标的表现。别小看这个看起来简单的实验它能把系统里大量隐藏问题暴露出来——比如某些表格旋转90度后OCR工具就失灵了某些宽表在汇总时列名映射错误这些在单一样例测试里根本发现不了。我在这类系统上磕磕绊绊做了几个月最大的体会是真正让Agent从Demo走向可用不是把底层模型换得更大而是把工具链打磨得更稳。工具描述要认真写执行器要经得起异常记忆要克制不图全评测要坚持跑批不看单例。如果你第一次动手做视觉Agent别急着上复杂框架先把我上面那个两个工具一个表格任务的闭环跑通再逐步拓展工具集这条路亲测可行。
阅读完成 · 觉得有帮助？
