围绕浏览器代理的失败路径构建 Talos/Taloswork —— 求直接的反馈

大多数浏览器代理在演示里看起来都很惊艳：分析页面、点几下、完成任务。然后布局变了，弹出登录或 CAPTCHA，或者代理需要再次访问同一个网站——整条工作流又从零开始。我在围绕一条不同的失败路径构建 Talos/Taloswork： 首次访问时，用轻量级无障碍快照（accessibility snapshot）加 LLM 来理解页面并确认交互方式。 后续访问时，复用已学到的页面类型/站点结构配方（recipe），而不是每次都重新读取和重新解析整个 DOM。 让浏览器操作与本地文件和其他工具处于同一个桌面工作区中。 当出现凭据、CAPTCHA、含义模糊的界面或结构变化时，把控制权交给人工，并在同一个浏览器会话中继续下去。 目标不是宣称完全自主，而是让浏览器工作流重复起来更快、调试起来更容易、也更不容易悄悄编造出一个结果。 我是这个项目的开发者。现阶段，我特别希望在三个方面得到反馈： 首次识别加可复用的站点配方，是否符合你对浏览器自动化工作方式的预期？ 明确的人工接管，会让你更放心地把它用于调研或行政类工作流吗？ 你会先用哪个网站或哪项重复性浏览器任务来试？ Talos/Taloswork 仍在积极开发中，所以针对定位、上手流程和失败模式的直接反馈，比“看起来很酷”有用得多。