AOI / DynaCU-Bench — dynamic computer-use observation interface

AOI / DynaCU-Bench — dynamic computer-use observation interface

一句话结论

为什么这对用户重要

用户近期关注 long-horizon computer-use agent 的失败模式：verified state、GUI/CLI 切换、状态漂移、恢复失败、报告夸大。AOI 的价值不在于又一个 computer-use demo，而在于它把失败根因拆到 observation interface：如果 agent 没看见动作间状态变化，后面的 planner、executor、auditor 再强也只能在过期状态上推理。

对 Hermes 来说，这也能迁移到非 GUI 场景：cron / coding / wiki ingest 的“观察”不应只看最终文件列表，而应采样关键中间信号，例如 source fetch 状态、API 429、raw hash、写入 diff、reindex 输出。缺失中间观察时，最终报告很容易夸大。

机制 / 一阶原理

AOI 将观察与行动解耦：agent 仍按离散 step 行动，但 AOI 在 step 间连续观察，并把动态信息压缩成现有视觉模型可消费的稀疏图片和文本。三个门控组件分别处理：约 3Hz 的 keyframe capture、音量门控的 Whisper 语音转写、以及 visual narration。静态/静音时门控几乎不产生成本，动态时才补充观察。

DynaCU-Bench 包含 100 个动态浏览器任务，覆盖 audio perception、visual-temporal perception、real-time interaction。多数任务用确定性 page-state check 评分，少数结合 LLM rubric；另有 Static-50 no-degradation control 和 DynaCU-Real-Local 跨 ASR/真实录屏鲁棒性集合。这让 benchmark 不只测“能不能看图”，还测动态观察是否在静态任务上不退化。

与已有 wiki 概念的关系

• 与 Loop-Engineering：它补充了 loop 的 observation layer，说明 verified state 必须来自足够新鲜、足够连续的环境信号。
• 与 Agent-Benchmarks：它把 computer-use benchmark 细分为动态视觉、音频、实时交互和静态无退化控制。
• 与 Harness-Engineering：它提醒 harness 需要显式定义 observation contract，而不是默认每步截图等价于真实状态。

对 Hermes / llm-wiki 的可执行启发

1. 在长程任务报告里区分“最终状态已验证”和“中间状态未观察”；后者应降为 medium/low confidence。
2. 给 radar loop 增加轻量 observation ledger：候选来源、访问结果、读取证据、写入文件、验证输出，避免只凭最终自然语言总结。
3. 对未来 GUI/browser 自动化，不要默认 screenshot-only；需要考虑 keyframe、DOM/CLI/API 交叉验证和 transient event 捕捉。

失败模式 / 边界条件

• AOI 可能增加上下文 token，且 README 明确提到某些模型会因 keyframe-token dilution 受损；组件应按模型/任务选择，而不是全开。
• 动态任务中音频服务、浏览器、Playwright、边缘 TTS、Whisper/vLLM 等依赖较重，复现成本高于普通静态 benchmark。
• LLM-judge 任务比例虽小但仍引入评测噪音；关键 claim 需要读取论文和 committed results 进一步复核。

写入记录

• 2026-08-24 09:00 CST：新增 AOI / DynaCU-Bench source 页，提炼动态 observation interface 对 computer-use loop 与 llm-wiki radar observation ledger 的启发。