最近半年一直在折腾多模态Agent的落地踩得最深的一个坑就是模型看起来什么都会但真正到关键决策的时候经常一本正经地胡说八道。尤其在音视频、图文混合输入的场景下视觉模块说“图里有一只狗”语言模块却说“用户问的是猫”两个模块各说各话Agent最终照着错误的那路信息往下执行整个链路就跑偏了。当时我就在想能不能让Agent在回答之前先“过一遍脑子”对自己哪路信息有把握、哪路信息不确定做一个内部评估然后再把不同模态之间的信息拿来做交叉验证。后来看到AAAI2026的多模态Agent专题里有个工作叫InEx思路跟我当时想的几乎一模一样但人家做得更系统先内省再做跨模态交叉核验。这篇文章就把我对InEx的理解、拆解、以及实际工程里怎么把它搬进自己项目里的经验一次性写清楚。InEx解决的核心问题可以一句话概括多模态Agent在面对冲突信息时如何知道自己“不知道”并且通过跨模态的证据链来消除不确定性。它做的事情不是发明一个新的多模态大模型而是在既有模型之上加了一套可插拔的“自检与核验”机制。对于正在做Agent落地、尤其是涉及多路输入多模态理解的同学这套思路有很强的参考价值。1. 为什么多模态Agent需要“内省交叉核验”这套机制1.1 多模态Agent的“盲信”问题远比想象中严重先说说我在实际项目里遇到的问题。之前做一个智能会议纪要Agent输入是会议录音转写文本加上PPT截图目标是自动生成一份包含“讨论结论”“待办事项”的摘要。第一次跑通的时候效果还挺惊艳但一上真实会议就露馅了。有一次PPT上明明白白写着“Q3目标1200万”转写文本里发言人说的是“我们Q3目标是至少1500万”两个信息源冲突了。Agent最后在摘要里写了Q3目标1200万因为它更“信任”视觉模态给出的数字完全没有意识到文本模态里有相反的证据。这类问题的本质不是模型笨而是多模态Agent默认了一种“所有模态都是互补的”假设现实里却经常出现模态间矛盾、噪声、过时信息。更麻烦的是常见的大模型范式并不鼓励模型说“我不确定”而是倾向于生成一个听起来自信满满的答案这就把“盲信”问题进一步放大了。InEx针对的正是这个痛点。它不做简单的vote融合也不搞“谁的分数高就听谁的”这种粗暴策略而是先把每一路模态的内部置信度算清楚再用高置信度的模态去核验低置信度的模态最后产出一个带证据链的回答。1.2 交叉核验为什么优于“打分融合”和“概率平均”先讲一个反直觉的结论在多模态信息冲突的时候加权平均往往比单模态更差。原因很简单。假设视觉模块对检测结果“画面中有红绿灯”给出0.9的置信度语言模块对转写文本“前方路口没有红绿灯”给出0.85的置信度。如果你做加权平均两个分数都挺高最后模型会倾向于输出一个“综合后的模糊结论”比如“路口交通信号信息存在不确定性”。这种结论在Agent决策链路里几乎没有价值既不能用来开车也不能用来规划路线。更好的做法是像InEx这样先识别出两个模态的证据其实指向同一个目标然后进入“举证”流程哪个模态的证据结构更完整、内部一致性更高就以它为锚点去质询另一个模态。交叉核验的意义在于它把“哪一路信息可信”这个问题从“容易受到打分尺度和阈值影响的数值比较”转化成了“在同一个任务目标下两路证据能互相印证吗”的逻辑判断。后者天然更适合语言模型来做也更接近人类做决策时的思维方式。你会看到InEx的核心触发条件不是“两个模态分数都低”而是“两个模态针对同一任务给出了指向不同的证据”。只有在这种情况下内省才有意义核验才有靶子。2. InEx的两阶段核心流程拆解InEx的完整设计如果只记一句话就是“先审己再核他”。具体来说它把一次多模态Agent的决策过程拆成两个阶段内省阶段和交叉核验阶段。前者负责搞清楚“我掌握了什么、哪部分可信”后者负责“用可信的证据去验证可疑的证据”。2.1 内省阶段让模型说出“我不知道”内省阶段是整个流程的灵魂也是InEx区别于大多数多模态Agent方案的原创点。它不是让模型简单地输出置信度而是强制模型在回答前先完成三类自我评估第一是模态完整性自检。当前手头掌握的图像、文本、音频等模态输入是否覆盖了回答这个问题所需的关键信息有没有哪一块是缺失的这一步非常重要因为很多幻觉问题的根源不是模型能力不够而是输入本身就不完整模型却强行回答了。第二是令牌级不确定性评估。这一点在LLM上实现得很成熟但在多模态Agent里容易被忽略。实际操作时InEx会拆解最终回答里的每个关键实体或命题逐个查看它在token预测层的概率分布。如果发现某个关键名词的概率熵特别高就会把这个实体标记为“可疑点”留到下一阶段做交叉核验。第三是跨模态关联度检查。这一步要回答的问题是“我这路模态的证据和另一路模态的证据指的是同一个东西吗”很多时候视觉模块说“图中有一个人”文本模块说“用户询问持卡人姓名”两个信息源虽然都指向“人”但它们在任务层面并不构成有效的证据关联。内省阶段会提前把这些不匹配暴露出来。内省阶段输出的是一个结构化结果哪些断言是可信的、哪些是存疑的、存疑的原因是什么。这个结果不直接作为最终答案而是作为下一阶段核验的输入项。2.2 交叉核验阶段用“证据链”代替“分数投票”交叉核验阶段的实现思路用工程类比来说就是把“软标签对比”升级为“硬证据比对”。假设内省阶段发现文本模态提到“会议决定延期到周五”而视觉模态输入的日历截图显示“会议时间周四15:00”。这两个信息冲突了。传统做法是分别给两路信息打分然后看谁的分数高。InEx的做法是构造一个核验query把“周五”和“周四15:00”作为两个检测项生成一个中间态模板——“日历截图中的会议日期是{候选值A}会议转写文本中的会议日期是{候选值B}请核验两个信息源是否指向同一事件并以证据为准输出修正后的结果。”这个模板的作用是把跨模态比对转化成模型更擅长的“同一任务下的证据交叉检验”而不是让模型在不同模态之间做抽象权衡。更有意思的是InEx在这个阶段还支持多轮核验。第一轮核验如果仍然分不出决定性证据它会针对存疑点生成新的查询条件递归地调用新的视觉模块或搜索模块去补充证据直到证据链闭环或者达到预设的最大轮数。这个“宁可多问几轮也不强行输出”的设计是多模态Agent在可靠性上迈出的很关键一步。2.3 内省与核验的交互流程示意为了方便说明我把整个过程整理成了一个自检五步流程Agent接收多模态输入图片文本可能的音频。内省阶段运行输出“可信断言”“存疑断言”“缺失信息”三组列表。如果存疑断言列表为空Agent直接基于可信断言作答。如果存疑断言存在则对每个存疑项构造交叉核验query触发对应的模态工具去验证。核验结果回填更新断言列表循环直到满足输出条件。这套流程的工程意义在于你不需要换掉底层的视觉模型或语言模型只需要在Agent的推理链路里插入一个“内省核验”的中间层就能显著提升最终回答的可靠性和可解释性。3. 实操层面把InEx搬进你自己的Agent项目看完前面的思路拆解接下来是大家最关心的部分这套方案在工程上到底怎么落地我在自己的项目里做了一个轻量版实现不依赖专门的大模型只用现有开源组件也可以跑通完整流程。下面把关键步骤和代码思路梳理出来。3.1 底层模型选型建议InEx不挑具体的多模态模型但不同选型会直接影响内省阶段的效果这一点务必重视。我的建议是“强语言模型中等视觉模型”的搭配。也就是说与其用一个端到端的多模态大模型不如把视觉理解和语言推理拆开。视觉部分用CLIP或SigLIP这类对比学习模型来做图文匹配打分语言部分用ChatGLM、Qwen、DeepSeek这类上下文理解能力强的模型来做内省和核验判断。原因有两点。第一内省阶段需要的不是“能不能看明白图”而是“能不能清晰描述自己看图时的不确定性”这种能力目前在纯语言模型上更成熟。第二拆开之后每个模块的日志、置信度、中间结果都是透明的这对后续调试和审计非常有帮助。视觉编码器负责把图像转成特征向量并和文本候选描述计算相似度分数语言模型负责读取这些分数、生成内省报告、发起交叉核验。两个模块各司其职比单模型硬扛所有任务要稳得多。3.2 内省置信度计算的关键实现内省模块在代码层面的核心是一个“多模态置信度评估函数”。我的实现思路是这样的对每个关键的语义单元比如一个名词短语或事件三元组分别从文本语义关联度和视觉语义关联度两个维度去打分再计算两者的分歧度。文本语义关联度用LLM对“该断言与已知上下文的逻辑一致性”打1-10分视觉语义关联度用CLIP计算图像和对应文本描述之间的cosine similarity映射到0-10分。当两者分差大于阈值时判定为存疑断言进入核验流程。这里有一个细节值得注意CLIP的score分布并不是均匀的它天然偏向于对某些类型的描述给高分。所以不建议直接用原始similarity值作为绝对分数而是要在你的数据集上做一个归一化。实际操作中我通常会采集几百条“图文匹配”和“图文不匹配”的样本然后计算当前阈值下的精确率和召回率找到平衡点。3.3 交叉核验的工程实现示例交叉核验模块的核心是一个“证据对比函数”。它的输入是内省阶段标记的存疑项输出是对应模态的核验结果。我用一个实际场景来演示。假设视觉模块说图片里有一辆红色汽车语言模块对应的文本描述却写着“一辆蓝色卡车”两者明显冲突。交叉核验模块的做法是生成一个结构化比对请求包含目标对象、颜色属性、以及两个冲突的候选值然后把请求发送给视觉编码器重新计算图像中主体对象的颜色属性分类置信度。这一步的关键在于你要把比对请求做得足够“窄”。不是问“图片里有什么交通工具”而是问“图片中主体对象的颜色是红色还是蓝色”。问题越窄视觉模型回答的可靠性越高交叉核验的结果就越有价值。核验完成后如果返回的结果能明确支持其中一路模态就以该路模态为准修正最终回答如果仍然模糊就把这个存疑项标记为“待进一步确认”并在最终输出中明确提示用户该信息未被验证。这个“诚实标注未验证信息”的行为在实际产品里反而是加分项。3.4 阈值设定与经验参数我在这套流程里用了三个关键经验参数大家可以直接拿来用再根据自己数据集微调内省判定阈值文本与视觉分数差异大于等于3分10分制时标记为存疑断言。核验置信阈值交叉核验返回的匹配概率低于0.75时拒绝采纳该证据。最大核验轮数单条断言最多核验2轮超过则转入“未验证信息”类别。三个参数单独看都不复杂但组合起来决定了整个系统“多疑”到什么程度。阈值调得太高模型会过度自信跟没加InEx差不多阈值调得太低又会陷入无限核验的循环拖慢响应速度。实践中我从阈值2.5起步逐步上调最后在3.0找到了准确率和耗时的平衡点。4. InEx在真实应用场景中的定位与效果观察4.1 适合什么样的业务场景InEx不是万能的它对场景有明确的选择偏好。从我的落地经验来看最适合的领域是那些“信息冲突代价高、用户容忍度低”的场景。典型代表是会议纪要与日程管理Agent。这类场景天然多模态文档、语音转写、日历截图、邮件正文常常混在一起且互相矛盾的情况非常多。跨模态冲突在真实会议里几乎每天都会发生。另一个典型是智能驾驶座舱里的多模态交互语音指令、摄像头画面、传感器文本信息同时存在任何“自信的误导”都可能带来实际风险。反过来如果场景是“单纯看图写一句话描述”或者“对单模态文本做摘要”InEx带来的收益就不大。因为没有多模态冲突内省找不到核验靶子整套机制退化为普通提示词工程白白增加推理耗时。判断方法很简单看你的Agent输入里是否经常出现“两个不同模态描述同一件事但细节不一致”。有就值得上InEx没有就不用折腾。4.2 推理耗时与成本变化我实测下来加上内省和交叉核验后单轮Agent响应时间会增加大约15%到30%。这个增量主要来自CLIP打分和交叉核验中的额外视觉推理调用。可接受与否取决于业务场景。离线处理场景比如会议纪要30%的延迟完全无所谓但线上实时交互场景比如语音助手这个开销就必须做工程优化了。我的做法是把内省阶段拆成“轻量版”和“完整版”先用规则匹配快速判断是否存在明显的跨模态关键词冲突只有命中规则才触发完整的内省流程。这样可以把平均延迟增量压缩到8%以内同时保住大部分收益。4.3 减少幻觉的实际观测数据在我的项目里对比开启InEx前后的效果幻觉类的错误输出下降了接近40%。注意这个数字不是把幻觉彻底消灭了而是把“明明信息冲突或缺失却照样自信作答”的情况大幅减少了。更关键的变化是系统开始会“拒绝回答”了。之前模型面对信息缺失时会想尽办法编一个答案加了内省之后模型更倾向于明确说“当前输入中缺少关于这一项的确认信息建议补充确认后再做决定。”从产品角度看这种“有分寸的拒绝”比错误的自信回答有价值得多。5. 落地时容易踩的坑与排查实录5.1 示例一内省分数退化成了“摆设”第一次跑通InEx流程后我发现内省阶段的“存疑标记”几乎很少触发所有断言都是高置信度。排查后发现是CLIP分数的归一化出了问题模型对大多数描述都给偏高的相似度分数导致文本和视觉信号很难拉开差距。解决方法是引入“对抗样本”来校准阈值。我特意构造了一批视觉和文本信息不匹配的样本加入测试集反复调整归一化函数直到不匹配样本也能被稳定识别出来。5.2 示例二交叉核验变成了“鸡同鸭讲”在实现交叉核验模块时我犯过一个典型错误核验query写得过于宽泛导致视觉模型返回的结果和存疑项不在同一个语义层面上。比如存疑项是“会议日期”核验query却写成了“根据日历截图判断会议安排”结果视觉模型返回了一大段关于会议主题的文字描述完全没法用来比对日期。修正关键是严格限定核验问题的边界。每个交叉核验query必须满足一条规则问题和存疑项在同一个语义粒度上。存疑项是日期问题就只能问日期存疑项是颜色问题就只能问颜色。5.3 常见问题速查表问题表现可能原因排查步骤存疑标记几乎不触发CLIP分数未归一化或阈值过高统计分数分布引入对抗样本校准阈值交叉核验结果与存疑项不相关核验query语义粒度太粗将query约束到与存疑项相同粒度核验轮数过多响应太慢内省阈值过低陷入过度怀疑调高内省阈值或增加规则预过滤最终结果“太保守”大量未验证信息核验置信阈值设得太高适当降低0.75阈值并补充更精准的视觉query加了InEx后效果没有提升场景本身缺乏跨模态冲突检查输入是否真正出现模态间矛盾5.4 一个小技巧把内省结果写进Prompt我最后再分享一个有奇效的实操细节内省阶段输出的“可信断言”“存疑断言”“缺失信息”三组列表我会直接以结构化文本拼接到下游任务的Prompt里。比如最终生成会议摘要时Prompt中会额外附上这样一段说明“以下信息已经通过跨模态核验确认无误会议时间、参与人。以下信息存在冲突但尚未确认预算数字。以下信息缺失下一步负责人。”下游模型看到这个提示后输出质量会肉眼可见地提升因为它在生成阶段就知道哪些话能说死、哪些话得留有余地。这个小技巧本质上把InEx从“决策过滤层”升级成了“上下文增强层”既保留了核验的价值又让下游模型的能力得到更好的发挥。在实际操作中我最大的体会是InEx的价值不是让你造出一个永远正确的Agent而是让Agent在不确定的时候知道该停下来并且知道该用哪路证据来消除这种不确定。单凭这一点它带来的可靠性提升就值得任何正在做严肃多模态Agent项目的人认真研究。