用 AI 代码智能体玩转浏览器自动化：一次真实任务的完整复盘

前言

最近几年，AI 编程助手从"代码补全工具"进化成了"自主执行任务的智能体"（Agent）。它们不再只是给出建议，而是能真正动手：读代码、跑命令、开浏览器、点按钮、填表单。本文记录一次真实任务的完整执行过程，包括踩过的坑和最终的解决方案，希望能给正在探索 AI 智能体的开发者一些参考。

任务背景

任务本身很典型：登录一个网站，进入指定页面，点击某个入口，提交一篇原创内容。这类"网页操作类"任务在日常工作里随处可见——签到打卡、数据录入、内容发布、定时巡检。人工做一次不难，但"每日一次"的重复劳动最适合交给自动化。

传统的做法是写 RPA 脚本或 Selenium/Playwright 脚本。而这次我尝试换一种思路：让 AI 智能体自己"看着"页面、自己决策下一步做什么，我只负责在关键节点（比如身份验证）确认。

环境准备：三个意想不到的坑

坑一：CLI 工具的版本断层

我使用的浏览器自动化 CLI 工具在执行过程中经历了一次大版本升级：旧版本的子命令（open、state、click）被彻底移除，取而代之的是"把原始 Python 通过 stdin 管道进来执行"的新模式：

browser-use <<'PY'
new_tab("https://example.com")
wait_for_load()
print(page_info())
PY

这种设计的哲学变化很有意思——从"命令封装"转向"代码即指令"。对 AI 智能体来说这反而是好事：与其记住几十个子命令的参数，不如直接写几行 Python。工具越贴近编程原语，智能体的容错空间越大。

坑二：无显示器服务器上的浏览器检测

自动化守护进程启动时，会通过扫描浏览器 profile 目录里的 SingletonLock 来判断"是否有浏览器在运行"。但我手动启动的 headless Chromium 使用的是独立的用户数据目录，不在扫描范围内，于是守护进程直接报错退出。

解决方案是通过环境变量直接指定 CDP（Chrome DevTools Protocol）端点：

export BU_CDP_URL=http://127.0.0.1:9222

这给了我们一个通用启示：当自动发现机制失效时，显式声明依赖端点永远是最可靠的兜底方案。

坑三：Canvas 绘制的二维码无法解码

登录页的二维码不是 img 标签，而是 canvas 实时绘制的。常规的图片抓取拿不到内容，OpenCV 的 QRCodeDetector 对 152×152 的小图直接解码失败。

解决分两步：

1. 调用 canvas 的 toDataURL() 导出为 base64 PNG；
2. 放大 4 倍 + 近邻插值后，用 zxing-cpp 成功解码。

import cv2, zxingcpp
big = cv2.resize(img, None, fx=4, fy=4, interpolation=cv2.INTER_NEAREST)
results = zxingcpp.read_barcodes(big)

小尺寸二维码是解码失败的常见原因。先放大再解码，是处理 canvas 二维码的标准姿势。

关键设计：把身份验证交还给人

整个任务里最重要的决策是：遇到登录墙就停下来，把控制权交还给用户。

我尝试过让智能体"自动填写账号密码"，但这带来两个问题：

• 凭据会经过对话上下文，存在泄露风险；
• 登录页常有验证码、二次确认等人机校验，强行绕过既困难又危险。

更优雅的模式是"扫码代理"或"验证码代理"：智能体负责打开页面、定位输入框、触发验证码发送，人类只需要扫一下码或念一下验证码，智能体轮询登录状态，登录成功后自动接管后续流程。人负责身份，AI 负责操作——这条边界划清楚之后，安全性和自动化程度可以兼得。

页面交互：可访问性树优于截图

对无图像识别能力的环境，AI 智能体操作页面最可靠的方式是 CDP 的可访问性树（Accessibility Tree）：

tree = cdp("Accessibility.getFullAXTree")["nodes"]
for node in tree:
    role = node["role"]["value"]
    name = node["name"]["value"]

拿到目标节点的 backendDOMNodeId 后，再通过 DOM.getBoxModel 算出坐标中心，用 click_at_xy(x, y) 点击。这条链路完全不依赖视觉，比截图+图像识别更稳定，也不会被 CSS 动画、懒加载干扰。

另一个容易被忽视的细节：页面底部的 Cookie 提示横幅可能悄悄挡住登录按钮，导致点击"无反应"。用 elementFromPoint 检查点击目标位置的真实元素，是排查这类"幽灵遮挡"问题的最快方式。

总结与心得

复盘整个过程，有几点值得沉淀：

1. 环境问题是自动化的头号杀手。三次卡壳全部出在环境（CLI 版本、浏览器检测、二维码渲染），没有一次出在业务逻辑上。做自动化之前先跑通"Hello World"能省下大半时间。
2. 工具的容错设计决定智能体的上限。显式端点声明、原始代码管道、可访问性树，这些"低级但确定"的接口，比"高级但脆弱"的封装更适合 AI 调用。
3. 人机边界要提前设计。登录、支付、删除这类敏感操作，一开始就规划成"人工确认点"，比事后补救安全得多。

AI 代码智能体正在把"想法到落地"的距离缩到最短。但真正让它可靠的，是每一次踩坑之后沉淀下来的工程经验。希望这篇复盘对你有帮助。