企业官网建设流程全解析

1. 浏览器Agent的现状与Jev Ultrafast的切入点

1.1 为什么浏览器Agent一直"看着聪明、用着笨"

做浏览器自动化的人都有一个共同感受：演示视频里行云流水，真到自己跑的时候处处卡壳。点错按钮、找不到元素、页面一刷新就全盘重来，这些问题的根源其实不在模型本身，而在于动作空间的组织方式。

传统浏览器Agent的做法是：把当前页面上所有可交互元素（按钮、链接、输入框）全部提取出来，编号成一个列表，然后让模型从这个列表里选一个。页面简单的时候没问题，但一旦遇到电商、OTA、后台管理系统这类复杂页面，可交互元素动辄几百个，模型的注意力被严重稀释，选错的概率直线上升。

更麻烦的是，很多操作是有先后依赖的。比如订机票，你得先选出发地，再选目的地，再选日期，再点搜索——每一步都会改变页面的结构。传统Agent每一步都要重新扫描全页面，既慢又容易迷失。

Jev Ultrafast这个项目标题里提到的"动态索引动作空间"，本质上就是在解决这个问题：不是把所有动作一次性摊开给模型看，而是根据当前所处的任务阶段，动态地筛选出真正相关的动作子集。

1.2 动态索引到底"动态"在哪里

我理解这个机制的核心在于两层：

第一层是任务阶段感知。Agent知道自己现在处于"选出发地"还是"选日期"还是"确认订单"阶段，每个阶段只暴露与之相关的动作。这就像你填一张纸质表格，眼睛只会聚焦在当前要填的那一栏，而不是同时盯着整张表的所有格子。

第二层是页面变化追踪。每次操作后页面DOM发生变化，动态索引会增量更新动作空间，而不是全量重建。这一点对速度的影响极大——全量扫描一个复杂页面可能需要几百毫秒到几秒，而增量更新可能只需要几十毫秒。

标题里"7.1秒完成机票预订"这个数字，如果放在传统方案下，光是页面扫描和动作选择的时间可能就要十几秒甚至更久。7.1秒意味着整个流程——打开页面、填写出发到达、选日期、搜索、选航班、确认——全部走完，平均每个步骤不到1.5秒。这个速度在浏览器Agent领域确实算得上"Ultrafast"。

1.3 机票预订这个场景为什么是块试金石

选择机票预订作为benchmark场景非常聪明。这个场景有几个特点：

• 多步骤强依赖：出发地→目的地→日期→搜索→选航班→填乘客信息→支付，每一步都依赖前一步的结果
• 动态内容多：航班列表是异步加载的，价格会变，余票状态会变
• 表单交互复杂：有输入框、下拉选择、日历控件、单选按钮等多种控件类型
• 容错率低：选错日期或机场，整个任务就失败了

能在这个场景下做到7.1秒，说明动态索引机制在动作筛选和页面追踪上都做得相当扎实。下面我会从技术实现的角度，把这个方案拆开来讲。

2. 动态索引动作空间的核心设计拆解

2.1 动作空间的层级化组织

传统方案把所有可交互元素平铺成一个列表，这是最直接但也最低效的做法。动态索引的第一步改进，是把动作空间层级化。

具体来说，页面上的动作不是孤立存在的，它们天然属于不同的功能区域。以机票预订页面为例：

Agent在任一时刻只需要关注当前层级和下一个可能层级的动作。这就把每次决策的候选动作从几百个压缩到了十几个甚至几个。

注意：层级划分不是写死的，而是根据页面语义结构动态推断的。同一个网站在不同状态下，层级划分可能不同。

2.2 动作相关性评分机制

光有层级还不够，同一层级内也可能有多个动作。动态索引的第二步是给每个动作打一个相关性分数，只保留分数最高的Top-K个动作给模型选择。

相关性分数怎么算？根据我的经验，通常会综合考虑这几个因素：

• 任务阶段匹配度：当前处于"选日期"阶段，那么日历控件相关的动作得分高，搜索按钮得分低
• 视觉显著性：页面上视觉突出的元素（大按钮、高亮区域）得分更高
• 历史成功率：过去在类似页面状态下选过这个动作且成功的，得分加成
• 元素稳定性：ID稳定、不易变化的元素得分更高，避免选到广告位或临时弹窗

这个评分机制是动态索引的灵魂。它让Agent在每一步都聚焦在"最该做的事"上，而不是被无关元素干扰。

2.3 增量式DOM追踪的实现思路

页面每次变化都全量重新解析DOM，这是传统方案慢的另一个原因。动态索引采用增量追踪：只监听与当前任务相关的DOM子树的变化。

实现上通常会用到MutationObserver这类浏览器原生API，但关键在于监听范围的控制。如果监听整个document，页面上的广告轮播、倒计时、消息推送都会触发回调，造成大量无效更新。

我的做法是：根据当前任务阶段，动态设置监听根节点。比如在"选日期"阶段，只监听日历组件的容器节点；在"选航班"阶段，只监听航班列表的容器节点。这样每次DOM变化的处理量能降低一到两个数量级。

2.4 动作执行与反馈闭环

动态索引不是一次性的，而是一个闭环：选择动作→执行→观察结果→更新动作空间→选择下一个动作。

这个闭环里最关键的是结果验证。Agent执行一个动作后，需要确认这个动作是否真的生效了。比如点了"搜索"按钮，需要确认航班列表是否真的加载出来了；选了日期，需要确认日期输入框的值是否真的变了。

如果验证失败，Agent需要能够回退并重试。动态索引机制下，回退的成本很低，因为动作空间是动态维护的，回退后只需要恢复到上一个状态的动作子集即可。

3. 从零搭建一个动态索引浏览器Agent的实操路径

3.1 环境准备与基础工具选型

要复现这个方案，你需要准备以下环境：

• 浏览器自动化框架：Playwright或Puppeteer。我推荐Playwright，因为它对多标签页、iframe、网络请求拦截的支持更完善，而且自带代码生成器，调试方便。
• 页面解析库：不需要额外的HTML解析库，直接用浏览器原生的DOM API就够了。如果需要更复杂的元素定位，可以加上XPath或CSS选择器的封装。
• 模型接口：任何支持函数调用（Function Calling）的大模型都可以。关键是要能把动作空间以结构化格式传给模型，并让模型返回选择的动作ID。
• 运行时：Node.js 18+或Python 3.10+。两个生态都有成熟的Playwright绑定。

安装命令示例：

# Node.js环境 npm init -y npm install playwright npx playwright install chromium # Python环境 pip install playwright playwright install chromium

提示：开发阶段建议用chromium的headless模式，速度快；调试阶段切换到headed模式，能看到页面实际操作过程，排查问题效率高很多。

3.2 页面动作提取器的编写

动作提取器是整个系统的基础。它的任务是从当前页面中提取出所有可交互元素，并给每个元素生成一个结构化的动作描述。

核心逻辑如下：

// 动作提取器核心逻辑（Node.js + Playwright） async function extractActions(page, taskPhase) { const actions = await page.evaluate((phase) => { const interactiveSelectors = [ 'button', 'a[href]', 'input', 'select', 'textarea', '[role="button"]', '[role="link"]', '[onclick]' ]; const elements = document.querySelectorAll(interactiveSelectors.join(',')); const result = []; elements.forEach((el, index) => { const rect = el.getBoundingClientRect(); // 过滤不可见元素 if (rect.width === 0 || rect.height === 0) return; if (getComputedStyle(el).visibility === 'hidden') return; result.push({ id: `action_${index}`, tag: el.tagName.toLowerCase(), text: (el.innerText || el.value || el.placeholder || '').trim().slice(0, 50), type: el.type || '', // 根据任务阶段计算相关性分数 relevance: calculateRelevance(el, phase), // 元素稳定性评分 stability: calculateStability(el) }); }); return result; }, taskPhase); // 按相关性排序，只保留Top-K return actions .sort((a, b) => (b.relevance + b.stability) - (a.relevance + a.stability)) .slice(0, 15); }

这段代码的关键点在于过滤和排序。过滤掉不可见元素能砍掉一半以上的噪音；按相关性排序后只取Top-15，进一步压缩动作空间。

3.3 任务阶段的状态机设计

动态索引的核心是"知道现在处于什么阶段"。这需要一个状态机来管理任务流程。

以机票预订为例，状态机可以这样设计：

INIT → SELECT_ORIGIN → SELECT_DEST → SELECT_DATE → SEARCHING → SELECT_FLIGHT → FILL_PASSENGER → CONFIRM → PAYMENT → DONE

每个状态对应一组允许的动作类型。比如在SELECT_ORIGIN状态下，只允许"输入文本"和"选择下拉项"两类动作；在SEARCHING状态下，只允许"等待"和"重试"两类动作。

状态转移的触发条件也很关键。通常有两种触发方式：

• 动作触发：Agent执行了某个动作后，根据动作类型和结果判断是否进入下一状态
• 页面触发：页面出现了某个标志性元素（如航班列表容器出现），自动进入下一状态

我个人的经验是两者结合最稳。动作触发作为主逻辑，页面触发作为兜底。比如Agent点了搜索按钮，但页面没反应，这时候页面触发机制可以检测到"航班列表未出现"，让Agent重试或报错。

3.4 模型交互的Prompt设计

给模型的Prompt不需要很长，但必须结构化。我的模板大致如下：

你是一个浏览器操作助手。当前任务：预订从北京到上海的机票。 当前阶段：选择出发城市。 可用动作： [1] 输入文本到"出发地"输入框 (相关性: 0.95) [2] 点击"交换出发到达"按钮 (相关性: 0.3) [3] 点击"搜索"按钮 (相关性: 0.1) ... 请返回你要执行的动作编号和参数，格式为JSON： {"action_id": 1, "params": {"text": "北京"}}

这个Prompt有几个讲究：

• 任务描述要具体：不要只说"订机票"，要说清楚出发地、目的地、日期等已知信息
• 动作描述要带上下文：不要只说"输入框"，要说"出发地输入框"
• 相关性分数要展示：让模型知道哪些动作更相关，引导它做正确选择
• 返回格式要严格：JSON格式便于程序解析，减少解析错误

3.5 完整流程的串联与计时

把上面几个模块串起来，主循环大致是这样：

async function runTask(page, task) { const startTime = Date.now(); let state = 'INIT'; let maxSteps = 30; while (state !== 'DONE' && maxSteps-- > 0) { // 1. 提取当前动作空间 const actions = await extractActions(page, state); // 2. 调用模型选择动作 const decision = await callModel(task, state, actions); // 3. 执行动作 const result = await executeAction(page, decision); // 4. 验证结果并更新状态 state = await verifyAndTransition(page, state, decision, result); // 5. 等待页面稳定 await page.waitForLoadState('networkidle', { timeout: 3000 }); } const elapsed = Date.now() - startTime; console.log(`任务完成，耗时 ${elapsed}ms`); return state === 'DONE'; }

7.1秒完成机票预订，意味着这个循环平均执行了8-10步，每步耗时约700-900毫秒。这个时间主要花在模型推理和页面等待上。要压缩时间，可以从两方面入手：一是减少每步的模型推理时间（用更小的模型或缓存常见决策），二是减少页面等待时间（用更精准的等待条件代替固定的networkidle）。

4. 实操中踩过的坑与排查技巧

4.1 动作空间爆炸的三种典型场景

即使做了动态索引，有些场景下动作空间还是会爆炸。我遇到过最多的三种：

第一种是日历控件。一个日期选择器可能包含几十个可点击的日期格子，加上月份切换、年份切换，轻松上百个动作。我的处理方式是：把日历控件当作一个复合动作，先让模型选择"设置日期"，然后由程序内部处理具体的日期点击逻辑，不把每个日期格子暴露给模型。

第二种是长列表。航班列表、商品列表动辄几十条，每条又有多个可点击区域。处理方式是分页或虚拟滚动，每次只暴露当前视口内的列表项，并且只暴露每项的主要操作（如"选择"按钮），不暴露次要操作。

第三种是嵌套菜单。有些网站的导航是多级下拉菜单，鼠标悬停才会展开。这种场景下，动作空间需要按需展开：先暴露一级菜单项，模型选择后再展开对应的二级菜单。

4.2 页面异步加载导致的"动作失效"

这是最常见的失败原因：Agent提取了动作空间，模型选了某个动作，但执行的时候页面已经变了，元素找不到了。

排查这类问题的关键是加日志。每次提取动作空间时，记录下每个动作对应的元素选择器和当时的页面状态；执行动作时，如果元素找不到，对比两次的页面状态差异。

解决方案有三个层次：

• 短期方案：执行动作前重新定位元素，用文本内容或相对位置定位，而不是依赖可能变化的ID
• 中期方案：在动作空间提取时给每个动作附加一个"有效期"，超过一定时间未执行就重新提取
• 长期方案：用MutationObserver监听关键区域的变化，一旦变化就主动刷新动作空间

4.3 模型选错动作的纠正机制

模型不是万能的，偶尔会选错动作。比如在"选日期"阶段选了"搜索"按钮。这时候需要有一个纠正机制。

我的做法是给每个状态定义一个动作白名单。模型返回的动作如果不在白名单里，直接拒绝并重新请求。同时记录这次错误选择，如果同一个状态下连续出错，就降低相关动作的分数或调整Prompt。

下面是一个常见问题速查表：

4.4 速度优化的几个实用技巧

7.1秒的成绩不是靠单一优化达成的，而是多个小优化的叠加。我实测有效的几个：

• 预加载模型：模型冷启动可能要几秒，提前加载好可以省掉这部分时间
• 并行提取：动作提取和页面等待可以并行，不用等页面完全加载完再提取
• 缓存常见决策：对于"输入出发地"这类确定性高的动作，可以直接执行，不用每次都问模型
• 精简Prompt：Prompt越短，模型推理越快。把不必要的历史信息砍掉，只保留当前状态和动作列表
• 用流式输出：如果模型支持流式输出，可以在模型还在生成的时候就解析出动作ID，提前开始执行

注意：速度优化要在准确率达标的前提下进行。我见过太多为了追求速度而牺牲准确率的案例，最后Agent看起来很快，但任务成功率惨不忍睹。建议先保证90%以上的成功率，再逐步优化速度。

5. 动态索引方案的适用边界与扩展方向

5.1 什么场景适合用动态索引

动态索引不是万能的，它最适合流程相对固定、页面结构有规律的任务。机票预订、酒店预订、表单填写、后台数据录入，这些都属于典型适用场景。

反过来，开放式探索任务就不太适合。比如"帮我在这个网站上找到最便宜的商品"，这种任务没有明确的状态机，动作空间无法有效收敛。这类任务更适合用传统的全量动作空间方案，或者结合搜索策略。

5.2 从机票预订扩展到其他场景

机票预订的状态机可以抽象成一个通用模板：搜索→筛选→选择→填写→确认。这个模板可以套用到很多场景：

• 酒店预订：搜索目的地和日期→筛选酒店→选择房型→填写入住人→确认
• 电商购物：搜索商品→筛选条件→选择SKU→填写地址→确认订单
• 后台录入：搜索记录→选择记录→编辑字段→保存→确认

每个场景只需要替换状态机的具体状态和每个状态下的动作白名单，核心的动态索引机制可以复用。

5.3 动态索引与视觉方案的结合

目前这个方案主要基于DOM结构。但有些页面（如Canvas渲染的图表、图片形式的按钮）没有可用的DOM结构，这时候就需要视觉方案来补充。

我的思路是：DOM优先，视觉兜底。先用DOM提取动作空间，如果某个区域没有可交互的DOM元素但视觉上有按钮，就用视觉模型识别出按钮位置，生成一个"虚拟动作"加入动作空间。这样既保留了DOM方案的速度优势，又覆盖了视觉场景。

5.4 多标签页与iframe的处理

实际任务中经常遇到多标签页和iframe。比如点击某个链接后新开了一个标签页，或者支付页面嵌在iframe里。

动态索引方案需要能够跨上下文管理动作空间。我的做法是维护一个上下文栈：主页面是一个上下文，每个iframe是一个子上下文，每个标签页是一个独立上下文。动作提取时，从当前活跃上下文提取；上下文切换时，保存当前状态并加载目标上下文的状态。

这部分实现起来比较复杂，但一旦做好，Agent的适用范围会大大扩展。

5.5 错误恢复与断点续跑

长流程任务最怕中途失败。动态索引方案因为维护了状态机，天然支持断点续跑：记录当前状态和已完成的操作，失败后从断点恢复，而不是从头再来。

实现上，每次状态转移时把状态和关键数据持久化到本地（如JSON文件或SQLite）。恢复时读取状态，重新提取动作空间，继续执行。这个机制在调试阶段特别有用，可以避免每次测试都从头走一遍流程。

6. 我个人的一些实操体会

做浏览器Agent这一年多，最大的感受是：慢就是快，少就是多。一开始总想着让Agent什么都能干，动作空间越大越好，结果就是什么都干不好。后来把动作空间收窄，每个阶段只给Agent看最相关的几个动作，成功率反而上去了，速度也快了。

动态索引这个思路，本质上就是把复杂度从模型侧转移到工程侧。模型不需要处理几百个动作的选择，只需要在十几个动作里做决策；页面变化的追踪不需要模型操心，由工程代码用MutationObserver处理。模型和工程各司其职，整体效率就上来了。

7.1秒这个数字，单看可能没什么感觉。但如果你自己动手搭过一个浏览器Agent，跑过机票预订这种多步骤任务，就知道这个速度意味着什么。传统方案下，光是等页面加载和模型推理，每个步骤就要两三秒，整个流程走完二三十秒是常态。7.1秒意味着整个体验从"能用"变成了"好用"。

最后分享一个小技巧：调试浏览器Agent的时候，把每一步的截图、动作空间、模型决策都存下来，按时间顺序排好。出问题的时候回看这个序列，比看日志快十倍。我现在的调试流程基本就是：跑一遍→看截图序列→定位问题步骤→针对性修复→再跑一遍。这个循环跑顺了，迭代速度会快很多。