阿里开源了个＂懒人神器＂:让 AI 替你填表,你去喝咖啡

你公司的 CRM 或者 ERP，是不是那种打开就让人窒息的那种？

我说的是真的字面意思——三十个字段，字段旁边套字段，下拉菜单套下拉菜单，光是找”联系人新建”按钮就要点四层菜单。

最近我翻到 Bridgers 这家法国数字代理公司写的测评时，他们量过一个数据：在他们日常对接的 ERP 系统里，建一条新联系人记录平均要花 3 分钟。三分钟，按一天操作 30 条算，就是 90 分钟。一天一半的下午就没了，全填表了。

然后他们接入了 page-agent。

同样的操作，现在的流程是：在 AI 面板里打一句话，”帮我建个新联系人，张三，销售总监，邮箱 zhang@xxx.com”，然后等 35 秒。

35 秒。表填完了。

说回这个项目本身。

Page-Agent，阿里巴巴出品，2026 年 3 月 15 日在 GitHub 上线就直接冲上热门，到我写这篇的时候（2026 年 3 月 19 日），Star 数已经过万（10k+），Fork 774，最新版本 v1.5.8 发布于 2026 年 3 月 16 日。更新节奏非常猛，基本上隔几天就有一个小版本推出来。

它到底做了什么？跟你印象里的”AI 操控浏览器”不一样

如果你之前听过 browser-use，或者 Playwright（网页自动化测试框架），会下意识以为 page-agent 是同一条路子——用 Python 写脚本，跑个无头浏览器（Headless Browser，就是没有图形界面的浏览器进程），AI 截屏，然后识别截图里的按钮在哪、点哪里。

不是。

Page-Agent 完全不截屏，不用 Python，不开无头浏览器。

它是纯 JavaScript，活在网页内部。用开发者的话说，”The GUI Agent living in your webpage”——AI 不是从外面遥控你的浏览器，而是住在网页里，直接读 DOM（文档对象模型，就是网页内部的元素树结构），知道这个页面上每个按钮、每个输入框叫什么、在哪里、现在是什么状态，然后直接操作。

这个区别大不大？对用户感知来说差别不明显，但对接入门槛来说是天壤之别。

browser-use 那套路子，得在服务端跑 Python 环境，要装依赖，要有无头浏览器进程，还要调用多模态模型（能”看图”的那种 AI）。成本高，复杂度高，不是 SaaS 厂商可以随手塞进产品里的东西。

page-agent 的最小集成方式，就是在你的网页里加一段 JS，连接你自己的 LLM 接口（支持 GPT、Claude、通义千问，凡是兼容 OpenAI API 格式的模型都行），完事。不用改后端，不用申请什么特殊权限。

关系顺便理一下：page-agent 的 DOM 处理组件和部分 prompt 源自 browser-use 的开源代码，README 里有明确的致谢声明。两者不是竞争关系，是分工不同——browser-use 做的是服务端自动化，page-agent 做的是客户端页面增强。

三类人最该盯着这个项目

第一类：SaaS 产品经理。

给自家产品加一个 AI Copilot（AI 副驾驶功能），通常意味着什么？意味着排期、后端改造、可能还得引入一个新的 AI 服务，几个月是少说的。

page-agent 把这个流程压缩成了前端几行 JavaScript。理论上，一个产品经理把需求丢给前端工程师，一周内可以上线一个能用自然语言操控界面的功能。不用动后端，不用新基础设施。

当然”理论上”这三个字很重要，后面说坑的时候会再提。

第二类：每天对着 ERP/CRM 表单填数据的人。

销售、行政、财务，这些岗位每天有相当比例的时间是在做”把信息从一个地方复制粘贴到另一个地方”这件事。

如果你们的系统已经接入了 page-agent，或者将来接了，使用体验的变化会是——你不再需要记住字段在哪里，不需要知道下拉选项叫什么，一句话说清楚你要做什么，AI 帮你执行。按 Bridgers 团队的数据，测试场景的编写时间也从 20 分钟降到了 7 分钟。

第三类：前端开发。

“AI 集成工程师”这个方向越来越清晰了。会把 page-agent 这类工具嵌入客户管理系统、会调试 DOM 识别问题、会对接各家 LLM 接口的前端工程师，在接下来两三年里会有很具体的市场需求。这不是我瞎说，Bridgers 在测评最后明确写了：他们决定把 page-agent 永久集成进自己的工作流，并且在为客户做方案时开始主动推荐这套路径。

坑和边界，说清楚比较负责

好，夸完了说坑。我觉得这种开源项目如果不说清楚限制，读者拿去用了踩坑会觉得被骗，这不好。

坑一：React 重度虚拟化组件和 Shadow DOM 可能识别不了。

Shadow DOM（影子 DOM，一种 Web 组件封装技术，把内部结构隐藏起来的那种）是 page-agent 目前的识别盲区。如果你们的系统恰好大量用了这种组件，可能会遇到 AI 找不到目标元素的情况。测试时先确认你的目标界面用了哪些组件库，别一上来就做生产部署。

坑二：不装 Chrome 扩展，只能操作当前单页面。

page-agent 本体只处理你当前所在的那个页面。跨页面、跨标签页的工作流，需要额外安装 Chrome 扩展（Chrome Web Store 已有上架，评分 4.9 分）。如果你的业务流程需要 AI 在多个页面之间跳转操作，这个扩展是必须的，不是可选的。

坑三：社区还年轻，文档不如 Playwright 完善。

截至 2026 年 3 月，核心贡献者大约 9 名，文档覆盖主要功能但深度不够。Playwright 那种级别的文档和社区沉淀 page-agent 还差得远。生产环境要接，做好自己踩坑的心理准备，或者等社区再成熟半年。

坑四：API 费用不在项目内。

page-agent 是”Bring Your Own LLM”（自带语言模型）架构，你得自己配 API Key。用 GPT、Claude 还是通义千问随你，但 token 费用自己出。演示版有一个 Demo LLM 可以免费试，但官方说明写清楚了”仅供技术评估”，不能用在正式场景里。

为什么在这个时间点写它

有个很直白的原因：国内目前对 page-agent 的深度报道非常少，大多数还停留在”阿里出了个 AI 网页工具”这个层面，没有把它跟 browser-use 的技术差异讲清楚，也没有把适用人群说具体。

但这个工具的潜力比它目前的热度要高。

说白了，现在大多数 SaaS 产品里的 AI 功能，要么是嵌了个聊天问答，要么是加了个自动生成文案。真正能”理解你要干什么然后替你操作界面”的，很少。page-agent 做的这件事，是在尝试把这个能力做成一个可插拔的通用模块——任何产品都能接，不管你用什么技术栈，只要是跑在浏览器里的页面。

这个方向如果跑通，影响面比大多数人现在意识到的要大。

当然，一万个 GitHub Star 离”跑通”还有距离。但阿里这块招牌和 MIT 协议的组合，至少保证了这个项目短期内不会突然消失或者改收费。这一点在选工具时是有价值的。

项目地址：https://github.com/alibaba/page-agent