page-agent：阿里巴巴开源的网页 GUI Agent，20k stars，一行 JS 给你的网页装上 AI

给网页加 AI 助手，不用改后端，一行 script 标签的事。

给一个 SaaS 产品加「AI copilot」有多麻烦？传统方案基本两条路：要么重写后端，做一套 agent 编排逻辑；要么装个浏览器扩展或 headless 浏览器（Playwright 那套），在外部控制页面。两条路都不轻量，尤其第二种还要用户装扩展，体验很重。

阿里巴巴开源的 page-agent（alibaba/page-agent，20.4k stars，MIT，TypeScript）给了第三条路：一个纯页内的 JavaScript GUI Agent，住在你的网页里，用自然语言操作界面。 不需要浏览器扩展、不需要 Python、不需要 headless 浏览器——一段 script 引入，页面就能听懂自然语言指令。

先把容易误解的点说清楚。它不是传统的浏览器自动化/爬虫工具，官方定位非常明确：客户端 web 增强（client-side web enhancement），不是服务端自动化。它的核心场景是给你的 SaaS 产品、ERP/CRM 系统、管理后台加一个 AI copilot，让用户用一句话完成原来要点 20 次的操作。

本文提纲

1. 它跟 Playwright / 浏览器扩展有什么本质区别
2. 核心设计：text-based DOM，不要截图
3. 一行代码接入，自带免费测试 LLM
4. 五个真实使用场景
5. 进阶：Chrome 扩展与 MCP Server
6. 它脱胎于谁，有什么限制
7. 谁该用，谁别用

它跟 Playwright / 浏览器扩展有什么本质区别

市面上的网页自动化方案大多走「外部控制」路线——起一个浏览器进程（headless 或带界面），通过 CDP 协议操作页面。Playwright、Selenium、browser-use 都是这套。问题是它们要装 Python、要装浏览器、要管理进程，对终端用户完全不透明。

page-agent 完全反过来：它跑在页面自己的 JS 运行时里，跟你的业务代码同进程。对比一下：

维度	Playwright / browser-use	page-agent
运行位置	外部进程控制浏览器	页面内 JS，同进程
依赖	Python + 浏览器二进制	只需一个 script 标签
用户安装	要装扩展或 agent 客户端	零安装，网页自带
感知方式	截图 + 多模态 LLM	text-based DOM
适合	测试、爬虫、RPA	产品内 AI copilot、无障碍
定位	服务端自动化	客户端 web 增强

这个定位差异决定了它的用法。Playwright 是 QA 和数据团队用的工具，page-agent 是产品开发者嵌进自己产品的能力。你不会用 page-agent 去做回归测试（那是 Playwright 的活），但你会用它让 ERP 系统的用户一句话填完一张复杂表单。

核心设计：text-based DOM，不要截图

这是 page-agent 最聪明的设计决策，也是它能在页内轻量运行的关键。

多数 GUI agent 靠「截图 + 多模态 LLM 看图操作」。这套方案的问题：截图要走 GPU 渲染、传给 LLM 的图像 token 成本高、延迟大、还要特殊权限（截屏需要用户授权或扩展能力）。在页内纯 JS 环境根本玩不转。

page-agent 不截图。它把页面的 DOM 序列化成文本结构，直接喂给文本 LLM。LLM 看到的是「这里有个按钮叫登录，那里有个输入框叫邮箱」这种结构化文本，然后输出「点击登录按钮」这样的指令，agent 再翻译成实际的 DOM 操作。

graph LR
    A[Natural Language] --> B[Text LLM]
    C[Page DOM] -->|serialize to text| B
    B -->|action instruction| D[DOM Manipulation]
    D --> E[Page Updated]
    E -->|re-serialize| B
    style A fill:#FF6B6B,color:#000000
    style B fill:#FFEAA7,color:#000000
    style C fill:#4ECDC4,color:#000000
    style D fill:#96CEB4,color:#000000

这套设计的好处：不依赖多模态模型（普通文本 LLM 就行，成本低）、不需要截图权限、延迟低、token 消耗少。缺点也很现实——纯文本描述有时会丢失视觉信息（比如靠颜色/位置传达的状态），但 page-agent 的 DOM 序列化做得比较细，元素的角色、文字、可见性都带上了。

这个 DOM 处理和 prompt 的设计，page-agent 明确承认是脱胎于 browser-use 项目的——把服务端的那套 DOM 交互模式搬到了客户端。

一行代码接入，自带免费测试 LLM

接入简单到离谱。最快的方式，在 HTML 里加一个 script 标签：

这一行就给你的网页装上了 GUI Agent，用的是官方提供的免费测试 LLM。加载后自动初始化，用户就能用自然语言操作页面了。

国内访问用镜像源更快：

生产环境推荐用 npm 安装，配自己的 LLM：

npm install page-agent

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('点击登录按钮')

注意几点：BYO LLM（Bring Your Own LLM），你接哪个模型都行，Qwen、GPT、Claude 都支持；language 控制界面语言；demo CDN 的免费 LLM 官方明确标注「仅供技术评估」，生产用必须接自己的 API key。

那个免费测试 LLM 用的 URL 自带说明：它有独立的服务条款和隐私政策，用了即视为同意。所以别在生产环境用 demo CDN，数据会过阿里巴巴的测试 LLM。

五个真实使用场景

README 列的用例，我按实际价值排序：

SaaS AI Copilot（最核心）。给你的产品加 AI 助手，几行代码的事，不用重写后端。用户不用学你的 UI，直接说「把上周的销售数据导出成 Excel」，agent 自己找到导出按钮、选时间范围、点确认。

智能表单填写。把 20 次点击的工作流变成一句话。这个对 ERP、CRM、管理后台特别实用——那些复杂的后台表单，老员工都嫌烦，新员工不会填。一句话搞定：「把客户信息按上次的模板填进去」。

无障碍。让任何 web 应用通过自然语言可操作。对视障用户，配合读屏软件和语音指令，零门槛使用复杂网页。这是个有社会价值的应用方向。

多页 Agent。靠可选的 Chrome 扩展，agent 能跨浏览器标签页工作——在一个页面拿到信息，到另一个页面执行操作。适合需要跨系统操作的场景。

MCP 控制。可选的 MCP Server（Beta）让外部 agent 客户端控制浏览器，把 page-agent 当成一个 MCP 工具来调用。

进阶：Chrome 扩展与 MCP Server

页内 JS 的能力边界是单个页面。要做跨页面任务，page-agent 提供了两个可选扩展：

Chrome 扩展：装上后，agent 能跨 tab 操作。这是「多页 Agent」场景的技术基础。比如「在 A 系统查订单，到 B 系统建工单」，单页 JS 做不到，扩展能。

MCP Server（Beta）：把 page-agent 暴露成一个 MCP 工具，让 Claude Desktop、Cursor 这些支持 MCP 的 AI 客户端从外部控制浏览器。这个方向把 page-agent 从「页内增强」延伸到了「被外部 agent 调用的执行体」。

注意两个都是 Beta / 可选，核心能力（页内自然语言操作）不依赖它们。不用扩展也能用 page-agent 的主力功能。

它脱胎于谁，有什么限制

page-agent 在 README 里明确致谢了 browser-use。DOM 处理组件和 prompt 设计是从 browser-use 继承来的，按 MIT 协议合规引用。这解释了为什么它的 DOM 交互模式很成熟——站在了一个成熟项目的肩膀上。

几个限制要说清楚：

text-based 的天然短板。纯文本 DOM 描述丢失视觉信息，靠颜色/图标/布局传达的状态（比如一个灰色的禁用按钮、一个位置偏移的悬浮菜单）可能识别不准。多模态方案能看图，page-agent 看不到。这是设计取舍换来的轻量代价。

单页边界。不加扩展，agent 只能操作当前页面。跨页任务必须装 Chrome 扩展。

不是测试/爬虫工具。这是最容易误用的地方。它不是 Playwright 替代品，做不了 headless 回归测试、大规模数据采集。硬要用它爬数据，既不顺手也违背设计初衷（官方定位写得很死：客户端增强，非服务端自动化）。

贡献门槛。项目明确写了：纯 AI/bot 生成的贡献不接受，必须有实质性人工参与。这反映他们对代码质量和可维护性的态度——20k stars 的项目不想被 AI 刷 PR 淹没。

谁该用，谁别用

该用：

• SaaS 产品开发者，想给产品加 AI copilot 但不想重写后端
• 复杂后台系统（ERP/CRM/管理后台），想简化表单填写流程
• 做无障碍功能，让 web 应用语音可控
• 需要 page 内自然语言交互的产品

别用：

• 做自动化测试——用 Playwright / Cypress
• 做数据采集/爬虫——用 Scrapy / Playwright
• 需要多模态视觉理解的场景——page-agent 是 text-based
• 要 headless 跑的服务端任务——它本质是客户端的

page-agent 抓住的是一个很真实的空白：在「重后端的 agent 编排」和「重依赖的浏览器自动化」之间，缺一个轻量的、能直接嵌进产品页面的 GUI agent。20.4k stars 说明这个定位击中了很多开发者的痛点。如果你在做 SaaS 或复杂后台，想让用户少点几十次鼠标，这个项目值得花半小时接入试试——demo CDN 一行代码，验证成本几乎为零。

参考文档与链接

• GitHub: alibaba/page-agent — 20.4k stars，MIT，TypeScript，网页 GUI Agent
• page-agent 官方文档 — 接入指南、配置、用例
• 在线 Demo — 直接体验自然语言操作网页
• npm: page-agent — npm 安装包
• Chrome 扩展文档 — 多页 Agent 扩展配置
• MCP Server 文档（Beta） — 外部 agent 控制浏览器
• GitHub: browser-use/browser-use — page-agent 致谢并脱胎于此的浏览器自动化项目
• Hacker News 讨论 — 社区对 page-agent 的讨论与反馈

做 SaaS 或后台系统的，用户还在点 20 次填表单？装个 page-agent 试试，评论区说说接入体验。觉得有用点个赞让更多人看到。

---

作者: itech001 来源: 公众号：AI人工智能时代 网站: https://www.theaiera.cn/ 每日分享最前沿的AI新闻资讯和技术研究。

本文首发于 AI人工智能时代，转载请注明出处。