SOTA Sync
← 返回 FEED
GITHUB2026-04-20

Browser Harness：让AI自己动手修Bug的浏览器控制框架

AI控制浏览器，一直是Agent领域的热门方向。但现有方案大多采用"预定义操作集"模式：把点击、输入、滚动这些动作封装好，AI从中选择。问题是，真实世界的网页无穷无尽，总有意料之外的交互场景——文件上传、验证码、弹窗处理——预定义的工具集迟早会遇到盲区。

browser-use发布的browser-harness换了一个思路：框架不提供工具，工具由AI在执行过程中自己写。

核心设计

这个项目用Chrome DevTools Protocol（CDP）直接连接浏览器，底层只有约592行Python代码，分成四个部分：

  • daemon.py + admin.py：建立CDP WebSocket连接，负责浏览器与AI之间的通信桥接
  • helpers.py：提供约195行起始工具函数，AI可以在此基础上修改和扩展
  • run.py：入口文件，仅36行，运行预加载了helpers的Python环境

框架本身几乎是"裸"的。没有操作流程模板，没有预设的网站适配逻辑，AI面对一个任务，如果发现helpers.py里缺少某个功能，直接修改这个文件，自己把缺失的部分写出来。

自愈机制

所谓"self-healing"（自愈）体现在这个循环里：

● agent: 想上传一个文件
● helpers.py → upload_file() 函数缺失
● agent 原地修改 helpers.py，写出 upload_file()
● 文件上传成功

这不是优雅的静态设计，而是动态生长的能力。AI在执行中遇到什么缺口，就填补什么缺口。传统的浏览器自动化框架是"先建好工具再做事"，browser-harness是"做事过程中顺便建工具"。

极简主义

市面上大多数浏览器Agent框架倾向于提供越来越丰富的内置能力——操作池越来越大，适配的网站越来越多，代码行数随之膨胀。browser-harness反其道而行：它故意保持最小化，只提供CDP连接通道和一套起始工具集。

项目方在README里明确说："No framework, no recipes, no rails. One websocket to Chrome, nothing between."（无框架，无配方，无护栏。一个WebSocket连Chrome，中间什么都不放。）

免费远程浏览器

作为配套能力，browser-use还提供免费远程浏览器服务：免费套餐包含3个并发浏览器，不需要信用卡。通过cloud.browser-use.com获取API key即可使用，适合sub-agent场景或生产环境部署。

意义

browser-harness的实验性质很明显——它不是要替代Playwright或Puppeteer这类成熟工具，而是在探索一个更本质的问题：当AI能够实时修改自己的工具集，浏览器自动化的边界在哪里？

传统框架试图枚举所有可能的操作，browser-harness选择把工具编写的权限完全交给AI。如果这个方向被验证有效，它的影响不限于浏览器控制本身——它代表了一种"运行时自我扩展"的Agent设计范式。

GitHub: browser-use/browser-harness（2.2k stars，MIT协议）

相关