L5-18：命令行浏览器操控 —— 用代码指挥浏览器自动干活

🎯 学什么：在终端里用命令操控浏览器——打开网页、点击按钮、输入文字、截屏保存、提取数据。不需要鼠标，不需要打开 Chrome，一个命令一行操作，像操控机器人一样操控浏览器自动完成任务。核心洞察：(1) 守护进程架构让延迟从秒级降到 50ms——不是每次操作都启动浏览器，而是浏览器常驻后台；(2) S-I-A-V 工作流（State→Interact→Again State→Verify）是整个 Skill 的黄金法则——每步必须先"看"再"点"，就像开车先看后视镜再并线；(3) 本地和云端是一套接口——这是 browser-use 设计最优雅的地方。 💡 难易度：⭐⭐⭐ | ⏱️ 预计时间：40 分钟

---

1. 课程概览

💡 白话小课堂：想象你有一个隐形的机器人秘书。你对它说"打开淘宝、搜索'蓝牙耳机'、点击第三个商品、截图、关闭浏览器"——它就在后台默默帮你做了，而你可以去喝杯咖啡。browser-use 就是这个机器人秘书——用命令行操控浏览器，不需要鼠标，不需要打开 Chrome 窗口。

来源：browser-use 团队 / https://github.com/browser-use/browser-use

---

2. 守护进程架构：为什么延迟只有 50ms

2.1 传统方式 vs browser-use 方式

传统方式：每次操作 → 启动浏览器 → 执行 → 关闭浏览器
  → 浏览器启动时间：2-5 秒（秒级延迟）
  → 每步操作都重新启动 → 80% 时间花在启动/关闭上
  → 就像"每次上厕所都买一个新马桶，用完就扔"

browser-use 守护进程方式：启动守护进程 → 浏览器常驻 → 每次操作瞬间执行
  → 命令间延迟：约 50ms（毫秒级——比眨眼快 5 倍）
  → 浏览器保持打开状态，状态持久化
  → 就像"买一个马桶，一直用"

架构优势：
  → 命令行浏览器自动化变得实用可行
  → 多步骤脚本流畅执行，没有启动等待
  → Cookie/登录态在命令间保持

2.2 四种浏览器模式

browser-use 提供四种运行模式：

模式 1：无头模式（默认 Headless）
  → 浏览器在后台静默运行，不弹窗口
  → 适合：生产运行、定时任务、CI/CD
  → 命令：browser-use open <url>（默认无头）

模式 2：headed 模式（可视化调试）
  → 你能看到浏览器窗口，实时观察机器人操作
  → 适合：开发新脚本、调试
  → 命令：browser-use --headed open <url>
  → 调试效率比无头高 10 倍——能看到页面加载不全、元素错位

模式 3：connect 模式（连接已有 Chrome）
  → 连接你日常使用的 Chrome，带着所有登录态和 Cookie
  → 适合：需要登录才能操作的网站（省去重新登录）
  → 命令：browser-use --connect <index> open <url>

模式 4：cloud 模式（云端浏览器）
  → 浏览器在云端运行，你的电脑关机也继续跑
  → 适合：长时间任务、大规模并发
  → 命令：browser-use cloud connect

---

3. S-I-A-V 黄金工作流

3.1 每步操作的四段循环

S-I-A-V 是 browser-use 最核心的工作流法则：

Step 1：State（查看状态）
  browser-use state
  → 返回：当前 URL、页面标题、所有可交互元素及其索引
  → 每个可交互元素有一个唯一的数字索引（1, 2, 3...）
  → 就像进入房间先开灯——看清所有可操作的东西

Step 2：Interact（执行交互）
  browser-use click 5        ← 根据 state 返回的索引操作
  browser-use input 3 "text"
  → 根据 Step 1 获取的索引精准操作
  → 不猜、不假设——索引是从 state 确认的

Step 3：Again State（再次确认状态）
  browser-use state
  → 操作后页面可能发生变化——元素增减、位置改变
  → 再次查看状态，为下一步准备
  → 就像开车并线后再看一次后视镜

Step 4：Verify（验证结果）
  browser-use screenshot
  → 截图验证操作结果
  → 确认预期效果达成

3.2 为什么必须先 state 再操作

跳过 state 的直接后果：

❌ 你认为第 3 个按钮是"确认" → browser-use click 3
   实际第 3 个按钮是"删除" → 灾难

跳过 state 的常见原因：
  1. "这个页面我很熟，我知道第几个按钮是什么"
     → 但页面可能因为 A/B 测试、版本更新、动态加载而变化
  
  2. "上一步 state 已经看过了，不需要再看"
     → 上一步的 state 是上一步的——页面在变化
  
  3. "先点一下试试，不行再说"
     → 在某些系统里，"点错了"是不可逆的（如点了"取消订单"）

State 命令返回所有可交互元素的索引和描述，
让你明确知道每个索引对应什么元素——这就是"安全网"。

---

4. 核心命令速查

4.1 导航和控制

# 页面导航
browser-use open <url>          # 导航到 URL
browser-use back                # 返回上一页
browser-use scroll down         # 向下滚（--amount N 指定像素）
browser-use scroll up           # 向上滚

# 标签页管理
browser-use tab list            # 列出所有标签页
browser-use tab new [url]       # 新标签页
browser-use tab switch <idx>    # 切换到指定标签页
browser-use tab close <idx>     # 关闭指定标签页

# 页面状态
browser-use state               # URL、标题、可点击元素索引+描述
browser-use screenshot [path]   # 截图（无路径输出 base64，--full 全页）

4.2 交互操作

# 基于索引的交互（索引来自 state 命令）
browser-use click <index>       # 按索引点击元素
browser-use click <x> <y>       # 按像素坐标点击（备选方案）
browser-use type "text"         # 向当前聚焦元素输入
browser-use input <idx> "text"  # 点击元素 → 清除 → 输入（推荐）
browser-use keys "Enter"        # 键盘按键
browser-use select <idx> "op"   # 选择下拉选项
browser-use upload <idx> <p>    # 上传文件
browser-use hover <index>       # 悬停
browser-use dblclick <index>    # 双击

# 数据提取
browser-use eval "js code"      # 执行 JavaScript，返回结果
browser-use get title           # 页面标题
browser-use get html            # 页面 HTML（--selector "h1" 限定范围）
browser-use get text <index>    # 元素文本内容
browser-use get value <index>   # 输入框当前值
browser-use get attributes <index> # 元素属性
browser-use get bbox <index>    # 元素边界框坐标

# 等待
browser-use wait selector "css"  # 等待 CSS 选择器对应的元素出现
browser-use wait text "text"     # 等待指定文本出现

# Cookie 管理
browser-use cookies get          # 获取所有 Cookie
browser-use cookies set <n> <v>  # 设置指定 Cookie
browser-use cookies clear        # 清除所有 Cookie
browser-use cookies export <f>   # 导出 Cookie 为 JSON 文件
browser-use cookies import <f>   # 从 JSON 文件导入 Cookie

# 会话管理
browser-use close                # 关闭当前浏览器
browser-use sessions             # 列出所有活跃会话
browser-use close --all          # 关闭所有会话

4.3 命令链和实用模式

# 命令可以用 && 串联
browser-use open https://example.com && browser-use state

# 表单填写一条龙
browser-use input 5 "user@example.com" && \
  browser-use input 6 "password" && \
  browser-use click 7

# 认证浏览（使用 Chrome 配置文件保持登录态）
browser-use profile list                    # 查看可用配置文件
browser-use --profile "Default" open <url>  # 已登录状态访问

# 暴露本地开发服务器
browser-use tunnel 3000                     # → https://abc.trycloudflare.com
browser-use open https://abc.trycloudflare.com

# 多会话并行（命名会话——每个独立浏览器实例）
browser-use --session scraper1 open <url>
browser-use --session scraper2 open <url>

# 多代理共享浏览器（--connect 模式）
INDEX=$(browser-use register)       # 注册获取索引
browser-use --connect $INDEX open <url>
# 每个代理有自己的标签页，写操作锁定标签页

---

5. 多代理与标签页锁定

5.1 标签页锁定机制

多代理共享一个浏览器时，标签页锁定机制防止冲突：

写操作锁定：
  → click、input、type、select、upload、keys
  → 执行这些操作后 → 该标签页"锁定"给当前代理
  → 其他代理只能对该标签页执行读操作

读操作不锁定：
  → state、screenshot、get text、get value、eval（只读 JS）
  → 执行这些操作后 → 标签页仍可被其他代理使用

常见踩坑：
  → 代理 A 做了 state（读操作，不锁定）
  → 代理 A 认为"这个页面我可以独占"
  → 代理 A 开始准备做 input
  → 但在 state 和 input 之间，代理 B 可能已经修改了同一个标签页
  → 因为读操作不锁定！

最佳实践：
  → 不要依赖"读操作后标签页不会变化"的假设
  → 需要独占的标签页：先做一个写操作锁定它
  → 或者给每个代理分配独立的标签页

---

6. 结构拆解：浏览器 CLI Skill 模板

---

7. 电商案例：竞品店铺价格变化自动截图监控

某拼多多店铺运营（主营手机配件——充电宝/数据线/手机壳，SKU 约 300 个）每天需要监控 6 个核心竞品店铺的价格变动——尤其是手机壳品类（周更款式，价格波动频繁，竞品经常在 3 天内从 ¥19.9 降到 ¥14.9 抢排名）。

手动巡店：开 6 个竞品店铺首页 → 点进「手机壳」分类 → 按销量排序 → 截取前 20 个 SKU 的价格 → 保存。每天耗时 35 分钟，且周五经常忘记做而导致周末被竞品价格偷袭。

用 browser-use CLI（CLI：命令行接口）构建自动巡店脚本：

#!/bin/bash
# 竞品价格监控：每天 9:00 / 14:00 / 20:00 自动运行三次

STORES=(
  "https://mobile.yangkeduo.com/mall_page.html?mall_id=4819237|配件大王"
  "https://mobile.yangkeduo.com/mall_page.html?mall_id=5821049|壳壳数码"
  "https://mobile.yangkeduo.com/mall_page.html?mall_id=3398765|潮壳工厂"
  "https://mobile.yangkeduo.com/mall_page.html?mall_id=7201934|闪魔旗舰"
  "https://mobile.yangkeduo.com/mall_page.html?mall_id=9154302|品胜专卖"
  "https://mobile.yangkeduo.com/mall_page.html?mall_id=2649081|第一卫"
)

TIMESTAMP=$(date +%Y%m%d_%H%M)
REPORT_DIR="/reports/price_monitor/${TIMESTAMP}"
mkdir -p "$REPORT_DIR"

# S-I-A-V 工作流每店执行
for store in "${STORES[@]}"; do
  URL=$(echo "$store" | cut -d'|' -f1)
  NAME=$(echo "$store" | cut -d'|' -f2)
  
  # S: State —— 进入店铺
  browser-use --session "patrol_${NAME}" open "$URL"
  browser-use wait selector "div.goods-list"  # 等待商品列表加载
  browser-use state
  
  # I: Interact —— 点击「手机壳」分类 tab
  browser-use click 4  # 第 4 个可交互元素 = 手机壳分类（由 state 返回确认）
  browser-use wait text "综合排序"
  
  # A: Again State —— 确认分类页加载后截图
  browser-use state
  browser-use screenshot "$REPORT_DIR/${NAME}_phonecase_top20.png" --full
  
  # 额外：点击「销量排序」截图一份（竞品爆款价格更关键）
  browser-use click 6  # 销量排序按钮
  browser-use wait text "共"
  browser-use screenshot "$REPORT_DIR/${NAME}_phonecase_bestseller.png" --full
done

browser-use close --all
echo "[$(date)] 6 店监控完成 → $REPORT_DIR" >> /var/log/patrol.log

带登录态的演进版本（获取会员价——有些店铺对登录用户显示更低价格）：

# 首次：用 Chrome 配置文件登录一次
browser-use --profile "BuyerAccount" open https://mobile.yangkeduo.com/login
browser-use input 3 "138****5678"  # 手机号
browser-use click 5                # 获取验证码
# ...手动输入验证码...
browser-use cookies export ~/cookies/pdd_buyer.json

# 后续每次：导入 Cookie 恢复登录态
browser-use cookies import ~/cookies/pdd_buyer.json
browser-use --profile "BuyerAccount" open <竞品店铺URL>

效果：

• 监控耗时：从 35 分钟/次（手动 6 店 × 2 截图）→ 2 分 30 秒（脚本全自动）
• 频率提升：从每天 1 次（经常忘记）→ 每天 3 次（cron job 9:00/14:00/20:00）
• 价格异动发现速度：一次 14:00 的截图发现竞品「壳壳数码」将 iPhone 15 Pro 液态硅胶壳从 ¥24.9 降至 ¥14.9——运营在 14:15 跟进调价至 ¥13.9（保毛利底线 15%），当天销量逆袭竞品 80 单。过去人工巡店只做一次，这个价格可能到第二天才发现，已经丢了一天窗口
• 截图可回溯对比——周五的截图 vs 周一的截图放在一个文件夹里，运营用文件名排序就能看出价格变化趋势

🔑 启示：电商竞品价格监控不是「做一次」——是「高频重复」。自动化的价值不是省那 35 分钟，而是把频率从 1 次/天提升到 3 次/天，把人的不确定性（周五忘了）变成脚本的确定性。S-I-A-V 工作流在此场景的价值：每个竞品店铺的 DOM 结构不同，state 返回的元素索引也不同——绝不假设「第 4 个永远是分类 tab」。

---

8. 掌握检验

Q1：browser-use 的守护进程（daemon）架构相比传统方式的优势是什么？

• A) 守护进程更安全
• B) 传统方式每次操作都要启动浏览器→执行→关闭浏览器（秒级延迟），守护进程让浏览器常驻实现约 50ms 调用延迟
• C) 守护进程使用更少的内存
• D) 传统方式不需要安装浏览器

Q2：S-I-A-V 工作流中，每一步代表什么？

• A) Start → Input → Action → Verify
• B) State → Interact → Again State → Verify
• C) Search → Inspect → Act → Validate
• D) Setup → Initiate → Apply → View

Q3：为什么每次交互前必须先运行 browser-use state？如果跳过这一步直接 click，可能会发生什么？

Q4：browser-use connect 和 browser-use --profile "xxx" 有什么区别？

Q5：浏览器四种模式（无头、headed、connect、cloud）分别适合什么场景？开发新脚本应该先用哪个模式？

Q6：标签页锁定机制如何工作？如果代理在标签页上只做了 state（读操作），标签页会被锁定吗？

Q7：请写出一个水果电商自动巡店脚本：打开后台 → 进入"订单管理" → 筛选"待发货" → 截图 → 关闭。

Q8：以下哪条不是 browser-use 的核心技巧？

• A) 始终先运行 state
• B) 用 --headed 调试
• C) 所有操作前先清除 Cookie
• D) 命令失败先 close 清理再重试

---

9. 答案

点击查看答案

Q1：B — 守护进程保持浏览器在命令之间持续打开，每次操作瞬间执行（~50ms），而传统方式每次都要重启浏览器。

Q2：B — State → Interact → Again State → Verify。核心原则是"先看再点"——就像开车先看后视镜再并线。

Q3：参考答案 — 跳过 state 的直接风险是"猜错了元素"——你认为第 3 个按钮是"确认"但实际是"删除"。页面可能因为 A/B 测试、版本更新、动态加载而变化。

Q4：参考答案 — --connect：连接当前正在运行的 Chrome（带着当前所有登录态）。--profile：启动新的 Chrome 实例，使用指定用户配置文件（配置文件中保存了之前登录过的 Cookie）。

Q5：参考答案 — 无头：生产运行；headed：开发调试（效率高 10 倍）；connect：连接已有 Chrome 保留登录态；cloud：云端运行。调试新脚本先用 --headed。

Q6：参考答案 — 写操作（click/input/type/select/upload/keys）锁定标签页；读操作（state/screenshot/get/eval）不锁定。代理只做 state 后标签页不会被锁定。

Q7：参考答案 — browser-use --profile "ShopOwner" open <后台URL> && browser-use state && browser-use click <订单管理索引> && browser-use wait text "订单管理" && browser-use state && browser-use select <筛选下拉索引> "待发货" && browser-use click <查询按钮索引> && browser-use screenshot /reports/orders.png --full && browser-use close

Q8：C — "所有操作前先清除 Cookie"不是核心技巧。Cookie 是保持登录态的关键资产，无故清除会导致需要重新登录。正确做法是保留 Cookie 甚至通过 export/import 持久化。

（6/8 通过）

---

10. 延伸阅读

• [[L5-17-ClaudeAPI最佳实践|上一课：Claude API最佳实践]]
• [[L5-19-云端浏览器自动化|下一课：云端浏览器自动化]]