Browser Harness 深度分析 - 2026-07-09

type

status

date

slug

summary

原始链接

GitHub 仓库：browser-use/browser-harness

README：Browser Harness README

使用说明：SKILL.md

安装说明：install.md

官方文章：The Bitter Lesson of Agent Harnesses

官方文章：Web Agents That Actually Learn

Benchmark 仓库：browser-use/benchmark

为什么今天选它

Browser Harness 今天值得写，不是因为它又做了一个浏览器 Agent，而是因为它把问题往下挖了一层。很多 Agent 框架把浏览器操作包装成 click、type、scroll 这类动作，再让模型在这些动作里选。Browser Harness 反过来做：让模型直接接触 Chrome DevTools Protocol，也就是 Chrome 暴露出来的底层控制接口；缺什么 helper，就让 Agent 自己写到 agent_helpers.py 或 domain skills 里。

这和《智汇AI》最近几篇关于 harness、skill maintenance、loop engineering 的主题有连续性，但焦点不同。前几篇更多是在讲 Agent 如何组织任务和沉淀技能；Browser Harness 更具体，它盯着一个硬问题：真实网页很脏，有 iframe、shadow DOM、登录弹窗、反爬、页面崩溃和加载不稳定。Agent 不是在干净 API 里跑，而是在浏览器这种会不断变形的环境里跑。

GitHub 数据也说明它不只是一个小实验。仓库创建于 2026-04-17，2026-07-08 仍有推送；截至我今天读取 GitHub API 时，仓库约 15.8k stars、1.4k forks，MIT 许可证。这个速度很少见。

图源：Browser Harness README。图里是让 Chrome 打开远程调试入口的步骤。它说明 Browser Harness 的核心定位：不是模拟一个浏览器，而是接入真实 Chrome/Chromium。对 Agent 来说，这意味着任务环境更接近人类实际使用网页的方式。

它要解决的问题

浏览器 Agent 以前常见的失败点有三类。

第一类是动作层太窄。框架提供几个固定动作，模型只能在里面选。网页一旦出现特殊控件、跨域 iframe、shadow DOM，动作抽象就开始漏水。

第二类是状态层太脆。页面加载一半、目标 tab 换了、弹窗抢焦点、iframe 断开，Agent 很容易继续对旧状态操作。很多框架会加一堆兜底逻辑，但这些逻辑本身也会过期。

第三类是经验无法复用。Agent 第一次搞懂某个网站怎么点，下一次还是从零探索。官方文章《Web Agents That Actually Learn》里把这个拆成 exploration 和 exploitation：一次任务里，很多成本花在摸清网页，而不是完成任务。

Browser Harness 的答案很直接：少包一层，让模型看见真实错误；少写死一层，让 Agent 把有效做法写成 helper 或 skill；少依赖一次性轨迹，让站点经验能留下来。

图源：Browser Harness README。这个授权弹窗看起来很小，但它对应一个重要设计选择：Browser Harness 默认接入本地正在运行的 Chrome，也支持云浏览器。它不是把浏览器藏在框架后面，而是把“浏览器连接”本身当作 Agent 运行环境的一部分。

核心思想

Browser Harness 的核心不是“浏览器自动化”，而是 self-healing harness。可以把它理解成一个 Agent 的执行外壳：Agent 运行时遇到缺口，不只是重试，还能补工具。

README 里写得很清楚：一个 websocket 直连 Chrome，中间尽量不加东西；Agent 在执行中发现缺失能力，就写进去；harness 会在每次运行里变好。官方文章《The Bitter Lesson of Agent Harnesses》进一步把观点说透：不要包住 LLM，也不要包住工具。以前他们用大量元素提取器、DOM 索引器和点击包装来帮 Agent，后来发现这些抽象也会限制模型。

这里的新意不在“用了 CDP”。CDP 很早就存在。新意在于它把 CDP、可编辑 helper、domain skills、真实浏览器状态放到一个闭环里：

Agent 接到网页任务。

通过 Browser Harness 读取页面、截图、执行脚本、点击坐标或调用 CDP。

如果现有 helper 不够用，Agent 可以把新 helper 写进工作区。

如果某个网站有稳定流程，就沉淀成 domain skill。

下一次类似任务不再从零探索。

这更像“运行时知识库”，不是传统意义上的插件市场。

系统怎么运作

从 README 和 SKILL.md 看，它的结构很轻：install.md 负责初次安装和浏览器连接，SKILL.md 是日常使用说明，src/browser_harness/ 是受保护的核心包，agent-workspace/agent_helpers.py 和 agent-workspace/domain-skills/ 是 Agent 可以沉淀经验的地方。

这个边界划得比较清楚。核心包不希望 Agent 随便改；任务相关的做法放在 workspace。这样既允许 Agent 自我修补，又避免每次任务都把底层框架改乱。

更有意思的是 domain skills。仓库里已经有一批站点技能目录，比如 amazon、booking-com、arxiv、bilibili 等。SKILL.md 里还要求：如果开启 BH_DOMAIN_SKILLS=1，遇到特定站点时要先读对应技能，再动手。这相当于把“经验复用”变成运行流程的一部分。

图源：browser-use/benchmark 仓库。这里比较的是 BrowserCode/Browser Harness 在不同模型下的表现。它提醒我们：底层 harness 很重要，但模型能力仍然影响结果。好的 harness 不是替模型思考，而是把模型能做的事完整暴露出来。

和常见 Agent 设计相比，新在哪里

常见浏览器 Agent 设计会把网页转成结构化状态，再让模型选择动作。好处是容易控制，也容易做日志和评测。坏处是网页越复杂，状态抽取越容易失真。你以为给了模型“可点击元素列表”，其实漏掉了真正能解决问题的底层路径。

Browser Harness 的新点有两个。

第一，它把 action space 放大。模型不只是点按钮，也可以用截图、DOM、JS、CDP、坐标和自写 helper。对复杂网页，这比固定动作集合更有弹性。

第二，它把经验沉淀放到执行层。domain skills 不是写给人看的教程，而是 Agent 下次能直接读取和使用的现场经验。官方文章里提到，一个 Agent 解决了 Duo 2FA 的设备信任提示，后续 Agent 就不必重复摸索同一个按钮。这类例子说明 skill 的价值不是“知识多”，而是能减少下一次探索成本。

但也要分清楚，哪些是真新东西，哪些只是工程包装。

真正新的部分，是把“工具不足”看成 Agent 可以自己修的运行时问题。传统框架通常假设工具由开发者提前写好；Browser Harness 假设工具集会随着任务演化。

工程包装的部分，是云浏览器、安装脚本、远程调试流程、截图 helper、认证流程。这些很重要，但不是思想本身。没有这些包装，项目不好用；只有这些包装，也不构成新范式。

可复用方法论

第一，Agent 产品不要急着把能力包死。越接近真实世界的任务，越需要保留底层逃生通道。固定工具可以提高早期成功率，但会限制长尾任务。

第二，把失败变成可保存的资产。一次失败如果只是日志，就是成本；如果能转成 helper、skill、测试用例或站点规则，下次就少踩一次。

第三，区分“核心稳定层”和“任务经验层”。核心层负责连接、权限、隔离和安全；经验层负责站点技巧、流程片段、异常处理。两层混在一起，系统会很快变乱。

第四，评测要贴近真实环境。browser-use/benchmark 把 BU Bench、Online-Mind2Web、Stealth Bench 分开看，方向是对的。浏览器 Agent 的失败不只来自模型不会推理，也可能来自被反爬拦截、页面没加载、iframe 操作失败。

图源：browser-use/benchmark 仓库。Stealth Bench 用来观察浏览器环境是否容易被拦。这个图和 Browser Harness 的关系在于：浏览器 Agent 的成功率不能只看模型，也要看底层浏览器是否能进入目标页面。

风险和没验证清楚的地方

第一个风险是安全边界。让 Agent 写 helper 和 skills，会带来很强的适应性，也会带来污染风险。一个坏 skill 如果被复用，错误会扩散。这里需要版本、来源、回滚和评审机制。

第二个风险是可解释性。固定动作框架虽然笨，但日志比较清楚。Browser Harness 给了模型更大的行动空间，调试时要能回答：它为什么执行这段脚本，为什么选择这个 target，为什么写了这个 helper。

第三个风险是网站规则和合规。真实浏览器控制、云浏览器、反爬绕过、验证码处理，这些能力在生产里很敏感。技术上能做，不代表业务上应该做。

第四个问题是 benchmark 的外推。官方 benchmark 很有价值，但仍然主要覆盖浏览器任务。它不能直接证明同样思路适用于企业系统、桌面应用、移动端或高风险业务流程。

第五个问题是技能质量。domain skills 如果由 Agent 自动生成，短期能提高效率，长期会遇到重复、过期、冲突和噪声。技能维护可能会成为新的工程负担。

对产品和研发的启发

Browser Harness 给 Agent 产品的提醒很朴素：不要只看对话体验，要看运行环境。一个 Agent 能不能落地，经常取决于它能不能稳定进入系统、看见真实状态、处理异常、记住站点经验。

对研发团队来说，可以借它的分层方式：核心能力保持小而稳定，任务经验放到可迭代空间里。不要把所有异常都塞进框架，也不要把所有任务都交给模型临场发挥。比较好的做法是：先让模型解决问题，再把稳定路径沉淀成技能，最后用评测和日志淘汰坏技能。

对应用落地来说，Browser Harness 也提醒了一件容易忽略的事：Agent 的 memory 不一定都是向量库里的文本记忆。很多时候，最有用的记忆是一段流程、一个选择器、一个等待条件、一个页面异常处理方法。它们更像操作经验。

今日沉淀

Harness 不只是工具外壳，它决定 Agent 能看见多少真实世界。

固定动作适合简单网页，复杂网页需要底层逃生通道。

Skill 的价值不是写得漂亮，而是让下一次少探索。

浏览器 Agent 的评测要同时看模型、浏览器环境和反爬阻力。

自修复系统必须配套技能治理，否则经验会变成噪声。