过去两年我一直在做多模态 Agent 相关的项目也看过不少团队在这个方向上的挣扎。现在的 Agent 给你感觉什么都能聊两句但真让它去完成一项需要看懂 — 想清楚 — 做出来的完整任务立刻露馅。这种割裂感不是某一个模型的问题而是技术路线的问题大多数系统把理解、生成、行动做成了三个独立模块各算各的账。这篇文章我想系统聊聊为什么这三者必须统一到一个架构里以及我在落地过程中踩过的坑和验证过的一些做法。如果你是做 Agent 开发、多模态融合或者正准备从单模态转向多模态方向这里面的内容应该能帮你少走不少弯路。1. 看起来聪明的假象当前多模态 Agent 的三大割裂先戳破一个泡沫。从 Demo 上看现在的多模态 Agent 确实很唬人你给它一张图片它能描述你问它问题它能回答你让它帮你查个东西它能调 API。但只要你把一个需要连续看、想、做多轮闭环的任务丢给它问题就全出来了。根基在于大家的架构默认是割裂的。1.1 理解与生成割裂识别是识别说话是说话最常见的做法是视觉模块负责做物体检测、OCR、姿态估计文本模块负责对话最后用一段胶水代码把结果拼起来。我见过很多项目里图像理解的输出是一堆 JSON 标签而文本生成模型根本不会用这些标签只能从中挑几个凑进句子里。结果是看得很细但说得很糙。举个例子一个图像理解模块检测出图片里有人、有狗、有飞盘检测框坐标都有。但生成模块只会说图片中有人和狗。它不是不知道飞盘而是标签和语言之间没有建立真正的语义对齐。这个问题的根源是理解任务以感知为目标生成任务以语言为目标两个目标函数各跑各的中间缺一个共享的表征空间。我在做多模态情感分析的时候感触特别深。视觉情感分析模型能识别出人脸表情的细微变化文本模型能理解用户说了什么但组合起来经常出现矛盾视觉模型判断是愤怒文本模型输出是感谢最后融合出的结果既不像愤怒也不像感谢。因为两个模块各自在自己的表征空间里做判断没有统一的可比较基准。1.2 行动与感知割裂Agent 不会真正看路更麻烦的是行动层。现在的 Agent 行动逻辑普遍是感知结果 → 规则映射 → 工具调用感知和行动之间隔着大量硬编码规则。比如检测到屏幕上有一个按钮坐标在某个范围就触发点击。这已经在很多 RPA、UI Agent 里用了但它把看这个动作变成了一个纯粹的坐标提取器。真正的行动应该建立在理解之上。人在点按钮之前会先理解这个按钮的语义——它是确认还是删除点了之后会产生什么后果。而现在的系统只是看到坐标→点击没有任何语义校验。我见过一个 Agent 在表单页面把取消按钮当成提交点了因为检测模块只负责给控件框不负责理解控件的语义。这种问题单靠加大感知模型的参数量是解决不了的必须在架构层面把理解的结果直接作为行动决策的依据。1.3 割裂的代价为什么插件式方案走不远有人会说我可以用插件把三个环节串起来每个环节用最好的模型不行吗不是不行是串起来之后误差会像滚雪球一样放大。我在自己的项目里统计过假设视觉理解模块准确率是 95%语义理解模块准确率是 90%任务规划模块准确率是 85%串联起来整体成功率不到 73%。而且这三个模块之间的信息传递往往是不可逆的前面的模块错了后面无论如何也纠不回来。真正的多模态 Agent 不应该是一条流水线而是一个闭环系统。理解的结果要被生成过程使用生成的结果要能驱动行动行动之后的反馈又要回到理解环节修正认知。这就是标题里说的理解、生成、行动的统一。下面我分三层展开讲每层我都会给出具体的实现思路和选型建议。2. 理解层从识别到场景理解的技术跃迁理解是 Agent 的地基。但理解这个词被用滥了很多人把分类、检测、分割都叫理解。在我看来真正的场景理解必须具备三个特征多模态融合能力、时序建模能力、推理能力。2.1 多模态融合的三个主流范式多模态融合的论文我读了很多主流范式其实就三套每套各有取舍。早期融合直接把图像特征和文本特征拼在一起喂给模型。好处是模态间的交互最充分坏处是数据对齐要求极高图像特征和文本特征的维度、语义粒度对不上就很尴尬。我在项目里试过把 CLIP 的图像特征和 BERT 的文本特征直接拼接效果很差因为两个特征空间本来就不是对齐的。晚期融合每个模态单独跑一个分支最后在任务层做决策融合。这种方案工程上最稳定也是很多工业级系统实际在用的。但它的上限也低——模态之间的交互只在最后一步发生大量跨模态的细节关联被丢掉了。比如你要理解一张菜单图片用户语音点餐的场景晚期融合很难捕捉到用户说 这个 的时候手指着的是图片里哪个菜这种细粒度关联。跨模态注意力融合通过注意力机制让不同模态的 token 两两交互。这是目前我觉得最靠谱的路线。视觉 token 和文本 token 放在同一个序列里通过 self-attention 自由交互模型可以学到哪块图像区域对应哪个词。代价是计算量大序列长度暴涨需要做 token 压缩。实操中我一般对图像先走视觉编码器做 token 化把一张图压成几十个 token再和文本 token 拼接。这三套方案不代表谁完全替代谁而是任务不同选择不同。你要是只做分类晚期融合完全够用你要是做复杂场景理解跨模态注意力几乎是必选项。2.2 场景理解需要的几项关键能力场景理解不等于物体识别。识别是图里有什么理解是这个场景正在发生什么。后者需要 Agent 具备三个能力第一是空间关系推理。物体之间的位置关系、遮挡关系、距离远近这些信息不是简单打个框就能表达的。我在做一个室内导航 Agent 的时候发现模型能把沙发和茶几都认出来但判断沙发在茶几左边还是右边就经常出错。后来我在训练数据里加入了物体之间的空间关系标注让模型显式预测关系三元组物体A空间关系物体B效果提升非常明显。第二是时间建模。静态图片理解只是第一步真实场景是连续的。摄像头拍到一个人在跑Agent 需要知道他跑的方向、速度、跑向哪里。现在的做法大多是把连续帧切成一堆独立图片处理等到要理解动作的时候就抓瞎。实际项目里要引入时序模块比如视频 Transformer 或者时序蒸馏把帧间变化编码进表征。第三是反事实推理。这个能力被绝大多数系统忽略但我觉得是多模态 Agent 能不能迈向智能的关键。简单说就是模型能不能预测如果我不做某个操作场景会变成什么样。比如一个机器人看到杯子里水快满了它需要推理出继续倒水会溢出来所以现在该停。纯感知模型做不到这一点因为它没有把感知结果和行动后果联系起来。这也是我为什么强调统一架构因为这种推理能力天然需要理解层和行动层协同。2.3 数据是理解的硬瓶颈聊到理解层就绕不开数据。我自己构建过多模态数据集深知这里面的痛。一个单模态的图片分类数据集标注几万张也就几个工程师几周的工作量。但多模态场景理解数据集既要图像标注又要文本描述又要语义对齐成本直接翻好几倍。热词里有人提到多模态数据集 bird1445这种命名其实代表了现在业界的一个现实数据集的规模都小得可怜因为标注成本太高。我在项目里用了一个讨巧的办法用大型模型辅助标注人工只负责校验。让视觉语言模型生成初始标注标注员去改错补充工作量能砍掉 50% 以上。但这带来一个新问题——模型标注的结果天然带偏见如果你的标注模型有系统性错误那人工也容易被带偏。所以我每次都会留一部分完全人工标注的数据做校验集定期测一下自动标注的偏差率。元学习在这个领域也有它的用武之地。多模态任务多样性极高新场景层出不穷每次重新收集数据训练显然不现实。我试过用 MAML 思路做小样本场景理解让模型在新场景中只通过学习几个样本就快速调整效果初看还行但离生产可用还有距离。这个方向目前更适合做研究探索工程上还是老老实实用大规模预训练加高质量微调更稳妥。3. 生成层统一输出空间才是硬功夫理解层解决的是看明白的问题生成层解决的是能表达的问题。在多模态 Agent 里生成不只是指文本回复还包括图像、语音、结构化动作指令等多种输出形式。真正的难点在于这些输出形式应该由一个统一的生成引擎控制而不是每个模态一个独立生成器。3.1 从文本生成到跨模态生成传统 NLP 的生成模型只输出文本序列多模态生成要复杂得多。现在文生图、图生文、语音合成各成一派但 Agent 场景下经常需要在一个会话中切换多种输出形式。你给我一张照片我要先理解照片内容然后写一段描述再根据描述生成一张改编后的图片最后配上一段语音说明。这个流程里每一次输出都是不同模态如果每个模态各自为政整个链路的调度和状态管理会非常崩溃。我的经验是引入一个统一的输出接口层把所有生成任务封装成统一的生成请求—生成结果模式。接口内部根据目标模态路由到不同的生成后端但对外暴露的是同一个协议。这样 Agent 的核心逻辑只需要关心生成什么内容不需要关心用什么技术生成。我们内部把这个叫做生成语义层它负责把任务意图转成具体模态的指令。比如同样的一个语义把红色改成蓝色落到文生图模块是让模型重绘落到程序化渲染模块是直接改 CSS落到语音模块则是读成一句好的变成蓝色了。3.2 生成与理解必须闭环如果生成只是单方向的输出那它就永远是个答录机。我越来越觉得生成结果必须能被理解层重新解读形成闭环。举个例子Agent 生成了一张修改后的图片它自己需要判断这张图是否真的符合用户的要求。这就需要一个自检机制生成结果再喂给理解模块和目标描述做相似度校验。这里面有一个很有意思的技术点一致性判定。我们以前做图像生成评价用的是 FID、IS 这些分布层面的指标但它们无法回答这张图是不是用户要的那张图。后来我转向了细粒度描述对比的方式让一个多模态模型分别描述目标需求图和生成结果图然后在语义空间里对比两条描述是否一致。这个方法虽然糙但在实际项目中比任何分布指标都管用。对抗生成网络在生成层的角色也值得说。虽然扩散模型现在已经成了文生图的主流但 GAN 的思想仍然在发挥作用尤其是在需要交互式、低延迟生成的场景里。扩散模型生成一张图要迭代几十步GAN 只需要一步这在 Agent 实时交互场景下是巨大优势。我有个做实时虚拟形象的项目就是在扩散模型做离线素材GAN 做在线微调兼顾质量和速度。3.3 情感一致性一个容易被忽略的生成难题做多模态情感预测和生成的时候我发现一个特别隐蔽的问题模态间情感语义不一致。模型生成的文字是开心的内容但配出的语音语调是平淡的生成的图片表情又带着哀伤。每一个模态单独看都说得通但放在一起就很违和。解决这个问题不能靠后期拼接要在生成源头就做统一规划。我的做法是在生成前先确定一个语义中心向量把情感、风格、意图这些高层属性编码成一个向量然后所有模态的生成都以这个向量为条件。比如我确定一个温和地提醒语义向量文本生成、语音合成、虚拟形象表情全部围绕这个向量做约束。这个思路不难但很多团队在做多模态生成时根本没想过跨模态对齐导致最后成品效果像新闻联播和恐怖片混在一起。4. 行动层Agent 真正做事的能力体系理解是大脑生成是嘴巴行动是手脚。大脑和嘴巴之间没打通顶多算个絮叨的观察者只有行动层也参与进来Agent 才真正进入智能体范畴。4.1 工具调用与 API 层的工程现实现在的行动层主流方案是让 Agent 调用工具。OpenAI 的 function calling、各种 Agent 框架的 Tool Use本质都是把外部系统封装成函数让模型决定什么时候调用哪个函数。听起来简单工程上全是坑。我自己做 Agent 开发的时候第一个坑是工具描述写不好。很多团队把 API 文档直接塞给模型那里面有大量无关细节模型不知道什么情况下该用哪个 API。后来我是这么做的每个工具都要写一个配置描述包含触发条件、参数说明、返回值格式、使用禁忌。甚至我会专门用一个多模态模型去理解这个描述看它能不能正确区分什么时候该用工具 A、什么时候该用工具 B。这个自检流程帮我提前发现了很多调用混乱的问题。第二个坑是工具调用的容错。外部 API 总是会返回意外结果超时、空值、字段缺失、格式变化。Agent 的决策模型往往只学了理想情况一旦返回结果和预期不符整个链路就断了。我的方案是给行动层加一个结果解释器每次工具返回后先用一个小模型把结果翻译成语义化的描述再让主 Agent 基于这个描述做下一步决策。这样即使 API 返回格式变了语义描述层能兜底主模型不用反复适应新格式。4.2 多模态记忆Agent 立住人设的根基没有记忆的 Agent 是永远在原地打转的。但记忆不只是把聊天记录存下来多模态 Agent 的记忆必须是跨模态的。用户上次说喜欢什么风格、发过什么图、修改过哪些元素这些信息要以统一的向量形式存起来在下一次交互时能被检索到。我做过一个设计助手类 Agent用户上传参考图然后提修改意见。一开始我只存文本对话记录结果下轮交互时 Agent 完全忘了参考图长什么样用户改了几次它也一无所知。后来我把用户上传的图像、修改历史、文本评论全部编码进一个统一的记忆库每次对话开始时先做记忆检索把相关的历史记忆注入上下文这个 Agent 才真正像记住了用户的偏好。多模态记忆在设计上要考虑4D问题——不仅要有空间特征还应该有时间维度知道用户偏好是何时形成的、是否已经过时。这个问题我在项目里也没完全解决目前是用时间衰减权重来处理新记忆权重高、旧记忆慢慢淡出。4.3 行动策略从规则到强化学习行动层的核心是决策。最早的 Agent 用规则引擎if-then 链写几百条可维护性极差。后来大家用大模型直接输出行动指令效果好很多但稳定性堪忧模型经常给出格式错误、逻辑跳跃的指令。最近大家开始尝试用强化学习让 Agent 学会在环境中做决策让模型自己探索什么行动会导致好结果。我在一个网页自动化项目里尝试过简单的策略优化。用大模型生成候选行动再用一个评估器判断行动结果是否达到预期把反馈作为奖励信号反传回去微调策略。实测下来对于填写表单、点击按钮、验证结果这类固定流程收敛效果不错但对于开放式任务比如根据用户需求设计一个页面布局奖励信号很难定义强化学得就很飘。我的建议是不要盲目上强化学习先把行动层和评估层做成一个可插拔的组合规则、模型、强化学习三种策略可以按任务切换。5. 统一架构的实践一个多模态 Agent 项目的骨架讲了这么多上点实操性的内容。我把自己最近做的一个多模态 Agent 项目的骨架拿来说这个项目目标很朴素用户上传一张产品图片一句需求文本Agent 自动完成理解需求 → 生成修改图 → 输出修改说明 → 按需推送到下游系统这条完整链路。5.1 整体方案设计我的架构不是一条流水线而是一个以中央语义总线为核心的闭环系统。输入层接收图像、文本、语音三种模态统一转成 token 序列理解模块多模态编码器场景理解模型输出结构化的语义表示物体、关系、意图、情感决策模块基于语义表示做任务规划决定先做什么、后做什么生成模块根据决策结果生成文本回复、修改图、语音等不同模态的输出行动模块执行工具调用、文件写入、API 推送等动作反馈模块收集执行结果和用户反馈写回记忆系统这里最关键的设计是所有模块之间只通过语义表示通信不直接传递原始数据。理解模块输出一份语义快照决策模块修改这份快照生成模块把快照渲染成用户可见的内容行动模块据此执行动作。这样每个模块解耦替换任何单点都不影响整体。5.2 任务规划和递归生成的实现流程我简单描述一下这个项目里一次完整任务的处理逻辑你可以照着搭一个最小版本用户输入产品图文本需求理解模块把图像编码成视觉 token文本编码成文本 token拼接后过跨模态注意力层输出场景语义表示例如深蓝色运动水壶需求是改成红色哑光表面决策模块解析语义表示生成任务列表[修改主色调 → 调整材质 → 生成效果图 → 生成说明文案]生成模块按任务列表执行每一步生成结果都回传给理解模块做校验。比如生成完了红色水壶图片理解模块要判断是不是红色、是不是哑光、水壶原先的主体结构有没有变校验通过后生成模块输出最终效果图和一段说明文字行动模块读取结果触发下游推送到用户的微信群或设计协作平台反馈模块记录用户后续的反馈更新记忆库这中间最核心的是第 3 步的生成-校验循环。我现在管它叫递归生成生成一个结果 → 理解这个结果 → 对比目标 → 再生成修正版本直到校验通过。这个机制能让多模态生成的稳定性上一个台阶但代价是延迟变高所以我在实现时设置了最大迭代次数一般是 3 次超过就退回到上一次最好的结果。5.3 Agent 框架选型与评估要点框架选择上我现在倾向于轻量级方案。市面上的 Agent 框架我试过几个最大的问题是过度封装——看似什么都有真要改逻辑得把框架源码翻个底朝天。我的建议是如果你需要快速验证想法用现成的 Agent 框架起步没问题但如果你要做有深度的多模态统一架构最好自己搭。核心代码量其实不大无非就是语义总线、模块注册、任务调度几个部分。评估方面我强烈建议不要只看单模态指标。一个典型的错误是图像生成用 FID文本生成用 BLEU语音合成用 MOS各自看都挺好但你不知道整个 Agent 是不是真的好用。我现在的做法是搭一个端到端任务成功率指标给定 100 条真实场景任务跑完整条链路统计多少条任务完全做对了多少条部分完成多少条彻底失败。这个指标虽然糙但最能反映用户感知到的质量。同时每个模块保留单独的评估集用于快速定位是哪一层出了问题。6. 真实项目里的坑我踩过的三条教训最后分享三个我在项目里实际踩过、花了不少时间才爬出来的坑给后面做多模态 Agent 的朋友一些参考。6.1 多模态幻觉比单模态更难防大家都知道文本模型有幻觉但多模态模型的幻觉更隐蔽。一个模型可能用一张图上完全不存在的物体生成了一段逼真的描述或者根据用户的一句模糊描述生成了一张包含不存在元素的图片。原因在于跨模态生成时某些 token 的注意力权重被错误激活模型想象出了一个不存在的视觉元素。我试过几种防幻觉的手段最有效的是局部一致性校验生成完成后在图像里标出描述中提到的关键物体确认它真的存在于画面中。比如描述说画面里有一只蓝色的马克杯就在图里定位蓝色马克杯这个对象看能不能找到。这个校验过程本身也靠多模态模型来完成但它不需要实时响应可以慢慢算准确性可控。6.2 模态对齐的数值稳定性问题有一次我训练跨模态模型发现 loss 在某个 step 之后突然飙升模型输出全变成 NaN。排查了两天最后定位到问题视觉特征和文本特征的量纲差异太大视觉特征的范数比文本特征大出好几个数量级在注意力计算中文本 token 被完全压制。这个问题的根源是模态对齐没有做归一化。解决方法是在拼接 token 之前对每个模态的特征做 LayerNorm把范数拉到同一个量级。另外我后来在注意力层加了余弦注意力替代点积注意力进一步缓解了不同模态特征尺度不一致的问题。这个坑极其隐蔽但它恰恰说明了多模态统一处理比单模态复杂得多每一个看似简单的拼接操作背后都有坑。6.3 别让 benchmark 骗了你业界有不少公开的多模态 benchmark但我直接拿过来用的时候经常翻车。很多 benchmark 的数据分布和真实场景差得太远模型在测试集上准确率高得吓人一上线就被用户反馈打脸。后来我学乖了每个项目都留出一部分真实用户数据做隐藏测试集模块迭代的时候拿它来验收而不是盲目相信公开 benchmark。这也引出我对多模态 Agent 未来的一个判断真正的进步不是模型参数更大、榜单分数更高而是理解、生成、行动三者协同时表现出的综合能力。我最近在尝试的一个方向是让 Agent 在行动之后根据反馈自我修正理解策略——比如它发现用户对某种生成风格不满意会自动调整下次理解的侧重点。这种行动反哺理解的闭环比单纯把某一个模态模型做大更有价值。这条路还很长但我觉得方向是对的。