Bernstein Multi Agent Orchestration

---

ステータス：ベータ版。 個人で保守しており、活発に開発中です。バージョン番号は成熟度ではなくリリース数を示します。マイナーバージョンでもインターフェースが変更される場合があります。依存するものについてはバージョンを固定してください。不具合は迅速に修正しますので、報告してください。

Bernsteinは、AIエージェント向けのオープンソースのガバナンスレイヤーです。ポリシーをコードとして実行します。誰が何を実行できるか、何に承認が必要か、何を記録すべきかをポリシーとして記述すると、Bernsteinがそれを適用し、検証可能な記録を生成します。決定論的なスケジューラー（調整処理にモデルは介在しません）がエージェントを並列実行し、生成物を審査し、すべてのステップを記録するため、実行結果は後からオフラインで、成果物だけを使って検証できます。CLI コーディングエージェント（Claude Code、Codex、Gemini CLI など50以上）はすぐに利用でき、同じレイヤーであらゆるエージェントのワークロードを管理できます。成果物は差分、調査レポート、データセット、監査証拠パックなどにできます。エアギャップ環境向けのインストールプロファイルも含まれています。Apache-2.0。

概要

ほかと異なる点は5つあります。以下で詳しく説明します。

• 調整ループにLLMを使いません。 スケジューリングは通常のPythonで行うため、実行を最初から最後まで再現できます。昨日の計画を再生すれば、昨日と同じタスクグラフが得られます。
• ハードウェアキーによる証拠。 オフラインのPIV管理とFIDO2承認検証は、信頼を固定し、明示的な時刻を記録する同じレシートプロトコルを共有します。トークン管理によってTRACEの信頼レベルが上がることはありません。ハードウェアキーによる証拠をご覧ください。
• 事後に検証できます。 リプレイジャーナルにはすべての実行が記録され、常時稼働するリネージスパインにはリネージを持つすべてのステップが記録されます。オプトインのHMACチェーン監査ログ（BERNSTEIN_AUDIT=1）を有効にすると、オフラインで検証できるレシートが追加されます。非決定性は、再実行の不安定さではなく、該当するステップでのハッシュ不一致として明らかになります。コード以外の成果物も同様に扱われます。タスクでは成果物コントラクト（レポート、データセット、アクションログ、運用結果）を宣言でき、Gitコミットではなく、署名付きリネージレシートによって完了します。
• 設計上、分離されています。 各コーディングタスクには、マージゲートを設けた専用のGitワークツリーが割り当てられます。成果物モードのタスクには、.sdd/workspaces/以下に作業ディレクトリが割り当てられます。エージェントはデフォルトでは変更可能なワークスペースを共有しません。共有される状態はタスクのバックログのみで、タスクはアトミックに取得されます。より厳格なファイルシステムの適用は、サンドボックスバックエンドからオプトインできます。ワークツリーを無効にすると、すべてのタスクが共有チェックアウト内で実行されます。
• 幅広く、ローカルで動作します。 選択可能なCLIエージェントアダプターは50種類以上あり、汎用の--promptラッパーも用意されています。状態はファイルベースで、SaaSを経由せず、サードパーティのデータプレーンもありません。

全機能の一覧は機能ページをご覧ください。機能マトリックスは網羅的な一覧です。

実行の流れ

1つのYAMLファイルで、フェーズ、役割、依存関係、ノードを実行する条件を宣言します。スケジューラーは通常のPythonとして実行します。ファイル内にプロンプトはなく、次に何をするかをモデルが決めることもありません。このグラフは監査証拠パックを生成します。完全なファイルは.bernstein/workflows/audit-evidence-pack.yamlにあります。

name: audit-evidence-pack
version: "1.0.0"

phases:
  - name: scope
    allowed_roles: [manager, architect]
  - name: collect
  - name: validate
    allowed_roles: [qa, security]
  - name: deliver
    allowed_roles: [security, manager]

nodes:
  define-control-inventory:
    phase: scope
    role: architect

  collect-audit-logs:
    phase: collect
    role: security
    depends_on: [define-control-inventory]

  # three more evidence streams collect in parallel:
  # collect-sboms-and-attestations, collect-runbooks-and-policies,
  # collect-eval-results

  assemble-pack:
    phase: validate
    role: docs
    depends_on:
      - collect-audit-logs
      - collect-sboms-and-attestations
      - collect-runbooks-and-policies
      - collect-eval-results

  mock-auditor-pass:
    phase: validate
    role: qa
    depends_on: [assemble-pack]

  remediate-findings:
    phase: collect
    role: docs
    depends_on:
      - source: mock-auditor-pass
        condition: "status == 'failed'"
    retry:
      max_attempts: 3
      until: "status == 'done'"

  sign-and-deliver:
    phase: deliver
    role: security
    depends_on:
      - source: mock-auditor-pass
        condition: "status == 'done'"

flowchart LR
    inv[define-control-inventory] --> logs[collect-audit-logs]
    inv --> sbom[collect-sboms-and-attestations]
    inv --> rb[collect-runbooks-and-policies]
    inv --> ev[collect-eval-results]
    logs --> pack[assemble-pack]
    sbom --> pack
    rb --> pack
    ev --> pack
    pack --> gate{mock-auditor-pass}
    gate -->|failed| fix["remediate-findings (retry x3)"]
    gate -->|done| sign[sign-and-deliver]

各ノードは、そのフェーズで許可された役割を持つエージェントが取得します。タスク内でエージェントが何をしても、役割の制限と承認ゲートは維持されます。コーディングノードは、専用のGitワークツリー内でマージゲートを通過すると完了します。上記のノードは別の方法で完了します。成果物コントラクトで成果物（レポート、データセット、スキャン、アクションログ）を指定し、コミットではなく署名付きリネージレシートによってノードが完了します。グラフがコード、調査、運用上の変更、またはその組み合わせのいずれを生成する場合も、スケジューラー、ジャーナル、オフライン検証は同じです。ソフトウェア、調査、ドキュメント、エンタープライズ、コントリビューターの各ワークフロー向けに、すぐ使えるグラフが.bernstein/scenarios/にあります。

30 秒でインストール

uv tool install bernstein    # or: pipx install bernstein
bernstein init
bernstein doctor             # checks a CLI agent is installed and authenticated
bernstein -g "fix the failing test in tests/test_foo.py"

pipx、pip、brew、dnf、npm、Docker についてはインストールガイドで説明しています。エアギャップ環境向けの wheelhouse については、専用のエアギャップガイドをご覧ください。

上の録画は実際の実行を記録したもので、その証明も付属しています。キャスト、その実行のジャーナルから作成された署名済み実行レシート、そしてそれを固定する公開鍵は、すべてdocs/assets/demo-run/にあります。今見た実行をオフラインで検証するには、次のコマンドを実行してください。

bernstein verify receipt docs/assets/demo-run/run-receipt.json \
    --public-key docs/assets/demo-run/run-receipt.pub.pem

コミット済みのレシートは、上記のコマンドでいつでも再検証できます。改ざんされたコピーは同じ検証に失敗します。scripts/record_demo.shを実行すると、新たな実際の実行から録画、レシート、鍵を再生成できます。ターミナル内のものは何も合成されていません。

実行中のタスクは、どちらのオペレーター画面からでも確認できます。どちらも同じタスク API を参照するため、片方がもう片方の遅延ミラーになることはありません。bernstein liveでは、左右の列がペイン全体として独立してスクロールするため、短いターミナルでも画面下部にあるウィジェットを表示できます。

bernstein live — ターミナルダッシュボード	bernstein gui serve — ブラウザダッシュボード

実行を検証する

ここでの決定性は、信じるものではなく確認するものです。監査を有効にして一度実行し、記録された内容を検証します。

BERNSTEIN_AUDIT=1 bernstein -g "fix the failing test in tests/test_foo.py"
bernstein replay list                 # run ids recorded on disk
bernstein replay latest --verify      # recompute the journal head, name the first divergent step
bernstein lineage verify <run_id>     # recompute the always-on lineage spine
bernstein audit verify                # HMAC chain + Merkle seal (written because audit was enabled)
bernstein audit diagnose <run_id> --signal gate --sign-key KEY
                                      # name the exact step a failure entered the run, as a signed receipt
bernstein verify run <run_id> --signing-key-path key.pem   # sign one portable run receipt
bernstein verify receipt .sdd/runs/<run_id>/run-receipt.json  # verify it offline: file only

ジャーナルは実行のたびに書き込まれます。リネージスパインは常に有効で、リネージを持つ各ステップのエントリーが追加されるため、短い実行では有効な空のスパインで完了する場合があります。bernstein audit verify で検証対象のチェーンが存在するのは、BERNSTEIN_AUDIT=1、コンプライアンスプリセット、または bernstein run --audit を指定して実行を開始した場合に限られます。--audit フラグは bernstein run に属します。上記の bernstein -g 形式では、環境変数を設定してください。

1つの実行レシートには、ジャーナルヘッド、実行によってスパインエントリーが書き込まれた場合はリネージスパインヘッド、さらにオプトイン時には監査チェーンの範囲が、公開鍵を埋め込んだ単一の Ed25519 署名対象として結び付けられます。そのファイルとオペレーターの公開鍵を持つレビュアーは、埋め込まれたアクションとチェーンが変更されていないことを確認できます。HMAC キーも、稼働中の .sdd/ も不要で、改ざん時には最初に不一致が生じたステップを示して 2 で終了します。このレシートは、埋め込まれたジャーナルの状態を特定します。その状態が完了済みジャーナル全体であることを証明するには、独立したヘッド／件数シールも必要です。ファイルのみを使い、--public-key のピン留めを指定しない場合、検証できるのは完全性だけです。レシート内部の整合性は証明できますが、誰が署名したかは証明できず、その旨は判定結果に示されます。詳細は決定論的リプレイをご覧ください。

評価値にも同じ検証可能性が適用されます。bernstein bench run <suite> --reliability k（別名 bernstein eval --reliability k）は、固定された調整のもとですべてのタスクを k 回実行し、pass@1 の上限とともに pass^k の下限（k 回すべての試行が合格する必要があります）を報告します。この結果は署名付きレシートに封印され、bernstein bench reliability-verify がオフラインで再計算するため、捏造された下限は検証に失敗します。詳細はpass^k 信頼性の下限をご覧ください。

仕組み

各目標は次の4段階で進みます。

1. 分解。マネージャーが目標を、役割、担当ファイル、完了シグナルを持つタスクに分割します。LLM の呼び出しは1回で、その後は通常の Python で処理します。
2. 起動。エージェントは、コーディングタスクごとに1つずつ、分離された git worktrees で起動します。アーティファクトモードのタスクには、代わりに通常の作業ディレクトリが割り当てられます。メインブランチはクリーンなままです。
3. 検証。ジャニターが具体的なシグナルを確認します。テストの合格、ファイルの存在、リントの問題がないこと、型が正しいことなどです。
4. マージ。検証済みの作業がメインに反映されます。失敗したタスクは再試行されるか、別のモデルに割り当てられます。

スケジューラーに通常の Python を使う理由と、それによって何を諦めるのかについては、決定性の理由をご覧ください。

日常的なコマンド

cd your-project
bernstein init                    # creates .sdd/ workspace, bernstein.yaml + templates/
bernstein -g "Add rate limiting"  # agents spawn, work in parallel, verify, exit
bernstein live                    # watch progress in the TUI dashboard
bernstein run plan.yaml           # multi-stage plan: skip LLM planning, execute directly
bernstein stop                    # graceful shutdown with drain

PR 自動化、スケジュール、チャットブリッジ、自動修正デーモンなど、オペレーター向けのコマンド全体については、オペレーターコマンドをご覧ください。

bernstein workflow は、エージェント、コマンド、ループの各ノードからなる宣言型 YAML DAG を実行します。中断された実行を再開する機能も備えています。

bernstein workflow run idea-to-pr -g "Add JWT auth"   # prints run_id
bernstein workflow resume <run_id>                    # picks up at the first non-completed node

実行状態は、各ノードで .sdd/runs/<run_id>/ にチェックポイントとして保存されます。再開時には実行開始時にマニフェストのダイジェストが検証されるため、仕様が変更されている場合は、異なるマニフェストが黙って実行されるのではなく、実行が拒否されます。ワークフローマニフェストをご覧ください。

リポジトリの衛生管理ゲート：bernstein readme-l10n verify は、翻訳済み README が英語の原文から逸脱している PR を、古くなったセクション名を示して失敗させます。bernstein readme-l10n sync は、英語版の編集後に翻訳を再同期します。readme-l10nをご覧ください。

対応エージェント

Claude Code、Codex CLI、Gemini CLI、GitHub Copilot CLI、Cursor、Aider、Goose、Muse Code、OpenAI Agents SDK、Amp、Cody、Continue、Devin Terminal、Junie、Kilo、Kiro、AWS Q Developer、Ollama、OpenCode、OpenHands、Open Interpreter、gptme、Plandex、AIChat、Letta Code、Qwen などに対応しています。アダプターの一覧には、30 種類のインストールコマンドが記載されています。bernstein integrations list は、src/bernstein/adapters/registry.py にある、解決対象を定める唯一の情報源から、組み込み済みの 56 種類の連携をすべて列挙します。このうち 54 種類は選択可能なエージェントアダプターで、残りの 2 つは mock テスト用スタブと self-hosted-endpoints エンドポイントプロファイルです。--prompt フラグを持つその他のものは、汎用ラッパーを通じて動作します。

同じ実行内でエージェントを組み合わせられます。定型コードには低コストのローカルモデルを使い、アーキテクチャにはより高性能なクラウドモデルを使えます。bernstein integrations list --installed で、マシン上で利用できるものを確認できます。

ボランティア計算資源

プロジェクトでは、課題をボランティアに公開するよう設定できます。誰でもアカウントやコーディネーターなしで、自分のマシン上で課題を実行できます。プロジェクトは volunteer.json マニフェストで、タスクに許可する操作（サンドボックスのバックエンド、ネットワークの許可リスト、実行時間とメモリの上限）を宣言します。提供者が設定する上限によって許可範囲を狭めることはできますが、広げることはできません。完了したタスクが生成するレシートには、その結果と、実行時に適用された封じ込めの判断が結び付けられるため、メンテナーは数か月後でも、実際に何にアクセスすることが許可されていたのかを確認できます。

bernstein volunteer verify .
bernstein volunteer browse --budget 60

提供者向けガイドではワーカーの実行方法と設定する予算を、プロジェクト向けガイドではマニフェストの宣言方法を説明しています。脅威モデルでは、各境界が保護するものと保護しないものを明示しています。1 コマンドで実行するランナーはまだ提供されていません。現在動作するサブコマンドは verify、browse、budget、verify-bundle、hub です。autopilot は登録されていますが、TaskSource が実装されるまでは実行できません。

トップページの先へ

詳細はすべてドキュメントサイトにあります。

ページ	内容
機能	機能の全一覧：MCP サーバーモード、署名付きエージェントカード、サンドボックスのバックエンド、アーティファクトの保存先、規制マッピング
bernstein_create_task	POST /api/v1/tasks → bernstein_claim → bernstein_complete
MCP サーバー	ローカルの stdio サーバーに加え、インストール不要でレシートを検証できる、ホスト型の読み取り専用エンドポイント mcp.bernstein.run。このリポジトリについての質問は、DeepWikiを通じて MCP 経由で尋ねられます
対象ユーザー	価値が発揮される場面と、Bernstein が適切なツールではない場面
ワークフロー	エージェント／コマンド／ループのノードからなる宣言型 YAML DAG
Web UI	TUI が使用するものと同じ API 上のブラウザーダッシュボード
クラウド実行	実験的機能：独自アカウントの R2 とワークスペースを同期しながら、Cloudflare Workers 上でエージェントを実行します。ホスト型の api.bernstein.run サービスはまだ利用できません
データソース	読み取り専用のクエリレシートと、各結果をその導出元のスキーマスナップショットに結び付けるクエリドライバー
エージェントカタログ	組み込みテンプレート以外のエージェント定義にロールを割り当てます。汎用 YAML／SKILL.md ディレクトリ、または Claude Code プラグインレイアウトのツリーを使用できます
インテグレーション	Bernstein が接続するものを、呼び名ごとに紹介します：SCIM、OIDC、Vault、OPA/Cedar、SPIFFE、OpenTelemetry、MCP、A2A。提供済みのもの、接続済みのもの、今後予定していないものを記載しています
セキュリティ	スコアカード、ファジング、堅牢化
アーキテクチャ	内部の仕組み

名前の由来

Bernstein は、アメリカの指揮者兼作曲家、レナード・バーンスタインにちなんで名付けられました。このプロジェクトは、バーンスタインがニューヨーク・フィルハーモニックを指揮したように、CLI コーディングエージェントのチームを指揮します。全員が合図に合わせて演奏し、楽譜は決定論的で、指揮者が結果に責任を持ちます。

3 つのコーディングエージェントを並行して動かすために Claude の料金を月 400 ドル支払っていたのに、マージ結果が非決定的だったため、bernstein を書きました。Apache 2.0 で、メンテナンスは個人で行っています。最新の統計：bernstein.run。

言及

vinta/awesome-python に掲載され、Augment Code のオープンソースのエージェントオーケストレーター特集で紹介され、Python Weekly #742にも掲載されました。また、このアプローチを awesome-agentic-patterns の決定論的なゼロ LLM オーケストレーションパターンとしてまとめました。

すべての掲載情報：20 以上の awesome リスト、ディレクトリ、ニュースレター、同業者からの引用

awesome リストへの掲載、カタログへの登録、先行事例としての引用、ニュースレターでの言及をすべて含む、追跡中の全リストは docs/mentions.md にあります。掲載情報は見つかり次第追加しています。修正は issue または PR でお知らせください。

管理実行

プランナーやエージェントプロセスを使わずに、空の監査済みコンテナを作成するには、bernstein_run(template="administrative", goal="Weekly sprint") を使用します。bernstein_create_task(title="Review brief", description="...", run_id="admin-...") で手動の作業を追加し、bernstein_run_status(run_id="admin-...") で状態を確認します。メンバーは通常の claim API で割り当て可能で、自動オーケストレーションの対象外です。メンバーが存在する実行は、すべてのメンバーのステータスが done、closed、または cancelled になると完了します。空の実行は開いたままです。オペレーターワークフローをご覧ください。

コントリビューション、サポート、ライセンス

PR を歓迎します。セットアップとコードスタイルについては CONTRIBUTING.mdをご覧ください。セキュリティに関する報告は SECURITY.mdからお寄せください。Bernstein によって時間を節約できた場合は、GitHub Sponsorsをご利用ください。お問い合わせ先：[email protected]。

引用情報のメタデータは CITATION.cff にあります。ライセンス：Apache-2.0。プロジェクト名は TRADEMARKS.mdで別途保護されています。

---

Alex Chernysh · GitHub · X · bernstein.run · タスク通知