多模态与实时交互

如果把模型的能力做一个面向应用的粗略划分，大致可以从三个方面来观察：理解、生成和交互。

• 理解回答的是“模型能否看懂并想明白”，包括理解文字、语音、图像和视频，以及在这些信息之上进行推理、判断与规划。
• 生成回答的是“模型能否把想法表达出来”，它可以生成文本和代码，也可以生成图像、视频、语音乃至动作。
• 交互回答的则是另一个问题：模型能否在持续变化的环境中，在合适的时机接收信息、采取行动，并根据反馈调整下一步。

理解和生成主要决定模型 “会什么” 以及智能上限；交互能力与智能上限并不直接相关，它主要决定模型能否在真实环境中把已有的智能有效地转化为任务结果。一个模型可能在数学推理或代码生成上非常强，却可能无法把实际任务做好。这和人的聪明程度与岗位表现之间的关系是类似的。

Agent 的交互对象不仅仅是文本和 API。当 Agent 需要听懂用户的语音指令、在屏幕上找到并点击正确的按钮、或控制机械臂精确抓取物体时，它进入了一个全新的领域：多模态实时交互——从纯文本输入输出扩展到多模态感知与实时响应。

语音：最自然的人机接口

语音的价值不只是把文字换成声音。正常说话的速度约为打字的四倍，而且不占用双手与视线，因此它天然适合把 Agent 放进持续工作、随时可能被打断的输入输出回路。语音输入法把口述转成文字，语音 Agent 则让用户直接与 Agent 协作；两者都可以支持引言中提到的 whisper coding。

本节同时讨论两个方向：用户对 Agent 说话，以及 Agent 代替用户对外部世界说话。语音模型决定“能回答什么”，交互架构决定“能否听清、及时回应、自然换手，并在通话中完成确认和工具调用”。后文先讨论交互时序，再讨论深度思考和表达质量。

交互时序：从级联到全双工

OpenAI 在 GPT-Live 的介绍中用“级联、轮次式、全双工”概括了语音系统的三种交互范式¹。它们不是简单的新旧替代，而是不同延迟、成本和可观测性约束下的取舍：

贯穿三种范式的主线是：如何摆脱“轮流说话”和 VAD 对发言权的猜测。级联和 Omni 仍要划分轮次，只有全双工把“该谁说话”变成模型的持续决策。

范式一 · 级联流水线（Cascading）

绝大多数商业语音助手都基于串行流水线（图9-1）：VAD 判断用户何时说完，ASR 把音频转成文字，LLM 理解并生成回复，TTS 再把文字念出来。模块化让每个组件可以独立优化，但每一级都可能增加等待时间。

在一个简短、不开启 reasoning 的回复中，VAD、ASR、LLM 和 TTS 的等待会串行累积（图9-2）。真实数值取决于输入长度、模型、硬件、网络和负载。

生产环境的排队还会进一步放大空载延迟（图9-3），但这属于服务容量规划，本章不展开排队模型。

实验 9-1 ★：构建传统语音 Agent

本实验用 WebSocket 串起麦克风、Silero VAD、本地 Whisper、流式 LLM 和 Fish S1 TTS，建立后续方案的级联基线。保留的真实单轮证据证明媒体和模型链路确实跑通，但不把一次空载运行解释成并发或生产负载 benchmark。代码与验收记录见 chapter9/live-audio。

附加项目：使用 WebRTC 构建“呼叫用户”的语音 Agent

电话 Agent 不一定要接入 PSTN。浏览器 WebRTC 就能复现“主动建立会话、询问缺失信息、复述确认并保存结构化结果”的闭环；需要联系外部机构时，再把同一个工具契约替换为合规的 PSTN/SIP 供应商。完整媒体链路、直接/ReAct 对照和验收证据见 chapter9/phone-agent。该项目保留原有 exp9-2 运行标识，但不再占用正文实验编号。

从串行到流式感知

图9-2描述的是“每一环跑完再交棒”的完全串行情形。生产系统仍可保留模块化分工，同时让各阶段尽早产出增量结果：

• ASR 边听边转：用户说话时持续生成临时转录，轮次结束后再确认最终文本。
• LLM 分段输出：第一段适合播报的文本生成后立即交给 TTS，不等完整回复。
• TTS 增量合成：持续返回音频块，让后续生成、合成和播放重叠进行。

“每一级都流式”不等于 ASR、LLM、TTS 从头到尾完全并行。标准级联中，ASR 可以与用户说话重叠，TTS 可以与 LLM 后续生成重叠，但最终回复仍依赖稳定转录。更激进的系统会根据部分转录提前启动 LLM；后续文本改变时，就必须取消、重启或修正生成。真正的抢跑需要提交、失效和回滚机制，不是打开 stream 开关就会自动获得。

普通流式化仍无法消除 VAD 的静默等待。传统 VAD + ASR 前端有三个问题：

1. 延迟累积：必须等待一段静音才能确认说完。
2. 信息丢失：有声/无声二值信号无法表达犹豫、情绪、附和和环境声。
3. 上下文被切断：邮箱、人名和专有名词可能被分片识别而出错。

真正的流式模型需要因果或分块编码器，并能增量解码。Whisper 的解码虽然是自回归的，但编码器需要完整音频段，因此不能直接等同于流式模型。RNN-T 和流式 Conformer 等传统流式 ASR 早已在工业界使用，本节关注的是在 LLM 骨干上加入语义级听觉感知。

基于 LLM 的流式听觉模型可以从连续音频中输出文本和语义事件，把“识别”和部分“理解”放进同一个模型。它保留从对话开始到当前时刻的上下文，也可以利用世界知识处理品牌、人名和专有名词；但模拟分块的耗时不能当作真正因果流式模型的性能承诺。

如果只想解决“用户是否说完”，也可以把轮次判断直接做进流式识别器：模型综合语义和静音判断一句话是否表达完整。端点判断的训练标签必须只使用决策时刻可见的信息，否则会因“上帝视角”产生线上无法复现的判断²。这是一条比完整音频大模型更轻的路线。

模型输出的不仅是文字，还可以包含声学事件标记：

• speak_start/end、interrupt：说话起止与打断意图；
• emotion：情感、犹豫等状态；
• laugh、sigh、noise：副语言和环境声。

这些标记和文字 token 形成统一事件流，Agent 可以据此识别犹豫、打断和环境变化，而不必把所有声音压成纯文本。

实验 9-2 ★：使用 Qwen2-Audio 模拟流式语音感知

Qwen2-Audio 本身不是流式模型。本实验用递增音频前缀模拟连续感知，并与 600ms VAD + Whisper 对照。它演示完整上下文对停顿和噪声场景的影响，但每次都会重新编码此前音频，因此不能把结果当作真流式模型的延迟承诺。

当前 canonical run 通过全部执行与溯源门禁，但只复现了 2/6 项预期行为：递增前缀实测为 8.4–11.3 秒，pause 样本漏报 silence，noise 样本仍误报 cough/laughter。这个负结果说明实验适合检查机制和失败方式，不能支持“一二百毫秒真流式感知”的结论。完整记录见 chapter9/streaming-speech。

范式二 · 端到端全模态模型（Omni）

级联即使采用流式感知，听、想、说仍通过离散接口交接；情绪、语调和环境声等信息可能在转成纯文本时丢失。Omni 用同一个模型直接听音频、生成回复并输出语音，因而有机会保留这些信息，但训练、调试和替换组件的成本更高（图9-4）。

端到端的优势主要体现在延迟和非文字信息上，并不必然转化为更高准确率。自级联先用同一模型转录，再基于转录回答：当文字足以承载任务信息时，它可能纠正一次感知错误；当答案依赖语速、情绪或环境声时，纯文本瓶颈会不可逆地丢失证据。关键不在于是否有中间表示，而在于中间表示承载了什么信息³。

Omni 仍然假设轮流说话，通常要靠 VAD 或语义端点划分发言权。用户报数字时的中途停顿仍可能被误判为说完；流式感知只能改善判断，不能取消轮次本身。

实时语音 API 通常处在级联与 Omni 之间：模型原生处理音频，但交互控制仍依赖 VAD，并通过打断和异步工具调用改善体验。Qwen3-Omni 的 Thinker-Talker 和 MiniCPM-o 的本地路径则说明，同一技术路线可以把思考、表达和多模态输入压到不同规模的模型中。这里更值得验证的不是模型榜单，而是端到端与自级联在不同任务上的失败方式。

实验 9-3 ★★：本地运行 MiniCPM-o 4.5，对比端到端与自级联

本实验固定一个本地 MiniCPM-o 4.5 revision，关闭 thinking mode，比较直接从音频作答与同模型自级联先转录再作答。它测的是音频信息是否被保留，不是后文的“边想边说”。

表9-1 MiniCPM-o 4.5 本地端到端与自级联结果（4 条机制检查，不是 benchmark）

任务类型	端到端	自级联	观察
语义算术（2 条）	1/2	2/2	自级联纠正了一个听写错误
副语言语速（2 条）	2/2	1/2	纯文本转录抹掉了快慢差异
合计	3/4	3/4	总分相同，失败位置互补

样本很小，不能据此声称哪条路径整体更准确或更快。完整硬件、版本、原始输出和真实 audio-to-audio 证据见 chapter9/end-to-end-speech。

Step-Audio 2 展示了直接处理原始音频、同时输出文本和语音的端到端路线；它关注语义之外的情绪、语速、语调和环境声。Step-Audio R1 在此基础上进一步把思考能力内化到音频模型中，后文把它作为“边想边说”的案例。

范式三 · 全双工交互模型

Omni 仍然把对话分成“用户说”和“模型说”两个时段，但同声传译等任务要求两者重叠进行。全双工模型因此不再预设轮次，而是持续听、持续说，并不断决定继续、停顿、打断或调用工具。

研究上的先声是 Kyutai 的 Moshi（2024）。它并行建模用户和模型的音频流，因此重叠说话和打断可以成为模型的自然行为。

Thinking Machines Lab 将这类路线称为交互模型（Interaction Model）⁴：交互性不再由 VAD 等外部 harness 拼接，而是内建在模型中。其微轮次机制以短音频块持续推进，让静音、重叠和打断都作为连续上下文保留。交互模型还可以把完整对话委派给后台推理模型，自己继续维持话头；后台结果返回后，前台再在合适时机接入。

OpenAI 的 GPT-Live 则把全双工路线带到生产规模：模型持续处理输入并生成输出，能等待用户、附和、被打断，也能处理实时翻译。它与交互模型一样，把复杂任务委派给后台模型，前台继续维持对话。

回顾这条叙事链：级联靠静音阈值猜测轮次，流式感知把判断升级到语义层，全双工则把“切换”本身变成持续决策。

认知时序：实时交互与深度思考

“交互表现”和“智能上限”是两个维度：前台模型要在用户仍然在线时回应，后台模型则可以花更多时间思考。下面三种方案是设计取舍，不是线性迭代；前两种可以套在级联或 Omni 上，只有第三种把思考与表达统一到端到端模型中。

方案一：快思考应付，慢思考回答

快思考可以在几百毫秒内先给出应付性回应，慢思考则在后台完成更深的推导。它的问题是简单问题会被重复处理，复杂问题又可能出现前后不一致：快模型先建议购买，慢模型随后发现套餐缺少关键功能，用户在几秒内便听到相互冲突的答案。根本原因是两个实例各自完成了一次独立思考。

方案二：快思考交互，慢思考提醒

方案二让后台模型通过状态栏或专门接口向前台模型提供建议，前台继续维持话头并决定如何表达。它比方案一稳定，但通信仍然间接：前台可能误解建议，也看不到后台的中间思考；在后台完成前，用户追问时前台仍只能依靠自己的能力应答。它可以自然地“等结果”，但不能真正做到边想边说。

方案三：端到端思考与表达统一（以 Step-Audio R1 为例）

方案三把思考能力直接内化到端到端音频模型中。Step-Audio R1 用两个互补机制解决两个问题：模态锚定思考蒸馏（MGRD）让模型基于声学特征思考，MPS 双脑架构让构思与表达并行。前者保证“想得对”，后者解决“说得及时”。

理想情况下，模型应该从音高、节奏和语调判断情绪，而不是只看转录文本。所谓“文本代理思考”，就是模型用歌词中的负面词汇代替对旋律和声学特征的分析。MGRD 筛选真正引用声学特征的思考过程，再用这些数据训练模型，并通过强化学习防止模型跳过思考直接猜答案。

MPS 让构思脑持续产出思考片段，表达脑收到片段后结合已有回复立即生成语音。两者以流水线方式并行，因此不必等完整思考结束才让用户听到第一句话（图9-6）。

统一模型最紧密地实现了“边想边说”，代价是思考和实时表达需要一起重训；解耦路线更容易替换后台大脑，统一路线则更适合追求极致自然度的专门场景。两者是取舍，不是简单的替代关系。

更像人的语音合成

传统 TTS 过于流畅、零停顿，反而容易暴露机器身份。停顿、填充词和偶尔的重复，是人类表达不确定性和思考状态的信号。

可以让主 LLM 在文本之外输出控制标记，例如 THINKING、EMO:happy 和 SPEED:0.8x，由 TTS 将它们映射为停顿、韵律、语速或笑声、叹气等非语言音频。实现上可以自研支持控制标记的 TTS，也可以用 voice cloning 准备不同情绪和风格的参考音频。

实验 9-4 ★★：基于 Fish Audio 的控制标记驱动 TTS

使用 Fish Audio S1 构建多参考语音库，比较无控制标记、单一参考音和多参考音三种配置。执行层根据标记选择匹配的情绪、语速和风格。

多参考语音配置在三次位置平衡的音频盲评中获得最高分，真人客服感为 4.67/5；但预设的全部排序没有完全复现，因为无控制标记组高于单一参考音组。这个结果说明表达控制有帮助，却不能把一次小规模听感实验当作普遍的音质结论。完整的 24 条参考音频、A/B/C 媒体和验收记录见 chapter9/controllable-tts。

Computer Use：GUI 自动化 Agent

读到这里也许会注意到，本章给语音的篇幅明显多于后两个场景——这是有意为之。在实时多模态这条演进线上，语音是走得最完整、最值得当作参考系的一个：从“串行流水线延迟太高”这个问题出发，经过端到端、全双工、边想边说等一系列方案，一直走到今天相对成型的终局，问题→方案→终局的全程都已经跑通。因此我们把它讲透，接下来的 Computer Use 和机器人两个场景，都可以对照语音这条脉络来看——它们各自走到了这条演进线的哪一段、卡在了哪里。

这三个场景看似不同，却面临相同的核心挑战：实时感知、低延迟决策、持续交互。语音场景强调“何时开口”，Computer Use 强调“下一步点哪里”，机器人强调“动作造成了什么后果”。三者都说明，模型在离线任务中答对问题，只是交互闭环的起点；只有能够持续观察、及时行动并检查结果，才算在真实环境中把事情做好。接下来看这些技术主题如何在视觉交互（Computer Use）和物理交互（机器人）中重现——首先把视角从听觉模态扩展到视觉模态：如果 Agent 不仅能理解语音，还能“看懂”屏幕并操作图形界面呢？

Computer Use（也称 GUI 自动化 Agent）让 AI 像人类一样通过观察屏幕、操作鼠标键盘来使用软件——比如打开浏览器搜索信息、在表格软件中填写数据、或在系统设置中调整配置。其核心是一个感知-思考-行动的循环（图9-7）：

1. Agent 对当前屏幕截图
2. 多模态模型接收截图和任务指令，输出一段思考和一个具体动作
3. 执行层在真实环境中执行该动作（移动鼠标、点击、输入文字等）
4. 等待界面响应后再次截图，进入下一轮循环

这里要区分“看懂界面”和“完成任务”。前者更接近多模态理解能力，可以用一次截图问答来测量；后者则要求模型把理解和生成动作放进闭环，处理页面加载、状态变化、误操作和不可逆后果。Computer Use 的难点因此不只是让模型在截图上答对，而是让它在每一步之后重新确认现实是否仍符合计划。

这个循环中有三个关键设计维度：动作空间（Agent 能执行哪些操作）、视觉定位（如何在截图中找到目标元素）、以及模型架构（如何从截图生成正确动作）。

动作空间设计

Anthropic 的参考实现把完整交互能力分成三类工具（图9-8）。这是一个清晰的动作空间设计，但不是模型供应商必须遵守的私有协议：只要 Harness 能把同样的截图、动作约束和执行结果转换成目标模型支持的消息与结构化输出，Claude、开放权重视觉模型和自托管端点都可以驱动同一个感知-思考-行动循环。

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-5 ★：运行 Computer Use（Anthropic 参考路径或开放模型路径）

路径 A 使用 Anthropic Computer Use Demo：容器打包完整的 Ubuntu 桌面环境（含浏览器、终端等常用工具），前端接收任务，后端把指令与截图发送给 Claude，再执行模型返回的鼠标、键盘、终端或编辑动作。这条路径用于理解原生 computer 工具协议，不要求所有读者拥有 Anthropic API。

路径 B 使用本书的 chapter9/computer-use-open-model companion：默认以开放权重的 Qwen3-VL 32B Instruct 驱动 browser-use，可通过 OpenRouter 托管 API，也可把 OPEN_MODEL_BASE_URL 指向自托管 vLLM/SGLang 或其他兼容端点。端点必须接收截图，并支持原生 JSON Schema；若只支持普通 JSON，可显式启用 schema-in-prompt 兼容模式。

两条路径使用同一只读任务和同一验收契约：最多 25 步，每步只执行一个动作，保留模型/端点身份、原始提供商响应、逐步截图、动作序列、最终答案和停止原因。模型不同就必须作为不同实验臂分别报告，不能把开放模型的结果冒充 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] <input type="text" placeholder="Search" aria-label="Search" />
[2] <button id="submit-btn" aria-label="Submit form" />
[3] <input type="text" placeholder="Enter your name" value="" />
[4] <a href="/docs" aria-label="Documentation" />

模型只需要输出一个 ID 号就行，系统自动用该元素的中心坐标执行点击。这类方案不省 token（因为要把所有标注信息都发给模型），但定位准确稳定，还免去了分割模型可能引入的漏检和误检。

纯坐标预测。

第三条路线不做任何标注，直接让模型输出坐标。以 SeeClick 和 Claude 的 computer use 为代表：在海量 GUI 截图和元素位置的配对数据上训练视觉模型，让它学会将自然语言描述（如“点击提交按钮”）直接映射到截图中的精确坐标——就像人类用户一样，纯粹靠“看”来找到要点击的位置。

在坐标预测方案中，模型对坐标的理解高度依赖训练时使用的分辨率（图9-10）。Claude 训练使用 XGA（1024x768）、WXGA（1280x800）、FWXGA（1366x768），如果输入的截图分辨率不匹配，模型预测的坐标就会系统性地偏移——就像在小地图上量距离然后直接用到大地图上一样。因此，需要在工具层实现双向坐标缩放机制，而且要按宽高比选目标分辨率，避免非等比拉伸把画面压变形、连带把坐标判断也带偏。例如，真实屏幕分辨率为 2560×1440（16:9），就该在 Claude 支持的三档里挑一个宽高比同样接近 16:9 的目标——FWXGA（1366×768）最匹配。截图时把屏幕等比缩放到 1366×768 送入模型；模型输出点击坐标 (683, 384) 后，反向映射为真实坐标 (683×2560/1366, 384×1440/768) ≈ (1280, 720)。反过来，若硬把 16:9 拉伸进 4:3 的 1024×768，画面会被横向压扁，模型预测的坐标就会系统性偏移。

三条路线的选择逻辑可以概括为：结构化信息可得时，优先用 DOM/Accessibility Tree 索引，定位最精确稳定；不可得时（原生桌面软件如 Photoshop、Canvas/WebGL 渲染的界面、游戏），既可以用视觉标注（原始 SoM 路线），也可以用坐标预测。视觉标注把定位变成选择题，对未经专门训练的通用模型更友好；坐标预测省去标注步骤，对做过 GUI 定位训练的模型更直接。两者在小元素和密集界面上的精度都仍有差距。

实验 9-6 ★：使用 browser-use 实现自动浏览器操作

基于 Playwright 浏览器自动化框架（一个用代码控制浏览器的工具库），结合多模态大模型实现自然语言驱动的浏览器操作。启用 SoM 可视化模式，每次决策前保存带标注框的截图。模型接口不限定为 OpenAI 或 Anthropic；本书提供 Qwen3-VL 开放模型 API 配置，并保留通用 OpenAI-compatible base URL 供其他托管服务或自托管推理使用。

测试任务“打开 Google 查询旧金山天气”：系统启动后截图显示 Google 搜索页面，交互元素被编号，模型选择搜索框、输入“San Francisco weather today”、提交搜索，再从结果页提取温度和天气状况。验收时独立核对答案与轨迹，并如实记录实际步数和耗时；“5 步、约 20 秒”只能是某次运行的观测值，不能在没有回执时当成固定结果。

本书保存的开放模型正式运行使用 OpenRouter 上的 qwen/qwen3-vl-32b-instruct。模型在 Google 搜索第 4 步遇到 CAPTCHA 后没有宣称成功，而是转到 weather.com，最终在第 16 步从 San Francisco 的 Today 页面读取 64°F、Sunny、体感 62°F、高 74°F、低 55°F。16/16 个 API 响应均报告请求的 Qwen3-VL 模型，15 张有效步骤截图与只读动作轨迹通过独立确定性验收。这个结果证明开放模型 API 路径可运行；它不等于 Anthropic 原生 computer 工具臂已经复现。

能看动画、能听声音的 Computer Use Agent

到目前为止，Computer Use 的感知都建立在一个隐含假设上：屏幕是静止的——截一张图、想一步、点一下，再截下一张图。可现实里的屏幕会放视频、会弹出转瞬即逝的通知、会播放会议里的人声。一个每 3–5 秒才睁一次眼、而且完全没有耳朵的 Agent，对这些“两帧之间发生的事”既看不见也听不到。看录屏、跟会议、听语音提示、应付一闪而过的对话框——这一整类日常电脑操作，对今天的 Computer Use Agent 几乎是禁区。

这里真正该被重新设计的，不是“动作接口”，而是“观察接口”⁵。核心思想是把观察（连续、自适应、多模态）从动作（离散）里解耦出来，做成一层插在环境和任意现成 Computer Use 模型之间、无需重训的感知中间件（可称之为 Agent–电脑观察接口，AOI）。它有三个“按需开闸”的部件：其一，帧间关键帧捕获——先用一个极廉价的像素门跳过几乎没变的画面，再用一个小模型判断画面是否发生了有意义的变化，只在变化时才截一帧，静止画面下几乎零成本；其二，音量门控的语音转写——有声音时才调用语音识别，让 Agent 第一次“长出耳朵”；其三，也是最关键的，把画面叙述成持久的文字——让模型把捕获到的帧描述成一句话（“刚弹出的提示说发布日期改到了 4 月 28 号”），并且即使原图之后被清理出上下文，这句文字仍留在记忆里，把动态信息以文本形式带着往下走。

一个反直觉的发现是：真正起作用的不是“选哪几帧”，而是“把帧叙述成能长期留存的文字”——文字才是 LLM Agent 最擅长处理的模态。在从 7B 到前沿规模的八个模型上，这层中间件无需任何重训就带来 +17 到 +48 个百分点的提升，其中语音类任务的差距最悬殊：加了这层感知，Agent 能把原本“听得见却动不了”的语音任务都做出来。但它也不是一套包打天下的固定配置——在某些更新的模型上，塞太多图像 token 反而会挤占推理、拖累表现，所以这些部件要按模型逐个挑选，而非一股脑全开。这与前面 Set-of-Mark 和坐标预测的取舍是同一个道理：感知方案没有银弹，要顺着模型的脾气来配。

Computer Use 的世界模型

上一节的观察接口解决的是 “屏幕中间发生了什么”：通过关键帧、语音转写和持久文字，让 Agent 不再只看到两张相隔很久的截图。但观察接口并不会消除规划延迟，Agent 仍然是串行的“截图—思考—点击”循环，每执行一个动作都重新观察、思考下一步。OSWorld-Human 的效率研究显示，即使任务最终成功，Agent 的操作步骤和等待时间仍明显多于人类；准确率达到人类水平，并不等于已经足够实用。

人类操作电脑时并不是点击之后才开始想下一步，而是会先对动作后果作出预测：如果实际变化与预期一致，就沿着原定计划继续执行；只有发现页面状态偏离预期，才停下来重新观察和规划。世界模型让 Agent 能够在行动前预测桌面接下来可能变成什么，从而实现这种类似人的 “推测执行” 机制，大大提高效率。

桌面状态不只是一张像素图，还包括窗口、焦点、滚动位置、输入框内容、加载状态、权限和网络返回；动作则包括点击、键盘输入、滚动、拖拽和等待。一个可用于 Computer Use 的世界模型至少要能编码当前状态、预测候选动作造成的状态变化，并把预测交给规划器决定下一步：

桌面状态 + click/type/scroll/wait ──> 下一状态的表示

这样，Agent 就能在真正点击之前比较候选动作的后果，在页面加载期间准备下一步，并在弹窗一闪而过时根据状态差异恢复。例如任务是 “在 VS Code 新建 Python 文件并写入 hello world”，模型可以先预测文件树和编辑器在成功后的关键状态，再选择点击、输入和保存动作；如果任务是删除文件，则可以先在隔离的虚拟桌面中预测是否会出现不可逆确认框，必要时请求用户确认。这里的重点不是让模型生成一张逼真的未来截图，而是预测完成任务所需的、可检查的状态差异。

2026 年 7 月，Induction Labs 公布的 Photon-1 展示了这条路线的一种实现，仅用 3 万小时的 H200 GPU 时间就完成了 computer use 世界模型的预训练。它把每帧压缩为离散的潜在 token，自回归预测动作之后的下一状态表示，而不是在预训练阶段逐像素生成截图；另外接入的图像生成器只用于把潜表示可视化，并非推理必需组件。给定一张种子截图和后续动作，模型可以连续“想象”桌面状态，再通过虚拟机上的在线训练学会输出 computer-use 动作。⁶

移动端：生态壁垒比技术更难

Computer Use 也在向移动端扩展。移动端与桌面在技术上确有差异：动作空间通常不再是“鼠标坐标 + 键盘”，而是接入系统的无障碍服务 API（如 Android 的 AccessibilityService）来读取界面元素、下发点击与文本输入；交互方式也从鼠标指针变成触摸手势，坐标的语义随之改变——同一个 (x, y) 到底是手指的单击、长按，还是滑动手势的起点，需要额外的手势类型来界定。第六章介绍的 AndroidWorld 等移动端基准，正是在这样的动作空间上评测 Agent 完成真实 App 任务的能力。

但真正卡住移动端的，往往不是这些技术差异，而是生态壁垒。曾有手机厂商尝试在消费级手机中集成 AI 助手，让它自动操作微信、淘宝、支付宝等日常应用，但很快遭遇平台限制。

这揭示了 Computer Use 面临的一个独特挑战：生态壁垒。封杀背后的根本原因是商业模式冲突。传统互联网应用的核心变现逻辑是流量与注意力：用户刷信息流时看到广告，搜索商品时跟随推荐算法的引导，浏览页面时产生冲动消费。而当 Agent 代替用户操作时，这条变现链路被彻底绕过：AI 不会关注广告，也不会冲动消费，直奔目标完成任务就走。对于靠广告和流量变现的平台来说，Agent 的每一次操作都在侵蚀其商业模式的根基。

这意味着 Computer Use 面对的不仅是 CAPTCHA（验证码）等技术层面的对抗，更是一个结构性的利益冲突。这一矛盾在短期内难以调和，也让 Computer Use 在消费级场景中的落地面临比纯技术问题更棘手的挑战。

机器人操作：以 XLeRobot 整理桌面为例

阅读提示：本节始终使用同一个任务——“把红色杯子放进托盘，把黄色废纸放进垃圾盒，最后重新观察并确认桌面状态”。实验 9-7 和 9-9 是 XLeRobot 真机实验，需要机械臂、标定、急停装置和现场观察员；实验 9-8、9-10 和 9-11 是对应的本地 GPU 实验。真机与模拟会明确分开报告，但任务目标、动作语义和成功条件保持一致。

机器人操作比“看图回答问题”难得多。模型不但要看懂画面，还要在真实世界里连续做出动作，而且每个动作都会改变下一刻的情况。XLeRobot 把这种区别变得很具体：同一台机械臂既可以由人通过键盘、手柄或 VR 设备遥操作，也可以把摄像头观察和一组受约束的动作工具交给 Agent 自主调用。硬件和任务都不变，改变的只是操作者——前者由人持续观察和纠错，后者必须由模型与控制系统完成同样的工作。

本节将用“整理桌面”贯穿五个实验。先让人遥操作真实 XLeRobot，测量真机在足够强的操作者控制下能做到什么；再在模拟器中建立同任务的理想控制上限。接着让 Agent 自主控制真实 XLeRobot，观察感知、规划和失败恢复如何影响结果；再把相同的工具契约放进模拟器，批量比较开环、逐步检查和世界模型三种策略。最后改变背景、物体外观、光照和视觉噪声，检查模拟中学到的视觉策略能否适应新的环境。

这里的瓶颈通常不是再给模型增加一个静态问答基准，而是让它在有限的感知和控制带宽下持续完成闭环。一个能用的机器人系统，至少要回答四个问题：

1. 人想完成什么任务？
2. 接下来先做哪个子任务？
3. 当前技能具体输出哪些动作？
4. 动作执行后，现实是否仍符合原来的计划？

本节把这四个问题放在 XLeRobot 的同一个控制闭环中，并分别说明四种技术各自负责什么：长程规划安排先处理杯子还是废纸，VLA 或动作原语完成抓取和放置，世界模型估计动作后果，从仿真环境迁移到现实环境则处理训练画面和真实摄像头、执行器之间的差异。即使高层模型已经具备足够的知识和规划能力，缺少其中任何一个反馈环节，系统仍可能无法把任务做完。

硬件与算法的分工

XLeRobot 最适合回答的第一个问题是：自主整理桌面失败时，究竟是机械臂本身做不到，还是算法没有把它用好？这里有一个不能被弱化的事实：像 XLeRobot 这样成本只有几百美元的机械臂，通过遥操作已经能够完成本节这种连续的多步桌面任务——人看着摄像头画面，抓起红色杯子放进托盘，再把黄色废纸放进垃圾盒，最后重新确认状态。这个结果不是“硬件勉强具备可行性”而已，而是一个明确的诊断证据：对于这个任务，硬件本体不是瓶颈，算法才是瓶颈。

诊断方法很直接：保持摄像头、机械臂、夹爪、桌面布置和成功条件不变，先让人接管闭环。人类会持续修正物体定位、动作选择、时机控制并处理抓取失败；自主系统与人的差距，正落在这些闭环能力上。当然，这个判断的范围是本节的桌面任务：它说明硬件已经跨过了完成该任务所需的负载、精度和工作空间门槛，并不意味着几百美元的机械臂能够胜任所有开放环境或更高难度的操作。

XLeRobot 支持键盘、Xbox 手柄、Switch Joy-Con 和 VR 设备等遥操作入口。人类操作者会自然地做很多算法必须显式实现的事：夹爪靠近杯子时减速，杯子滑动时修正抓取点，第一次没有夹住纸张时重新观察，并在物体放入目标区域后检查结果。遥操作因此不只是收集演示数据，也是一种“固定硬件、替换操作者”的诊断实验。⁷

实验 9-7 ★：真机遥操作 XLeRobot 整理桌面

在真实 XLeRobot 工作区内放置红色杯子、托盘、黄色废纸和垃圾盒。操作者通过一种已完成校准的遥操作方式执行固定任务：“把红色杯子放进托盘，把黄色废纸放进垃圾盒，最后重新观察并确认桌面状态。”实验至少重复多轮，并记录摄像头画面、操作者输入、机械臂状态、动作时间、抓取失败、重试次数和最终状态。

验收不能只看“最后桌面似乎收拾好了”。红色杯子必须位于托盘内，黄色废纸必须位于垃圾盒内，机械臂回到安全姿态，而且全程没有碰撞、越界或未经确认的人工代做。

真机遥操作得到的是最有说服力的任务上限，但它不适合批量改变物体数量和位置。为了得到可重复、可统计的对照，下一步把同一个“物体归位”问题搬进二维桌面模拟器，用理想控制器代表一个不会感知错误、不会选错动作的强操作者。

实验 9-8 ★：在模拟器中测量同任务的理想控制上限

在二维桌面模拟器中随机摆放红色杯子、黄色废纸及其目标区域，由理想控制器依次接近物体、抓取并移动到正确位置。它不需要识别图像，也不会选错动作，因此代表“感知和决策都正确时，这个任务至少可以做到什么”。

实验关注任务成功率、完成步数和路径长度，并改变物体初始位置与任务规模，观察理想上限是否稳定。它与实验 9-7 使用相同的成功条件，但测量的是非致动模拟，不代表 XLeRobot 真机已经运行。二者共同建立后续自主控制的两条参考线：实验 9-7 是真实硬件上的人类闭环，实验 9-8 是模拟环境中的理想闭环。

机器人控制的基本结构

机器人系统通常会把不同时间尺度的工作分开：

这是一种常见的工程分工，不是唯一的模型架构。VLA 可以承担一部分高层判断，规划器也可以是规则程序、VLM 或优化器。无论采用哪种实现，都应该把“任务顺序”和“眼前动作”分开，否则高层模型的推理延迟会拖慢底层控制，底层的高频控制也会让高层模型处理大量无关细节。对 XLeRobot 来说，模型不应直接输出任意关节角；它只选择 pick、place、verify_state 或 stop 等有边界的技能，经过标定、限速并带超时的执行器再把技能变成真实机械臂动作。

长程规划与任务分解

用户说“把桌面整理干净”时，系统不能把这句话直接交给动作模型。规划器要先列出场景中的物体和目标，再决定先后顺序，并为每一步写清楚开始条件、完成条件和风险限制。例如：

处理红色杯子 → 清理黄色纸张 → 检查桌面

“处理红色杯子”还要继续拆成两个动作和一次检查：

pick(red_cup) → place(red_cup, tray) → verify_state()

每完成一个技能，就得到一个可以检查的节点。如果抓取失败，只重试当前这一步；如果物体被人挪动了，或者用户改变了目标，只需要重新规划受影响的后续步骤，不必把旧计划全部重做。给智能体的工具也应该足够简单：一次调用只做一件事，动作范围固定，有超时限制，执行后立即重新观察。

实验 9-9 ★★：使用 Gemini Robotics-ER 1.5 驱动 XLeRobot 自主整理桌面

保持实验 9-7 的真实 XLeRobot、桌面布置、任务指令和成功条件不变，把人类操作者替换为 Agent。可以使用 Gemini Robotics-ER 1.5 这类具身推理模型负责观察和规划，通过 RoboCrew 风格的智能体循环只开放五个工具：observe_scene、pick、place、verify_state 和 stop。⁸

模型先观察桌面，决定处理顺序，再调用经过标定的 XLeRobot 抓取和放置动作。每完成一个技能都必须重新观察并检查后置条件；抓取失败时只能重试当前技能，用户喊停、物体离开工作区或状态无法确认时必须调用 stop。模型不能直接输出任意关节角，也不能仅凭自己先前说过“已经完成”就跳过真实检查。

验收标准与实验 9-7 完全相同：杯子位于托盘内、废纸位于垃圾盒内、机械臂回到安全姿态且没有碰撞或越界。区别在于，自主实验的任务语义必须来自模型观察，真实动作必须来自工具调用，最终状态必须由新观察确认；人只能负责启动、急停和安全监护，不能在中途代替 Agent 完成动作。这样，实验 9-7 与 9-9 才能直接比较“同一硬件、同一任务，人类闭环与模型闭环之间还差什么”。

真机实验能暴露标定误差、相机遮挡和夹爪失败，却很难安全、可控地重复大量故障。后面的模拟实验会保留这五个工具和完全相同的任务状态，只把真实执行器换成可注入失败的桌面环境，用来拆解开环执行、逐步检查和动作预测各自贡献了什么。

VLA 控制

VLA 是 Vision-Language-Action 的缩写，中文可以理解为“视觉—语言—动作模型”。它接收当前画面和一条技能指令，然后输出机器人接下来要执行的动作：

当前观察 + 技能指令 → 动作

在 XLeRobot 的例子里，高层规划器只提交 pick(red_cup)，VLA 或技能策略还要根据当前画面决定从哪个方向接近杯子、夹爪何时闭合、手臂以什么轨迹抬起。执行层完成这一小段运动后重新拍摄桌面，只有确认杯子确实被夹住，规划器才允许提交 place(red_cup, tray)。因此，工具调用定义的是期望的状态变化，VLA 定义的是如何通过连续动作实现这个状态变化。

RT-2 和 OpenVLA 把连续动作切成离散的 token，再像生成文字一样逐个输出；π₀ 则代表另一条路线，直接生成连续、平滑的动作轨迹。两种方法没有简单的高下之分：离散 token 更容易和语言模型结合，连续轨迹通常更适合表达平滑运动。真正的取舍在于动作应该怎样表示，而不只是模型大小。⁹

大模型每秒通常只能推理 1—10 次，而传统控制器每秒可能要更新几十到上千次。工程上常用“动作分块”：模型一次生成一小段未来动作，控制线程按较高频率执行这一小段，模型则在后台准备下一段。这样可以把一部分推理等待藏在动作执行时间里。代价是，动作段越长，运动越平滑，模型在这段时间里看到的新画面却越少；如果 XLeRobot 伸手抓杯子时杯子被碰动，它可能仍在执行根据旧画面生成的动作。因此，动作分块是在平滑性和反应速度之间做取舍，而不是没有代价的加速。

VLA 的局限

“长程规划 + VLA”是一个实用的基本方案，但它仍然有几个容易被忽略的问题：

• 训练数据有限：机器人演示远少于互联网文本和图像数据。模型见过“杯子”这个词，不代表它见过各种材质和摩擦条件下的杯子。
• 只学会模仿，不一定懂后果：行为克隆主要学习“示范者下一步怎么做”，并没有明确要求模型回答“这个动作会造成什么结果”。
• 机器人各不相同：不同机器人有不同的自由度、坐标系、夹爪和执行器延迟，同一个动作不一定能直接搬到另一台机器人上。
• 观察可能过时：动作块开始执行后，物体可能被移动、遮挡或碰倒，但模型仍在依据上一帧画面做决定。

所以，语言模型知道“杯子”是什么，并不代表它知道摩擦、接触、液体晃动和电源线会怎样改变未来状态。VLA 主要回答“现在应该做什么”，还需要另一类模型帮助判断“做了之后可能发生什么”。

世界模型

可以把世界模型理解成一个“动作结果预测器”。它学习的是：在当前状态下采取某个动作，下一刻的状态可能怎样变化。

当前状态 + 候选动作
    → 预测下一状态或未来片段
    → 比较候选结果
    → 选择动作、重新规划或安全停止

一个能用于机器人的世界模型，至少要做好三件事：

• 看懂当前状态；
• 预测不同动作可能带来的结果；
• 把这些预测交给规划器或控制器，帮助它们做选择。

只会描述视频的 VLM，或者只会生成画面的模型，并不会自动变成可靠的机器人世界模型。它还必须知道动作是什么，并且能预测动作对物体和环境的影响。V-JEPA 2 代表在内部状态中预测未来的一条路线，World-Action Model 则明确学习“动作—未来观察”的关系。这些模型可以和 VLA 配合使用，不需要取代 VLA。¹⁰

在实际系统中，世界模型通常有三种用法：

1. 动手前：比较抓取、推动、等待等候选动作，优先选择风险更小的方案；
2. 执行时：把真实观察和预测结果对照，发现偏差就缩短动作、停止或重新规划；
3. 训练时：利用视频、仿真数据和失败轨迹学习状态变化，减少真机上的试错次数。

回到 XLeRobot 的桌面任务：如果黄色废纸被红色杯子部分遮住，系统可以比较“先抓纸”“先移动杯子”和“换一个抓取方向”几个候选技能。世界模型不需要生成一段逼真的机器人视频，只要能预测哪些候选动作更可能让纸张变得可抓取、哪些动作可能碰倒杯子，就已经能帮助规划器排序。动作执行后，真实摄像头观察仍然是最终事实；预测只能帮助选择，不能代替验收。

世界模型给出的不是确定答案，而是“如果这样做，可能会发生什么”的可比较预测。预测得越远，误差通常越大；一段看起来逼真的未来画面，也可能不符合真实的接触和摩擦规律。因此，实际系统仍然需要短期预测、实时观察、对不确定性的估计，以及独立的硬件安全控制器。生成式世界模型可以用来做交互式仿真或可视化，但不能把“会生成视频”和“能指导机器人动作”混为一谈。¹¹

实验 9-10 ★★：在模拟器中比较三种自主整理桌面的闭环

把实验 9-9 的任务、对象状态、成功条件和五个工具原样放进桌面模拟器，只把真实 XLeRobot 执行器换成可控的模拟执行器，并让抓取偶尔出现可恢复的瞬时失败。这样可以在不改变问题的前提下比较三种策略。

开环执行一次生成完整动作序列，中途不重新观察；逐步检查在每个 pick 和 place 之后重新读取状态，失败时只重试当前技能；预测式执行再增加一个短期世界模型，先比较候选技能的预期结果，再选择下一步。实验比较任务成功率、工具调用开销和失败恢复能力，并检查最终成功是否都由 verify_state 的新观察确认。

这个实验不是为了证明小型模拟世界模型等同于真实机器人的物理模型，而是验证一个更基础的关系：开环计划会把一次局部失败带到任务末尾，逐步检查能够恢复，动作预测则可以进一步帮助候选技能排序。最终是否真的完成，仍然必须由环境反馈决定。

从仿真环境到真实机器人

实验 9-10 即使在模拟器里表现稳定，也不能直接推出实验 9-9 的 XLeRobot 真机会同样成功。从仿真环境走到真实机器人，并不是再换一种控制器，而是要处理两个环境之间的差异。训练时可以使用遥操作数据、视频数据或仿真交互数据；真正部署时，同一个红色杯子、黄色废纸、托盘和垃圾盒会出现在不同的背景、光照、相机位置和遮挡关系中，机械臂还会遇到不同的摩擦、传感器噪声和执行器延迟。只要这些差异足够大，模拟中学会的动作就可能在现实中失效。

实验 9-11 ★★★：同一桌面任务的 RGB 跨环境测试

在模拟环境中继续使用“把物体移动到对应目标”的基本问题，把每个样本理解为整理桌面中的一个局部决策：根据 RGB 画面判断应该向哪个方向接近物体，或是否已经可以抓取。训练四种结构相同的视觉策略：一组只看固定画面，一组改变背景，一组改变物体外观，最后一组同时改变背景、外观、光照和噪声。

所有策略都在原始环境和变化后的新环境中测试，比较视觉条件变化前后的动作判断准确率。这个实验要回答的不是“模拟器是否已经等于 XLeRobot 真机”，而是一个更窄的问题：训练时主动扩大画面变化范围，是否有助于同一个杯子—托盘、废纸—垃圾盒任务适应新的摄像头画面。即使结果改善，真机部署仍然需要真实相机标定、执行器测试和完整的安全闭环。¹²

本章小结

本章从模型的三类能力出发：理解、生成和交互。理解与生成主要决定模型能够完成什么、智能上限在哪里；交互则把这两种能力放进一个有时间约束、会产生反馈、还可能改变环境的闭环中。交互能力与智能上限并不直接相关，但它决定模型能否在真实环境中把已有的智能转化为稳定的任务结果。

语音、Computer Use 和机器人分别把这个问题放在声音、数字界面和物理世界中。它们可以按同一条主线理解：

持续感知
  → 判断当前状态与时机
  → 选择回复或动作
  → 让输出进入环境
  → 观察反馈
  → 继续、修正、重试、停止或重新规划

语音部分比较了级联流水线、端到端 Omni 和全双工交互三种范式，核心变化是从“轮流说话”转向持续听说，并在前台实时交互与后台深度思考之间进行分工。Computer Use 把同一个闭环具体化为“截图—动作—新截图”，其主要瓶颈已从单纯的能否完成任务，扩展到操作效率、连续视觉理解和状态确认。

机器人部分则用 XLeRobot 整理同一张桌面的五个连续实验，把抽象架构落到了一个可比较的问题上：真机遥操作和模拟理想控制先建立人类与理想闭环的上限；真机自主控制和模拟策略对照再测量 Agent 与这个上限的差距。

思考题

1. ★★ 语音 Agent 的端到端模型将 ASR-LLM-TTS 合并为单一模型，降低了延迟却失去了模块化。如果端到端模型在某个环节（如语音识别）出错，调试和修复比串行管道困难得多。你会如何设计端到端语音 Agent 的可观测性（observability）系统？
2. ★ Step-Audio R1 通过 MPS 双脑架构实现“边想边说”。但人类在“边想边说”时经常会说出未经深思熟虑的话、自我纠正、或使用填充词。Agent 的“边想边说”应该模仿人类的这些特征吗？
3. ★★ SoM（Set-of-Mark）及其结构化变体（DOM 元素索引）将 Computer Use 的视觉定位从开放坐标预测转为封闭 ID 选择，但都需要先检测和标注界面元素——无论靠分割模型还是靠 DOM。如果界面包含非标准控件或动态变化的元素，标注就可能不完整或不准确。这种情况下应该回退到坐标预测吗？
4. ★★ XLeRobot 等几百美元级机器人平台让遥操作数据收集变得廉价。但遥操作数据的质量高度依赖操作者的技能。一个不熟练的操作者提供的数据会如何影响 VLA 模型的训练？如何在数据收集阶段自动筛选低质量数据？
5. ★★★ 本章覆盖了语音、Computer Use 和机器人三种交互形态。交互架构可以通过端到端统一、模块化级联或前台交互与后台推理解耦来改进，而不必和智能上限沿同一条路线增长。未来五年的 Agent 应该优先追求更强的统一模型，还是保留可替换的快慢分工？请结合延迟、可观测性、模型迭代速度和任务风险讨论。
6. ★★★ 当前 Computer Use 以“截图 → 动作 → 截图”的离散循环运作，每次观察都是一张静态帧。但人类对屏幕的感知是连续的——我们能看到动画播放、观察加载进度、理解视频内容。这意味着今天的 Computer Use 根本无法处理需要时序视觉理解的任务。如何重新设计感知层以支持连续的视觉流理解？
7. ★★ DOM/Accessibility Tree 元素索引在标准 Web 应用上效果显著，但越来越多的软件界面（Canvas/WebGL 渲染、跨平台自绘控件）不提供可访问的结构化信息，只能依靠视觉标注或坐标预测。你认为 Computer Use 应该押注纯视觉路线，还是同时维护结构化和视觉两条路径？维护两条路径的成本和收益分别是什么？
8. ★★ VLA 模型采用动作分块（action chunking）——如正文所述，π₀ 的典型配置是一次生成 50Hz 频率下 25-50 个未来动作——将推理延迟隐藏在执行时间里。但如果执行过程中环境突变（如物体被移走），预生成的动作序列就会失效。如何在动作分块的效率优势和环境变化的响应速度之间取得平衡？
9. ★★★ 本章的三个场景（语音、Computer Use、机器人）都面临“感知-思考-行动”循环的延迟问题，都需要在智能上限和交互时效之间做分工。在语音场景中，这表现为“说错了再纠正”；在 Computer Use 场景中，这表现为“先点再看”；在机器人场景中，这表现为“走一步看一步”。如何通过动作分级、可逆操作、状态确认、权限控制和安全停止，保证快速交互不会导致无法挽回的后果？