OpenClawにおけるマルチエージェントオーケストレーション:ルールを集中管理し、サブエージェントを生成する

あるOpenClawユーザーが、エージェントごとに孤立したワークスペースから集中型のオーケストレーションパターンへの進化を共有しています。当初、システム管理者、ファミリーエージェント、コーポレートアシスタント、スポーツリーグ管理など、ユースケースごとにそれぞれ独自のworkspace-*を持つ個別のエージェントを作成していました。スキル(例:スポーツエージェント用のチームロースタースキル)を開発する際には、そのエージェントと直接チャットしていました。
問題点:横断的なルール(例:「ポイントスコアや支出台帳などの構造化データは常に.JSONファイルに保存する」)が生まれたとき、その指示をすべてのエージェントのワークスペースに手動でコピーする必要がありました。解決策は、単一の「メインエージェント」をオーケストレーターとして昇格させることでした。現在、メインエージェントはすべてのアーキテクチャルール(.JSON規則など)を保持し、サブエージェントをオンデマンドで生成してツールを構築します。例えば、コーポレートエージェント用の支出トラッカーを構築するには、ユーザーがメインエージェントに要件を説明し、メインエージェントがサブエージェントのワークスペースで構築されたスキルが中心ルールに従うことを保証します。これで重複はなくなりました。
ユーザーは、このパターンは今では「明白に見える」と認めていますが、当初は推奨される「メインエージェントがサブエージェントをオーケストレーションする」パターンがエージェント間の構築シナリオに適用されるかどうか確信が持てなかったと述べています。
📖 全文はこちら: r/openclaw
👀 See Also

検証ハーネスの修正により、Claudeの計画実行問題が解決されました
開発者は、ファイルの存在、API応答、設定変更などの成果物を検証することで、Claudeが自身の計画の各ステップを実際に実行しているかどうかをチェックする、30〜50行のbashまたはPython検証レイヤーを構築しました。

高品質な応答をアンカーとして活用し、Claudeの長いスレッドでの出力のずれを防ぐ
A user describes how Claude responses degrade after 30-40 messages, and how they anchor the best mid-thread output to start fresh conversations.

Codexで構築、OpenClawで実行:実用的な分割が機能する
ある開発者が、OpenClawのフラストレーションを突破した方法を共有。自動化ロジックはCodexで構築し、OpenClawは純粋に実行レイヤーとして使用。さらに、Apple MessagesをCarPlay経由で使うことで、まるでJarvisのようなアシスタントに近づいたと語る。

マルチモデルルーティングにより、OpenClaw APIのコストが50%削減されます。
ある開発者が、異なるタスクを異なるモデルにルーティングすることでOpenClaw APIコストを50%削減しました:複雑な推論にはClaude、ファイル操作やテスト生成にはDeepSeek、中程度のタスクにはGeminiまたはGPTを使用しています。