LongHorizon-Harness — long-horizon computer-use state harness
LongHorizon-Harness — long-horizon computer-use state harness
一句话结论
AMAP-ML/LongHorizon-Harness 把长程 agent 任务拆成 Manager、Executor、Auditor 三个角色：Manager 维护目标、已验证进展和下一步，Executor 以 fresh context 执行单个清晰任务，Auditor 独立检查真实环境中的文件、界面、日志和测试。只有通过独立验证的结果进入持久状态。这是 Harness-Engineering 从 coding run 扩展到 GUI+CLI 长程 computer-use 的一个高价值样本。
为什么对用户重要
用户的 Hermes 经常要在“知识发现 → 原文读取 → raw 保存 → source/concept 写入 → index/log/reindex → 最终报告”之间保持状态。LongHorizon-Harness 的核心价值是把长任务的脆弱点显式拆开：不是让一个上下文越来越长的 agent 从头撑到尾，而是让执行者反复 fresh-start，并由独立审计者把真实通过的进展写入可信状态。这与 llm-wiki 的 raw/index/log/write-record 纪律高度同构。
机制 / 一阶原理
长程任务失败通常不是单轮能力不足，而是 state drift、上下文污染、失败后无法恢复、验证自证和跨工具进展丢失。LongHorizon-Harness 的三角色结构用两个原则缓解这些问题：
- 状态只接受已验证事实：Executor 可以失败、误判或产生未通过 artifact；但只有 Auditor 检查过的结果才能进入 persistent task state。
- 执行上下文可刷新，任务状态不可丢：Executor 每轮只看当前任务所需材料，避免长期上下文膨胀；Manager 保留原始目标、已验证进展和下一步，使任务可以跨 GUI、CLI、文件、浏览器和应用继续推进。
README 还报告了在 WeaveBench、OSWorld 2.0、Terminal-Bench 2.1 上的同模型/同执行后端 harness 增益；本次未复现实验，因此只把它作为“harness 变量可被测量”的证据，而非本地结论。
与已有 wiki 概念的关系
- 对 Harness-Engineering：补充“Manager / Executor / Auditor + verified state”的长程控制结构。
- 对 Context-Engineering：fresh context worker 是对抗 context rot 的工程手段；不是压缩所有历史，而是只把 verified state 传给下一轮。
- 对 Agent-Benchmarks：强调同模型同后端只改 harness 的 matched comparison，并把 GUI、CLI、混合桌面任务纳入评测。
对 Hermes / llm-wiki 的可执行启发
- 把每日 radar 显式分三层：Manager=候选目标与晋升标准；Executor=搜索/读取/写入；Auditor=文件存在、raw hash、wikilink/index/log/reindex 检查。
- 只把已验证事实写入状态：无法访问、只读到截断内容、API 429 的候选应保持 HOLD/未入库，不应被压缩成正式概念结论。
- 复杂任务采用 fresh-context 子任务：当一次 ingest 涉及 10+ 页面时，应拆成有明确输入输出的 worker，并让主 agent 只合并 verified output。
失败模式 / 边界条件
- 多角色结构会增加协调成本；小任务不应过度使用重 harness。
- Auditor 如果只读 executor 的自然语言报告，就会退化为自证；必须读真实文件、日志、测试或界面状态。
- GUI/desktop 任务有权限和环境依赖；macOS 辅助功能权限、插件状态和进程清理都需要 doctor/preflight。
写入记录
- 2026-08-07 09:00 CST：新增 LongHorizon-Harness 来源页，提炼 Manager/Executor/Auditor、verified state、fresh context 与 llm-wiki radar workflow 的映射。