Browser Harness：让 AI 直接接管真实浏览器的轻量自愈执行层

如果你已经在用 Claude Code、Codex 这类 AI 编程助手，又希望它们能直接操作你的真实浏览器，那么 Browser Harness 是一个很值得关注的项目：它不是再套一层厚重框架，而是给模型一条直连 Chrome 的最短路径，并允许它在任务进行中自己补齐缺失能力。

一句话定位

Browser Harness 是一个面向 AI Agent 的轻量浏览器执行层，直接连接 Chrome DevTools Protocol，让模型在真实浏览器里完成任务，并能在执行过程中自我扩展能力。

基础信息卡片

说明：Star、Fork、Issue 数等活跃数据会持续变化，阅读时请以 GitHub 仓库实时信息为准。

解决什么问题

现在很多 AI 浏览器自动化方案都有一个共同问题：能力看起来很多，但真正落到复杂网页任务上，往往还是需要人为补脚本、补选择器、补边界处理。框架层越厚，模型离真实浏览器越远，遇到页面变化时就越容易卡住。

Browser Harness 想解决的就是这件事。

它的思路不是把浏览器操作封装成一套固定配方，而是尽量缩薄中间层，直接建立到 Chrome DevTools Protocol（CDP）的连接，把浏览器能力更直接地暴露给模型。这样当任务中途发现“当前 helper 不够用”时，模型不是立刻失败，而是可以直接改 harness 本身，把缺的函数补进去，再继续执行。

这也是它 README 里反复强调的关键词：self-healing。这里的“自愈”不是玄学，而是允许模型在执行过程中扩展工具本身，而不是永远被预设接口限制住。

核心功能

1. 直连 CDP，尽量减少中间抽象

项目最吸引人的一点，是它对“薄”这件事非常执着。

README 里直接把整体规模写得很透明：核心代码量大约只有 592 行 Python，主要由 run.py、helpers.py、admin.py、daemon.py 组成。它传递出的不是“大而全平台”的感觉，而是一个刻意保持轻量、方便被模型理解和修改的浏览器执行层。

对于 AI Agent 场景，这一点很关键。中间层越薄，模型越容易读懂当前工具到底能做什么、不能做什么，也越容易在任务失败时自己修。

2. 允许模型在任务中途补齐缺失能力

这个项目最有辨识度的地方，不是“能操作浏览器”，而是“能边做任务边长能力”。

README 里给了一个很直观的例子：当模型想上传文件时，如果 helpers.py 里还没有 upload_file()，它就直接把这个函数写进去，然后继续完成上传。

这意味着 Browser Harness 不是把模型当成一个只能调用固定 API 的操作者，而是把它当成一个既能执行任务、又能维护执行层的工程师。对于那些流程多变、网站细节又经常变化的场景，这种设计会比一套完全预定义的动作库更灵活。

3. 支持真实本地浏览器，也支持远程浏览器

从 install.md 和 SKILL.md 看，Browser Harness 的使用路径分成两类。

第一类是连接用户自己的真实 Chrome。它强调的是“直接接到你正在用的浏览器”，这样模型看到的就是你真实登录态、真实标签页和真实环境，更适合日常助理式操作。

第二类是远程浏览器。项目提供了 Browser Use cloud 这类远程能力，适合子代理并行执行，或者在无界面的服务器环境里运行。README 还明确提到免费层支持 3 个并发浏览器，不需要绑卡，这对做自动化实验或者多任务拆分来说门槛比较低。

4. 把经验沉淀成 domain skills

很多自动化项目把“经验”留在一次性脚本里，下一次重跑还得重新踩坑。Browser Harness 则明显想把这些网站级经验沉淀下来。

仓库里有 domain-skills/ 和 interaction-skills/ 两类知识：

• domain-skills 更偏站点级任务经验，比如某个平台的页面结构、稳定选择器、交互细节
• interaction-skills 更偏通用浏览器操作能力，比如下载、滚动、iframe、上传、弹窗等

更有意思的是，项目鼓励这些技能由 agent 在真实任务中自动生成，而不是手工拍脑袋编写。这个思路很符合 Agent 工具演进的方向：真正有价值的知识，不是事先想出来的，而是任务跑通之后沉淀下来的。

5. 对 Codex / Claude Code 的接入路径比较清晰

这个项目并不试图做一个封闭产品，而是很明显地在拥抱现有的 AI 编程助手工作流。

README 里直接给了面向 Claude Code 和 Codex 的 setup prompt；install.md 还专门说明了如何把它的 SKILL.md 注册到对应 agent 的全局技能目录中。换句话说，它不是让你额外学习一套新平台，而是把自己做成现有 Agent 工作流中的浏览器能力补丁。

这也是它容易传播的原因之一：对已经在用 Claude Code、Codex 的用户来说，上手心智负担很低。

适合谁

我觉得 Browser Harness 比较适合这几类人：

• 已经在使用 Claude Code、Codex、Hermes 这类 agent，希望把浏览器能力也接进来的人
• 经常要处理真实网页登录态、后台录入、上传下载、内容运营这类网页任务的人
• 想做更灵活的浏览器自动化，而不满足于固定脚本的人
• 想让多个子代理并行跑网页任务的人

如果你的目标只是做稳定、封闭、规则非常明确的网页测试，那么传统测试框架可能已经够用了。但如果你更在意“让模型自己理解页面、补工具、继续执行”，那 Browser Harness 的设计会更对路。

快速上手

按照项目文档，体验它的大致路径不复杂：

1. 打开仓库，先看 install.md
2. 克隆项目并安装为可全局调用的工具
3. 让它连接到你的真实 Chrome，或配置远程浏览器
4. 再读 SKILL.md，了解日常使用方式
5. 从一个具体网页任务开始，让模型边做边学习

它的一个典型调用形态是：

• 通过 browser-harness 执行一段 Python
• helpers 会预先导入
• daemon 自动启动
• 模型根据任务不断调用、修改、补充 helper

如果你已经在自己的 AI 工作流里用了技能文件、任务脚本、子代理协作这些机制，那么 Browser Harness 基本能无缝接进去。

结论

Browser Harness 的价值，不在于它把浏览器自动化包装得多花哨，而在于它重新定义了 AI 操作浏览器时“工具应该长什么样”。

它足够轻，模型看得懂；它足够近，能直接碰到真实浏览器；它又足够开放，允许模型在任务执行过程中自己把工具补完整。这几件事叠在一起，才让它和传统“浏览器自动化脚本封装层”拉开了差异。

如果你最近正好在关注 AI Agent 如何真正落到网页任务、内容运营、后台操作、跨站点流程自动化这些场景，这个项目值得你专门花点时间看一遍。

我自己的判断是：它未必会成为所有人都用的浏览器方案，但它很可能会成为“AI 如何接管真实浏览器”这条路线里，一个非常有代表性的轻量实现。