阿里开源 Page Agent：让智能体直接嵌进网页里，靠读文字而不是截图操作界面
MIT 协议开源、模型无关，接入任意 OpenAI 兼容文本模型即可用，目前只能操作单个页面视图
- 阿里巴巴团队开源了 Page Agent，一个以纯 JavaScript 形式跑在网页内部的智能体库，直接读取页面的文字化结构（DOM）来理解和操作界面，不依赖截图
- 核心技术是 DOM dehydration（DOM 脱水）：把整页成千上万个节点压缩成一份只保留可交互元素的精简文本地图 FlatDomTree，普通文本模型就能精确定位元素
- 采用 MIT 协议开源，模型无关，通过任意 OpenAI 兼容 endpoint 接入，只传文本、不需要多模态模型，代码继承自 browser-use 的 DOM 处理和 prompt 逻辑
- 因为跑在网页内部，它会自动继承用户当前的登录态、cookie 和权限，不用单独写后端，也不需要无头浏览器
- 局限也很明确：安全规则写在 prompt 里而非硬约束，核心库只能操作单个页面，跨标签页要额外装一个 Chrome 插件
阿里开源了一个反常规的浏览器智能体
阿里巴巴团队最近开源了 Page Agent，一个以纯 JavaScript 形式运行在网页内部、通过读取文字化 DOM 来理解和操作界面的智能体库。
它像一个真实用户那样住在网页里，读页面的文字结构去点按钮、填表单，全程不启动无头浏览器、不截图、也不需要能看图的多模态模型。
老办法的成本花在哪
要看懂 Page Agent 省了什么，先看外部工具为了操控一张网页要背多少东西。它们不进网页，只能站在外面隔着一层玻璃指挥。
这套外部驱动的思路，在跨站点抓数据、跑端到端测试时依然好用。Page Agent 想解决的是另一头的麻烦：当这个网页本来就是你自己的产品、你能改它的代码时，为什么还要绕这么大一圈。
把一整张网页压成一份文字清单
一张现代网页可以有上千个节点，把整段 HTML 原样丢给模型又慢又贵。Page Agent 的做法，是先给页面做一次「脱水」，只留下真正能操作的那几样东西。
收到指令后，智能体扫描整个 DOM（Document Object Model，浏览器把网页解析成的那棵元素树），找出每一个能交互的元素，按钮、链接、输入框，给每个都标上一个序号（index）加上角色（role）和文字标签（label）。冗余的装饰性标记全部剥掉，整页被压成一份叫 FlatDomTree 的精简文本地图。模型读的就是这份清单，不是像素。
就像把一本厚书的正文全撤掉，只留下目录里的章节标题和页码。模型不用啃完整本书，扫一眼这份目录，就知道该翻到哪一页、按哪个按钮。
脱水前后，模型看到的东西差多少
原文的演示页把这条循环直接摆出来了：一个「Dehydrated DOM」面板显示模型读到的清单，旁边一个「Action trace」面板随着指令执行逐条更新，你能看着它一步步点下去。
指令进来之后，里面怎么跑起来
从一句自然语言到页面上真的被点了一下，中间是一条固定的闭环。脏活由一个叫 PageController 的部件接手。
PageController 暴露的就是这几个具体动作，对着序号操作元素：
await this.pageController.updateTree()
await this.pageController.clickElement(index)
await this.pageController.inputText(index, text)
await this.pageController.scroll({ down: true, numPages: 1 })
整个 monorepo 把职责拆成三个小包，各管一块：
@page-agent/core无界面的智能体核心逻辑page-agent带 UI 面板的完整入口类@page-agent/page-controller负责 DOM 提取和元素编号，可选 SimulatorMask 做视觉反馈开发者手里的三道护栏
和其他工具比，谁该用它
这张对比表想说的是场景，不是速度。四种方案跑在不同的位置、用不同的方式读页面，各有各的地盘。
| 方案 | 跑在哪 | 怎么读页面 | 接入成本 | 最适合 |
|---|---|---|---|---|
| Page Agent | 网页内部（客户端 JS） | 脱水后的文字 DOM | 一个 script 标签或 npm | 你自己产品里的操作型 copilot |
| Selenium / Playwright / Puppeteer | 外部进程 | 经驱动读 DOM（WebDriver/CDP） | 驱动加运行时或服务 | 脚本化端到端测试 |
| browser-use | 外部进程 | DOM 加可选视觉 | Python 加一个浏览器 | 自主的多站点智能体 |
| WebMCP | 服务端工具 | 结构化函数调用 | 需要标准被普遍采用 | 智能体原生调用工具 |
它走的是另一条路：让网页把自己的功能包装成结构化的「工具」函数，直接暴露给智能体调用，靠的是标准化接口。Page Agent 靠读 DOM 文本，WebMCP 靠标准协议，一个不用改网页也能上、一个要等接口标准被大家接受。
结论落在适用范围上：Page Agent 适合你能改代码、说了算的产品内部；要去爬别人的网站、或者对着被锁死的环境干活，外部驱动依然是赢家。
能拿它做什么
因为它就住在你的应用里，能替用户真的把操作做完，而不是只在旁边告诉他该怎么点。原文给了四个具体例子。
最小成本是一行 script 标签
想先感受一下，一个 script 标签就能加载带免费测试模型的 Page Agent，直接在页面上体验。
<script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/iife/page-agent.demo.js" crossorigin="true"></script>
正式使用则是装包，再把 endpoint 换成你自己的：
import { PageAgent } from 'page-agent'
const agent = new PageAgent({
model: 'qwen3.5-plus',
baseURL: 'https://dashscope.aliyuncs.com/compatible-mode/v1',
apiKey: 'YOUR_API_KEY',
language: 'en-US',
})
await agent.execute('Click the login button')
model 和 baseURL 接受任何 OpenAI 兼容的服务商，换模型基本就是换一个 base-URL 和 key。
new PageAgent 的 apiKey 会被打包进前端代码里，正式环境要通过你自己的后端做代理转发请求，不能把密钥裸露在客户端。智能体也支持在执行每个关键动作前先弹出来让人确认。它做不到的那几件事
这套「住在网页里」的做法有它天然的代价，官方把限制说得很清楚。用它之前，这几条要先摆在桌面上。
写在 prompt 里的安全规则，只是建议
像「绝不自动提交支付表单」这种规则，是放在系统 prompt 里的。它们是有说服力的引导，不是硬保证。对于敏感或有破坏性的操作，服务端校验必须保留，prompt 里的指令不能当成你唯一的防线。
核心库只管一个页面
核心库瞄准的是单个视图内的交互，它自己没法在标签页或窗口之间移动。要做跨页面的自动化，得装那个可选的 Chrome 插件，而插件需要单独安装和授权。此外还有一个 Beta 阶段的 MCP server，能让 Claude Desktop、Copilot 这类外部智能体反过来驱动它。
展开：三种运行位置各解决什么
核心库跑在页面里，管单页操作；Chrome 插件补上跨标签页的能力，代价是要装、要权限；Beta 的 MCP server 则把 Page Agent 变成一个能被外部智能体调用的工具，接回到 Claude Desktop、Copilot 这些外部智能体上。三层各管一段范围，越往外，装配和授权的成本越高。
回到开篇那句话，Page Agent 和主流工具走的是两条路：一条是嵌进网页内部读文字，一条是站在外面靠截图和协议远程操控。它把浏览器自动化能落地的地方，从「用外部脚本操控别人的网页」，延伸到了「产品自带的一层自然语言操作入口」。
The agent lives inside the webpage as plain JavaScript. It reads the live DOM as text and acts as the real user. No headless browser, no screenshots, no multi-modal model. ， MarkTechPost, 2026-07-02