Argus、固定重みのエージェントに経験を蓄積させ、SWE-Bench Proの精度を59％から約78％へ向上

Argusの中核はモデルの重みを更新することではなく、エージェントの実行レイヤーを、蓄積と監査が可能なステートマシンへ変えることにある。Managerはユーザーの当初の意図を保持し、Planner、Engineer、Reviewerは、予算、目標、検証条件が明確に定められた個々のmission内で作業する。メモリ、スキル、validator、ルーティング判断、さらには失敗したアプローチも、各ロールによるレビューまたはタスク固有のテストを通過した場合に限り、長期状態へ書き込まれる。これにより、一度の誤りがそのまま後続作業を汚染することを防ぎ、複数sessionにまたがるタスクでも、すでに除外されたアプローチをシステムが保持できる。

論文では、7種類のタスクに対して、それぞれ異なるタスク固有の指標を使用している。このうち、GPT-5.5を利用したSWE-Bench Proの実験では約78％の精度を達成した。Copilotを直接使用した対照群は59％だったが、Argusが消費した総token数は対照群の1.41倍だった。状態の蓄積が進むにつれ、成熟段階では1問当たりの問題解決用入力token数が初期段階より21％減少し、エージェントの稼働時間も15％短縮された。Reviewerのプロセスでは、validatorによる34件の救済と、厳格なレビューサイクルによる22件の救済が記録された。これらの数値は「初期投資によって後続の再利用を可能にする」という考えを裏付けるが、あらゆるワークロードでコストが下がると直接結論づけることはできない。

より具体的な外部証拠として、エージェントはFlash Linear Attention向けのTileLang RWKV6カーネルを生成した。H100上の指定ワークロードでは、forward passのレイテンシが0.199ミリ秒から0.168ミリ秒へ短縮された。maintainerによるレビューでは、長いsequenceで指数オーバーフローが発生するリスクが見つかり、ブロック単位の局所的なセンタリングを追加するよう求められた。エージェントが修正し、テストを再実行した後で、コードはようやくマージされた。これは検証ゲートの価値と限界を同時に示している。エージェントは採用可能な成果を生み出せる一方、benchmarkでは表面化しなかった数値上の問題を発見するには、依然としてドメインエキスパートが必要だった。エンジニアリングチームが今後注視すべき点は、完全なruntime、実行トレース、再現可能な評価が公開されるかどうか、そしてタスクやモデルを切り替えた後に永続メモリが誤りの蓄積を引き起こさないかどうかである。