CUADebug：计算机使用Agent的错误诊断与修复 · CUADebug: Diagnosing and Repairing Computer-Use Agent Failures

计算机使用agent（Computer-Use Agent, CUA）通过截图感知界面、通过鼠标键盘动作执行任务，其失败根源往往难以定位，因为视觉感知（有没有看错屏幕）、空间定位（坐标/元素是否点对了）、底层交互执行、任务级推理与规划、以及环境本身的动态变化，这几类因素常常纠缠在一起。现有工作大多止步于"判断任务是否成功"，缺少一套系统化的方法去回答"具体是哪一步、什么类型的错误导致了失败，以及应该怎么修"。作者认为，对CUA而言，诊断不应止于事后解释，而应能产出可直接用于修复重跑的具体建议。

CUADebug 包含三个组成部分：
1) 两级错误分类体系：五个顶层类别——感知（Perception）、定位与交互（Grounding & Interaction）、任务推理与控制（Task Reasoning & Control）、外部/系统因素（External/System）、其他（Others），下设共30个细粒度子类型（如"视觉幻觉""坐标/元素定位错误""进度误判"等），并刻意区分"因果源头"与"表面症状"，便于按根因索引和定向修复。
2) CUADebugger 调试器：不是一次性通读整条失败轨迹，而是运行一个主动检查循环，配备两类专用工具——步骤检查工具（拉取任一可疑步骤的前后成对截图，连同该步的动作、推理过程与执行状态，暴露agent"说的"和"屏幕上实际发生的"之间的不一致）和结构化提交工具（强制输出完整诊断：根因步骤、分类标签、证据、修正建议、置信度）。系统还支持可选的情节记忆检索，把历史相似诊断作为"候选证据"引入，但要求针对当前轨迹重新验证而非直接采信。
3) CUAErrorBench 基准：从 Claude 4.5 Sonnet（144条）、Gemini 2.5 Pro（30条）、Qwen 3.5（30条）三种agent来源收集的204条人工标注失败轨迹，标注者从最终失败结果反向追溯，定位最早的因果错误，记录根因步骤、分类标签、证据、修正建议、置信度五个字段，多人标注后合并为单一参考标签。

对204条失败轨迹的人工分析显示，任务推理与控制类错误占绝对多数（110/204），其次是感知问题（36）、定位/交互问题（25）、外部/系统原因（13），另有20例被判定为OSWorld环境内本就不可行的任务。

在 Claude agent 轨迹子集上，使用 CUADebugger 后"标签+步骤"联合诊断准确率从基线 11.2% 提升到 19.6%（Gemini 2.5 Pro 作调试器后端），Qwen 3.5 后端从 7.6% 提升到 14.6%，Claude 4.5 Sonnet 后端从 4.9% 提升到 15.3%，说明诊断增益在不同调试器后端模型上具有一致性。在任务重跑实验中，基于根因分析的方法明显优于仅凭历史记录续跑的基线：单次重跑完成率从 13.89% 提升到 29.90%；持续迭代重跑的成功率从基线 12.2% 提升到 25.86%，逼近人工oracle指导下 29.21% 的上限。此外作者还测试了让LLM在无人工先验的情况下自主演化分类体系，发现不同随机种子生成的分类体系彼此难以对齐命名，仅约15%-28%的人工子类型可通过语义映射找回，这一结果被用来说明人工锚定的分类设计仍是必要的，完全自动化的分类发现尚不可靠。

这篇工作填补了一个此前较少被系统化处理的空白：多模态computer-use agent的因果定位问题。相比纯文本/代码agent的调试（报错栈、单测覆盖率等有天然的定位信号），CUA的失败根因往往埋在"截图看错了""坐标点偏了""以为完成了其实没完成"这类跨模态不一致里，很难靠传统日志排查。CUADebugger"主动检查可疑步骤+前后截图对比"的设计思路，本质上是把调试问题转化为一个有工具可用的子agent任务，这与duplex agent中"交互层负责实时反馈、思考层负责深度校验"的分工逻辑有相通之处——都是通过引入一个独立于主执行流的检查/校验回路来提升系统鲁棒性。不过论文中19.6%和25.86%的绝对数值仍然偏低，说明CUA错误诊断这件事本身难度很大，短期内更适合作为提升可用性的辅助手段，而非可完全自动化替代人工排查的方案；另外29%的human-oracle上限与25.86%的差距，也提示当前调试器的证据获取（仅前后截图+动作日志）可能还不足以还原完整的因果链，后续如果能引入更细粒度的中间状态（如DOM/可访问性树）或许还有提升空间。