Mini-SWE-Agent は、Python で書かれたミニマリストなオープンソースのソフトウェアエンジニアリングエージェントである。バージョン 2.4.5 のソースを調査した ハーネスエンジニアリング：コーディングエージェントの解剖、アーキテクチャ、進化 ― 11 システムのソースコード研究 において、これは 11 のシステムからなるコーパスの中の「100 行の研究上の下限」とされている。論文は、同論文が エージェントハーネス の中に見出す 7 つのサブシステムのすべてを、これがおよそ 100 行で実装していると説明している。すなわち、1 つの while ループ、1 つのテンプレート、1 つのツール、1 つのメッセージリスト、2 つの上限、オーケストレーションなし、そして拡張の手段は構造的型付けのみ、というものである。論文はこれを Princeton と Stanford によるものとしている。
論文は、このミニマリズムを意図的なものとして位置づけている。この設計は、モデルの能力をスキャフォールディングの複雑さから切り離し、一方がどの程度もう一方の代わりになりうるかを確かめるためのものである。同研究の全体を通じて、これは他のシステムにおける各サブシステムの実装を比較する際の最小形として用いられている。
機能
ループは、モデルに問い合わせて返されたアクションを実行する線形の while True であり、ステートマシンもイベントソーシングも並行処理もない。メッセージリストは際限なく増え続け、完全にモデル自身のコンテキストウィンドウに依存しており、論文はこれによって軌跡が完全に再現可能で分析しやすくなると述べている。ツールは bash の 1 つだけで、サブプロセス呼び出しとして実行される。プロンプトは 1 ターンにちょうど 1 つの bash コマンドを要求し、各呼び出しは新しいサブシェルで実行されるため、ディレクトリや環境の変更はコマンドの前にインラインで付ける必要がある。プロンプトは YAML 設定に埋め込まれた Jinja2 テンプレートで、セッション開始時に一度だけレンダリングされ、モデルへのアクセスは LiteLLM を介して行われる。
安全のための仕組みはリソースの上限、すなわちステップ数の上限とコストの上限で、2.4 系ではこれに実時間の上限と連続する不正な形式の応答の上限が加わった。さらに、オプトインの対話的な確認モードがある。論文はこれを、ベンチマーク評価には十分だが本番利用には不十分だとし、この下限でさえ最小限の行き詰まり検出器を備えるようになったことを指摘している。実行は、Docker、Singularity、Bubblewrap などの差し替え可能な環境で行える。拡張は Python のプロトコルを通じて行われ、Model、Agent、Environment のいずれかのプロトコルを実装したクラスであれば継承なしに差し替えられる。論文はこれを、そのコーパスの中で最も軽量な拡張の仕組みと呼んでいる。
採用状況とエコシステム
論文は Mini-SWE-Agent を、ループの洗練度はベンチマークの性能を予測しないという観察の主な根拠として用いており、このプロジェクトが SWE-bench Verified で報告している結果が、はるかに大規模なシステムと同じ範囲に収まっていることを挙げている。論文は、そうした数値が自己申告であり、異なるモデルと異なる時期に得られたもので、直接の比較ではないことを明記している。同じ研究は、自らの最初の設計上の推奨事項 ― 線形のループから始めること ― の手本としてもこれを挙げており、同研究の 90 行の最小限の実用的なハーネスのスキャフォールドは、他のシステムのパターンと組み合わせる線形ループの出典として Mini-SWE-Agent の名前を挙げている。別プロジェクトである SWE-agent については SWE-Agent を参照のこと。