LongHorizon-Harness

如果你已经在做需要持续很多步的 Agent，并且痛点是“模型总说自己做完了但状态其实错了”，它值得关注；若你只是想要现成通用聊天 Agent，它并不是那类产品。更准确地说，它不是新的基础模型、也不是完整工作流 SaaS，而更像给 Claude Code、Codex 一类执行代理外接的一层“状态管理+独立验收”运行时。

从证据看，它主张把 Manager、Executor、Auditor 分开：执行器负责干活，审计器根据环境真实状态确认进度，再决定后续步骤。多条帖文复述了相同论文结论：在 WeaveBench、OSWorld 2.0、Terminal-Bench 2.1 上，仅替换 harness 就出现通过率或完成率提升、且部分场景 token 更省。这里要区分，X 转发和“注目论文”只能证明热度；对能力判断更有价值的是多条内容具体讲到独立验收、故意注入错误看是否纠偏、以及“same model same backend only harness changes”的对照说法，但目前仍主要来自社媒转述，官方仓库与系统化实测样本不足。

门槛与成本方面，现有证据只能支持它是开源框架思路，未见明确官方定价，也没有可靠 API 费用表，因此不能把任何演示成本当稳定承诺。保守看，真实成本主要会落在接入现有 Agent、维护环境观测、增加审计步骤后的推理与工程复杂度上；是否更省 token，也仅能说论文/社媒演示在部分基准中如此，不代表所有生产任务都降本。

适合对象是已经在做长程编码、桌面操作、科研工作流等真实多步任务的 Agent 团队，尤其是需要日志、验收闸门、错误不连锁放大的开发者；不太适合只想快速搭个聊天机器人、单步工具调用 Agent，或没有环境状态可验证的场景。社媒共识整体偏正面，集中认可“把自我评估和验收拆开”的方向；但讨论质量以转发、论文介绍和观点帖为主，教程和完整复现实测较少，也有人认为生产里早已有更土但有效的验收办法，所以当前更像值得跟进的框架方向，而不是已被大规模证明的现成标准件。