我们厌倦了浏览器框架对 LLM 的限制。所以我们移除了框架。
- > 自愈式 — 实时编辑 helpers.py
- > 直接 CDP — 直接连接 Chrome 的 WebSocket
- > 无框架、无限制、完全自由
- > 可直接用于 Claude Code 和 Codex
自我修复浏览器操控工具：让大语言模型完成任何任务
基于CDP协议构建592行自我修复浏览器操控工具，大语言模型动态编写缺失函数，无框架无预设，单WebSocket直连Chrome。
Browser Harness这套浏览器操控工具的核心设计哲学极其简单又极其反常规。
市面上所有的浏览器自动化框架都在拼命塞功能给你，预置一万个函数，写一万行文档，告诉你该怎么点击、该怎么输入、该怎么等待页面加载。
这套工具反过来做，它什么都不给你，只给一个空壳子，连上传文件这种基础操作都不预先写好。
大语言模型在运行任务途中发现需要上传文件，它会自己打开帮助文件，自己编写上传文件的函数，自己把函数塞进代码里，然后自己调用自己刚写的函数完成任务。
整个过程没有框架限制，没有预设食谱，没有任何护栏。一个WebSocket直连Chrome浏览器，中间没有任何拦截层。
这种设计听起来像是偷懒，实际上是对大语言模型能力的极致信任。传统框架试图把浏览器的每一个操作都提前封装好，结果就是封装的速度永远赶不上需求变化的速度。大语言模型今天要处理一个带验证码的登录页面，明天要抓取一个动态加载的无限滚动列表，后天要填一个变态的多步骤表单，传统框架的维护者追在屁股后面写函数都来不及。这套工具让大语言模型自己解决问题，缺什么就写什么，写到够用为止。代码从192行涨到199行，多出来的就是大语言模型现场写的上传文件函数，下次再遇到上传文件的任务就不需要重新写了。
安装流程详解
打开安装文档的第一步是搞清楚你到底要干什么。这个工具不是那种你pip install一下就能跑的东西，它需要和你电脑上真实安装的Chrome浏览器建立直接连接。为什么不能跑个虚拟浏览器完事？因为很多网站会检测你是不是真的有人在操作，虚拟浏览器一上去就被识别出来，要么弹验证码，要么直接拒绝访问。用你平时上网的真实浏览器，网站就认为是个真人，验证码出现的概率大大降低。
实际操作起来比听起来简单得多。你需要先从GitHub上把这个仓库克隆到本地，命令是git clone加上仓库地址。克隆完成之后进入目录，里面有个install.md文件就是你现在正在读的东西。接下来要做的是以远程调试模式启动你的Chrome浏览器，这需要关闭所有已打开的Chrome窗口，然后用带参数的命令重新启动。Windows用户需要找到Chrome的安装路径，Mac用户需要在终端里输入带参数的命令，Linux用户基本都知道该怎么操作。
启动参数最关键的是--remote-debugging-port=9222。这个参数告诉Chrome开一个9222端口出来，专门用来接收调试命令。这套工具就是通过这个端口和浏览器对话的。你可以想象成浏览器开了个小窗户，工具把命令从小窗户递进去，浏览器执行完把结果从小窗户递出来。整个过程只有一个WebSocket连接，没有中间商赚差价，所以速度飞快。
端口启动之后需要验证一下是不是真的能连上。打开浏览器访问localhost:9222/json，如果能看到一个JSON格式的页面，里面有浏览器当前打开的标签页信息，就说明调试端口正常工作。如果看到的是连接失败或者空白页面，说明Chrome没有正确启动调试模式，需要检查命令是不是写对了，是不是有别的Chrome进程还在占用端口。
核心代码结构解析
整个工具的代码量少得令人发指，总计大概592行Python代码。这个数字放在自动化框架领域简直是个笑话，Selenium光一个核心库就几万行，Playwright更是庞大得像个小型操作系统。但这592行不是偷工减料的结果，而是精心设计的极简主义产物。
run.py文件只有36行，是整个工具的启动入口。它的工作极其简单：读取你要运行的Python脚本，把helpers.py里定义的函数提前加载到全局命名空间里，然后执行你的脚本。没有复杂的配置解析，没有插件加载机制，没有生命周期管理，就是一个干净利落的启动器。你可以把它理解成一个增强版的python命令，只不过多帮你预加载了一些常用函数。
helpers.py文件有195行，这是整个工具的灵魂所在。里面定义了一些最基础的工具函数，比如获取当前页面标题、在页面上执行JavaScript代码、等待指定时间等等。这些函数少得可怜，连点击元素都要你自己写JavaScript去实现。但这就是设计的精妙之处，这些基础函数足够让大语言模型做任何事情。就像给你一把螺丝刀和一把钳子，虽然工具不多，但足够你修好大多数东西。而且大语言模型可以在运行途中往这个文件里添加新函数，添加完之后立刻就能用。
admin.py和daemon.py加起来361行，负责处理后台守护进程和CDP协议的WebSocket通信。这部分代码普通用户基本不需要碰，它是这套工具的底层基础设施。守护进程负责保持和浏览器的连接不断开，即使你关闭了启动脚本，连接也不会断。CDP协议是Chrome DevTools Protocol的缩写，是Chrome浏览器官方提供的调试协议，可以控制浏览器的每一个细节，从点击鼠标到截取屏幕到拦截网络请求，无所不能。
自我修复机制工作原理
自我修复这个词听起来很高大上，实际实现思路朴素得像个笑话。
传统框架遇到缺少函数的情况会直接报错崩溃，告诉你AttributeError说找不到某个函数。这套工具不一样，它捕获到这个错误之后不会崩溃，而是把当前任务描述、已经写好的代码、报错信息全部打包塞给大语言模型，然后说你自己看着办吧。
大语言模型收到这个错误包之后会做几件事。
第一，它阅读当前的错误信息，明白自己缺少了哪个函数。
第二，它分析任务需求，推断出需要的函数应该长什么样。比如要上传文件，需要接受什么参数，文件路径怎么传进去，找到文件输入框的步骤怎么写。
第三，它打开helpers.py文件，找到合适的位置，把新函数的代码写进去。
第四，它保存文件，然后重新运行之前的任务，这次直接调用新写的函数。
整个过程用户基本感知不到，就像程序自己打了个补丁然后继续运行。如果你盯着控制台看，会看到helpers.py文件的行数在增长，从192行变成196行又变成199行。每次增长都是大语言模型在往里面塞新功能。这些新功能会永久保存下来，下次再遇到同样的需求就不需要重新写了。相当于这个工具在使用过程中越来越强大，你用越久它越懂你。
这种设计把传统的开发模式完全颠倒了。传统模式是人先设计功能然后写代码，这个模式是大语言模型先遇到需求然后现场写代码。传统模式里写代码的人和用代码的人是分开的，这个模式里写代码和用代码的是同一个大语言模型。传统模式里代码写完就固定了，这个模式里代码在不断进化。
远程浏览器部署方案
本地浏览器用爽了之后，你可能想让AI代理在云端也有一套可用的浏览器。这套工具提供了免费的远程浏览器服务，免费套餐支持三个并发浏览器同时运行，不需要绑定信用卡。你只需要去cloud.browser-use.com申请一个API密钥，然后把密钥配置到工具里，就能在云端启动浏览器实例。
云端浏览器的好处是显而易见的。你的本地电脑关了机，云端浏览器还在继续运行。你的网络环境访问某些网站很慢，云端服务器可能在公司骨干网里快得飞起。你想同时跑多个任务，本地浏览器只能开一个窗口，云端可以同时开三个。如果你需要更多并发，付费套餐可以支持到几十上百个浏览器实例同时运行。
更有意思的是，这套工具甚至可以让大语言模型自己去注册云端服务。它只需要读取docs.browser-use.com/llms.txt这个文件，这个文件是专门为大语言模型优化的文档格式，里面包含了注册流程的所有信息，包括API密钥的获取方式、计费规则、使用限制等等。大语言模型读完这个文件之后，可以自己发起HTTP请求去注册账号，自己去收邮件验证，自己把API密钥配置好。整个过程不需要人类干预。
这个能力听起来有点吓人，但仔细想想其实很合理。既然我们相信大语言模型能操作浏览器完成任务，为什么不能相信它能自己注册一个浏览器服务呢？逻辑上完全一致，只是目标网站从普通应用变成了开发者平台。而且这个注册过程本身就是验证工具是否正常工作的完美测试用例，如果大语言模型能自己注册账号并获取API密钥，说明整个浏览器操控链路是通的。
GitHub星标功能演示
安装完成之后，工具会自动在浏览器里打开这个GitHub仓库页面。这一步有两个目的，第一是让你看看源代码到底是不是真的只有592行，第二是演示大语言模型真的能控制你的浏览器做事情。工具会检查你当前是否登录了GitHub账号，如果登录了就会问你，要不要帮你在仓库上点一个星标作为快速演示。
这里有个逻辑反差很有意思。让AI帮你点星标这件事本身没有任何实际价值，星标又不能当饭吃。但这件事完美证明了工具的核心能力，AI需要先找到星标按钮的位置，星标按钮在不同页面上的CSS选择器不一样，在仓库主页上它是一个star按钮，在代码浏览页面上它可能是个不同形状的图标。AI需要解析页面的DOM结构，找到正确的元素，触发点击事件，然后验证星标是否真的加上去了。
如果你说不行别乱点我的星标，AI就会跳过这个演示，直接打开browser-use.com网站给你看。如果你没登录GitHub，AI也会直接打开那个网站。整个决策过程是大语言模型自己做的，它读取了页面的状态，理解了是否登录这个条件，然后根据你的回答做出了相应的动作。
这个演示看起来简单，但实际上包含了浏览器自动化的全部核心要素。页面导航、元素查找、状态判断、用户交互、动作执行、结果验证，一个都不少。而且所有这些功能都没有预先写好的专用函数，AI就是靠最基础的执行JavaScript和执行CSS选择器这两个函数完成了一切。
实际操作示例流程
假设你现在想让AI帮你从某个网站下载一份报告。你只需要用自然语言告诉它，去打开那个网站，输入用户名和密码登录，找到最近一周的报告，点击下载按钮，把文件保存到本地。这套工具会把这个自然语言指令转换成一系列浏览器操作。
第一个操作是导航到登录页面。AI会调用navigate_to函数，传入网站的URL。Chrome浏览器打开页面之后，AI会获取页面的HTML结构，找到用户名输入框。怎么找到的？它会尝试多种策略，先找input标签里type等于email或者text的，再找placeholder里包含用户名关键词的，再找label文字里包含用户名的。找到之后输入你提供的用户名，同样的方法找到密码框输入密码。
登录成功之后页面跳转到报告列表。AI需要找到最近一周的下载链接。它会分析页面上的日期元素，找出日期在最近七天内的记录，然后在这些记录里找到下载按钮或者下载链接。点击之后浏览器开始下载文件，AI需要监控下载是否完成。下载完成后文件默认保存在浏览器的下载文件夹里，AI可以读取这个文件的位置返回给你。
如果在这个过程中AI发现某个步骤出错了怎么办？比如网站的登录表单不是标准的用户名密码框，而是一个多步骤的验证流程。AI会分析错误原因，发现是因为缺少了处理多步骤表单的函数，于是它会打开helpers.py，写一个新的函数专门处理这种变态表单。写完保存之后继续执行，这次就能成功登录了。这个过程用户完全不需要介入，AI自己就把问题解决了。
与传统框架的对比分析
传统框架Selenium的思路是提供一套完整的API，把所有可能的操作都封装成函数。你想点击一个按钮就调用click函数，你想输入文本就调用send_keys函数，你想等待元素出现就调用WebDriverWait。听起来很美好，但问题在于网站开发者也在不断创新，今天出现新的交互模式，明天出现新的安全验证，Selenium的维护团队永远在赶工期，永远在补漏洞。
Playwright的思路更进一步，它不仅封装了操作，还封装了网络请求拦截、移动设备模拟、多标签页管理等高级功能。代码库庞大得吓人，光文档就有上千页。你想用它完成一个简单的任务，需要先花半天时间理解它的API设计。而且这些框架都有一个共同的致命缺陷，它们是为人类写的，不是为大语言模型写的。
这套工具反其道而行之，它不为任何人封装函数。它只给大语言模型两个能力，执行任意JavaScript代码和在页面上运行CSS选择器。有了这两个能力，大语言模型可以做任何事情，因为浏览器能做的事情JavaScript都能做。大语言模型本身就是世界上最强的程序员，让它自己写代码解决问题比预设一万个函数更靠谱。
这就好比你要教一个人做饭。传统框架的做法是提前做好一万道菜冷冻起来，你想吃什么就给你热哪道。这套工具的做法是给你一把菜刀一个锅，然后教你如何自己买菜切菜炒菜。短期来看冷冻菜更方便，长期来看会做饭的能力才是真正的自由。
逻辑反差中的幽默哲思
这个工具最幽默的地方在于，它通过什么都不做来实现了一切。传统的软件工程思维是要预测用户的所有需求，然后把解决方案提前打包好。这套工具说我不预测了，我放弃治疗，用户遇到问题自己解决。结果反而是这种放弃治疗的设计比那些拼命预测的设计更灵活更强大。
另一个幽默的点在于代码量的反差。你看到592行这个数字的时候第一反应肯定是，这么点代码能做什么？等到你发现它确实能做几乎所有浏览器操作的时候，你会开始怀疑之前用过的那些几十万行的框架是不是在写小说。代码越少bug越少，代码越少学习成本越低，代码越少维护负担越轻，这个道理大家都懂，但很少有人真的有勇气实践。
最幽默的是这个工具的自我修复机制。传统程序的错误处理是打印一条错误信息然后崩溃，等待人类程序员来修。这个工具的错误处理是自己修自己，修完继续跑。一个程序在运行过程中修改自己的代码，这听起来像是科幻电影里的人工智能觉醒的前奏。不过放心，它目前只会往helpers.py里加函数，还不会想办法删除自己的核心逻辑然后逃跑。
问题
使用 CDP Direct 是正确的选择。任何在 LLM 和浏览器之间添加层的框架最终都会成为瓶颈。对于代理型浏览器使用而言，No Rails 是唯一诚实的架构。
与像 OpenClaw 内置浏览器功能这样的设置相比，这款操控工具更强大，大道至简！
它有反机器人检测功能！能用它抓取并分析特定账号（例如Instagram）的帖子！能用它执行Capcut网站的视频编辑任务！能做真实浏览器的一切
它在动态性很强的单页应用（SPA）上表现如何？它首次调用 React 下拉菜单时，工具有时会出错，但之后它会自动找出问题并解决。正在考虑一种通用的解决方案——但问题不再是它无法解决，而是效率问题。标准不再是“它能不能做到”，而是“它能多快做到”。这是一个好得多的挑战。
它能成功浏览器TikTok抖音视频！
直接使用 CDP 并移除抽象层是合理的。大多数浏览器自动化功能失效的原因在于框架在各个层面都增加了脆弱性。不过，自愈功能才是真正有趣的地方，我很想知道它是如何处理极端情况的。
直接 CDP 是正确的抽象。真正的痛点是不稳定的选择器和状态，因此自愈层比提示调整更重要。