Page Agent:在网页中实现自然语言操作

传统的网页自动化通常依赖固定选择器和脚本。开发者需要提前知道按钮、输入框和页面结构,然后通过代码完成点击、输入和滚动。

Page Agent 提供了另一种思路:让 Agent 直接运行在网页中,根据用户的自然语言理解当前页面,并操作真实的 DOM。

它可以做什么

用户可以输入类似这样的指令:

把筛选条件改成最近一个月,选择状态为已完成,然后导出结果。

Agent 需要先理解目标,再识别页面中对应的输入框、下拉框和按钮,按照顺序完成操作。最终用户不需要记住每个功能位于哪个菜单下面。

和传统自动化的区别

Playwright 或浏览器自动化脚本通常是确定性的:

await page.locator('#date-range').click()
await page.locator('text=最近一个月').click()
await page.locator('#export').click()

这种方式执行速度快、结果稳定,但页面结构变化后可能需要重新维护选择器。

Page Agent 更偏向目标驱动。用户告诉它要完成什么,模型根据页面内容决定下一步操作。它不一定依赖固定的 CSS 选择器,而是需要理解页面中的文本、元素和交互关系。

运行在网页中的特点

Page Agent 的一个特点是可以直接集成到网页应用里,不一定要求用户安装额外的浏览器插件或专用浏览器。

网页页面
├─ 当前 DOM 和可交互元素
├─ 用户自然语言目标
└─ Agent 执行层
↓
点击 / 输入 / 滚动

这种方式适合给已有系统增加自然语言操作入口,也适合构建后台管理、表单填写和复杂配置场景中的辅助能力。

需要解决的问题

自然语言操作虽然灵活,但执行结果不能只依赖模型“看起来理解了”。页面中可能存在相似按钮、动态加载内容和不可见元素,Agent 需要在执行前确认当前页面状态。

另外,点击和输入属于可逆操作,但删除数据、提交订单和发布内容具有外部副作用。对于这类操作,应该增加确认步骤:

识别目标 → 生成操作计划 → 执行低风险步骤
↓
高风险操作前确认

还需要考虑操作失败、页面跳转、权限不足和模型误判。一个完整的 Page Agent 不能只有“让模型点击”,还要有状态观察、错误恢复和操作审计。

适用场景

Page Agent 比较适合以下类型的应用:

  • 后台系统中的复杂筛选和批量操作
  • 表单填写和资料录入
  • 需要跨多个页面完成的流程
  • 给已有系统增加自然语言辅助入口

如果页面流程非常固定、对稳定性要求极高,传统脚本可能仍然更合适。Page Agent 的优势主要在于减少用户学习成本,让用户用目标描述代替记忆操作路径。

我觉得这类技术有意思的地方在于:网页不再只是供人操作的界面,也可以成为 Agent 观察和执行任务的环境。但要真正用于业务,还需要把权限、确认和失败恢复放在和模型能力同样重要的位置。