マルチエージェントオーケストレーション
複数のエージェントを走らせ、順序はコントローラに決めさせる。
事前に書き下せない順序の仕事があります。type: controller を設定して実行終了時に何が真であるべきかを宣言すれば、次にどのエージェントステップを実行するかは、返ってきた指摘を見てモデルが選びます。個々のアクションは通常のワークフローステップのままで、ログ、リトライ、承認、監査履歴が付きます。
# code-review.yaml
type: controller
llm:
provider: anthropic
model: claude-opus-5
system: |
Get top_n.py past both reviews. When a review fails, pass its finding
to revise, then ask that same reviewer again. A revision made for one
reviewer can break the other.
steps:
- name: review_simplicity
description: Judge simplicity. Prints PASS, or FAIL with what to change.
action: harness.run
with:
provider: opencode
prompt: Read top_n.py. Print "PASS" or "FAIL: <what to change>".
- name: review_correctness
description: Judge correctness. Prints PASS, or FAIL with the bug.
action: harness.run
with:
provider: codex
prompt: Read top_n.py. Print "PASS" or "FAIL: <the bug>".
- name: revise
description: Edit top_n.py to resolve one review finding.
action: dag.run
with: { dag: revise }
tasks:
- name: simplicity_passed
description: The latest simplicity review returned PASS on the current file.
- name: correctness_passed
description: The latest correctness review returned PASS on the current file.ステップ順序ではなく完了条件を宣言する
各アクションは実際のエージェント CLI: Claude、Codex、Gemini、OpenCode
タスクは完了、スキップ、失敗のいずれかで決着する
人間の回答待ちはプロセスを残さずに中断できる
一目で比較
コントローラワークフローとエージェントフレームワーク
完了条件を宣言します。open のタスクがなくなった時点で実行が終わります。
モデルが終了を判断するか、すべての経路を前もって描いて人手で維持することになります。
待機中の実行はプロセスを終了し、別のプロセスで再開します。
長時間の待機は、生かし続けるプロセスと自前で運用するステートストアを意味します。
スケジュール、キュー、リトライ、成果物、監査履歴が DAG 実行から得られます。
プロジェクトごとに作り直すか、ホスト型の制御面に委ねます。
ワークフローファイルに書かれたステップの集合。
ツール定義が許す範囲すべて。
詳細
それぞれの強みと向き不向き
書き下せないのは順序の部分
グラフは終了コードで分岐できますが、レビューが実際に何を言ったかでは分岐できません。コントローラワークフローはアクションを固定したまま、順序だけを委ねます。
- ステップはアクションのカタログになり、維持すべき depends がなくなります
- tasks に、実行が終わった時点で何が真であるべきかを宣言します
- コントローラがあるエージェントの指摘を次のエージェントのパラメータへ運びます
モデルが選ぶのは順序であって能力ではない
コントローラは宣言されたステップの中からしか選べません。ステップを発明することも、独自のシェルコマンドを書くことも、ファイルに書かれていないものへ手を伸ばすこともできないため、影響範囲はワークフロー定義そのものです。
- 各エージェントをホスト上で、あるいはマウントと外部通信を明示したコンテナサンドボックス内で実行する
- 役割ごとにプロバイダーとモデルを分ければ、同じモデルが自分の成果を採点することはありません
- 信頼できるようになった処理はサブワークフローへ移せば、判断の対象から外れます
本番運用の制御はフレームワークではなく実行から来る
コントローラの実行は DAG 実行です。スケジュール、キュー、リトライ、成果物、監査履歴がそのまま適用され、エージェントの消費を抑える上限もプロンプトの指示ではなくエンジンの設定です。
- ask_user は実行を永続的に中断します。プロセスは終了し、ワーカースロットが解放されます
- 数時間後に担当者が回答すると、新しいプロセスで実行が再開します
- ターン数、アクション試行、質問回数の上限に達すると、際限なく消費せずに実行が失敗します
後から実行を再構成できる
コントローラには依存辺がないため、実行はグラフではなく、実際に下された判断の並びとして表示されます。
- 判断のタイムライン: 1 ターン 1 行で、試行回数、所要時間、各アクションが生成した子実行へのリンクが並びます
- 各ゴールを完了、スキップ、失敗のどれとして決着させたか、その理由を示すタスク表示
- モデルが見たすべてのツール結果を含む完全なトランスクリプト
FAQ
Dagu を導入する前によくある質問
コントローラワークフローはエージェントループと何が違いますか？
素のループでは、終わったかどうかをモデルが決めます。コントローラはループのまま終了条件だけを取り戻します。タスクと「完了とは何か」を宣言し、open のタスクがなくなった時点で実行が終わります。
そのタスクが不要だと分かった場合はどうなりますか？
コントローラはスキップとして記録し、その理由を残します。実行は成功したままです。「やる必要がなかった」と「できなかった」は監査ログ上で別の結果なので、スキップと失敗を分けています。
ステップごとに別のモデルを使えますか？
使えます。各エージェントハーネスステップが自分のプロバイダーとモデルを指定し、コントローラ自身のモデルは別に設定します。安価なモデルで高価な専門エージェントを動かすことも、2 つのプロバイダーに相互チェックさせることもできます。
際限なく消費するのを止めるには？
上限はエンジン側で強制されます。1 回の実行でアクションは最大 5 回、質問は最大 5 回、ターン上限の既定値は 50 で、引き下げられます。上限に達すると実行は失敗し、未決着のまま残ったものを名指しします。
通常のグラフを使うべきなのはどんなときですか？
グラフが描けるならグラフを描いてください。type: graph は速く、安く、再現可能なので既定のままです。コントローラは、順序が本当に前段の結果に依存する場合にだけ使ってください。
次の一歩
まず 1 つのワークフローから。
Dagu をインストールし、不安定なスクリプトやエージェントタスクを 1 つ YAML に移して、実際の実行履歴を見て判断できます。