让大模型操作浏览器这件事，业界已经探索了相当长的时间。早期方案大多依赖截图加视觉模型识别页面内容，再用坐标点击的方式完成任务，这种方式在简单页面上勉强可用，一旦遇到结构复杂的动态网页，误判率和失败率就会明显上升。根本原因在于，截图只是网页渲染后的像素呈现，丢掉了DOM结构、元素语义、事件绑定这些真正有价值的底层信息。阿里开源的Page Agent项目正是针对这个痛点，它不走纯视觉路线，而是把网页的结构化信息直接提炼出来交给大模型，让模型像读一份接口文档一样理解网页。
一、为什么视觉方案不够用：网页理解的本质差异
目前主流的Web Agent方案可以粗略分为两类：一类以视觉为核心，模型输入是页面截图或DOM渲染后的图像；另一类以结构化数据为核心，模型输入是经过处理的DOM信息。两类方案的差异不只是输入形式，而是决定了模型对网页理解的天花板。
视觉方案的第一问题是分辨率与上下文长度之间的矛盾。一个中等复杂度的电商页面，截图分辨率太低会导致文字识别错误，分辨率太高又会消耗大量视觉token，成本迅速攀升。更麻烦的是动态加载内容：下拉刷新、悬浮菜单、懒加载图片，这些状态在截图瞬间可能根本没有渲染出来，模型自然无从判断。
第二个问题是交互语义的丢失。一个按钮长什么样，截图能告诉你；但这个按钮绑定了什么事件、点击后是弹窗还是跳转、是否处于禁用状态，这些信息只存在于DOM和JavaScript运行时中。纯视觉方案需要模型去猜，猜错了整个任务链路就断了。
Page Agent选择结构化路线，核心主张是：网页本身就是一份结构化文档，与其让模型从像素里反推结构，不如直接把结构喂给它。这个思路与早期一些把整棵DOM树塞给模型的做法不同，它做了大量的信息压缩与筛选，避免上下文爆炸。
二、Page Agent的核心设计：DOM提取与语义化压缩
Page Agent的整体流程可以概括为三步：注入脚本提取可交互元素、对元素进行语义化标注、将结果组装成模型友好的上下文。它在浏览器端执行一段注入脚本，遍历DOM树，过滤掉纯展示性的节点，保留可交互元素，例如输入框、按钮、链接、下拉选择器等，并为每个元素分配一个唯一的索引标识。
// Page Agent 提取元素后的结构示意
{
"url": "https://www.ipipp.com/search",
"title": "商品搜索",
"interactive_elements": [
{
"index": 1,
"tag": "input",
"role": "searchbox",
"placeholder": "输入商品名称",
"value": "",
"visible": true
},
{
"index": 2,
"tag": "button",
"text": "搜索",
"disabled": false,
"visible": true
}
]
}注意这里的压缩策略。如果把整棵DOM树原样输出，一个页面的token量轻松超过几万，绝大多数模型都会吃不消。Page Agent的做法是只保留与任务执行相关的属性，比如元素标签、可访问性角色、可见文本、禁用状态、表单值等，同时合并语义等价的节点，剔除被遮挡或不可见的元素。经过这层处理，一个复杂页面通常能压缩到几百到几千token，完全可以放进常规模型的上下文窗口。
另一个值得关注的细节是操作指令的标准化。模型决策后输出的不是坐标，而是类似click(2)、fill(1, "手机壳")这样的结构化动作，其中数字对应用户侧的元素索引。这种方式天然规避了视觉方案中坐标漂移、分辨率适配等一系列问题，执行层面由Page Agent的运行时负责将动作映射回真实的DOM事件。
三、快速上手：接入主流大模型跑通第一个任务
Page Agent以开源项目形式发布，支持通过Python SDK调用，也提供了命令行工具便于快速验证。下面演示一个基础用法，接入OpenAI兼容接口，让Agent完成一次搜索任务。
from page_agent import Agent, BrowserConfig
# 配置浏览器与大模型接口
config = BrowserConfig(headless=False)
agent = Agent(
browser_config=config,
llm_provider="openai",
model="gpt-4o",
api_key="sk-xxxx"
)
# 描述任务目标，Agent 自主规划并执行操作
result = agent.run(
task="打开搜索页，输入关键词笔记本支架，点击搜索按钮并汇报结果数量"
)
print(result.summary)这段代码背后发生的事情值得拆解一下。Agent启动后会先导航到目标页面，注入提取脚本拿到结构化快照，把快照连同任务描述、历史动作一起组装成提示词发给大模型。模型返回下一步动作指令，运行时执行后再获取新的页面快照，如此循环直到模型判断任务完成。整个过程形成了经典的观察、思考、行动闭环。
如果你使用的是国产大模型，比如通义千问，只需修改llm_provider和model参数，配合OpenAI兼容的接入地址即可。由于输入是纯文本结构化信息，对模型的多模态能力没有硬性要求，即便是纯文本模型也能驱动，这在一定程度上降低了使用成本。需要注意，模型的选择对成功率影响很大，结构化输入降低了理解门槛，但多步规划能力仍然依赖模型自身的推理水平，建议优先选用推理能力较强的型号。
四、实战中的注意事项与适用场景
结构化方案并非万能，实际落地时有几个坑需要提前了解。首先是动态渲染页面的时机问题：如果页面采用大量异步加载，提取快照的瞬间内容可能尚未就绪。Page Agent内置了等待策略，会检测网络空闲和DOM稳定状态，但对极端场景仍建议在任务描述中明确步骤顺序，或者通过配置延长等待时间。
其次是iframe与Shadow DOM的处理。这两类结构在不少后台管理系统中非常常见，普通的选择器往往拿不到内部元素。Page Agent的提取脚本对常见情况做了穿透处理，但对于自定义程度较高的Shadow DOM组件，可能需要结合具体框架调整注入逻辑。遇到元素提取不全的情况，优先排查这两点。
从适用场景来看，Page Agent在以下几类任务中表现比较突出：一是自动化测试脚本生成，因为结构化上下文天然适合生成稳定的选择器；二是信息采集与监控，尤其是需要多步交互才能触达的深层数据；三是作为通用Agent框架的浏览器执行底座，与规划层解耦后可以灵活组合。对于视觉布局强相关的任务，比如判断页面美观度、对比设计稿差异，结构化方案就力不从心了，这类需求仍然要靠视觉模型补充。
总体来看，Page Agent代表了一种务实的工程路线：不追求让模型模拟人类看网页，而是把网页最本质的结构信息以最高效的方式交给模型。对于正在构建Web Agent或者被网页自动化稳定性困扰的团队来说，这是一个值得深入研究并在实际项目中验证的开源选择。
Page Agent大模型网页自动化修改时间：2026-09-03 13:51:13