“浏览器代理成本高昂且仍在成熟”这种表述可能忽略了架构方面的问题

每隔几周这里就会有一个关于浏览器代理的讨论——通常以“确实如此，但成本高昂且仍在成熟”之类的结语收场。我以前也持这种看法。但我认为成本和可靠性问题部分源于架构上的不匹配，而不仅仅是这个领域尚处于早期阶段。我反复看到的一种模式是：代理 + 无头Chrome + AI层叠加在一起。浏览器控制页面；AI层试图弄明白页面的含义。这两者是脱节的。代理在每个步骤中都需要消耗令牌来重新叙述上下文，因为浏览器在步骤之间并不保留任何理解。我一直在测试一种不同的配置。Opera Neon现在有了命令行界面——`opera-browser-cli`——它将浏览器的原生AI代理（Do、Make、Research）暴露为终端命令。AI位于浏览器内部，而不是附加在浏览器之上。当你从外部编排器调用它时，你调用的不是一个需要单独模型来解释输出结果的页面控制器。你调用的是已经知道自己正在看什么的工具。实际操作中：无头模式，本地运行，绑定到一个端口，返回给编排层的输出无需清理步骤即可直接使用。令牌开销比我之前使用的Playwright+模型+提示栈要低。这并不能解决所有问题。反机器人层无论采用哪种架构都仍然麻烦。而且你依赖于拥有一个活跃的Neon会话，这限制了纯无服务器的用例。但当浏览器理解自己在做什么，而不仅仅是报告它看到了什么时，失败模式是不同的——并且更容易恢复。还有人用这种方法吗？当任务确实需要理解页面而非仅仅解析页面时，你们使用的浏览器层是什么？