# 多模态与实时交互 前面的章节探讨了 Agent 在文本世界中的设计——通过上下文、工具和代码与数字系统交互。然而，Agent 的交互对象不仅仅是文本和 API。当 Agent 需要听懂用户的语音指令、在屏幕上找到并点击正确的按钮、或控制机械臂精确抓取物体时，它进入了一个全新的领域：**多模态实时交互**——从纯文本输入输出扩展到**多模态感知与实时响应**，这是 Agent 跳出“对话框”的关键一步。所谓“多模态”，就是同时处理多种信息形式——文字、语音、图像、视频、动作——而不只是文本。 先划定本章的边界。静态的图像与文档理解——看一张截图、读一幅图表、解析一份 PDF——已经作为感知工具自然融入了前面各章的 Agent 实践：对今天的多模态大模型来说，这类“一次输入、一次理解”的任务已相对成熟，不需要专门的架构设计。本章聚焦的是另一类问题：**实时性把多模态问题变难**的三个场景——语音对话、GUI 操作、机器人控制。在这些场景中，输入是持续流动的、输出必须在严格的时间预算内给出，架构设计因此发生质变。至于连续视觉流（视频）的实时理解，截至写作时对 Agent 而言仍是开放问题——本章 Computer Use 部分讨论的逐帧截图局限和章末思考题会再回到这个话题。还要划清另一条边界：多模态**生成**（生图、生视频）在本书框架中只是普通的工具调用（第五章多媒体生成已涉及），Agent 把它当作一个外部工具来使唤即可，并不涉及本章要解决的实时交互难题，因此不在本章主线之内。 语音交互、Computer Use 和机器人操作看上去跨越三个完全不同的领域，但做起来会发现卡住的地方高度相似：都要同时处理多种模态的信息，都对延迟极度敏感。语音停顿超过两秒就让人焦躁，机器人控制的毫秒级抖动可能导致碰撞。这两个约束共同把三个场景推向同一个架构方向：从**串行流水线**（像工厂流水线一样，一个环节做完才能交给下一个）走向**端到端模型**（一个统一的模型直接从输入到输出，省去中间的交接环节）。 本章按以下脉络展开： 1. 先用“语音架构的三种范式”搭起坐标系——级联（VAD-ASR-LLM-TTS 流水线）、端到端全模态（Omni，单模型但仍轮流说话）、全双工（Moshi、GPT-Live，边听边说），并沿“如何摆脱 VAD 的轮次假设”这条轴依次拆解每一环的延迟与取舍；其中级联一节还会讲如何用流式语音感知替代 VAD + ASR。 2. 再看思考架构如何调和“实时响应”与“深度思考”的矛盾：从快慢简单并行，到后台推理模型当“军师”的解耦路线（GPT-Live 委派、Pine AI 等），再到 Step-Audio R1 把思考“内化”进单一模型的“边想边说”。 3. 然后讨论更像人的语音合成对执行层的优化。 4. 最后把视角扩展到 Computer Use（让 AI 像人一样操作电脑屏幕）和机器人操作，看同样的延迟与多模态问题在这两个场景中如何表现。 其中要特别提示两处偏理论、可跨场景迁移的重点：**思考架构**（快、慢两套思考如何协作）以及由它衍生出的**快慢接口**（Latent Bridge，快慢模型之间除了文字还能传什么）。它们虽然从语音场景讲起，却不只服务于语音——后面的 Computer Use 与机器人同样会遇到“何时该请一个慢军师”的问题，值得读者格外留意。 ## 语音：最自然的人机接口 在拆解语音 Agent 的架构之前，先退一步看语音本身的价值。在人与计算机的各种交互方式中，语音是带宽最高、也最自然的一种：正常说话的速度约为打字的四倍，且无需占用双手与视线。正因如此，语音正从一种次要的输入方式，逐渐变为不少人日常工作的主交互界面——从早到晚直接对 Agent 讲，而非逐字敲键盘。 落到工具层面，这条路线上大致有两类产品。一类是**语音输入法**（如 Typeless）：把口述实时转写为文字，再送入任意应用，本质上是对键盘输入的替换；另一类是**语音 Agent**（如 Pine、ChatGPT Voice）：用户与之直接对话协作，语音既是输入，也是交互本身。二者最典型的进阶用法，是引言中提到的 **whisper coding**——以口述指挥编程或研究 Agent：开发者讲出意图、与 Agent 反复讨论，再由它执行编码与实验；本书作者团队的十余篇论文正是以这种方式完成的。 需要说明的是，本章接下来讨论的语音架构同时服务于两个方向：用户对 Agent 说话（作为人机接口），以及 Agent 代替用户对外部世界说话（如打电话协商）。两者背后是同一套实时语音技术。下面就从语音架构的三种范式说起。 ## 语音架构的三种范式 要理清语音 Agent 的技术演进，一个清晰的坐标系是 OpenAI 在 2026 年发布 GPT-Live 时给出的三分法[^ch9-12]——它恰好对应了 ChatGPT 语音自身走过的三代架构： 1. **级联（Cascaded）**：把语音识别（ASR）、大语言模型（LLM）、语音合成（TTS）三个模型串成一条流水线，一棒接一棒。最早的 ChatGPT Voice 就是这样，它第一次让人能“对话”前沿模型，但信息在模型间传递时会丢失，回应缓慢而生硬。 2. **端到端全模态（Omni）**：用单一模型直接“听音频、想回复、说出来”，把三段合一，延迟更低、韵律与情感等非文字信息得以保留。但它仍然假设“轮流说话”——模型要等用户停顿才开口，而轮次切换靠静音来判断，稍一停顿或有背景噪音就可能被误判为“说完了”，在不该插话时插话。ChatGPT 的高级语音模式（Advanced Voice Mode）就属于这一代；OpenAI 把它称作“轮次式语音模型（turn-based）”，工业界更常按模型能力称之为“全模态（Omni）”模型（如 Qwen3-Omni），两个名字指的是同一类东西。 3. **全双工 / 交互式（Full-Duplex / Interactive）**：模型边听边说，同时处理输入与输出，每秒做许多次“该说、该听、该停、该打断、还是该调用工具”的决策，彻底取消了“轮流”这个假设。2024 年 Kyutai 的 Moshi 是研究先声，2026 年 OpenAI 的 GPT-Live 把它带到了 1.5 亿用户的规模。 贯穿这三代的其实是同一条主线：**如何摆脱“轮流说话”这个假设，摆脱 VAD（语音活动检测）对轮次的猜测**。级联和 Omni 都还依赖 VAD 划分轮次，只有全双工彻底消解了轮次本身。下面三节就沿这条轴依次展开。三种范式并非简单的新旧替代，而是不同延迟与成本约束下的设计取舍，在 2026 年的生产系统里长期并存。 此外，GPT-Live 还带来第二个结构性变化——把“实时交互”与“深度思考”解耦：遇到需要搜索或复杂推理的问题时，交互模型把任务委派给后台的前沿模型（发布时用 GPT-5.5），自己继续维持对话。这条“快慢分工”的线索会在后面“思考架构的取舍”一节专门展开。 [^ch9-12]: OpenAI. *Introducing GPT-Live.* 2026-07-08. https://openai.com/index/introducing-gpt-live/ 。本节“级联 / 轮次式 / 全双工”三分法即出自该文对 ChatGPT 语音三代演进的总结；文中“端到端全模态（Omni）”对应其“turn-based voice models”一类。 ## 范式一 · 级联流水线（Cascading） 绝大多数商业语音助手——从智能音箱到客服机器人——都基于串行流水线（图9-1）：语音活动检测（VAD）判断用户何时说完 → 自动语音识别（ASR）把音频转成文字 → 大语言模型（LLM）理解意图并生成回复 → 文本到语音（TTS）把回复念出来。就像接力赛一样，每个环节必须等上一棒跑完才能起跑。 ![图9-1 语音 Agent 串行流水线](images/fig9-1.svg) 早期的语音助手采用这种四阶段串行流水线，原因很简单：没有单一模型能同时处理语音识别、语言理解、思考和语音合成四个任务。模块化架构让每个组件可以独立开发和优化。但模块化的代价是延迟累积——每个阶段都要等上一个阶段完成才能开始。 **VAD** 是流水线的起点，持续监听音频流。最关键的设计是结束点检测（End-of-Speech Detection）：通常设置 500-800ms 的连续静音阈值——如果用户停了半秒以上没说话，VAD 就认为用户说完了。这引入了第一层延迟，而且很难两全：阈值设得太短，用户只是思考时停顿一下就被误判为说完，句子被截断；设得太长，用户说完后要干等大半秒才有反应。 **ASR** 把音频波形转成文字。Whisper、SenseVoice 等模型转录 5 秒音频，在 GPU 上部署中小规格模型时通常需要 50-200ms；更大规格的模型或资源受限的部署环境则会达到 200-500ms（实验 9-3 中的对照组即属后者）。更关键的问题在于：在整个 VAD 等待与 ASR 转录过程中，后面的 LLM 完全闲着，没收到任何信息，无法提前开始思考。 **LLM** 推理（inference）阶段，即使优化得当，根据上下文长度不同，首 token 延迟（TTFT，即模型吐出第一个字的等待时间）往往需要 100-500ms，而输出完第一句话又额外需要 100ms 左右。如果启用 reasoning（思考），时间可能延长到 5-10 秒。在传统架构中，TTS 必须等 LLM 输出完整回复文本才能开始工作。 **TTS** 把回复文字转成语音，合成通常需要 200-500ms。把每一环的延迟加起来（图9-2）：VAD（500-800ms）+ ASR（50-200ms）+ LLM（100-500ms）+ TTS（200-500ms），总计约 0.9-2 秒——这还是所有服务都空闲、没人排队的理想情况。 ![图9-2 延迟瀑布：串行累积总响应时间](images/fig9-2.svg) 一旦投入生产，排队延迟会让情况雪上加霜。这和餐厅排队的道理一样：厨房越忙，等餐时间越长，而且不是线性增长而是急剧飙升（图9-3）。当服务器没有任何等待队列时（即“空载”），处理一个请求的时间称为空载延迟。但当多个请求同时到达时，后到的请求必须排队等待。 直觉上，利用率越高，等待时间会非线性地飙升。具体的数学关系可由排队论给出（此处仅作直觉理解，不需要严格推导）：总延迟 ≈ 空载延迟 × 1/(1-利用率)。利用率是指服务器忙碌时间的比例，比如利用率 50% 意味着服务器一半时间在处理请求、一半时间空闲。利用率 50% 时延迟变成空载的 2 倍，利用率 80% 时变成 5 倍——这就是为什么服务器不能长期在高负载下运行。 ![图9-3 排队延迟曲线](images/fig9-3.svg) > **实验 9-1 ★：构建传统语音 Agent** > > 本实验构建完整的实时语音对话系统，支持用户通过麦克风与 AI 语音交互。系统采用前后端分离架构，通过 WebSocket 实时通信。 > > 核心流程遵循严格的串行模式：前端捕获麦克风输入，通过 WebSocket 实时发送到后端。后端运行 Silero VAD 模型进行语音活动检测，相比传统的音量检测方法准确率更高、抗噪能力更强，检测到约 500ms 连续静音后将音频片段提取出来进行后续处理。 > > ASR、LLM、TTS 各阶段均支持多家提供商灵活切换，开发者可根据延迟、准确率和地区网络条件选择最优组合。 > > **实验 9-2 ★：使用 PineClaw Voice API 构建电话 Agent** > > 实验 9-1 构建了浏览器内的语音对话系统，但真实世界中许多 Agent 任务需要拨打真实电话——联系客服协商账单、预约餐厅、确认订单。第四章通过 PineClaw 的 Channel 机制展示了事件驱动架构如何将电话通知的响应延迟从分钟级降到秒级；本实验则聚焦于语音通话本身的构建。以 [PineClaw Voice API](https://pineclaw.com/)（作者团队所开发）为例，这类生产级电话语音 API 通常封装了拨号、IVR 导航（即“查询请按 1，转人工请按 0”这类电话菜单）、对话和转录的全流程：Agent 提供电话号码、目标和上下文信息后，由语音 Agent 完成整段通话，返回结构化的通话记录。 > > **实验目标**：构建一个能通过真实电话完成任务的 Agent，将 PineClaw Voice 作为工具集成到 ReAct 循环中。 > > **技术方案**：使用 PineClaw Voice Python SDK（`pine-voice`），为 Agent 配备 `make_phone_call` 工具。Agent 接收用户的任务描述（如 “帮我预约明天下午 3 点的牙科检查”），通过 ReAct 思考决定：(1) 需要拨打哪个电话号码；(2) 通话的目标和关键信息；(3) 通话结束后如何向用户汇报结果。 > > Agent 的工作流程：用户说 “帮我打电话给诊所预约明天的检查” → Agent 思考需要哪些信息（诊所电话、预约时间、患者姓名）→ 如信息不足则向用户澄清 → 调用 `make_phone_call` 工具 → PineClaw 拨打电话、与对方对话、完成预约 → Agent 收到通话摘要和转录 → 向用户汇报结果。 > > **验收标准**：成功拨打测试电话（可先拨打自己的手机验证连通性）。Agent 能根据任务描述自主决定通话参数，通话结束后正确提取关键信息（预约时间、确认号等）并向用户汇报。对比直接使用 API 与通过 Agent ReAct 循环调用的差异——后者能处理信息不完整的情况（如用户未提供电话号码时先搜索）。 > > 这个实验展示了语音 Agent 的一个重要应用方向：**Agent 不仅能与用户语音对话，还能代替用户与外部世界进行电话交互**。PineClaw 的语音 Agent 经过专门训练，能应付小时级的等待、电话菜单导航和复杂协商——想象一下让 AI 替你打运营商客服电话等候转人工，这些正是传统串行语音管线难以胜任的场景。 ### 级联流水线的全链路流式化 需要澄清一个常见误解：上面 0.9-2 秒的延迟账，算的是“每一环都跑完再交棒”的**完全串行**情形。但 2025 年的生产系统早已不这么做了。主流做法不是抛弃模块化，而是保留 VAD-ASR-LLM-TTS 的分工，同时让每一级都变成**流式**，让相邻环节在时间上重叠起来： - **ASR 边听边转**：采用流式识别，用户还在说，文字就在持续产出，不必等 VAD 判定整句结束再开始转录； - **LLM 按句切分输出**：模型一边生成，一边按标点或语义把回复切成小句，第一句刚成形就往下游送，而不是等整段回复写完； - **TTS 句级流式合成**：拿到第一小句就开始合成播放，后面的句子边生成边补上，用户听到第一个音节的时间大大提前。 这样一来，ASR、LLM、TTS 三级不再是接力棒式的先后关系，而是像流水线上三个同时开工的工位。LiveKit Agents、Pipecat 这类开源框架，以及主流商用外呼系统，走的都是这条路线。全链路流式化之后，端到端延迟通常能压到 600-800ms，明显好于完全串行的 0.9-2 秒。 但流式化能压缩的只是“转录、思考、合成”这三段可以重叠的计算，有一段延迟它压不掉：**VAD 的静默等待与轮次判断本身**。系统仍然要靠 500-800ms 的静音阈值来猜测“用户到底说完没有”，这段等待是流水线开工的前提，无法靠重叠来消除。要连这段延迟也一并压缩，就不能再在“让各级重叠”上着力，而须转向最前端的感知环节本身。 ### 流式语音感知：替代 VAD + ASR 这一感知前端由两级构成——VAD 判断用户是否说完、ASR 将音频转写为文字——二者共同决定了整条流水线何时启动、又接收到怎样的输入。传统的 VAD + ASR 级联存在三个根本问题： 1. **延迟累积**：VAD 必须等 500-800ms 静音才能确认用户说完，因为它无法预知未来，只能靠“等一等”来区分“真的说完了”和“只是停顿想一想” 2. **信息丢失**：VAD 只输出“有声/无声”这样的二值信号，情绪变化、语气起伏、犹豫停顿、背景环境等声学细节全部丢失。误判问题在复杂环境中尤为突出——用户停顿稍长就被误判为说完导致句子截断，背景噪音误触发导致没人说话时系统开始处理，用户附和的一声“嗯”也无法判断到底是想打断还是在表示认可 3. **准确率下降**：VAD 把连续音频切成一段段独立片段，各自送入 ASR 识别，破坏了上下文的连续性。需要前后文才能正确识别的内容（邮箱地址、品牌名、人名、专有名词）错误率明显上升——比如用户报邮箱“john dot smith at gmail dot com”，如果“john”和“smith”被切到不同片段，“smith”可能因为缺少上下文被误识别为“miss” **流式语音感知模型**提供了根本性的解决方案。先澄清“流式”的技术含义：一个语音模型能否流式处理，关键在于**编码器是否因果或分块**（只依赖已经到达的音频，而不需要看到整段录音）以及**解码是否增量**（每收到一小段音频就输出一部分结果）。Whisper 不能流式，并不是因为它的解码方式——它的解码本身就是自回归的——而是因为它的编码器需要一个完整的音频段（固定 30 秒、不足则填充）才能开始工作。还要说明的是，流式识别本身并不是新技术：以 RNN-T 和流式 Conformer 为代表的传统流式 ASR 早已在工业界大规模部署——手机的实时字幕、输入法的语音输入用的都是这类模型——它们与 LLM 并无关系。 本节关注的是一条新路线：**基于 LLM 的流式听觉感知**——以开源 LLM 为骨干做后训练，让模型直接从连续音频流中输出语义级的响应，把“识别”和“理解”合并进同一个模型。它是对传统流式 ASR 的升级，而非流式技术的发明：增量识别的延迟同样保持在单步推理时间（几十到一二百毫秒）的量级，但模型看到的不再是被 VAD 切碎的孤立片段，而是从对话开始到当前时刻的连续音频流，可以基于完整上下文做上下文学习（In-Context Learning），对用户的个人信息、专业名词、发音习惯的识别准确率显著提升。 这条路线的另一个关键优势是继承了 LLM 的世界知识和常识推理能力——毕竟骨干模型见过海量文本。比如模型知道“苹果”后面跟“发布会”大概率指 Apple 而非水果，这种知识增强使得对金额、地名、品牌名等高价值信息的识别准确率远超传统 ASR。这条路线已有可落地的模型，如 Fixie 的 Ultravox——把音频直接送入 LLM 骨干、输出文本与语义 token；本节实验所用的 Qwen2-Audio、阿里的 Qwen2.5-Omni 也属于同一类音频原生模型。 不过，替代 VAD 不一定非得动用一个完整的音频大模型。如果只想解决第一个问题——**判断用户到底说完没有**，还有一条更轻的路子：把这个“轮次判断”直接塞进识别器本身[^ch9-11]。做法是在一个很小的开源流式识别模型上加个 LoRA，让它一边转写、一边**综合语义和静音**判断“这句话是不是已经表达完一个完整的意思”——因为轮内停顿（报电话号码时顿一下）常常比轮间间隔还长，光靠静音阈值必然两头不讨好。更有意思的结论是：模型总在“该不该收话”上摇摆，根源往往不在模型结构，而在**训练标签是用“上帝视角”标的**——标注时用到了决策点之后才出现的音频，而线上的模型根本看不到未来；把每条标签都改成“只用决策当下能拿到的信息”来标，这种虚假的摇摆就消失了。这也呼应了第七章后训练的一条判断：很多时候，数据比架构更关键。这条更轻的路线也已有生产级实现：Deepgram 的 Flux、AssemblyAI 的 Universal-Streaming 把端点与轮次判断直接嵌入流式识别模型、专为语音 Agent 设计；开源侧则有 LiveKit、Pipecat 提供的语义轮次检测模型。 [^ch9-11]: 把轮次判断做进识别器、以及“标签的上帝视角”这一诊断见 Li, Bojie and Noah Shi. *The Trade-off Was in the Labels: Causal Supervision for Turn-Aware Streaming ASR.* 2026（待发表）. 模型输出的不仅是文字，还包括一系列**声学事件的特殊标记**——它们是模型训练时引入的专用 token，模型学会了在检测到对应声学事件时自动输出。常见的几类如下： - ``：基于语义和声学的综合判断来确定说话起止，而非简单的静音检测 - ``：区分用户是真的想打断，还是只是在附和或受到背景噪音干扰 - ``：情感标记 - `` / ``：笑声、叹气等副语言信号 - `` / ``：环境声 这些标记和文字 token 形成统一的事件流，一起送入思考层。 ``` Input audio: "Um, actually I think... no wait, let me reconsider." Model output stream: Um, actually I think... no wait, let me reconsider ``` 注意模型输出的不只是文字转录，还包括语音事件标记（开始/结束说话、情绪变化、沉默间隔）。Agent 框架可以利用这些标记实现更自然的交互——比如检测到用户犹豫时主动提供选项。 > **实验 9-3 ★：使用 Qwen2-Audio 模拟流式语音感知** > > 需要先说明实验设计：Qwen2-Audio 本身是整段输入的非流式模型。本实验采用**分块输入模拟流式处理**——把连续音频流切成固定长度的小块，每块连同此前累积的音频上下文一起送入模型，模型逐步生成文本和声学事件 token（如笑声、停顿等非语言信号），并测量每个分块从送入到产出文本的延迟。这里有个关键代价：Qwen2-Audio 的编码器不是增量式的，每处理一个新块都要把此前累积的全部音频从头重新编码一遍，因此对话越长、累积音频越多，单块的编码延迟就越高——这正是“模拟流式”与“真流式”（采用增量或因果编码器，只对新到达的一小段音频做增量编码）之间的本质差别。这一设计能演示“保留完整上下文的连续感知”带来的准确率收益，但延迟数字只反映分块粒度与推理速度，并不等于真正按流式设计的模型（如采用分块编码的 Qwen3-Omni）的首包延迟；感兴趣的读者可以换用后者重做本实验。对比方案是传统的 VAD + Whisper ASR 流水线。测试三类场景：正常对话、带停顿的长句、含背景噪音的对话。 > > 结果：分块模拟方案的增量识别延迟可以控制在一二百毫秒的量级（具体取决于分块长度与硬件），而传统方案需要等 VAD 确认说完（600ms）再加上 Whisper 推理（本实验配置下约 200-500ms），合计 800-1100ms。在带停顿的场景中，VAD 在第一次长停顿处就误判为说完，把句子截成了两段分别识别，“大概两点左右”因为缺少上下文被误识别为“大概零点左右”；而分块方案保持完整上下文，正确识别了整句。在背景噪音场景中，Qwen2-Audio 输出 `<|noise|>` token 标记噪音存在但不中断识别，传统 VAD 则被噪音误触发，导致识别流程提前启动。 ## 范式二 · 端到端全模态模型（Omni） 回顾整个级联流水线：即便感知前端已替换为流式语音感知，它终究仍将“听、想、说”三者分派给三个独立的模型，彼此之间以一条离散的接口相连。这条接口再宽，也不过是若干语义 token 与零星的声学标记——说话人当下的情绪、语气、语调，以及背景中的环境声与音乐，绝大部分在交接时损失殆尽；何况三段各自训练、各自优化，彼此难以协同。端到端全模态模型（Omni）则另辟蹊径——以单一模型直接“听”音频、“想”回复、“说”出来，将三段合而为一（图9-4）。只要训练数据充分，模型内部的隐空间（Latent Space）便能在文本之外将这些副语言信息直接传递至生成端：延迟更低，韵律与情感也得以保留。取舍在于：**级联流水线**模块清晰、每段可独立调优、可解释性好；**端到端模型**延迟更低、能保留非文字信息，代价是训练数据需求更大、可解释性更差。 还需补充一个常被忽略的维度：端到端的优势主要体现在**延迟**上，在**准确率**维度上并不必然占优。一个值得对照的方案是**自级联**（self-cascade）——由同一模型先将音频转录为结构化文本，再基于该文本进行推理；与其一次性端到端作答相比，何者准确率更高取决于具体任务。其规律可概括为：当答案主要由语义内容（即“说了什么”）决定、中间文本足以充分承载任务相关信息时，自级联的准确率与端到端相当乃至更优，这一优势在感知能力较弱的模型上尤为显著；反之，当答案高度依赖文本难以表征的非语言线索（语调、情绪、环境声）时，端到端方显现出明显优势。更重要的是，二者的优劣**可依据任务性质事先判定**，而非简单归因于“端到端更为先进”。由此可进一步导出一条设计原则：决定性能的关键往往不在于是否引入中间表示这一**瓶颈**，而在于该瓶颈所承载的信息——若将中间文本由单纯的转录提升为附带副语言标记（情绪、语速、环境声）的结构化表示，端到端原有的准确率优势往往随之收窄，这与前文〈流式语音感知〉所主张的“感知层不应仅输出纯文本”一脉相承[^ch9-13]。 但 Omni 无论多强，本质上也只是把三个模型合成了一个，**并未取消“轮流说话”这一假设**：它依然依赖 VAD 来划分发言权——一旦检测到用户出声便停下，用户一静音便随即开口。于是那个熟悉的问题再度浮现：用户报出一串数字、中途略作停顿，Omni 便判定对方已说完而强行插话。前文的流式语音感知能将轮次判断从静音时长升级到语义层面，大幅缓解这类误判，但那终究只是在“轮次”框架内的局部修补，并未取消轮流本身。要**从根本上**跳出这一困境，就不能再于“轮次”框架内修补，而须让模型边听边说、自主决定何时开口，不再存在“该谁说话”的硬性切换。 [^ch9-13]: 级联与端到端在准确率上的优劣何时逆转，以及如何依据任务性质（中间表示能否充分承载任务相关信息）预测其方向，完整的跨模态测量见 Li, Bojie and Noah Shi. *The Cascade Gap: When and Why Self-Cascades Help Multimodal Agents.* 2026（待发表）。 ![图9-4 端到端多模态语音模型架构对比](images/fig9-4.svg) **OpenAI Realtime API** 在模型层面接近端到端（模型原生处理音频），但在交互控制层面仍依赖传统 VAD，属于向完全端到端过渡的中间方案。它最初（2024 年 preview）跑在 GPT-4o 上，2025 年正式 GA 后改用独立的语音专用模型 **gpt-realtime**（不再是 GPT-4o 的一个模式，而是为实时语音单独优化的模型）。API 默认启用服务端 VAD，自动判断用户何时开始与结束说话。支持对话中打断——检测到用户开口时立即停止当前语音生成，就像两个人面对面聊天时一方插话、另一方会自然停下来。gpt-realtime 还引入了异步函数调用：模型可以一边等工具返回结果，一边继续和用户说话，把工具延迟藏在对话过程中。这些都改善了体验，但本质仍在 VAD 框架下做优化。**Gemini Live API** 思路类似，支持 VAD 敏感度配置，打断时保留已发送的信息以确保对话连贯。 **Qwen3-Omni** 采用 Thinker-Talker 架构：将思考（理解与推理）与表达（语音生成）分成两个专门模块，统一了对文本、图像、音频与视频的感知与生成。Qwen3-Omni 的低首包延迟源自生成端（Talker）的架构：它以多码本自回归的方式逐步生成音频 token，配合因果（causal）codec 把这些 token 增量地解码成波形，因此思考模块一产出文本，Talker 就能接着流式合成语音，无需等整段回复生成完毕。据官方报告，其冷启动理论首包延迟低至约 234ms，支持 19 种语言理解和 10 种语言生成，在 36 项音视频基准中 22 项领先。 **Step-Audio 2** 走了一条不同的路线：直接处理原始音频输入，输出文本和音频，实现真正的端到端语音对话。它不仅能理解说了什么（语义信息），还能感知怎么说的——副语言信息（Paralinguistic Information），比如说话人的情绪是高兴还是愤怒、语速是急促还是迟疑、语调是上扬还是低沉——以及背景里的环境声和音乐。它通过思考与强化学习生成富有表现力的回复，还集成了 RAG 机制和外部工具（网络搜索、音频搜索）。据 Step-Audio 2 论文报告，在其提出的 StepEval-Audio-Paralinguistic 副语言理解基准上，Step-Audio 2 的准确率达 83.09%，领先同期开源全模态模型 Qwen2.5-Omni（44.18%），也高于 GPT-4o Audio（43.45%）和 Kimi-Audio（49.64%）。 Step-Audio R1 是 Step-Audio 系列的后续工作，在 Step-Audio 2 端到端语音对话架构的基础上，进一步把思考能力直接内化到音频模型中，两者代表了同一技术路线的递进演化。 ## 范式三 · 全双工交互模型（Full-Duplex / Interactive） 范式二把三个模型合成了一个，却仍守着“轮流说话”的假设——要么用户说、要么模型说，切换点靠 VAD 或语义来猜。可有些场景并不是 “你一句我一句” 的轮流说话。**同声传译**便是一例：译员并不等说话者说完整句才开口，而是边听边在脑中组织，一个意群的意思大致完整便随即译出，聆听与翻译始终重叠进行。**合着音乐击打鼓点**的节奏游戏则更为极端——听觉须持续追踪不间断的音乐流，双手要踩准节拍即时敲击，同时还需预判下一拍，此处甚至无所谓“一轮”，输入是一条永不停歇的连续流。这类任务对 turn-by-turn 模式构成根本性挑战：它们要求聆听、思考、动作同时进行，而轮次模式的前提恰恰是将三者分置于先后不同的时间片。全双工模型正是把“摆脱 VAD”这条路走到逻辑终点——索性取消“轮流”这一假设，让模型**同时持续地听和说**。 研究上的先声是 Kyutai 的 **Moshi**（2024）。它并行建模两条音频流（用户的声音和模型自己的声音），再辅以一条“内心独白”文本流来提升生成语音的语言质量。由于任一时刻都在收听，重叠说话、随时打断都成了天然行为，不需要任何显式的打断检测逻辑，端到端延迟约 200ms，接近人类对话的自然节奏。 2026 年，Mira Murati 创立的 **Thinking Machines Lab** 预览了他们称为**交互模型（Interaction Model）**的新范畴[^ch9-14]，并把全双工背后的主张挑明：交互性不该以 VAD 之类的外挂 harness 环绕在模型之外，而应内建于模型自身——用其原话说，“要让交互性随智能一同扩展，交互性就必须成为模型本身的一部分”。落到架构上便是**微轮次（micro-turn）**：模型不等一整轮说完，而是以约 200ms 为一段，持续地“读入 200ms、生成 200ms”，让音频、视频、文本几路流交织推进。这一粒度是刻意的折中——足够细，使静音、重叠、打断都作为连续流保留在模型的上下文里，不再有人为的轮次边界需要迁就；又足够粗，能把多路模态成块地并发处理，把延迟压在实时可感的范围内。正因交互被纳入模型内部，“边听边说”“边看边插话”这些过去要靠专门 harness 才能拼出的行为，如今都成了模型的分内之事，并会随模型一同变强：首个模型 TML-Interaction-Small 把三路流从零一同训练，一旦察觉用户正写下一段含 bug 的代码、或有人步入画面，都能主动开口。 它对“慢思考”的接法也颇具代表性。交互模型自身只负责让对话保持在线，一旦遇到需要深度推理或工具调用的问题，便委派给后台一个更强的推理模型——交出去的不是一句孤立的查询，而是**整段对话的上下文**。后台模型一边推理，结果一边流式回传，交互模型再挑一个不打断用户的时机将其自然织入对话，其间它照常接话、答追问、守住话头。如此便以“非思考模型的延迟”，兑现了“推理模型的规划、工具与智能体能力”。据官方报告，TML-Interaction-Small（276B 参数 MoE、激活 12B）的轮次切换延迟低至约 0.40 秒（GPT-realtime-2.0 约 1.18 秒），在考察视觉主动性的基准上大幅领先于近乎零分的竞品；截至写作时仍处于研究预览阶段。 [^ch9-14]: Thinking Machines Lab, “Interaction Models: A Scalable Approach to Human-AI Collaboration,” 2026-05. https://thinkingmachines.ai/blog/interaction-models/ 同年，OpenAI 的 **GPT-Live** 则把全双工带到了生产规模，作为 ChatGPT 语音的新默认模型向全球铺开。它不再把对话看作一串分立的消息轮次，而是**持续处理输入的同时持续生成输出**，因此每秒能做许多次交互决策：该开口说、继续听、停顿、打断，还是去调用一个工具。表现出来就是：用户思考时它会安静等待而不是抢话，会用“嗯”“对”这样的附和表示自己在听，也能胜任实时翻译这类必须边听边说的任务。 GPT-Live 也走了同一条快慢分工的路——**把“实时交互”与“深度思考”解耦**：碰到需要搜索、推理或更复杂的智能体操作时，负责交互的 GPT-Live 把任务委派给后台的前沿模型（发布时是 GPT-5.5），自己继续维持对话的流动，等后台出结果再把它带回对话里。GPT-Live-1 与 mini 版本在后台用 GPT-5.5 Instant，Medium、High 档位则调用带思考的 GPT-5.5，让用户按需在“快”与“深”之间取舍。这条“快慢分工”正是下一节“思考架构的取舍”要展开的主题。 回顾本章的“替代 VAD”叙事链：VAD 靠静音阈值猜测发言权的切换，流式感知（见前文范式一“流式语音感知”一节）把切换判断升级到语义层，而全双工模型彻底消解了“切换”本身——它一直在听，“打断”不再是一个需要专门处理的事件，barge-in 处理链也因此在架构上被省去了大部分环节。这是“替代 VAD”这条叙事线截至写作时的终点。 ## 思考架构的取舍：从分离到统一 真正要解决的是**实时响应与深度思考之间的矛盾**：用户期待毫秒级的回应，而复杂问题需要秒级的思考时间，如何在保持低延迟的同时让模型想得足够深？这个矛盾并不专属于端到端架构，级联流水线同样绕不开。 下面的三种方案并非线性的技术迭代——它们是针对不同约束条件的设计取舍，在实践中并存，选择哪种取决于应用场景对延迟和思考深度的要求。需要先点明三者的分野：方案一、方案二本质上是“两个独立模型并发”的快慢分工，并不依赖端到端，甚至可以套在级联流水线之上；只有方案三才把思考真正内化进端到端模型。 值得注意的是，到 2026 年，“快慢解耦”这条路已经成了前沿语音产品的主流选择，并有了专门的名字。Thinking Machines Lab 把它称作“交互模型（Interaction Models）”——一个实时交互模型耦合一个异步的后台推理模型；xAI 的 Grok Voice “Think Fast”、Pine AI 的语音 Agent、以及上一节 GPT-Live 的“委派”，走的都是同一条“快在前台维持对话、慢在后台深度推理”的路线。选择解耦而非“训练一个全能模型”，背后有一个务实的理由：前沿推理模型每隔几个月就迭代一次，而实时交互能力需要专门的数据和训练目标，把两者塞进同一个模型，等于让它去追一个不断移动的靶子，还可能稀释掉最宝贵的推理能力[^ch9-8]。反过来，只要把最强的推理模型原封不动放在后台、只训练一个轻量的交互模型在前台，就能始终用上当下最强的“大脑”——这正是 GPT-Live 强调“可持续换用最新前沿模型”的原因。下面按“协调机制由弱到强”的顺序看三种方案。 ### 方案一：快思考应付，慢思考回答 快慢思考并行执行（图9-5）：快思考在 500ms 内给出简短的应付性回答（类似于人先说一句“让我想想”），慢思考在后台花 5-10 秒进行深度思考后给出完整回答。慢思考使用的技术叫“推理时计算扩展”（test-time scaling）——通俗地说，就是让模型在回答问题时“多想一会儿”：不是一步给出答案，而是像人类解数学题一样，先列出思路、逐步推导、检查结果，用更多的计算步骤换取更高质量的回答。 ![图9-5 快/慢思考架构与方案对比](images/fig9-5.svg) **问题一：简单问题过度思考**。用户问“今天星期几”，快思考已在 500ms 内正确回答“星期三”，慢思考仍然跑完整整 10 秒思考后又重复一遍“星期三”。这不仅浪费计算资源，更严重的是破坏对话节奏——用户已经得到答案准备聊下一个话题了，却被一个重复回答打断。**问题二：快慢不一致**。两者独立并行，虽然看到的上下文相同，但思考路径可能完全不同——快思考基于某个假设给出初步答案，慢思考却发现这个假设不成立，得出了相反的结论。用户在几秒之内先后听到自相矛盾的回答，信任感瞬间崩塌。根本原因在于：方案一把对话拆成两个独立的思考过程，而非一个连贯的认知活动，快慢之间缺乏协调机制。 ``` 这个套餐适合我吗? 这个套餐价格很优惠，我建议您购买。 好的，那我... 等一下，我发现这个套餐缺少您需要的国际漫游功能，可能不太适合。 （愤怒） 你到底是建议我买还是不买?! ``` ### 方案二：快思考交互，慢思考提醒 方案二让慢思考能看到快思考的输出，通过 Agent 状态栏（第二章介绍的动态元信息注入机制）向快思考提供建议，而不是直接对用户说话。相比方案一改进了两点：慢思考在后台异步运行，利用说话间隙持续思考；由于能看到快思考的输出，不会直接冲突，而是退到幕后当“军师”。前面提到的 GPT-Live 委派、Pine AI 语音 Agent 都是方案二在生产中的实例——后台的推理模型把结论通过一条精简的文本通道回传给前台的交互模型，由前台决定何时、以何种措辞说给用户听。 但这个方案仍有本质局限。**快思考可能不听指挥**——两个独立的思考实例之间的沟通是间接且模糊的。快思考收到 Agent 状态栏 后可能理解偏了，比如把“价格需要重新确认”理解成“问用户能否接受这个价格”而非“价格算错了要重新计算”。**无法获知中间思考结果**——慢思考 10 秒思考中已经产生了大量有价值的中间结论，快思考完全看不到，只能干等最终 Agent 状态栏。如果用户在慢思考完成前再次提问或打断，快思考只能靠自己有限的理解回答。这就像两个人合作解题却只能通过递纸条交流，看不到对方的草稿纸。 方案二还面临一个根本性的理论问题：**无法实现“边想边说”**。人类面对复杂问题时，不是先在脑子里想好完整答案再一口气说出来，而是想一段说一段——“这个问题很有意思……（停顿思考）首先我们需要考虑……（继续思考）其次……”。方案二中的快思考只能说些填充词干等慢思考出结果，无法将思考过程自然地穿插在对话中。 ### 方案三：端到端思考与表达统一（以 Step-Audio R1 为例） 方案二虽然解决了慢思考的等待问题，但在架构上依然是“先想再说”——思考和表达仍是两个分离的过程，不可能实现像人一样边想边说。要突破这个根本限制，需要将思考能力直接内化到模型中。 Step-Audio R1 正是沿着这个方向提出了一个根本不同的方案：将思考能力直接内化到端到端音频语言模型中，通过双脑架构实现真正的“边想边说”。它其实由两个互补的机制组成，分别解决两个不同的问题：**模态锚定思考蒸馏（MGRD）**先解决“想得对不对”——让模型真正基于声学特征而非文本转录来思考；**MPS 双脑架构**再解决“说得及不及时”——让思考与表达并行，实现低延迟的边想边说。前者是后者的前提：只有思考本身扎根于声音，边想边说才真正有价值。下面依次展开。 **文本代理思考问题**。理想情况下，语音模型应该直接分析声音特征（如音高、节奏、语调）来理解说话人的情绪或意图。但实际上很多模型走了捷径：现有音频语言模型存在一种反直觉现象，思考链越长，性能反而越差。Step-Audio R1 团队发现根因是“文本代理思考”（Textual Surrogate Reasoning，即用文本信息“代替”声学信息来分析）：模型在“思考”时，实际上是基于文本转录在做语义层面的思考，而不是真正在分析声学特征。举个例子：让模型判断一首歌的情绪，它分析的是“歌词里提到了悲伤”，而不是“小调旋律加上下行音高轮廓传递出忧伤感”。这种模态错位源于训练数据：大多数音频模型的 CoT（Chain-of-Thought，思维链）数据由文本模型生成，自然继承了纯文本的思考模式。 **模态锚定思考蒸馏**（MGRD, Modality-Grounded Reasoning Distillation）通过迭代自我改进来解决这一问题（图9-6）。名字虽然拗口，核心思路其实很直观：筛选出“真正在听声音”的思考过程，用它们来训练模型，让模型学会像音乐老师一样用耳朵分析，而不是像文字编辑一样只看歌词。具体分三步： 1. 让当前模型对同一段音频生成多条不同的思考过程，然后筛选出真正基于声学特征的那些。怎么筛选？看思考内容里有没有提到具体的声音参数。例如，对于一段愤怒的语音输入，基于文本的思考是“用户说了‘太差了’这种负面词汇，所以判断是愤怒”——这只是在分析文字内容；而基于声学特征的思考是“语速比正常快了 40%、音量明显升高、声调变尖”——这才是在真正“听”声音。MGRD 筛选后者 2. 用这些高质量的思考数据重新训练模型，强化其“用耳朵思考”的能力 3. 通过强化学习进一步优化，防止模型偷懒跳过思考直接猜答案 经过多轮迭代，思考的根基从文本抽象逐步迁移到声学分析——模型开始关注“音高轮廓在 1.2 秒处急剧下降”而非笼统地说“说话者似乎不开心”。 **MPS 双脑架构**（Mind-Paced Speaking，直译为“跟随思维节奏说话”）解决的是思考与语音输出之间的延迟矛盾（图9-6）。它的灵感来自人脑的分工：人脑中负责思考的区域和负责组织语言的区域是分开的，可以并行工作——你在想下一句话的同时，嘴巴还在说上一句。MPS 用两个模型模拟这种分工：**构思脑**（Formulation Brain）负责持续思考，产出一段段的思考结果；**表达脑**（Articulation Brain）每收到一段新的思考结果，就结合之前的思考和已有回复，把它转化为语音回复。 两者并行运行——构思脑不必想完全部内容，表达脑就已经开始说话了。例如，在 t=0ms 时构思脑开始分析用户问题，在 t=200ms 时输出第一段思考结果（文本 token 序列）；表达脑在 t=200ms 收到这段结果后，结合已生成的回复上下文，在 t=350ms 开始输出对应的语音 token——两个模块以流水线方式并行运作，用户在 t=350ms 就能听到第一个音节。 ![图9-6 Step-Audio R1 MGRD 与 MPS 双脑架构](images/fig9-6.svg) > **实验 9-4 ★★★：使用 Step-Audio R1 实现端到端语音思考** > > 本实验使用 Step-Audio R1 模型，对比不同配置在语音思考与对话任务上的表现。Step-Audio R1 由音频编码器、音频适配器和 Qwen2.5 32B 解码器组成，需要多卡 GPU 部署。 > > 本实验在两个任务上评估：**Spoken-MQA**（语音数学题）考察模型在听到口述题目后能否进行多步数学推理；**URO-Bench**（中文口语对话基准）考察开放对话质量。 > > 测试配置分为两个维度。第一是**思考时机**：完整的 **TBS**（Think-Before-Speak，先想完再说，作为无延迟约束的对照基线）会先生成全部思考再开口；为了降低延迟，MPS 提供两种“边想边说”的变体——**Speak-First**（也称 spkfirst，零延迟，开口和思考同时启动）与 **Think-First**（也称 thkfirst，等思考脑产出第一段后才开口，延迟约 80 token）。第二是**架构**：MPS 双脑并行 vs. 传统单模型 TBS。 > > 结果如表9-1所示，用于对比不同思考时机和架构配置在数学准确率与对话评分上的表现。 > > 表9-1 Step-Audio R1 不同语音思考配置对比 > > | 配置 | Spoken-MQA | URO-Bench | > |------|-----------|-----------| > | 不思考直接回答（基线） | 70.6% | 77.4 | > | MPS Speak-First（零延迟） | 92.8% | 82.5 | > | MPS Think-First（~80 tok 延迟） | 93.9% | 84.8 | > | 完整 TBS（无延迟约束） | 93.0% | — | > > 一个有趣的发现是：Speak-First 对思考任务影响极小（92.8% 接近完整 TBS 的 93.0%）。原因在于 **CoT**（Chain-of-Thought，思维链）的开头通常只是在复述问题内容，还没进入真正的推理，因此即便让模型一开口就同时启动思考，最终准确率也几乎不受损失。另一个值得注意的细节是：Think-First（93.9%）甚至略高于无延迟约束的完整 TBS（93.0%）——一种可能的解释是分段产出思考、逐段转化为表达，起到了类似分步监督的正向作用；当然，两者差距也在评测误差范围之内，不宜过度解读。 > 方案三把思考“内化”进单一模型，最优雅地实现了“边想边说”，但代价正是本节开头说的“移动靶子”：这一个模型既要当最强的推理者、又要当实时的说话者，而两种能力都在快速演进，统一路线就得反复重训才跟得上。这也解释了写作时的产业分野——追求“可随时换用最新大脑”的前沿产品（GPT-Live、Grok Voice、Pine AI）大多押注方案二的解耦路线，方案三则更适合追求极致自然度、且愿意承担专门训练成本的场景。两者不是谁取代谁，而是“可换的大脑”与“更紧的边想边说”之间的取舍。 ### 快慢之间的接口：文本之外还能传什么 （提示：这是一段跨场景的接口讨论，暂时离开语音主线。）回头看方案二会发现一个被忽略的设计维度：慢思考给快思考“递话”，用的是**文本**通道（通过状态栏传一句建议）。文本好懂、好调试，却是慢思考脑子里那点东西的一根细吸管——真正丰富的中间状态，被压成了几句话。那么，这条快慢之间的接口，能不能不用文字？ 在实时游戏这种对节拍最苛刻的场景里，这条路是走得通的（可称之为潜空间桥，Latent Bridge）[^ch9-8]：让一个负责快速反应的小模型（每秒出十几个动作）和一个负责推理的慢模型（每秒出一次思考）都**冻结不动**，只训练它们之间一个几千万参数的小“桥”，把慢模型的隐层结论直接投影成几个“潜 token”，像多模态模型塞视觉 token 那样拼进快模型的输入里——绕开了“想法→文字→再理解”的往返。结果在多个 Atari 游戏上，这条潜空间通道比传统文本通道又高出一截（部分游戏 +26% 到 +82%），而每步只多花约 5 毫秒，仍然跟得上实时的节拍。 它也给出一条诚实的边界：**快慢协作到底有没有用，取决于任务的瓶颈在“想不想得到”还是“来不来得及反应”**——当慢思考本来就比快反应强时，这座桥才帮得上忙（这条相关性跨游戏高达 r≈0.9）；反过来，如果任务纯拼反应速度，再好的桥也无济于事。这个判断不止对游戏成立，它也预告了本章后面 Computer Use 会遇到的同一个问题：什么时候值得请一个“慢军师”，什么时候那只是徒增延迟。 [^ch9-8]: 只训练一座冻结双模型之间的潜空间桥、以及“何时值得请慢军师”的完整分析见 Li, Bojie and Noah Shi. *The Latent Bridge: A Continuous Slow-Fast Channel for Real-Time Game Agents.* arXiv:2606.24470, 2026. 无论端到端还是模块化，感知层和执行层各自的质量仍然至关重要。端到端模型解决了架构层面的延迟问题，但“听得准”和“说得像”这两个基本功并不会因为架构的变化而自动解决——“听得准”对应的流式语音感知已在范式一中讨论过，这里再看“说得像”的执行层：更像人的语音合成。 ## 更像人的语音合成 传统 TTS 的“完美”恰恰是问题所在：过于流畅、零停顿、没有填充词的语音让人一听就知道是机器。人类说话时的那些“不完美”并非缺陷——停顿、填充词（“嗯”、“呃”、“那个”）、偶尔的重复——其实是思考过程的自然外化，向听者传递“我正在想”“我不太确定”等重要信号。但 AI 的思考速度远快于语音播放，输出天然流畅完整，直接合成出来就会暴露机器身份。 **解决方案**：把“在哪里该停顿、该用什么语气”的决策权交给主 LLM。LLM 输出的不仅是文本，还包括控制标记：`[THINKING]` 表示插入 1-2 秒的思考停顿和填充音（“嗯……”）；`[SEARCHING]` 生成较短停顿和搜索性填充词（“那个……”“怎么说呢”）；`[EMO:happy]` 等调整语气韵律；`[SPEED:0.8x]` 控制语速。只有 LLM 才知道当前是在回答复杂问题需要停顿一下、还是用户已经不耐烦了应该加快语速、又或者是轻松闲聊该活泼些。 TTS 在这个方案中扮演多模态生成器的角色，输入文本 + 控制标记，输出音频。遇到普通文本就正常合成语音，遇到控制标记就生成对应的非语言音频：`[THINKING]` 生成“嗯……”拖长音，`[SIGH]` 生成叹气声，`[LAUGH:small]` 生成轻笑，`[BREATH]` 生成吸气声。 实现路径有两条：一是自研 TTS 原生支持控制标记（灵活性最高，但需要专业团队）；二是利用 voice cloning（声音克隆），为同一个虚拟人准备数十条不同情绪、语速、风格的参考语音，根据控制标记选择最匹配的参考语音去调用 TTS API（如 ElevenLabs、Fish Audio），几周内就能完成部署。 > **实验 9-5 ★★：基于 Fish Audio 的控制标记驱动 TTS** > > 使用 Fish Audio S1 的声音克隆能力（只需 3-10 秒参考语音就能零样本克隆出同一音色）。构建 24 条参考语音库，覆盖情绪（中性/高兴/沮丧/思考）x 语速（正常/快/慢）x 风格（正式/轻松），每条约 5 秒。 > > LLM 输出示例：`[EMO:happy][SPEED:fast]太好了！您的订单已确认。[THINKING]嗯，让我查一下发货时间...[EMO:neutral][SPEED:normal]预计明天下午送达。` > > 执行层解析标记并映射到对应的参考语音：`[EMO:happy][SPEED:fast]` 对应“高兴+快速+轻松”参考音，`[THINKING]` 对应“思考+慢速+正式”参考音（带停顿节奏和犹豫语气），`[EMO:neutral][SPEED:normal]` 对应“中性+正常+正式”参考音。Fish Audio 会保证不同参考语音之间音色一致，只是韵律和情感有所变化。 > > 对比三种配置：无控制标记（流畅但机械，一听就是 AI）、单一参考语音（自然但情感单调）、多参考语音库（确认信息时欢快快速，解释说明前有自然停顿，整体接近真人客服的表达方式）。 ## Computer Use：GUI 自动化 Agent 读到这里也许会注意到，本章给语音的篇幅明显多于后两个场景——这是有意为之。在实时多模态这条演进线上，语音是走得最完整、最值得当作参考系的一个：从“串行流水线延迟太高”这个问题出发，经过端到端、全双工、边想边说等一系列方案，一直走到今天相对成型的终局，问题→方案→终局的全程都已经跑通。因此我们把它讲透，接下来的 Computer Use 和机器人两个场景，都可以对照语音这条脉络来看——它们各自走到了这条演进线的哪一段、卡在了哪里。 这三个场景看似不同，却面临相同的核心挑战：实时感知、低延迟决策、持续交互。接下来看这些技术主题如何在视觉交互（Computer Use）和物理交互（机器人）中重现——首先把视角从听觉模态扩展到视觉模态：如果 Agent 不仅能理解语音，还能“看懂”屏幕并操作图形界面呢？ Computer Use（也称 GUI 自动化 Agent）让 AI 像人类一样通过观察屏幕、操作鼠标键盘来使用软件——比如打开浏览器搜索信息、在表格软件中填写数据、或在系统设置中调整配置。其核心是一个**感知-思考-行动**的循环（图9-7）： 1. Agent 对当前屏幕截图 2. 多模态模型接收截图和任务指令，输出一段思考和一个具体动作 3. 执行层在真实环境中执行该动作（移动鼠标、点击、输入文字等） 4. 等待界面响应后再次截图，进入下一轮循环 ![图9-7 Computer Use Agent 的感知-思考-行动循环](images/fig9-7.svg) 这个循环中有三个关键设计维度：**动作空间**（Agent 能执行哪些操作）、**视觉定位**（如何在截图中找到目标元素）、以及**模型架构**（如何从截图生成正确动作）。 ### 动作空间设计 Anthropic 定义三类工具构成完整的交互能力（图9-8）： ![图9-8 Computer Use 动作空间](images/fig9-8.svg) **GUI 操作工具**（computer tool）：鼠标操作包括移动（mouse_move）、左/右/中键点击、双击/三击、拖拽（left_click_drag），以及更精细的按下/松开（left_mouse_down/up）。滚动（scroll）支持四个方向并可配合修饰键。键盘操作包括逐字输入（type，每个字符间隔 12ms 模拟真实打字）、组合键（key，如 Ctrl+C）、长按（hold_key）。感知动作：截图（screenshot）、获取光标位置（cursor_position）、等待（wait）。 **命令执行工具**（bash tool）：提供持久的 bash 终端会话，120 秒超时，通过哨兵字符串检测命令是否执行完毕，多次调用之间保持环境状态（比如 cd 到某个目录后下次调用还在那个目录）。 **文件编辑工具**（str_replace_editor）：通过字符串匹配实现安全编辑，支持查看、创建、替换、插入和撤销操作，比直接覆盖整个文件更精确，不容易误改其他内容。 > **实验 9-6 ★：运行 Anthropic Computer Use Demo** > > 容器打包了一个完整的 Ubuntu 桌面环境（含浏览器、终端等常用工具）。前端接收任务指令，后端将指令与截图发送给 Claude，模型返回操作指令（移动鼠标、点击、输入文字等），执行层在虚拟桌面中执行。 > > 关键观察：每个动作间隔 2-5 秒（显著慢于人类），但对常见任务展现良好规划能力，能自主拆解为合理操作序列。 > ### 视觉定位（Grounding） 在循环的每一轮中，模型需要在截图中准确定位目标元素——“搜索框在哪里？”“提交按钮的坐标是什么？”这就是视觉定位（Grounding）问题。当前主要有**两大思路**：一是把定位变成**选择题**——先把界面元素标注好编号，模型只需从中选一个；二是**纯坐标预测**——让模型像人一样直接“看”着截图报出坐标。其中选择题思路又有两种实现方式：**纯视觉标注**（原始的 Set-of-Mark，用分割模型在像素上切出候选区域）和**结构化元素索引**（DOM/Accessibility Tree，直接读取界面自带的结构）。选择题思路的共同优势，是把开放式的“在截图中找到按钮并预测坐标”转化为封闭式的“从已标注好的元素中选一个”——就像考试中选择题比填空题更容易答对一样，模型只需说“点击 [123]”而不是“点击屏幕左上角偏右大约 200 像素处的蓝色按钮”。 **Set-of-Mark：视觉标注法。** 原始的 Set-of-Mark（SoM）由微软研究院于 2023 年提出，最初是为了释放 GPT-4V 的视觉定位能力。它是一个**纯视觉**方法：用图像分割模型（SAM、SEEM 等）在截图上自动切出候选区域，为每个区域叠加编号标记，模型看到的是一张带编号的图，只需报出编号，由系统换算成对应区域的中心坐标。整个过程不需要 DOM，也不需要任何界面内部结构，因此原生桌面软件、游戏界面同样适用——只要分割模型能把候选区域切出来。 **结构化元素索引：SoM 思想在 Web 上的结构化实现。** 当界面本身能提供结构化信息时，标注可以做得更精确。现代网页在渲染之前就已经定义了完整的元素结构（DOM 树）和语义角色（哪个是按钮、哪个是输入框），无障碍接口（Accessibility Tree）为许多桌面应用提供了类似的信息。与其让分割模型在像素里猜“哪个区域是按钮”，不如直接问界面本身“你有哪些可以点击的元素？”。以 browser-use 项目为代表的 Web Agent 方案正是这样做的：从 DOM 中枚举可交互元素并编号，可以看作 SoM 思想在 Web 上的结构化实现（图9-9）。流程分四步： 1. 通过浏览器调试接口（CDP，Chrome DevTools Protocol）获取网页的结构化表示（DOM 树）和无障碍信息 2. 自动检测哪些元素可以交互（按钮、输入框、链接等） 3. 为每个可交互元素标注唯一 ID 并在截图上绘制边界框 4. 同时生成文本列表描述每个 ID 对应的元素 ``` Screenshot: [图片中关键元素标注了 [1]、[2]、[3]、[4] 等 ID] Elements: [1] [2]