🔧 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 的全部代码： | 文件 | 行数 | 职责 | |------|------|------| | `run.py` | ~36 行 | 运行 Python，预加载 helpers | | `helpers.py` | ~195 行 | CDP 薄封装，agent 可编辑 | | `admin.py` + `daemon.py` | ~361 行 | CDP websocket 守护进程 | | **总计** | **~592 行** | **完整 browser agent 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 抽象的方向性 抽象有两种方向： | 方向 | 例子 | 对 Agent 的影响 | |------|------|---------------| | **Human-friendly** | `click("登录按钮")` | 省了人类认知负担，但限制了 agent | | **AI-native** | `Input.dispatchMouseEvent(x=120, y=340)` | 对人类不友好，但对 agent 最自由 | 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"——越少越强，越底层越自由。**