Browser Harness
作者：@gregpr07
核心哲学：Every framework that adds a layer between the LLM and the browser eventually becomes the bottleneck. No rails is the only honest architecture for agentic browser use.
关联：harness-engineering/agentic-infrastructure，harness-engineering/components-coding-agent
架构创新
Browser Harness 是一种移除传统框架抽象的自主修复浏览器 agent 架构，直接通过 CDP（Chrome DevTools Protocol）控制浏览器。
| 传统框架封装 | Browser Harness |
|---|---|
| Selenium/Playwright 中间层 | 单个 WebSocket 直连 Chrome |
| 预定义选择器和等待逻辑 | 运行时动态编辑 helpers.py |
| 框架能力成为瓶颈 | LLM 自己动态修复 helper 代码 |
| 人工维护 selectors | Self-healing：模型发现错误并修正 |
Self-Healing 机制
运行时动态修复：
- 不依赖预定义的选择器或等待逻辑
- 当 React 动态下拉菜单第一次操作出错时，模型会自己发现并修正 helpers.py
- 最终完成任务，而不是卡在预定义的失败路径上
实际表现：
React 动态下拉菜单第一次可能出错，但模型会自己发现并修正，最终完成任务。
Direct CDP 设计
- 通过单个 WebSocket 直接控制 Chrome
- 没有中间框架层
- LLM 接收原始 DOM 和浏览器状态，自行决定操作
与传统 Browser Agent 框架的对比：
| 维度 | Playwright/Selenium 封装 | Browser Harness |
|---|---|---|
| 抽象层级 | 高（提供 page.click, page.wait 等 API） | 低（原始 CDP 命令） |
| 灵活性 | 受限于框架 API 设计 | 受限于 LLM 能力上限 |
| 维护成本 | 人工更新 selectors | 模型自动修复 |
| 失败模式 | 框架报错，任务中断 | 模型重试，自我修正 |
工程启示
- 框架即瓶颈：任何在 LLM 和浏览器之间添加的抽象层，最终都会成为 agent 能力的上限
- No Rails 诚实架构：让 LLM 直接面对原始环境，而不是通过人工预设的"护栏"
- Self-healing 推广：agent 应该在运行时有能力修复自己的工具代码，而不是依赖人工维护
适用场景
- 高灵活性浏览器自动化（抢票、复杂表单、动态 SPA）
- 需要绕过传统框架限制的边缘场景
- 快速变化的前端环境（选择器频繁变更）
Counterpoints & Gaps
- 可靠性未验证：self-healing 在复杂多步流程中的成功率缺乏大规模测试数据
- Token 消耗：原始 CDP 数据量远大于封装后的 API，可能显著增加上下文成本
- 调试困难：模型自行修复的过程对人类不透明，失败时难以排查
- 安全边界：移除框架层意味着移除了内置的安全检查（如跨域限制、敏感操作确认）
Browser Harness JS（2026-04-20）
@gregpr07 发布了纯 JavaScript 版本的 Browser Harness：
- 纯 JS 实现：works on Cloudflare Workers, Vercel, anywhere JS runs
- 基于 Bun：no package requirements, no install
- globalThis access：agents persist state
- 代表了 agent 基础设施的轻量化趋势：从重量级框架到零依赖工具
链接：https://x.com/gregpr07/status/2046082887641104608
Sources
- AI 简报 2026-04-19 — 深度文章 #5