ハーネスエンジニアリングのプラクティス P4. サブエージェントは「蒸留器」として契約する 🎯 ポイント サブエージェントが50ファイルの生ログを親に返したら、親のコンテキストは即死します。返すべきは「議事録」ではなく「結論」です。 📝 概要 探索用サブエージェントの契約を「結論を返す、議事録は返さない」と定義します。50ファイル探索して5行の所見を返す。これは礼儀ではなく、文脈階層のメモリ管理規律です。 🔍 解説 サブエージェントを使う主な目的は、親エージェントのコンテキストウィンドウを守ることです。しかし、サブエージェントが生の探索結果をそのまま返してしまうと、その目的は完全に失われます。サブエージェントは「蒸留器」として機能すべきです。大量の情報を読み込み、本質だけを凝縮して返す。この契約を明示的にプロンプトで定義し、返答のフォーマットも制約することで、文脈階層全体の効率が保たれます。安価なモデルで広く探索し、高価なモデルで深く判断する、というトークン経済の原則とも合致します。 🛠 実践方法 ・サブエージェントのプロンプトに「結論を返す、議事録は返さない」と明記し、返答フォーマット（行数上限・構造）を制約します ・探索タスクには安価なモデルを使い、親エージェントの判断には高価なモデルを使うトークン経済を設計します ・サブエージェントの返答サイズを監視し、閾値を超えた場合は再蒸留を要求するガードを設けます ・蒸留の粒度をタスクに応じて調整します（分類タスクなら3行、分析タスクなら10行など） 💼 ユースケース ・大規模コードベースの調査で、複数のサブエージェントにファイル群を分担探索させ、各々が要約のみ返す場面 ・マイグレーションで、各ユニットの状況を調査するサブエージェントが「移行可／要手動対応／不明」の3分類だけを返す場面 ・インシデント対応で、ログ・メトリクス・トレースを別々のサブエージェントが調査し、相関する異常の要約だけを返す場面 ⚠ 落とし穴 サブエージェントの蒸留品質が低いと、重要な情報が失われるリスクがあります。「結論だけ返せ」と指示しても、何が結論に値するかの判断はモデルの能力に依存します。また、蒸留の過程で文脈が失われすぎると、親エージェントが誤った判断をする可能性もあります。蒸留の粒度は、タスクの性質に応じて調整が必要です。 #HarnessEngineering# #AIAgent#