LongHorizon-Harness

長時間にわたる Agent をすでに作っていて、「モデルが完了と言うが実際の状態が違う」という問題が大きいなら採用検討に値します。逆に、すぐ使える汎用 AI アシスタントを探している人向けではありません。より正確には、新しい基盤モデルでも完成済みの SaaS ワークフロー製品でもなく、Claude Code や Codex のような実行系 Agent の上に載せる「状態管理＋独立検収」の実行レイヤーに近いです。

証拠上の中核は Manager、Executor、Auditor の分離です。Executor が作業し、その結果を Auditor が実環境の状態から検証して次へ進めます。複数の投稿が、harness だけを差し替えて WeaveBench、OSWorld 2.0、Terminal-Bench 2.1 で改善したという主張を繰り返しています。ここで熱度証明と有用性証明は分けるべきで、拡散投稿や注目論文まとめは関心の高さを示すだけです。能力判断に比較的有効なのは、独立検証、意図的な誤り注入、same model same backend の比較に触れた投稿ですが、現時点ではなお SNS 上の要約が中心で、公式実装情報や第三者の体系的再現は限られます。

コスト面では、証拠から確実に言えるのはオープンソースの枠組みという点までで、公式価格や API 料金表は確認できません。したがって、デモ由来のコスト感を安定した約束として扱うべきではありません。保守的に見ると、既存 Agent への統合、環境状態の観測、監査ループ追加による推論コストや実装複雑性が主な負担になりそうです。トークン削減も一部ベンチや投稿上の主張であり、常に本番で安くなる保証ではありません。

向いているのは、長時間のコーディング、デスクトップ操作、科学ワークフローなど、実環境で多段実行する Agent チームです。ログ、検収ゲート、誤りの連鎖抑制が欲しい開発者には特に合います。逆に、単純なチャットボット、単発ツール呼び出し Agent、検証可能な環境状態が乏しい用途には不向きです。SNS 上の共通認識は「自己申告と検収を分ける方向は良い」という前向きなものが多い一方、議論の質はリポストや論文紹介が中心で、実践チュートリアルや大きなサンプルの実測は少なめです。すでに現場ではもっと素朴な検収策が使われているという指摘もあり、現状は完成された標準部品というより、有望な Agent システム設計として追う段階です。