最近半年一直在折腾多模态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项目的人认真研究。
