事件内容
7 月初,阿里巴巴开源了一款叫 Page Agent 的 JavaScript 客户端库,挂在 alibaba/page-agent。这个库做的事情很直接:把 AI 智能体作为 JavaScript 模块直接嵌入网页,让 AI 在浏览器里以「网页用户」的身份,根据自然语言指令,完成点击按钮、填写表单、滚动页面等操作。
整套库的代码基于 TypeScript,协议采用 MIT,核心架构是三大包:@page-agent/core(无头 Agent 逻辑)、page-agent(含 UI 面板的入口类)、@page-agent/page-controller(DOM 提取与元素索引)。
最值得拎出来说的,是它实现 DOM 自然语言操控的核心技术——DOM 脱水(DOM Dehydration):把整个页面的实时 DOM 树压缩成一个叫 FlatDomTree 的纯文本映射,扔给一个普通的文本大模型(默认示例是阿里自家的 qwen3.5-plus,OpenAI 兼容端点),模型读完文本结构后,精确告诉你「该点哪个按钮」。整个过程不走截图、不依赖多模态——只有纯文本往返。
深度剖析
第一,这是一套「反 Playwright」的工程哲学。
熟悉自动化测试的人知道,行业里最主流的工具链是 Playwright、Puppeteer、Selenium、browser-use——它们的共同点是:外部进程,通过截图或 Chrome DevTools Protocol 来操控浏览器。这种模式的优点是跨页面、跨标签;缺点是部署重、需要无头浏览器、要付费给多模态模型、Cookies 和会话不连续。
Page Agent 反着做:Agent 活在网页里,作为一段普通 JavaScript 加载。一旦加载,AI 就继承了用户的 Cookies、会话、登录态——根本不需要「重新登录」。没有无头浏览器、没有外部驱动、没有后端服务。一个 标签加一段异步调用,AI 就能在用户已经登录的网页里工作。
第二,「FlatDomTree」是这件事的关键工程抽象。
现代网页可能包含成千上万个 DOM 节点,直接发给模型既贵又慢,而且模型对 HTML 嵌套结构理解很差。Page Agent 的解法是:扫描页面,识别所有可交互元素(按钮、链接、表单字段),给每个元素分配一个 index + role + label,剥掉冗余的样式和嵌套标签,生成一个紧凑的纯文本映射。模型看到的是人类可读的「[42] button: 登录」这种结构,而不是生 HTML。
这种做法的隐性胜利是:完全不需要多模态。一个 Qwen3.5-Plus 级别的纯文本模型,就能精确执行点击/填写——把商业化的边际成本打到了「几厘钱/任务」。
第三,使用门槛被压到了 SaaS 工程师都能直接动手的程度。
最简集成示例:
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(‘点击登录按钮’)
模型可以换、端点可以是任意 OpenAI 兼容服务——意味着你换 GPT、Claude、GLM 都可以,不需要改代码逻辑。Production 部署时需要注意:密钥放在客户端 bundle 里不安全,应当用自己的后端中转请求——这是一个简单但非常容易被忽略的工程纪律。
第四,官方列了四个真实落地的应用场景,值得逐个过一遍:
– SaaS AI 副驾:产品内置 AI,直接帮你执行而不是给你步骤说明 – 智能表单填写:把多步 ERP/CRM 报销流程压缩成一句「给我提交一份 50 美元午餐报销单」 – 无障碍控制:配合 Web Speech API,任何网页都能用语音操控 – 遗留系统现代化:没有 API 的老系统,加个指令栏就能用自然语言驱动,原代码不需要改
每个场景的共同点是:产品方控制代码、能加 JS 脚本。对「外部站点、跨页面、锁闭的 SaaS」这些不在产品方控制范围内的场景,Playwright/Puppeteer 仍然更合适。
值得关注的原因
对独立开发者:这是一张「Agent SaaS」的入场券。在 Page Agent 之前,做一款「AI 帮你点 SaaS 内部按钮」的产品,需要解决浏览器驱动、Cookies 隔离、登录态同步这一整套工程难题。Page Agent 把这些全免了——只要你的产品是一个有界面的 Web App,几行 JS 就能加上 AI 副驾功能。
对大模型公司:这是「文本模型能完成的事不必上多模态」的关键佐证。很多人误以为「Agent 必须用 GPT-4V、Claude 3 Vision 这类多模态模型」,Page Agent 实证了只要 DOM 抽取得好,文本模型能精准完成 GUI 操控。这意味着 Agent 类应用的成本结构,可能比大家想象的要友好得多。
对企业 IT:这是遗留系统改造的「自然语言桥」。企业里堆了几十年的老 SaaS、定制 ERP、内部工具,重写一套 AI 接口基本不可能。Page Agent 提供了一种「不改造老系统,只加一段 JS」的渐进式方案——把 AI 能力的入口嫁接在现有系统之上,既保住了历史投资,又获得了 AI 加持。
对协议生态:这又是一例「OpenAI 兼容端点 = 事实标准」。Page Agent 不锁模型,通过 baseURL+apiKey 让你换用任何 OpenAI 接口风格的厂商——这意味着国内千问、智谱、月之暗面,海外 OpenAI、Anthropic、Groq 都能直接接入。协议抽象层一旦做到位,生态自然归属标准而非巨头。
风险与待观察
第一,Prompt 层面的安全约束是不可靠的。官方坦承:「不要自动提交支付表单」这种规则,只能写在系统提示词里。它是「有说服力的指引」,不是硬保证。敏感的、有破坏性的动作,服务端验证仍然是必须的。这条对金融、政务、企业 IT 的部署者尤其重要——单 Page Agent 客户端保不住合规底线。
第二,单页面边界。核心库只能在一个视图内交互,不能跨标签页、跨窗口。多页面自动化需要装官方提供的 Chrome 扩展(需要单独装和授权),或者等 Beta MCP server 成熟。现在做「跨页面的全流程 Agent」,仍需要 Playwright 那条路线。
第三,密钥分发。上面提到的「密钥不应放在客户端 bundle」,在 demo 示例里恰恰是这样写的。如果开发者直接抄官方 demo 部署,会有密钥泄露风险。生产前必须改架构。
第四,生态成熟度。Page Agent 是从 browser-use fork 出 DOM 处理和 prompt 的,得益于 browser-use 的活跃社区,未来跟进可能比较快。但本身是一个新开源项目,长期维护的承诺、跨浏览器兼容性、GitHub issue 的响应速度,都需要 6 个月以上的观察。
来源:阿里 alibaba/page-agent GitHub 仓库 MarkTechPost 7 月 2 日深度报道