LongPuzzleBench：长程视觉 puzzle GUI agent benchmark

LongPuzzleBench：长程视觉 puzzle GUI agent benchmark

一句话结论

LongPuzzleBench 用 6 个确定性浏览器 puzzle 环境、114 个关卡和 16 个 game × difficulty evaluation cells 测 GUI/computer-use agent 的长程视觉推理、状态保持、精确交互和恢复能力；agent 只拿 screenshot 与公开 action feedback，evaluator-only state 走独立评分路径。

为什么对用户重要

许多 computer-use benchmark 偏短任务，容易把“会点一次按钮”误判为“能持续完成工作”。LongPuzzleBench 的价值在于把长程 GUI 能力放在受控、可重复、可本地运行的环境里，让状态漂移、无效动作恢复、空间规划和 delayed consequences 暴露出来。

机制 / 一阶原理

Puzzle game 是可控的长程环境：状态每步变化，正确动作依赖前序状态和未来规划；错误动作可能不会立即失败，但会改变后续可达路径。LongPuzzleBench 用 bundled browser build、fixed catalog、seed 0、repository-relative config 保持复现；评分读取 evaluator-only bridge，而不是把答案暴露给 agent。

这类 benchmark 的一阶原理是 可控长程性：比真实桌面任务更可复现，比静态问答更能暴露 sequential decision failure。它不是测业务知识，而是测视觉 grounding、action precision、plan persistence 和 recovery。

与已有概念的关系

• 对 Agent-Benchmarks：补充长程 GUI 评测的 deterministic environment 与 evaluator-only state。
• 对 Loop-Engineering：长期 loop 不仅要完成最终目标，还要监控中途无效动作、策略漂移和恢复行为。
• 对 Harness-Engineering：agent interface、action set、observation channel 与 scorer separation 是 benchmark harness 的关键变量。

可执行启发

1. Hermes computer-use eval 可以先构造小型 deterministic UI tasks，而不是直接拿真实网站做不可复现实验。
2. 报告除 pass/fail 外，应记录无效动作次数、恢复次数、状态漂移、最短路径差距和观察 token。
3. evaluator-only state 不能通过 prompt、DOM 或工具泄漏给 agent；否则 benchmark integrity 失效。
4. GUI/CLI hybrid agent 应明确何时允许切到 CLI/API 后门，防止绕开视觉任务本身。

失败模式 / 边界

• Puzzle 环境控制性强，但和真实办公软件/网页业务流程仍有 domain gap。
• 如果 agent 只优化 puzzle heuristics，未必迁移到真实 computer-use。
• README 声称的 leaderboard/protocol 本轮未实际运行验证。

深度判断

本轮晋升为正式 source 页，因为它提供可复用的 long-horizon GUI benchmark 设计：确定性本地环境、evaluator-only scoring、公开 observation/action feedback 和宏平均协议，符合短期高权重 computer-use failure mode 主题。

写入记录

• 2026-08-28 09:00 CST：新增 LongPuzzleBench 分析，提炼受控长程 GUI 环境、evaluator-only state 与状态漂移评测对 Hermes computer-use benchmark 的启发。