这个开源项目,想让 AI 真正接管你的浏览器

2026-05-01 | 开源工具观察 | Browser Harness

▌ 核心结论

browser-harness 不是给普通人点按钮的 AI 浏览器插件，而是给 AI agent 开发者的一层极薄浏览器控制底座。它的激进之处在于：不预设复杂框架，不把 agent 关进固定流程，而是让 agent 直接连到 Chrome，并在任务中补写自己缺少的 helper。

MIT / Python / CDP

如果把网页自动化比作让一个人去办事，传统工具更像一张很细的流程表：先找哪个选择器，点哪个按钮，等哪个元素出现。browser-harness 的思路更像把钥匙和操作台交给 AI：你能看见网页，能点，能截图，能调用 Chrome DevTools Protocol，缺什么小工具就现场写一个。

这就是它名字里的 harness：不是一个全功能平台，而是一套把 LLM 接到浏览器上的“缰绳”和“接口”。项目 README 的表述很直接：用一层 thin、editable 的 CDP harness，把 LLM 连接到真实浏览器。

小白先看懂：这项目是干什么的

它首先是给开发者、AI agent 创业团队、自动化工作流团队用的。尤其适合那些要让 AI 操作网页、登录后台、抓取页面、上传文件、处理表单、跑重复性浏览器任务的人。

它解决的核心问题是：LLM 会推理，但浏览器是一个复杂、动态、充满弹窗和登录态的真实环境。很多自动化框架要求你提前写好选择器和流程；browser-harness 则把控制层做薄，让 agent 根据截图、CDP、helper 代码自己摸索路径。

典型使用场景包括：让 AI 在真实 Chrome 里完成网站操作；让 sub-agent 使用远程浏览器；为某个网站沉淀 domain skill；在任务中补写上传、下载、滚动、对话框处理等 helper。

但如果你只是普通用户，只想在网页上问 AI、总结网页、写邮件，基本不需要折腾它。它更像一套给“造 AI 浏览器工人”的工具，而不是面向大众的一键产品。

第一，薄。项目说明里把核心复杂度压得很低，README 写到整体约 592 行 Python，并把核心包、agent_helpers、domain-skills 分开。这种薄不是功能少，而是尽量减少中间层。

第二，可自修复。README 举的例子是 agent 想上传文件，发现 helper 缺失，就在 agent-workspace/agent_helpers.py 里补一个任务所需 helper，然后继续完成任务。

第三，贴近真实浏览器。项目直接基于 CDP，可以连本地 Chrome，也可以用 Browser Use 的远程浏览器。对于需要登录态、复杂网页、后台系统的任务，这比静态 HTTP 抓取更接近真实工作流。

它的 SKILL.md 里有一个很能说明审美的细节：默认推荐先截图，再按坐标点击，必要时再落到 DOM 或 raw CDP。也就是说，它不迷信选择器，不把网页当成一棵永远稳定的 DOM 树，而是承认网页首先是一个“可见、可操作、会变化”的界面。

Playwright 和 Selenium 更适合人写自动化脚本：测试工程师知道页面结构，提前写好步骤，稳定执行。browser-harness 更适合 agent 自己探索：先看页面，再行动，卡住时补 helper，学到网站规律后沉淀 domain skill。

这不是谁替代谁的问题。如果你要做可重复、可审计、强确定性的端到端测试，传统框架仍然更成熟。如果你要研究“让 AI 自己完成网页任务”，browser-harness 的设计更贴近 agent 的工作方式。

判断标准很简单：你是在写固定脚本，还是在训练一个会观察、会试错、会把经验写回工具箱的 agent？前者不一定需要它，后者很值得看。

截至我核对 GitHub 页面时，browser-use/browser-harness 显示约 8.7k stars、780 forks、233 commits，语言为 Python 100.0%，许可证为 MIT。这个热度说明它已经被 agent 圈层注意到了。

但同一个页面也显示：No releases published。pyproject 里的版本是 0.1.0，要求 Python 3.11 以上，依赖 cdp-use、fetch-use、pillow、websockets。这意味着它更像快速演进中的开发者工具，而不是已经封装好的企业级产品。

所以，正确姿势不是立刻把它接进生产系统，而是把它当成一个观察窗口：浏览器 agent 的下一步，可能不是更厚的框架，而是更薄的可编辑接口。

第一是权限。它连接的不是模拟网页，而是真实浏览器。真实浏览器里可能有登录态、账号权限、后台数据和支付入口。让 agent 操作真实浏览器，本质上是在授权一个会写代码的自动操作者。

第二是治理。自修复听起来很美，但“agent 会改 helper”也意味着你要管理它改了什么、为什么改、是否可复用、是否引入危险行为。越是强大的工具，越不能只靠兴奋感使用。

第三是边界。复杂验证码、强风控、跨域登录、企业内网、敏感数据，都不是一个开源 harness 单独能解决的问题。它给的是底座，不是所有网页任务的免死金牌。

如果你正在做 AI agent、浏览器自动化、网页操作型助理、内部运营机器人，它值得拉下来读一遍。哪怕不直接采用，也能看到一种很有代表性的设计方向：把通用控制层做薄，把场景经验留给 agent 自己沉淀。

如果你是普通 AI 用户，建议先跳过。你需要的是成熟应用，不是浏览器控制底座。browser-harness 的价值不在“我今天能省几个点击”，而在“AI 能不能逐渐学会使用真实软件”。

它最有意思的地方，是把一个老问题重新摆上桌面：网页不是静态文档，软件也不是 API 的附属物。真正有用的 agent，迟早要回到真实界面里，去看、去点、去犯错、去把经验留下来。

项目地址：https://github.com/browser-use/browser-harness

主要来源：GitHub README、项目官网 browser-harness.com、SKILL.md、pyproject.toml。数据核对时间：2026-05-01。

检索关键词：browser-use/browser-harness、Browser Harness、CDP、self-healing browser agents、agent_helpers、domain-skills