一条推文，把整个开发者圈的情绪点燃了。
墨西哥博主 Nix0n 用西班牙语写下一行标题：
"EXCLUSIVA: CHINA ACABA DE ABRIR LA PUERTA AL FUTURO DE LAS WEB APPS"
「独家：中国刚刚为Web App的未来打开了大门。」
这条推文拿下364个赞、497次收藏、2.8万次浏览。评论区没人觉得他夸张，因为他说的是真事，阿里巴巴悄悄开源了一个叫 PageAgent 的东西，只用一行代码，就能让AI「住」进任何一个网页里，像真人一样点按钮、填表单、翻页面。
▲ @UnTalNixon_exe 的推文，2.8万次浏览、364赞、497收藏，评论区一片"这是未来"的惊呼。
一、外面看热闹的人，可能没看懂它到底狠在哪
如果你只是刷到"又一个AI代理开源了"，很容易划走。毕竟2024年之后，AI agent的新闻已经多到审美疲劳。
但PageAgent不太一样。它悄悄干了一件所有人都没做过的事：把AI代理从浏览器外面，搬进了网页内部。
要理解这份分量，得先看清过去二十年浏览器自动化走过的两条老路。
第一条路是"脚本时代"。Selenium、Puppeteer、Playwright，这些工具让开发者写死路径和选择器，跑固定的端到端测试。稳，但脆，页面稍微改版，脚本就崩。
第二条路是2024年之后火起来的"AI代理时代"，代表是browser-use这类工具。它们的架构可以概括成"外部大脑+外部眼睛+外部手"：一个Python进程开一个无头浏览器，定期截屏，把图片扔给多模态模型，模型看图做决策，再通过Chrome DevTools Protocol把指令发回浏览器。
这套架构听起来很酷，用起来却处处是坑。多模态模型认图比认文字贵得多，图片token的成本是文字的10到100倍。外部进程还看不到用户已经登录的session和cookie，得单独处理鉴权。整个流程像是找了个不认识你家的外人，蒙着眼睛摸进你家客厅。
Marktechpost在7月2日的分析文章里，点破了这个局面：
"Most browser automation runs from the outside... That's automation pointed at your app ， not something living inside it."
「大多数浏览器自动化都是从外部驱动的……那是对着你的应用做自动化，跟活在应用内部完全是两码事。」
阿里的工程师simon_luv_pho显然也是这么想的。他选了第三条路：inside-out（由内而外）。
▲ Marktechpost官方账号发布的源推文，2026年7月3日凌晨发出，2.1万次浏览，附带项目核心卖点清单，正是这波全球关注浪潮的起点。
二、DOM脱水：为什么一段文字比一张截图更懂你的网页
PageAgent的核心黑科技，官方管它叫"DOM dehydration"（DOM脱水）。
普通人打开网页，看到的是像素，按钮、输入框、排版好的文字。但浏览器内部其实一直维护着一棵看不见的树，叫DOM（文档对象模型），记录着每个标签、每个属性、每层嵌套关系，像一本家族谱。
一个稍微复杂点的网页，DOM树可能有成千上万个节点。如果把这坨原始HTML整个丢给大模型，又贵又慢，模型还未必看得懂重点在哪。
PageAgent的做法是先"拧干水分"：
页面加载后，注入一段轻量JS。用户说一句自然语言指令，比如"把订单金额改成50美元并提交"。代理开始扫描当前DOM，把所有能交互的元素，按钮、输入框、链接、下拉菜单，挑出来，给每一个编一个简短索引，标注角色和可见文字。
这棵"脱水"后的树，官方叫它 FlatDomTree，是一份干净紧凑的文本清单，冗余标签全部剥离，只留下模型真正需要的信息。
大模型读到的，是这样一份文本地图，而非像素点阵。它返回的动作也很干脆，类似click(3)或者input(7, "张三")。
真正干活的是一个叫PageController的模块，Marktechpost的文章里贴出了它的核心调用：
await this.pageController.updateTree()
await this.pageController.clickElement(index)
await this.pageController.inputText(index, text)
await this.pageController.scroll({ down: true, numPages: 1 })
这几行代码看着平平无奇，背后的意义却不小：只要一个够强的纯文本模型就够用了，不需要多模态、不需要视觉模型，成本立刻降一个量级。
而且因为代理是在浏览器session里原地运行，它天然继承了用户已经登录的身份、权限和状态，不用像外部代理那样，专门写一套鉴权逻辑去模拟登录。
官方Demo站上，这套流程有一个直观的可视化面板。
▲ alibaba.github.io/page-agent/ 官方演示页，主标题写着"The AI Operator Living in Your Web Page"（活在你网页里的AI操作员），输入框下方就是一句自然语言指令即可运行的体验区。
页面正中写着："One line of code, turns your website into an AI-native app."（一行代码，让你的网站变成AI原生应用。）左边输入指令，右边实时展示"Dehydrated DOM"和"Action trace"两个面板，你能亲眼看着一段网页结构被压缩成文字，又亲眼看着模型一步步执行动作。
三、故事的起点：一个"不安分"的Show HN帖子
PageAgent这次并非横空出世。三个月前，它就已经悄悄在Hacker News上发过一次帖，标题是《Show HN: PageAgent, A GUI agent that lives inside your web app》，拿到147个赞、76条评论。
发帖人正是simon_luv_pho，他在帖子里写下了这样一段话：
"I built this because I believe there's a massive design space for deploying general agents natively inside the web apps we already use, rather than treating the web merely as a dumb target for isolated bots."
「我做这个的原因是，我相信在人们已经在用的网页应用里原生部署通用代理，存在巨大的设计空间，而非把网页仅仅当成孤立机器人的哑目标。」
▲ Hacker News上的Show HN帖，147票、76条评论，作者本人在评论区连续现身，回应CSP限制、脱水保真度、扩展沙箱等细节追问。
评论区的攻防很值得一看。有人吐槽把LLM地址填成了本地内网IP，扩展应声崩溃，怎么也启动不了；有人追问Chrome扩展的跨标签能力会不会被滥用；作者的回应异常坦诚，他承认这套东西目前高度实验性，会一个个补issue，甚至主动聊起"客户端代理的安全模型"这种容易被回避的话题。
一位用户建议扩展权限应该限制在某个固定的标签组里，作者当场给出方案：目前扩展只能访问任务开始时的活跃标签，以及任务过程中新开的标签，且全部自动归到一个专属标签组，不会碰其他已存在的标签。
这种边被质疑边给方案的姿态，或许正是这个项目能从一个小众Show HN帖，滚成22.3k星标现象级项目的隐藏原因，技术圈从来只认作者敢不敢在评论区正面刚，营销话术在这里不管用。
四、为什么偏偏是现在火了
从三个月前的HN冷启动，到7月2日Marktechpost发出深度长文，再到7月3日凌晨X上多语言同时爆发，西班牙语、英语、阿拉伯语、中文帖子几乎同一时间刷屏，这个节奏本身就值得琢磨。
原因大致能拆成四层。
第一，时机撞对了。2026年这一年，AI agent的新闻已经密集到让人麻木，"又一个外部浏览器机器人"很难再让人兴奋。PageAgent"住进网页内部"的说法，第一次给这个赛道带来了差异化的角度。
第二，集成成本低到没有借口。想用Cursor，得换编辑器；想用Playwright，得写脚本、配环境。PageAgent只要一行<script>标签，产品经理、设计师，甚至不写代码的人都能立刻感受到效果。
第三，它扎进了一个真实存在的痛点。ERP系统里20次点击才能填完的表单、没有API的老旧内部工具、想快速给SaaS加个Copilot功能，这些场景过去都得靠重写代码，现在开口说一声就能试。
第四，成本和隐私的说法讲得漂亮。纯文本+自带模型密钥（甚至能接本地Ollama），意味着企业不用担心把截图和用户会话发给第三方视觉服务，这对做2B产品的团队格外有吸引力。
英国分析师和印度开发者几乎同时在X上写下类似的评价。印度开发者Suryansh Tiwari的原话是：
"Alibaba just killed the browser automation stack."
「阿里刚刚终结了浏览器自动化这套老架构。」
这话可能有点夸张，但它精准踩中了当下开发者的情绪：大家都受够了那套"外部大脑+外部眼睛"的笨重组合。
五、跑过真实生产环境的团队怎么说
情绪归情绪，真正让人信服的还是数字。
数字营销机构Bridgers花了几周时间，把PageAgent拉进真实项目里做对照测试，写了一篇长评测，标题起得毫不客气：《Alibaba Page Agent Review: Free Cursor Alternative or Just Another AI Gimmick?》（阿里PageAgent测评：免费的Cursor替代品，还是又一个AI噱头？）
▲ Bridgers团队的实测长文，起因很实际：Cursor每人每月20美元，GitHub Copilot每人每月19美元，一个十人开发团队光是AI编程订阅费就要多掏出一大笔钱。
测下来的结论出乎预料。表单填写场景，耗时缩短到原来的五分之一；测试场景的编写速度，快了3倍。团队原本担心免费的东西能有多好用，实测之后发现至少在表单和内部流程这类场景里，PageAgent确实能打。
文章里特别强调了一点：这东西谈不上是Cursor的替代品，更像是一层互补的"界面操作层"，Cursor帮你写代码，PageAgent帮你的产品自己把界面操作跑起来。
真实落地的场景其实比想象中更宽。
一个物流公司的内部系统里，一张30个字段的订单表单，过去手动填要3分钟，接入PageAgent之后，口述加确认只要35秒。
一个SaaS仪表盘里，用户开口说"把上个月所有状态为pending的订单导出成CSV并发到我邮箱"，代理会自己找到筛选按钮、导出按钮，填好邮箱地址，点击发送，不用改一行后端代码，原有的权限校验照常生效。
结合Web Speech API，视障或者年长用户可以开口说"把字体调大""换成深色主题""提交退款申请"，屏幕阅读器友好，门槛几乎为零。
对于那些没有REST API、重写前端代价巨大的老旧ERP系统，嵌入PageAgent之后用户可以用自然语言操作，界面本身不用动，安全规则和业务逻辑照旧生效，这可能是最现实的一条"遗留系统现代化"捷径。
六、爽归爽，风险这道题也得答明白
任何能"帮你操作页面"的东西，反过来想，也是"能操作你页面的东西"。
PageAgent运行在页面的JS上下文里，权限和其它第三方脚本完全一样，它能做用户能做的所有事，也可能被同一页面里的恶意脚本干扰。这一点，作者在HN上没有回避，主动承认了。
官方给出的护栏思路是这几条：
操作层面设了allowlist/blacklist，开发者可以精确限定代理能做哪些动作；涉及密码、卡号等敏感字段，会做数据掩码，压根不发给大模型；关键动作执行前，必须弹出确认框，等人工点头；开发者还能往里注入领域规则，比如"永远不要自动提交支付"。
但Marktechpost的文章也提了一句很扎实的提醒：
"Prompt instructions should not be your only control."
「提示词层面的规则，不该是你唯一的防线。」
写在系统提示词里的规则终究只是"劝导性的"，算不上可靠保证。真正涉及支付、删除这类高风险动作，官方建议必须保留服务端二次校验。
还有一条更基础的安全提醒：千万别把API密钥写进前端代码里发布出去。生产环境必须把大模型请求统一走自己的后端代理转发，密钥留在服务器，前端只拿到执行结果。
对比来看，PageAgent的风险模型其实比很多同类方案更可控，因为它只在"你自己拥有代码权的页面"里跑，注入点和规则完全由开发者掌控，不像桌面级agent那样拿到整个系统权限，也不像某些云端agent那样长期存着用户的token。
七、更大的看点：一场范式转移正在发生
过去二十年，Web的默认假设一直是"给人用的"，RPA、测试脚本、爬虫，本质上都是在模拟人的动作。
PageAgent真正值得记一笔的地方，在于它标志着另一种可能性正式登场：软件不再只是一个被动展示的界面，而是同时暴露出一层"可以被对话操作"的活接口。
这个想法其实早有雏形。早年的书签工具（bookmarklet）、Greasemonkey/Tampermonkey这类用户脚本、浏览器扩展版的Copilot，走的都是类似的路子，把额外的智能"塞"进已有的网页里。PageAgent的不同之处在于，它头一回把大模型的规划能力标准化、产品化，做到了零配置嵌入任意网页。
几个问题还悬在半空，没人能给出确定答案：
浏览器如果哪天原生内置了更深层的agent能力（WebMCP这类提案已经在讨论），PageAgent这类库会不会变成一个过渡期的polyfill？会不会有人专门针对这类"活在页面里"的代理，摸索出提示词注入的攻击链条，逼着所有开发者持续加固allowlist？如果哪天9B以下的小模型也能在浏览器本地稳定跑复杂的工具调用，"零后端AI Copilot"会不会变成SaaS产品的标配？
这些问题目前都没有标准答案。但至少现在，PageAgent已经用22.3k星标和一场跨越多种语言的关注热潮，证明了一件事：当AI真的要去"用"一个产品，最简单粗暴的办法，就是让它住进产品里面。
对着自己的产品，你的SaaS、你的内部系统、你那个没人愿意重写的老后台，不妨想一个问题：如果给它加一层"能听懂人话"的操作层，只需要一行代码，你会不会也想试试？
