今天这场面试，一进门我就觉得不太对。

桌上没有常见的算法题白板，也没有让我手写代码。面试官把一副耳机推到我面前，说：“先听一下。”

我戴上耳机，里面是一段实时语音 AI 的演示。用户刚说到一半，AI 已经开始接话；用户突然插嘴打断，它又能立刻停下来重新听。那种感觉不像以前的语音助手，等你说完一句，转成文字，再慢悠悠回复。它更像一个正在和你抢话的人。

她说：“最近 GPT-Live 这类实时语音系统又被讨论起来了，你觉得这里面最关键的技术点是什么？”

我当时有点想当然，脱口而出：“应该就是 Whisper 把语音转文字，LLM 理解一下，再 TTS 读出来？”

她没有马上反驳，只是把耳机摘下来，盯着我看了两秒。

那两秒很长。

她问：“如果只是语音转文字，那它怎么边听边说？用户打断的时候，系统到底是在处理音频、文本，还是在做跨模态推理？”

我开始意识到，自己把多模态想得太薄了。

她又补了一句：“再说图像、音频、视频、文本进入 Agent 后，不可能都靠一句‘转成文字’糊过去。你讲一下，LLM Agent 在多模态任务中到底怎么做推理。”

然后她把原题抛了出来：

“LLM Agent 在多模态任务中如何执行推理？”

面试结束后，我回去重新整理了一遍。下面是我的面试复盘。

回答重点

这题先抓一句话：多模态推理的关键，是把图像、音频、视频、文本这些不同形态的信息，转换成模型能理解的语义表示，再让 LLM Agent 做融合、判断和行动。

面试里如果只说“图片给视觉模型、语音给语音模型、文本给大模型”，答案会显得很散。更稳的说法是先讲统一表示，再讲融合方式，最后讲 Agent 怎么调用工具完成任务。

主流方案大概有三种。

第一种是视觉-语言融合。比如用 CLIP、BLIP-2 这类视觉编码器，把图像转成 embeddings，再和文本输入一起送进模型。也可以直接使用带视觉理解能力的大模型，让模型一站式处理图片和文字。比如让模型看一张简历截图，判断候选人是否写了真实项目；或者看一张后台报错图，结合报错文本判断问题出在哪。

第二种是语音-文本桥接。工程上常见做法是先用 Whisper 这类 ASR 模型把音频转成文本，再交给 LLM 分析和生成响应。这条路最容易落地，客服录音分析、会议纪要、语音问答都可以这么做。但它也有明显边界：如果你要处理实时打断、语气、停顿、多人重叠说话，只转文字就不够了。

第三种是工具链调用。LLM Agent 不一定自己吃掉所有模态，它可以按任务需要调用 OCR、物体检测、视频帧提取、语音识别、图像检索等工具，把工具结果合并进上下文，再做更高层的推理和决策。

这也是 Agent 场景里更常见的落地方式。比如用户上传一段面试录屏，Agent 可以先抽关键帧，再识别屏幕文字，接着转写音频，最后把“画面变化 + 说话内容 + 时间顺序”放到一起分析。它推理的对象已经不只是文本，而是一串被结构化后的多模态证据。

如果要用代码理解多模态调用，可以把下面这段当成示意：图片先转成可传输的数据，再和文本问题一起交给视觉模型处理。真实项目里要按当前 SDK 和模型能力调整写法。

import openai
import base64

with open("image.jpg", "rb") as f:
    image_data = base64.standard_b64encode(f.read()).decode("utf-8")

response = openai.chat.completions.create(
    model="vision-capable-model",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "这张图里有什么？"},
            {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_data}"}}
        ]
    }]
)

面试里讲到这里，最好补一句工程判断：简单任务可以先把模态结果转成文本再交给 LLM；复杂任务要考虑模态对齐、时序关系、工具链编排和结果校验。

扩展知识

多模态推理真正绕不开的是模态对齐。

图像是像素矩阵，文本是 token 序列，音频是波形信号，视频还多了时间维度。它们原本不在同一个表示空间里。如果模型要理解“图里这个按钮”和“用户说的右上角登录按钮”指的是同一个东西，就必须把不同模态映射到接近的语义空间里。

CLIP 的思路很典型。训练时给模型一批图像和对应文本描述，让匹配的图文向量更近，不匹配的更远。训练完成后，一张“猫坐在沙发上”的图片和这句话的文本描述，向量就会靠得更近。这样模型才能做图文检索、图文匹配，也能成为后续视觉语言模型的底座能力。

BLIP-2 的思路更偏工程节省。它不重新训练整个大模型，而是冻结图像编码器和 LLM，中间加一个 Q-Former 映射层。这个小层负责从图像里抽取对语言模型有用的视觉特征，再交给 LLM 理解。好处是训练成本低很多，资源受限时更容易落地。

如果处理视频，问题会再复杂一层。视频不是一堆图片简单相加，它有先后顺序。常见做法是先抽关键帧，比如每秒抽 1 到 2 帧；再对每个关键帧做视觉理解；如果视频有声音，还要用 ASR 转写音频；最后按时间线把画面、声音、字幕、动作合并起来。

比如分析一段会议录像，模型要知道谁先提出方案，谁后面反对，哪个时间点屏幕上出现了关键表格。这个时候，只把视频里每一帧单独描述一遍是不够的，Agent 需要把信息按时间组织起来。

工程实践里还有几个坑。

第一是上下文长度。多模态输入很吃 token，一张图片、一段音频、一串 OCR 结果，很快就能把上下文塞满。真实项目里不能什么都往 LLM 里倒，要做筛选、摘要和缓存。

第二是延迟。图像编码、ASR、视频抽帧、工具调用都会增加耗时。实时语音场景尤其敏感，如果系统每一步都串行执行，用户很快就会觉得它“慢半拍”。这也是为什么实时语音系统会讨论流式处理、打断处理和全双工交互。

第三是幻觉。多模态模型有时会“看见”图片里没有的东西，或者把视频里的动作理解错。关键业务里不能只相信模型一句话，最好加 grounding、检测模型或人工审核，把模型说的内容和原始证据对应起来。

这题答到最后，面试官其实想听你能不能把多模态推理讲成一条工程链路：输入怎么进来，模态怎么对齐，工具怎么调用，结果怎么融合，错误怎么校验。

面试官追问

追问：CLIP 的对比学习具体是怎么做的？为什么能让图像和文本在同一个空间里？

回答：CLIP 训练时会拿一批图像和对应文本描述，让配对的图像 embedding 和文本 embedding 靠近，让不配对的样本远离。比如一个 batch 里有 N 对图文，每张图的正样本是自己的文本描述，负样本是其他 N-1 条文本。反过来文本也一样。训练久了以后，图像编码器和文本编码器虽然结构不同，但输出会落到可比较的语义空间里，所以可以直接算相似度。

追问：视频太长，关键帧抽取会丢失信息，有没有更好的处理方式？

回答：可以从抽帧策略和模型能力两边优化。抽帧不要固定每隔几秒取一帧，可以基于场景切换、画面变化、语音转折点来抽关键片段。模型上也可以用 VideoMAE 这类视频编码器，直接建模连续帧里的时序信息。工程里常用分层方案，先粗略摘要整段视频，再挑关键片段做精细分析，这样比把整段视频全塞进去更稳。

追问：多模态模型的幻觉问题怎么缓解？

回答：先让模型少猜，prompt 里明确要求只描述图中确实存在的内容。更稳的是做 grounding，让模型输出内容时标注对应的图像区域或证据来源。关键场景还可以加后处理校验，比如用物体检测模型验证它说的对象是否真的存在。视频和语音场景也一样，最好保留时间戳和原始证据，方便回查。

追问：实时语音系统里，为什么单纯 ASR 转文字再交给 LLM 可能不够？

回答：ASR 串联方案适合普通语音转写和离线分析，但实时语音要处理打断、停顿、语气、多人说话、边听边说这些问题。用户说到一半改口，系统不能等整句结束后再反应。工程上就要考虑流式音频处理、增量理解、响应中断和状态管理。这个时候多模态 Agent 处理的不是一段完整文本，而是一条不断变化的音频和语义流。

多模态推理这题，背几个模型名不难，难的是别把它讲成“把所有东西都转成文字”。面试官真正想听的是，你能不能把图像、音频、视频和文本放进同一套 Agent 工程流程里，让模型既看得懂，也能查证、能调用工具、能承担后续决策。

更多多模态推理、实时语音、Agent 工具链相关面试题，可以进入面试鸭继续查阅。