> 来源:browser-use 团队,The Bitter Lesson of Agent Harnesses
一、数字对比: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 grephelpers.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 的思想:
- 动态 skill 生成:agent 遇到缺失功能时,自己写 skill 文件
- 能力下沉:不要把 channel API 包得太厚,让 agent 直接访问底层
- 自修复:失败时不只是报错,而是尝试修复自己的工具链
六、局限与边界
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"——越少越强,越底层越自由。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
如需转载请保留出处:https://51itzy.com/kjqy/282529.html