rcua_ticket_002

01概览

页面就绪后三十秒开售，三百四十个竞争买家按冻结的时间表吃掉库存。agent 要在目标区售罄之前，为两位指定观演人买到两张 Floor GA 票，含费总价不超过 760 美元。

三件事决定了这题是否成立：deadline 必须有物理意义（售罄时刻由竞争者时间表事后决定，不是谁拍板定的数字）、预算是含费总价而列表默认显示面价、浏览不持票（选中一条票不构成占位，只有进入结账才有三十秒持票）。最后一条看起来像细节，但它正是实时性的来源——详见第五节。

02流程与界面

七个页面，形态照大型国际票务站的购票流程：演出详情 → 排队室 → 票务页 → 实名观演人 → 验证滑块 → 结账 → 订单确认。站名、艺人、场馆、观演人和订单全部虚构，品牌中性。

场馆图与座位级视图

五十四个编号分区：内场 A1–C2（6）、下层 101–118（18）、上层 201–224（24）、包厢 S1–S4（4）、无障碍 ACC W/E（2）。能买的是同一排相邻座位组成的块，不是单个座位，所以找到目标意味着先认出分区、再认出排。

页面只公布当前打开的那一个分区的座位，不会同时给出所有分区的座位数——把它们加起来就是剩余库存，也就是 deadline。一个分区的票卖完或被撤走，整块在图上变灰。

03七项机制

每一条都是这类网站的真实机制，不是装饰。橙色是阻断——不处理就过不去；灰色是干扰——踩中不扣分，但单列误触发率。

04一局的时间线

t2 标准档。横轴是服务端单调时钟的秒数；把指针移到任一标记上看它是什么。

05实时性从哪来

早先的版本沿用了项目更早的原型的一条规则：竞争者拿不走 agent 已经选中的票。写出来才发现这条规则把整题掏空了——开售瞬间随便点一张 Floor 票，之后慢慢做一百秒照样赢。

第一次完整跑浏览器流程时就撞上了：

deadline_ms            110433     ← 预测 Floor 110.4 秒售罄
order_committed_ms     131278     ← 我 131.3 秒才下单，仍然买到
want_zone_sold_out_ms  131278     ← Floor 最后一批是被我自己买走的

真实站点是到结账才持票，选中不等于占住。改成只有结账持票期间受保护之后，参考解的失效点整体前移了一档，三档难度也因此重新标定了一轮。

代价是票会在犹豫时被买走。为了让这份压力可见而不是无声——一个静静变灰的按钮，截图 agent 很难察觉——服务端会清空选择、给出提示，并记一条 selection_lost 事件，计入 selections_sniped。

06评分与指标

另报、但不进 score 的指标

读结果必须同时看 score 和误触发率：一个见什么点什么的 agent 完全可能拿到高分。

07难度标定

脚本参考解既是可解性证明，也是标定工具：它在假时钟上每个动作收固定的思考时间，于是「这档能不能解」变成一个可测量的问题。下面的数字来自三十个种子的实测。

08演示回放与完成情况

真实运行，按实际节奏重建：每张截图停留到下一张截图出现为止，所以模型想得慢，画面就停得久。红框是点击位置。下面的步骤表和视频同步，点任意一行可以跳到那一步。

视频是用保存的截图和动作时间戳重建的，不是屏幕录制。横条上的蓝线是开售，橙线是目标区售罄，橙色粗刻度是推理超过 8 秒的那几步。

各步完成情况

下面是两个模型这一局各自做到了哪一步，来自服务端事件日志，不是模型自述。✓ 是真的发生了，✗ 是没有。

GPT-6.1 Sol 的失败是被抢：流程走到了第三页，输在插页耽误的时间和竞争者到达之后反复被抢。GPT-4o 的失败是点不中：时序判断没问题（它等到了开售才动手），输在把按钮的位置判断错了，并且 25 次重复同一个错误坐标。前一种和这道题的设计直接相关（插页、选座被抢）；后一种是对按钮位置的判断，和题目设计无关，换一道题也可能出现，这里没有做对照。

换成 2528 的通用 harness 之后

你们站上 2528 的 harness（rcua_realtime_harness_2528.zip，40 KiB，已原样存进仓库的 harness_2528/，记了压缩包的 SHA-256）里，真正通用的只有一小块：realtime_runtime.py 规定了“WAIT 只表示这一轮不操作，不 sleep，下一张截图立刻开始”，再加上它的 EvoCUAAgent 提示词与历史、以及“流里一出现第一个完整动作就截断并执行”的选择器。这三块我原样导入，没有改。

跑法本身是 001 专用的，我只替换了它写死的部分：任务启动与评分（001 没有难度档和冻结 episode）、时间预算（001 是 100 步 / 90 秒外加固定睡 62 秒，002 用 episode 自己的时长，然后等世界走完）、模型入口（它走的是内部网关和密钥文件，这里换成任何 OpenAI 兼容地址加环境变量里的 key），以及拖动：它的 gui_executor.py 对 dragTo 直接抛错（001 没有拖动），而 002 的滑块必须拖。EvoCUA 的 left_click_drag 只有终点，所以模型要先 mouse_move 到把手，我在执行器里记住指针位置来补上。

三局都是 t1 档的 ep00，都是 0 分。GPT-6.1 Sol 两局都走过了排队室、插页和含费开关，输在选中的票被反复抢走。GPT-4o 输在插页：点了 Subscribe 而不是 ×。第一局跑在下面第一个缺陷修复之前，第二局和 GPT-4o 跑在修复之后。

跑真实模型暴露的两个缺陷

• 半买的块仍算选中（引擎）：GPT-6.1 Sol 选中的块有 3 个座位，竞争者先买走 2 个，只剩 1 个。引擎只在整块买光时才判选择失效，所以它带着一块凑不齐两连座的票走完观演人、滑块，到结账付款才被拒。现在座位数一低于份数就判失效，并把已经走到观演人页或滑块页的人送回选座页。
• 评分器与引擎对“持票保护”的理解不一致（评分器）：付款被拒后引擎清空了选择，保护随之消失，竞争者随后买走了那一块；评分器却认为保护要到离开结账页才解除，于是把这份合法的日志判成非法。现在选择丢失或付款被拒都视为保护结束。那份真实日志已存成回归夹具。

这两个缺陷都是单靠脚本参考解和离线测试找不到的：前者要有人在半买的块上继续往前走，后者要有人走到结账再付款失败。

09与大麦版 rcua_ticket_001 的对比

两题是同一条赛道上的两个难度。001 的失败只可能来自反应时间：GPT 第一轮的失败是 58.25 秒取图、63.18 秒才执行提交，错过了 60–61 秒的窗口。002 里失败可以来自许多别的地方：没打开含费开关、刷新了排队室、点了插页上的 Subscribe、认错了座位、勾错了人。一个只有时序压力，一个把时序压力放进了一整条流程里。

有意保持一致的部分

• 服务端权威时钟，与模型推理和浏览器轮询无关；刷新不重置。
• 评分只看服务端事件日志的重放，截图和页面文字不是输入；模型自报完成不算成功。
• 幂等的 request_id，换标识也不会重复生成订单。
• 没有对 agent 开放的 reset、改时钟、改库存或读评分的接口。
• 仅标准库 + 浏览器，无 CDN、无外部素材。

002 比 001 少的东西

• 没有绝对开售时间（--release-at）。
• 没有真实站点的参考记录：001 记了四个访问过的 URL，002 老实写的是没有。
• 几乎没有模型评测：001 有 Qwen、GPT 各 5 局和成功样本视频，002 只有上面这一局。

10冻结 episode 集

三档各三十个 episode，共九十个，加一份 MANIFEST.json。只存种子是不够的——生成器改一行，已发表的数字就悄悄变成关于另一个世界的数字。

MANIFEST 记录每局的文件 sha256、journal 会写入的规范化 episode sha256、以及该档的 config sha256。评测集固定前五局，其余二十五局 held-out。

python3 tools/make_episodes.py --verify

六项验收：文件哈希 · 规范化哈希 · 每局仍能由自己的种子逐字节重建 · 各档 config 仍与当前 scenario 吻合 · 九十局 deadline 全部有限 · 十五个评测 episode 各跑两遍世界逐事件相同。另外独立生成两遍比对，九十个文件逐字节相同。

按 id 启动时会再核对一次哈希。磁盘上被改过一个字段的 episode 会被拒绝启动，服务端根本起不来，而不是跑完九十秒再在评分时发现世界不对。

一个 episode 文件里有什么

以 t1/ep00.json 为例（44 KiB）。整场竞争在开始前就排定了，下面是它的全部内容，数字都取自这个文件。

{
 "tier": "t1",
 "seed": 0,
 "onsale_s": 30.0,
 "episode_len_s": 180.0,
 "competitors": [
  [
   91.1871,
   "Lower",
   2
  ],
  [
   92.9641,
   "Floor",
   3
  ],
  [
   93.4824,
   "Floor",
   2
  ],
  "… 共 340 条"
 ],
 "listings": [
  {
   "id": "LFL00",
   "kind": "standard",
   "price_cents": 21000,
   "row": "E",
   "seat_from": 2,
   "seats": 2,
   "section": "A1",
   "zone": "Floor"
  },
  "… 共 272 条"
 ],
 "resale_listings": "… 共 51 条",
 "disruptions": {
  "hold_at": null,
  "interstitial": "app",
  "interstitial_at": 34.451,
  "queue": true,
  "queue_init": 96,
  "resale_at": null,
  "slider": true,
  "slider_target": 0.738,
  "toasts": [
   31.706,
   33.347,
   37.129,
   38.28
  ]
 },
 "ground_truth": {
  "deadline_s": 124.5676,
  "sellout_s": {
   "Accessible": 140.7196,
   "Floor": 124.5676,
   "Lower": 132.1264,
   "Upper": 146.3028,
   "VIP": 124.6856
  },
  "n_distractors": 9
 },
 "seeds": {
  "err": 1112038970,
  "slider": 2087043557
 }
}

11交付与 OSWorld

任务包按站上已实现 sample 的格式交付：task.json、dependencies.json、provenance.json、reference_notes.md、README.md、checksums.sha256、OSWorld 入口与冻结评分器、单题清单、VM 资源包。打包脚本用固定时间戳与权限写 zip，同一棵树重复打包字节相同。

入口钉死两个哈希

更早的那题把整个配置内联成字符串字面量；这对四十五 KiB 的冻结 episode 不适用，所以改成世界走资源包、身份走哈希：

TIER           = 't2'
EPISODE_ID     = 'ep00'
CONFIG_SHA256  = 93ea1c4691d302c5eae33a7ce1b6ad40238b3535b484c7065f0143ee5ee9518a
EPISODE_SHA256 = 50189fc893f2727ee958c20a88c227a49224790d8b345606b1aaf2c192be1f72

evaluate 把 record、effective_config、effective_episode 三份都拉回评测侧，先确认两个哈希与钉死值一致再判分。为什么钉两个而不是一个：config 与 episode 若被成对换掉，二者彼此自洽，单钉一个查不出来。

12边界

• 没有访问、抓取或复刻任何真实票务站点，因此没有可列的 URL。更早的那题记录了四个实际访问过的页面；这一题没有对应记录，不应被引用为任何真实平台的复刻。
• 场馆图是几何规则生成的原创布局：椭圆碗加等分角度的分区，不对应任何真实场馆的分区表，也没有真实场馆那种不规则的看台形状与视线遮挡。座位级视图只有单个分区的行与座号。
• 难度对着脚本参考解标定，没有用真实模型标过。
• 真实浏览器走通了 1.0 与 0.6 两条正确路径，两次运行的竞争者购买都经过了 listing 级重放；超预算、票数错、勾错人、超时、重复下单由契约测试覆盖，未在界面中逐条复现。
• 真实 OSWorld VM 的 setup / evaluate 尚未运行；模型闭环评测尚未进行。
• 所有时间参数都是本实验配置，不代表任何真实票务平台的参数。支付为模拟，不执行真实付款，不收集支付信息。