我在一个真实站点上对我的浏览器代理与 Browser Use 进行了基准测试（150次验证运行，同一模型）。发送页面差异而非完整重渲染，使得令牌增长减少了37%。

每个主要的浏览器代理框架都修复了旧问题——它们现在都会淘汰旧的页面观察（我阅读了 Browser Use 0.13.6、Skyvern、Stagehand 和 Magnitude 的源代码来确认）。但它们每一个在每次步骤中仍然会重新发送当前页面的完整渲染——在 Browser Use 中高达 40K 字符——即使唯一的变化只是一个复选框。我一直在构建 Rote，一个浏览器代理的内存管理器，它的核心技巧是：在获取一个页面的基础快照后，只发送差异，这些差异通过内容派生的元素 ID（角色+名称+血统的哈希值）来标识，这些 ID 在重渲染和导航中保持不变。基准测试：Browser Use 0.13.6 与 Rote，两者都使用 gpt-4.1-mini，真实 WordPress 站点，五种任务长度（9–25 步），每个单元 15 次匹配运行。成功由独立的页面状态断言判断，而非代理的自我报告。两个框架都取得了 75/75 的成绩。结果： • 输入令牌增长：每步 2,160 vs 3,437——慢了 37.2%（95% 置信区间 35.6–38.8） • 发送了 849 次差异，中位数 24 字符，对比 9,270 字符的完整快照（中位数减少了 99.6%），每次运行输出令牌减少 2.7 倍 在哪些方面它表现不佳——因为没有缺点的基准测试就是广告：在短任务（约 9 步）上，Browser Use 在花费上便宜约 15%，尽管使用了更多令牌——它们的长不变前缀正是提供商缓存所奖励的。成本在约 13 步时转向对我有利，到 25 步时便宜 16%。另外，淘汰意味着代理回忆的是它做了什么，而不是它看到了什么——需要回忆之前页面的任务在设计上会失败，直到我推出笔记机制。而且 Browser Use 默认启用历史记录压缩，我还没有这个功能。乐于回答任何关于方法论的问题——如果你认为设置在某些方面对 Browser Use 不公平，请告诉我，我会重新运行。