浏览器自动化测评：Agent Loop对比RPA的五大关键差异
写在前面
过去半年，我主导开发了一款基于CDP的浏览器自动化CLI工具，核心目标是赋能Claude Code这类智能体，使其具备“观察页面、点击元素、输入文本”的基础交互能力。最初的架构遵循经典的智能体循环范式：截图 → 多模态模型推理 → 输出动作指令 → 执行 → 循环。然而，经过一年的深度迭代，这个循环被持续解构与精简，最终形态却意外地回归到一个更为“古典”的模式——越来越趋近于传统RPA（机器人流程自动化）的核心理念。
接下来分享的五点核心洞察，均源于这个项目的实战打磨。它们与当前主流叙事中“智能体日益自主化”的论调形成了鲜明对比，揭示了一条更为务实的工程化路径。
一、DOM 比视觉更便宜也更准
一个常见的直觉误区是：“页面是给人看的，所以让模型分析截图最符合自然交互。” 但实践验证，这个直觉并不可靠。
实际上，一行简单的 document.querySelectorAll JavaScript调用，就能在毫秒级时间内精准获取页面上所有可交互元素，并附带XPath、ARIA角色（role）、标签（label）等结构化元数据。这条基于DOM的路径，其精确度和效率远胜于“截图 → 目标检测 → OCR识别”这条冗长且易错的视觉链条。一次 Runtime.evaluate 调用耗时在毫秒级，成本几乎可忽略；而一次多模态推理则需1到3秒，且成本从几分钱起步。
因此，在我们的CLI架构中，DOM原语层承担了超过90%的交互任务。多模态视觉层仅作为后备方案（fallback），仅在处理Canvas渲染内容、Shadow DOM封装组件或滑块验证码等DOM无法直接解析的场景时才会启用。在这里，视觉回退不代表“更智能”，而意味着“成本更高、响应更慢的最终备选方案”。
二、分层 fallback，不是 multi-agent
当前业界流行“规划者（Planner）+执行者（Executor）”的双模型协作架构。我们同样进行过尝试，但最终结论是：两个大语言模型协同工作，其整体脆弱性往往高于单个模型，而非更鲁棒。原因很直接：当规划者的指令与执行者的理解出现偏差时，系统内部缺乏仲裁机制，只能依赖反复重试（retry）来碰运气，这本质上是靠消耗资源来弥补设计缺陷。
我们采用的替代方案是：一个统一的调度者（通常是外部的Claude Code智能体），配合两层特性迥异的能力——确定性的DOM原语层（零大模型调用）和多模态视觉回退层（需大模型推理）。调度逻辑被硬编码在技能（skill）文件中，其核心原则是：默认采用A方案（DOM）；仅当A方案在同一子目标上连续失败两次后，才升级到B方案（视觉）；B方案执行单步后，必须立即切换回A方案进行结果验证。
这本质上是确定性的分层回退机制，而非复杂的多智能体协作。减少一个大模型调用环节，系统的整体稳定性提升了不止两个数量级。
三、录制是一等公民，不是事后日志
初期，我们将“操作录制”视为一个可选的调试工具——文档中提及，由用户按需开启。后来意识到这是一个重大认知偏差：智能体成功运行一次任务所产生的操作序列，本身就是最具价值的可复用资产。再次执行相同任务时，你无需大模型重新决策，也无需视觉分析，直接回放这段录制好的脚本即可。
因此，我们彻底重构了设计：browser open 命令会自动开启录制，browser close 命令则自动停止录制并生成一份结构化的XML制品。录制贯穿整个自动化生命周期，无论中间的具体操作是依赖DOM还是触发了视觉回退。这一设计将大模型调用的成本，从“每次任务执行都必须支付”压缩为“仅在首次流程定型时需要”。
回顾来看，这正是经典RPA的核心工作模式——大模型在此仅仅扮演了录制阶段的智能辅助角色。
四、Skill 是行为契约，不是 prompt 模板
Claude Code的技能（Skill）系统有一个反直觉的高级用法：不要将其编写为“使用说明书”，而应将其定义为“行为契约”。
例如，在我编写的技能中，会包含这样的铁律：
这条规则并非写给我自己，而是写给未来那些冷启动的、缺乏任何上下文的智能体。当同一个智能体再次执行任务时，它无法看到历史对话，只能通过解析技能描述来决定行为。规则越精炼、越绝对、越包含“原因（why）”和“反面示例（counter-example）”，就越能抵御大模型固有的随机性。
如果将技能当作业务文档来撰写，你会得到一堆模糊的、“这样也行、那样也可”的描述；而将其视为契约来制定——明确规定哪些必须执行、哪些严格禁止、违反即视为错误——这样的技能才真正具备工程化价值。
五、不可逆操作要在 CLI 层打围栏
当智能体获得浏览器自动操作能力时，首个高风险场景必然是“它替我点击了不该点的按钮”。我们的解决方案是：将不可逆操作的风险控制，下沉到CLI工具层实现硬性约束，而非依赖提示词（prompt）进行软性规劝。
以录制生命周期管理为例：由 browser open 命令自动启动的录制，其所有权归属于 'browser' 这一核心层。即使中间某个GUI子会话意外终止，也只能停止它自身启动的录制（如果存在），外层的核心录制进程将持续运行。这意味着，即便智能体在中间步骤执行出错，整个任务的边界也被“open → close”这组操作严格界定，最终生成的录制制品始终对应一个完整、可复用的自动化片段。
技能文档中规定的“必须调用close”仅是软约束，而CLI内部实现的状态机才是硬约束。唯有软硬结合，才能有效抵御大模型偶尔的“不可预测行为”。
结语
近两年智能体循环（Agent Loop）的演化路径，本质上是一个将大语言模型从“控制流主体”逐渐收敛为“专家系统接口”的过程。其核心模式演变为：由大模型完成一次性决策，生成一套可稳定回放的操作脚本，后续所有执行均依赖此脚本。这与1990年代RPA的工作模式相比，仅差了一个“录制阶段的智能化辅助”。
这并非智能体的退化，而是工程实践在复杂现实中必然的收敛与沉淀。