MITチームがReefをオープンソース化：推論サーバーを、学び続けるAIエージェントの基盤に
オンラインリクエストから帰属可能な経験を残し、Recipeがモデルまたはハーネスの候補を生成。評価とバージョンチェーンを経て、次のサービス提供に進む変更が決まります。
- 多くのエージェントはデプロイ後に学習をやめてしまいます。原因はオンラインに経験がないからではなく、推論ログ、フィードバック、トレーニング、バージョンリリースが互いに分断されているからです。
- ReefはServe、Observe、Grow、Commitの各段階で、リクエストを帰属可能な経験に変換し、モデルまたはハーネスの候補を生成します。評価を通過したバージョンだけがサービスに戻ります。
- RecipeはSAO、OpenClaw-RL、TTT-Discover、SkillClaw、GEPAなどの手法を同じ基盤に接続します。シナリオが記録とバージョンを隔離し、学習方法はデプロイ設定が決定します。
- Reefはまず、学習しない記録専用プロキシとして外部モデルの前段に置き、後から段階的に学習を有効化できます。閉ループは更新を制御しますが、フィードバックや評価目標の妥当性まで保証するわけではありません。
エージェントが実際のタスクを完了するたびに、ユーザーが何を修正したか、ツールがなぜ失敗したか、どの実行経路が高い評価を得たか、どの結果が問題を本当に解決したかといった、非常に価値のある経験が蓄積されます。しかし、多くの推論サーバーは回答を返した後、これらのシグナルを捨ててしまいます。モデルが本番環境にデプロイされた瞬間、それは学習を停止した瞬間でもあるのです。
マサチューセッツ工科大学（MIT）の Ao Qu 氏と Human-Agent-Society チームは、この断絶を埋めるプロジェクト、Reef を開発しました。Reef は、オンライン推論、経験の記録、更新候補の生成、評価、バージョンリリースを、長期稼働する一つのクローズドループにつなぎます。これにより推論サーバーは、単に「回答」するだけでなく、エージェントが継続的に学び、自己改善するための役割も担います。
このシステムが解決しようとしているのは、特定のトレーニングアルゴリズムではなく、継続的学習に欠けていたエンジニアリング基盤です。本番トラフィックから信頼できる経験を取り出し、モデルと外側の実行基盤のどちらを更新すべきかを決め、未検証の変更が本番サービスへ直接入り込むのを防ぎます。Reef は、この広い目標を 継続的な自己改善 と呼びます。システムは経験から繰り返し改善できますが、自ら次世代システムを生み出す再帰的自己改善（RSI）をすでに実現したという意味ではありません。
デプロイ後のエージェントが学習を停止する理由
従来の大規模モデルのライフサイクルは、データ収集 → モデル学習 → オフライン評価 → デプロイ → リクエスト対応、という一方向のパイプラインです。学習システムはパラメータがどのように変化するかに関心を持ち、推論システムは結果を安定して返すことだけに関心を持ちます。この二つはデプロイの時点で分断されています。
エージェントの普及によって、この分断の代償はますます大きくなっています。長時間のタスクには、複数ターンの対話、ツール呼び出し、中間状態、実行結果、ユーザーフィードバックが含まれます。これらは「システムが当時何を見ていたか」「何をしたか」「結果は本当に良かったのか」という三つの重要な疑問に答える材料です。こうした経験は、一般的なオフラインコーパスより実際のニーズに近いにもかかわらず、学習システムへ戻す安定した経路がない場合が少なくありません。
もう一つの問題は、エージェントの動作がモデルの重みだけで決まるわけではないことです。プロンプト、メモリ、スキル、ツール権限、オーケストレーションロジックのすべてが最終結果を左右します。ツールの選択ミス、コンテキスト設計の破綻、ルールの不備が原因なら、モデルを追加学習しても高くつく割に効果がないかもしれません。本当に変更すべき対象は、モデルの外側にある可能性があります。
したがって、継続的な学習には、次の二つの断絶を同時に解消する必要があります。
- 推論は終点ではない。 オンラインの軌跡、実行結果、ユーザーフィードバック、環境からの報酬は、次の学習ラウンドへの入力となる。
- モデルだけが更新対象ではない。 重みと、コンテキスト、メモリ、スキル、ツール、オーケストレーションを担当する外側のシステムであるハーネスは、同じ進化とバージョン管理のプロセスに入る必要がある。
したがって、問題は「トレーニングパイプラインをもう一つ追加する方法」から「経験、候補、新しいバージョンを継続的に生成するオンラインシステムをどのように管理するか」へと変わります。
ここで、Reef は、当サイトの二本の解説記事とうまくつながります。ハーネスエンジニアリングは「モデルの外側に何を最適化できるのか」をさらに掘り下げ、OpenAI の ARC-AGI-3 レビューは、ハーネスが結果に与える影響を具体的な実験に落とし込んでいます。Reef が補う次のステップは、これらの変更をオンラインの経験から継続的に生成し、評価を経て、次のサービスのバージョンに安全にリリースできるようにすることです。
一つのリクエストが次の更新に変わるまで
Reef は、学習サイクルを Serve、Observe、Grow、Commit の四つのステップに分けます。Serve はリクエストを処理して記録を残し、Observe はその後のフィードバックを特定のインタラクションに関連付け、Grow は条件を満たす経験を使用して候補を生成し、Commit は評価に合格した候補だけを新しいバージョンとしてリリースします。
この四つのステップが継続的に機能するには、次の三つのエンドツーエンドの機能に依存しています。
| 制御対象 | 解決すべき問題 | 欠如した場合の結果 |
|---|---|---|
| 経験 | フィードバックをリクエスト、コンテキスト、実際のバージョンに正確に関連付ける | サンプルがどのやり取りに由来するか特定できず、トレーニングデータが急速に歪む |
| エージェント全体 | モデルとハーネスの両方で変更可能な部分を特定する | 動作の変化を特定できず、更新対象を誤る |
| バージョンリリース | 候補を評価し、本番バージョンをいつ置き換えるかを制御する | 悪い更新がサービスを汚染し、古いタスクが新しいバージョンを上書きする可能性がある |
まず、経験とフィードバックを関連付ける
Reef はまず推論サーバーです。OpenAI の /v1/chat/completions と Anthropic の /v1/messages リクエストボディを受け入れます。アプリケーションは新しい呼び出しプロトコルを発明する必要はありません。違いは、各レスポンスが x-reef-agent-record-id を追加で返すことです。これは、この推論のレシートのようなものです。
ユーザー評価、テスト結果、環境からの報酬が発生した後、アプリケーションは /reef/report を呼び出し、このレシートを使用してフィードバックがどのインタラクションに対応するかを示します。
response = reef.post(
"/v1/chat/completions",
headers={"x-reef-scenario": "support-agent"},
json={"model": model, "messages": messages},
)
receipt = response.headers["x-reef-agent-record-id"]
reef.post(
"/reef/report",
json={
"score": 0.0,
"feedback": "没有处理空 token 的情况",
"references": [receipt],
},
)
この例のフィードバックは「空の token を処理していない」という意味です。レシートによって、継続的学習で最も基本的な帰属問題、つまりフィードバックがどの推論、どのコンテキスト、どのエージェントバージョンを評価しているのかを特定できます。Reef が言う ステートフル推論 は、チャット履歴を保存するだけではありません。構造化された推論記録、フィードバック参照、シナリオ、アーティファクトのバージョン、サンプルの鮮度まで保存することを意味します。
統一された記録層は、複数ターンのセッション連結、重複サンプル、オフポリシーの陳腐化も処理します。後者は、経験がどのくらい古いポリシーからのものであるか、そしてそれが現在のバージョンのトレーニングにまだ適しているかを測定します。異なるシナリオは、それぞれの記録とバージョンを分離します。レシピはデプロイ設定によって選択され、リクエストはシナリオを指定できるだけで、学習方法をその場で切り替えることはできません。
次に、モデルを変更するか、ハーネスを変更するかを決定する
モデルは言語、推論、生成を担当し、ハーネスはそれらの能力を確実なアクションにまとめる役割を担います。モデルがどんなに強力でも、誤ったツール権限や混乱したコンテキストを補うことはできません。ハーネスがどんなに精巧でも、モデルにない能力をゼロから作り出すことはできません。そのため、Reef は両方を、候補を生成し、評価を受け、バージョンをリリースできる学習面として扱います。
- モデル側： レシピは条件を満たす記録を非同期に取り込み、チェックポイントまたは LoRA 候補を学習します。モデル学習バックエンドは Slime をベースにしています。候補が承認されると、NCCL 経由で重みを同期し、サービスを停止せずに推論エンジンをホットアップデートできます。
- ハーネス側： レシピは、実行軌跡、フィードバック、評価タスクに基づいて、ルール、プロンプト、メモリ、スキル、ツール、オーケストレーションツリーを変更します。Cordis はハーネス進化のバックエンドとして、新しいバージョンをインストール可能なアーティファクトで提供します。対話型クライアントでは、更新するか見送るかを選べます。
モデル重み
レコードがトレーニングバックエンドに送られ、チェックポイントやLoRA候補が生成されます。評価を通過すると、サービングランタイムがホットアップデートされます。
成果物: 新しいモデルアーティファクトハーネス
トレースとフィードバックが、プロンプト、メモリ、スキル、ツール、オーケストレーションツリーの変更を促進します。
成果物: インストール可能なハーネスアーティファクト
公式コードのレイヤリング: 上位のエントリとレシピはアプリケーションカーネルに入り、下位の能力はアダプタ経由でランタイム、トレーニングバックエンド、Git LFS/SQLiteに接続されます。
ハーネスの新バージョンは明確な更新プロンプトで提供され、対話ユーザーはインストールすることもスキップすることもできます。
これにより、「エージェントバージョン」は単なるモデル名ではなくなります。リクエストがどの重みセット、どのルールバージョン、どのスキルセットとツールを使用したかを、追跡可能なバージョンチェーンで記録できます。モデルとハーネスは一緒に変更される必要はありません。レシピは片方だけを更新したり、実行を担当する外部モデルを凍結したまま、ガイドモデルだけをトレーニングしたりすることもできます。
最後に、評価に合格した候補だけをサービスにリリースする
継続的更新の最大のリスクは、システムがノイズ、個人の偏見、報酬ハッキングを学習し、最終的に悪化することです。Reef は「新しい候補」と「サービス中のバージョン」を厳密に区別します。レシピはまず候補を生成し、評価プラグインが候補と既存のバージョンを比較します。候補が拒否された場合、本番サービスは変更されません。評価で異常が発生した場合、プロセスはシャットダウンされ、準備中の更新はリリースされません。
拒否:サービス中のバージョンは変更されません。
承認:アーティファクトをコミット → サービング状態をロード → リリースヘッドを更新。
評価が明確に合格した場合にのみ、Reef はアーティファクトをコミットし、新しいサービング状態をロードして、リリースを進めます。モデルのチェックポイント、LoRA、ハーネスツリー、ルーティングポリシーはすべてバージョン管理できます。Git と Git LFS がこれらのオブジェクトの保存を担当します。
各シナリオは、独自の追記専用リリースチェーンを維持します。パブリッシャーがリリースヘッドを進めるときは、自分が確認した旧ヘッドを宣言しなければなりません。別のタスクがすでに更新をリリースしていれば、compare-and-swap が古い状態に基づくコミットを拒否し、先に始まったトレーニングタスクが新しいバージョンを上書きするのを防ぎます。
このゲーティングにより、更新がルールに従ってサービスに適用されることが保証されますが、「何がより良いか」をチームに代わって定義することはできません。評価セットが狭すぎる、フィードバックに偏りがある、指標が操作されやすい場合、厳格なバージョンチェーンは誤った目標をより確実に実行するだけです。
さまざまな学習方法が一つの基盤を共有する方法
ラーニングレシピは「どのように学習するか」を決定し、共通基盤が記録、バッチ処理、評価、リリースを担当します。オンライン強化学習、テスト時学習、プロンプト最適化、スキル進化はアルゴリズムが異なりますが、次の三つの設定問題に集約できます。
- シグナルはどこから来るのか？ 環境からの報酬か、ユーザーフィードバックか、テスト結果か、次の状態か、それともレビューモデルの判断か？
- 経験はどのように得るのか？ 実際のタスクを受動的に待つのか、それとも能動的に探索、検索、自己対戦を行うのか？
- 最終的に何を変更するのか？ モデルの重みか、ガイドモデルか、ルールか、スキルプールか、それともハーネスツリー全体か？
Reef はすでに複数の方法を同じインターフェースに組み込んでいます。
| レシピ | 経験とシグナル | 主な更新対象 |
|---|---|---|
| SAO | 連続するタスクをテストまたは検証器で採点 | モデルの重み |
| OpenClaw-RL | ユーザーとのやり取りの次状態から利用可能なシグナルを抽出。明示的なレポートは不要 | モデルの重み |
| TTT-Discover | 同じ問題を繰り返し試し、環境報酬でより良い解を保持 | モデルの重み |
| Guidance-TTT | コード検索結果を採点し、実行モデルは固定 | ガイドモデルの重み |
| SkillClaw / Harness Evolve | 失敗トラフィック、実行軌跡、評価タスクからスキルまたはルール候補を生成 | スキルプールまたはハーネスツリー |
| GEPA | 失敗を振り返ってルールを書き換え、小さなバッチと完全な検証セットで選別 | ルールやスキルなどのハーネスコンポーネント |
OpenClaw-RL の例では、架空の学生の72問の GSM8K の課題を個人エージェントに連続して送り、「何回のやり取りで学生の好みに一致するか」で適応速度を測定します。TTT-Discover は別のアプローチを取ります。Packing 32 などの採点可能な問題を中心に反復試行し、環境からの報酬を使ってより効果的な解法を保持します。一方は継続的なインタラクションから受動的に学習し、もう一方は単一の問題に対して能動的に探索しますが、両者とも同じ記録およびバージョン基盤を共有しています。
GEPA は、継続的学習が必ずしも重みの更新を意味しないことをさらに示します。失敗トラフィックからハーネスコンポーネントを選び、より強力なリフレクションモデルに書き換えを提案させ、小さなバッチと完全な検証セットで段階的に選別します。Reef の AIME 2025 検証では、二つのランダムシードでそれぞれ 26.67% から 46.67% へ、24.00% から 36.00% へ改善しました。ただしシードは二つだけです。実装が動作し、改善候補を生成できることは示していますが、さまざまなタスクで他の方法より一貫して優れているとは証明していません。
導入時からトレーニングを始める必要はありません。Basic Recipe はリクエストを記録するだけで学習しません。ローカル GPU がなくても、一つの Reef プロセスで外部 HTTP モデルをプロキシできます。ローカルの SGLang に接続し、トレーニングを起動せずに使うことも可能です。チームはまず、リクエスト、レシート、フィードバック、バージョンチェーンが正しく機能するかを確かめてから、重みやハーネスの更新を有効にするか決められます。
reef-infra の PyPI パッケージには中核インフラが入っていますが、Cookbook Recipes はソースリポジトリ側にあり、wheel パッケージには含まれません。これらの手法を動かすには、ソースをチェックアウトし、それぞれの依存関係を導入する必要があります。モデル学習には通常、ドキュメントに記載された GPU 環境が必要ですが、スキルやハーネスの進化には GPU なしで動く経路もあります。
Reef が本当に変えるもの
Reef は、エージェント開発における三つの分離されたシステムを接続しました。推論サービスは帰属可能な経験を蓄積し始め、モデルとハーネスはバージョン境界を共有し、トレーニング結果は評価とリリース管理を経て初めて本番環境に戻ることができます。
これは、トレーニングがもはや定期的にチェックポイントを生成するだけではないことを意味します。Observe はどのフィードバックが信頼でき、まだ新しいかを決定し、Grow は変更を提案し、Commit はその変更が次のサービスのバージョンになり得るかを決定します。したがって、継続的学習は、オフラインでの実験ではなく、長期的なリリースエンジニアリングになります。
このアーキテクチャに適しているのは、タスクが繰り返し発生し、結果を比較的高い信頼性でテストまたは採点でき、チームが回帰評価とアーティファクトのライフサイクルを維持できる場面です。散発的で主観的なフィードバックしかなく、安定した評価基盤もないなら、クローズドループをつないでも不確実性が速く積み上がるだけです。
Reef は Apache-2.0 ライセンスを採用しており、Python 3.10 以降が必要です。アーティファクトとチェックポイント機能は Git LFS に依存しています。これは、エージェントが実際のサービスで「やりながら学ぶ」ことを可能にするコントロールプレーンを提供しますが、最終的に良い習慣を学ぶか悪い習慣を学ぶかは、フィードバックシグナル、学習方法、評価の質によって決定されます。