Reef は完全にオープンソースです: https://github.com/Human-Agent-Society/reef
1. あらゆる「RSI」の誇大広告が現実になる前に
今日の RSI をめぐる熱狂が完全に現実化する前に、私たちは Reef をオープンソース化したいと考えています。これは、私たちが同じより広範な問題、すなわちエージェント(ハーネス + モデル)が経験から継続的に進化できるようにするために構築してきたインフラです。
その目標は、オープンソースコミュニティが継続的な自己改善を実験し、そのための本番環境グレードのインフラに容易にアクセスできるようにすることです。ここでは、継続的な自己改善をより広範で実用的な枠組みとして使用し、RSI は同じアイデアのより完全に再帰的な形態を表しています。¹
2. なぜ継続的な自己改善には新しいインフラが必要なのか?

GIF
ほとんどの LLM インフラは、比較的単純なライフサイクルを想定しています。モデルを訓練し、評価し、デプロイし、そして推論に使用します。継続的に自己改善するエージェントにとっては、この設定の背後にある 2 つの前提が崩れ始めると考えています。
第一に、推論はもはやパイプラインの終点ではありません。エージェントは作業中に、軌跡、実行結果、ユーザーフィードバック、将来の改善に繋がるその他のシグナルなど、有用な経験を生成します。推論時に起こることは、単に提供して破棄するものではなくなり、学習プロセス自体の一部となります。
第二に、進化するのはモデルだけではありません。エージェントはモデル以上のものであり、継続的な自己改善はモデルの重みに限定されるべきではありません。プロンプト、メモリ、スキル、ツール、オーケストレーションロジックはすべて、経験から改善される可能性があります。より強力なモデルはエージェントの能力を拡張し、より優れたハーネスはそれらの能力をより効果的に引き出し、複雑なタスクでより確実に実行するのに役立ちます。
これらの変化が組み合わさることで、かつてはほぼ順次的なパイプラインであったものが、継続的な進化ループへと変わります。エージェントは対話し、経験を生成し、自身のさまざまな部分を改善し、それらの変更を維持する価値があるかどうかを評価し、システムの新しいバージョンとしてサービスに戻ります。
これが、私たちが Reef を単なる訓練インフラとは考えない理由でもあります。訓練はループの一部に過ぎません。継続的な自己改善のためのインフラは、ライブ推論から始まり、エージェント全体の進化をサポートする必要があると考えています。

GIF
3. そのようなインフラには何が必要で、Reef はそれをどのように実装するのか?

Reef アーキテクチャ
継続的な自己改善のためのインフラは、経験、エージェント、更新の 3 つをエンドツーエンドで所有する必要があります。つまり、(1) ライブトラフィックから学習し、(2) モデルとハーネスの両方を更新し、(3) 更新のリリース方法を適切に評価、バージョン管理、制御することです。
経験を所有する — 学習はライブサービングの上に構築されなければならない
推論と訓練は歴史的に切り離されてきました。一部の RL インフラ(例:Slime、veRL)はデータ生成のために推論エンジンを組み込んでいますが、これらのシステムはモデルサービングではなくモデル訓練用に設計されています。私たちは、継続的な自己改善インフラはまず推論インフラであるべきであり、ライブ推論を中心に訓練能力を構築すべきだと考えます。システムは実際のアプリケーションにサービスを提供し、テスト時の経験を収集し、学習レシピがそれを継続的に消費できるようにします。 この信念は、訓練シグナルの生成や訓練サンプルの選択を含む、多くの設計上の選択の再考につながります。
推論は Reef にとってネイティブです。Reef は標準的な推論エンドポイントを公開しており、既存のアプリケーションに簡単に統合して、自己進化するシステムに変えることができます。
1# client = xxx # Reef のサービングエンドポイントへの httpx クライアントを初期化23# Reef を通じた標準的な推論呼び出し、Open-AI 形式4response = client.post(5 "/v1/chat/completions",6 json={"model": xxx, "messages": xxx},7)89# Reef によって保存された推論レコードへの参照10receipt = response.headers["x-reef-agent-record-id"]
アプリケーションは、特定の推論呼び出しに関連する報酬、評価者のフィードバック、またはその他のシグナルを、以下を通じて報告することもできます。
1# 対応する推論レコードにフィードバックを添付2client.post(3 "/reef/report",4 json={"feedback": "wrong answer", "references": [receipt]},5)
ライフサイクル全体を通じて静的であり続ける既存の推論エンジンとは異なり、Reef はステートフル推論を提供します。Reef は推論トレースとフィードバックを構造化された経験ストリームとして保存し、オフポリシーの陳腐化、セッションのマージ、重複排除などの問題を処理します。学習レシピは、このストリームがどのように処理されるか、どの学習アルゴリズムが使用されるか、そしていつ更新が評価されデプロイされるかを定義します。これにより、異なるアプリケーションが同じインフラ上で独自の学習戦略で進化できるようになります。
エージェント全体を所有する — モデルとハーネスの両方がステートフル推論を通じて進化する
エンドツーエンドの結果を提供できる AI エージェントは、モデルだけでなくハーネスもで構成されます。モデルはタスクを解決するために必要な基礎的な能力を提供し、ハーネスはツール、コンテキスト、メモリ、フィードバック、オーケストレーションを管理することで、複雑で長期的な軌跡にわたって信頼性の高い実行を可能にします。この 2 つは密接に結合されています。ハーネスはモデルの能力がどのように引き出され、具体化され、実行されるかを決定し、モデルはハーネスが確実にサポートできる実行の形態を決定します。したがって、どちらかの進歩は、もう一方の最適な設計を変える可能性があります。継続的な自己改善インフラは、モデルの重みだけでなく、プロンプト、メモリ、スキル、ツール、オーケストレーションロジックを含む、エージェントスタック全体の共同進化をサポートする必要があります。
Reef はモデルとハーネスの両方の更新をサポートします。
ハーネス側では、Reef は Cordis を「訓練バックエンド」として使用します。ハーネス進化レシピは通常、エージェントの軌跡とフィードバックを分析し、ハーネスへの編集を提案します。このプロセスは Reef 内で完全に実行され、進化した各ハーネスバージョンはインストール可能な更新としてユーザーにリリースされます(Reef が localhost:8900 で提供されていると仮定)。
1curl -fsS -H "Authorization: Bearer $REEF_TOKEN" \2 'http://localhost:8900/reef/harness/install?adapter=pi' | bash
上記のコマンドは、典型的なコーディングエージェントとほぼ同じ方法で、Reef でラップされた Pi ハーネスをインストールします。ハーネスは Reef のステートフル推論エンドポイントを使用するように設定されているため、その推論トラフィックは Reef を通過します。ユーザーが作業するにつれて、Cordis は設定されたハーネス進化レシピに従ってハーネスを進化させ、新しいバージョンが Reef を通じて利用可能になります。次回ユーザーがハーネスを開くと、次のように表示される可能性があります。

モデル側では、学習レシピが Reef レコードを消費してモデルの重みを更新します。訓練は、分散訓練バックエンドを使用してライブサービングと非同期に実行され、現在は Slime から適応されており、チェックポイントや LoRA アダプターなどの候補となる重み更新を生成します。
候補が評価に合格し、デプロイが承認されると、Reef はそれをシナリオのモデルアーティファクトの新しいバージョンとして公開し、NCCL ベースの重み同期を使用してサービスを再起動することなくサービングエンジンをホットアップデートします。
更新を所有する — 進化したリリースは評価され、バージョン管理される
継続的に進化するエージェントは、特に進化がパフォーマンスの向上を保証するものではないため、サービス品質の低下の影響を受けやすくなります。そのため、進化した各候補はリリース前に評価されるべきです。Reef は、進化した候補が現在シナリオにサービスを提供しているアーティファクトを置き換えることを許可するかどうかを制御します。候補が拒否された場合、サービングは変更されません。それ以外の場合、Reef はそれを新しい監査可能なリリースとして公開します。
Reef が進化させることができるもの(モデルチェックポイント、LoRA アダプター、ハーネスツリー、ルーティングポリシーなど)はすべて、バージョンコントローラーによって管理されるアーティファクトとして表現されます。Reef はアーティファクト、特にモデルの重みなど大きなディスク容量を占めるものを管理するために Git LFS を採用しています。リリースパスは次のとおりです。

各シナリオには追加専用のリリースチェーンがあります。Reef は比較交換を使用してシナリオのリリースヘッドを進めるため、古いパブリッシャーが新しいリリースを上書きすることはできません。リリースパイプラインにより、Reef は継続的なバージョン変更とリリースプロセスを効率的に追跡できます。
4. Reef における継続的な自己改善手法
上記のインフラは、継続的な自己改善のための共通の抽象化を提供します。エージェントが実際にどのように改善するかというロジックは、モジュール式の学習レシピを通じて実装されます。
テスト時に生成されたシグナルをより優れたエージェントに変えるための方法は、オンライン強化学習、テスト時訓練、スキル進化、ハーネス進化、自己対戦など、ますます増えています。異なる名前とメカニズムにもかかわらず、それらはすべて同じ基本的なパターンを共有しています。テスト時に生成されたシグナルが、次のインタラクションを生成するシステムへの更新に変換されるということです。
これらのレシピは、主に 3 つの次元で異なります。
学習シグナル: 改善を促進するシグナルはどのような形式で、どこから来るのか?
経験獲得: 学習経験はどのように生成されるのか?エージェントによって積極的に求められるのか、それとも外部のタスクやインタラクションから事後的に生成されるのか?
進化対象: 実際に変更されるのは何か:モデル、ハーネス、またはその両方か?

Reef ですでにサポートされている、または近日中にサポート予定のレシピ
Reef は、これらのメソッドが同じインフラ上で異なる学習レシピを通じて主に表現できるように設計されています。レシピの使用は簡単です。1 つ選択し、Reef サービスを開始するときに設定します。
1# serve.yaml2reef:3 recipe: recipes.sao.recipe:SAORecipe # 進化レシピをプラグイン4 batch_size: 1 # レシピ固有の設定5 max_staleness: 18
次に、設定を使用して Reef を起動します。
1reef serve -c recipes/sao/examples/sao/serve.yaml
以下に、2 つの例、OpenClaw-RL と TTT-Discover を示します。これらは非常に異なる進化戦略に従いますが、どちらも Reef で実装できます。

GIF
このビジュアルは、Reef における OpenClaw-RL の統合を示しています。ユーザーは、Reef によって非同期に継続的に進化され、ユーザーを中断することのないモデルを持つエージェントと対話します。ラウンドが蓄積されるにつれて、エージェントは徐々にユーザーの好みを正しく解釈することを学習し、満足のいく回答を提供します。

GIF
このビジュアルは、TTT が Packing 32 ソリューションを反復的に改善する方法を示しています。最適化が進むにつれて、ますます効果的なソリューションが発見され保持され、パッキングスコアが徐々に向上します。
5. 結論
Reef は、継続的な自己改善という広範なアイデアを具体的なシステム問題に変えるための私たちの試みです。Reef をオープンソース化することで、この問題を研究しやすくし、単にサービスを提供するだけでなく、経験から継続的に学習し進化するエージェントを構築するための実用的な基盤をコミュニティに提供したいと考えています。
Reef を試し、独自の学習レシピを構築し、エージェントと統合してみてください。コード、ドキュメント、サンプルレシピは https://github.com/Human-Agent-Society/reef でご覧いただけます。Reef が役立つと感じられたら、リポジトリにスターを付けていただけると幸いです。一緒に構築したり、継続的な自己改善についてより広く議論したい場合は、私たちの Discord にぜひご参加ください: https://discord.gg/5y8e5f937k。
- ここでは、RSI よりも広範で実用的な枠組みとして継続的な自己改善を使用しています。これは、AI 自体が次のバージョンを生成するシステムの構築と改善に参加する、RSI にしばしば関連付けられる完全なクローズドループを必要とせずに、経験から繰り返し改善されるシステムをカバーします。Reef はこのより広範な問題のために設計されており、その上でより再帰的な形態の自己改善が出現する余地を残しています。
増え続けるコントリビューター一覧(アルファベット順): Chai Wenhao (@wenhaocha1), Ding Shuangrui (@ShuangruiDing), He Hao, He Haoze, Jiang Chonhe (@JiangChonghe), Jiang Nan (@nanjiangwill), Jiang Xuan, Li Xiaochen (@jacobli99), Liang Paul (@pliang279), Liu Bo (@Benjamin_eecs), Long Boyuan, Mang Qiuyang (@MangQiuyang), Qi Zhenting (@ZhentingQi), Qu Ao (@ao_qu18465), Qu Mingruo, Wang Zhaokai, Yan Xuezhi, Yu Hanfei (@yhfchitanda), Yu Haofei (@haofeiyu44), Yu Simon (@simon_ycl), Zheng Han (@hanzheng_7), Zhou Kaichen (@alex_kai2020), Zhou Zijian (@BobbyZhouZijian), Zhu Jiacheng (@JiachengZhu_ML), Zhuang Dingyi





