第 16 章 多模态与实时智能体

本章把智能体的能力往三个方向各推一步，图像、实时语音和屏幕操作；前五个部分一直有一个共同设定，模型的输入输出都只是文字，可真实业务常常是另一回事，快递客服收到的附件可能就是一张现场拍下的破损快件照片，语音热线那一头根本没有输入框，电商运营要改价的商家后台不提供 API、只留下一张张网页表单。16.1 讲图像理解与图像生成，图片直接放进对话消息、按 token 计费，这一节的图像输入也是后面两节的共同入口；16.2 讲实时语音，WebSocket 全双工、语音活动检测与打断处理，把一轮交互的延迟从秒级压到对话的节拍；16.3 讲计算机使用智能体，让模型直接看屏幕、动鼠标键盘，截屏、DOM 和混合三条表示路线各有代价。三个方向各补一环，图像补输入输出面，照片、截图和扫描件不必再靠人逐句转成文字，模型也能直接交出图片；实时语音补交互节奏，模型话说到一半，用户插话也能当场接上；计算机使用补行动能力，只有界面、没有接口的系统也能上手操作。

16.1 多模态 API，图像理解与生成

多模态（Multimodal）说的是模型能同时应付文本、图像、音频等多种形态的输入和输出。这一节从最常用的图像理解讲起，做法就是把图片直接放进对话消息；中间过一遍中文模型的多模态现状，再接着看图像生成的调用长什么样。拿快递场景当例子，用户传上来一张快递纸箱的照片，纸箱一角已经塌陷，表面洇着一大片水渍，还跟着一句话“这样能理赔吗”，只认文字的智能体接到这张图，能做的只有两件事，要么请用户把破损情况描述一遍，要么干脆当这张图不存在，不管走哪条路，用户的体验到这里都断了。

图像理解在调用形态上动的还是第 1 章那份 messages。区别只有一处，content 从字符串换成了数组，文本块和图像块并排摆在里面。下面拿通义百炼的 OpenAI 兼容端点做例子，接入方式沿用第 1 章 1.4。

import base64
import os

from openai import OpenAI

# 通义百炼 OpenAI 兼容端点，地址按官方兼容接口文档现在给的填（业务空间形态，第 1 章 1.4）
client = OpenAI(
    api_key=os.environ["DASHSCOPE_API_KEY"],
    base_url="<百炼兼容端点，见官方文档>",
)

def encode_image(path: str) -> str:
    with open(path, "rb") as f:
        return base64.b64encode(f.read()).decode("utf-8")

response = client.chat.completions.create(
    model="qwen3-vl-plus",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "这张面单照片上的运单号是多少？只回答号码。"},
                {
                    "type": "image_url",
                    "image_url": {
                        "url": f"data:image/jpeg;base64,{encode_image('package.jpg')}"
                    },
                },
            ],
        }
    ],
)
print(response.choices[0].message.content)

content 数组里只放两类块。type 为 text 的块装文字指令，type 为 image_url 的块装一张图。把图交给模型，主流做法分两种。图挂在公网上，就把 URL 直接写进 image_url.url，下载的工作交给服务端。图存在本地，就先读出二进制、用 base64 编好码，拼成 data:image/jpeg;base64,xxxx 这种 data URL，再填进同一个字段。

OpenAI 还备了第三种形态。图先通过文件接口传上去，之后用文件 ID 来引用，单个请求最多放 1500 张图，总载荷 512MB（截至 2026-08，以官方文档为准）。要一次给多张图，就把图像块依次排进同一个数组。拿面单照片和破损照片对照、让模型判断责任归属，就是这样的场景，两张图各占一块，模型按顺序全看得到。

百炼那边走的也是同一条链路，视觉模型挂在 OpenAI 兼容端点上，消息结构和 OpenAI 完全一致，从文本模型迁过来只需要换掉 model 参数和密钥，几乎不花什么额外成本。

图片的计费不走张数，走 token。一张图只要进了上下文，厂商就会把它折成若干 token，至于折多少，取决于这张图的分辨率和清晰度档位。

OpenAI 的计费方式很有代表性（截至 2026-08，以官方定价页为准）。规则有些细碎，先把几条摆出来，随后拿一张截图算一遍就能明白。detail 参数写在图像块的 image_url 里，和 url 并列。取值是 low，图片就压成 512 像素见方，只收一个固定的低价。取值是 high，图先按比例缩到最长边不超过 2048、短边不超过 768，然后数 512 像素见方的块，按块加价。gpt-4o 与 gpt-4.1 这一代，从基础 85 个 token 起算，每块再加 170 个。

gpt-5.4 起又多了 original 档，专门给画面大、细节密的图用，计算机使用的截屏也算这一类。它的计费方式改成数 32 像素见方的补丁块，块数再乘一个约 1.2 的系数。另外，各档都给块数设了预算，超过预算就先把图等比缩小。

具体怎么算，用一张 2048×1536 的截图走一遍 gpt-4o 与 gpt-4.1 这一代的计法就能看清，档位一旦选错，成本会差出一个数量级。high 档先做等比缩放，短边 1536 高过 768 的上限，缩到 768 等于整体砍掉一半，长边跟着掉到 1024，图就成了 1024×768。接着切 512 见方的块，长边 1024 分成两列，短边 768 摊出一行半，不足整块的照整块算，两列两行合起来 4 块。从 85 个起算，每块加 170 个，总数到 765 个 token。low 档不挑图多大，一律只按基础 85 个计，同一张图就差了九倍，不多不少一个数量级。这笔开销我第一次是拿厂商的计费记录反推出来的，档位一选错，差价在一页计费单上排得明明白白。到 16.3，计算机使用智能体每走一步观察都要截屏，这项开销还会再放大。

中文厂商计费时同样会把图像折成 token，只是公式大多不公开。好在 usage 回执里有个现成的 image_tokens 字段，拿一张典型图发一次请求、读一回回执，就能实测出折算口径，比照着像素面积凭直觉估可靠得多。

截至 2026-08，中文模型的多模态支持是什么情况？把四家的视觉能力摆在一起，差别一眼就能看出来。

厂商	系列	能力面	接入与特点
通义	Qwen-VL（qwen3-vl-plus 等）	图像理解	百炼 OpenAI 兼容端点，名字直接填 model 参数，另有 OCR 与视觉推理系列
Kimi	旗舰原生视觉	图片与视频	base64、文件上传、多图对话
豆包	视觉理解系列	图片、视频、文档	火山方舟提供理解接口
智谱	GLM 视觉系列	图像、视频、文档	含图形界面分析能力，16.3 再遇到

别看各家厂商的调用形态五花八门，共同点倒是很清楚，都在往 OpenAI 的消息结构上靠。差别留在细节里，视频能接多长、图像分辨率顶到多少、有没有单独的 OCR 系列，每家答案各不相同，真到接入那天，还是以各家厂商的官方文档为准。中文业务里，视觉模型常派上用场的地方主要有三个，面单与发票的字段抽取、商品图的合规审核和手写工单的辨认。只做文字抽取，交给各家厂商专门的 OCR 系列更划算；需要理解与判断的，像这张破损该谁担责，才轮到通用视觉系列。

OCR 本身的实现分三路，取舍摆在一起才看得清。独立 OCR 引擎包装进流水线是老路，模块化、可解释、能在本地跑，引擎和模型各自单独调优；原生带 OCR 能力的基础模型是第二条，图像直接进、文本直接出，在手写、扫描件和带噪截图这类困难输入上更稳；第三条是拿自家单据为 OCR 微调一个多模态模型，准确率最高，投入也最大。三路怎么挑，要看调用量有多大、单据版式稳不稳、要不要本地部署，并不是越贵越好。

图像生成正好反过来，模型交出来的不再是文字，而是一张图。通道也不再走 chat 接口，改用一条独立的生成接口。OpenAI SDK 的形态见下，client 是 OpenAI 形态的客户端，中文厂商的生成接口各有自己的端点。

result = client.images.generate(
    model="gpt-image-2",
    prompt="一张扁平风格的插画，快递纸箱一角塌陷，表面有明显水渍",
    size="1024x1024",
)
with open("broken-box.png", "wb") as f:
    f.write(base64.b64decode(result.data[0].b64_json))

请求里给一段文字描述，配上尺寸、质量这些参数，返回直接就是图片的 base64，写进文件就能用。OpenAI 眼下走 GPT Image 系列，截至 2026-08 最新到 gpt-image-2。中文这边，通义万相在百炼上放了文生图模型，wan2.6-t2i 就是一个（截至 2026-08，以百炼文档为准）；豆包则用火山方舟图片生成 API，模型是 doubao-seedream 系列。各个模型服务提供商的形态都差不太多，文本进去、图片出来，按张或者按量收钱。

把生成和理解拼到一起，就能组成一个闭环，先让模型生成一张图，再把图送回视觉模型自查，看文字有没有拼错、构图符不符合要求，不合格就带着审查意见重新生成，全程不用人眼盯着。这套做法在营销物料、商品配图的初稿生产里，已经是常见的流水线。

生成出来的内容，免不了被追问一句，这是不是 AI 做的、谁做的。可靠的答案得在生成那一刻埋进去，事后猜是猜不出来的。想埋这个答案，眼下有两条路可走。一条是水印，生成时轻微调整选词或像素的概率，让输出带上肉眼看不出的统计特征，埋水印的一方自己能验出来；短板也在这，换一家生成的内容，它就验不了。另一条是 C2PA，一套内容来源的开放标准，把生成工具、修改历史这些来历以元数据的形式随文件携带，15.6 讲的隐式标识与它是同一类做法。至于反向的问题，拿一份来历不明的内容判断是不是 AI 生成，现在的检测器靠不住，连模型厂商自己出的文本分类器都因为准确率不足撤下过。商用物料牵涉知识产权时，能自证来源的是生成那一刻留下的记录，不是事后检测。

生成这一头还有一个结构性的节省思路，把构思和渲染拆开。模型只负责出构思，交一份结构化的参数或图形代码；把它画出来的工作交给确定性代码，用户拖动滑杆调参数，也不必再惊动模型。token 集中花在构思这一步，渲染和微调一分不花。生成图像如此，生成界面上的图表与图形，道理一样通用。

图像进上下文的消息通道还有第二条，工具结果里同样能夹带图片。这块形态是各家厂商的协议自己定的，4.3 讲方言时见过，那边的 tool_result 本身是块数组，图像块和文本块可以一起放进同一条 user 消息。落到 OpenAI 兼容形态，工具结果是 4.2 那样的字符串，图像块在这里不是标准件，各家厂商有没有扩展、怎么传，都要以当期文档为准。16.3 的计算机使用智能体正是从这个入口进来的，每一步观察回填的都是截屏图，那节的例子走 Anthropic 形态。

视觉模型通常也接视频，只是模型眼里并没有连续的视频流，只有抽出来的帧序列。调用方把视频文件或 URL 传上去，抽帧的工作交给服务端，这个机制到 16.2 讲实时视频输入时还会再碰到。

图像理解躲不开幻觉。图上模糊的数字、反光盖住的文字，模型都可能编一个看着合理的值。运单号在照片里只占十几个像素时尤其危险，模型多半会顺手编一个，而不是直接说看不清。多图对照又添一层风险，面单和破损照片一旦读串，就会把 A 单的结论安到 B 单头上。碰到关键信息，要么让模型先给出图中依据再作答，要么收进第 12 章的评测任务集定期回归，别让破损定责这类判断没经过校验就上线。

消息通道之外，图像还有第三种用法，绕开对话去走检索。多模态检索有两条路。一条是生成式，叫视觉模型看图说话，先把图翻译成文字，再送进第 6 章的检索管道。另一条是嵌入式，请多模态嵌入模型把图和文映射进同一个向量空间，照片直接拿来当查询，去翻纯文字写的目录。买家拍一张穿搭照问“有没有同款”，生成式要模型先描述照片再去找，嵌入式则拿照片的向量直接比相似度，少一步转述，就少一层走样。

拿商品目录举例，嵌入式有一条现成的做法。每个商品，把标题、描述文本和商品图合在一起，嵌成一个向量；价格、类目这类结构化字段不进向量，另放进元数据里。检索时先按向量召回，再拿元数据做过滤。第 6 章那条铁律在跨模态检索里照样成立，库里的向量和查询向量必须出自同一个嵌入模型，照片向量和目录向量要用同一个模型算，一旦换模型，整个库都要重建。

图像进了上下文，调用节奏却一点没变，还是一次请求、等一个完整响应，延迟按秒计。语音对话要求的延迟比这低一个数量级，还得让用户随时插话，一问一答等响应的模式满足不了这两条，16.2 换一套架构来应对。

16.2 实时语音，WebSocket 全双工、语音活动检测与打断处理

实时语音要解决三件事，一条双方都能随时开口的传输通道、轮次由谁判定、用户插话怎么处理，本节按级联与端到端两路架构、语音活动检测、打断处理与回声消除展开，鉴权、视频输入和测试分层随后各给做法。交互要论自然，语音排第一，可第一代智能助手恰恰把它做得最差，2011 年 Siri 跟着 iPhone 4S 亮相之后，这类产品共有的失败模式很快就现了形。

一段典型对话就能说明问题。用户说“帮我找几家不错的意大利餐厅”，助手答得不错，接着追问“你偏好城里哪个区域”，用户回“嗯，办公室附近的怎么样”，助手接不上这句上下文，直接把它当搜索词丢给了搜索引擎。问题出在老的架构上，整套系统建立在意图（intent）与槽位（slot）的表单模型上，先判断用户想触发哪条命令，再从句子里提取参数去填表格，表格填不上，整条链路就走不下去。

大语言模型把理解上下文这道关闯过去了，可真要把 LLM 接进语音链路，第一个障碍是传输架构，模型能力反而排在其后。

这条链路按直觉搭出来就是下面这样。先把一整句话录下来，交给语音识别服务转成文字。文字发给 LLM，取回一段回复。回复再送语音合成服务，换回音频，最后在本地播出来。全程五段串行，两头的录音和回放是本地动作，中间三段各自要跑一趟完整的 HTTP 请求响应。三次来回加到一起，从用户说完话到听见第一声回复，延迟很容易就超过一秒。这条五段链路有个通行的名字，叫流水线，也叫级联，与降成本语境里按难度在小模型与大模型之间分流的模型级联，不是一回事。

比延迟更麻烦的是结构上的缺陷。HTTP 天生一问一答，服务端没法主动把数据推到客户端，模型正说着话，用户的插话根本递不进去，只能等这一轮播完再排队。轮询也补不上这个缺口。客户端定时去问服务器有没有新数据，轮询间隔本身就是一段延迟，间隔一压短，连接数先到达上限。

语音对话真正需要的，是一条双方都能随时开口的通道。全双工（full-duplex）就是两个方向同时收发的通信模式，WebSocket 是它最标准的实现，连接一建立，客户端和服务端随时都能主动发消息，谁都不用等对方。

第 1 章提过 API 没有状态，每一轮都得把全部历史重新发一遍。实时语音换了个挂法，把会话状态挂在连接上。建连时先发一条 setup 消息，声明用哪个模型、什么音色、回什么模态。之后麦克风音频按几十毫秒一块切好，不断上行，模型的音频增量持续下行，客户端边收边播。会话就是这条连接本身，连接一断，会话跟着结束，重连就得从头重建状态。

工具调用也在这条会话里完成。语音通道并不只管聊天，setup 消息里就能顺带声明函数，格式跟第 4 章的 JSON Schema 是一套。对话走到需要动手的地方，模型推过来一个函数调用事件，带着一个调用标识。客户端执行完，拿同一个标识把结果回填进会话，模型再用这个结果接着生成，全程不必断开重连。

OpenAI 的 Realtime API 与 Google 的 Live API 流程上是同一套，Gemini 一边额外多了一档非阻塞模式，工具在后台跑，模型不必空等结果。第 4 章那套工具循环放回这里照样转得动，差别只在每一圈都发生在一条长期在线的连接里。

实时链路的鉴权有个特殊之处，主密钥无论如何不能进前端。多数实时产品是 Web 应用，浏览器要直连实时接口，而页面里任何混淆手段，都防不了用户打开开发者工具去看网络请求。

两家官方给出的其实是同一个模式，都让后端代签临时令牌。自家服务端拿主密钥向签发接口换一个短时效的令牌，再发到页面，页面拿它建连，过期了就作废。OpenAI 的 Realtime API 有一个专门的签发接口，签发时还能带上用户标识，让会话和最终用户挂上关系。Gemini 的 Live API 文档同样写明，生产环境要用临时令牌，不用标准 API key。

代签令牌把密钥的暴露面收得只剩一台服务端，第 13 章讲的那条治理原则，说的就是这种情况。

语音活动检测（Voice Activity Detection，VAD）管的是这条链路里的轮次判断，谁在说话、什么时候算说完。没有它，系统分不清用户是停下来喘口气还是真说完了，只能靠按钮切换轮次，那等于退回第一代的老路。

VAD 会持续分析上行音频，一检测到自然的停顿，就判定这一轮用户说完了，触发模型开始生成。成熟的实现还能把主说话人和背景噪声分开，路边过车、旁边有人闲聊都不至于误触发。想管得更严也可以，把服务端 VAD 的灵敏度调低甚至直接关掉，客户端改用按住说话那种按键模式。

VAD 放在哪一侧，是实现时要做的取舍。Google 的 Live API 把它放在服务端，挪到客户端自己做也行，开源的轻量 VAD 库能直接嵌进采集端。

用户话说到一半就把模型打断，后面那套处理马上跟着转起来。

VAD 最棘手的场景要数打断（barge-in），也就是模型话没说完，用户先开口。真人聊天里抢话插嘴天天发生，模型讲到一半，用户已经发觉方向不对。链条是这么走的，服务端 VAD 在模型播音时检测到用户语音，判断用户打断了，先向客户端推一个打断事件。客户端随即停播，把没播完的音频队列清掉，同时中止本轮生成，用户后面说的话就作为新输入进来。链路本身不复杂，难在两处。

难处之一，是半句话怎么进上下文。模型的话播到一半就掐断了，已经播出去的用户听见了，没播出去的只存在于生成流里，这一轮在对话历史里该怎么记？记全文，等于把用户根本没听到的内容也算作说过；记一半，模型原本的意图又丢了。更麻烦的是，打断本身就带着修正的信息，用户插的那半句“不对，发顺丰”，只有结合刚才没播完的那段话才能正确理解。各家厂商的实时接口处理这类状态的细节各不相同，接入时看当期文档，但问题本身谁也绕不开。

难处之二在回声，表现是模型打断自己。扬声器正在播模型的语音，麦克风却一直开着，把模型自己的声音收了回去。对 VAD 来说，这段音频和用户说话分不出来，于是它判定有人插话，停掉播放、清空队列，结果助手永远说不完一整句。

信号处理领域给这个问题起了个专门名字，回声消除（Acoustic Echo Cancellation，AEC）。做法是拿正在播放的输出信号当参考，把麦克风输入里对应的那部分成分减掉。全程实时完成，难度在信号处理圈里相当出名。

终端这一侧倒是有一条现成捷径。浏览器给实时通话备了一套媒体栈，硬件加速的回声消除是内置的，采集麦克风时打开一个约束就能启用。

const stream = await navigator.mediaDevices.getUserMedia({
  audio: { echoCancellation: true },
});

多数实时语音产品愿意做成 Web 应用，这也是一个理由。回声消除这件难事可以整个交给浏览器，代价是多扛一层 Web 前端的工程复杂度，这笔交换多数团队算得过来。让用户戴上耳机当然也能从物理上隔断回声，可把戴耳机当成前置要求的产品，体验先输了一截。

除了音频，实时接口普遍还收视频，处理方式跟直觉正好相反。摄像头或屏幕共享的原始流是每秒三十帧的视频，直接上行既费带宽又费 token，也没必要，模型要的是环境快照，不是流畅动画。通行的做法叫抽帧，采集端每秒从视频流里取一帧，画到画布上转成 JPEG，作为图像块单独发过去，用户本地的预览画面仍是全帧率播放。抽得密，信息全、响应快，成本也跟着高；抽得疏，成本降了，动作一快模型就看不清发生了什么。每秒一帧是常见的起点，具体按场景调。

截至 2026 年 9 月，这一层各个模型服务提供商的做法大体趋同，双向流以 WebSocket 为主，但它不是唯一的路。OpenAI 的 Realtime API 同时提供 WebRTC 传输，浏览器、手机这类客户端直连的场景，官方推荐用 WebRTC，理由是性能更稳；WebSocket 留给服务端对服务端的连接。各家厂商对 WebRTC 支持到什么程度，以当期文档为准。Google 的 Live API 建在 Gemini 体系上，音频、视频、文本输入和音频输出能在同一个会话里并发。OpenAI 的 Realtime API 靠 realtime session 维持长连接，模型走 gpt-realtime 系列，音频和图像输入都能接。这两家的会话都是音频直接进出模型、不落文字稿的端到端形态，跟前面那条五段流水线正好相对。

中文厂商这边，火山引擎的豆包端到端实时语音也走 WebSocket 接入，全双工版本已经有了（口径截至 2026-08）。阿里云百炼的 Qwen-Omni Realtime 系列收流式音频加图像帧输入，专门做实时音视频对话。能力细节迭代得很快，具体参数看各家厂商的当期文档。

把这些机制拼起来，骨架不长，两个协程各管一个方向，主循环里只剩调度。下面的骨架代码略去了麦克风采集、播放队列与鉴权，事件名与字段要对齐所用厂商的文档，不能直接运行。

import asyncio
import json

import websockets  # 第三方包，pip install websockets

async def send_loop(ws, mic):
    """上行：麦克风音频块持续发送，发出去就忘。"""
    async for chunk in mic:            # 采集端按固定时长切块
        await ws.send(json.dumps({"type": "audio", "data": chunk}))

async def recv_loop(ws, player):
    """下行：模型音频增量入队播放，打断事件立即清空队列。"""
    async for message in ws:
        event = json.loads(message)
        if event["type"] == "audio":
            player.enqueue(event["data"])
        elif event["type"] == "interrupted":
            player.stop_and_clear()    # 用户插话，掐掉未播完的音频
        elif event["type"] == "turn_complete":
            player.mark_turn_end()     # 一轮结束，回到监听状态

async def main():
    async with websockets.connect("wss://example.com/realtime") as ws:
        await ws.send(json.dumps({"type": "setup", "model": "…"}))
        await asyncio.gather(send_loop(ws, mic), recv_loop(ws, player))

asyncio.run(main())

这段骨架有三处关键点。收发两个方向真正并发靠 asyncio.gather，任一方都不卡另一方，全双工落到代码里就是这个结构。recv_loop 处理打断事件必须当场做，清空播放队列晚个一百毫秒，用户就会多听到半句话。send_loop 发出音频块后不等任何确认，发出去就忘，可靠性和顺序都交给 WebSocket 协议本身。

选流水线还是端到端，还要把一件事算进去，护栏能放在哪。流水线会先把语音转成文字，再交给模型，转写稿走到模型之前，就能加一道护栏，不该答的内容这一步能拦住。模型讲完、合成播报之前还能再加一道，比如把信用卡号按下不念出来，匹配规则还得容忍转写错几个字。端到端实时模型没有这类插入点，音频直接进模型，输入侧无处下手，护栏只剩输出一端。要不要输入护栏，成了选架构时必须实际计算的一项。要，就走流水线，模型前后的检查点都在；端到端的话，防线全压在输出侧和权限设计上。

两条路之间还留着混着用的余地。前台摆一个端到端实时模型，快问快答，打断照接；碰到专业任务，按意图切给流水线那头的专家，交接在内部完成，用户那头听不出接缝，语音里没有页面刷新这种事，切换做得平顺，整段对话听下来就是连续的。再往外一圈是电话网。真要接进能拨真实号码的电话系统，最后一公里靠 SIP（会话发起协议，电话网建立通话用的控制协议）网关，一边接电话信令，一边把音频流翻译成实时接口收发的块，实施细节看各家网关厂商的文档。

语音测试也有自己的分层办法，从里到外一共三种。最里层用文本模式跑，绕开语音接口，测的还是逻辑、工具调用与交接，跑得快，适合天天回归。中间层用预录好的音频文件顶替麦克风，让转写、模型到合成整条链路真实走一遍，转写错字这类链路问题，就得靠这一层暴露出来。最外层请一个 LLM 扮演客户，和被测智能体真实对话若干轮，考察多轮体验和打断处理。这一层就是第 12 章的模拟用户，它的弱点与治理照样适用。三层各管一段，哪里坏了就近修哪层，真麦克风加真人对话，留给发布前的最后验收。

16.3 计算机使用智能体，截屏、DOM、混合表示三条路线与代价

计算机使用智能体（Computer Use Agent）让模型直接看屏幕、动鼠标键盘，把只有界面、没有接口的系统里的任务做完。这类任务的真实场景不少，供应商一张调价表递过来，五百多个 SKU 都得在商家后台一个个改价，可后台不开放 API，能用的只有网页表单；财务那边每周要把各条线的明细填进公司报表系统，那套系统比报表制度还老，同样只有界面。这类任务想自动化，向来只有两条路，要么说服系统方开接口，周期按季度算，要么雇人点鼠标，按件付钱，计算机使用是第三条路。

这类智能体干活的循环，仍是观察、思考、行动的老三样，落到实现层面是三个组件，各管一段。LLM 那一层生成动作序列，把任务翻译成界面动作，点哪个按钮、往哪个输入框填字。界面表示这一层做一次转换，把当前界面状态换成某种形式送进模型。最后一层是自动化工具，负责把动作真正执行到界面上。

执行器早就成熟了。模拟鼠标键盘，浏览器场景拿微软开源的 Playwright 来干，桌面场景交给 PyAutoGUI。

真正的新问题出在组件的配合上，它和普通工具调用有一个根本差异。天气工具返回“晴，24 度”，信息到这儿就完整了；智能体点下一个按钮之后，却必须再看一眼界面，新页面出来了没有、报错了没有、弹窗挡住了没有。观察是动作的一部分，一旦省掉，动作成没成、下一步往哪走，模型自己都不知道。

三条路线的差别，其实就在界面表示这一个组件上，也就是拿什么去代表屏幕。

文本路线用结构化文本表示界面，落到 Web 场景就是 DOM 与 HTML。直接的好处摆在明处，模型读到的是一份精确结构，定位元素靠 CSS 选择器，token 也省。问题在真实页面的 DOM 又大又脏，广告脚本、隐藏元素和无关节点全搅在里面，整页扔给模型，既吃上下文又分注意力。工程上只能做过滤，把可交互的按钮、链接和输入框留下。

过滤之外还有一道更硬的关卡，覆盖率。桌面应用通常没有文本形态的界面表示，能到手的只有截屏。移动应用更麻烦，布局文件在训练语料里倒是常见，运行时的应用却不会把它吐出来，文本路线照样够不着。

还有一类无障碍接口，像 Windows 的 UI Automation、macOS 的 Accessibility API，能读出元素层级与状态，勉强算文本路线的延伸。可它们表达不了布局和视觉关系，颜色、重叠和图表这些全都会丢。

中文场景里大量政企与行业软件恰好属于“只有界面”那一类，文本路线碰上它们直接出局。

截屏路线的做法是拿图片表示界面，让视觉模型直接看，16.1 讲的图像输入在这里派上用场。覆盖率是它最大的优势，恰好跟文本路线相反，凡是显示得出来的界面都截得到，桌面应用、远程环境和 Canvas 画的图表都一样。

代价集中在三处。图像本来就按 token 计费，16.1 算过这笔开销，截屏又格外费 token，分辨率一高，一张图能顶几千 token。截图上没有 CSS 选择器可用，模型定位点击位置只能靠坐标，按钮标签、输入框占位符这类精细文本，从图里读出来常有偏差。窗口尺寸、分辨率和界面改版都会让像素变样，泛化比文本路线难一截。

工程上还有一类增强做法。先让检测模型在截图上把可交互区域框出来、逐个编号，再把标好号的图交给模型，OmniParser 与 Set-of-Mark 提示都属于这一路。

另一个方向是专用模型。字节跳动的 UI-TARS 只看截图输入，拿大规模界面数据专门训练 GUI 操作，在 OSWorld 基准上拿到 24.6% 的成功率，盖过同期通用模型加提示的方案。这条路线要再往上提能力，眼下靠的主要就是这份专用训练。也有厂商不另开专用模型，把 GUI 分析做进通用视觉模型里，智谱的 GLM 视觉系列（16.1 的厂商表提过）走的就是这条路。

混合路线干脆两个都要。DOM 结构负责精确定位，截屏负责视觉上下文，实现上让同一个取状态的接口分出 text、visual、hybrid 三种模式。效果通常最好，代价也跟着上来。双份输入吃两份 token，工程量比单一表示多出几倍，两种表示要对齐、要同步，任何一路失败还得备降级路径。面向生产环境的 Web 智能体，推荐的就是混合。要精确、要控制成本，走文本；要覆盖率，走截屏；两头都想要，就准备付混合这层工程成本。

三条路线之外其实还有第四条。WebMCP 出自 W3C 网页机器学习社区组，是个还在孵化的标准提案，截至 2026 年 8 月没有定稿。它把方向整个反了过来，不再让智能体去逆向工程界面，而是让网站自己声明能做什么。它想给网页平台添三件东西。一件是在浏览器里注册工具的原生接口；一件是把现成 HTML 表单标注成工具的声明式写法；还有一件是管发现与状态的共享契约。

这套提案落到开发者手里，有两条路可选。命令式用 JavaScript 注册工具，调用后返回结构化结果，注销挂在 AbortSignal 上，页面一关就自动清理。声明式简便得多，给表单元素加几个属性，浏览器自动把参数 schema 生成好，存量表单改几个属性就变成了工具。

WebMCP 跟第 5 章讲的 MCP 哲学相通，差别只在它们待的层。后端的 MCP 服务器是独立进程，凭据自己管。WebMCP 的工具跑在用户的浏览器标签页里，继承用户已登录的会话，操作天然以用户身份发生，会话 Cookie 和 DOM 在同一处。这条路线真要走通，前面那些 DOM 噪声、截屏 token 开销和点哪个按钮的歧义都会换成另一副样子。代价是网站方得动手改造，智能体这一侧只能等生态慢慢长成。

路线选完，离系统做完还差得远，剩下六项挑战，每一项都能在中文场景里找到对应。

界面表示和接地，也就是把模型的动作对上真实的界面元素，难在细节与开销之间的平衡，这一点前文已经展开过。

上下文与记忆这一关，要跨着系统过。任务得在多个后台之间把状态维持住，价格改到一半切去库存系统查个数，回来还得记得上次改到哪个 SKU。

动作消歧这一关躲不开。页面上同名按钮一多，像三个都叫“提交”，一个属于表单、一个藏在弹窗、一个管分页，模型凭什么点这个而不点那个？真拿不准时向人求证，比贸然点击一次再回滚划算得多。

安全与隐私这头同样松不得。智能体手里过的是登录态与凭据，截屏里带着的还是用户数据。

剩下两项，延迟与成本、可靠性与鲁棒性，恰恰是生产里最容易出问题的。每一步都是一次模型调用，截图再把 token 数往上顶，五百个 SKU 的改价任务走完就是两三千次调用。对策主要有几条，按会话设 token 预算，按任务监控成本，常规动作用小模型，只在需要决策时才截屏。

调用节奏上还有一个结构性省法，省在动作序列怎么排上。让模型照当前界面把整串动作一次排完，再交给执行器照单跑，这叫显式规划；让模型一步一停，每动一步看一眼新状态再动下一步，这叫隐式规划。静态、可预期的界面用前一种划算，登录表单、联系表单这类页面，动作序列提前定得下来，模型调用从每步一次缩到头尾几次。动态界面只能用后一种，机票预订、信息流这类页面，执行到一半界面自己会变，提前排好的步骤会过时，逐步看状态反而少走弯路。判据就一条，界面会不会在模型预料之外变样。

可靠性这一头同样严峻。弹窗、界面改版和不同浏览器的行为差异，随便哪一个都能让昨天还能跑的流程今天失效。这就回到第 12 章的结论，这类系统要是没有评测任务集兜底，根本不敢迭代。

截至 2026-08，Claude 这边已经把这套组件打包成了标准件。计算机使用工具成了稳定工具集 computer_toolset_20260801，不再需要 beta 头，旧版 computer_20251124 也还能用。工具集里共 17 个成员工具，截屏、区域放大、单击双击三击、右键、拖拽、移动光标、滚动、按键、输入文本和等待都在其中，动作空间就是这份工具清单本身。调用的时候只要声明一个工具类型。

{
  "tools": [{ "type": "computer_toolset_20260801" }],
  "messages": [
    { "role": "user", "content": "登录商家后台，把 SKU-8848 的价格改成 59.9 元。" }
  ]
}

模型把结果回填时同样走 tool_result，特别的是截屏这个动作。回填过来的是 base64 编码的 PNG 图像块，恰好接上 16.1 的图像输入，模型看到的下一帧屏幕就是一张普通图片。

官方文档把安全建议写在同页。系统要在最小权限的专用虚拟机或容器里跑，网络出口要限制，敏感动作要有人确认。这些跟第 13 章 13.2 的结论完全一致。计算机使用类智能体暴露面最大，它要执行任意网页里可能藏着的指令，白底白字的隐藏文本就混在它读的 DOM 与截图里。虚拟机隔离与 13.3 的三层防御，是这类系统部署的前提，不是可选项。

白底白字之外，指令还能藏得更深，直接写进图片的像素里，藏成文字轮廓，藏成人眼难辨的图案。截屏路线的智能体看得见这些字，也会照着执行；DOM 路线读的是结构化文本，像素里藏的字碰不着，想执行也无从执行。同一句恶意指令换个藏法，一条路线中招、另一条躲过，这类攻击叫视觉提示注入（Visual Prompt Injection）。

危害有专门的基准量过，VPI-Bench 测下来，计算机使用智能体的误导率最高过半，浏览器类最脆弱，到过百分之百。防它有三层。截图来源收窄，只截任务环境里的画面；截到的内容过一道二次检查，专找像素里藏的指令；关键动作执行前，人工确认照旧顶上。

企业安全这边还有一个缺口。传统终端安全工具设计的时候就默认操作者是人。终端检测与响应（EDR）盯着进程与文件行为，数据防泄漏（DLP）盯着数据外发，可哪个是合法的人工操作，哪个是行为长得差不多的智能体操作，它们分不出来。改价智能体逐个点后台按钮，落下的键鼠事件和日志，跟人手操作留下的一样。盲区是双向的。企业想放行自家智能体，在现有工具里也找不到能把它加进白名单的地方。注入攻击真操纵了智能体，现有工具也未必能拦住。安全厂商正在补这个缺口，浏览器检测与响应（BDR）一类工具，就是冲着监控浏览器里的智能体行为去的。计算机使用智能体进场之前，要问安全团队的问题清单里，就得添上这一条。

还有一层约束在技术之外，让智能体去操作别人的网站，先看对方让不让。robots 协议与服务条款怎么写、限流给多少，动手之前都看一遍；能跑无头浏览器就别占一台带界面的机器，资源开销能省则省，压垮对方服务器的事更不能干；限流同时也是自保，触发封禁或人机验证，任务照样停摆。中文语境里这些不是礼貌性建议，爬虫合规是硬约束，计算机使用只是操作方式变了，要守的规矩一条没变。

五百个 SKU、每个平均五次动作、每次动作后再观察一次，要是每次观察都带一张截屏，一个任务下来就是两千多张图要进上下文。按 16.1 讲的图像 token 计费方式，成本在开工之前就能估出量级。量级虽然大，计算机使用这条路还是走得通的，只是得按任务粒度先把成本估清再开跑。配合小模型分工和按需截屏，数字能压下一截；实在压不下来的场景，退回人力或者推动对方开接口，反而更体面。

本章小结

• 16.1 多模态 API。图像理解把图片直接放进消息，content 换成数组，text 块与 image_url 块并排；给图三法，URL、base64 data URL 和文件 ID 引用。图片按 token 计费，OpenAI 按 detail 档位（low 固定低价、high 切 512 像素块加价、gpt-5.4 起 original 档数 32 像素补丁），档位选错成本差一个数量级；中文厂商公式多不公开，用 usage.image_tokens 实测。图像生成走独立生成接口，文本进、图片出；来源可靠性在生成时埋入（水印或 C2PA 元数据），事后检测不可靠。
• 16.2 实时语音。级联五段串行延迟超一秒，实时语音换 WebSocket 全双工，会话状态挂在连接上；轮次由 VAD 判定；打断的链条是停播、清队列、中止生成，回声消除用浏览器 echoCancellation；鉴权走后端代签短时效令牌，主密钥不进前端；测试分三层，文本模式、预录音频和 LLM 扮客户。
• 16.3 计算机使用。三条表示路线各有代价，文本省 token、定位准，但桌面与移动应用够不着；截屏全覆盖但费 token、只能靠坐标定位；混合效果最好、工程量翻倍。观察是动作的一部分，动作成没成要看新界面。显式规划适合静态界面（调用次数缩到头尾几次），隐式规划适合动态界面，判据是界面会不会在预料之外变样。部署前提是最小权限虚拟机或容器加敏感动作人工确认。白底白字之外，指令还能藏进图片像素（视觉提示注入），截屏路线看得见、DOM 扫描碰不着，VPI-Bench 测得计算机使用类误导率最高过半、浏览器类到过百分之百，对策是截图来源收窄、二次检查加人工确认。
• 延伸方向还有世界模型（world model），让模型从大量视频学物理规律，在内部表征里先预演再执行（Meta 的 V-JEPA 2 走得靠前），训练昂贵、真实环境难泛化、误差随时间累积，眼下仍是实验性；物理 AI 把动作接到执行器与传感器，环境 AI 常驻后台主动感知，两者都在早期。
• 三节合起来看，回路没变，变的是两头，观察端原先只有文字，现在加进图像与音频；行动端原先只有 API 调用，现在伸到鼠标键盘。

参考资料

• OpenAI 官方文档 Images and vision（图像输入三形态、detail 档位、单请求 1500 张与 512MB 上限、gpt-4o 与 gpt-4.1 的图像 token 计法、gpt-5.4 起的 original 档），https://developers.openai.com/api/docs/guides/images-vision ，核实于 2026-08（2026-08-30 复核仍一致）。
• 阿里云百炼文档《通过 OpenAI 接口调用通义千问 VL 模型》（qwen3-vl-plus 与 qwen-vl-plus、业务空间端点形态、多图示例、DASHSCOPE_API_KEY），https://help.aliyun.com/zh/model-studio/qwen-vl-compatible-with-openai ，核实于 2026-08。
• Kimi 开放平台文档《配置 Kimi 视觉模型》（图片与视频输入，base64、URL、文件上传、多图对话），https://platform.kimi.com/docs/guide/use-kimi-vision-model ，核实于 2026-08。
• 火山方舟文档《图片理解》与《多模态理解》（豆包视觉理解系列，图片、视频、文档输入），https://www.volcengine.com/docs/82379/1362931 、https://www.volcengine.com/docs/82379/1958521 ，核实于 2026-08；火山方舟图片生成 API（豆包文生图，doubao-seedream 系列），https://docs.volcengine.com/docs/82379/1541523 ，核实于 2026-08-29。
• 智谱开放平台模型文档（GLM 视觉系列，图像、视频、文档理解与 GUI 分析），https://docs.bigmodel.cn/cn/guide/start/model-overview ，核实于 2026-08。
• OpenAI 官方文档 Image generation（gpt-image-2、images.generate 调用形态、b64_json 返回），https://developers.openai.com/api/docs/guides/image-generation ，核实于 2026-08。
• 阿里云百炼文档《万相 图像生成与编辑 API 参考》（通义万相文生图模型 wan2.6-t2i），https://help.aliyun.com/zh/model-studio/wan-image-generation-api-reference ，核实于 2026-08。
• Google AI 官方文档 Live API（WebSocket 双向流，音频、视频、文本并发输入，生产环境推荐临时令牌替代标准 API key）与 Live API Tool use（会话内声明函数、send_tool_response 回填、非阻塞调用），https://ai.google.dev/gemini-api/docs/live-api 、https://ai.google.dev/gemini-api/docs/live-api/tools ，核实于 2026-08。
• OpenAI 官方文档 Realtime and audio（realtime session 长连接，gpt-realtime 系列，/v1/realtime/client_secrets 后端签发临时凭证）与 Realtime conversations 的 Function calling 一节（session.tools 声明、call_id 回填），https://developers.openai.com/api/docs/guides/realtime 、https://developers.openai.com/api/docs/guides/realtime-conversations#function-calling ，核实于 2026-08。
• OpenAI 官方文档 Realtime API with WebRTC 与 Realtime API with WebSocket（Realtime 双传输并存：从浏览器、移动设备这类客户端直连，官方推荐用 WebRTC、性能更稳；服务端对服务端的应用用 WebSocket），https://developers.openai.com/api/docs/guides/realtime-webrtc 、https://developers.openai.com/api/docs/guides/realtime-websocket ，核实于 2026-09。
• 火山引擎文档《端到端实时语音大模型 API 接入》与《端到端实时语音 全双工版本》（豆包实时语音，WebSocket 接入与全双工版本），https://www.volcengine.com/docs/6561/1594356 、https://www.volcengine.com/docs/6561/2549778 ，核实于 2026-08。
• 阿里云百炼文档《实时（Qwen-Omni-Realtime）》（流式音频与图像帧输入的实时音视频对话），https://help.aliyun.com/zh/model-studio/realtime ，核实于 2026-08。
• MDN Web Docs，MediaTrackConstraints.echoCancellation（浏览器回声消除约束），https://developer.mozilla.org/en-US/docs/Web/API/MediaTrackConstraints/echoCancellation ，核实于 2026-08。
• Anthropic 官方文档 Computer use tool（稳定工具集 computer_toolset_20260801、17 个成员工具、无需 beta 头、截屏以图像块回填 tool_result、最小权限虚拟机建议），https://platform.claude.com/docs/en/agents-and-tools/tool-use/computer-use-tool ，核实于 2026-08。
• 字节跳动团队《UI-TARS: Pioneering Automated GUI Interaction with Native Agents》（2025，纯截图输入的 GUI 智能体模型），https://arxiv.org/abs/2501.12326 ，核实于 2026-08。
• Apple 新闻稿 Apple Launches iPhone 4S, iOS 5, iCloud（2011-10-04，Siri 随 iPhone 4S 首次亮相），https://www.apple.com/newsroom/2011/10/04Apple-Launches-iPhone-4S-iOS-5-iCloud/ ，核实于 2026-08-29。
• 《Multimodal, Real-Time AI Agent Systems》第 2、3 章（第一代助手 intent 与 slot 分析、WebSocket 双工架构、VAD 与打断事件、回声消除、每秒抽帧与帧率权衡）。见 txt-ref-zh/multimodal-realtime-agents/。
• Victor Dibia《Designing Multi-Agent Systems》（2025）第 5 章（计算机使用智能体三组件、三种界面表示与对比、六大挑战、观察回路、成本管理建议、UI-TARS 结果转述；5.7.2 企业安全盲区：EDR/DLP 难以区分智能体操作、浏览器检测与响应 BDR）。见 txt-ref-zh/designing-multi-agent-systems/。
• 《Agentic AI Bible》第 31 章（项目实战：语音智能体——流水线链路可加输入护栏、端到端模型只能做输出护栏；文本模式、预录音频、LLM 扮客户的语音测试三法）。见 txt-ref-zh/agentic-ai-bible/。
• 《Breaking the Model Context Protocol》第 10 章（WebMCP：让网站把功能声明为工具的网页标准提案，命令式 JavaScript 工具注册与声明式表单标注、AbortSignal 注销清理、工具跑在用户已登录的浏览器标签页里）。见 txt-ref-zh/breaking-the-mcp/。
• W3C Web Machine Learning Community Group：WebMCP 规范页（社区组孵化报告，非 W3C 标准；把 JS 函数与 HTML 表单暴露为 AI 可调用工具），https://webmachinelearning.github.io/webmcp ，核实于 2026-09-01。
• Max Gfeller《Building Agentic Applications with CrewAI and MCP》（Manning MEAP）第 5 章（嵌入式多模态检索：生成式与嵌入式两路；商品目录以标题、描述、商品图联合嵌入成单个向量，价格与类目放元数据；嵌入模型名快变，未入正文），见 txt/crewai-mcp.txt（英文原文，第 5 章，行 3756-4012）。
• Victor Dibia《Designing Multi-Agent Systems》（2025）第 5 章（动作序列的显式与隐式规划：静态可预期界面先出完整序列省模型调用、动态界面逐步依状态迭代；生产清单：尊重 robots 与服务条款、限流防压垮对方与防封禁、无头模式降资源开销）。见 txt-ref-zh/designing-multi-agent-systems/。
• 《Designing AI Interfaces》（Louise Macfadyen，O'Reilly 2026）第 5 章（水印与检测：生成时调概率嵌统计水印、C2PA 内容来源元数据、事后检测不可靠——厂商自家文本分类器因准确率不足下线、水印仅埋设方自证有效）。见 txt/designing-ai-interfaces.txt（英文原文）。
• 《The Bible of Agentic AI Systems》（Stefanos Drakos，自出版 2026）第 31 章（SIP 集成：经 SIP 服务商把电话音频接到实时接口的 WebSocket，需要时交接给流水线或人工）、第 15 章（语音内多智能体交接无缝，用户察觉不到切换）。见 txt-ref-zh/agentic-ai-bible/。
• 《Building Multimodal Generative AI and Agentic Applications》（Indrajit Kar，BPB 2026 中译）第 16 章（GenAI 式 OCR 三法：独立引擎包装进流水线、原生 OCR 基础模型、为 OCR 微调多模态 LLM 的取舍谱系）。见 txt-ref-zh/building-multimodal-agentic/。
• 《Claude Code: The Definitive Guide to Agentic Development》（独立出版，2026）第 5 章（三层分工省 token：AI 管构思、界面管展示、无代码编辑管微调，token 只花在创建阶段）。见 txt-ref-zh/claude-code-definitive/。
• 《Agentic AI For Dummies》（Pam Baker，Wiley 2026）第 10 章（世界模型：内部环境表征支持“做了会怎样”的预演，V-JEPA 2 从视频学运动、因果与空间关系；训练昂贵、难泛化、不透明、本质上不完整等局限）。见 txt/agentic-ai-for-dummies.txt（英文原文）。
• 《Building and Distributing Agentic AI Solutions》（Julian Soh 等，Apress 2026）第 4 章（物理 AI：动作翻译到执行器与物理输入输出；环境 AI：常驻后台、靠传感器主动评估环境）。见 txt-ref-zh/building-distributing-agentic-ai/。
• Cao 等《VPI-Bench: Visual Prompt Injection Attacks for Computer-Use Agents》（2025-03 提交 arXiv，ICLR 2026；306 个测试场景，像素层藏指令的攻击让截屏路线智能体照做而 DOM 扫描不可见，计算机使用智能体最高 51% 被误导、浏览器使用智能体最高 100%），https://arxiv.org/abs/2506.04619 ，核实于 2026-10-07。