在 Computer Use、桌面自动化、浏览器操控等 GUI Agent 场景中，模型反复点击同一界面却无法推进任务，是开发者经常遇到的故障之一。掘金一篇关于 GUI Agent 防打转机制的技术文章提出，这类问题并不一定源于模型能力不足，更常见的原因是防打转机制被四类盲区绕过。文章建议，开发者应把判断标准从“动作是否执行”改为“画面是否发生变化”。
四个盲区让防打转机制失效
GUI Agent 通常按照“截图—决策—动作—再截图”的循环工作。死循环发生在动作执行之后：界面仍停留在同一画面，但模型无法得知这一点。文章将防打转失效归纳为四个原因。
- 动作被判定为“机械成功”。点击、按键等操作在接口层返回 ok=True，因此原本设定的失败止损没有机会触发。即使设置了“10 步内失败 8 次就停”的规则，系统也可能因为只统计执行失败而不生效。
- 重复动作检测过于严格。许多防打转策略要求动作完全相同才报警，但真实场景中，模型每次给出的目标描述或坐标可能略有差异，导致系统认为这是新动作。
- 模型缺少画面对比能力。GUI Agent 每轮通常只看到当前截图，缺少对上一轮画面的记忆，因此难以自行发现界面没有变化。
- 低思考档位削弱自我纠错。素材提到，将 DeepSeek 的思考档位设为 low 会削弱模型发现自身循环的能力；排查时可以临时调高档位观察，但不能只依赖模型自身反省。
用画面哈希、等待验证和兜底上限搭建检测
针对上述问题，文章给出的方案不是继续调高失败阈值，而是改变“成功”的定义：一次操作不能只看系统是否接收，还要看界面是否出现变化。围绕画面变化，检测可以分为三层。
第一层是画面哈希。对每一轮截图进行降采样后计算哈希值，如果连续多轮哈希相同，说明 Agent 正在面对同一幅界面。素材提到，来自 Gemini Computer Use 实践的参考阈值是：连续 3 轮以上针对同一画面哈希动作，就应升级给人类处理。文章示例代码中的判断阈值同样使用 loop_threshold=3。
第二层是 wait-screenshot-verify 规则。动作执行后不立即进入下一步，而是等待、截图、验证画面是否变化。素材称，Anthropic 的官方建议也在 prompt 中加入类似规则，以减少盲目重试。
第三层是坐标漂移检测与迭代上限。坐标漂移检测关注动作是否集中在同一区域，例如示例参数 center=(1205, 1056)、radius=30；即使每次坐标略有偏移，只要仍落在同一区域且画面没有变化，也可视为疑似打转。迭代上限则作为最后兜底，示例使用 max_iterations=20，防止所有检测都失效时 Agent 无限运行。
多步 GUI Agent 的可靠性工程
这一思路对 GUI Agent 开发的意义，在于把循环问题从模型智能问题转化为可验证的工程问题。过去常见的自动化脚本可以依赖固定流程或人工监控，但 GUI Agent 面对的是动态界面，任何一次按钮未响应、弹窗未关闭或页面未跳转，都可能让模型陷入重复动作。
文章也给出了适用边界：如果 Agent 只做单步操作，或者有人工随时中断，完整的防打转机制可能是过度设计；但只要 Agent 会连续执行多步操作，就值得加入“画面是否前进”的检测。判断标准是界面状态是否推进，而不是调用是否返回成功。
对开发者而言，这类实践把 GUI Agent 调试从“模型是否够聪明”转向更具体的系统设计：如何保存上一帧截图、如何比较画面变化、如何设置重试阈值、如何在达到阈值后停止或交给人类。当 Agent 连续自主执行多步操作时，外部防打转机制不再是额外优化，而是影响资源消耗和任务可用性的基础组件。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/ai-cao-zuo-dian-nao-xian-ru-chong-fu-dian-ji-xian-jian-cha
