企业官网建设流程全解析

多模态这个方向，2024 年之前大家聊的还是"图文对齐做得怎么样""CLIP 又刷了什么榜"，到了 2024 年下半年之后，话题明显变了。我在组里带人读论文的时候发现，同样一篇讲 Fusion 的文章，2023 年读和 2025 年读，关注点完全不一样——以前关心的是融合结构怎么设计，现在关心的是这套融合机制能不能塞进一个 Agent 的决策回路里，能不能支撑起一个 World Model 的预测。这篇梳理就是把我这两年带着团队读论文、复现代码、踩坑填坑的过程整理出来，从最底层的 Fusion 讲起，一路走到 Reasoning Agent 和 World Model。不管你是刚进组的研究生，还是想从单模态转多模态的工程师，应该都能从中找到自己需要的那一段。

1. 为什么 2024 年之后的多模态综述必须重写

1.1 旧范式的天花板在哪里

2022 到 2023 年那批多模态工作，核心命题基本围绕"对齐"和"融合"两个词展开。对齐层面，CLIP 系列把图文对比学习做到了极致，后续的 BLIP、ALBEF 基本是在这个框架上做修补。融合层面，大家比的是 cross-attention 放在哪一层、Q-Former 的 query 数量取多少、视觉 token 压缩到什么比例还能保住性能。这套范式在 VQA、图文检索、caption 这些任务上确实刷得很高，但问题也很明显：模型本质上还是在做"给定输入，输出一个答案"的映射，它没有状态，没有记忆，不会主动去获取信息，更不会规划一个多步的推理过程。

我举个具体的例子。你给一个 2023 年的多模态模型看一张复杂的图表，问它"2023 年 Q3 相比 Q2 增长了多少"，如果图表里数据是直接标注的，它大概率能答对；但如果需要它先找到图例、再对应到具体柱子、再做减法，它就开始胡说了。这不是模型不够大，而是它的推理链路是单步的、前馈的，没有中间状态可以承载"我找到了图例""我定位到了柱子"这些中间结论。

1.2 三个新命题：统一处理、Agent 化、世界建模

2024 年之后，多模态研究的重心明显往三个方向迁移。第一个是多模态统一处理，也就是不再为每种模态组合单独设计架构，而是用一个统一的 tokenizer 和统一的 Transformer 骨架处理文本、图像、音频、视频甚至动作。这个方向的代表工作是各种 native multimodal 模型，它们把图像切成 patch 直接当 token 喂进去，和文本 token 混在一起做自回归。第二个是多模态 Reasoning Agent，模型不再是被动回答问题，而是能调用工具、能多步推理、能在推理过程中主动去看图、去裁剪、去放大某个区域。第三个是World Model，模型要能预测"如果我做一个动作，世界会变成什么样"，这是从感知走向决策的关键一步。

这三个命题不是孤立的。统一处理是基础设施，Agent 是交互形态，World Model 是能力上限。你去看 2025 年之后那些有影响力的工作，基本都在这三个方向的交叉点上。比如一个能操作 GUI 的多模态 Agent，它需要统一处理截图和文本指令，需要多步推理来规划点击顺序，还需要一个隐式的世界模型来预测"点了这个按钮之后界面会变成什么样"。

1.3 读论文的顺序建议

我个人的建议是，如果你刚开始系统读这个方向的论文，不要一上来就啃 Agent 和 World Model，那样容易飘。正确的顺序是先把 Fusion 这条线打扎实，理解视觉特征怎么进到语言模型里、token 压缩的代价是什么、不同融合粒度的取舍在哪里。然后看统一处理这条线，理解 native multimodal 和 modular 架构的本质区别。再往上才是 Agent 和 World Model。这个顺序的好处是，后面看到 Agent 里那些"看图-推理-再看图"的循环时，你能清楚地知道每一步的视觉信息是怎么被编码和传递的，而不是把它当成一个黑盒。

2. Fusion 这条线：从 cross-attention 到 early fusion 的取舍

2.1 融合粒度的三个层次

多模态融合按发生的位置，大致可以分成三个层次。Late fusion是各模态独立编码，最后在决策层做融合，比如分别用视觉模型和文本模型编码，然后把两个特征拼接起来过一个分类头。这种做法的好处是各模态可以独立优化，坏处是模态间的细粒度交互丢失了。Cross-attention fusion是当前最主流的做法，在语言模型的某些层插入 cross-attention，让文本 token 去 attend 视觉 token。Flamingo 是这方面的经典工作，它用 perceiver resampler 把变长的视觉特征压缩成固定数量的 token，然后在冻结的语言模型层间插入 gated cross-attention。Early fusion则是把视觉 token 和文本 token 从一开始就拼在一起，走同一个 Transformer，native multimodal 模型基本都走这条路。

这三种没有绝对的优劣，关键看你的任务和资源。Late fusion 适合模态间关联弱的场景，比如用文本描述辅助图像分类。Cross-attention 适合需要细粒度对齐但又想复用预训练语言模型的场景，训练成本相对可控。Early fusion 上限最高，但训练成本也最高，而且对数据量和数据质量的要求非常苛刻。

2.2 Cross-attention 的工程细节：gated 机制为什么重要

Flamingo 那套 gated cross-attention 的设计，很多人读论文的时候会跳过，觉得就是个门控而已。但我在复现的时候发现，这个 gating 是训练能不能稳住的关键。具体来说，cross-attention 层的输出会乘一个 tanh 门控值，这个值初始化为 0。这意味着训练刚开始的时候，cross-attention 相当于不存在，模型完全依赖预训练语言模型本身的能力。随着训练进行，门控值慢慢打开，视觉信息才逐渐注入。

为什么要这么设计？因为如果你直接把随机初始化的 cross-attention 插进去，训练初期它会往语言模型里注入大量噪声，把预训练学到的语言能力破坏掉，loss 会先飙升再慢慢降下来，运气不好就直接崩了。gating 机制相当于给视觉信息的注入加了一个软启动，让模型有一个平滑的过渡过程。这个技巧在后面很多工作里都能看到变体，本质思想是一样的：在冻结的大模型上插入新模块时，一定要保证新模块在初始化时对原模型是"透明"的。

2.3 Token 压缩的代价：你省的是算力，丢的是细节

视觉 token 的数量直接决定了计算量。一张 448x448 的图，如果 patch size 是 14，那就是 32x32 等于 1024 个 token。如果每层都做 full cross-attention，这个开销是惊人的。所以几乎所有工作都会做 token 压缩，常见的手段有 perceiver resampler、Q-Former、pooling、或者简单的线性投影降维。

但压缩是有代价的。我做过一个对比实验，在图表理解任务上，把视觉 token 从 1024 压到 64，整体准确率掉了大概 8 个点，而在需要读取小字或者精细数值的任务上，掉得更厉害，能到 15 个点以上。原因很简单，压缩过程本质上是一个信息瓶颈，那些低频但关键的细节（比如图表角落的小字标注）很容易在压缩中被丢掉。

提示：如果你的任务涉及文档理解、图表问答、OCR 密集场景，token 压缩比例不要设得太激进。宁可多花算力，也不要让关键细节在入口就丢了。一个实用的做法是保留两套视觉特征，一套压缩后的全局特征用于粗粒度对齐，一套高分辨率的局部特征用于细粒度任务，按需调用。

2.4 融合位置的选择：浅层融合 vs 深层融合

Cross-attention 插在语言模型的哪几层，也是一个需要实验的问题。浅层融合（插在前几层）让视觉信息更早地参与语言表示的形成，适合需要深度跨模态理解的任务。深层融合（插在后几层）则更接近输出，适合视觉信息只作为辅助参考的任务。我自己的经验是，如果算力允许，每隔 2 到 4 层插一个 cross-attention 效果比较均衡。全部层都插，收益递减明显，但算力开销线性增长。

另外提一个容易被忽略的点：cross-attention 的插入位置和语言模型的架构强相关。如果是 decoder-only 的模型，cross-attention 通常插在 self-attention 和 FFN 之间；如果是 encoder-decoder 架构，则要考虑是插在 encoder 还是 decoder。这些细节在论文里往往一笔带过，但复现的时候如果搞错了，性能差异会很大。

3. 统一处理架构：native multimodal 到底改变了什么

3.1 从 modular 到 native 的范式转移

早期的多模态模型基本是 modular 的：一个视觉 encoder，一个投影层，一个语言模型，三段式拼接。这种架构的好处是每一段都可以独立替换和升级，视觉 encoder 可以用最新的 ViT，语言模型可以用最新的 LLM。但坏处也很明显：模态之间的交互被限制在投影层和 cross-attention 层，模型没有真正"理解"不同模态之间的关系。

Native multimodal 的思路是把所有模态都变成 token，用同一个 Transformer 处理。图像被切成 patch，每个 patch 过一个线性层变成一个 token；音频被切成帧，同样变成 token；文本本来就是 token。所有这些 token 混在一起，走同一个自回归目标。这样做的好处是模态间的交互发生在每一层、每一个注意力头里，模型有最大的自由度去学习跨模态关系。

3.2 统一 tokenizer 的设计难点

说起来简单，做起来难。第一个难点是不同模态的 token 在数值分布上差异很大。文本 token 的 embedding 是学出来的，数值范围相对稳定；图像 patch 经过线性投影后，数值分布可能完全不同。如果直接混在一起，训练初期很容易出现某些模态的梯度主导了更新。常见的解决方案包括对每个模态的 token 做独立的 layer norm，或者给不同模态的 token 加可学习的模态 embedding。

第二个难点是序列长度。一张图动辄几百上千个 token，一段视频更是天文数字。如果全部塞进同一个序列，注意力复杂度直接爆炸。所以 native multimodal 模型通常会在视觉侧做一些下采样，或者用一些稀疏注意力的技巧。但下采样又会回到前面说的信息丢失问题。这个矛盾目前没有完美的解法，只能根据具体任务做取舍。

3.3 训练策略：从分阶段到端到端

Native multimodal 模型的训练通常分几个阶段。第一阶段是模态对齐，用大量的图文对做对比学习或者生成式预训练，让视觉 token 和文本 token 在表示空间里对齐。第二阶段是多任务预训练，混入 VQA、caption、OCR、grounding 等各种任务的数据，让模型学会处理不同的多模态任务。第三阶段是指令微调，用高质量的指令数据让模型学会遵循人类指令。

这里有个经验：阶段之间的数据配比非常关键。如果第二阶段里 OCR 数据太多，模型会变得只会读字，对整体场景的理解能力下降；如果 caption 数据太多，模型会倾向于生成描述性文本，在需要精确回答的任务上表现不好。我见过不少复现工作，架构完全照搬，但数据配比没调好，最后性能差了一大截。

3.4 统一处理的代价：模态干扰问题

统一处理不是没有代价的。最典型的问题是模态干扰：当模型同时处理多种模态时，某些模态的能力会下降。比如一个 native multimodal 模型，它的纯文本能力往往不如同规模的语言模型，纯视觉能力也不如专门的视觉模型。这是因为模型容量被多个模态分摊了，而且不同模态的优化目标可能存在冲突。

缓解这个问题的手段有几个。一是增大模型容量，让每个模态都有足够的参数空间。二是用模态特定的专家层，比如 MoE 架构里不同专家负责不同模态。三是在训练时动态调整各模态数据的采样权重，避免某个模态主导训练。这些手段各有优劣，实际用的时候往往需要组合使用。

4. Reasoning Agent：多模态模型从"回答"到"行动"

4.1 什么是多模态 Reasoning Agent

传统的多模态模型是"输入-输出"的映射：给一张图和一段问题，输出一个答案。多模态 Reasoning Agent 则是在这个基础上加了"思考"和"行动"两个环节。思考是指模型会在内部进行多步推理，每一步产生一个中间结论；行动是指模型可以调用外部工具，比如裁剪图像、放大某个区域、调用 OCR、搜索知识库，然后基于工具返回的结果继续推理。

这个转变的意义在于，模型不再受限于单次前向传播能处理的信息量。一张高分辨率的大图，直接塞给模型可能细节全丢了，但 Agent 可以先看全局，定位到感兴趣的区域，然后裁剪出来放大看，这样就能处理远超单次输入限制的信息量。

4.2 工具调用的设计模式

多模态 Agent 的工具调用，常见的有几种模式。视觉操作类工具包括 crop、zoom、rotate、enhance，用于获取更清晰的视觉信息。感知类工具包括 OCR、目标检测、分割，用于提取结构化的视觉信息。知识类工具包括检索、计算器、代码执行，用于补充模型自身知识不足的部分。

设计工具集的时候，一个关键原则是工具的输出要能被模型理解。比如 OCR 的输出不能只是一堆文字，还要带上位置信息，这样模型才能知道这段文字在图的哪个位置，和视觉内容对应起来。我见过一些实现，OCR 只返回纯文本，结果模型拿到了文字但不知道它对应图里的哪个部分，推理就断了。

4.3 多步推理的终止条件

Agent 做多步推理，什么时候停？这个问题比看起来难。如果停得太早，推理不充分，答案可能不对；如果停得太晚，浪费算力，还可能陷入循环。常见的终止条件包括：模型输出了一个特殊的终止 token、达到了最大步数限制、连续几步的结论没有变化、或者置信度超过某个阈值。

我自己的经验是，最大步数限制是必须的兜底，但不要设得太小。对于复杂的图表推理任务，我一般设 8 到 12 步。同时要监控循环，如果模型连续两步调用了相同的工具、传了相同的参数，就应该强制终止，因为这大概率是陷入了死循环。

4.4 训练数据的构造：过程监督比结果监督更重要

训练一个多模态 Agent，最难的不是模型架构，而是数据。你需要的不只是"图+问题+答案"这样的三元组，而是完整的推理轨迹：模型先看了哪里、调了什么工具、得到了什么中间结果、最后怎么得出结论。这种过程数据非常昂贵，因为需要人工标注或者用强模型生成。

过程监督（process supervision）比结果监督（outcome supervision）效果更好，这一点在多个工作里都得到了验证。原因也不难理解：如果只告诉模型最终答案，模型可能会学到一些捷径，比如从问题里的关键词直接猜答案，而不是真正去做推理。而过程监督强制模型学习每一步该怎么做，泛化能力更强。

注意：构造过程数据时，要确保中间步骤是"可验证"的。比如裁剪区域的坐标、OCR 返回的文字，这些是可以客观验证的。如果中间步骤本身就有噪声，模型会学到错误的推理模式。

5. World Model：多模态理解的下一站

5.1 World Model 要解决什么问题

World Model 的核心是预测：给定当前状态和一个动作，预测下一个状态。放在多模态语境下，状态可以是视觉观测，动作可以是语言指令或者物理动作。比如一个机器人 Agent，它看到当前场景（视觉观测），接收到指令"把杯子拿起来"（动作），World Model 要预测执行这个动作后场景会变成什么样。

这和传统的多模态理解有本质区别。理解是"看到了什么"，预测是"接下来会发生什么"。后者要求模型不仅理解当前观测，还要理解物理规律、因果关系、动作的后果。这是从感知智能走向决策智能的关键一步。

5.2 视觉预测的表示问题

World Model 的一个核心难题是：预测什么？像素级预测最直观，但计算量巨大，而且很多像素级细节对决策并不重要。特征级预测更高效，但需要保证特征包含了决策所需的信息。目前主流做法是在一个压缩的隐空间里做预测，这个隐空间可以是 VAE 的 latent，也可以是某个预训练视觉模型的中间特征。

我个人的看法是，预测的粒度应该和任务相关。如果是精细操作任务，比如插拔连接器，那预测需要保留足够的空间细节；如果是导航任务，那预测可以更抽象，只需要知道"前方有障碍物"这种语义级别的信息。

5.3 和 Agent 的结合：模型预测控制

World Model 和 Agent 结合，最自然的框架是模型预测控制（MPC）。Agent 在每一步，用 World Model 模拟多个候选动作的后果，选一个预期收益最高的执行。这个思路在机器人领域很成熟，现在被搬到多模态 Agent 上，用于 GUI 操作、游戏、网页导航等场景。

但这里有个工程上的坑：World Model 的预测误差会累积。如果每一步预测都有小误差，多步之后误差会放大到不可用的程度。缓解手段包括：用短视界的预测（只预测几步）、用 ensemble 降低方差、在真实环境中定期校正。这些手段都有代价，实际用的时候需要根据任务容错率来权衡。

5.4 当前 World Model 的局限

说实话，当前的 World Model 离"通用"还很远。大部分工作只在特定领域、特定任务上有效，换一个环境性能就崩了。核心原因是训练数据覆盖不了真实世界的多样性，模型学到的"物理规律"其实是对训练分布的过拟合。另一个问题是评估困难，预测得准不准，很多时候没有客观标准，只能靠下游任务的表现来间接衡量。

6. 复现和实操中的那些坑

6.1 环境配置：版本地狱

多模态模型的复现，环境配置是第一道坎。我统计过我们组复现失败的案例，大概有三分之一卡在环境上。最常见的问题是 CUDA 版本、PyTorch 版本、flash-attention 版本之间的不匹配。flash-attention 对版本极其敏感，CUDA 12.1 和 12.4 可能需要完全不同的 flash-attention 版本，装错了要么编译失败，要么运行时报奇怪的错误。

我的建议是，复现之前先看论文有没有官方 repo，有的话严格按它的环境配置来，不要自作主张升级版本。如果没有官方 repo，那就找一个社区复现，看它的 requirements 和 issue 区，通常能避开大部分坑。另外，用 conda 而不是 pip 管理环境，conda 能更好地处理 CUDA 相关的依赖。

6.2 数据加载：多模态数据的 IO 瓶颈

多模态训练的数据加载和纯文本训练完全不是一个量级。文本数据加载基本不构成瓶颈，但图像和视频的读取、解码、预处理非常耗时。如果数据加载跟不上 GPU 的计算速度，GPU 利用率会很低，训练时间成倍增加。

优化手段有几个。一是预先把图像解码成统一的格式（比如 webdataset 的 tar 格式），减少训练时的解码开销。二是用 DALI 或者 torchvision 的高效解码后端。三是合理设置 dataloader 的 worker 数量和 prefetch 数量。我一般会把 worker 数量设成 CPU 核心数的 70% 左右，prefetch 设成 worker 数量的 2 到 4 倍。

6.3 训练稳定性：loss spike 的处理

多模态训练中 loss spike 是家常便饭，尤其是 early fusion 的模型。原因可能是某个 batch 的数据有问题、梯度爆炸、或者学习率设得太大。处理 loss spike 的常规手段包括：梯度裁剪、降低学习率、跳过异常 batch、用 bf16 代替 fp16。

但更重要的是定位 spike 的原因。我一般会在训练脚本里加一个监控，记录每个 batch 的 loss、梯度范数、以及各模态的 loss 分量。如果 spike 总是出现在包含某种特定数据的 batch 上，那大概率是数据问题；如果梯度范数突然飙升，那是优化问题。定位到原因才能对症下药。

6.4 评估：不要只看一个指标

多模态任务的评估很容易陷入"刷一个指标"的陷阱。比如 VQA 任务，很多工作只报 overall accuracy，但这个指标掩盖了很多问题。一个模型可能在 yes/no 问题上表现很好，但在计数、空间关系、细粒度识别上很差，overall accuracy 却看不出来。

我的做法是按问题类型分层评估。把测试集按问题类型（颜色、形状、数量、空间关系、OCR 等）分组，分别算准确率。这样能清楚地看到模型的短板在哪里。另外，对于生成式任务，BLEU、ROUGE 这些指标和人类判断的相关性有限，最好能做一些人工评估，或者用强模型做自动评估。

7. 几个值得关注的研究方向

7.1 多模态 RAG

RAG 在纯文本领域已经很成熟了，但多模态 RAG 还有很多问题没解决。核心难点是检索：文本检索可以用 embedding 相似度，但多模态检索要考虑跨模态相似度，而且检索单元是什么？是整张图、图里的区域、还是图文对？不同的检索单元对应不同的索引结构和检索策略。

我比较看好的方向是区域级的检索。把图像切分成有语义的区域，每个区域单独编码和索引，检索时返回最相关的区域而不是整张图。这样能大幅减少无关信息的干扰，提升下游任务的表现。但区域怎么切、怎么保证切出来的区域有语义完整性，这些还是开放问题。

7.2 多模态 Agent 的记忆机制

现在的多模态 Agent 基本没有长期记忆，每次任务都是从头开始。但在实际应用中，Agent 需要记住之前的交互、记住用户的偏好、记住环境的变化。怎么设计一个高效的多模态记忆机制，是一个很有价值的方向。

记忆的表示、存储、检索、更新，每个环节都有挑战。表示上，要统一不同模态的信息；存储上，要考虑容量和访问速度的平衡；检索上，要能根据当前上下文找到相关的记忆；更新上，要能处理过时信息和冲突信息。这些问题目前都没有很好的答案。

7.3 World Model 和具身智能的结合

World Model 最大的应用场景可能是具身智能。一个具身 Agent 需要在真实物理世界里行动，而真实世界的试错成本很高，所以需要在"脑内"先模拟。World Model 就是这个模拟器。但目前 World Model 的精度还不足以支撑复杂的物理操作，大部分工作还停留在仿真环境里。

从仿真到真实的迁移（sim-to-real）是一个经典难题。World Model 在仿真里学到的规律，到了真实世界往往不适用，因为真实世界的物理参数、传感器噪声、环境变化都更复杂。域随机化、系统辨识、在线适应，这些手段都有用，但离完全解决还有距离。

8. 我个人的阅读和复现节奏

最后聊点方法论的东西。这两年读这个方向的论文，我最大的体会是不要贪多，要读透。这个方向论文数量爆炸，每天都有新工作出来，如果每篇都泛读，最后脑子里全是碎片，形不成体系。我的做法是选几篇有代表性的工作，把它的代码跑通、把它的实验复现、把它的设计选择搞清楚，这样比读十篇泛读的收获大得多。

具体节奏上，我一般每周精读一到两篇，泛读五到十篇。精读的论文要写笔记，重点记录它的核心设计、关键实验、以及我自己复现时遇到的问题。泛读的论文只需要知道它解决了什么问题、用了什么方法、结论是什么。这样坚持下来，一年能精读五十篇左右，基本能覆盖这个方向的主要进展。

另外，多动手，少空想。多模态这个方向，很多细节是论文里不会写的，只有自己跑过代码才知道。比如 cross-attention 的初始化、token 压缩的具体实现、数据加载的优化，这些工程细节往往决定了复现的成败。我见过太多人论文读得很熟，但一动手就卡住，就是因为忽略了这些"脏活累活"。

复现的时候，建议从小的配置开始。不要一上来就复现最大的模型，先用小模型、小数据把整个 pipeline 跑通，确认每个环节都正确，再逐步放大。这样即使出问题，也容易定位。我一般会先用几百条数据做一次完整的训练和评估，确认 loss 能正常下降、评估指标合理，再上全量数据。这个习惯帮我省了很多时间。