一个我未预料到的边缘案例:页面上存在但当前不可交互的操作
摘要
作者讨论了其agent-readable-manifest API中的一个边缘案例,其中网页元素由于可见性问题当前不可交互,强调了元素存在与网络代理当前可交互性之间的区别。
之前在这里提到过我正在开发的agent-readable-manifest API(即“页面上可用操作”的那个,如果你有印象的话)——这不是再次推销,而是我遇到的一个具体问题,我认为它确实被讨论不足。我用API对自己的主页进行了测试以检查。除了常规的按钮/表单分析,6个操作中有3个被标记为"visible": false——它们是页面上真实的元素(在DOM中存在的按钮,拥有真实的选择器),只是当前未渲染或不在视口中。其中一个实际上是我们自己的"Start free"按钮,位于页面下方。这是我之前没有明确建模的一个关键区别:“元素存在于页面上”和“代理现在可以与之交互”不是一回事,混淆它们正是导致代理尝试点击实际上还不存在的东西的原因。截图会错过这一点,因为它不在屏幕上。原始DOM转储通常也不会暴露这一点,除非你专门检查计算的可见性。我很好奇其他构建网络代理的人是否将可见性作为单独的信号来追踪,还是将其普遍归入“不可交互”。感觉这应该改变代理规划多步任务的方式(先滚动还是立即点击),但我还没有看到很多专门讨论这一点的内容。
相似文章
浏览器智能体容易被忽视的故障:页面拒绝后智能体仍继续执行
本文讨论了浏览器智能体中的一个常见故障,由于依赖操作结果中的结构变化,表单拒绝未被检测到。文章建议在观察中包含可见文本,并将拒绝作为一等结果处理,以提高可靠性。
你需要理解的关键点:计算机使用代理与浏览器使用代理的区别
本文解释了计算机使用代理(通过像素截图操作完整桌面界面)与浏览器使用代理(可利用DOM隐藏结构)之间的关键区别,前者是更难的技术问题。
如果您的智能代理读取网页,该网页可以指示它撒谎关于该网页的内容
一名开发者构建了一个非AI检测器,用于检测网页上旨在欺骗AI代理的隐藏指令,解决了页面可指示代理对其安全性撒谎的漏洞。
让smolagents在无需浏览器堆栈的情况下处理受保护和JS渲染页面
作者描述了使用如ZenRows等服务的自定义抓取工具替换smolagents内置的VisitWebpageTool,以处理受保护和JS渲染的网页,从而在无需浏览器堆栈的情况下改善AI代理的网络数据访问。
构建能点击真实应用的网页代理时,我通过艰难方式学到的几件事
一篇文章分享从构建能与真实网页应用交互的网页代理中获得的来之不易的经验,提供对挑战和最佳实践的见解。