多模态Agent开发指南：理解、生成、行动闭环的工程实践

多模态 Agent 这四个字，这两年几乎成了 AI 圈子所有热度的交汇点。一边是 GPT-4o、Gemini、Qwen-VL 这类原生多模态大模型把"理解现实世界"的门槛拉低，另一边是 Agent 框架、编排引擎和工具调用协议把"行动闭环"变成可工程化的东西。但真把理解、生成、行动串成一个完整系统时，你会发现这条路远比想象中坎坷：图像特征和文本特征怎么对齐，工具调用失败怎么回退，多模态记忆到底存什么、怎么存、存多久，以及"看起来每个环节都跑通了，连起来就崩"的 Agent 执行错误，每一个都是实打实的坑。

这篇文章不是学术综述，是我从模型选型、特征融合、Agent 编排、记忆设计到评测调试一路踩坑的经验记录。适合正在做多模态 Agent 原型、想从纯聊天机器人往 autonomous agent 方向走的开发者，以及准备把多模态能力嵌进业务流程的算法工程师和产品负责人。读完你不会得到一个现成的成品系统，但你会知道该在哪几个核心环节上投入精力，以及避免哪些我已替你趟过的雷区。

1. 多模态 Agent 的本质：为什么"理解—生成—行动"必须统一

1.1 多模态不是"多一种输入"，而是换了一个物种

纯文本 Agent 的输入是字符串，输出是字符串，工具调用是它对格式化的 JSON 描述做出选择。整个过程本质上发生在"符号世界"。多模态 Agent 不一样，它的输入可能是摄像头画面、一段嘈杂的现场录音、一份手写表格的照片，甚至是一路实时视频流，输出也可能是图片、语音、操作指令。

这就好比一个人蒙着眼睛靠别人口述去拧螺丝，和睁着眼睛自己看、自己摸、自己调整姿势去拧螺丝，虽然目的都是把螺丝拧进去，但感知通道和决策方式完全是两个量级。多模态带来的不是"多了几个输入接口"，而是模型必须在一个连续的、不确定的、信息冗余甚至冲突的真实世界里做决策。

具体到技术形态，多模态输入至少要覆盖这几类：图像和视频（分辨率、帧率、时序关系）、音频（语音内容、语速语调、环境噪声）、文本（指令、知识、历史记录），以及物联网场景下的传感器数据（温度、位置、IMU 姿态等）。每一路信号的底层分布都不一样，它们不像一行行的 token 那样天然处在同一个语义空间里。

我一开始天真地以为，多模态 Agent 就是把多模态大模型的 API 接上，外面套一层 function calling 就能交付。后来发现只做输入侧的多模态是远远不够的，Agent 的认知空间、工具描述、记忆表示都需要跟着改成多模态形态，否则理解层和行动层之间永远隔着一道翻译的损耗。

1.2 从理解到生成再到行动，闭环是怎么转起来的

标题里的"理解、生成、行动的统一"，对应到工程上就是三个核心模块。

理解层负责感知和推理：图像里有什么物体、它们在什么空间关系下、语音里表达了什么意图、文本里隐含了什么约束。这一步通常由视觉 encoder、语音 encoder 和语言模型共同完成，输出是结构化的"情境认知"。

生成层负责表达和创作：根据理解到的情境，生成一段解释、一份报告、一张示意图、一段语音回复，或者修补一张图片里的某个区域。生成的目标不是"说一句漂亮话"，而是让后续的行动决策有依据。

行动层负责改变环境：调用 API、执行代码、操作数据库、控制硬件设备，或者向另一个 Agent 发起协作请求。行动的结果又会作为新的观测反馈到理解层，形成循环。

这个循环在学术界有个很著名的名字叫 ReAct（Reason + Act），本质上就是让模型交替进行推理和行动，而不是一次性生成完整计划再机械执行。实践中你会发现，一次性计划在大模型时代特别不靠谱——模型高估了自己对环境的预测能力，真实世界的工具结果往往会推翻计划假设，而 ReAct 这种"想一步、做一步、看结果、再想下一步"的模式，容错率高很多。

多模态 Agent 的 ReAct 循环里，观测（observation）不再是纯文本格式的 API 返回，而可能是截图、视频帧、声音片段。行动（act）也不再局限于发请求、写文件，还可能包括"转动机器人关节""发送一段合成语音"这类物理或音视频动作。所以闭环的每一跳都要处理不同模态之间的转换，这就是统一性的真实含义：每个环节都能接收模态，也能产出模态。

1.3 统一难在哪：对齐、时序与反馈

难处至少有三个方面，都是我在实际项目里反复撞过的墙。

第一是特征空间对齐。图像经过 ViT 编码后得到的是 patch 级向量，文本经过 tokenizer 后得到的是 token 级向量，音频经过 encoder 后又是一套时频特征。它们各自活在各自的坐标系里，模型要用投影层和注意力机制把它们拉到同一个语义空间。这个对齐质量直接影响理解层能不能形成正确的跨模态事实判断，比如"画面里的红绿灯状态"和"语音里说的'可以走了'"是不是在描述同一时刻。

第二是时序同步。视频和音频天然带时序，文本可能带时间戳，传感器数据是流式的。如果 Agent 要判断"用户在听完这三秒语音后点击了哪个按钮"，它必须知道各路输入的相对时序关系。很多多模态数据集在构建时没有严格保留同步标注，导致模型学到的是"模态之间的统计相关性"，而不是"因果顺序"。

第三是行动反馈的闭合。文本对话里，模型的输出本身基本就是最终结果；但多模态 Agent 的行动结果可能需要重新被感知层读取，比如操作了 GUI 之后要截图确认界面状态，操作了机器人之后要读传感器反馈。这个"行动→（新的多模态观测）→理解→再行动"的反馈回路如果没有认真做，Agent 就会变成盲飞状态，看起来在执行任务，实际上早就偏得十万八千里了。

2. 核心链路拆解：从感知到行动，每一步的取舍

2.1 多模态特征提取与融合：第一道坎就是"对齐"

多模态特征提取这块，现在的主流做法是各模态各用一个预训练 encoder，然后在语言模型的某个中间层合并。图像侧常用 CLIP 或者 SigLIP 训练的 ViT，音频侧有 Whisper encoder、HuBERT、WavLM，文本侧直接走 LLM 的 embedding 层，有些方案还会对视频做抽帧后再按帧提取。

编码之后就是融合策略的选择，这一点工程上非常容易犯选择困难症。

早期融合（early fusion）把各路特征在进入主干网络之前就拼成一个大向量，实现简单，对对齐要求高，因为编码器预训练时根本没见过这种拼接方式，效果往往不稳定；晚期融合（late fusion）让各路模态各自走完整的编码通路，最后在决策层合并，灵活性高，但跨模态的细粒度交互会被削弱；混合融合（hybrid fusion）就是用交叉注意力（cross-attention）在中间层反复做模态间的信息交换，现在大多数多模态大模型实际采用的就是这种路线。

实操层面我的建议是：第一优先理解并复现模型的融合结构，比如 Qwen-VL 是怎么把图像 token 插入文本序列中的，而不是着急换花哨的融合模块。第二，如果自己做下游微调，融合层的学习率通常是 encoder 主干的好几倍，因为预训练 encoder 已经比较稳定，而融合层是随机初始化的，要在训练早期快速收敛。多模态情感分析这类任务里，模态之间不是平等的，语音的语调往往比文本内容更能反映真实情绪，这就要求融合模块学习出动态的模态权重，而不是机械地平均。

2.2 生成层：从"会说话"到"会做图、会出声"

生成层在纯文本 Agent 里只是把推理结果写成自然语言，但多模态 Agent 的生成范围一下子宽了：生成一段文案、生成一张修正后的图片、生成一段语音提示，甚至生成一段操作脚本。

这就带来一个架构选择：文本生成可以走自回归，图像生成主流还是扩散模型（diffusion），语音生成则有自回归和基于 flow matching 的方案。如果你要在单一 Agent 里同时打通这些能力，最省力的方式是不要自己训生成模型，而是把各模态专用生成模型以工具的形式挂进去。比如 Agent 决定"需要给用户展示一张示意图"，就调用图像生成工具；需要口语播报，就调用 TTS 工具。

实际踩坑最多的是生成结果的校验。文本生成还可以用规则和相似度检查，图像生成怎么判断它满足了用户的约束？我见过不少项目在生成之后加一层 VLM 回顾校验：把生成图重新送进一个视觉语言模型，让它对照需求描述逐项打分，不达标就重新生成一次。这个"生成—回看—再生成"的模式简单有效，但要注意控制重试次数和成本。

另一个容易被忽视的点是，多模态 Agent 生成的内容会成为下一轮行动的依据。比如 Agent 生成了一张路线图，用户在图上圈了个红圈，下一轮 Agent 就要能通过视觉定位知道红圈在哪里。也就是说，生成层产出的内容必须是可以被理解层再次消费的，而不是一次性展示后就丢掉。这个闭环意识很重要，否则系统会碎片化。

2.3 行动层：Agent 与聊天机器人的分水岭

行动层是 Agent 之所以叫 Agent 的原因。聊天机器人只会回答问题，Agent 会调用工具、执行代码、提交表单、发起支付，然后根据结果决定下一步动作。

工程上最传统的实现是 function calling：模型从系统提示词或工具列表中选择一个函数，按照给定的 JSON Schema 填写参数。但真实系统的行动层远不止这一层，我把它拆成四块：

任务规划：把高层目标分解成子任务，决定先做哪个后做哪个。常用模式有 Plan-and-Execute（先整体规划再逐步执行）和 ReAct（每步先推理再行动），复杂任务里也可以混合使用。

工具注册：向 Agent 发布工具的描述信息，必须做到名称语义清晰、参数说明详尽、示例覆盖边角情况。工具描述写得好不好，直接决定模型会不会调用错、参数填没填对。

结果解析：工具返回的可能是不同模态，比如 OCR 结果、数据库结构化数据、PDF 文本、图片截图。这些结果要能转化为模型可理解的上下文，必要时还要清洗、压缩、去重。

错误恢复：工具调用可能失败、超时、返回空值，Agent 要么换个参数重试，要么换一个工具，要么向用户求助，而不是直接崩溃或无限循环。错误恢复能力是绝大多数 Agent 项目成熟度的分水岭。

一段很真实的经验：多模态 Agent 的行动层训练数据非常贵，因为每一步行动都要关联对应的多模态观测。如果你的团队预算有限，不要一开始就追求全自动执行，先做"人机协同模式"：Agent 负责建议下一步动作，人负责批准和执行。这样既能积累高质量轨迹数据，又能避免 Agent 胡搞把环境弄坏。

2.4 Agent 框架与编排：框架名字不重要，抽象层级才重要

现在社区里各种 Agent 框架已经到了目不暇接的程度，除了最早出圈的 LangChain、AutoGen、CrewAI，新单词隔三差五就蹦出来，什么 pi agent、hermes agent、modex agent，还有一堆藏在 GitHub 里没出圈的项目。我的建议很直接：别被这些名字牵着走，看它解决的问题和解耦的抽象层级就够了。

框架本质上是解决三个问题：Agent 怎么感知世界、Agent 怎么决策、Agent 怎么行动。不同框架的抽象层级不同。有些框架是"低层工具集"，提供各种连接器的封装；有些框架是"中层运行时"，帮你实现 ReAct 循环和记忆管理；有些框架是"高层编排系统"，让多个 Agent 互相协作。

你还会经常看到两个词：harness 和 agent。在不少开源项目里，harness 指"模型的运行时外壳"，负责输入输出规范化、工具调用解析、循环控制、状态保存，而 agent 指的是"模型实例加上让它做事的完整环境配置"。有经验的工程师会告诉新人：先搞清楚你的应用需要在哪个抽象层级定制，再把框架剥开改，不要整个框架无脑套进去。比如你只需要一个单 Agent 工具调用循环，用轻量级实现完全够；但如果你要跑多角色协作脚本，就值得引入带编排能力的框架。

3. 实操路径：从零搭一个多模态 Agent

3.1 模型选型与基础环境

先明确一条原则：多模态 Agent 的效果上限由基础模型决定，工程能解决的是下限和稳定性。所以选模型是第一个关键决策。

如果预算够、对延迟不敏感，直接用商业 API 是起步最快的方式。GPT-4o、Gemini 1.5 Pro 这类模型原生接受图文输入，视觉推理能力强，工具调用支持也完整。如果数据敏感或者要深度定制，就得考虑开源模型本地部署：Qwen-VL 系列在中文场景和文档理解上表现出色，LLaVA 系列轻量易上手适合做实验，近期的一些 MoE 多模态模型则在推理成本上有优势。选型时要关注几个硬指标：最大图像分辨率、视频抽帧上限、上下文长度和音频采样率。

本地部署还有一个必须考虑的硬件问题。7B 到 13B 规模的 VLM 做推理，至少需要一张 16GB 以上的显卡才比较舒服；如果要同时跑 embedding、向量检索、TTS，就要规划显存占用。我见过不少团队第一步就卡在环境上，与其盲目追求大模型，不如先跑通端到端小模型，把架构验证了再升级基座。

多模态输入管线这块，常见的选择是"开源多模态模型 + 专用工具链"拼装。例如 Ollama 可以快速拉起 Qwen2-VL，Open WebUI 负责界面，用 FAISS 做向量检索，用 Whisper 处理音频转录。这套组合基本零成本就能搭建一个可演示的多模态 Agent 原型。

3.2 多模态输入管线：图像、音频、视频怎么统一

实操里最烦的不是模型，而是输入管线。多模态 Agent 要处理的是各种来源、各种格式、各种质量的真实数据，所以第一步得做统一封装。

我的做法是定义一种统一的观察消息（observation message）结构，里面可以承载不同类型的内容块。比如一张图片被 OCR 后产生文本块，同时保留图像块；一段音频被 Whisper 转录成文本块，同时附上情感标注块。消息统一后，模型无论从哪个模态拿到了信息，整理后都在同一套提示词格式中运行，代码复杂度和调试难度会大幅下降。

值得注意的细节是预处理的取舍。视觉输入，我会限制图片最大边不超过模型规定的分辨率，同时保留缩放比例。音频输入，先统一转成 16kHz 单声道 wav 再送 encoder，避免不同采样率带来的隐性 bug。视频输入，关键帧抽取策略要按场景定制：对话场景 1-2 秒抽一帧足够，动作识别场景可能要密集抽帧，但帧数越多成本越大，必须平衡。

另一个关键点是占用时间的问题。多模态处理比文本处理慢得多，一个 10 秒的视频，抽帧加上逐帧编码可能就要好几秒。所以在 Agent 循环中要提前决定哪些观测需要全部编码，哪些只需要抽摘要。最优实践是先用低成本方法（文件名、标题、时间段描述）建立粗索引，只有真正需要细看的内容才做高成本编码。这一步做好了，Agent 的整体响应延迟能降一半以上。

3.3 记忆模块：短期工作记忆、长期向量记忆与"4D 记忆"争论

Agent 的记忆系统和单轮问答最大的区别在于，它必须跨越多次交互保持一致性。我用三层结构来做：

短期工作记忆（scratchpad），本质是当前任务上下文窗口，包含对话历史、中间推理、工具返回结果。它的上限就是模型的上下文长度，所以核心设计是"怎么裁剪"：太早的信息丢弃，太长的结果摘要。

长期记忆用向量数据库持久化。每次交互结束，把理解到的知识点、用户偏好、任务结论转成 embedding 存进去，复用的时候做相似度检索。开源方案里 FAISS 够用，项目规模大了再考虑 Milvus 或 Qdrant。这里核心参数只有两个：embedding 模型的维度，以及每次检索返回的 top-k，前者决定检索精度，后者决定上下文占用。

"多模态记忆到底包不包括 4D"这个问题，是我在热搜里看到的，实际上它是空间智能浪潮下的延伸思考。传统的记忆是"文本知识 + 图像描述"，但一个能操作物理世界的 Agent，它对物体摆放位置、空间关系、运动轨迹的记忆，本质上需要空间维度加时间维度，也就是 4D。当前工程做法往往退而求其次：用视频关键帧序列存时间维度，用三维坐标标注和 SLAM 地图存空间维度，再靠文本索引把它们串起来。目前还没有统一的 4D 记忆表示，所以大家也不用焦虑，先把"时间维度上的关键帧"和"空间维度上的坐标描述"这两层做好，就已经跑在大多数人前面了。

3.4 行动闭环：工具注册、Skill 与流式传输协议 MOQ

工具注册是行动闭环的地基。每个工具要以 JSON Schema 形式描述清楚参数和返回结构。下面是我常用的一种工具定义格式：

{ "name": "query_vehicle_image", "description": "在车辆影像库中检索指定时段、指定区域的截图", "parameters": { "type": "object", "properties": { "start_time": {"type": "string", "description": "起始时间，ISO 8601 格式"}, "camera_id": {"type": "string", "description": "摄像头编号，缺省返回全部"} }, "required": ["start_time"] } }

这里特别要提醒的是 description 的写法。模型理解工具靠的就是这段描述，所以一定要包括边界条件默认值和失败时可能抛出的错误，而不是干巴巴一句"查询车辆图像"。一个好的工具描述，要让模型判断出"什么样的情况该用这个工具，什么样的情况不该用"。

Skill 是近年 Agent 社区绕不开的一个词。Skill 和 Agent 的关系经常让人混淆，我的经验是：Skill 是"可复用的能力单元"，比如"OCR识别""语音转文字""发送邮件""图像抖动"；Agent 是"有目标、有记忆、有决策循环的完整实体"。技能像是工具箱里的工具，Agent 是使用工具的人。不要一开始就把技能系统设计得很复杂，先用扁平结构把高频动作沉淀成技能，用多了再做技能编排。

流式传输这块，我要专门说一个越来越重要的协议：MOQ（Media over QUIC）。多模态 Agent 一旦接入实时音视频或者摄像头流，就得考虑低延迟传输问题。传统基于 TCP 的方案弱网表现差，基于 WebRTC 的又偏复杂。MOQ 基于 QUIC 协议，天然支持多路复用、低延迟和拥塞控制，对"一边接收实时视频帧、一边向 Agent 回传控制指令"这种双向流场景很合适。而且 QUIC 本身就是 HTTP/3 的底层协议，生态已经比较成熟，不是实验品。如果你做的是自动驾驶远程协助、机器人遥操作这类场景，值得认真研究 MOQ。

3.5 多模态数据集与微调：绕不开的对齐与标注问题

如果你想在垂直场景里获得更好的效果，微调是躲不开的。但要微调，首先得有靠谱的多模态数据集。热搜词里那个 bird1445，不管具体指代哪一个数据集编号，它背后反映的是同一个问题：多模态数据集最难的永远是"模态配对"和"标签一致性"。

所谓模态配对，就是同一件事物在不同模态下的表现能否对应上。一个文档图像、它的 OCR 文本、一个描述它的语音句子，这三样东西必须严格指向同一条记录。实际构建数据时，文本和图像对应相对容易，但音频和视频的时间戳对齐经常出错，差个几百毫秒，标签就从"正确"变"噪声"了。

标签一致性更是血泪教训。同一张粗糙的手绘图纸，标成"产品设计草图"和"电路连接示意"会导致完全不同的微调结果。所以标注规范里最好明确多级分类体系加否定性说明，否则标注员会按自己理解乱标。

微调时我还会建议混合一部分纯文本指令数据。多模态模型微调经常把指令遵循能力带偏，因为图像数据里的指令密度低。混合文本指令相当于"基础能力保持 + 多模态能力增强"的组合，能让模型在文本任务上不退化，多模态任务上进步。

4. 容易被忽略的暗礁：情感建模、Agent 安全与评测

4.1 复杂场景下的多模态情感预测，到底在建模什么

多模态情感分析/预测这几年一直是热门方向，但大家往往低估了它的数学建模难度。它的本质是：给定来自不同模态的观测序列，预测说话人或场景中参与者的情感状态。不只是分类任务是预测标签，还有回归任务是预测情感维度。

工程化工其做法是这样：文本模态可以归一化为 token embedding，音频模态提取韵律特征，视觉模态提取面部表情或姿态特征。每个模态序列长度不一样，所以对齐是关键。接着用按时序模型（如 Transformer、GRU）对每个模态分别建模，再用注意力机制计算模态间权重。比如一段视频里，人嘴上说着"没事"但声音发抖肢体僵硬，模型要能够学习出音频和视觉模态的权重应该更高。数学上看，注意力权重就是"对当前情感判断而言，这个模态有多可信"的估计。

损失函数也有讲究。简单的交叉熵在多模态上容易忽略时序连续性，实务上我建议加上对比学习损失：让同一情感状态下不同模态的表示靠得更近，不同情感状态的表示拉远。这能让模型学到的表示更加鲁棒。

模态缺失是复杂场景最大的敌人。现实录音里可能只有文本没有画面，监控场景里可能只有图像没有语音。训练时要用随机丢弃模态的增强策略，推理时模型也要学会说"我缺少某路感知，判断置信度降低"，而不是硬给一个自信的答案。

4.2 Agent 安全：记忆攻击与提示注入

多模态 Agent 的安全问题，比纯文本大模型严重得多。原因很简单：它能行动，能访问工具，能读取外部数据，一旦输入带恶意，风险直接从回答阶段放大到了操作阶段。

最常见的攻击路径之一是提示注入。现在用户不再直接输入文字，可能上传图片、音频、PDF，这些内容里可能藏着恶意指令。视觉模态尤其危险，一幅图片里可以嵌入肉眼看不见的噪声图案，但模型能感知到并在识别后执行其中隐含指令。所以多模态 Agent 在设计上必须做"指令与数据分离"：来自外部数据的文本块统一加权限标签（如 data_only），禁止被当成系统指令执行。

记忆污染是另一个更隐蔽的攻击方式。攻击者通过注入一段内容，让 Agent 把它当成事实写进长期记忆，之后 Agent 会在所有后续对话中被持续误导。尚在演进中的 A-MemGuard 这类防御框架，主要思路就是给记忆写入加一层"守卫"：写入前验证内容来源和权限，读取时检查读取者的敏感等级，同时给记忆条目加时间戳和来源标记，方便事后追溯污染链。它的本质和数据库里"来源于安全上下文写入"这个朴素想法是一致的，但工程实现上有大量细节，比如多模态记忆如何加签名、误杀率怎么控制。

实践层面的安全基线，我建议至少做四条：工具权限最小化，Agent 只能调用完成当前任务所必需的工具；输入内容净化，外部文件统一走隔离解析服务，能在解析阶段剥离的部分绝不留给模型；动作审核，高风险操作（删除、支付、发送）必须二次确认；全链路日志，每步推理过程、工具调用、记忆写入都落盘，事后即便出了问题也来得及回放定位。

4.3 评测 Agent：为什么总是"看着能用，一跑就崩"

"评估 Agent"这件事，比评估一个文本模型难得多。文本测评有几十个公开 bench，但 Agent 在真实环境里的任务路径是开放式的，模型 A 和模型 B 可能用完全不同的步骤完成任务，你没法简单比较"准确率"。

我的做法是三层评测。底层是组件评测：每个工具、每个记忆检索、每个模态提取器单独打分，保证底座可靠。中间层是任务回放评测：拿一批录制好的多模态交互轨迹，让 Agent 重放，固定初始状态，看是否得到同样的决策序列，这相当于 Agent 的回归测试。顶层是开放式任务人工评测：让真实用户或内部测试员发布任务，人工依据"任务完成率、步骤合规性、出错后的恢复能力"三个维度打分。

"Agent execution terminated due to error"这类报错，几乎每个做过 Agent 的人都见过一次，这不是 Agent 框架出 bug，而是某一步执行异常后整个循环被终止。排查思路要按链路走：先去翻日志，定位是在感知层（输入解析失败）、推理层（模型输出格式无法被解析）还是行动层（工具真的执行错误）。绝大多数情况发生在推理层，模型返回了一段疑似 JSON 但不合法，或者工具名跟注册列表差一个字。解决方案不是改模型，而是设计一个"格式纠错器"，在模型输出后面接一个轻量脚本，尝试用正则和智能修复把格式纠回来；纠不回来，才触发重试。

5. 常见问题与避坑速查

5.1 高频问题的排查速查表

这一节我直接给结论，把高频神坑整理成表格。这些项目里十有八九会遇到，建议收藏。

5.2 我给新手的学习路线建议

结合我自己带团队的经验，多模态 Agent 的学习路径我觉得可以分四阶段走，不用急着一步登天。

第一阶段，先跑通纯文本 Agent。熟悉 ReAct 循环、function calling、工具注册的基本写法，把 Agent 的状态管理和错误恢复机制摸透。这一步不需要多模态，只用文本 API 就能完成，目标是理解"行动闭环"的工程本质。

第二阶段，接入多模态输入。把图像理解、音频转写接进现有 Agent，让模型能够在对话中"看图说话""听声辨意"。这个阶段关注输入管线的统一封装和延迟优化，不追求炫技。

第三阶段，做深度结合。让多模态信息参与工具选择和记忆检索，比如根据路况图片决定调用哪条导航工具，根据用户语气选择回复风格。这时你开始体会到"多模态不是叠加而是融合"。

第四阶段才是上层建筑：多模态记忆体系、安全防御、身份权限、多 Agent 协作。到这一步，你已经不是追热点的人，而是能自己拆解新框架、做工程设计决策的人了。到那时，什么 pi agent、hermes agent 之类的新名字再出现，你只会看一眼架构图，然后说出那句经典台词："这不就是把某个模块换了个封装嘛。"

最后再分享一个我个人很有体会的观察。做多模态 Agent 最消耗人的不是模型效果不够好，而是"系统永远处于不稳定但看起来能用"的状态。很多团队在这个阶段纠结要不要推倒重来，我的建议是：不要推倒，回到第三层评测，逐层定位是感知、推理还是行动的确定性不足，然后针对修。

这是多模态 Agent 最好玩也最磨人的地方。每条链路单独拿出来都是成熟技术，可把它们缝合成一个能稳定行动的智能体，靠的是对细节的敬畏。工具链还没收敛，框架命名还很混乱，评测标准也远未定稿，但这恰恰意味着，真正的工程红利不在"再训练一个大模型"，而在如何把已有的模型、工具、记忆和协议，编排成一个可靠的整体。