大家好，我是十三！欢迎来到十三Tech。
《Agent 设计模式之美》感知模块最后一讲。前三讲（分诊、压缩、发现）都默认一个前提------进入 Agent 的信息已经是某种 token。这一讲处理的是更前面的一步：数据在进入 Agent 之前，应该先变成什么形态。
这一讲叫"多模态融合"，但它给出的判断直接否定了我的直觉：多模态融合不是 prompt 工程，是数据形态工程。
模型供应商负责让模型能看图、读 PDF、听音频。工程师负责判断这张图、这页 PDF、这段日志该用什么形态进入 Agent。
一、图片没想象中那么贵
我以前的本能是"能转文本就转文本"。但这一讲给了 token 数学。
1024 乘 1024 的图大约 1400 token，差不多是同长度文本的 1.5 倍。真正贵的不是单张图，是 80 页 PDF 整份塞进去（超过 15 万 token），和 Agent loop 每一步都重新打包同一张图。
这两个成本陷阱完全可以用 PDF 拆解和 prompt caching 解决------前提是先做 token 数学，而不是凭感觉。
二、老编辑的版面工艺
一个老练的财经编辑不会全做成纯文字：市场趋势用折线图------空间关系是信号；财务数据用表格------结构是信号；分析观点用文字------逻辑是信号。
Agent 工程师也要学这种版面工艺。架构图和流程图保留为图，因为空间关系本身就是信号。表格转 markdown，因为结构是价值。长日志走 bash 预过滤再交给 Sub-Agent，因为数据量远超窗口。
判断标准很简单：这种信息的关键信号，是空间关系、是结构、还是逻辑？ 答案不同，它该变成的形态就不同。
三、金融研报 Agent 的完整 Pipeline
这一讲最具体的例子是一份 80 页行业研报。
MultiModalFuser 把 PDF 拆分成 TOC + 关键页 + 关键图表 + 表格 + 装饰图丢弃，合计约 16K token。对比直接喂 80K，省 82%。然后三个任务并行跑------核心论点摘要、数字事实核查、销售要点生成------成本从 0.27降到0.058。
三个关键工程决策：关键图表识别靠业务关键词字典（"市场规模""市占率""营收""毛利率"），这是金融领域的信号资产；装饰图必须丢（80 页研报 30 到 50 张图里只有 5 到 10 张有信息量）；数字核查必须强制引用，每条数字带 page 或 chart 引用，找不到引用的 confidence 降级。
这套 CriticalChartSpec 关键词不是普通配置，是领域知识沉淀。它和我做服务端时做"业务关键词字典""领域规则引擎"是完全同构的------领域知识必须沉淀成显式的、可维护的结构化资产。
四、lazy import 工程纪律
Hermes Agent 规定音频相关依赖必须 lazy load，不能在 module 顶层直接 import。原因很简单：Agent 运行在各种环境------本机、CI、Docker、远程 SSH、WSL------很多环境没有音频设备也没有 PortAudio。启动时硬 import 音频库，Agent 可能在还没处理任何任务之前就崩掉。
这和服务端做"可选依赖 / 插件机制 / feature flag"完全是同一思路------保护主进程启动稳定性。pdfplumber、cv2、pydub、transformers 这些多模态依赖，凡是 80% 用户不会用到且对运行环境有依赖的，都应该函数内 lazy import 或 try-except 优雅降级。
五、感知模块四讲收束
四讲合在一起切的是同一个问题：当下这个 session 里 Agent 怎么看清楚世界。
注意这里说的顺序是数据形态流水线的先后，不是这几讲的阅读顺序。多模态融合在流水线里最靠前，先决定数据该变成什么形态；分诊再决定哪些信息靠近模型；压缩负责长会话里的工作记忆；发现负责未知空间里的探索。如果形态一开始就错了，后面怎么分诊、压缩、探索都是在错误材料上继续消耗。
这也是整个感知模块给我最大的认知收获：我以前以为 LLM 时代来了以后，做服务端时熟悉的那套工程纪律要么被"长上下文"消解掉，要么需要一套全新的方法。这五讲给出的判断很硬------问题没变，只是载体变了。
虚拟内存管理、工作集理论、日志治理的"行为 vs 状态"分离、主进程不做重活------这些老经验在 Agent 场景几乎可以平移。感知层不是新知识，是老问题在新载体上的回归。
关于十三Tech
All in AI Agent方向的架构师，专注AI工程实践。
相信AI是程序员的最佳搭档，帮助每一位开发者驾驭AI。
公众号：十三Tech
GitHub：@TriTechAI