研究 Browser Agent 时，我觉得最容易被忽略的，不是模型能不能点击网页，而是一个更实际的问题：怎么确认它真的完成了任务？ 比如，让 Agent … · @R7Ruk · TwKit

@R7Ruk

研究 Browser Agent 时，我觉得最容易被忽略的，不是模型能不能点击网页，而是一个更实际的问题：怎么确认它真的完成了任务？ 比如，让 Agent 在网页上填写一份表单。它找到了正确的页面，识别了字段，也成功点击了提交按钮。从执行过程来看，一切似乎都很顺利。但如果必填项漏填了，或者页面没有真正保存数据，这次运行依然是失败的。更麻烦的是，如果提交后只是没有及时收到确认，Agent 盲目重试，还可能产生重复记录。 这让我更关注 Browser Agent 的整个执行闭环，而不是单纯看它的操作能力。 它需要先观察页面，再决定下一步，执行之后重新检查状态。如果页面发生变化，就不能继续依赖之前的观察结果；如果一次操作没有得到预期反馈，也不能直接认定操作失败。尤其是涉及提交、购买等有副作用的动作时，重试之前应该先确认上一次操作究竟有没有成功。 这也解释了为什么 Agent 并不总比脚本更合适。步骤固定的任务，用 API 或脚本往往更容易控制；只有当流程需要根据页面状态动态调整时，Agent 的灵活性才真正有价值。但灵活性也意味着执行路径可能变化，结果必须有相应的验证机制。 评估它是否值得使用，也不能只看单次运行花了多少钱。失败重试、结果核验和人工修正，都是完成任务所付出的成本。真正应该关心的是：花了多少资源，最终交付了多少经过验证的正确结果。 我更愿意把 Browser Agent 看成一种需要对结果负责的自动化系统，而不只是一个会操作浏览器的 AI。能执行动作只是起点，能证明任务完成，才是可靠性的关键。 https://browser-use.com/posts/browser-agents

曝光 75 · 评论 2 · 点赞 3 · 书签 0