阿里一行JS代码杀疯了:网页里长出「AI操作员」,Selenium当场判了死刑

你打开公司的报销系统，屏幕上多了一个输入框。你打字：「帮我把上周五那趟差旅，交通类，342.5元，填好报销单交上去。」

三秒后，页面自己动了起来。分类下拉框被打开，选中「交通」；金额框被填上342.5；表单被提交。你的手指全程没碰过鼠标。

这是阿里巴巴开源的PageAgent在这几个月里被反复安利的真实功能。背后不需要独立服务器，不需要浏览器插件，连截图都用不上。这个「AI操作员」，就活在你正在看的这个网页里。

一条推文，判了浏览器自动化死刑

3月20日，开发者Nainsi Dwivedi发了条推特，标题就够狠：

"🚨 Breaking: Alibaba just killed the browser automation stack."

「突发：阿里刚刚干掉了浏览器自动化这一整套技术栈。」

她接着写道：

"page-agent.js ， a GUI agent that lives directly inside your webpage. No Selenium. No Puppeteer. No Chrome extension. No Python backend. Just one script tag."

「一个就活在你网页内部的GUI代理。不靠Selenium，不用Puppeteer，不需要Chrome扩展，也不用Python后端。只需要一个script标签。」

这条推特最终停在15.5万次浏览、1.5K点赞、3K收藏。三个月后的7月3日，开发者Suryansh Tiwari用几乎一模一样的段落又发了一遍；同一天，Marktechpost官方账号也发帖预告了自己的系统分析文章。同一个项目，同一套说法，被三个不同账号在三个月里各讲了一遍。

▲ Nainsi Dwivedi 3月20日发布的推文，拿下15.5万次浏览、1.5K点赞，是这波讨论最早的高热度节点之一。

一个开源库，凭什么让开发者们喊出「杀死Selenium」这种话？

外部机器人，和网页里的「原住民」

要理解这股劲儿从哪来，得先看懂过去二十年浏览器自动化怎么玩。

Marktechpost的分析文章开篇就把老办法说透了：

"Most browser automation runs from the outside. Playwright, Puppeteer, Selenium, and browser-use all drive a browser from an external process. They read the page through screenshots or the Chrome DevTools Protocol."

「大多数浏览器自动化都是从外部驱动的。Playwright、Puppeteer、Selenium、browser-use，全部靠一个外部进程去操控浏览器，靠截图或者Chrome DevTools协议去读页面。」

具体流程是：先起一个无头浏览器，把每一步截图丢给一个能看图的多模态大模型，模型判断该点哪、该填什么，外部脚本再模拟一次点击。整套流程像雇了个盲人，每走一步都要先拍照问路。

PageAgent把这套流程整个搬进了页面内部。它是一段JavaScript，就跑在你打开的这个网页的运行环境里，读的是实时DOM文本，全程靠文字判断，不用对着像素猜。它用不着单独起一个浏览器实例，因为它本来就在你的浏览器里，天然继承你当前登录的session和cookie。

▲ Marktechpost 7月2日发布的技术分析，把PageAgent和Selenium、Playwright、browser-use、WebMCP做了系统对比。

把DOM「脱水」，才是真正的技术核心

一个现代网页的DOM树，动辄几千个节点。把这坨原始HTML照单丢给大模型，又慢又贵。

PageAgent的解法，官方管它叫DOM Dehydration（DOM脱水）。

拿到一条指令后，Agent先扫描整个页面，把所有能交互的元素，按钮、输入框、链接，挑出来，给每个元素编上索引、贴上角色和标签。原本臃肿的DOM被压成一份干净的文本地图，叫FlatDomTree，冗余的样式和标签全部扔掉。

大模型看到的只是这份紧凑的文字清单，加上你的指令，然后吐出一串动作：点第7个元素，往第12个输入框里打字。剩下的执行工作交给PageController：

await this.pageController.updateTree()
await this.pageController.clickElement(index)
await this.pageController.inputText(index, text)
await this.pageController.scroll({ down: true, numPages: 1 })

这样设计的好处很明显：普通的文本模型就够精准操作了，用不着能看图的多模态模型。省下来的是多模态模型的token费用和响应延迟。

集成方式也确实只要一行：

<script src="https://cdn.jsdelivr.net/npm/page-agent@1.11.0/dist/iife/page-agent.demo.js" crossorigin="true"></script>

想接自己的模型，用npm也就几行：

import { PageAgent } from 'page-agent';
const agent = new PageAgent({
  model: 'qwen3.5-plus',
  baseURL: 'https://dashscope.aliyuncs.com/compatible-mode/v1',
  apiKey: 'YOUR_KEY',
});
await agent.execute('点击登录按钮');

官方demo站上的标语毫不含蓄："The AI Operator Living in Your Web Page"，「活在你网页里的AI操作员」。

▲ 官方demo站可以就地在浏览器里输入指令试跑，标语写着「活在你网页里的AI操作员」。

22.3k星，和一张对比表

代码有没有人认，GitHub最诚实。截至发稿，alibaba/page-agent仓库拿到22.3k星、1.9k fork，94个版本标签，最新v1.11.0在4小时前刚发布，34位贡献者、1085次提交，是个还在持续迭代的活跃仓库。

▲ alibaba/page-agent仓库截至发稿22.3k星、1.9k fork，v1.11.0四小时前刚发布。

官方文档里放了一张对比表，把PageAgent和它的「师父」browser-use摆在一起：

这张对比表，其实是PageAgent自己给的定位说明：它瞄准的，是能不能被塞进自己产品里的适配能力。它的DOM处理和提示词，确实衍生自browser-use，README里专门写了致谢，但browser-use要装Python、要维护浏览器实例池，PageAgent只要往页面里插一行脚本。

▲ 官方文档里的Overview页：Smart DOM Analysis、Secure & Controllable、Zero Backend、Accessible Intelligence，四项核心特性配上和browser-use的对比表。

HN老哥们，没那么容易被说服

热闹归热闹，Hacker News上的讨论要冷静得多。作者本人（网名simon_luv_pho）在Show HN帖子里亲自解释了设计初衷：

"I'm experimenting with an 'inside-out' paradigm instead... you get a client-side agent that interacts natively with the live DOM tree and inherits the user's active session out of the box, which works perfectly for SPAs."

「我在尝试一种反过来的'由内而外'范式……你得到的是一个客户端Agent，原生地和实时DOM树交互，天然继承用户当前的登录状态，这对单页应用来说简直完美适配。」

这条帖子拿到147个点赞、76条评论，讨论比想象中更针锋相对。开发者jadbox试着把LLM地址填成http://0.0.0.0:8080，结果扩展当场崩溃，还反复在启动时继续崩。另一位网友netsharc补充嘲讽了一句：

"Hah, wow. I hope this is an LLM response, otherwise, what a huge blindspot for a developer..."

「哈，我真希望这是大模型自己的锅，不然对一个开发者来说，这算个挺大的盲区……」

安全性的讨论更实在。有网友问Chrome扩展的权限该不该锁定在固定标签组里，作者回应：目前扩展只能访问任务启动时的活动标签页，新开的标签会自动归入专属标签组，碰不到用户已有的其他标签。另一位网友补充：把Agent关进一个用户看得见的标签组，才是真正能建立信任的边界。

▲ Show HN帖子拿到147分、76条评论，作者亲自回应了WebGL崩溃、标签组沙箱等质疑。

再往深了看，风险不止这些。文档里也承认，prompt级别的护栏管不住代码约束，让模型「永远不要自动提交支付表单」，这只是一条建议，够不成代码层面的强制锁，敏感操作还是得靠后端校验兜底。另外，把API key摆进客户端bundle，生产环境里等于把钥匙挂在了门口，官方也建议换成代理到自己后端的方案。

前端开发者，这次翻身了

过去几年，AI Agent浪潮里前端团队多半是被自动化的对象，外部机器人爬你的页面、点你的按钮、抓你的数据，前端全程被动。

PageAgent把这个关系倒了个个。国内开发者社区讨论这个项目时，提出了一个概括：「By Frontend, For Frontend」，由前端打造，为前端服务。产品自己长出AI能力，不再沦为别人Agent的操作靶子。真实的登录态、真实的权限边界、真实的会话，全部原地继承，不用共享密码，不用后端模拟。

这不代表Selenium和Playwright要退场。跨站抓取、无UI的大规模测试、公开数据聚合，这些场景外部Agent依然是唯一解。PageAgent的Beta版MCP Server，倒是暗示了另一条路，让Claude Desktop、Copilot这类外部大Agent，把某个网页里跑着的PageAgent，当成一个具体工具去调用。两条路子，正在往「网页内轻量Agent + 外部重型Agent + MCP胶水层」的混合架构上靠拢。

从Selenium到Playwright，从browser-use到PageAgent，变的是执行动作发生的位置，没变的是同一个问题：谁能替用户，把网页变成一个能用语言操作的界面。这一次，答案第一次落在了前端自己手里。