LongHorizon-Harness：面向真实电脑环境的长程 Loop Engineering
LongHorizon-Harness：面向真实电脑环境的长程 Loop Engineering
一句话结论
LongHorizon-Harness 把 Claude Code、Codex、OpenCode、DeepSeek Harness 等执行后端外包给一个外层长程循环：恢复目标与已验证状态、选择下一步、执行、检查真实结果、checkpoint 或把失败证据带入下一轮。它不是新模型，而是把 Loop-Engineering 落到 GUI + CLI 混合电脑环境的运行时系统。
为什么对用户重要
用户的 Hermes / llm-wiki radar 本质上也是无人 loop：每天发现来源、评分、写 raw、更新概念、验证索引并报告。LongHorizon-Harness 的价值在于把“长任务能不能持续推进”拆成可工程化的外层机制，而不是把希望寄托在一次超长上下文里。对未来的 Hermes 自动化，最可迁移的是：每轮 fresh context、外部状态、独立验证、失败证据回注、明确 checkpoint。
机制 / 一阶原理
README 给出的核心机制是：模型决定单轮能做什么；harness 决定下一轮做什么、如何验证真实电脑状态、保存哪些进度、失败或 context refresh 后如何继续。它把任务拆成 bounded steps，并让 manager/verifier/state 角色围绕执行后端工作；同一模型、同一执行后端下，README 报告 WeaveBench pass rate 从 51.8 到 80.7、OSWorld 2.0 binary 从 2.8 到 8.3、Terminal-Bench 2.1 success rate 从 69.7 到 77.2。由于这些结果来自项目 README 和待查 arXiv，先标为 medium confidence。
与已有 wiki 的关系
- 对 Loop-Engineering：它把 cron/Ralph 式循环推进到“真实桌面 + 终端 + 多后端”的长程运行时。
- 对 Harness-Engineering：它说明 harness 的重点不只是工具权限，也包括跨轮状态、任务恢复和验证节奏。
- 对 Agent-Benchmarks：它把 benchmark 变量固定为“同模型、同执行 backend，只改变外层 harness”，这比只比较模型排行榜更适合解释工程收益。
对 Hermes / llm-wiki 的可执行启发
- 每日 radar 应保留一个轻量 round ledger：候选、晋升/拒绝理由、失败来源、写入文件、验证输出。
- 对长任务不要无限延长单次上下文；应把任务拆成可恢复阶段：discover → fetch → raw → promote/reject → verify → report。
- 对 GUI/浏览器类任务，若未来进入 Hermes 自动化，应学习“真实电脑状态验证”而非只验证文本计划。
失败模式 / 边界
- README 结果需要用 arXiv 论文、trajectory 或可复现实验进一步验证；今天 arXiv API 429/timeout，未能读论文全文。
- 长程 loop 可能放大错误方向；没有 verifier 和预算上限时，会把“持续工作”变成“持续消耗”。
- GUI/desktop 自动化更依赖宿主环境，macOS/Windows/Linux 差异会影响可迁移性。
写入记录
- 2026-08-21 09:06 CST：新增 LongHorizon-Harness source page，沉淀其对长程电脑使用 loop、checkpoint/recovery 和 benchmark 归因的启发。