Article

项目研究：Browser Harness

项目研究开源AI浏览器自动化Agentbrowser-use

项目研究：Browser Harness

> 仓库：https://github.com/browser-use/browser-harness > 维护方：browser-use 团队（GitHub 24k+ 星的 browser-use 项目作者） > Star：7.2k（截至 2026-06） > 核心代码：~1k 行，4 个 Python 文件 > 创建：2026-04

---

「这是什么」一句话定性

让 LLM 像新手学徒一样直接摸你电脑上的 Chrome——用着发现少了个动作，就当场把代码补进去，下次还会用。

> 不是把浏览器操作"包成 API 给 AI 调用"，而是把 Chrome 的一根 WebSocket 拉到本地，让 AI 自己看着办。

---

「它怎么转」逻辑全景图

├─ 触发层：什么情况下需要用它？
│   ├─ AI 任务涉及浏览器：填表、抓数据、跨站点操作
│   ├─ 现有 RPA/Playwright 框架太重、改不动
│   └─ 想要"用着用着越来越聪明"的工具
│
├─ 核心层：4 个文件 + 1 个工作区
│   ├─ _ipc.py (8.9K)
│   │   └─ Unix socket / TCP loopback 通信协议
│   │      一行 JSON 一个请求/响应，{method, params, session_id}
│   │
│   ├─ daemon.py (19K)
│   │   └─ 守护进程：保活 Chrome 连接、命名空间（BU_NAME）
│   │      支持本地 Chrome + Browser Use 云浏览器
│   │
│   ├─ admin.py (35K)
│   │   └─ 启动器 + 健康检查 + 自动更新 + PID 指纹防误杀
│   │      关键设计：跨平台用 process start time 识别同一进程
│   │      避免 PID 复用把无辜进程当 daemon 干掉
│   │
│   └─ run + agent-workspace/
│       ├─ agent_helpers.py ← AI 自己改的代码
│       └─ domain-skills/   ← 站点套路库（linkedin/, github/...）
│
├─ 输出层：怎么判断做对了？
│   ├─ 浏览器按 LLM 意图动起来
│   ├─ agent_helpers.py 越长越聪明
│   └─ domain-skills/ 积累出可复用 playbook
│
└─ 卡点层：新手最容易在哪里卡住？
    ├─ Chrome 144+ 首次连接要手动点弹窗的 Allow
    ├─ Chrome 136+ 用默认 user-data-dir 时 --remote-debugging-port 被静默忽略
    ├─ Way 2 模式复制默认 profile 后 cookies 全失效（加密键绑了原目录）
    ├─ 改了源码没提交时 browser-harness --update 直接拒绝
    └─ domain skills 不能手写——必须 AI 在实战中"发明"出来才合规范

为什么这么设计：作者在 The Bitter Lesson of Agent Harnesses 里讲透了——20 年浏览器自动化范式（DOM 提取 → 元素 ID → 包装器调用）现在是被 LLM 干翻的对象。别给 AI 包装层，给它 Chrome 自己，让它边干边学。

---

「怎么升级」三段位路线图

入门段（能用）

- 跑通 uv tool install -e . + browser-harness - 在 Chrome 里勾选 chrome://inspect/#remote-debugging（一次就好） - 让 AI 跑 page_info() 看到自己登录态里的页面 → 信任就建立起来了

进阶段（用好）

- 学会看 agent_helpers.py 怎么被 AI 自动改写 - 给高频任务攒 domain skills（PR 回去也是贡献方式） - 用 BU_NAME 起多个隔离会话（工作 / 测试 / 抓数据分开） - Way 2 用于无人值守任务，Way 1 用于"AI 帮你点自己浏览器"

高手段（用活）

- 把 Browser Use Cloud 浏览器接入，AI 在云端浏览器里操作、本地完全干净 - 跨会话编排：一个 AI 调度多个 harness 实例跑并行任务 - 把领域套路编成可复用 Playbook，自己做"AI 操作顾问"

普通用户和高手的本质差距：不是会不会调用，而是敢不敢让 AI 改你的代码。这一脚迈出去，harness 才有自愈；迈不出去，就还是个远程浏览器。

---

「能用在哪」场景迁移建议

场景 1：日常自动化（最直接）

自动填表 / 跨系统数据搬运 —— ERP、CRM、表单系统 - 迁移变量：表单结构多变，AI 自己截图判断 + 写新 helper - 风险：误填线上系统，先在 Way 2 隔离 profile 跑通

场景 2：动态数据采集

传统爬虫搞不定的 SPA、登录墙、验证码 - 迁移变量：登录态会过期，靠 AI 重新识别 - 风险：面对反自动化识别强度高的站点会更难，这工具走的是真浏览器指纹，相对更难被识别

场景 3：Web E2E 测试

用 harness 代替 Playwright/Cypress 写测试用例 - 迁移变量：测试要可重复，AI 写 helper 时要带断言 - 风险：AI 改写可能让测试飘移，断言要严格

部署参考

好处： - 日常 Chrome 的登录态、扩展、书签全部继承（Way 1） - 不依赖 Browser Use 云，本地全跑也成 - 跟 Claude Code / Codex 无缝集成（就是 SKILL.md 一行 import）

注意事项 / 风险： - Way 1 模式下，AI 进程能操纵你登录的所有网站（银行、邮箱、内部系统）—— 别在生产环境裸跑 - 让 AI 改 agent_helpers.py 意味着你的工作区代码随时在变—— 提交频率要高 - 跨平台有差异：macOS 用 ps -o lstart=，Windows 走 ctypes，作者对 PID 指纹识别做了细致处理 - 云浏览器是付费服务（Browser Use Cloud ），不传 API key 就用不了

---

一句话总结

它的灵魂：不要替 AI 决定它该会什么，给它 Chrome 自己和一沓白纸，让它在实战中自己长出能力。

附带引用两句关键设计哲学（来自 README / Bitter Lesson 文章）： > "The harness improves itself every run." > "Skills are written by the harness, not by you."

返回列表