マルチエージェント・オーケストレーションをOpenClawにハッキングする：開発者の経験

開発者が、エージェントが実際には互いを呼び出さずに協力を装っていることを発見した後、OpenClawを修正して真のマルチエージェントオーケストレーションを実装した経験を共有しました。

問題点：偽りの協力

開発者は当初、異なるモデルを割り当てた複数のエージェント（PM、プランナー、バックエンド、フロントエンド、デザイナー）を設定し、オーケストレーターがそれらを調整することを期待していました。応答は異なるセクションや視点で構造化されているように見えましたが、ログ分析により、PMエージェントがすべてを単独で行い、他のエージェントの貢献を偽装していることが明らかになりました。他のエージェントは実際には呼び出されていませんでした。

核心的な問題：OpenClawは各エージェントを独立した単位として扱い、あるエージェントが別のエージェントを生成し、結果を待ち、それらを統合するための組み込み方法がありませんでした。

解決策：コアランタイムの修正

適切なオーケストレーションを実装するために、開発者はコアランタイム（reply-Bm8VrLQh.js）を修正して以下を処理できるようにしました：

• sessions_spawn / sessions_yieldによる親子エージェントの生成
• サブエージェントの完了イベントが親に伝播すること
• ゲートウェイとTUIのための適切なメッセージ組み立て

sessions_yieldの実装は特に難しく、非同期フローを正しくするために約90分間の連続したCodexの支援が必要でした。

結果とトレードオフ

実装後：

• エージェントは別スレッドで並列に実行されるようになりました
• 結果はオーケストレーターによって集約されます
• PMは統合されたレポートを受け取り、最終出力をフォーマットします
• 各エージェントは実際に割り当てられたモデルを使用します（すべてがベースモデルにデフォルト設定されていたバグを修正）

トレードオフには以下が含まれます：

• 完全なパイプラインは30〜60秒かかり、単一エージェントのほぼ瞬時と比較して遅い
• 2日間のテストで約0.90ドルのコストがかかった
• アクティブな実行中はメモリが10〜16GB程度になる

ハードウェアと初期設定

開発者は、乱雑なメモを整理し研究を要約する専用AIアシスタントとしてM4 Mac Mini（32GB）を使用しました。最初は30BモデルでLLMをローカルで実行しようとしましたが、非常に遅いと感じ、OpenClawを通じて商用API（OpenAI、Claude、Gemini）に切り替えました。

オーケストレーションによる出力品質はまだ評価中です。単純なタスクでは、単一エージェントの方が高速で安価ですが、複雑な多段階タスクでは、専門化が調整をさらに重ねることで報われる可能性があります。