模式矩阵 /模式白皮书/P4

P4 · Multi-Modal Fusion · 多模态融合

字段	值
双轴坐标	感知 Perception × 并行 Parallel（撒）
成本档	③（多路 specialist 处理器 + vision 调用，开销显著）
课程对应	02-05
目录归属	全集 33 模式之一 · 感知模块 4 模式之一
一句话	Agent 接到的输入有图、有文、有表、有日志，把每一种转换成最适合 LLM 消化的形态，再合并喂给推理层。

它解决什么问题

感知模块前三个模式处理的都是文本流，怎么挑、怎么压、怎么找。多模态融合换一种形态：PDF、图表、表格、扫描件、日志混在一起的异构信息。把一份 80 页研报整份喂给 vision 模型，y 轴刻度密、像素糊，市场规模 5800 亿被读成 5800 万，差了一千倍；全部 OCR 成纯文本又把图全丢了，研报里真正值钱的市场规模柱状图、竞争格局饼图坍缩成一句"图 3 显示市场份额"，Agent 读到等于没读到。

多模态融合把这件事工程化，关键在数据进入上下文之前：哪一段该走 vision、哪一段该转文本、哪一段应该被丢掉。它处理的是 Agent 还没"想"之前的输入形态问题——形态错了，下游怎么挑、怎么压、怎么探都是在错误的形态上继续消耗。

为什么坐标是「感知 × 并行」

纵轴 · 感知：融合处理的是多通道输入（PDF、图、音、结构化数据）合成统一表示，是感知最原始的"融合"问题，发生在推理之前。
横轴 · 并行：每一路数据同时交给各自的 specialist 处理器（PDF parser、OCR、table extractor、日志 sub-agent）并行转换，各路互不依赖、可同时跑，再由一个 fuser 把多路结果聚合（gather）成统一的 prompt content。这是典型的扇出—聚合（fan-out / gather）：N 路并行处理 + 一次合并，不是单链顺序，也不是单点路由。

核心机制

融合的核心判断是给每一路数据选对载体，再合并。判定标准就一条铁律：空间信息是信号才保留为图，结构信息是信号该转 markdown。

输入类型	默认处理	成本对比
架构图、流程图	转 Mermaid	8 节点图 Mermaid ~50 token，draw.io XML ~1200，差 24×
表格、结构化数据	转 GitHub Flavored Markdown	10×6 表 markdown ~150 token，截屏走 vision ~1398，差 9×
chart、heatmap	保留图但只做检索 anchor，要数字走 chart→CSV 二次提取	vision 直读 chart 准确率低，不能当推理引擎用
长日志（>> 窗口）	三层流水线	见下

两个机制撑起工业级融合。第一，vision token 的真实数学。同一张 1024×1024 喂三家差 16 倍（GPT-4o detail=high 765、Gemini 1032、Claude Sonnet 1398、GPT-4o detail=low 仅 85）；prompt cache 是最值钱的一刀，cache reads 是 base rate 的 0.1×，重复读同一份 PDF 省 90%。第二，长日志三层流水线：bash 预过滤（grep/awk/jq 在 shell 把 500MB 缩到 5-10MB，只烧 CPU 不烧 token）→ sub-agent 处理（便宜模型读完返回 200-500 token 结构化摘要）→ 结构化产物回主 context（JSON 而非 free text，原始日志的指针留在摘要里需要时再查）。500MB 日志直灌 Sonnet 约 $150 还可能溢出窗口，走三层约 $0.16，差约 940 倍。

适合的生产场景

金融研报分析：PDF 表格 + 分析师文字 + 市场规模图表，每一路单独看都不完整，必须拼起来才能下判断。
保险理赔：事故照片 + 报案文本 + 结构化保单数据合一。
运维事故响应：监控截图 + 长日志片段 + 配置文件，长日志必走三层流水线。
任何输入混着结构化和非结构化的场景：判断标准是各路信息是否互补——如果只是同一信息的重复表达，跳过融合直接进推理，融合是有成本的。

容易出错的地方

看错图：研报 5800 亿读成 5800 万就是这一类，chart 直读准确率本就低，且 multi-turn 有传染性——早期一轮看错，后面跟着错。对策是 cross-field consistency check（图里提取的数字要跟文本区同名数字对得上，对不上触发人工 review），每轮重新校验图源，不要在第三轮还用第一轮看错的数字推理。
图片 input 月底账单爆炸：POC 阶段每月 $50，上生产变成 $2.5M/月。根因是 agent loop 每跑一步都把整个 prompt（含那张 800KB 图）重新打包发一遍，图片付 N 次不是一次。对策三层：budget guard（USD/token/wall-clock/recursion-depth 四道天花板，任一触发即 halt）、thumbnail-first（默认低分辨率，需要细节再请求 high-res）、prompt cache。
sub-agent 死循环、finding 丢失：四个 agent 互相调用，无人值守的周末烧掉 $47,000 / 264 小时。根因是 handoff 时 long-form context 被截断，下游拿到残缺指令又回头问上游，循环起来。对策是 Memory Pointer Pattern（完整 finding 存 state store，context 里只传 pointer ID）+ pre-execution budget enforcement（每个 sub-agent 启动前强制声明 budget，超出就 kill）。
截断阈值一刀切：按 tool 语义分别定阈值才对——bash 头尾各半（错误常在结尾 stack trace）、read_file head-only（信息密度集中前段）。一刀切无论切多大都会在某个 tool 上失真。

关键指标

按形态的 token 占比（image > 50% 或 log > 40% 即告警）：某形态占比悄悄漂移，比如 image 突然涨到 60%，几乎一定是该转表格/markdown 的图没转。这种诊断比"总 token 涨了"早报警，能在账单爆炸前发现。
agent loop 的 budget 触发情况（必须有 pre-execution cap）：四道天花板（USD/token/wall-clock/recursion-depth）的触发与拦截记录。卡不断或卡得太晚就是 $47K 风险。
chart 路径的二次提取率：走 vision 的 chart 中有多少做了 chart→CSV 提取再计算。直接拿 vision 输出的数字做推理是高风险信号。

最小骨架

fuse(inputs):                       # inputs 是多路异构输入
    对每一路按形态分发：
        TEXT   → 直接进 content
        IMAGE  → base64 走 vision（空间信息是信号才走这条）
        TABLE  → 转 markdown（结构是信号，省 9×）
        PDF    → 抽目录 + 定位关键页 + 关键图走 vision + 表转 md + 装饰图丢
        LOG    → bash 预过滤 → sub-agent 摘要 → 结构化 JSON 回主 context
        AUDIO  → STT 转文本
    合并成统一 content blocks，返回 + 一份 trace（每路 modality / tokens_out / method）
health_check：按形态盯 token 占比，异常形态早报警

specialist 工具（ocr / stt / pdf_extract / log_subagent / bash_filter）用注入而非封装，迁移环境时只换注入实现（如 OCR 从 Textract 换本地引擎），不动 fuser 主流程。多模态依赖（cv2、pyaudio、pdfplumber）要 lazy import 到函数体内并加 ImportError 兜底，避免在 headless 环境启动即 crash。

企业落地一例

一个券商研报分析 Agent 做了三版。V1 把 80 页 PDF 整份喂给 vision，单次约 90K token、$0.27，柱状图市场规模 5800 亿被读成 5800 万。V2 全部 OCR 成纯文本，token 降到 35K 便宜一半，但摘要句子通顺、销售要点全空——值钱信息恰恰长在图表里，转文本后空间信息全坍缩。V3 没再调 prompt，重新设计 pipeline：PDF 先抽目录、定位关键页、关键图保留原图走 vision、表格转 markdown、装饰图直接丢，最后塞给模型 18K token，比 V1 省 80%，数字核查也过了。一份 PDF 客户经理一天平均查 8 次，开 prompt cache 后单份日均成本从 $2.16 降到 $0.46。工程师的复盘是写了三周 prompt 都没用，最后救场的是重新想数据该长什么样。

与其他模式的关系

上下文分诊（P1）、语义压缩（P2）、渐进发现（P3）：融合在感知四把刀的最前。形态错了，下游 Triage 怎么挑、Compaction 怎么压、Discovery 怎么探都是在错误的形态上继续消耗。
扇出聚合（C2，协作模块）：长日志三层流水线里把过滤后数据交给 sub-agent 处理，是扇出聚合在感知层的体现——多个 specialist 处理器并行处理后汇到中央 fuser。
分层记忆（Memory 模块）：sub-agent 死循环的对策 Memory Pointer Pattern 与记忆模块共享同一思路——完整产物存外部 store，context 里只传 pointer。

一句话记住它

多模态融合不是 prompt 工程，是数据形态工程——好的融合让 Agent 看到恰当的少，而不是完整的多。

本页属于 ADPS 33 模式白皮书。返回模式矩阵与白皮书目录，或查看配套可运行代码目录。