北京
Browser Use 联创 Greg 用两年时间做了一件事：把围绕模型搭的架子一层层拆掉。2024年11月产品刚发布时，浏览器智能体需要人工定义状态和动作空间，模型要做的是从菜单里挑动作。到2025年9至10月，团队引入 JavaScript 执行与持久化 notebook，模型不再挑动作，而是直接写程序。这一步之后，Hermes 案例里出现了一个关键数字：用单个 browser_exec 替换掉 12个浏览器工具，Opus 4.8 的 token 消耗下降 60%，Kimi K3 下降 66%。
效率涨了，可靠性没掉
通常做减法会让人担心一件事：省了资源，是不是也省掉了成功率。Hermes 案例给出的答案是反的。两个模型在替换工具之后，都完成了全部 18/18 次任务运行。token 降了，任务一个没丢。这说明动作自由化和可靠性之间并非此消彼长的关系，至少在这个案例里不是。
再往后走一步，团队撤掉了预定义状态，让模型直连 CDP，自行决定是截图、查 DOM 还是看 frame。最后一步是复用 Pi、Codex、OpenCode 这些已经成熟的编码智能体循环。整条路径的方向很统一：把人类设计的中间表示，一点点交还给模型。
遥控器换成了编程语言
Greg 的论证被解读为 Bitter Lesson 的第三次移植，落点在观察与动作的粒度上。Sutton 当年的论断是通用方法胜过注入人类知识，这一次被推进到了中间表示层面。预定义状态和动作菜单不是在帮助模型，而是在限制它。人类工程师的领域知识，从资产变成了负债。
这个判断听起来刺耳，但对照演进路径并不难理解。当模型只能从固定菜单里挑动作时，菜单的边界就是模型能力的边界。菜单设计得再精巧，也是在用人的先验去框住一个可能比设计者更会做选择的系统。遥控器换成了编程语言，模型自己写程序去操作浏览器，中间那层翻译被拿掉了。
三条可以搬走的原则
作者从这段演进里提炼出三条可迁移的原则：
- 复用经过验证的 agent harness，不要从零重造
- 暴露模型能用好的最简底层接口
- 让模型自己选择观察与动作
这三条被作者认为适用于浏览器、电脑、文本、音乐等所有智能体领域。核心逻辑是一致的：模型能力越强，围绕模型搭建的 Harness Engineering 就越应该被拆掉。拆的顺序也有讲究，先让模型从挑动作变成写程序，再撤掉预定义状态，最后接上成熟的智能体循环。
对做智能体产品的团队来说，这条路径提供了一个可对照的坐标。如果还在人工定义状态和动作空间，可能需要问一句：这些中间表示是在帮模型，还是在替模型做它本可以自己做的决定。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
