🎯 问题
Agent 默认'持续行动'（刷页面/调工具强推进度），但很多长时任务的正确策略是'持续关注'：监控、等待、及时响应——没有 benchmark 把等待当首要任务。
刷新页面不会让演唱会门票提前开售。现有基准几乎全部假设反应式环境（状态只因 agent 动作而变）、单会话跑到底。被迫持续行动的 agent 轻则烧钱、重则直接失败（轨迹越长成功率越低）。SentinelBench 把'监控-等待-反应'类任务（Sentinel Tasks）做成可测量对象。
10 个 React+FastAPI+SQLite 的消费应用复刻（仿 Gmail/Slack/LinkedIn/Spotify/Instagram/Robinhood/GitHub/Calendar/Scholar/YouTube），事件按脚本时间线直接写数据库并反映到 UI，世界演化与 agent 行为完全无关。内容由 100 personas + 201 entities 的合成目录填充（MicroMail 260 封邮件、MicroChat 200 条消息等），保证跨应用世界内一致。评测协议对 agent 无侵入：shell 命令模板 + 起始 URL，任何能从终端调起的 web agent 都能测，不绑 Playwright/截图/DOM 格式。
🔧 任务与协议
任务二轴：被动 38/主动 42/no-op 陷阱 20 × 绝对 41/相对 39；生命周期 /init→/redirect→Running→/contact→/evaluate（SQL 判分）；speed_factor 把事件时刻按比例缩放。
被动任务=条件发生后访问 /contact 表单即成功（过早=假阳性失败）；主动任务=数据库终态过任务专属 SQL（如'附件消息存在且已读'）；no-op 陷阱=条件永不触发、坚守到仿真结束才算过——专门惩罚'临截止蒙一把'策略。相对任务（'再多 3 封'）要求记住初始状态，专考长轨迹记忆。任务由 Claude Code (Opus 4.6) 生成：prompt+事件采样+排期+判分 SQL 一体产出，过确定性单测+拒绝采样+人工审校。
Running 状态下事件时刻 = 默认时刻 ÷ speed_factor（默认 1.0 = 10 分钟任务；0.25 = 40 分钟；2.0 = 5 分钟）。宽限期固定 30 秒不随 speed_factor 缩放。/redirect 技巧把 agent 启动时间从测量剥离。指标三件套：成功率、反应时间（完成时刻−条件时刻，no-op 无定义）、token/美元成本（agent 自报 costs.json——非侵入协议的代价）。对照工具：sleep(time) 无条件让出 vs wait_for(condition, timeout)——每秒文本快照 + difflib 增量 diff + LLM 判断变化是否满足条件，周期刷新页面。
📊 结果
GPT-5.4(low)+wait_for 0.75 最好；sleep 中位成本 5.1× 于 wait_for；GPT-5.4+sleep 在 no-op 任务上意外提前放弃。
六条件（GPT-5.4/GPT-4o/Qwen3.5:9b × wait_for/sleep）：GPT-5.4 0.75/0.68，老模型和小模型都停在 0.46–0.49。被动>主动全条件成立；小/老模型在相对措辞上大幅劣化（GPT-4o 0.50→0.23），GPT-5.4 反而相对措辞略好。成本：GPT-5.4 sleep 中位 $1.17 vs wait_for $0.23，工具调用中位 19.5 vs 6——sleep 退化成 5–10 秒的碎片轮询。
speed_factor=0.25（40 分钟，仅 GPT-5.4）：wait_for 0.69/$0.48 vs sleep 0.56/$4.65——差 13 题且便宜 9.7×。sleep 的成本随目标事件时刻线性上涨，wait_for 基本平坦；sleep 失败多为负反应时间（提前放弃——日志里 GPT-5.4 明知条件未满足仍收工）。反应时间细节：GPT-5.4 上 wait_for 平均反而慢 8.4s（diff+LLM 判断的开销），其他模型上 wait_for 更快——三指标必须一起报。
🧭 划界
最近邻是 ARE/Gaia2（同为事件驱动时间独立），差异：网页 vs API+通知队列、触发条件要自己推断 vs prompt 里给定。
作者引 Gaia2 数字：GPT-5(High) 总分 42.1% 但 temporal 任务 0.0%，最好的 Claude-4-Sonnet(thinking) 也只有 8.5%。Pare-Bench 同为 wait-then-act 但触发源是用户模拟器；WebArena/OSWorld 等 CUA 榜全部单会话无等待；产品侧（ChatGPT scheduled tasks、Yutori Scouts、Claude Code monitor 工具）是被测对象而非测量仪。
作者自述局限：事件时刻是人工排布（随机+LLM 排期），非真实时间分布；判定条件多为客观数值，主观条件与短暂条件（'跌破 $500 时买入'——错过即不可能完成）未覆盖；想用于训练需压缩 rollout，但浏览器客户端依赖真实时间（证书/动画/JS 相对时间戳），压缩仿真时间需要全组件同步公共时钟——Gaia2 的'sleep 即快进'在浏览器场景不可行。这段话是'时钟主权'问题最清楚的工程证词。
💡 对主线的启示
调速旋钮已经造好但没人扫阶梯：speed_factor 通用可缩放到任意时长，全文只测 1.0/0.25 两档、0.25 只测了 GPT-5.4，且只往慢拉没往快压。
对 duplex-omni-actor 的三点用途：① 慢端载体首选——shell 模板即插即用，接入约 0.5–1 人周；② no-op 陷阱设计直接吸收进额定速度协议（防蒙对照）；③ '不会等'不仅是成本问题还是正确性问题（GPT-5.4+sleep 在 no-op 上提前放弃）可作 motivation 引用。
注意事项：宽限期 30s 不缩放（拉长任务时相对变严，跨 speed_factor 对比要提）；token 指标依赖 agent 自报；它测'等待与及时反应'（慢压力），不测'思考期间世界跑掉'（快压力）——与 GameWorld-RT/RealtimeGym 的快端压力互补，正好构成我们调速阶梯的两翼。引用纪律（团队卡片）：speed_factor 实测只有 1.0/0.25 两档，不能说它已提供阶梯扫描。