浏览器智能体容易被忽视的故障:页面拒绝后智能体仍继续执行
摘要
本文讨论了浏览器智能体中的一个常见故障,由于依赖操作结果中的结构变化,表单拒绝未被检测到。文章建议在观察中包含可见文本,并将拒绝作为一等结果处理,以提高可靠性。
在我为智能体构建浏览器工具时,我反复遇到一个问题,我认为这不仅仅是我个人的情况。当网页表单拒绝提交时,它通常不会添加任何新控件。它只是在字段附近打印一条消息。如果你的智能体的操作结果只报告结构变化,那么被拒绝的提交和成功的提交看起来是一样的。智能体读取成功,进入下一步,然后所有后续操作都在未推进的屏幕上执行。任务在三个步骤后失败,看起来与真正原因无关的地方。基于截图的智能体面临更难的相同问题,因为拒绝是几个红色像素,模型必须正确注意到并解释。对我来说,解决方法是让操作结果携带页面所说的内容,而不仅仅是结构变化,然后将拒绝作为剩余批次的停止条件:4. 点击“保存配送详情”,页面显示:“请修复下面高亮的字段。”、“全名是必填项。”、“配送地址是必填项。”页面拒绝了此步骤,因此剩余的两个步骤未尝试。给这个领域的建设者两个建议。首先,在观察中采样可见文本,而不仅仅是控制树,否则你会错过每个验证消息。其次,将拒绝作为一等结果,与成功和错误区分开来,因为它需要不同的恢复:智能体应该修复指定的字段,而不是重试点击或放弃任务。值得一提的是,我自己的测试套件没有捕捉到这个问题。流程无论如何都通过了,因为测试在每个步骤后重新读取页面,错误在那里可见。只有每个操作的结果是盲区,这正是智能体在批处理步骤时读取的内容。我为智能体构建浏览器工具。乐意在评论中详细讨论。
相似文章
真正让你头疼的AI代理故障不是崩溃,而是那些顺利完成却做错事的运行。
本文讨论了AI代理如何常常通过错误地完成任务而不崩溃,悄无声息地失败,导致未被检测到的错误。它强调了常见的失败模式,并探索了潜在的检测策略。
浏览器代理很酷,直到一个登录界面第14次毁掉了工作流程
作者批评浏览器代理因登录界面和干扰而频繁失败,建议使用正规API或Runable等原生连接器来实现更可靠的自动化。
我的浏览器代理会话中有40%悄然失败,问题不在LLM
一位开发者发现,40%的浏览器代理会话因浏览器指纹识别和自动化检测而悄然失败,而非LLM推理问题。一个名为Leakish的开源工具发现了这些问题。
你的编码代理说“完成了”,但它从未真正检查过这个东西在浏览器中是否有效。
对AI编码代理的批评,它们声称完成任务却没有在真实浏览器环境中验证功能。
将"人类拒绝"视为与"智能体故障"不同的故障模式——事实证明,这种区分在生产环境中非常重要
讨论如何将'人类拒绝'视为与'智能体故障'不同的故障模式,这显著影响了AI智能体在生产环境中的可靠性和调试。