Page Agent 把说明书式客服，变成直接替用户完成网页操作的 AI

作者徐某人    |    日期  2026-09-02    |    邮箱  x17513604077@gmail.com

Page Agent ·  Web GUI Agent  ·  TypeScript  ·  MIT项目地址  https://github.com/alibaba/page-agent

事情是这样的。

不知道大家有没有被一些公司的后台系统折磨过。

左边十几个菜单，点开以后还有二级菜单。页面上密密麻麻摆着筛选框、状态栏、表格和按钮，想改一条资料，得先找到客户管理，再进入详情页，再切到基础信息，最后还要猜那个灰色的小铅笔到底能不能点。

最离谱的是，你去问客服，客服通常会发来一段这样的回复。

请点击左侧设置，在账户管理中选择权限配置，然后进入高级选项。。。

看完以后，人更懵了。

文档也有，客服也回了，按钮还是找不到。

我一直觉得，很多软件真正缺的不是更多帮助文档，而是一个坐在旁边、能直接替你操作的人。

然后我看到了 Page Agent。

这个由阿里巴巴开源的项目，想做一件很具体的事，把一个 AI 操作员直接装进网页里。

用户不用学习菜单，也不用背产品术语，只需要说一句，把这份报销单提交给直属主管。

接下来，Agent 自己读取页面，找到对应字段，填写表单，点击按钮，再根据页面反馈继续往下走。

不是教你点。

是它替你点。

图 1 Page Agent GitHub 仓库首页

一个住在网页里面的 Agent

Page Agent 的官方定位，是一个纯 JavaScript 实现的页面内嵌式 GUI Agent。

它主要服务的对象不是爬虫开发者，也不是想在外面遥控浏览器的人，而是网站和 Web 应用的开发者。

开发者把它接进自己的网页，用户就能通过自然语言与现有界面交互。

截至 2026 年 9 月初，这个仓库已经获得大约 2.9 万颗 Star 和 2500 多个 Fork，采用 MIT License，主要语言是 TypeScript。最新正式版本为 v1.12.2，仓库在 8 月底仍有提交，说明项目还在持续维护。

它最吸引人的那句话是，一段脚本，让任何网页拥有自己的 AI Agent。

听着多少有点广告味。

但顺着它的实现方式往下看，会发现这个项目确实选了一条很特别的路线。

如今很多网页 Agent 都像一个坐在屏幕外面的机器人。

它先给网页截图，再让多模态模型从图片里找按钮，最后通过浏览器自动化工具移动鼠标、点击坐标。

Page Agent 没有这么做。

它就住在网页里面。

所以它不需要猜屏幕上哪一块像按钮，也不需要每一步都截图。它可以直接读取页面的 DOM，也就是浏览器已经解析好的网页结构。

标题是什么，输入框是什么，按钮能不能点，当前表格有哪些内容，这些信息本来就存在网页代码里。

Page Agent 会把复杂 DOM 进行压缩和脱水，把装饰、样式和大量无关节点剔掉，只留下和任务相关的文本及可交互元素，再交给语言模型理解。

模型不需要看一张两百万像素的截图。

它拿到的更像是一份网页骨架。

登录按钮，输入框，订单列表，下一页。

干净，直接。

这也是它和昨天介绍的 Open-AutoGLM 最明显的区别。Open-AutoGLM 面对的是手机屏幕，它需要用视觉模型去理解一个外部界面。Page Agent 已经身处网页内部，可以直接读取浏览器理解过的结构。

一个在屏幕外看图。

一个在页面里读 DOM。

目标都叫 GUI Agent，但走的是两条完全不同的路。

图 2 Page Agent 官方 README，强调 Agent 直接运行在网页中

它是怎么把一句话变成一串点击的

假设你正在使用一套企业客户管理系统。

你输入一句，把华东区本月还没有回款的客户筛选出来。

Page Agent 会先分析当前页面中可用的元素和信息，把页面状态连同任务发给模型。

模型根据目标生成下一步工具调用，可能是选择华东区，可能是填写日期，也可能是点开回款状态下拉框。

页面执行操作以后，Agent 再读取更新后的 DOM。

如果筛选条件已经生效，它继续下一步。

如果弹出了确认框，它处理弹窗。

如果目标已经完成，它结束任务并返回结果。

整个过程仍然是 Agent 常见的观察、判断、执行、再观察。

不同之处在于，它的观察对象不是截图，而是文本化的页面结构。

这带来了几个很现实的好处。

模型输入通常更紧凑，不必消耗大量 token 去描述像素。文本定位也更稳定，不会因为浏览器缩放、主题颜色或分辨率变化，就突然认不出同一个按钮。

而且它不依赖 Python、无头浏览器或默认安装的浏览器插件。对于只需要操作当前页面的场景，Agent 就运行在页面自己的 JavaScript 环境里。

这点挺关键。

传统浏览器自动化更像一个外部工作人员，拿到浏览器控制权以后，去访问不同网站、打开不同标签页，再完成一套流程。

Page Agent 的默认形态更像网站自己雇了一名员工。

它熟悉当前页面，也只在当前页面工作。

所以官方一直强调，这个项目是为客户端网页增强而设计的，不是服务端自动化工具，也不是用来替代所有爬虫和浏览器 Agent 的。

这个边界讲得很清楚，我反而更喜欢。

图 3 Page Agent 官网任务输入界面，用户可直接用自然语言下达网页操作指令

最适合它的地方，不是普通博客

如果一个网页只有三篇文章和一个搜索框，给它加 Agent 多少有点用大炮打蚊子。

Page Agent 真正容易发挥价值的，是那些功能很多、操作很深、用户又不得不用的系统。

ERP、CRM、财务后台、项目管理平台、内部工单系统。

这些软件最常见的问题不是功能不够，而是功能太多。

一个刚入职的员工，可能要跟着同事学两天，才能弄明白怎么创建客户、分配权限、提交审批。操作步骤一旦变化，旧教程和录屏又会立刻过期。

如果页面里住着一个 Agent，用户就不一定要先理解软件的组织结构。

他可以直接描述结果。

创建一个新的供应商档案，把合同日期设为今天，提交给采购经理审核。

Agent 再把这个目标翻译成一连串页面动作。

这时候，软件的入口就从菜单变成了意图。

客服场景也一样。

过去的答疑机器人只能告诉用户去哪里点。接入 Page Agent 之后，它有机会把那句请进入设置页面，变成我现在帮你完成。

产品教学也会发生变化。

新用户不再只看一段录屏，而是让 Agent 在真实页面里演示一次怎么提交报销。看完以后，页面状态也已经走到了正确的位置。

还有一个很容易被忽略的方向，是无障碍。

对于视障用户、老年用户，或者不熟悉复杂软件的人来说，自然语言不是一个花哨入口，而可能是能否独立使用这套系统的差别。

按钮层级再深，菜单名字再拗口，最终都可以被压缩成一句人能听懂的话。

这块我是真的觉得有价值。

一行代码可以体验，但生产环境不是一行代码

Page Agent 的体验门槛确实很低。

官方提供了一段 CDN 脚本，放进页面就能加载带免费测试模型的 Demo Agent。

<script  src="https://registry.npmmirror.com/page-agent/1.12.2/files/dist/iife/page-agent.demo.js"  crossorigin="anonymous"></script>

这适合快速验证一个页面能不能被操作。

正式项目更适合通过 NPM 安装。

npm install page-agent

然后创建 PageAgent 实例，接入符合 OpenAI 接口规范、并支持 tool call 的模型。

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: 'zh-CN',})await agent.execute('点击登录按钮')

官方列出的模型范围很广，Qwen、OpenAI、Claude、Gemini、DeepSeek、GLM、Kimi、MiniMax 和 Grok 都有对应型号。

但支持不代表效果完全一样。

Page Agent 很依赖模型的 tool call 能力。格式能力弱的模型容易生成错误调用，小模型也可能在复杂页面里顾此失彼。官方建议优先选择速度快、工具调用稳定的模型，本地部署则可以接 Ollama 或 LM Studio。

本地模型还要注意上下文长度和 CORS。普通页面的提示内容可能达到一万五千 token 左右，默认四千上下文很容易被截断。官方文档建议至少配置八千，并明确提醒，小于 10B 的模型通常效果不佳。

然后是最容易踩坑的一件事。

千万不要把真实的 LLM API Key 写进公开的前端代码。

浏览器发出去的请求，用户是可以查看的。把密钥直接打包进 JavaScript，和把家门钥匙贴在门口没有太大区别。

如果要把 Page Agent 集成进生产环境，官方建议增加后端代理，由后端转发模型请求，再通过 Cookie 或其他方式做鉴权。

所以，一行代码解决的是体验入口，不是完整的生产安全。

这两个概念得分开。

只在当前页面，还不够怎么办

页面内运行让 Page Agent 变得轻，也给它画了一条边界。

默认情况下，它最擅长当前页面里的操作。

但真实任务经常会跨页面。

搜索商品以后打开详情页，提交资料以后跳转审批页，查完订单还要去另一个标签页核对物流。

为了解决这类任务，项目提供了一个可选的 Chrome 扩展。

PageAgent.js 仍然负责页面内自动化，扩展则补上跨标签导航、页面切换和浏览器级控制。用户授权以后，页面 JavaScript、本地 Agent 或云端 Agent 都可以通过扩展发起多页面任务。

项目还提供了处于 Beta 阶段的 MCP Server。

装好 Page Agent 扩展，再把 @page-agent/mcp配置到本地 Agent 客户端，Claude Code、Codex 或其他支持 MCP 的工具就有机会把自然语言浏览器任务发送给 Page Agent。

这条链路有点意思。

网页里的 Agent，不再只听网页用户的指令，也可以成为外部 Agent 的一双手。

不过权限随之变大。

扩展可以访问页面、导航和控制多个标签页，如果授权令牌落到不可信页面手里，隐私风险会非常直接。官方因此用 Token 保护调用能力，并要求用户只把 Token 提供给可信应用。

能控制得越多，越要清楚是谁在控制。

Agent 产品最后绕不开的，永远是这句话。

它不会因为会读 DOM，就永远不犯错

Page Agent 不使用截图，确实绕开了一部分视觉识别问题。

可 DOM 也不是一块永远干净的土地。

有些网页把关键内容画在 Canvas 里，有些交互藏在 iframe 或 Shadow DOM 中，有些组件的语义标记做得很差。页面虽然看起来像一个按钮，代码里却可能只是套了几层 div。

这时，模型拿到的结构未必比人眼看到的更清楚。

复杂页面还会带来上下文膨胀。DOM 节点越多，模型需要理解的内容越长，速度、成本和判断稳定性都会受到影响。

再加上 Agent 本身会规划错误，可能点错按钮，可能重复尝试，也可能在表单里填入不合适的内容。

所以，涉及删除、支付、发布、权限修改和批量操作时，开发者仍然需要设计确认步骤、操作白名单、数据脱敏和停止机制。

Page Agent 官方也提供操作黑白名单、自定义知识和数据保护方向的配置能力。

但框架提供能力，不代表安全策略会自动长出来。

最终哪些动作可以直接执行，哪些必须让用户确认，还是产品团队自己的责任。

我还没有把 Page Agent 接进自己的生产网站，跑完一套真实用户流程。因此这篇写的是基于官方仓库和文档的项目拆解，不是一次完整压力测试。

2.9 万颗 Star 很亮眼，项目也已经迭代到 v1.12.2，但它仍主要由作者 Simon 独立维护。维护者公开说明，资源有限，希望项目保持开放、轻量和可持续。

这也提醒我们，开源项目的热度和商业级服务保障不是一回事。

正式接入之前，该有的兼容性测试、权限审计和失败兜底，一个都不能少。

以后还需要软件说明书吗

我有时候觉得，图形界面过去四十年的核心逻辑，是让人去适应软件。

软件把能力藏进菜单、按钮和表单，人去学习这些入口在哪里，叫什么名字，应该按什么顺序操作。

帮助中心、教学视频、客服话术，都是在帮助人记住这套规则。

Page Agent 代表的是另一个方向。

软件开始主动理解人的目标，再用自己已有的界面完成任务。

它没有推翻原来的网页，也没有要求开发者重写一套 AI 原生产品。那些菜单、按钮、表格和审批流仍然存在，只是上面多了一层自然语言入口。

旧系统不必一夜重生。

先让 Agent 学会使用它就行。

这可能才是 Page Agent 最有意思的地方。

它不是再造一个浏览器，而是让每个网页有机会学会操作自己。

以前用户打开后台，面对的是一张功能地图。

以后用户打开同一个后台，可能只需要说一句，我想完成什么。

剩下的路，网页自己走。

到了那一天，最先失业的也许不是程序员。

是那份写了两百页、打开率不到百分之一的软件使用手册。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧。如果想第一时间收到推送，也可以给我个星标。

谢谢你看我的文章，我们，下次再见。

/ 作者，徐某人

/ 投稿或爆料，请联系邮箱，x17513604077@gmail.com

项目地址，Page Agent  https://github.com/alibaba/page-agent