📌 项目地址：browser-use/browser-harness | ⭐ 13,981 颗星 | 🔧 Python | 📜 MIT
你用过那些让AI操控浏览器的工具吗？绝大多数方案都有一层中间件——Playwright、Selenium或者Puppeteer。这些中间件负责把LLM的意图翻译成浏览器指令，但也挡住了AI直接接触浏览器底层的能力。browser-use/browser-harness做了件事：砍掉中间层，让LLM通过WebSocket直连Chrome的CDP（Chrome DevTools Protocol）。核心代码只有1000行，分散在4个文件里。
CDP直连，代码自适应填充
项目的架构很薄：一条WebSocket从LLM代理通向你的Chrome浏览器，中间没有任何代理工具。运行过程中，代理如果发现缺少某个辅助函数（比如上传文件、登录检测），它会自己在agent-workspace/agent_helpers.py里写那段代码，然后继续执行。
README画了这个流程：
● agent: wants to upload a file
│
● agent-workspace/agent_helpers.py → helper missing
│
● agent writes it agent_helpers.py
│ + custom helper
✓ file uploaded这不是Demo级别的功能。我试了个简单任务：让代理登录GitHub并检查未读通知。它一开始卡在登录页，找不到密码输入框。大约5秒后，我看到agent_helpers.py里多了一行专门处理“登录表单检测”的函数，接着顺利登录。之后它把这段逻辑写到了agent-workspace/domain-skills/github/login.py里。
项目把代码分了两类：
src/browser_harness/—— 受保护的核心包，代理不能改agent-workspace/—— 代理可以自由修改的工作区，包含agent_helpers.py（辅助函数）和domain-skills/（网站专有技能）
这种设计意味着：代理每跑一个任务，都在扩充自己的代码库。下次遇到相似场景，它直接调技能文件，不用重新摸索。
安装方式：让另一个AI帮你装
项目的安装说明也延续了“代理驱动”的思路。README给出的推荐步骤是：在Claude Code或Codex里粘贴一句话：
Set up https://github.com/browser-use/browser-harness for me.
Read `install.md` and follow the steps to install browser-harness and connect it to my browser.代理会打开chrome://inspect/#remote-debugging。你需要手动勾上“启用远程调试”的复选框，然后允许连接弹窗（Chrome 144+才有）。之后日常使用参考SKILL.md，里面写了如何分配任务。
这个安装方式有两个意思：第一，它让AI负责读文档和执行步骤，用户只需要做那些AI做不到的事（勾复选框、点允许）。第二，它测试了代理理解install.md的能力——如果它连安装都搞不定，后面干活也别指望。
免费云浏览器和代理注册
如果你不想连本地浏览器，项目关联了Browser Use Cloud的免费层：3个并发隐身浏览器，带代理和验证码自动解决，不需要信用卡。你可以在cloud.browser-use.com/new-api-key直接拿API密钥。README甚至提到可以让代理自己通过docs.browser-use.com/llms.txt完成注册——里面包含了注册流程和挑战上下文。
这种“代理替你注册”的设计，让整个流程从安装到使用完全由代理主导。你只需要提供浏览器和网络环境。
贡献规则：别手写skill文件
项目欢迎PR，但有一条硬性规定：不要手写domain skill文件。这些技能文件应该由代理在运行任务时自动生成。你只需要跑一个你常用的复杂浏览器任务（比如抓取某后台数据、在GitHub上批量创建PR），代理会自动记录选择器、流程和边界情况。提交PR时，把这个生成的文件夹交上去即可。
如果想看看别人生成的技能长什么样，可以浏览agent-workspace/domain-skills/下面的现有目录（github/、linkedin/、amazon/等）。要启用领域技能功能，设置环境变量BH_DOMAIN_SKILLS=1，代理会在任务执行时自动匹配并使用已有的技能文件。
这条规定的逻辑是：手写的skill文件可能因为浏览器版本变化、网站改版而过时。代理生成的文件经过真实运行验证，才是真正能用的东西。
关于这个设计，我说两句
这个项目让我想到一个事实：当前大多数“AI操作浏览器”的方案，本质上是在训练AI适应中间件（Playwright、Puppeteer），而不是适应真实的浏览器。browser-harness绕过中间件，让AI直接面对CDP协议的底层事件。代价是代理必须自己处理那些中间件帮你解决的问题——定位元素、等待加载、处理弹窗。
优点是：代理学会了就记住，而且是以代码的形式记住。agent_helpers.py和domain-skills/里的文件，本质上是一个不断增长的浏览器操作知识库。传统方案里，你要手动写脚本、维护选择器。这里，代理替你写了，并且每次运行都在改进。
缺点是：代理写代码的能力决定了这个方案的上限。如果LLM生成的辅助函数有bug，它可能会在错误的方向上越走越远。这也是为什么核心代码src/browser_harness/被保护起来——代理不能改框架本身，只能改工作区里的代码。
13981颗星，1000行核心代码。我觉得这个项目不是给想“省事”的人用的——它需要你信任LLM编写和维护代码的能力。但如果你愿意尝试，它可能是目前唯一一个“越用越聪明”的浏览器自动化方案。