把 GUI Agent 的失败讲清楚，而不是只报一个成功率

1. 面试开场怎么讲

30 秒版本

这个项目解决的是 GUI agent demo 很难复盘的问题：最终失败时，我们不知道是页面没打开、 browser target 绑错了、证据没抓到，还是模型真的不会操作某个控件。我搭了一个本地确定性浏览器 benchmark，并围绕 UI-TARS 做了 preflight 修复、capture、judge、step trace 和 failure taxonomy。 最终它能把一次 agent run 变成可审计 artifact，而不是口头描述。

2 分钟版本

1. 背景：GUI agent 的评测很容易停留在“成功/失败”，但工程上更需要知道失败层级： 环境、目标页、证据采集、最终状态，还是具体交互 primitive。
2. 方法：我把 benchmark app、task registry、deterministic judge、run recorder、 UI-TARS integration、CDP preflight、capture bundle、step trace、failure taxonomy 和 finish gate 分层组织，每层都有 schema 和验证脚本。
3. 结果：扩展到 10 个任务后，全部任务都有 capture bundle，finish gate 显示 local 和 integration 都 ready；但 UI-TARS 没有 full success，说明问题不在“没有证据”，而在交互执行质量。
4. 价值：面向 agent reliability，它提供的是 failure analysis workspace，可以指导后续 model/operator 改进，也能避免把环境错误误判成模型能力问题。

2. 项目要解决的问题

GUI agent 看似简单：给模型一个浏览器任务，让它点击、输入、提交，然后看结果。但真正做 benchmark 时会遇到三类混在一起的问题。

3. 组织架构：代码和职责怎么分

项目采用轻量但很清晰的分层：浏览器任务和 judge 是 deterministic core；UI-TARS/CDP 相关代码是 integration layer；实验、报告、taxonomy、finish gate 是 evidence layer；scripts 把这些层串成 可重复运行的命令。

目录视角

核心数据流

4. Benchmark 覆盖了哪些 GUI primitive

任务不是随便堆出来的，而是覆盖了企业应用里常见且容易让 GUI agent 失手的操作类型。 每个任务都有明确的初始状态和可机器判断的成功标准。

5. 证据链：为什么这个项目可信

这个项目最重要的不是“跑了 10 个任务”，而是每个结论都能回到 artifact。面试时可以强调： 我们把一次 GUI agent run 拆成多个可验证层级，每层都有 schema、validator 和失败边界。

deterministic task
  -> UI-TARS attempt
  -> preflight target check / repair
  -> capture.json + trace.json + run-export.json
  -> real-run-summary.json
  -> step trace attribution
  -> failure taxonomy
  -> finish gate

The latest P2 pass adds sanitized, run-scoped native UI-TARS action-event transcripts for three representative attempts: the original settings-toggle run plus two visible-target/screenshot-tool failure attempts for onboarding-form and ticket-review.

6. 当前结果应该怎么解释

面试时不要把 0/10 讲成 leaderboard 结论。更准确的讲法是： 扩展轮次证明 capture completeness 和 environment readiness 已经闭环，所以失败不再主要归因于“我们没抓到证据”。 在这个前提下，失败集中出现在 interaction primitives。

7. 开发过程中的取舍思考

这一节是面试最容易加分的地方。不要只说“我写了哪些模块”，要说你面对不确定性时如何定边界。

8. 实现细节：你需要能讲出来的几个点

8.1 Deterministic judge

public/tasks.json 定义任务和 criteria，src/judge.mjs 对每个 task 写确定性 judge。 评分是通过 criteria fraction 得到的，success=true 只有在所有 criteria 都通过时才成立。 这让 partial progress 可以被保留下来，例如 settings-toggle 通过 3/4 criteria 得到 0.75。

8.2 Browser API

app 暴露 window.__BENCH__.reset()、snapshot()、evaluate()、 exportRuns()、importRuns()。UI-TARS 或脚本不需要读内部实现，只要能打开页面并最终 从这个 API 拿 state 和 judge result。

8.3 UI-TARS preflight

preflight 的关键不是“检查页面能不能打开”，而是检查 UI-TARS 受控 Chrome 的 CDP target 是否唯一、正确、可激活。 它会处理几类高频问题：空 target list、search page start、active target mismatch、多个 benchmark tab、 stale child Chrome、Chrome error page。必要时它会创建新 target、导航 search target、隔离多余 target， 最后激活正确 benchmark tab。

8.4 Capture 和 artifact validation

capture 通过 CDP 在目标页面执行 benchmark capture expression，拿到 finalState 和 evaluation。validator 再检查 summary、capture bundle、taxonomy、step traces、finish gate 是否互相一致。这个设计能防止“summary 写了 captured，但实际没有 capture file”这类证据断裂。

8.5 Oracle baseline

validate:oracle-baseline 用 scripted UI actions 跑过同一个 public/app.mjs 事件路径， 再用 window.__BENCH__.evaluate(taskId) 评分。它验证 10/10 tasks 可以通过 UI actions 得到 score=1，所以当 UI-TARS 失败时，我们可以排除“任务本身不可解”这个 P0 风险。

9. 面试追问准备

Q1：为什么不用真实网站？

可以回答：真实网站适合最终外部验证，但第一阶段我更关心把失败原因拆清楚。真实网站会引入登录状态、网络波动、 DOM 变化、AB test、权限和反爬，容易让 judge 不稳定。本地 deterministic app 能保证同一个状态、同一个 criteria、 同一个 UI path，先把 reliability pipeline 做稳。后续可以把这套证据链迁移到更真实的网站任务上。

Q2：0/10 success 是不是说明项目失败？

不是。这个项目目标不是把 UI-TARS 调到最高分，而是构建能解释失败的 benchmark harness。0/10 full success 在 10/10 captured 和 finish gate ready 的前提下反而有分析价值：它说明环境和证据链已经闭环，失败集中在 dropdown commit、selection commit、modal、pagination、multi-select 等 primitives。项目产出的是 failure map。

Q3：怎么保证 judge 公平？

judge 只看 deterministic state，不读模型日志，也不靠主观截图判断。每个 task 有明确 success criteria； partial score 是 criteria 通过比例；oracle baseline 证明正确 UI 操作可以拿满分。这个组合能降低 judge bug 和任务不可解带来的误判。

Q4：preflight 为什么这么复杂？

GUI agent 的真实失败经常不是模型不会点，而是它根本看错了页面。UI-TARS 可能绑定到 search tab、空 target、 错任务、多个 benchmark tab 或已经失效的 Chrome 子进程。preflight 把这些问题显式化，并在安全条件下自动修复。 这样后续失败才可以归因到 interaction primitive，而不是环境噪声。

Q5：step trace 不是原始动作日志，会不会不可靠？

它的定位不是替代 raw action log，而是把已有 artifact 做成可读的 timeline attribution。每个 step 都标明 evidence kind 和 references，并在 schema 里承认 limitation。现在 P2 已经补了一组三任务 native action transcript 样本，但历史 expanded round 仍然不能被回填成 raw action log。

Q6：你在这个项目里最难的工程问题是什么？

可以讲 target binding。最开始 UI-TARS 有时看着 Google 或错误 tab，capture 也可能因为多个 benchmark target 变得 ambiguous。如果不解决这个问题，所有模型能力结论都会被污染。我后来把 preflight 做成状态机式的检查和修复： 发现 live UI-TARS child Chrome、过滤 stale endpoint、判断 benchmark/search/error target、必要时创建或导航 target、 隔离多余 tab、最后激活正确页，并把每次修复写成 artifact。

Q7：下一步你会怎么做？

1. 修复 UI-TARS 可见窗口绑定，让截图稳定落在 prepared benchmark page。
2. 带 native transcript preservation 重复 10-task expanded round，报告 variance 和 confidence intervals。
3. 把同一 harness 接到更多 GUI agent/operator，对比 failure taxonomy，而不是只对比 success rate。
4. 把 dashboard/GIF 放在证据闭环之后，用可视化帮助读者浏览，不替代 artifact。

11. 面试前代码路径速查