subagent parallel width cap - Liplus-Project/liplus-language GitHub Wiki
subagent 並列幅の上限は in-flight 5、値は暫定で強制機構を持たない
Question
親が同時に走らせる subagent の数に上限を置くか。置くなら何本で、何を数えるのか。
Current resolution
上限 = 同時 in-flight 5 本。 数える対象は「spawn 済みでまだ返っていない subagent」であって、1メッセージあたりの Agent ツール呼び出し数ではない。binding condition = 前の batch が全て報告を返すまで次の batch を投げない。
適用先は skills/task-subagent-delegation/SKILL.md を通る全ての並列委譲（親 issue またぎの worktree 並列 / 同一親 sub-issue 並列 / bounded read-only 調査の fan-out）。skills/evolution-parallel-agent-eval/SKILL.md の N / M / P fan-out は Design Dimensions 側で別途 bounded なため除外。
値 5 は暫定であり、強制機構は存在しない。 どちらも仕様本文に明記してある。
Edges
- depends on
parallel-subagent-eval-three-axis-decomposition— 値 5 の括り出しに eval の default 幅 N=3 を下端の基準として使っている。eval 側の N が動けば上限値の妥当性も再検討対象になる - depends on
dynamic-workflows-non-adoption— 上端の基準として host 側の fan-out スケール（research preview で同時 16 / 1 run 累計 1000、#1426 / #1428 で評価のうえ非採用）を参照している - conflicts with （現時点で対立 entry なし）
値 5 の導出
実測から導いていない。 cost / latency のどちらも測っていない。下端に eval の確立済み default 幅（N=3）、上端に host スケールの fan-out（同時 16）を置き、そのあいだの安全側として 5 を選んだだけの括り出しである。
したがって「5 が最適である」という主張は本判断に含まれない。含まれるのは「上限が無い状態よりは在る状態のほうがよい」という主張だけであり、観測が出た時点で値を改訂することを前提にしている。
背景 — 何を数えるかで一度外している
初版（#1532 / PR #1533）の上限は 1メッセージあたりの Agent ツール呼び出し数 として書かれていた。brake 1 の指摘で、この数え方では上限が上限として機能しないことが判明した。
5 本を投げたメッセージの直後に、1本目の wave が返る前へさらに 5 本を投げると、各メッセージは 5 以下に収まったまま実 in-flight 幅が 10 に達する。仕様の文言をすべて守った状態で上限の 2 倍が成立するため、これは運用ミスではなく仕様の穴だった。
同 PR の brake 1 ラウンド4で、上限の定義を in-flight bound へ移し、「前 wave の完了まで次 batch を投げない」を binding condition として明記する形に修正した。同じサイクルのラウンド3では、上限が並列委譲パターンの一つにしか掛からない書き方になっていた scope 不足も別途修正している。
受容した対価 — recall 依存であること
上限を強制する hook / counter / gate は存在しない。親が spawn の瞬間に binding condition を思い出して自己適用することに全面依存している。
これは rules/model/subtractive-structural-beauty.md の spec write 条項に正面から抵触する:
Procedures whose execution by future AI is not guaranteed must be replaced by structures that are reliably executed (hook / bootstrap / rule / physical constraint).
指摘元は #1533 の brake 1 で、N=3 の 3体全員が独立に同じ条項を引いて指摘した。同型の欠陥は rules/model/trigger-check-gate.md が自己記述済みであり（「a forgettable relief path is strictly dominated by the deterministic hook」）、5軸ゲートのほうは #1493 で hook 化されて解決している。
暫定対応として、recall 依存であることを仕様本文に honesty clause として明記し、構造的強制への置き換えを #1534 で追跡する形にした。rules/operations/operations.md の Post-L1-Merge Runtime Observation が #1413 に対して取っているのと同じ扱い。
#1534 が抱えている検討軸は3つ:
- PreToolUse hook で Agent ツール呼び出しをカウントする経路が harness 上で成立するか（現行
adapter/claude/hooks/は on-session-start / on-user-prompt / post-tool-use のみ） - in-flight 数の観測が hook から可能か。困難なら per-message batch size の強制に落とし、上限の主張自体を機構の側へ合わせる
- 値 5 の妥当性そのもの
再評価条件
- 実 in-flight 幅の超過が観測されたとき（recall 依存の穴が実害として出た初回）
- cost / latency の実測が取れたとき。値 5 は測定に置き換えられる前提の暫定値である
- #1534 の検討軸1 / 2 が harness 上で成立すると判明したとき。その時点で honesty clause は構造へ置き換わり、本エントリの「受容した対価」節は解消される
検出サイン（この判断が後で疑問視される場合）
- 「1メッセージ 5 本以内なので上限を守っている」と述べられた時 → 数える対象は in-flight であって per-message ではない。前 wave が返っているかを先に確認する
- eval の N / M / P fan-out を上限違反として止めようとした時 → 除外対象。Design Dimensions 側で別途 bounded になっている
- 上限を spawn 深度（subagent が自分の子を spawn する軸）の話と混ぜて読んだ時 → 別軸。深度は
skills/task-subagent-prompt/SKILL.mdBounded delegation - 「5 という値の根拠は何か」と問われた時 → 実測ではない。N=3 と host スケール 16 のあいだの安全側という括り出しであり、観測が出れば改訂する前提であることを先に述べる