TL;DR
Level Rule (правило уровня) — способ решить, какие скилы (файлы с инструкциями для агента) пора убрать, потому что модель их уже «впитала». Скилл прячут от модели и дают ей задачу, собранную из этого скилла. Если модель сама проходит задачу на высокий балл, скилл можно списать. Одно условие: задача должна быть честной, то есть другая модель с этим скиллом справляется заметно лучше, чем без него.
Привычное правило такое: «Прогнал с ним и без него. Разницы нет — значит, скилл не нужен». Нулевая разница получается в двух разных случаях. Первый: модель и так всё умеет, скилл лишний. Второй: модель проваливает задачу в обоих прогонах, а скилл ей не помогает, потому что написан плохо или не про то. В обоих случаях «разница ≈ 0», и правило по разнице удаляет оба скилла. Во втором случае вы стираете скилл, который нужно чинить, и записываете в «освоенное» то, чего модель не умеет.
Метод проще: смотреть на уровень без скилла, а не на разницу. Ниже 0,4 без скилла — модель не умеет, скилл не трогаем. Выше 0,8 без скилла, и задача подтверждена другой моделью — скилл можно убирать. Для разных моделей вердикт будет разным, поэтому проверять нужно под ту модель, на которой вы работаете.
Схема метода
ШАГ 1: Берём скилл → просим другую модель (из другой «семьи») придумать
задачу: цель названа, содержимое скилла в условии НЕ раскрыто
ШАГ 2: Из скилла выписываем «пункты умения» (то, что нельзя угадать)
и отбрасываем «общие пункты» (файл создан, код запускается)
ШАГ 3: Сложность: целевая модель решает БЕЗ скилла.
Прошла больше половины пунктов — задача слишком лёгкая, генерируем заново
ШАГ 4: Целевая модель решает задачу БЕЗ скилла 3 раза → средний балл U
ШАГ 5: Проверка честности: другая (лучше — более слабая) модель решает
задачу С скиллом и БЕЗ него. Выигрыш ≥ 0,1 → задача настоящая
ШАГ 6: Решение:
U ≥ 0,8 + задача подтверждена → убрать для этой модели
U < 0,4 → не убирать и не полагаться на него: чинить
между ними → оставить, проверить второй задачей
Шаги выполняются в отдельных чатах или запусках: генератор задач, целевая модель, проверяющая модель.
Пример применения
Задача: Вы руководитель аналитики в магазине на Wildberries. У вашего агента в Claude Code есть три скила: - «Юнит-экономика карточки»: комиссия по категории, логистика, возвраты, хранение; - «Как писать отчёты по SQL в нашем ClickHouse»; - «Тон ответов на отзывы покупателей».
Версия модели обновилась, и вы хотите понять, какие скилы можно убрать, чтобы не раздувать контекст. Коллега предлагает: «Прогони с ними и без них, если оценки равны — удаляем».
Промпт (для модели-генератора, в новом чате, лучше другой модели, не той, на которой работает агент):
Вот содержимое скилла «Юнит-экономика карточки Wildberries»:
[вставить текст скилла]
Составь одну проверочную задачу, которую агент мог бы выполнить без этого скилла.
Правила:
1. В задаче назови ЦЕЛЬ (например: «посчитай маржинальность карточки при таких вводных»), но НЕ раскрывай формулы, ставки и конвенции, которые даёт скилл.
2. Выпиши рубрику из 6–8 пунктов проверки.
3. Каждый пункт пометь: [УМЕНИЕ] — нужна информация, которую компетентный специалист не угадает без скилла; [ОБЩИЙ] — любой толковый ответ его выполнит.
4. Верни задачу и рубрику отдельными блоками.
Дальше: запустите задачу 3 раза на рабочей модели без скилла и оцените только пункты [УМЕНИЕ]. Затем запустите её на другой модели с и без скилла.
Результат: Модель-генератор вернёт задачу и размеченную рубрику. После запусков у вас будет три картины. Скилл, который агент проходит без подсказки на высокий балл, а другая модель с ним выигрывает, можно списать. Скилл, где обе версии провалились, надо чинить или переписывать. Скилл, где с ним ответы лучше, оставляем. Скил про тон ответов, скорее всего, окажется в зоне «оставить» или «проверить второй задачей», потому что критерии там размытые (это моё предположение, в статье такого скилла нет).
Почему это работает
Слабость в лоб. Нулевая разница между «с» и «без» — это одинаковые баллы, а не одинаковая причина. Модель может одинаково хорошо проходить задачу или одинаково плохо. В статье из скилов, которые правило «разница рядом с нулём» отправляло на удаление, значительная часть оказывалась из второй категории. Скилл тихо удаляют, хотя его надо было чинить.
Что модель делает хорошо. Когда скилл спрятан, а задача описывает цель без содержимого, прогон показывает реальный уровень модели. Он не зависит от того, чем скилл помогал. Уровень стабильнее повторяется на разных задачах, чем разница: согласованность вердиктов между двумя задачами — 0,42 против 0,23.
Как метод обходит слабость. Высокий балл без скилла бывает по двум причинам: модель умеет, или задача лёгкая и скилл ей не нужен. Одна модель их не разделит. Поэтому второй модели дают ту же задачу с скиллом и без него: если она заметно выигрывает, задача действительно требует знаний из скилла. Почти половина «высоких баллов» в исследовании оказалась на задачах, где скилл никому не помогал.
Рычаги: - Порог удаления (0,8). Поднимите для критичных скилов, снизьте для мелких. - Число прогонов (3). Больше прогонов почти не снижает шум. Выгоднее добавить вторую задачу, чем делать больше прогонов. - Модель-свидетель. Берите более слабую модель: она показывает пользу скилла там, где сильная уже обходится без него. - Другая семья моделей для генерации задач: она не придумывает задачи под знания, которые есть у целевой модели.
Шаблон промпта
Ты составитель проверочных задач для скилов агента.
{текст_скилла}
{модель_на_которой_работает_агент}
1. Составь ОДНУ исполняемую задачу по этому скиллу.
- Назови цель и, если нужно, инструмент или предметную область.
- НЕ раскрывай ответ и конвенции, которые даёт скилл.
2. Составь рубрику из {число_пунктов} пунктов.
3. Разметь каждый пункт:
[УМЕНИЕ] — нужна информация из скилла, которую компетентный специалист
не угадает без него;
[ОБЩИЙ] — любой толковый ответ выполнит (файл создан, код запускается).
4. Проверь свою задачу: можно ли её выполнить так, как она написана?
Если нет — перепиши.
Шаг A: Запусти задачу {число_прогонов} раза на {целевая_модель} БЕЗ скилла.
Оцени только пункты [УМЕНИЕ] → U (доля выполненных).
Если по всей рубрике выполнено больше половины — задача слишком лёгкая:
перегенерируй.
Шаг B: Запусти задачу на {модель_свидетель} С скиллом и БЕЗ него.
Выигрыш с скиллом ≥ {порог_выигрыша}? Да → задача честная.
Шаг C:
U ≥ {порог_удаления} и задача честная → убрать скилл для этой модели.
U < {нижний_порог} → не убирать и не полагаться: починить скилл.
Иначе → оставить, проверить второй задачей.
Что подставлять: {число_пунктов} — 6–8. {число_прогонов} — 3. {порог_выигрыша} — 0,1 (как в статье). {порог_удаления} — 0,8. {нижний_порог} — 0,4. {модель_свидетель} — другая модель, желательно слабее рабочей.
🚀 Быстрый старт — вставь в чат:
Вот шаблон проверки скилла на «впитанность». Адаптируй под мою задачу:
у меня есть скилл для агента, хочу понять, можно ли его убрать.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какая у вас целевая модель, какая другая модель доступна как «свидетель», какой скилл проверяете и сколько прогонов вы готовы сделать. Эти данные нужны, потому что метод строится на сравнении двух моделей: той, чей уровень проверяем, и той, которая подтверждает, что задача вообще требует скилла. Остальную структуру модель возьмёт из шаблона.
Ограничения
⚠️ Вердикт привязан к модели: Тот же скилл для одной модели можно убрать, для другой нет. Сменили модель — проверяйте заново.
⚠️ Одной задачи мало: Повторяемость между разными задачами для одного скилла невысокая. Шум идёт от выбора задачи, а не от числа прогонов. Для важного скилла нужна вторая задача.
⚠️ Проверяли только открытые модели: Обе стороны эксперимента — модели семейств Qwen и DeepSeek. Судья тоже из Qwen. Как это поведёт себя на Claude, GPT или Gemini, из статьи не видно.
⚠️ Метод не про качество скилла: Он отвечает на вопрос «можно ли убрать», а не «хороший ли скилл». Для сравнения скилов между собой разница «с ним и без него» как раз подходит.
⚠️ Задачи синтетические: Их придумывает модель, а не живой пользователь. Скилл, где нужны данные конкретной компании (название файла, внутренние правила), «впитать» нельзя: проверять там нечего.
⚠️ Масштаб: В исследовании всё автоматизировано на тысячах скилов. Руками это реально для нескольких скилов, а для больших библиотек понадобится скрипт.
Как исследовали
Команда взяла 1 251 публичный скилл для агентов. Для каждого другая модель синтезировала задачу с рубрикой. Условия: цель названа, но то, чему учит скилл, не раскрыто. Затем четыре открытые модели прогнали задачи без скилла (по три раза) и с ним. Работу оценивала одна модель-судья по рубрике. Рубрику разделили на «пункты умения» и «общие пункты», потому что общие (файл создан) проходит любой.
Скилы, где модель набрала мало и без скилла, и с ним (uncovered, «не покрыто»), составили заметную долю. Правило «разница рядом с нулём» отправило на удаление более половины таких скилов у каждой из четырёх моделей. Правило уровня не могло удалить ни одного: по построению оно смотрит только на балл без скилла. Чтобы исключить подгонку (состояние скилла и вердикт считались по одним и тем же данным), вердикт читали по одной задаче, а состояние по другой. Правило по разнице всё равно удаляло 45% «не покрытых» скилов, правило уровня — 14%.
На независимом бенчмарке SkillsBench почти все удаления по разнице опирались на задачи, которые не проходил целиком ни один прогон. При этом удаление по правилу уровня не стоило заметной потери в наградах. Результат, который удивил: почти половина высоких баллов без скилла получалась на задачах, где скилл вообще никому не помогал. Этого не видно, если проверять одной моделью.
Практический вывод по надёжности: шум в основном идёт от того, какая задача выбрана (повторяемость между задачами 0,41), а не от числа прогонов (0,90) и не от длины рубрики (0,91). Инвестировать лучше в разные задачи, а не в больше прогонов.
Адаптации и экстраполяции
🔧 Техника: заменить «скилл» на «правило из CLAUDE.md» → проверить, нужны ли ваши инструкции
Не всякий скилл стоит проверять, но те же шаги можно применить к отдельным правилам в файле инструкций агента. Возьмите правило («всегда проверяй тесты перед коммитом по нашему регламенту»), удалите его и дайте агенту задачу про эту ситуацию. Если без правила агент на высоком уровне делает то же самое — правило избыточно. Если на низком — правило не работает или модель не умеет, и надо переписывать. В статье это не проверялось: скилы в ней целые, а не отдельные правила.
🔧 Техника: слабая модель-свидетель → шире порог «честной задачи»
В статье отмечено, что слабая модель удерживает проверку полезной по мере роста моделей: сильные уже обходятся без скилла, а слабая ещё показывает его ценность. Если у вас есть доступ к небольшой модели, используйте её как свидетеля на шаге B.
Ресурсы
- Работа: Beyond Gain: Measuring Skill Internalization for Agent Skill Retirement.
- Авторы: Yanze Wang, Pengfei Yao, Tianyi Sun, Hongda Chen, Yunyun Han, Jun Sun, Chuanrui Hu, Yafeng Deng. EverMind, Shanda Group, Peking University, Southeast University.
- Код: github.com/EverMind-AI/SkillCorpus (папка skillcorpus/lifecycle).
- Данные: huggingface.co/datasets/EverMind-AI/skillcorpus-lifecycle.
- Связанные работы из статьи: формат задач Tessl; SkillsBench; правила удаления скилов в ASSAY, SKILL0, SKILLC, SLIM.