Argus:証拠で「続けるか曲げるか」を決める長期作業向けの実行環境
この論文は、長期間にわたる思考や研究で「同じ方針を続けるべきか、失敗として軌道修正すべきか」を証拠に基づいて判断し、記録しながら運用する実行環境(ランタイム)を提案します。提案システムはArgusと名付けられており、モデル本体の重みは固定したまま、持続する状態と制御方針を通じて自分のやり方を進化させます。重要な点は、方針変更(ピボット)を正当化するために証拠と役割ごとの審査が必須であることです。これにより「失敗をごまかして目標をすり替える」ことを防ぎます。
研究チームはArgusを四つの役割で設計しました。Manager(管理者)が全体の意図を保持し、Planner(計画者)が次の仕事を選び、Engineer(実行者)が実装と評価を行い、Reviewer(審査者)が成果を検査して承認を出します。実行は「耐久的なプロジェクト状態(shared project state)」上で――ログ、成果物、メモリ、手続き、検証器などを残して――区切られたミッション単位で行われます。論文は作業契約をKt=(ι, ot, ct, vt)という形式で表し、ιは不変のユーザー意図、otはその時点の運用目標、ctは制約、vtは検証基準を示す、と説明します。
Argusの鍵は「検証ゲートつき自己進化」です。新しく得られた記憶、手続き、検証方法、あるいは計画の経路は、該当する役割(たとえばReviewerや許可されたEngineer自己審査)による検査と、可能ならタスク固有の検証器からの証拠が得られて初めて永続状態に取り込まれます。モデルの重みは変えずに、以後のミッションは“変化した探索方針”を引き継ぎます。日常のミッションはオペレーターの決定点まで自律で進行できますが、重大な方針変更は明示的な承認を要します。
評価は複数の比べやすい場で行われ、いくつかの具体的な結果が示されています。SWE-Bench ProではArgusが約78%の成功率を出し、比較対象のDirect Copilotの59%を上回りました(Argusは合計で1.41倍のトークンを使用)。ランタイムが検証に基づいて自己進化した後の“成熟波”では、立ち上げ時と比べて解決入力トークンを21%削減し、1タスクあたりのアクティブ作業時間を15%短縮しました。運用中には34回の検証器による回復と22回の厳密なレビュー・ループ救出が記録されました。さらにAARRI-Benchで76.8%を達成し、数学データ生成では28ポイントの差をつけました。成果物としては、最適化したRWKV6カーネルが上流リポジトリに統合されたことや、数学キャンペーンで偽と判明した経路を保持しつつ証明に基づく境界更新を6回行ったこと、論文作成パイプラインが254ミッションを回し16段階のロールバックを経て提出に至ったことなどが挙げられます。
重要な注意点も明示されています。評価の一部は観察的であり、対照的な学習実験(controlled ablation)は行われていないとされています。内部の検証ケースには公開できない研究者やプロジェクト固有の情報が含まれるため、報告は定性的な動機づけに留める箇所があります。Argusはモデル重みを更新しない「ハーネス(運用基盤)」であって、新しい学習済みモデルを生み出すものではありません。また、外部の検査者が存在するような場面ではランタイムが最終責任を持たない場合があり、公開トレースは「完全に無人で動いた割合」を示す測定を含んでいません。総じて、この報告は証拠に基づく方針変更と履歴を蓄積する実用的な方法を示すものであり、より厳密で制御された評価が今後の課題として残ります。