サブ Agent は一時的なもので、独自の識別子、記憶、チャネルを持たず、Agent 一覧にも表示されません。
2 つの効果
- コンテキストの分離:途中の作業がメインの会話のコンテキストを消費しないため、トークンを節約でき、モデルの注意も必要な内容に集中します
- 並列実行:複数のサブ Agent を同時に動かせるため、全体の所要時間は最も遅い 1 つ分で済みます
引き継ぐもの・引き継がないもの
サブ Agent はメイン Agent の環境の一部を引き継ぎますが、コピーではありません:
そのため、サブ Agent はメイン Agent から渡された内容しか知りません。会話履歴を見ることも、ユーザーに質問することもできないので、必要なパス、識別子、制約、すでに決まっている前提は、タスクを作成する時点ですべて書き込む必要があります。
実行されるタイミング
メイン Agent が自分で判断します。設定も専用のコマンドも必要ありません。 サブ Agent が作成される場合:- 互いに依存しない複数の作業を同時に進められるとき(例:「A と B の 2 つの製品をそれぞれ調べて」)
- 途中の出力は大量だが、必要なのは結論だけのとき(例:「このエラーに既知の解決策があるかコミュニティで調べて」)
- 途中の結果がないとメイン Agent が先に進めないとき(ファイルを数個読む、数回検索する程度は通常の作業です)
- タスクが会話の前の内容に依存する、または途中でユーザーへの確認が必要なとき
- この会話を超えて継続的に実行するタスク。これには定時タスクを使います
実行中の表示
サブ Agent は Web コンソールとデスクトップアプリでそれぞれ 1 枚のカードとして表示されます。展開すると、呼び出し中のツールとそこまでの手順を確認でき、完了後はカードの中にレポートが入ります。サブ Agent は個別に開始・終了するため、どれがまだ実行中かがそのまま分かります。組み込みのタイプ
作成時にタイプを 1 つ選びます。タイプによってシステムプロンプトと使えるツールの範囲が決まります:独自のタイプ
ワークスペースのsubagents/ ディレクトリに .md ファイルを置くと、タイプを追加できます。書式はスキルと同じです:
tools を絞るのが最も確実な制約です。read, ls, search_files だけのタイプは、何も変更できません。
初回起動時に subagents/ の下に README.md と example.md.template が作成されます。後者を .md にコピーすれば有効になります。テンプレートは毎ターン読み直されるため、追加したファイルは次のメッセージから有効になり、再起動は不要です。
使用できないツール
次のツールは、すべてのサブ Agent で使用できません:関連設定
サブ Agent はデフォルトで有効です。Web コンソールとデスクトップアプリの「設定 → Agent 設定」で切り替えられ、次のターンから反映されるため再起動は不要です。細かい制限はconfig.json で調整します:
設計
- コンテキストの分離:サブ Agent はメッセージ履歴が空の状態で起動し、ペルソナファイルを読み込まず、メモリマネージャーにも接続しません。メインの会話には呼び出しと最終的な結論だけが残ります。
- 並列実行:1 回の呼び出しに含まれる複数のタスクはそれぞれのスレッドで実行され、制限時間を共有します。同じターンで発行された複数の呼び出しも同時に開始します。
- ステップ数は半分:サブ Agent の最大ステップ数はメイン Agent の半分です。タスクの範囲がすでに定まっているため、会話全体と同じ予算は必要ありません。上限に達した場合は、完了した範囲をまとめるよう求めます。
- タイムアウトの追跡:タイムアウトしたタスクは中止され、その旨が記録されます。結果の数は常にタスク数と一致するため、メイン Agent は「見つからなかった」と「最後まで実行できなかった」を区別できます。
- 表示とコンテキストの分離:モデルには構造化データを返し、ユーザーには整形したレポートを表示します。どちらも同じ結果から生成されますが、表示用の内容がモデルのコンテキストに入ることはありません。
