parallel agent eval distilled to token guide - Liplus-Project/liplus-language GitHub Wiki

parallel-agent-eval の本体は蒸留で約 5,340 トークンまで縮み、推奨超過の残りは受け入れた

Question

skills/evolution-parallel-agent-eval/SKILL.md の本体を、Agent Skills 標準の推奨（本体 5,000 トークン未満）に収めるには、振る舞いを変えない蒸留だけで足りるか。足りないなら、残りをどう扱うか。

Current resolution

蒸留だけで −55% まで縮んだ。ただし推奨には約 7% 届かず、その差は受け入れる tradeoff として閉じた。（#1601 / PR #2098。受け入れは 2026-09-26、Master の go による）

前 後
本体（frontmatter を除く） 46,205 B 21,012 B
旧トークナイザ（claude-haiku-4-5 で実測） 約 11,170 約 5,340
新トークナイザ（claude-sonnet-5 で実測） 約 15,500 約 7,400

トークン数は claude -p --output-format json の入力トークン差分から取った。issue の見積もり（10.9 KB ≈ 2,700 トークン）は旧トークナイザの比率と一致したので、判定には旧トークナイザの数字を使った。新トークナイザは同じ文を約 1.4 倍のトークンに数える。そのため、どちらのトークナイザで測った「5,000」なのかを書かないまま閾値を比べても意味がない。

分割では残りの差は埋まらない。#1601 のコメント（2026-09-25）で決めた退避策は「蒸留で届かなければ brake 1 とそれ以外の評価に分ける」だった。しかし brake 1 以外の経路でしか使われない文は約 700 B（約 180 トークン）しかない。分けると skill が 1 本増え、listing に載る description も 1 本増える。差を埋めずに自由度だけが増えるので、分割は採らなかった。

Edges

Background

#1601 の項目 2。PR #1600 の分割の後も、この skill だけが推奨を超えていた。2026-09-25、Master の方針は「蒸留して縮められるなら蒸留、無理そうなら分けてもいい」だった。

3 周目で剥いだもの

2 周目の残余の節は「Procedure はステップ番号を固定しているので、文単位でしか縮められない」と見立てていた。3 周目ではステップ番号 1〜9 を固定したまま、Procedure を約 17 KB から約 7 KB まで縮めた。**番号の固定は縮める量の上限ではなかった。**縮んだ分の主体は、節をまたいだ重複だった。

  • Procedure と Constraint が同じ規則を二度書いていた。対象は、所見の投稿先、却下の最終性、裁定の主体、実測の範囲だけを渡すこと。Constraint のラベルは外部から参照されるので残した。Procedure 側は参照に置き換えた。
  • spawn の種類の分け方（judge 型 / probe 型、Claude / Codex）が三重に書かれていた。場所は Implementation Note、step 3、Constraint: Effort floor。Effort floor へ集め、Implementation Note の節は消した（外部参照が無いことは grep で確認した）。Claude の probe 型が親セッションの effort を上げる文だけは step 3 に残した。skills/task-subagent-spawn/SKILL.md がそこを「Procedure step 3」として指しているためである。
  • Codex の effort 値の対応と、model_reasoning_effort を toml に書かない禁止は、skills/task-subagent-spawn/SKILL.md が既に持っている。本文からは落とした。
  • Trigger の箇条書きは frontmatter の description と同じ内容だった。本文には brake 1 の必須条件だけを残した。
  • window mark の引数の説明は、scripts/window_marker.py の必須引数と重なっていた。open は必須引数が無ければ動かないので、本文には順序と、拒否されたときの振る舞いだけを残した。

逐語 literal（引用ブロック 15 行）は、前後でバイト単位で同一である。

本 entry が保持する理由（本文からは剥いだもの）

既存の entry と、他の skill の本文に無いものだけをここに置く。

  • N / M / P がそれぞれ何を買うか。 subagent_count (N) は確率的なばらつきへの頑健性、axes_per_subagent (M) は盲点の被覆、premise_variations (P) は前提の違いへの頑健性を買う。本文には定義と、どういうときにどの型を使うかだけを残した。（brake 1 の round 1 で、軸 B と削除行の確認の両方がこれを指摘した）

  • Boundary 節にあった関係の説明。

    • skills/evolution-loop は observe / evaluate の段でこの方法を呼ぶ。方法の本体はこちらにある。
    • skills/evolution-l1-update-gating は L1 変更を認可する軸で、この実証の軸とは直交する。L1 のゲートは issue 形成時の観測閾値であって、二本目の brake ではない。
    • rules/evolution/promotion-judgment.md は観測の積み上げであり、この方法は実装直前の仕様検証である。両者は直交する。
    • この方法の spawn は委譲の特殊形である（目的は評価データを集めることで、実装を任せることではない）。

    振る舞いとして残ったのは、並列幅の上限の免除一文だけで、これは Design Dimensions に移した。

  • Claude の probe 型で親の effort を上げる手順を強制するものは無い。 Claude Code には spawn ごとに effort を渡す引数が無いためである。本文には手順だけを残した。

  • **Axis statement form の各部品が「句」である理由。**この形式が固定するのは、軸が何を名指すかであって、どれだけ書くかではない。

  • **no-write を prompt literal に頼る受容の追跡。**再発を merge 後に追えるのは、Self-Evolution Observation Format の entry を持つ PR だけである。entry が無い PR では、merge 後に何も追わない。

  • **step 4 / step 9 の記録の所在。**所見は評価者のコメントに、裁定は著者のコメントに、どちらも PR のスレッドに既にある。eval の記録はスレッドとセルフレビューの上にある。本文には「転記しない」という振る舞いだけを残した。

Constraints

  • 外部から参照される節名、Procedure のステップ番号、Constraint のラベル、小見出しは変えない。
  • tests/ が本文に要求する literal はすべて残す。
  • 逐語 literal はバイト単位で同一にする。

Conclusion

採った案は、蒸留したうえで約 5,340 トークンでの超過を受け入れる案。退けた案は二つ。

  • 分割：差を埋めず、skill が 1 本増える。
  • 本文の振る舞いまで削って 5,000 に届かせる：蒸留の前提（振る舞いを変えない）を破る。

Related

  • issue #1601、PR #2098
  • rules/model/liplus-coding-rule.md Body States Behavior