複数のAIエージェントを使うとき、「誰が作業するか」だけを決めても、最後の返答が二重になることがあります。専門エージェントが完成品を返した後、司令役が同じ内容を言い換えてもう一度返すケースです。委任時点で 結果を誰が受け取り、誰の返答をユーザーに見せるか まで決めると、この混乱を減らせます。
この記事では、Orkas の公開実装にある3つの委任ツールを、設計例として読み解きます。本記事は Orkas の紹介活動の一環です。AI を下書きに使い、技術的な記述は公開コードで確認しました。以下はコードの分析であり、処理速度や実運用での効果を計測した報告ではありません。
1. 委任先と、返答の行き先を別に考える
Orkas の Commander は、専門エージェントへの委任に次の3つの経路を使います。
| 経路 | 専門エージェントの返答 | Commander の次の動き |
|---|---|---|
hand_off_to |
ユーザーに見える | そのターンを終了する |
dispatch_to |
ユーザーに見え、結果も Commander に返る | 別の処理や複数結果の統合を続ける |
run_worker |
ユーザーには見えない | 私的な中間結果を受け取って続ける |
たとえば「資料を1本作る」という依頼で、残りの作業を資料担当エージェントに渡すなら hand_off_to が合います。逆に「調査結果を得て、次に表を作る」なら、調査担当の結果を Commander が使う必要があるため dispatch_to です。見出し候補を一時的に比較するような独立した下調べは、ユーザーに別の回答を出さない run_worker が合います。
この区別はモデルへの指示だけではなく、ツールの戻り方にも表れています。公開コードでは hand_off_to が endTurn: true を返して Commander のターンを終わらせ、dispatch_to は対象エージェントの完了結果をツール結果として返します。run_worker は匿名ワーカーの結果だけを Commander に返し、表示用のエージェント発言を作りません。
2. 「続ける作業」を具体的に書けないなら、引き渡す
dispatch_to の説明には、Commander が結果を受け取った後に行う具体的な次の作業が必要だと明記されています。別の委任、ツール呼び出し、または異なる複数結果の統合などです。専門エージェントの完成した回答を整形・言い換え・承認するだけなら hand_off_to を使います。
これは小さなルールですが、委任後の「司令役による再要約」を抑える設計です。次のように、委任する前に一行で確認できます。
専門エージェントの結果を受け取った後、私は＿＿＿＿を実行する。
空欄が「その結果をユーザーに伝える」だけなら、司令役が結果をもう一度受け取る必要はありません。一方、「調査で得た数値を表に入力する」「2人のレビューの差分を照合する」と書けるなら、司令役が継続する理由があります。
3. 並列化の対象も経路ごとに変わる
公開実装では dispatch_to と run_worker が並列実行可能なツールとして定義されています。ただし、同時に走れる数は内部の枠で制限されます。hand_off_to はターンの最後の動作なので、ほかの委任と並行実行する経路ではありません。
ここで重要なのは「並列なら速い」という単純な話ではなく、依存関係です。2つの独立した調査なら並列にできます。2つ目の仕事に1つ目の結果が必要なら直列です。最後の成果物を専門エージェントがそのまま届けるなら、そこで引き渡します。
実装から持ち帰れること
マルチエージェントの委任 API を設計するときは、少なくとも次の3点を分けると判断しやすくなります。
- 成果物をユーザーに直接見せるか。
- 司令役が結果を受け取って、具体的に何を続けるか。
- その仕事はほかの仕事と独立しているか。
この3点が決まると、委任ツールの名前だけでなく、戻り値、UI上の表示、ターンの終了条件まで一貫させられます。
参照: Orkas の設計説明 / 委任ツールの実装