浏览器代理很酷,直到一个登录界面第14次毁掉了工作流程
摘要
作者批评浏览器代理因登录界面和干扰而频繁失败,建议使用正规API或Runable等原生连接器来实现更可靠的自动化。
浏览器代理可能是最酷的演示,也是每个星期二最烦人的依赖项。一切都很完美,直到:会话过期、双因素认证出现、随机模态框弹出、按钮移动、页面加载异常、Cloudflare决定你的代理犯了罪,现在“自主工作流程”正盯着登录界面。开始认为浏览器控制应该是应急手段,而不是默认选项。如果Gmail、Sheets、Slack或其他任何应用有适当的连接器或API,就用那个无聊但可靠的方法。这就是我喜欢Runable为普通商业应用提供原生连接器的一点。不性感,但重复性工作可能不应该取决于按钮是否移动了14像素。不过,对于没有API的长尾软件,浏览器代理仍然感觉非常有用。现在人们是如何构建这个的?先用API/工具调用,浏览器作为后备?还是浏览器代理已经足够可靠,让你可以放心地将它们作为主要执行层?
相似文章
我觉得现在的浏览器代理开始变得不同了。
作者观察到,浏览器代理已从华而不实的演示演变为可靠地执行研究、更新表格、完成工作流等任务,标志着从助手到操作员的转变。
智能体是新的浏览器
作者认为,SaaS 公司不应该构建自己的智能体来控制 API 的用户体验,这就像为了控制网站用户体验而去分叉 Chrome 一样;他们应该专注于数据收集,让智能体来处理呈现和查询。
我创建了一个工作流程,利用浏览器自动化代理来优化和申请工作
一位开发者分享了一个免费、开源的工作流程,使用浏览器自动化代理来简化重复的求职申请过程,例如填写Workday表格。
你需要理解的关键点:计算机使用代理与浏览器使用代理的区别
本文解释了计算机使用代理(通过像素截图操作完整桌面界面)与浏览器使用代理(可利用DOM隐藏结构)之间的关键区别,前者是更难的技术问题。
@browser_use: 您的代理可以绕过任何网站的登录 以下是使用 Browser Use Profiles 的方法:> 创建配置文件并开始设置…
Browser Use 推出了 Profiles,允许代理通过将本地浏览器数据同步到云端来绕过登录,从而实现持久化会话。