浏览器 Agent 别再迷信长上下文，精简 Token 才是提升执行成功率的真理

很多做浏览器 Agent 的工程师现在都有个误区，就是陷入了「堆料」的路径依赖。每当 Agent 执行任务失败、定位不到元素或者在页面跳转时迷路，大家的第一反应往往是：是不是上下文给得不够？或者模型参数量还不够大，导致它理解不了复杂的页面结构？

但在浏览器自动化这个特定场景下，这种逻辑其实是失效的。最近看了一些实战数据，有一个非常反直觉的结论：通过极致精简 Token 效率，不仅能大幅砍掉运行成本，执行成功率反而能反超那些依赖海量数据的方案。

目前很多开发者构建 Browser Agent 的习惯是，直接将整个页面的 DOM 树或者大量的 HTML 碎片喂给模型。从直觉上看，这提供了充足的上下文，确保模型「看到了所有信息」，能避免信息缺失。但实际上，网页源代码中充斥着大量的冗余标签、样式类名和无关的脚本，这些在模型看来全是噪声干扰。

在 BU Bench v1 的测试环境下，这种差异被量化地展现了出来：采用「精简路线」的 Browser Agent 成功率达到了 88%，而对比组 Browser Code 仅为 78%。这 10% 的差距在自动化领域是至关重要的。它证明了在特定指令集下，剔除冗余信息反而能让模型更精准地捕捉到关键的 DOM 元素，而不是在海量的 Token 中迷失方向，导致定位失败或产生幻觉。

除了成功率，从成本和工程落地维度来看，这种优化带来的冲击力更强。在实际运行对比中，单次任务的成本从 8.34 美元直接下降到了 5.37 美元。更夸张的是，由于处理的 Token 数量剧减，整体运行时间缩短了一万多秒。对于需要实际部署的开发者来说，这意味着 Agent 正在从一个「昂贵的实验室玩具」向「可商业化的工具」迈进。

为什么「少即是多」在浏览器自动化中如此有效？我们需要理解模型推理在网页操作中的特性：它是断断续续的、步进式的。如果每一个操作步骤都携带巨大的 HTML 碎片，Token 账单会随着页面跳转的深度呈指数级爆炸。而如果采用经过微调的轻量化专业模型来接管每个步骤，不仅能显著降低 GPU 的占用，还能极大提升响应速度。

这种「以精简换精度」的思路，本质上是在降低微调小模型时的计算压力和 VRAM（显存）预算。在浏览器操作这种强领域任务中，一个针对精简指令集进行过微调的小模型，其执行的稳定性往往高于一个被海量噪声干扰的通用大模型。通用大模型虽然见多识广，但在面对一个极其复杂、充满冗余标签的网页源代码时，很容易在海量 Token 中迷失。

对于正在开发类似 Agent 的工程师，我建议放弃对 Long Context 的盲目追求，尝试将重心转移到输入结构的优化上。你可以分析任务流中哪些 Token 是真正影响决策的，通过结构化压缩来降低推理成本。

这种优化逻辑给我们的最大启发是：不要把模型升级当作唯一的救命稻草。在自动化领域，从底层输入结构入手，通过精简 Harness 部署，让单次任务成本变得可预测，这才是 Agent 能够真正规模化落地的核心竞争力。