19 · 多模态交互：语音、Computer Use 与事件驱动
「AI-Agent 面试深度指南」· 模块五 · 知识工程与交互扩展 · 第 19 篇 / 共 32 篇
引言
前三篇讨论的都是"文本进、文本出"的 Agent。但真实世界的接口远不止文本：用户会说话，系统有图形界面，外部事件随时发生。
扩展模态听起来是"加个功能"，实际上它会改变整个 Agent 的运行时假设——交互尺度从秒级压到毫秒级（语音），动作从确定变成不确定（GUI），触发从主动拉取变成被动推送（事件）。本文讲这三类扩展的技术要点与工程挑战。
一、语音：把交互尺度压到毫秒
1.1 三种范式
级联流水线（Cascading）：ASR（语音转文字）→ LLM → TTS（文字转语音）。
- 优点：每个环节可替换、可调试、可观测；
- 缺点：延迟叠加（三段串行），丢失语气、情绪、停顿等副语言信息，难以打断。
端到端全模态（Omni）：单一模型直接处理语音输入并输出语音。
- 优点：保留副语言信息（能听出用户不耐烦）、延迟低、可处理笑声与感叹；
- 缺点：中间过程不可见（无法审查转写文本）、可观测性下降、难以替换组件。
全双工：可以同时听和说，支持打断与附和（“嗯”“对”），最接近真人对话。
- 工程挑战：回声消除、说话人分离、VAD（语音活动检测）、打断检测、流式状态机。
1.2 认知时序的工程解法
一个关键洞察：用户能忍受"思考时间"，但不能忍受"沉默"。
解法是把前台与后台分离：
- 前台：即时回应（“我帮您查一下，稍等”）+ 语气词 + 填充音，维持对话感觉；
- 后台：并行跑深度推理与工具调用。
这在技术上要求 Agent 运行时支持流式与并行，而不是一个阻塞的请求—响应循环。
1.3 延迟预算
语音对话的舒适延迟通常在 500ms 以内。分解下来：
VAD 检测(100ms) + ASR(100-300ms) + LLM 首 token(200-500ms) + TTS 首帧(100-200ms)
这意味着必须流式：ASR 边说边转、LLM 边生成边送 TTS、TTS 边合成边播放。任何环节等待完整结果都会突破预算。
二、Computer Use：把动作空间扩展到屏幕
2.1 为什么需要
大量系统没有 API（老旧的 OA、内部工具、第三方网站）。Computer Use 让 Agent 通过"看屏幕 + 操作鼠标键盘"来完成任务，等于绕过了 API 的缺失。
2.2 三个核心技术点
动作空间设计。动作粒度要够粗：一次"填写表单（字段映射）"胜过十次点击。粒度太细会导致：轮数爆炸、每步误差累积、成本失控。
视觉定位（Grounding）。把自然语言目标映射为屏幕坐标。常见做法：模型输出带坐标的动作，或由专门的 UI 检测模型识别元素并标注编号（Set-of-Mark 思路），再由模型选择编号。后者更稳——它把"像素级定位"转成了"选择题"。
状态确认。每步动作后必须重新截图确认，而不是假设成功。界面有加载、弹窗、跳转延迟，"点了就算完成"是典型错误。
2.3 与机器人操作同构
Computer Use 与机器人操作共享同一条控制骨架：观察 → 决策 → 动作 → 再观察。机器人领域的一个经验同样适用：
开环执行（一次生成完整动作序列，中途不重新观察）会把一次局部失败带到任务末尾；逐步检查（每步后重新读取状态，失败只重试当前步）能恢复；预测式执行（用世界模型预判候选动作的结果）能进一步提升规划质量。
2.4 移动端的特殊困难
- 生态壁垒：权限限制与反自动化机制（技术问题之外还有合规问题）；
- 动态布局：屏幕小、元素位置随内容变化；
- 输入法与手势：文本输入比桌面端复杂得多。
三、事件驱动：从"主动拉取"到"被动推送"
3.1 三个转变
观察：从"Agent 主动去取"扩展为"世界主动推来"——Webhook、定时任务、消息队列、监控告警。
动作：从"回合内做完"扩展为"先发起、后续靠事件收尾"——提交工单后等回调，而不是阻塞等待。
交互：从同步等待扩展为跨渠道异步触达——用户不在线时通过邮件/IM/推送告知。
3.2 同步模型如何支持异步打断（难点）
模型一次生成是一个完整回合，中途插入新事件会破坏上下文一致性。三种处理方式：
回合边界注入：事件进入队列，在当前回合结束后注入上下文。最简单、最安全。
取消信号：Agent 在每个循环边界检查取消标志，收到则做资源清理（关闭子进程、释放锁、保存 checkpoint）后退出。
状态栏呈现：把外部事件以结构化方式写进上下文尾部（“用户在 2 分钟前发来一条新消息”），让模型自己决定何时处理。
3.3 长时程任务的基础设施
- 持久化与断点续跑：任务状态与轨迹落盘，重启后从最近一步恢复；
- TODO/看板驱动：计划显式化，实时标记进度，支持插队与重排；
- 预算与超时：轮数、token、时间三重上限；
- 幂等与重试：外部操作带幂等键，网络抖动可安全重试；
- 进度可见：长任务尤其需要让用户看到"进行到哪一步"，否则用户只会觉得卡住了。
四、三种扩展的共性
4.1 共享的控制骨架
无论屏幕、语音还是物理世界，本质都是：
观察（Observation）→ 决策（Decision）→ 动作（Action）→ 再观察
区别只在于观察的信噪比（截图噪声大、语音有歧义）、动作的可靠性（API 确定、GUI 不确定）、以及时间尺度（API 秒级、语音毫秒级、机器人百毫秒级）。
4.2 一个普适原则
最终是否完成，必须由新的观察来判定，而不是由模型的自我报告判定。
模型说"已保存"不算，要读回来确认；模型说"已点击"不算，要截图确认。这条原则是跨所有模态的可靠性基石。
4.3 成本与复杂度的现实
多模态扩展的成本远高于文本：截图每张数百到上千 token、语音转写按分钟计费、GUI 操作轮数是 API 调用的数倍。因此能用 API 就别用 GUI，Computer Use 应是最后手段而非首选。
五、面试考点与答题框架
5.1 高频真题
Q1：级联语音与端到端语音怎么选？
答：需要可控、可审计、可替换组件（如客服场景要留转写文本做质检）→ 级联；追求低延迟与自然交互（如陪伴、口语陪练）→ 端到端。工程上还可混合：端到端做交互，级联做留痕。
Q2：Computer Use 的主要瓶颈是什么？
答：操作效率（步数多、错误累积）、连续视觉理解（长任务中界面状态跟踪）、动作后的状态确认（有加载与弹窗）、以及缺少 API 校验带来的盲区。缓释手段是粗粒度动作、Set-of-Mark 定位、每步重观察。
Q3：长任务如何支持取消与续跑？
答：状态与轨迹持久化 + checkpoint；循环边界检查取消标志并清理资源；任务带幂等键支持安全重试；用看板呈现计划与进度，支持中途插队与重排。
5.2 加分点
- 能给出语音延迟预算的分解，说明你做过流式链路；
- 能把 Computer Use 与机器人操作类比（开环 vs 逐步检查）；
- 强调"完成与否必须由新观察判定"这一跨模态原则。
小结
多模态扩展的是接口边界，但控制骨架不变。三种扩展各自的关键挑战是：语音在延迟与打断，Computer Use 在定位与状态确认，事件驱动在状态持久化与可取消。无论哪种，都别忘了那条铁律——模型说自己完成了不算数，重新观察一次才算。
