先说两个画面。

一个是后台运营。 每天早上要做同一件事：把前一天的两百多条订单，逐条改成“已发货”。每条要点开、改两个下拉、填一个单号、点保存。一条二十秒，一轮下来一个多小时。做到第一百条的时候，手一抖改错行的概率明显往上升。

一个是研发测试。 每次发版前，要把三十个功能点挨个点一遍，看有没有被改坏。这件事有个正式名字，叫回归测试。点完还得截图留证，不然说不清验的是哪一版。

两件事的共同点很扎心：操作本身没有技术含量，但不能不做，而且只能靠人一条一条点。

为什么只能靠人？要么系统根本没有接口可调；要么有接口，但得写脚本——而脚本很脆，页面一改就得重写，对“只做一次”的活也不划算。

现在多了第三条路：让 AI 打开浏览器，替你点。

这里得说清一件事：这些系统不是“忘了给程序留接口”，而是做出来的时候，还没有 AI 这个用户。界面就是给人点的，压根没打算让程序去调它。等 AI 能读文档、能调接口了，存量系统也不会为了它重新改造——成本摆在那儿。有些新系统已经开始补（发 API token、接 MCP），但大多没有。

这篇讲三件事：什么场景值得这么干、怎么把它跑通（这部分可以直接照着做）、它凭什么能成。核心一句话：你负责说要什么，AI 负责怎么点。

一、什么情况值得让 AI 去点网页

开场那两件之外，这几种也值。

场景 具体长什么样 值得吗
没有接口的老系统 内部 OA、财务系统、上世纪的 ERP，只有网页 值
给系统补接口文档 一个没人写文档的系统，想知道它到底调哪些接口、传什么参数 很值
跨系统搬数据 A 后台导出的表格，逐条录进 B 后台 值，但要人看一眼结果
只有界面上才有的信息 某个后台的报表，没有导出功能，只能看屏幕 值，但别指望从图表里读数字

反过来，两种情况最好别用：

  • 系统本身有接口。有接口就用接口，一条命令的事，比开浏览器快得多。
  • 同一个流程要反复跑。第一次用 AI 摸清楚，之后应该写成脚本。原因最后一节说。

二、开始之前：两件准备

1. 装（一次性）

需要先有 Node.js，官网下载安装包即可。下面两条命令在 Mac 的终端、Linux 的 shell、Windows 的 Git Bash 里都能跑——Windows 上建议直接用 Git Bash 或 WSL。

1
2
npm i -g agent-browser
agent-browser install

第一条装工具，第二条下载它要用的浏览器。机器上已经有 Chrome 的话，第二条通常也能过。

如果你一点命令行都不想碰，把这一节交给身边会的人做一次就行。后面全是给 AI 下指令，不用自己敲。

2. 给它一个固定的“浏览器身份”

这一步最容易被忽略，但它直接决定你以后要不要天天扫码。

浏览器记住登录状态，靠的是一个本地目录——里面放着 cookie 这类凭证，通常叫 profile。同一个 profile 再打开同一个网站，就还是登录状态。

别拿你日常用的 Chrome 目录去凑。 两边存的钥匙不是一套，拷过去读不出登录信息，等于白拷。

正确的做法是给它单独一个目录：

1
agent-browser --profile ~/.cache/ab-profiles/my-app open https://your-app.com

第一次打开，手动登录一次。扫码、输密码、过短信验证都行——只有这一次。之后用同一个 profile 再开，直接就是登录好的页面。

三条经验：

  • 一个站点一个 profile。混着用会把不同站点的凭证搅在一起，出问题很难查。
  • 换电脑、换目录，通常会要求重新登录。跨机器搬运我们没验证过，稳妥做法就是重登一次。
  • 这个目录等于你的登录凭证。别提交到 git，也别随手发给别人。

另外，用完记得关掉（agent-browser close）。这是个习惯问题：不关它就一直是个后台进程。

三、把活交给 AI：一次完整执行

先看一张图，知道谁在跟谁说话。

人、AI、agent-browser 和浏览器的关系

你只说目标；AI 看清单、动手；工具负责把编号变成真实点击，再把清单、截图、接口记录递回去。

人在这件事里只做两件事：开头说清目标，结尾验收结果。中间所有动作都是 AI 做的。

你实际要做的，就是把目标说清楚。比如：

打开 http://localhost:5173，用 admin / 123456 登录，建一个叫“测试”的项目，加一个成员“张三”，记一笔 50.5 元的交通费。做完把列表截图和这次调用的接口给我。

它会把这句拆成一串动作。干活循环说白了四步：

1
看一眼页面清单  →  挑一个编号动手  →  再看一眼确认  →  不对就查原因、重来

举个真实的例子。我只说了“在这个费用系统里记一笔 50.5 元的交通费”，它自己走完了这些：

步骤 AI 自己做了什么
1 打开页面，发现跳到了登录页；读清单，看到“用户名”“密码”“登录”三个编号
2 填账号密码，点登录
3 页面变了，重新读一遍清单（编号全变了，旧的不能用了）
4 点“创建项目”，弹出对话框，填名字，点创建
5 进账本点“新增费用”，发现付款人下拉是灰的，旁边写着“请先添加成员”——于是先去加成员
6 回来填金额 32+18.5（系统会自己算出 50.50），选类型，选付款人，保存
7 回头核对：列表显示“共 1 笔 · 合计 ¥50.50”

第 5 步值得多看两眼：没人告诉它要先加成员，它是从页面上的提示读出来的，自己改了顺序。

跑完之后，它把这张截图和这次调用的接口记录一起交回来：

账本页截图：一笔 50.50 元的交通费已经记上

出错的时候，它是怎么自己爬起来的

这是 AI 和脚本最大的区别：脚本碰到意外就崩，AI 会读错误、换策略。

比如它想点一个被弹窗盖住的按钮，工具不会硬点，而是告诉它：

1
Element 'button' is covered by <div#overlay> at its click point...

AI 读完这句，明白是遮罩挡住了，于是先去关弹窗，回来再点。整个过程不用人插手。

再比如它拿着一个过期的编号去点，会被告知“找不到这个编号”——它就知道该重新读一遍清单，而不是硬试。

什么时候该人介入？三种：

  • 它在同一个地方反复打转（说明那个控件它没看懂，你得给点线索）
  • 操作不可逆、代价高（删除、付款）——让它停下先给你看
  • 结果看着对，但你不放心——去看截图和接口记录

四、为什么这样能成：三个真实的难题

难题一：页面太大，AI 读不完

我量了一个普通网页的源码：1.29 MB，四千多个元素。换算成 token 大约 32 万（按 4 个字符约 1 个 token 粗估），比大多数模型能读的还多。里面九成是样式名、图标数据这类噪音。

类比一下：你要找三楼会议室，别人把整栋楼的施工图全给你。

所以工具只给“清单”。同一份界面，两个数字摆一起：

页面 源码大小 清单大小
一个文档站 1.29 MB 18.7 KB
一个后台管理页 127 KB 1.5 KB

后台那行值得多看两眼：源码 127 KB，清单 1.5 KB，差了八十多倍。

难题二：光看得懂不够，还得点得准

说“点保存”，比说“点坐标 (640, 480)”靠谱得多。编号就是这个道理。

坐标本身也不稳：窗口大小、页面缩放、滚动位置，任一样变了，同一个按钮的坐标就跟着变。编号不会。

而且它发的是浏览器级别的鼠标事件，和真人点击一样，页面分不出真假。有些组件只认这个。

难题三：做完得能证明

人跟你说“办好了”，你会要个回执。AI 也一样：截图、请求记录、接口返回，这三样就是回执。

顺带说个反直觉的设计：截图默认只存到硬盘，不进模型的上下文。这是故意的——看图很贵，多数时候你只需要它在那儿躺着，出事再翻。

五、它好在哪，和别人有什么不一样

同类工具不少，差别在于“给谁用”。

工具 是什么 给谁用
Selenium 老牌浏览器自动化库 写测试脚本的人
Playwright 现代浏览器自动化库 写测试、爬虫的人
Puppeteer Node 里控制 Chrome 的库 前端 / Node 开发者
Playwright MCP 把浏览器包成给 AI 用的工具 AI，开箱即用
agent-browser 一个命令行工具 让 AI 直接上手

前三个有个共同点：要你先写好“点哪个按钮”。页面一改，代码就得改。后两个是给 AI 用的，页面长什么样它自己看。

Playwright MCP 那类方案不是不行，而是“说明书”太厚：二十一个工具的定义就要一万三千多 token，还没干活先花掉一截。这个账我在另一篇里算过。

agent-browser 实打实的好处有四个：

  1. 一个命令装好，不写代码、不起服务、不需要项目依赖。
  2. 省 token。工具只有一份，页面只给清单。
  3. 登录态留得住。一个固定 profile，登录一次管很久。
  4. 证据齐。截图、请求记录、单条接口返回，都是命令级别的事。

六、几个坑：人要知道的，和要写给 AI 的

先说个容易忽略的地方：坑分两种，该记的地方不一样。

人的脑子里要记的（判断类）：

坑 怎么办
系统本身有接口 别绕浏览器，直接用接口
同一个流程要跑上好几遍 写成脚本，让 token 花销归零
一次流程几十万 token 只有一次性、判断类的事才划算
请求记录里有密码和 token 发出去之前先脱敏

要写给 AI 的（执行类）——写进你的指令、项目约定，或者固化成一个技能：

坑 给 AI 的话
有些表单填了不生效 填完做一次别的操作，回头确认值还在
图表上的数字读不出来 要数字去读接口，别看页面
在线画图、图表看板这类界面看不见内容 别硬点，改用应用自己的导出功能
测试数据会污染统计和分页 用完删掉，把数量还原

差别在于：人会忘，AI 每次都会照做。把坑写成“给 AI 的约定”，比记在人脑子里可靠得多。

收个尾

  • 系统是为“人”造的，AI 是后来的用户，改造要时间——浏览器是现在唯一不用改造就能用的入口。
  • 用法上人是指挥、AI 是执行：你说目标，它看清单、动手、出错自己重来，最后把证据交给你。
  • 真正省事的方向是系统自己把能力交给 AI，但存量系统改造慢，这个过渡期会很长。

在那之前，会让 AI 用浏览器的，比不会的，能干的活多一个量级。

附录：手动跑一遍（不经过 AI）

想先自己感受一下，或者要排查 AI 到底卡在哪一步，可以手动走一遍。

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
# 1. 装（只装一次）
npm i -g agent-browser
agent-browser install

# 2. 用固定身份打开（第一次要手动登录）
agent-browser --profile ~/.cache/ab-profiles/my-app open http://localhost:5173

# 3. 看清单，拿到编号
agent-browser snapshot -i

# 4. 填账号密码、点登录（编号换成你看到的）
agent-browser fill @e5 "admin"
agent-browser fill @e6 "123456"
agent-browser click @e3

# 5. 页面变了，重新看一遍清单
agent-browser snapshot -i

# 6. 接着点：建项目、填名字、提交
agent-browser click @e19
agent-browser fill @e27 "测试项目"
agent-browser click @e26

# 7. 看它调了哪些接口
agent-browser network requests --filter api
agent-browser network request <上面列出的 requestId> --json

# 8. 留证据，然后关掉
agent-browser screenshot 结果.png
agent-browser close

这几处容易翻车，按命令顺序排：

  • 编号每次重看。页面一变就重排，拿旧编号去点会报“找不到”。
  • 填完做一次别的操作，再回头确认值还在。有些表单的表面值和真实状态不同步。
  • 从第 3 步起不用再带 --profile，浏览器一直在跑；但重新 open 时要带上。
  • 第 7 步的 requestId 换成 network requests 打出来的真实值，别照抄示例。
  • close 要执行，不然它一直是后台进程。

上面这些命令，就是 AI 在第三节里替你敲的那些。