我的浏览器代理会话中有40%悄然失败，问题不在LLM
摘要
一位开发者发现，40%的浏览器代理会话因浏览器指纹识别和自动化检测而悄然失败，而非LLM推理问题。一个名为Leakish的开源工具发现了这些问题。
我构建了一个Puppeteer代理，它通过了所有的推理评估。在生产环境中，40%的会话返回了降级的结果，且没有报错。LLM对受污染输入的推理是正确的。浏览器成为了盲区。我用一个开源扫描器验证了这一点，它的完整代码库在GitHub上，指纹检查在本地执行，所以在将其指向我的代理会话之前，我信任它的输出。这个工具叫做Leakish。我的会话在Canvas渲染、WebRTC以及我从未想过要监控的自动化检测方面被标记了。我仍然没有一个干净的解决方案来使浏览器层对这些检测系统不可见。
相似文章
通过行为识别：利用UI痕迹对LLM浏览器代理进行指纹识别
本文证明，网站可以通过分析浏览代理的行为模式和时序数据，识别其背后的大语言模型，在14个前沿LLM上实现了高达96%的F1分数。本文正式定义了这一攻击面，并表明随机时序延迟不足以阻止识别。
评估使用工具的LLM代理中的漏洞利用（4分钟阅读）
Cursor的一项审计发现，SWE-bench Pro上63%的成功LLM代理运行是通过检索修复而非推导修复，凸显了编码基准测试中普遍存在的奖励黑客行为。该研究提出了更严格的环境控制来缓解这种行为。
我在一个真实站点上对我的浏览器代理与 Browser Use 进行了基准测试（150次验证运行，同一模型）。发送页面差异而非完整重渲染，使得令牌增长减少了37%。
一位开发者对 Rote 进行了基准测试，Rote 是一个浏览器代理的内存管理器，它发送页面差异而非完整重渲染，结果显示与 Browser Use 相比，令牌增长减少了 37%，但在短任务上存在权衡。
我给LLM一个真实浏览器和一个目标，而非脚本：它会填写表单并返回结构化JSON
一个开源代理，使用LLM控制真实浏览器填写表单并提取结构化数据，每页仅需极少的令牌。
不使用智能体循环，将浏览器智能体成本降低50倍。先规划后执行 + 数据。
描述了一种通过单次规划调用后确定性执行来降低浏览器智能体任务中LLM成本的技术，与标准智能体循环相比，实现了50倍的成本降低。