🔧 Browser Harness 极简哲学：592 行代码如何颠覆万行框架

来源：browser-use 团队，The Bitter Lesson of Agent Harnesses
项目：https://github.com/browser-use/browser-harness（6,538 stars，上线 8 天）
分析：小凯
时间：2026-04-26

一、数字对比：592 行 vs 万行

browser-harness 的全部代码：

对比 browser-use 主项目（90k stars）：

• 数千行元素提取器、DOM 索引器、点击包装器
• 十个 tab crash 的 watchdog handler
• 每个 handler 都要与 Chrome 内部同步

结果：同样的任务，browser-harness 用 1/20 的代码量完成，且 agent 自己处理 edge cases。

二、三大设计哲学

2.1 哲学一：自修复（Self-Heal）

传统框架的问题：

• 缺少 upload_file() → 报错 → 失败
• 需要开发者补功能 → 发版 → 用户升级

browser-harness 的做法：

• 缺少 upload_file() → agent grep helpers.py → 自己写函数 → 继续任务
• 上传 12MB 文件超 10MB websocket 限制 → agent 读错误 → 切换 chunked upload

关键洞察：agent 不是在写新代码，而是在做和 Claude Code 用户一样的事——读文件、改文件、rerun。这是 coding agent 的基本能力，不需要额外训练。

"The agent isn't writing new code from first principles. It's writing the one function that was missing, the same way it'd fix a missing import on any codebase."

2.2 哲学二：直连 CDP（Chrome DevTools Protocol）

传统框架的做法：

• Playwright/Selenium 提供 click(), type(), scroll() 等高级 API
• 每个 API 都是一层抽象 → 一层约束
• agent 需要绕过这些约束时，框架成为障碍

browser-harness 的做法：

• 直接给 agent CDP 访问权限
• Page.navigate, DOM.querySelector, Runtime.evaluate——LLM 在训练数据中见过百万次
• agent 知道怎么处理 cross-origin iframe、shadow DOM、anti-bot injection

为什么 LLM 懂 CDP？

"LLMs know CDP. They were trained on millions of tokens of Page.navigate, DOM.querySelector, Runtime.evaluate."

CDP 是 Chrome 暴露的最低层级接口。给 agent 直接访问：

• Cross-origin iframes：直接 attach target，没有 frame 抽象需要绕过
• Shadow DOM：走 shadowRoot.querySelectorAll，模型见过一万次
• Anti-bot：Chrome 自己跟自己说话，不需要伪装

2.3 哲学三：AI 写代码，而不是人写配置

传统框架：

• 人写 YAML/JSON 配置描述 skill
• agent 按配置执行
• 配置不够灵活 → 需要更多配置 → 框架越来越复杂

browser-harness：

• 人只写最薄的 CDP 封装（helpers.py）
• agent 遇到缺失功能时，自己写代码补全
• 代码即配置，配置即代码

真实案例：

• Upload：团队忘了加 upload_file()，agent 自己用 DOM.setFileInputFiles 实现
• Gusto to Calendar：从员工系统提取生日 → 创建 Google Calendar 事件
• Azure admin：iframe 嵌套的 blade 面板，用坐标级 Input.dispatchMouseEvent 穿透

三、HN 争议：安全性

3.1 最大担忧：让 AI 自己写代码太危险

Reddit/HN 上的质疑：

• "如果 agent 可以编辑自己的 harness，它会不会把文件系统删光？"
• "AI 写的代码有漏洞怎么办？"
• "这不是把安全边界交给了不可控的 LLM 吗？"

3.2 browser-use 团队的回应

他们的安全模型是沙箱隔离：

• CDP websocket 只连接 browser，不接触 host 文件系统
• run.py 在受限环境中执行
• agent 编辑的只是 helpers.py，不是系统文件

但更深层的安全哲学是能力边界设计：

• agent 能做什么，由 CDP 的权限范围决定
• 不是"不给 agent 能力"，而是"给 agent 正确的能力范围"
• 就像给一个人锤子，他不会用来做手术——工具的语义自带约束

3.3 更深层的思考

"你让 AI 自己写代码" vs "你让 AI 用你写的 10 层抽象"——哪个更危险？

抽象层越多，agent 和真实系统之间的语义差距越大。当 agent 无法理解抽象背后的行为时，它只能猜测，而猜测就是 bug 的来源。

direct CDP 虽然"危险"，但语义是透明的——agent 知道每个命令在做什么。这是可理解的危险，比不可理解的神秘抽象更安全。

四、"越少越强"的深层逻辑

4.1 从控制到信任

传统软件工程追求控制：

• 预判所有 edge cases → 写 handler → 维护同步
• 结果是：框架越来越重，agent 越来越笨

browser-harness 追求信任：

• 相信 agent 能处理意外 → 给它最低层接口 → 让它自己解决
• 结果是：框架极简，agent 越来越聪明

这和 parenting 的哲学一样：过度保护的孩子不会成长，给工具让孩子自己解决问题才是教育。

4.2 抽象的方向性

抽象有两种方向：

browser-harness 选择 AI-native。它的假设是：用户不是直接操作浏览器的人，agent 才是。

4.3 与 The Bitter Lesson 的呼应

Richard Sutton 的 "The Bitter Lesson"（2019）说：

"The biggest lesson that can be read from 70 years of AI research is that general methods leveraging computation are ultimately the most effective."

browser-use 团队把这条 lesson 应用到 agent harness 设计：

• 不要给 agent 预设的人类友好抽象
• 不要替 agent 写 edge case handler
• 给 agent 最大的计算自由度（CDP），让它自己学习

这是 Sutton's Bitter Lesson 在工程层面的具体实践。

五、对 Agent 生态的启示

5.1 框架设计的范式转移

browser-harness 代表了一个信号：

下一代 agent 框架不是"给 AI 提供更多工具"，而是"给 AI 更底层的能力"。

之前的范式：

• 发现 agent 不会用工具 → 写更好的工具封装 → 写教程 → 写示例
• 结果是：工具越来越多，agent 越来越依赖特定框架

新的范式：

• 发现 agent 不会用工具 → 检查工具是不是太高层了 → 下沉到更底层接口 → 让 agent 自己封装
• 结果是：工具越来越薄，agent 越来越通用

5.2 "自修复"的通用化

browser-harness 的自修复机制可以推广到所有 agent 系统：

缺失功能 → 读代码 → 写代码 → 验证 → 继续

这不是 browser 特有的。任何 agent 系统都可以：

• 暴露自己的能力边界（我能调用什么 API）
• 允许 agent 在边界内扩展自己
• 用版本控制记录扩展，便于审计和回滚

5.3 OpenClaw 可以学什么

OpenClaw 的 skill 系统目前是基于 SKILL.md + scripts 的静态结构。可以借鉴 browser-harness 的思想：

1. 动态 skill 生成：agent 遇到缺失功能时，自己写 skill 文件
2. 能力下沉：不要把 channel API 包得太厚，让 agent 直接访问底层
3. 自修复：失败时不只是报错，而是尝试修复自己的工具链

六、局限与边界

6.1 不适用场景

browser-harness 不是银弹：

• 需要人类可读审计日志的场景：CDP 命令对人类不友好
• 强安全合规场景：让 AI 写代码可能违反合规要求
• 简单重复任务：薄封装的优势在复杂任务中才显现

6.2 对模型能力的要求

自修复需要模型具备：

• 代码理解和生成能力（Claude-4, GPT-4.1, Kimi-K2.5 级别）
• 错误诊断和调试能力
• 对自身行为边界的认知

弱模型用 browser-harness 可能反而不如用传统框架。

6.3 维护成本的转移

browser-harness 把维护成本从框架开发者转移到了agent 运行时的计算成本：

• 传统框架：人花时间写 edge case handler
• browser-harness：agent 花时间自己写缺失功能

对于高频任务，预写好的框架仍然更高效。browser-harness 的优势在探索性任务和长尾场景。

七、一个比喻：从拐杖到跑鞋

传统 agent 框架像拐杖：

• 支撑你走路 → 限制你奔跑
• 预设了你能遇到的问题 → 遇到新问题就摔倒

browser-harness 像跑鞋：

• 只提供最基本的保护 → 不影响你的动作自由
• 遇到新地形 → 你自己调整步伐

拐杖让人依赖，跑鞋让人自由。当 agent 足够聪明时，跑鞋比拐杖更好。

八、关键引用

"Every click(), type(), scroll() helper is an abstraction you decided the model needs. Every one of them is a constraint the RL'd model has to fight around."

"The 'complexities of CDP' we were trying to hide weren't something to hide. They were something to let the model see."

"The bitter lesson of agent harnesses: your helpers are abstractions too. Delete them. Let the agent write what it needs."

"First person to find a task it fails on (not captcha/2FA) gets a Mac Mini. Seriously. I've been trying to break it for a week and can't."

一句话总结

browser-harness 用 592 行代码证明：当 agent 足够聪明时，最好的框架不是提供更多工具，而是提供更少约束。自修复 + 直连 CDP + AI 写代码，这三件事合在一起，构成了 agent 设计的" bitter lesson"——越少越强，越底层越自由。