alibaba/page-agent：把 AI 操盘手塞进网页里，一段 JS 就能让用户「说人话」操作 UI

发表于 分类于 ， ，
阿里开源的 26.1k stars 项目，用纯 JavaScript 把 GUI Agent 嵌入任何网页里——不靠 Playwright、不靠 OCR、不走后端，让用户用一句话就能完成「点 20 下后台才搞定的报销流程」，并在 HN 上线当天拿下 147 分、76 条讨论。

一个让产品和运营同事集体沉默的下午

上周帮朋友的电商团队做内训。开场的需求评审会上，运营总监展示了一段用户调研视频 —— 一个 50 多岁的老板娘，第一次用某 SaaS 进销存系统去「把上周的订单导出给会计」。她花了 14 分钟、点了 78 下屏幕、中间误触了 3 次弹窗，最后在「批量导出 PDF 含税发票」这一步彻底放弃，打电话叫了儿子的大学同学过来代操作。

视频放完之后，整个会议室沉默了一分钟。

这个画面其实是无数 B2B 软件的常态：UI 是给熟练用户设计的，新手只能靠培训文档、客服话术、视频教程「忍」过去。但过去一年大模型进展神速，「让 AI 替用户点」已经成了显学 ——browser-use 用 Python 驱动整个浏览器、Playwright + GPT-4o 用截图 + 视觉模型做桌面自动化、Anthropic Computer Use 直接接管屏幕……

但这些方案都有同一个问题：它们都活在网页的「外面」。

要么得让用户手动启动一个外部进程，要么得在用户的浏览器 / 电脑上专门装一个客户端。对于一个普通的 SaaS 产品而言，这意味着每一个想「让用户开口说话就能操作」的产品经理，都得先说服公司拨预算、加机器、过安全审计、走合规流程，最后大概率死在「把这套东西部署到 50 万现有客户机器上」这一关。

直到上周 GitHub Trending 上冒出来一个项目，把整件事翻了个面 ——alibaba/page-agent，26.1k stars、1,071 个 commits、33 个 Release（含 v1.12.1）。它是一个「住在网页里」的 GUI Agent：一段 <script> 标签就能塞进任何网站，让用户直接用自然语言操作当前页面，AI 像「真用户」一样去点、去填、去翻页。不需要 Playwright、不需要 Puppeteer、不需要 OCR、不走后端、零依赖（只依赖一个 zod）。

Show HN 当天拿下 147 分、76 条评论，社区里最热的一句话是 ——「Alibaba just killed the browser automation stack」。

下面我把它拆开讲清楚。

项目背景：为什么「把 Agent 塞进网页」这件事这么重要

要理解 page-agent 在解决什么，得先理解现有 GUI Agent 架构的痛点。

当前 GUI Agent 的三种主流形态

第一类是 外部进程派。browser-use、Playwright + LLM、Selenium 集成都是这一派。它们跑在浏览器外面的 Python 脚本里，靠 Chrome DevTools Protocol (CDP) 给浏览器发指令。优势是能跨页面、能抓整站、能跑 CI；劣势是 没法继承用户当前已经登录的会话，对需要鉴权的 SaaS 后台基本抓瞎。

第二类是 桌面自动化派。Anthropic Computer Use、OpenAI Operator、各种 RPA 平台。它们靠截图 + 视觉模型 + 模拟键鼠，把用户的整个桌面接管起来。优势是「通杀所有软件，包括桌面应用」；劣势是 贵、慢、需要视觉模型，且每次操作都得先把页面截成图，token 消耗惊人。

第三类，是 page-agent 选择的 内嵌派。它直接作为一段 JavaScript 跑在你的网页里，和页面的 JavaScript 共享同一个 DOM 上下文、同一个浏览器会话、同一个 localStorage。结果是：

  • 用户已经登录？AI 自动继承。
  • 单页应用（SPA）？AI 直接看见 React/Vue 渲染好的真实 DOM。
  • 跨站？可选配一个 Chrome 扩展当「桥」，由用户在主动打开的 Tab 里授权。
  • 不需要后端？所有出网请求只去 LLM 接口，数据不出你的合规边界。

它和 browser-use 的关系也有必要交代一下 ——page-agent 的 DOM 脱水（dehydration）脚本就是从 browser-use port 过来的，作者 Simon 在 HN 上明确致谢。但 browser-use 跑在 Python 外部进程里，page-agent 是把同一套 prompt 逻辑搬进了浏览器。

这个「内嵌」架构有副作用：它对 Shadow DOM、canvas、iframe 有意留白（v1.12.1 还没覆盖）。但对绝大多数 「UI 稳定 + 操作链路长」的 B2B 系统（ERP、CRM、客服后台、低代码平台）来说，它就是把「点 20 下」变成「说一句话」的最短路径。

核心功能：一段 <script> 就能让网页听懂人话

page-agent 的设计哲学和之前写过的 TencentDB Agent Memory、AG-UI 协议 都不同 —— 它不是给 Agent 工程用的，是给 Web 开发者用的。你不需要懂 LangGraph、不需要懂 Tool Use schema、不需要懂 Vector DB，只要会 npm install 或者贴一段 <script> 就能上手。

按官网文档和 README 总结，它的硬功夫可以拆成五个：

1. 一行 CDN 集成，30 秒跑起来

最快的方式就是贴一段 <script>：

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

页面加载完会自动在右下角冒出一个 AI 操盘手 UI。默认调的是阿里云上的免费测试 Qwen LLM，加 ?autoInit=false 可以自己 new window.PageAgent(...) 接管初始化。国内有 npmmirror 镜像可以替换。

2. 纯 DOM 操作，不要视觉模型

browser-use 的核心技巧叫「HTML dehydration」—— 把活的 DOM 树「脱水」成一份带交互元素索引的纯文本快照，发给 LLM。LLM 返回的不是坐标，而是「点击 ref=5 那个输入框」这样的引用。page-agent 把这套 prompt 完整继承下来，所以一个 9B 参数量的小模型（比如 Qwen3.5-4b）就能跑得动 —— 它告诉 HN 评论者：「Anything smaller than 9b can’t really handle the complex tool call schema I use. Qwen3.5 4b is quite good but still gives messy json quite often.」

省视觉模型 = 省 GPU = 省 token。一个 ERP 页面如果走截图路线，单次任务可能要消耗 5,000+ token 视觉输入；走 DOM 路线通常 200-800 token 就够，成本差距大约在一个数量级。

3. 天然继承用户会话和权限

这是最关键的一条。当用户已经在浏览器里登录了 SaaS 后台，page-agent 自动拿到这整套会话上下文 ——Cookie、JWT、localStorage、Service Worker—— 它和网页共享同一个 DOM，不需要再去「模拟登录」、不需要处理验证码（设计上发现 CAPTCHA 会主动停下来交还控制权）。

这意味着开发 B2B 集成时，再也不用为「浏览器自动化能登录但拿不到鉴权后的真实数据」写 workaround 了。

4. 自带白名单 / 黑名单 + 数据脱敏

官方文档里有 Custom Tools 和 Instructions 两套配置口，允许开发者：

  • 限制 AI 只能操作特定 DOM 节点（避免 AI 跑到「删除账号」按钮上搞事）；
  • 对敏感字段（手机号、身份证）做 masking，发给 LLM 之前自动脱敏；
  • 注入自定义 prompt，引导 AI 按业务规则行事（比如客服系统的「必须先查工单再回复」）。

这是面向「生产环境」必备的能力。HN 上一位资深前端工程师 selimenes1 专门提了一句：「If you plan to integrate it into your web app. It’s better to have a proxy api for the llm and auth the request with cookie or something.」—— 别把 API key 直接塞前端。

5. 跨 Tab 能力用 Chrome 扩展补齐

内嵌模式只能控制当前页面。想跨 Tab 时，配套的 Chrome 扩展（Page Agent Ext） 派上用场。它的权限模型设计得非常克制：

  • 只有用户主动点扩展按钮，扩展才获得当前 Tab 的 activeTab 权限；
  • AI 新开的 Tab 全部被自动归到一个 Tab Group 里；
  • 不会动用户已有的其他 Tab；
  • 跳到哪个网站需要用户明确授权。

这套「Tab Group 隔离 + 明确授权」在 HN 评论区被反复点赞，因为它「给了用户肉眼可见的边界」。

实战示例：5 分钟把 page-agent 接进你的 React 后台

下面我用一个假想的「报销后台」做例子，走一遍最常见的接入姿势。

步骤 1：NPM 安装（推荐用于正式项目）

1
2
npm install page-agent
# 当前版本：v1.12.1

步骤 2：React 项目里挂载

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
import { PageAgent } from 'page-agent';
import { useEffect } from 'react';

export function ExpenseAdminWithAI() {
  useEffect(() => {
    // 建议通过自家后端代理 LLM API，避免 key 泄露
    const agent = new PageAgent({
      llm: {
        baseURL: '/api/agent-llm',  // 你自己的代理端点
        apiKey: '<by-cookie-or-session>',  // 实际从后端注入
        model: 'qwen-plus',
      },
      // 只让 AI 操作报销相关页面元素
      scopeSelector: '[data-agent-scope="expense"]',
      // 把敏感字段脱敏
      dataMask: {
        fields: ['cardNumber', 'idCard', 'phone'],
      },
      // 注入业务规则
      customInstructions: `
        在提交报销单前，必须验证金额不超过用户剩余预算。
        如果用户要求删除历史记录，必须先弹窗确认。
      `,
    });

    return () => agent.destroy();
  }, []);

  return (
    <div data-agent-scope="expense">
      {/* 报销后台 UI */}
    </div>
  );
}

步骤 3：用户用自然语言操作

假设这是一个需要点 8 步的传统 UI：

用户：「帮我把 7 月所有金额超过 500 块的差旅报销单都标记为「待复核」。」

page-agent 内部大致是这样工作的：

  1. 把当前 DOM 脱水成带 ref 的快照发给 LLM；
  2. LLM 返回类似 [{action: "click", ref: 12}, {action: "type", ref: 27, text: "500"}, ...] 的动作序列；
  3. page-agent 通过 dispatchEvent 派发真实的鼠标 / 键盘事件；
  4. 每步执行完都重新脱水 DOM 确认结果，再发下一轮请求。

整个过程对用户来说，就像一个看不见的「真用户」按在了屏幕那头。

步骤 4：调试 + 兜底

如果想看 AI 当前在想什么，可以在 dev 环境加 debug: true，它会把每一步的 prompt、LLM 返回、执行结果都打到 Console。生产环境如果不想发车，可以一并开启 requireApproval: 'always'，每一步都让用户在右下角气泡里点「同意 / 拒绝」。

适用场景和限制

把目前文档、HN 讨论、第三方评测综合下来，page-agent 最香的场景是这几类：

  1. B2B 后台的客服话术换皮 —— 让「请点击右上角设置 → 找到『通知偏好』→ 关闭『每日邮件汇总』」这种话术变成「别再给我发邮件了」，客户支持工单量直接砍一个数量级。
  2. 老旧系统的现代化外包 —— 公司里总有那种「没人敢动、没人能换、但每天被吐槽」的 J2EE/.NET 老后台，加一段 <script> 就能让它听懂人话，比做完整 UI 重构便宜两个零。
  3. 无障碍访问 —— 给视障、老年用户群体一个「说话就能用」的入口，文章开头的老板娘再也不用叫儿子同学过来帮忙了。
  4. 内部培训 / 演示 ——AI 直接演一遍「提交报销的标准流程」，比录视频教学更有代入感。
  5. 复杂表单的「填空助手」——B2B 客户录入时，AI 根据历史数据自动填 80% 字段，把 30 分钟的录入缩短到 5 分钟。

但它的边界也需要明确，不要硬上的场景：

  • 跨站爬虫 —— 内嵌模式下它只能动当前域，跨域需要爬取的话请走传统的 browser-use；
  • CAPTCHA / 验证码 —— 设计上发现 CAPTCHA 就停手，需要真人介入；
  • Shadow DOM / WebGL Canvas——v1.12.1 暂未覆盖，重度可视化页面会看不到；
  • 强 CSP 站点 —— 会因 Content-Security-Policy 拦截 LLM 请求；HN 上有人提到这是企业 SaaS 的普遍痛点；
  • 长按 / 拖拽交互 —— 目前还不支持，需要等后续版本。

总结

alibaba/page-agent 的意义不在于「它又是一个浏览器自动化框架」，而在于它把 GUI Agent 从「桌面 / 浏览器外的独立进程」拽回到了 「网页内部的 JavaScript 库」 这个位置。这个位置的好处是：

  • 一行 <script> 就能集成，不用部署新服务；
  • 天然继承用户登录态和会话，0 鉴权成本；
  • 不需要视觉模型，纯 DOM 文本就够了，省 token、省 GPU；
  • 26.1k stars + HN Show 147 分的社区信号，已经通过了早期采用者验证。

如果你是前端开发，给自己公司的后台加一段试试，30 秒就能看到效果；如果你是产品经理 / 解决方案架构师，这是给「客户为什么不用我们」这个问题一个成本最低的回答 —— 把「点 78 下」变成「说一句话」。

它不是万能解药，但极可能是 「让 AI 真正进入企业的 B2B 工作流」这件大事上，最被低估的一块拼图。仓库地址 👉 github.com/alibaba/page-agent，官方文档 👉 alibaba.github.io/page-agent。如果你接进生产，欢迎回来分享你的坑。