AI開発チームを構築し、自分自身で作業をレビューさせた — マルチエージェントループから学んだこと

ほとんどのマルチエージェントのデモは5分間は印象的だが、5時間持たない。数ヶ月かけてTask Hounds — オープンソースのローカルマルチエージェント開発ワークスペース — を構築した経験から、本当に重要だった設計判断を紹介します。

セットアップ

Task Houndsは1つのプロジェクトに対して3つのエージェントをループで動作させます。

• マネージャー：コンテキストを理解し、計画を維持し、1サイクルにつき1つの具体的なタスクを割り当てる
• ワーカー：タスクを実装し、変更したファイル、テスト結果、既知の問題を含む構造化されたレポートを提出する
• レビュアー：バグ、UXの問題、リスクを検査し、マネージャーが次に何をするかを決める前に結果を確認する

人間がDirective（指示）（ミッション）を作成し、実行中に思考や新しいタスクを挿入できます。計画、ToDo、レポート、フィードバック、ライブエージェントストリームなどすべてがローカルのSQLiteに保存され、リアルタイムダッシュボードで表示されます。

教訓1：一度に1タスクの方が並列処理より優れている

最初は並列ワーカーを試みました。デモとしては素晴らしかったですが、何も出荷できませんでした。エージェント同士が互いのファイルを上書きし、マネージャーが失敗の原因を特定できなかったのです。一度に1タスクにシリアル化すると遅く見えますが、実際にははるかに多くの作業を完了できます。

教訓2：人間に書き込み保護されたアンカーを与える

目標の逸脱は長いループの静かな殺し屋です。約10ループ目で、計画が微妙に要求した内容と一致しなくなります。私たちの解決策：Human Directiveはすべてのセッションにコピーされ、ループはそれを編集することが禁止されています。ミッションを変更できるのは人間だけです。逸脱は固定アンカーとの可視的な乖離として現れるようになり、静かな変異ではなくなりました。

教訓3：構造化された引き継ぎ、チャット履歴ではない

エージェント間で会話履歴を渡すと2つの問題が発生します。コンテキストウィンドウを圧迫し、下流エージェントが上流の推論ノイズに依存してしまうのです。Task Houndsの各ホップは固定ドキュメントです。マネージャーのメモリは明示的なJSON引き継ぎで、各ループで1回読み取られます。ワーカーの出力は固定レポートスキーマです。機械可読のToDo JSONが無効な場合、作業がリリースされる前にループが修復します。

教訓4：レビュアーは権限を持つべきではない

当初、レビュアーは修正を直接割り当てることができました。結果：2つのエージェントが永遠に交渉し続ける、無限のレビュースパイラルが発生しました。今はレビュアーは構造化されたフィードバックをマネージャーに提出するだけで、マネージャーが「修正」「継続」「停止」を決定します。判断と決定を分離することで、ループ全体が安定しました。

教訓5：信頼はUIの問題で、モデル問題ではない

システムに与える自律性の度合いを最も大きく変えたのは、より優れたモデルではありませんでした。むしろ観察できることでした。すべての決定がSQLiteの行とダッシュボードのパネルとして表示されることで、「1時間実行させても大丈夫か？」は信仰の問題ではなく、証拠の問題になりました。

まだ難しいこと

• LLMとのテキスト契約は依然として脆弱。構造化出力/ツール呼び出しが修復レイヤーの一部を置き換えるでしょう
• コスト：3つの役割はワンショットプロンプトより多くのトークンを使用します。計画→実装→レビューの方が混乱した単一エージェントを再プロンプトするより無駄が少ないという賭けですが、これは長いタスクでは正しいものの、小さな編集では正しくありません
• クロスプラットフォームの洗練（管理ランタイムは現在Windows優先、Dockerはどこでも動作）

試してみる

Task HoundsはMITライセンスです：https://github.com/catowabisabi/task-hounds
3分のデモ：https://www.youtube.com/watch?v=pu-Rt8Ye4EQ

エージェントループを構築したことがある方 — あなたのループは計画、実行、レビューのどこで失敗しますか？コメントで意見を交換できれば嬉しいです。