Open Swarm

Operating Swarm の操作

Operating Swarm は Python のエージェントワークフローを実行し、共有サービスを通じてモデル API、ローカルエージェント CLI、外部ハーネスを接続します。ターミナルコマンド、OpenAI 形式の HTTP エンドポイント、または React WebUI を使用できます。

実験的なアルファ版です。 ソースコードは公開済みパッケージより先行しています。モデルとツールを使うワークフローは、CLI、API、WebUI を通じて動作確認されています。これは、同梱されているすべてのレシピやリモート連携が動作することを示すものではありません。日付入りの検証レポートを参照してください。

Operating Swarm は、OpenAI の実験的な Swarm の派生プロジェクトとして Open Swarm という名前で始まりました。現在はエージェント、ツール、ハンドオフに OpenAI Agents SDK を使用しています。これは独立したプロジェクトであり、OpenAI 製品ではありません。LICENSE と NOTICE を参照してください。

アーキテクチャ

Python のインポート名は swarm です。Django が設定、認証、永続化された会話を提供します。ブループリントクラスがワークフローを実装します。ApiKindBase は Agents SDK のグラフを実行し、CLI アダプターはホストプロセスを起動し、リモートアダプターは外部ハーネスのプロトコルを呼び出します。チーム編成によって、これらの機能を組み合わせます。API と WebUI はこのバックエンドを共有します。

ブループリントは CLI と API を通じて実行され、専用のウェブページは付属しません。WebUI は共通の製品 UI です。

用語は現在も整理中です。コードでは api、cli、remote、team の基底クラスを使用していますが、古いドキュメントではプログラムによるワークフローを「ブループリント」と呼んでいます。モデルプロファイルは推論エンドポイントを選択します。CLI やリモートをラップしても、その外部プロセスに SDK が注入されることはありません。コンテキストの転送と再開はアダプターによって異なり、すべてのハーネスをまたいだ継続性は確立されていません。

現在のソースをインストールする

WebUI には Python 3.12 または 3.13、uv、Node.js 24+ を使用してください。バックエンド全体のテストにおける基準環境は Linux/WSL です。以下のローカルワークフローは Windows でも動作確認されています。Bash の構文：

git clone https://github.com/matthewhand/operating-swarm.git
cd operating-swarm
uv sync --locked --extra tui
export SWARM_CONFIG_DIR="$PWD/.runtime/config"
export SWARM_USER_DATA_DIR="$PWD/.runtime/data"
export SWARM_CONFIG_PATH="$PWD/.runtime/swarm_config.json"
mkdir -p "$SWARM_CONFIG_DIR"
cp docs/examples/inventory-config.json "$SWARM_CONFIG_PATH"
export OPENAI_BASE_URL="https://api.openai.com/v1"
export OPENAI_MODEL="YOUR_MODEL_ID"
read -rsp 'Model API key: ' OPENAI_API_KEY; echo
export OPENAI_API_KEY
export API_AUTH_TOKEN="$(uv run python -c 'import secrets; print(secrets.token_urlsafe(32))')"
export DJANGO_DEBUG=true

アカウントからアクセスできるモデルを選択してください。すでに Ollama サーバーが起動している場合は、OPENAI_BASE_URL=http://127.0.0.1:11434/v1、インストール済みのツール対応モデルの正確な名前、そして OPENAI_API_KEY=ollama（ローカル用のプレースホルダー）を使用してください。サポート状況はモデルによって異なります。このレビューでは既存の OpenAI 互換ゲートウェイを使用しました。Ollama モデルの検出は完了した Ollama ワークフローのテストではありません。

クローンと同期の後、PowerShell で環境を設定します。

$env:SWARM_CONFIG_DIR = "$PWD/.runtime/config"
$env:SWARM_USER_DATA_DIR = "$PWD/.runtime/data"
$env:SWARM_CONFIG_PATH = "$PWD/.runtime/swarm_config.json"
New-Item -ItemType Directory -Force $env:SWARM_CONFIG_DIR | Out-Null
Copy-Item docs/examples/inventory-config.json $env:SWARM_CONFIG_PATH
$env:OPENAI_BASE_URL = 'https://api.openai.com/v1'
$env:OPENAI_MODEL = 'YOUR_MODEL_ID'
$key = Read-Host 'Model API key' -AsSecureString
$env:OPENAI_API_KEY = [System.Net.NetworkCredential]::new('', $key).Password
$env:API_AUTH_TOKEN = uv run python -c 'import secrets; print(secrets.token_urlsafe(32))'
$env:DJANGO_DEBUG = 'true'

すべての状態は Git で無視される .runtime/ に保存されます。これらは localhost での開発用設定です。共有環境にデプロイするには、本番用の Django 設定、シークレットキー、許可するホスト、認証、データベースの計画が必要です：デプロイ、認証、データベース。ネイティブ開発ではデフォルトで SQLite を使用し、Compose では Postgres を用意します。このレビューでは Docker、Pinokio、デスクトップ用インストーラーは検証していません。

実用的なモデルとツールのワークフロー

同梱の inventory_demo は、架空の在庫から再発注計画を算出します。stock_report ツールが数量とコストをローカルで計算し、モデルがこれを呼び出して結果を説明します。注文を行うことも、シェルアクセスを必要とすることもありません。

uv run os-cli launch inventory_demo --message "What should we reorder, and what will it cost?"

想定される結果は ノートが9冊（36）、フォルダーが6個（18）、合計54 です。もっともらしい回答だけでは、ツールが実行された証拠にはなりません。WebUI では、処理が完了すると stock_report が表示されます。ブループリントのソース。

os-cli と os は同じコマンドです。引数なしで実行すると、オプションの TUI（--extra tui）が開きます。os-api はサーバーを起動します。os-webui という実行可能ファイルはありません。サーバーがビルド済みの React アプリケーションを配信します。

API と WebUI

同じ設定済みターミナルから：

uv run python -m django migrate --settings=swarm.settings --noinput
npm --prefix webui/frontend ci
npm --prefix webui/frontend run build
uv run os-api --host 127.0.0.1 --port 8000

localhost:8000 を開き、inventory_demo を選択して、再発注について質問します。ローカル開発プレビューではブラウザーセッションが確立されます。WebSocket 認証には HTTP ベアラーヘッダーではなくセッションクッキーが使用されます。共有デプロイについては AUTH.md を参照してください。

同じ API_AUTH_TOKEN を設定した別のターミナルで：

curl -fsS http://127.0.0.1:8000/v1/models \
  -H "Authorization: Bearer $API_AUTH_TOKEN"
curl -fsS http://127.0.0.1:8000/v1/chat/completions \
  -H "Authorization: Bearer $API_AUTH_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"model":"inventory_demo","messages":[{"role":"user","content":"What should we reorder, and what will it cost?"}]}'

model は上流モデルではなく、Swarm のレシピ／シートを選択します。Chat completions は stream:true による SSE に対応しています。/v1/responses は model と input を受け付けます。これらは互換性を確保するためのインターフェースであり、OpenAI API と完全に同等ではありません。不明なモデルには 404、不正なメッセージには 400 を返します。トークンが設定されている場合、HTTP 認証情報がない場合や正しくない場合は拒否されます。Ctrl+C で停止します。デモをリセットする際は、オペレーターデータを保持してください。

統合の制限

アダプターを使用するには、別途インストールされ、到達可能で、認証済みのサービスが必要です。os-cli remotes で設定済みのインスタンスを一覧表示できます。リモートプロトコル。ヘルスチェック、一覧取得、推論の完了は、それぞれ異なる検証レベルです。

統合	検証結果
AnythingLLM、OpenMousBot、TrueForge	設定済みのインスタンスは、ヘルスチェックと一覧取得の呼び出しに応答しました。送信結果はレポートに記載されています。
Hermes	10 月 21 日、オプションのライブテストスイートでプライマリがヘルスチェック、検出、実際のモデル応答に合格し、セカンダリは失敗しました。それ以前のプライマリでの応答はタイムアウトしました。
Rakazo、Herdr、ネストされた Swarm	設定済みのターゲットを利用できませんでした。推論が動作するという主張はありません。
Open WebUI	サービスは稼働中でしたが、一覧取得で認証情報が拒否されました（401）。別のインスタンスは停止していました。
Flowise、n8n、Tencent Octop、OpenMuse	設定済みのインスタンスをテストしていません。テストやカタログの項目は、ライブ環境での稼働を証明するものではありません。
Letta	専用のリモートを削除しました。古いローカル設定にはまだ含まれています。API プロファイルとの互換性はここでは検証していません。

MCP クライアント／サーバーモード、メモリーバックエンド、サンドボックスブラウザー、デスクトップ／トレイのインターフェース、TUI 操作、すべての CLI プロバイダー、種類をまたぐコンテキスト転送、インストーラーは、すべてがテスト済みではありません。過去の GIF や設計図は、現在の稼働を示す証拠ではありません。FEATURE_STATUS.md と検証レポートを参照してください。

パッケージとリリースの状況

ソース	内容
このツリー：os-core 0.6.0a1	未リリースのアルファ版準備中です。紹介されているワークフロー／WebUIを使うには、リポジトリをクローンしてください。
GitHub Release v0.5.4（2026 年 6 月 19 日）	過去のタイトルは「django_chat resolves its LLM profile」です。現在の UI とアーキテクチャが登場する前のリリースです。
PyPI open-swarm==0.5.4	Python >=3.10 向けの過去のパッケージであり、現在の os-core ではありません。
PyPI os-core	2026 年 10 月 20 日の確認時点では公開されていません。
packaging/open-swarm-alias	未公開の移行用エイリアスです。os-core の依存関係が利用可能になってから公開してください。

Main では、0.5.4 を再利用しなくなりました。公開ワークフローはこのリポジトリ名を認識し、タグとバージョンの整合性を確認します。インデックスへのアップロードには、引き続き公開者の認証情報または Trusted Publisher の設定と、明示的なリリースが必要です。Python ホイールには React のビルド成果物は含まれていません。WebUI を使用するには、ソースをチェックアウトしてください。PR をマージしても PyPI には公開されません。公開に関する作業はレポートに記載されています。

開発

uv sync --locked --extra dev --extra test
uv run pytest tests/core/ tests/views/ -x -q
npm --prefix webui/frontend test
npm --prefix webui/frontend run type-check
npm --prefix webui/frontend run build

一部のバックエンドテストでは Unix の実行可能スクリプトを使用するため、すべてのチェックを実行するには Linux/WSL を使用してください。Windows の回帰テストでは、設定の分離、プロセスロック、安全な失敗、CLI の終了ステータスを個別に確認します。AGENTS.md と CONTRIBUTING.md にコントリビューションの要件が記載されています。

任意の実サービスチェックは tests/live にあります。開発ホストでプライベートな SWARM_LIVE_<INSTANCE>_URL と認証情報の環境変数を設定してから、uv run pytest tests/live -m live_remote --no-cov -q --tb=no --show-capture=no を実行してください。設定されていないインスタンスはスキップされ、設定済みのインスタンスで失敗するとテストも失敗します。サマリーでは、ヘルスチェック／検出とモデルの回答完了を区別し、正常に動作するインテグレーションの数を集計します。OMB、Rakazo、AnythingLLM には専用のテストターゲットが必要です。

任意の実機 UI チェックでは、明示的なデバイスブラウザー URL の環境変数を使用し、設定されていない場合はスキップされます。Android Chrome は実機のスマートフォンで動作確認済みです。利用可能な ADB 接続では Android ランタイムのみが確認できたため、ChromeOS ネイティブのレンダリングは未検証です。

参考資料：最小限のワークフロー設定、設定の完全な例、設定ガイド、開発者向けマップ、ハンドオフグラフの例。

過去のストーリーボードと GIF は、ANNOUNCE とデモガイドに残っています。これらは過去のメディアであり、現在のインテグレーション確認用ではありません。