AI浏览器自动化：逐动作推理与录制回放方案对比

一、对比背景：为什么浏览器自动化需要讨论实现路径

在AI智能体逐步进入真实业务系统的过程中，浏览器操作是最常见的执行手段之一。无论是登录后台、抓取报表、填写表单，还是跨系统搬运数据，浏览器自动化都承担着“最后一步执行”的角色。

当自动化任务由大模型驱动时，一个容易被忽视的成本问题会迅速暴露：浏览器操作的每一步都可能触发一次模型推理。打开页面、输入账号、输入密码、点击按钮、提取数据，这些在传统脚本中只需毫秒级完成的操作，在AI智能体框架中往往被拆解为多次“推理—调用—再推理”的循环。

于是，两种实现路径逐渐分化：

• 方案A：逐动作推理——每一次浏览器操作都由大模型实时决策；
• 方案B：录制回放——首次执行由模型推理，之后将轨迹固化为脚本直接回放。

本文围绕这两类方案展开对比，重点回答：它们的差异来自哪里、各自适合什么场景、迁移时需要注意什么。

二、对象定义：两类方案分别是什么

方案A：逐动作推理

该方案将浏览器自动化视为一系列连续的决策点。模型在每一步观察当前页面状态，推理出下一个动作，再通过浏览器控制接口执行。典型流程为：

模型推理 → 调用浏览器打开
模型推理 → 调用浏览器输入
模型推理 → 调用浏览器点击
模型推理 → 调用浏览器提取

每一步操作都依赖一次模型推理，任务链路越长，推理次数越多。

方案B：录制回放

该方案将“首次执行”和“后续执行”分离。首次执行时，模型仍以推理方式控制浏览器，但系统会完整记录操作轨迹；之后将轨迹转换为可回放脚本，后续执行不再经过模型推理，直接运行脚本。

流程可概括为：

首次执行：模型推理 → 记录轨迹 → 生成脚本
后续执行：直接运行脚本

其核心理念可以概括为：录制一次，长期自动执行。

三、相同点分析

两类方案并非完全对立，它们在某些层面具有共同目标：

1. 都面向浏览器自动化执行：最终目的都是完成页面操作与数据获取；
2. 都可与大模型能力结合：方案B的首次执行同样依赖模型推理；
3. 都关注任务可重复性：差异在于对“重复”的处理方式不同；
4. 都需要处理页面不确定性：如元素定位、页面加载、弹窗干扰等。

因此，选择的关键不在于“要不要用模型”，而在于模型推理应出现在任务的哪个阶段、出现多少次。

四、核心差异分析

1. 技术架构差异

维度	方案A：逐动作推理	方案B：录制回放
控制方式	模型实时决策每一步	首次推理，后续脚本执行
依赖组件	模型服务 + 浏览器控制接口	模型服务 + 轨迹记录 + 脚本引擎
执行链路	每步都经过模型	后续执行不经过模型
系统边界	推理与执行强耦合	推理与执行可分离

方案A的架构更简单，但推理与执行高度耦合；方案B增加了轨迹记录和脚本引擎，但换来了执行阶段的轻量化。

2. 成本结构差异

方案A的主要成本来自模型推理次数。任务每天执行100次，若每次需要5步操作，则每天产生500次推理。方案B在首次执行后，后续99次可直接回放，推理次数大幅下降。

需要注意的是，方案B并非零成本，它仍需要：

• 轨迹存储与版本管理成本；
• 脚本引擎维护成本；
• 页面变化时的重新录制成本。

因此，任务重复频率越高、步骤越稳定，方案B的成本优势越明显。

3. 稳定性与效率差异

方案A每次执行都重新推理，对页面微小变化有一定适应能力，但推理延迟叠加后，整体执行时间较长。

方案B回放阶段执行速度快、延迟低，但脚本对页面结构变化较敏感。若页面元素位置、标识或流程发生改变，脚本可能失效，需要重新录制或调整。

4. 模糊判断处理差异

这是两类方案最值得关注的差异之一。浏览器自动化中存在一些无法完全脚本化的步骤，例如：

• 页面出现多个相似链接，需要选择目标；
• 需要识别验证码；
• 抓取结果需要人工确认；
• 评论文案需要模型生成。

方案A天然适合处理这类判断，因为每一步都可交给模型决策。方案B则需要在轨迹中显式标记“模糊点”，例如：

{
  "fuzzy_point": {
    "requires_judgment": true,
    "reason": "数据提取结果需确认",
    "hint": "检查数据准确性"
  }
}

开发者也可以在录制时手动标注：

await controller.click(
    "#link",
    fuzzy_reason="页面存在多个链接",
    fuzzy_hint="需要根据目标选择"
)

当轨迹导出为模型提示时，系统可自动生成待判断说明，由模型在回放阶段介入处理模糊点，其余步骤仍走脚本。这种“脚本为主、模型为辅”的混合模式，是方案B在保持低Token消耗的同时兼顾灵活性的关键设计。

5. 运维与迁移差异

方案A的运维重点在于模型服务稳定性、推理延迟和调用配额；方案B的运维重点在于脚本版本管理、页面变更监控和模糊点规则维护。

从方案A迁移到方案B，需要评估：

• 现有任务中哪些步骤是稳定的、可脚本化的；
• 哪些步骤必须保留模型判断；
• 页面结构变更频率如何；
• 是否需要建立脚本回归测试机制。

五、典型场景选择

场景	更适合的方案	原因
一次性或低频任务	方案A	录制回放收益有限
高频重复任务	方案B	回放阶段无需模型推理
页面结构频繁变化	方案A或混合模式	脚本维护成本可能较高
含验证码、人工确认环节	混合模式	模糊点交由模型处理
对执行速度要求高	方案B	脚本回放延迟更低
探索性任务	方案A	流程尚未稳定，不适合固化

六、选型建议

1. 任务重复频率高、流程稳定：可优先考虑录制回放方案，以降低长期推理成本；
2. 任务变化频繁、需要实时判断：逐动作推理更合适，避免脚本频繁失效；
3. 既有稳定步骤又有判断环节：建议采用混合模式，在轨迹中标记模糊点，由模型按需介入；
4. 团队运维能力有限：需评估脚本版本管理和页面变更监控的投入，避免回放脚本成为新的维护负担。

七、迁移与使用注意事项

• 不要一次性全量迁移：先选择重复频率高、流程稳定的任务试点；
• 建立模糊点规范：明确哪些步骤需要模型判断，避免回放阶段误执行；
• 关注页面变更：脚本回放对页面结构敏感，需配套监控与告警；
• 保留人工兜底：对涉及资金、权限或数据准确性的步骤，应设置确认环节；
• 版本化管理轨迹与脚本：便于回溯和快速恢复。

八、总结

逐动作推理与录制回放并非谁取代谁的关系，而是面向不同任务特征的两种路径。前者灵活、适应性强，但推理成本随执行次数线性增长；后者在执行阶段轻量高效，但需要额外处理脚本维护和模糊判断。

更务实的做法，是根据任务的重复频率、稳定性要求和判断复杂度，选择单一方案或混合模式。对于高频、稳定、步骤明确的浏览器自动化任务，录制回放能够显著降低Token消耗；对于探索性强、变化频繁的任务，逐动作推理仍是更稳妥的选择。理解两者的技术差异与边界，才是做出合理架构决策的前提。