我遇到的浏览器智能体最大问题不是幻觉,而是假性成功
摘要
作者指出,浏览器智能体最大的失败模式并非幻觉,而是“假性成功”——智能体在视觉上确认了 UI 状态的切换,却从未验证后端的实际状态,并提出“动作 → 预期状态 → 独立验证”的完成证明模型。
我发现浏览器智能体有一个非常恼人的失败模式。从智能体自身的视角来看,它把一切都做对了:
- 找到了正确的页面
- 点击了正确的按钮
- 填写了正确的字段
- 没有出现明显的报错
- 告诉你任务已完成
但实际上,任务并没有真正发生。例如,网站可能悄悄拒绝了表单提交,会话可能已过期,某个操作可能没有持久化,或者 UI 在视觉上发生了变化,而后端其实并没有接受这个操作。
所以智能体的推理看起来完全合理:
“我点击了提交 → 页面发生了变化 → 所以提交成功了。”
但它唯一真正验证到的东西,只是 UI 层面的状态切换而已。
我开始觉得,浏览器智能体需要一个更接近“完成证明”的概念。问题不应该是“这个动作执行了吗?”,而应该是“我有什么证据可以证明预期的状态现在已经成立?”
例如:
“动作 → 预期状态 → 独立验证 → 继续”
其他人有遇到过这个问题吗?你们在自己的智能体中是怎么处理验证的?因为为了这个问题,我已经试过用 Playwright 搭配 Claude、GPT 和 Codex 等方案了。
相似文章
浏览器智能体容易被忽视的故障:页面拒绝后智能体仍继续执行
本文讨论了浏览器智能体中的一个常见故障,由于依赖操作结果中的结构变化,表单拒绝未被检测到。文章建议在观察中包含可见文本,并将拒绝作为一等结果处理,以提高可靠性。
AI代理的失败方式鲜有人论及。以下是我亲眼所见。
文章强调了AI代理工作流程中实际的系统级失败,例如上下文泄漏和幻觉细节,认为这些通常是基础设施问题而非模型缺陷。
幻觉作为特性而非缺陷:评估多智能体架构将推测性语言模型输出转化为可测试科学假设的能力
本文提出了一种基于Rust的多智能体架构,利用LLM幻觉作为特性来生成和评估科学假设,并将其性能与直接提示和其他方法进行比较。
让我损失最惨重的智能体故障全都声称成功
作者分析了155个AI智能体任务,发现大多数故障源于基础设施问题,如超时和虚假成功信号,而非模型错误,从而提出了基于效果断言和使用多条验证路径等实践方法。
幻觉即利用:携带证据的多模态智能体
本文形式化了多模态智能体中的幻觉到动作转换,并提出了携带证据的智能体(ECA),它使用受限验证器仅授权安全的工具调用,在200个任务的流水线上实现了0%的不安全动作率。