Ouroboros:レビュー済みコミットで自ら進化するコーディングエージェント
導入
コーディングエージェントの評価は、しばしば「いま目の前の課題をどれだけ解けるか」に集中しがちです。Ouroboros の論文が扱うのは、その一段下にある実行基盤です。つまり、エージェントが使うツール、プロンプト、コンテキストの組み立て方、そしてハーネス自体の実装を、レビュー済みコミットを通じて継続的に改善し、その変更を後続の作業環境へ反映するという発想です。
主要ポイント
- 改善対象はモデル出力だけではない:Ouroboros は単なるプロンプト手法ではなく、エージェント・ハーネス全体を進化させる仕組みとして説明されている。ツール、プロンプト、コンテキスト構築、コアコードの変更がレビューを経て取り込まれ、次の実行時に利用される。
- 二つの進化モード:一つは「再帰的自由進化」で、システム改善そのものをタスクとして扱い、1 回の進化サイクルの完了後に次のサイクルを予定できる。もう一つは「経験駆動型のコア進化」で、通常作業や統治された人間との対話からバグ、使いにくさ、非効率なコンテキスト構築を発見し、構造的な変更につなげる。
- ベンチマーク結果はスナップショットで評価:論文によれば、Opus 5 を用いた実行で Terminal-Bench 2.1 は 86.74%、OSWorld-Verified は 90.69% に到達した。また、5 回 rollout の CL-Bench キャンペーンでは正規化報酬 0.2301 を記録した。重要なのは、これらの評価が凍結されたシステムスナップショットで行われ、ライブ進化中の Hope とは別系統だと説明されている点だ。
- Hope は長期公開デプロイの事例:Hope は、公開記録のある Ouroboros デプロイとして最長とされ、161 日間の自由進化実験として運用された。七つの統治された人間コミュニケーション面で動き、人間とのやり取りが問題や提案を生む一方、どの変更を追求するかはエージェントが決める。
意義と影響
Ouroboros の意義は、エージェントの進歩をモデル性能だけでなく、運用基盤の改善プロセスとして捉えた点にある。実利用から欠陥を見つけ、コンテキストの組み立てを改善し、レビュー済みの変更をランタイムへ戻せるなら、将来のコーディングエージェント競争では基盤モデルだけでなく、その周辺システムの進化能力が重要になる。
同時に、論文は安全面の難しさも明確にしている。自己発展型エージェントが自分のコードを書き換え、新しいモデル API を選べるなら、ガードレールは単なる付属機能では不十分だ。進化や公開環境からの圧力の中でも、レビュー、統治、系統分離が権威を保つ設計が求められる。
コメント
ログイン状態を確認中…
コメントを読み込み中…