AI 网页自动化：从脚本执行走向可恢复的智能体系统

一个可靠的执行闭环#

我把一次网页任务拆成五个阶段：

1. 观察：获取当前 URL、可见 DOM、关键控件和页面状态；
2. 理解：判断当前页面处于任务的哪个阶段；
3. 规划：只生成下一步最小动作，而不是一次生成整段操作；
4. 执行：通过浏览器驱动完成点击、输入或导航；
5. 校验：检查页面是否出现预期状态，再决定继续、重试或回退。

这个循环看起来简单，真正的工程难点在于：系统必须知道“自己刚才做了什么”，也必须知道“页面是否真的接受了这个动作”。只有动作记录，没有结果验证，自动化就很容易在错误状态上继续运行。

DOM 与视觉不是二选一#

结构化 DOM 适合精确定位输入框、按钮和表格，成本低且可解释；视觉模型更适合处理 Canvas、复杂组件和缺乏语义标记的界面。实际系统中，我更倾向于分层使用：

• 优先读取可访问性树和稳定属性；
• DOM 信息不足时，再调用视觉理解；
• 高风险操作必须回到明确的页面状态进行二次确认；
• 每次只执行一个可验证动作，减少错误扩散范围。

这种组合比“让模型看截图随意点击”更可靠，也比完全依赖 CSS 选择器更能适应页面变化。

状态机比长提示词更重要#

复杂任务不能只靠一段很长的提示词维持上下文。我会把业务流程表示为显式状态，例如 待登录、资料填写中、等待确认、已完成 和 需要人工处理。每个状态只允许有限的动作，并且定义清晰的进入条件和退出条件。

任务运行时还需要保存以下信息：

• 当前目标与已经完成的步骤；
• 最近一次页面快照和关键字段；
• 每个动作的输入、输出与耗时；
• 重试次数、异常原因和恢复路径；
• 涉及提交、删除、付款等动作时的人工确认点。

这让系统具备可观测性：一次失败不再只是“运行出错”，而是可以定位到具体页面、具体状态和具体动作。

我正在验证的方向#

目前我更关心三个指标：任务完成率、平均恢复次数和人工接管比例。模型能力决定系统能看懂多少，而状态约束、结果校验和异常恢复决定它是否真的能长期运行。

一个可用于生产的 AI 网页自动化系统，最终应该像可靠的软件服务一样工作：过程可追踪、动作可审计、异常可恢复，遇到不确定情况时能够及时停下，而不是带着错误继续执行。