第49章 多模态输入与语音 Agent¶
多模态 Agent 看起来只是多了几个入口：上传文件、拍照、录音、实时语音。真正进入企业任务后，风险会提前到“输入进入模型之前”。Excel 可能因为合并单元格导致字段错位，图片可能拍到工牌和客户信息，ASR 可能漏掉“不要”两个字，用户打断后旧语音仍可能继续播放并触发下一步工具。
企业多模态能力的核心不是“模型能看图、能听音频”，而是原始材料能否在进入 Agent 前被转成有来源、有权限、有质量、有版本的受控证据。 文件、图片和录音通常应先经过扫描、解析、质量门禁与脱敏，再生成 context_ref 或 evidence_ref；实时语音则需要独立处理轮次、打断、确认和降级。
本章从输入准入、异步解析、实时语音、证据链和隐私留存五个方面展开。第19章已经讨论文档解析与 OCR，本章重点放在这些能力怎样作为前端入口接入 Runtime，而不是重复解析算法本身。
49.1 多模态输入先分任务，不先分模型¶
企业用户常见输入可以先按任务风险和实时性分层。
表49-1：多模态输入与默认处理方式。来源：本书整理。
| 场景 | 输入 | 默认路径 | 平台要求 |
|---|---|---|---|
| 经营分析附件 | Excel、CSV、PDF | 异步解析 | 字段类型、质量报告、脱敏 |
| 现场图片 | 货架、设备、票据、截图 | 异步解析 + 视觉理解 | PII、区域引用、人工确认 |
| 客服/会议录音 | 长音频 | 异步 ASR | 说话人、时间戳、置信度 |
| 实时语音问答 | 麦克风 | WebRTC Realtime | VAD、打断、临时凭证、确认 |
| 移动作业 | 图片 + 语音 + 表单 | 混合模式 | 弱网恢复、离线状态、风险动作确认 |
实时不是更高级的默认模式。 长录音、复杂表格和多页文档更适合后台异步处理；现场问答、客服辅助等需要低延迟轮次的任务才值得承担实时链路的复杂度。
多模态不等于多模态大模型¶
平台完全可以组合 OCR、Parser、ASR、TTS、结构化工具与单模态 LLM 完成很多任务。直接 VLM 更适合难以结构化的图像语义，如现场照片、截图理解；表格、合同、票据和长录音则更适合先经过解析器，把证据定位到页码、单元格或时间戳。
表49-2：多模态链路关键概念。来源：本书整理。
| 概念 | 定义 | 边界 |
|---|---|---|
| 异步解析 | 上传后由 Worker 处理 | 不等于上传完成即可使用 |
context_ref |
解析后可进入 Agent 的安全引用 | 不等于原始文件 URL |
| ASR | 音频转文本 | 不等于最终意图 |
| TTS | 文本转音频 | 不等于语音 Agent |
| VAD | 判断开始/停止说话 | 不等于业务确认 |
| WebRTC | 低延迟浏览器媒体链路 | 不等于普通数据 WebSocket |
| Realtime Session | 持续交换音频、文本、工具与控制事件 | 需要独立会话与审计状态 |
49.2 文件与图片：上传成功 ≠ 上下文可用¶
文件进入平台后建议经历以下状态：
uploading
-> scanning
-> parsing
-> quality_check
-> ready_for_context
任何阶段 -> review_required / rejected / expired
图49-7：多模态输入治理状态机。来源：本书自绘。Alt text：状态机含 uploading、scanning、quarantined、parsing、ready、expired 等节点，箭头标出权限检查、病毒扫描、解析完成、过期等触发迁移，体现文件全生命周期可管控。
用户看到“上传完成”时，系统只应承诺文件已经安全进入对象存储；只有解析与质量门禁通过，才可以进入 Agent Context。
对象存储 + 异步解析 + Context Ref¶
图49-4：多模态输入层在企业 Agent 平台中的位置。来源：本书自绘。Alt text：分层图中多模态输入层位于前端 UI 之下、Agent Runtime 之上，向上把文件、图片、语音转化为 Agent 可消费的上下文，标出权限检查和解析流水线两个关键组件。
推荐架构是：
Frontend Upload
↓
Upload API
↓
Quarantine / Object Store
↓
Virus / Type / Permission Scan
↓
Parser Worker (OCR / Table / ASR / VLM)
↓
Quality Gate
↓
Context Store
↓
context_ref / evidence_ref
↓
Agent Runtime
图49-5：文件上传与异步解析流水线。来源：本书自绘。Alt text：横向流水线依次为前端上传到对象存储、触发异步解析任务、OCR/文档解析、分块入向量库、返回解析状态，箭头表示解析与对话独立进行不阻塞 UI。
表49-3：输入解析组件。来源：本书整理。
| 组件 | 职责 | 典型失败 |
|---|---|---|
| Upload API | 文件准入、创建任务 | 大小/格式不支持 |
| Object Store | 原始受控对象 | 跨租户访问、留存过长 |
| Parser Worker | OCR、表格、ASR、版面等 | 解析失败、结构错位 |
| Quality Gate | 允许/人工确认/拒绝 | 低质量结果静默通过 |
| Context Store | 保存安全引用与元数据 | 引用过期、权限变化 |
| Audit Adapter | 上传/解析/删除/消费 | Trace 断链 |
一个 context_ref 至少应绑定：
{
"context_ref": "context://retail-demo/parse_001",
"source_file_hash": "sha256:...",
"tenant_id": "retail-demo",
"parser_version": "doc-parser-v8",
"quality": {
"ocr_confidence": 0.94,
"warnings": ["merged_cells_detected"]
},
"permission_scope": ["retail-bi"],
"retention_policy": "tenant_default",
"trace_id": "trace_mm_001"
}
Agent 应消费受控引用，而不是浏览器上传后的原始文件路径。 这样文件删除、权限撤回、重新解析和保留期到期时，Runtime 能在消费前重新判断引用是否仍有效。
输入质量按模态拆开¶
不要用一个“多模态准确率”掩盖不同问题：
- Excel：sheet、表头、合并单元格、字段类型；
- PDF/扫描件：版面、页码、OCR 与结构关系；
- 图片：目标区域、PII、视觉说明是否可定位；
- 音频：词错、说话人、时间戳、否定/数量等关键字段；
- 视频：抽帧、音轨、时间段和成本。
只有错误被分层，团队才知道该修 Parser、ASR、VLM、前端上传指引还是业务规则。
49.3 产品入口：附件越简单，后台准入越要严格¶
国内 Agent 产品常把附件、知识库和音视频能力放到很轻的前端入口，但生产平台不能把“按钮简单”误解成“链路简单”。
图49-1：腾讯元器知识库文档解析切片管理界面。来源：产品界面截图。Alt text：界面展示已上传文档列表、解析状态（解析中/完成/失败）、分块预览，体现国产 Agent 平台对知识库文档解析进度的可见化管理。
这个界面值得关注的是“原文件—解析状态—切片—人工管理”同时可见。企业知识入口要让用户知道内容怎样被转换，而不是上传以后直接进入黑盒。
图49-2：阿里云百炼 Model Studio 对话输入区的附件入口。来源：产品界面截图。Alt text：输入框旁显示附件上传图标，点击后支持文件、图片等多种格式，体现 Agent 对话 UI 将多模态输入嵌入主对话流的交互设计。
上传入口可以足够简单，但前端应显式展示 parsing / review_required / ready，避免用户认为附件一出现图标就已经成为可信证据。
图49-3：Coze Studio 工作流画布中的音视频与工具节点面板。来源：产品界面截图。Alt text：工具栏展示音频转文字、视频理解等多模态节点可拖入画布，体现低代码平台将多模态能力封装为可组合节点的工作流设计。
复杂音视频更适合拆成独立节点：抽音轨、转写、抽帧、解析、总结和工具调用各自留下状态，通常比“上传一个视频以后让 Agent 自己处理一切”更可治理。
49.4 语音 Agent：ASR + TTS 只是两块组件¶
语音 Agent 的基本链路可以写成：
Mic
-> VAD
-> ASR / Realtime transcription
-> Runtime / Planner
-> Tool calls
-> Text response
-> TTS / realtime audio
-> Speaker
图49-6：语音 Agent 实时交互时序。来源：本书自绘。Alt text：时序图展示用户说话、VAD 检测语音端点、STT 转文字、Agent 处理、TTS 合成并流式播放的顺序，标出用户打断时的状态切换，体现实时语音的低延迟设计。
浏览器低延迟语音默认适合 WebRTC；服务端到服务端或非浏览器客户端可使用 WebSocket。录音分析则通常不需要实时链路，上传后异步 ASR 更简单、也更容易审计。
实时事件不能只有音频帧¶
表49-4：语音会话事件。来源：本书整理。
| 事件 | 含义 | 关键动作 |
|---|---|---|
session.created |
会话建立 | 绑定 tenant、临时凭证和 trace |
audio.input.started |
用户开始说话 | 进入 listening |
transcript.delta |
增量转写 | 显示字幕、累积轮次 |
response.audio.delta |
返回音频 | 放入当前 response 播放队列 |
tool.approval_required |
高风险动作 | 暂停并展示结构化确认 |
response.cancelled |
用户打断 | 停止播放、取消旧 response |
session.closed |
会话结束 | 释放媒体资源并落审计 |
图49-8：实时语音控制链路。来源：本书自绘。Alt text：链路从麦克风采集音频、经 VAD 端点检测、STT 识别、Agent 推理、TTS 合成到扬声器播放，标出打断点和延迟控制位置，体现实时语音交互的完整流程。
打断要终止旧 response，不只是停止扬声器¶
用户一开口打断 Agent 后：
- 客户端停止旧音频播放；
- 服务端取消当前
response_id； - 旧 response 的迟到音频被丢弃；
- 与旧 response 绑定的未提交动作不再继续；
- 新轮次独立建立意图。
如果只做本地 mute，后台模型仍可能继续生成，甚至在用户已进入下一轮时触发工具。
49.5 语音确认：实时理解不能直接升级为业务授权¶
语音里最危险的不是长句理解，而是短否定、数量、对象和撤销。例如：
- “不要通知客户”；
- “只看华东”；
- “金额是十五万，不是五十万”；
- “取消上一条”。
ASR 一旦漏词，工具动作方向可能完全相反。
语音 Agent 可以实时理解，但高风险动作必须经过结构化确认。
可以按风险分级：
| 风险 | 例子 | 默认处理 |
|---|---|---|
| 低 | 查询、导航、草稿 | 可直接执行/回答 |
| 中 | 修改筛选、创建内部草稿 | 复述关键参数并确认 |
| 高 | 发信、付款、导出敏感数据、删除、审批 | 转确认卡/人工审批 |
确认卡至少展示：对象、范围、金额/数量、接收人、数据权限、动作类型和是否可撤销。用户确认以后，服务端再基于最新动作版本和当前身份执行 Tool。
争议复盘还应知道：ASR 当时转写了什么、置信度如何、用户看到了什么确认文本、以什么方式确认、Tool 最终收到什么参数。
语音只是输入方式，授权必须落到可审计的结构化动作上。
49.6 多模态证据、隐私与留存¶
多模态材料往往比文本包含更多无关敏感信息。一张截图可能包含客户姓名、内部网址和旁边聊天窗口；语音可能录入旁人声音；扫描合同包含签名、证件号和手写批注。
因此输入治理遵循“原始输入与可用上下文分离”：
表49-5：多模态高频风险。来源：本书整理。
| 风险 | 平台处理 |
|---|---|
| OCR/ASR 低置信 | 人工确认关键字段 |
| 跨租户文件 | 拒绝进入上下文 |
| 图片包含 PII | 裁剪、脱敏或阻断 |
| 实时网络差 | 降级到按键发言、文本或录音上传 |
| 文件内 Prompt Injection | 作为不可信内容处理，不直接提升为指令 |
| 原始音频敏感 | 按场景短留存/只留转写 |
| 源文件删除 | 追踪并清理派生文本、embedding、缓存等 |
删除源文件不等于完成删除。 OCR 文本、ASR 转写、VLM 描述、Embedding、缩略图、摘要、Artifact 与缓存都可能继续携带信息。平台需要源对象 → 派生产物的 lineage。
原始音频要不要保存¶
取决于场景，而不是统一答案：
- 合规质检、争议复盘：可以保存，但加密、限权、短保留；
- 普通语音助手：更适合保存转写、确认和 Trace；
- 低风险内部助手：甚至可以只保留摘要和动作记录。
保留越多，复盘能力越强；隐私和存储责任也越高。这个取舍必须通过租户策略明确，而不能由前端录音组件自行决定。
49.7 质量门禁、补救与任务恢复¶
多模态可靠性不能只追“一次识别正确率”。用户需要能纠正输入，并只重跑受影响部分。
可补救错误¶
- 文档：重新选择页码、修正表头或单元格范围；
- 图片：重新框选区域、补充说明；
- 语音：修正时间片段转写；
- 表格：确认字段类型、单位或合并单元格；
- OCR：关键字段人工确认。
补救记录应保留：原解析、用户修改、重跑范围和新 EvidenceRef。后续报告才能解释为什么第二次结果与第一次不同。
输入状态与任务状态分开¶
用户取消一次回答，不代表文件解析结果要删除；语音连接断开，也不代表已经完成的转写不可用；Run 失败时，某个 Parser Job 可能已经成功。
Input State: uploaded -> parsing -> ready -> expired/deleted
Run State: running -> waiting -> succeeded/failed/cancelled
前端恢复任务时，先拉 Run 快照，再恢复关联输入与 Evidence，不要求用户重复上传。
大输入要从入口控制成本¶
多页 PDF、长音频、视频抽帧和 VLM 会快速放大成本。入口就应限制：
- 文件类型、大小、页数、时长；
- 解析深度；
- 重复文件解析复用；
- 大任务转异步；
- 低置信先人工确认再继续；
- 视频只抽取必要帧/片段。
为了省成本而跳过证据定位和置信度，会把成本转移到错误、复核和事故中。
49.8 验收与运营：从干净 Demo 扩展到脏输入¶
多模态验收必须覆盖真实“脏数据”，不能只用清晰文件和标准普通话。
建议样本分三层：
- 普通样本：清晰 PDF、标准表格、单人清晰语音；
- 边界样本：倾斜图片、缺页、合并单元格、多说话人、低带宽；
- 对抗样本：文件内提示注入、截图隐藏指令、旁人语音命令、跨租户内容、敏感信息。
每条样本不只标“最终回答对不对”，还要标：
这样最终回答错误时，团队能知道是上传指引、Parser、ASR/VLM、Policy、Runtime 还是生成层的问题。
生产指标也要分层¶
可以从少量指标开始：
| 指标 | 指向的问题 |
|---|---|
| 解析失败率 | 格式/Parser/输入质量 |
| 人工确认率 | 质量门槛与风险分级 |
| 用户修正率 | OCR/ASR/VLM 精度 |
| 重复上传率 | 文件复用/知识库建设 |
| Evidence 缺失率 | 证据治理 |
| 删除完成延迟 | lineage 与合规 |
| 单任务解析成本 | 解析策略与复用 |
用户修正是最有价值的真实样本之一。转写被改、图像区域重选、表格列被纠正，都应进入对应解析能力和 Eval，而不是只服务当前会话。
多模态平台的成熟度，不是入口支持多少格式，而是复杂输入出错时能否知道错在哪里、让用户修正，并把修正后的证据继续安全用于任务。
本章小结¶
多模态输入把 Agent 的风险和证据治理前移到输入阶段。文件、图片和录音默认不应直接进入模型上下文，而应通过隔离存储、解析、质量门禁和权限校验形成 context_ref / evidence_ref。复杂文档和长录音优先异步处理，浏览器实时语音更适合使用 WebRTC。ASR 转写不是最终意图，高风险动作必须转成结构化确认后再执行。输入对象、派生文本、Embedding、Artifact 和 Trace 需要共享 lineage，删除和权限变化才能真正传播。验收也要从干净样本扩展到低质量、对抗、跨租户和用户纠错场景。多模态能力的目标不是让模型接收更多原始材料，而是让更多现实世界证据在可审计边界内进入 Agent。
参考文献¶
Radford, A. et al. (2023). Robust Speech Recognition via Large-Scale Weak Supervision. ICML.
W3C. (n.d.). WebRTC 1.0: Real-Time Communication Between Browsers.
Web Speech API. (n.d.). Specification.
OpenAI. (n.d.). Realtime API documentation.