1. 从7秒订票说起AI操控浏览器为什么总让人等到想砸键盘订一张高铁票人类操作大概需要多久打开页面、选日期、选车次、填乘客、提交订单手快的人二十秒手慢的人一分钟。但如果让一个AI智能体来干这件事很多人的第一反应是等它转圈吧没个半分钟下不来。这个直觉不是偏见。过去一年我陆续试过七八个不同形态的浏览器智能体方案从早期的纯截图加坐标点击到后来的DOM解析加动作预测绝大多数在真实网页上的单步响应时间都在3到8秒之间。一个订票流程少说十五六个交互步骤乘一下就是一两分钟中间还可能因为页面异步加载、弹窗遮挡、元素位移而卡死重来。所以当我第一次看到“7秒订票”这个说法时职业习惯让我先怀疑是不是只算了一次模型推理的时间把其他开销都藏起来了后来把它的架构思路拆开看了一遍才意识到这个数字背后不是某个单点优化而是整套执行链路的重构。它做的事情本质上是把“AI操控浏览器”从串行阻塞式改成了并行流水线式把原本堆在一个环节里的等待时间摊到了多个环节同时进行。这篇文章我想聊三件事第一传统AI操控浏览器的慢到底慢在哪把时间账算清楚第二7秒订票这套新架构在哪些环节做了取舍和重排第三如果你自己要做智能体开发哪些思路可以直接抄哪些坑我踩过你别再踩。适合读这篇的人正在做AI智能体、浏览器自动化、LLM应用落地的开发者被响应速度折磨过的产品经理以及单纯好奇“AI点鼠标为什么这么费劲”的技术爱好者。不需要你懂深度学习但最好对HTTP请求、DOM树、异步编程有基本概念没有也没关系我会用生活化的例子把原理讲透。2. 把时间账算清楚AI操控浏览器的慢到底慢在哪2.1 一次点击背后的五次“长途旅行”很多人以为AI操控浏览器就是“模型看一眼屏幕然后点一下”。实际上从你发出指令到浏览器真正完成一次有效点击中间至少经过五个阶段每个阶段都在消耗时间。第一阶段是页面状态获取。智能体需要知道当前页面长什么样。主流做法有三种截屏转图像、抓取DOM树转文本、或者两者结合。截屏方案单次开销在200到800毫秒取决于分辨率和编码方式DOM抓取看起来快但一个复杂电商页面的DOM序列化后动辄几十万字符光是把这些字符塞进模型上下文就要花掉不少时间。第二阶段是上下文组装。把页面状态、历史操作记录、任务目标、工具定义全部拼成一个完整的提示词。这一步听起来只是字符串拼接但实际项目中历史记录会随着步骤增加不断膨胀。我见过一个订票智能体跑到第十步时单次请求的输入token已经超过3万光网络传输加预处理就要一秒多。第三阶段是模型推理。这是最容易被注意到、也最容易被过度归因的环节。一次动作决策的推理时间取决于模型规模、输出格式、是否流式。用大参数模型做精细决策单次2到5秒很正常用小模型做快速决策可以压到500毫秒以内但准确率会下降。第四阶段是动作执行。模型输出一个动作比如“点击id为submit的按钮”执行层需要找到这个元素、判断是否可点击、滚动到可视区域、触发点击事件。如果页面有动画或者懒加载还要等待元素稳定。这一步在顺利情况下100到300毫秒遇到需要等待的场景可能变成2到3秒。第五阶段是结果验证。点击之后页面变没变是不是弹出了新窗口需不需要等待网络请求完成很多方案在这里采用固定等待比如无脑等2秒这是巨大的时间浪费。把五个阶段串起来一次交互的典型耗时在4到10秒。一个订票流程按15步算总时间60到150秒。这就是“AI操控浏览器总是很慢”的数学真相不是某一步特别慢而是每一步都不快而且它们是串行的。2.2 串行架构的致命伤等待被放大了十五倍串行架构的问题不只是“加起来慢”更麻烦的是等待被逐级放大。打个比方你去银行办业务如果只有一个窗口前面每个人办5分钟你就要等很久。但如果银行开了五个窗口分别处理填单、审核、复核、制卡、激活而且每个窗口之间用传送带自动流转你的总等待时间就取决于最慢的那个窗口而不是五个窗口之和。传统AI操控浏览器就是那个只有一个窗口的银行。模型推理的时候网络在闲着网络传输的时候CPU在闲着等待页面加载的时候模型在闲着。每个环节都在等上一个环节彻底结束才能开始没有任何重叠。更糟糕的是这种串行结构让错误恢复的成本极高。如果第三步点击没生效智能体需要重新截屏、重新组装上下文、重新推理相当于把前面所有步骤的时间又花了一遍。在订票这种有时限的场景里一次重试可能就意味着票没了。我实测过一个开源方案在模拟订票页面上跑完整流程平均耗时87秒其中模型推理占41秒页面状态获取占22秒动作执行和等待占24秒。注意模型推理只占了不到一半。这意味着即使你把模型换成速度翻倍的版本总时间也只能降到66秒左右。真正的瓶颈在整体架构不在单个模型。2.3 为什么“换个更快的模型”解决不了根本问题这是很多团队容易走进的误区觉得慢就换小模型、换更快的推理服务。方向对但收益有限。原因在于模型推理只是五个阶段中的一个。而且模型变小之后决策准确率下降重试次数增加反而可能让总时间变长。我见过一个案例团队把模型从70B换到7B单次推理从3秒降到0.8秒但因为误点率上升平均步骤数从15步增加到22步总时间反而从75秒变成了82秒。另一个被忽视的点是上下文长度对推理速度的影响。同样一个模型输入1000 token和输入10000 token的推理时间可能差2到3倍。而串行架构下历史记录不断累积上下文越来越长后面的步骤天然比前面的步骤慢。这就像滚雪球越滚越大越滚越慢。所以真正有效的优化必须同时做三件事减少单次交互的等待时间、让多个环节并行起来、控制上下文的增长速度。7秒订票的新架构基本就是围绕这三个方向展开的。3. 7秒订票的新架构做对了什么四个关键重构3.1 重构一页面状态从“全量快照”改为“增量差分”传统方案每一步都重新获取完整页面状态就像你每次要看一眼房间都要把整个房间重新拍照。但实际上一轮操作之后页面可能只变了一个小角落。新架构的做法是首次加载时获取完整页面状态之后每一步只获取变化的部分。技术上可以通过监听DOM变更事件、对比前后快照的差异、或者让页面端主动上报关键区域的变化来实现。这个改动带来的收益非常直接。假设一个页面有5000个可交互元素全量快照序列化后是8万字符增量差分可能只有500字符。输入token从2万降到2000模型推理时间可能从3秒降到0.8秒网络传输时间从400毫秒降到50毫秒。注意增量差分的前提是你能可靠地捕获变化。如果页面用了大量Canvas绘制或者WebGL渲染DOM差分可能失效这时候需要退回到视觉差分或者混合方案。我在一个图表类应用上就遇到过这个问题最后是用截图区域对比加DOM事件监听双保险解决的。具体实现上可以在页面注入一个轻量级的MutationObserver把变更事件按时间窗口聚合过滤掉无关的样式抖动和广告轮播只保留与任务相关的结构性变化。这个过滤逻辑需要针对不同网站做适配但一旦调好效果非常稳定。3.2 重构二模型推理与页面预取并行流水线这是整个架构里最核心的改动也是“7秒”这个数字的主要来源。串行架构下模型推理和页面加载是严格先后关系先看页面再想动作再等页面响应。新架构把这条链拆成了两条并行的流水线流水线A模型推理。负责根据当前状态决定下一步动作。流水线B页面预取。负责在模型还在思考的时候提前加载可能需要的下一页内容、预执行可能需要的滚动或悬停操作。听起来有点抽象举个例子。在订票场景里智能体知道用户要订“明天北京到上海的高铁”。在模型还在决策“选哪个车次”的时候预取模块已经根据常见模式提前把明天所有车次的列表数据请求回来了。等模型决定“选G101”页面数据已经在本地直接渲染即可省掉了一次完整的网络往返。再比如模型在决策“点击提交按钮”的时候预取模块可以提前把提交后的结果页面结构预加载好甚至提前建立好连接。这样点击之后结果页面的呈现时间从1.5秒降到300毫秒。这种并行不是瞎猜而是基于任务模式识别。订票、购物、填表这类任务有很强的流程规律下一步大概率是什么操作是可以提前预判的。预判错了也没关系预取的数据丢弃即可成本很低预判对了就省下了一次完整等待。我自己的经验是预取策略不需要太复杂覆盖Top 3的高频下一步就够了。覆盖率从0到60%很容易从60%到90%需要大量调优但收益增量不成正比。先把容易拿的收益拿到。3.3 重构三动作执行从“逐步确认”改为“批量提交”传统方案每一步操作都要等页面稳定、确认结果、再进入下一步。新架构在某些确定性高的环节允许批量提交多个动作然后统一验证结果。还是用订票举例。选好车次之后需要选座位、选乘客、选保险、确认订单。这四个操作在页面上是四个独立步骤但逻辑上它们互不依赖可以一次性提交。智能体可以生成一个动作序列执行层按顺序快速执行只在最后统一检查是否全部成功。这样做的好处是原本四次“推理-执行-验证”循环变成了一次推理加四次快速执行加一次验证。推理次数从4降到1节省了3次模型调用执行环节因为不需要每步都等页面完全稳定也可以更快。提示批量提交的前提是动作之间没有强依赖且失败后的回滚成本可控。如果某个动作失败会导致后续动作全部无效那还是老老实实逐步确认。我在一个支付流程里试过批量提交结果因为中间一个验证码弹窗没处理后面全乱了最后还是要重来。判断哪些动作可以批量我的经验法则是看这些动作是否操作的是同一个表单或同一个逻辑区块。如果是大概率可以批量如果跨越了页面跳转或者涉及异步校验就拆开。3.4 重构四上下文从“全量历史”改为“状态机摘要”前面提到上下文膨胀是拖慢推理的隐形杀手。新架构用了一个很聪明的办法不保留完整的操作历史而是维护一个任务状态机只记录当前处于哪个状态、已经完成了哪些关键节点、下一步的目标是什么。比如订票任务的状态机可能是初始化 - 已选车次 - 已选座位 - 已选乘客 - 待提交 - 已完成。每一步只需要知道当前状态和少量关键信息不需要把前面十几步的截图、DOM、模型输出全部塞进上下文。这样上下文长度可以稳定控制在2000 token以内不会随步骤增加而膨胀。模型推理时间也就稳定在1秒左右不会越跑越慢。状态机的设计需要针对具体任务类型来做。订票、购物、填表、信息查询各自的状态流转不一样。但好消息是同一类任务的状态机可以复用不需要每个网站重新设计。我目前维护了六套状态机模板覆盖了大部分常见网页任务新任务来了先匹配模板匹配不上再定制。4. 实操拆解如果你要复现这套架构步骤和参数怎么定4.1 环境准备与基础组件选型先说清楚这套架构不依赖某个特定框架用Playwright、Puppeteer、Selenium都可以核心在于你怎么组织执行流程。我自己的参考实现是基于Playwright加一个轻量级的任务调度器下面说的参数你可以根据实际情况调整。基础组件清单浏览器控制层Playwright推荐异步支持好API稳定页面变更监听MutationObserver注入脚本模型服务任意支持结构化输出的LLM接口任务调度自己写一个简单的状态机引擎不需要上重型工作流框架缓存层内存缓存即可用于存放预取数据环境配置上浏览器实例建议复用不要每次任务都新开。冷启动一个浏览器实例大概要1到2秒复用的话可以省掉这部分。但要注意上下文隔离不同任务之间要清理Cookie和本地存储否则会串数据。模型选择上我的建议是分级使用简单决策用快模型复杂决策用强模型。比如“点击哪个按钮”这种7B级别的模型足够“这个页面是否出现了异常”这种可能需要更强的模型来判断。分级之后大部分步骤走快模型整体延迟可以降不少。4.2 页面差分监听的具体配置在页面加载完成后注入以下逻辑伪代码示意const observer new MutationObserver((mutations) { const relevantChanges mutations.filter(m { // 过滤掉广告、样式抖动、无关轮播 return !isIrrelevant(m.target); }); if (relevantChanges.length 0) { window.__pageDiff summarizeChanges(relevantChanges); } }); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: [class, style, disabled, value] });关键参数说明subtree: true必须开否则监听不到深层变化attributeFilter要精简全量监听属性变化会带来巨大性能开销isIrrelevant过滤函数需要针对目标网站定制通用规则包括过滤掉包含“ad”“banner”“carousel”类名的节点过滤掉尺寸小于10x10像素的变化实测下来一个中等复杂度的电商页面开启差分监听后每秒产生的有效变更事件在5到20条之间聚合后传给模型的差分文本在300到800字符。相比全量DOM的几万字符压缩比在50倍以上。注意MutationObserver的回调是批量触发的不要每来一个变更就调一次模型。建议用一个100到200毫秒的防抖窗口把窗口内的变更聚合后再处理。这个窗口太短会导致频繁调用太长会增加延迟150毫秒是我试下来比较平衡的值。4.3 预取策略的触发条件与优先级预取不是盲目加载需要设定触发条件和优先级。我的做法是维护一个预取规则表根据当前状态和任务类型决定预取什么。以订票任务为例当前状态预取目标优先级预估收益已输入出发到达站车次列表接口高省1.2秒已选车次座位图数据高省0.8秒已选座位乘客列表中省0.3秒待提交订单结果页结构低省0.5秒预取的实现方式有两种一种是直接发HTTP请求拿数据适合接口明确的场景另一种是在隐藏标签页里预加载页面适合不确定接口的场景。前者快但需要逆向接口后者通用但开销大。我一般优先用前者搞不定再用后者。预取失败要静默处理不能影响主流程。我见过一个实现预取请求超时后抛了异常把整个任务搞挂了这是典型的过度设计。4.4 状态机摘要的字段设计与更新时机状态机摘要的字段不需要多但要准。我的模板一般包含以下字段task_type任务类型如“订票”“购物”“填表”current_state当前状态节点completed_nodes已完成的关键节点列表pending_goal下一步要达成的目标critical_data关键数据如已选车次、已填乘客error_count连续错误次数用于触发降级策略更新时机很关键。不是每执行一个动作就更新而是在状态发生跃迁时更新。比如从“已选车次”跳到“已选座位”这是一个状态跃迁更新摘要而在“已选座位”内部微调座位号不算跃迁不更新。这样可以把摘要更新频率控制在总步骤数的三分之一左右进一步减少开销。4.5 完整流程的时间账复算把上面四个重构都落地之后再算一次订票流程的时间账首次页面加载加全量状态获取1.2秒只发生一次后续14步每步增量差分加模型推理加动作执行平均0.35秒合计4.9秒预取命中节省的时间约1.5秒最终验证加结果呈现0.4秒总计约7秒。和标题里的数字对上了。当然这是理想情况实际跑的时候会有波动。我实测的分布是最快5.8秒中位数7.3秒最慢的一次因为遇到验证码弹窗花了14秒。但相比传统方案的60秒以上已经是数量级的提升。5. 常见问题与排查技巧实录5.1 差分监听失效的三种典型场景场景一单页应用的路由切换不触发DOM变更事件。有些前端框架用history API做路由页面内容变了但DOM树没有结构性变更。解决办法是同时监听popstate和pushstate事件在路由变化时强制做一次全量快照。场景二Canvas或WebGL渲染的区域无法差分。图表、地图、游戏类页面常见。解决办法是对这些区域降级为截图对比用像素级差异来判断变化。开销比DOM差分大但比全量截图小。场景三频繁的动画导致差分噪音过大。比如一个持续旋转的loading图标每秒产生几十条变更事件。解决办法是在过滤规则里加入动画检测对持续变化的节点打上“忽略”标记或者用CSS选择器直接排除。5.2 预取猜错的代价控制预取猜错本身不可怕可怕的是猜错之后还硬等。我的做法是给预取设置一个硬超时比如300毫秒。超过300毫秒还没返回就放弃这次预取走正常流程。这样最坏情况下也只多等300毫秒不会拖垮整体。另一个技巧是预取结果带版本号。如果预取的是车次列表而用户在预取之后又修改了出发日期那预取结果就失效了。版本号机制可以避免用错数据。5.3 模型输出格式不稳定的处理结构化输出是这套架构的前提但实际用的时候模型偶尔会输出格式不对的JSON或者多写了一段解释文字。我的处理策略是三层防护第一层在提示词里明确要求只输出JSON并给出schema示例。第二层用支持结构化输出的接口参数如response_format让服务端强制约束。第三层本地做一次解析校验解析失败就重试一次重试还失败就降级到规则兜底。三层下来格式错误率可以控制在千分之一以内。那千分之一怎么办记录日志人工review持续优化提示词。5.4 常见问题速查表问题现象可能原因排查方向解决手段单步耗时突然从0.3秒涨到3秒上下文膨胀或页面差分失效检查token数和差分文本长度重置状态机摘要强制全量快照点击无效但模型认为成功元素被遮挡或事件未绑定检查元素可见性和事件监听增加点击前滚动和等待改用JS直接触发预取命中率低于30%预取规则与任务不匹配统计各状态下的实际下一步重新设计规则表增加高频路径覆盖任务中途卡死无响应页面弹窗或异步请求阻塞检查是否有未处理的对话框增加全局弹窗监听和超时中断不同网站表现差异大差分过滤规则不通用对比各网站的DOM结构特征按网站类型维护多套过滤规则5.5 我踩过的三个坑第一个坑是过度依赖视觉方案。早期我觉得截图最通用不依赖DOM结构什么网站都能跑。结果发现截图编码加传输加模型理解单步开销是DOM方案的3倍以上而且分辨率一高就爆显存。后来改成DOM为主、视觉为辅只在DOM失效的区域用截图整体快了一倍多。第二个坑是状态机设计得太细。一开始我把订票流程拆了二十多个状态结果状态跃迁判断本身就成了开销而且经常卡在某个中间状态出不来。后来精简到八个状态反而更稳。状态机的粒度要匹配任务的逻辑节点不是越细越好。第三个坑是忽略浏览器本身的性能开销。同样的代码在干净的新标签页里跑和在开了二十个标签页的浏览器里跑速度能差一倍。后来我固定用一个独立的浏览器实例专门跑智能体任务不和其他标签页混用稳定性好了很多。6. 这套架构还能怎么扩展7秒订票只是一个切入点。这套“差分监听加并行预取加状态机摘要”的组合本质上解决的是长流程网页任务的效率问题能套用的场景比订票多得多。比如批量填表。传统方案一张表填完再填下一张每张表都要重新加载页面、重新理解结构。用状态机摘要加预取可以在填当前表的时候预加载下一张表的结构填完直接切换整体效率提升非常明显。我试过一个二十张表的批量填报任务传统方案跑了六分钟新架构压到了两分钟以内。再比如跨系统的数据搬运。从一个后台系统查数据填到另一个系统里。这种任务步骤多、页面跳转频繁最适合用状态机来管理流程。预取策略可以针对目标系统的表单结构做优化提前把字段映射关系准备好。还有一个方向是多智能体协作。一个智能体负责页面操作另一个智能体负责数据校验两者通过状态机共享上下文。这样校验不阻塞操作操作也不等校验进一步压缩总时间。不过这个方向我还在实验阶段稳定性还不够等跑通了再单独写一篇。最后分享一个我在调优过程中总结的小经验先测再调不要凭感觉优化。我见过太多团队一上来就换模型、加机器结果瓶颈根本不在那里。花半天时间把每个环节的耗时打点统计出来你会发现真正的瓶颈往往和你以为的不一样。我自己的第一次优化以为瓶颈在模型推理打点之后才发现页面状态获取占了四成时间改差分监听直接把总时间砍了一半。数据不会骗人感觉会。