Скилл-оптимизаторы: автоматически дописанные правила для агента не лучше ручного скила, но делают его дороже

Сам метод авторов (BiPA) — это диагностика, а не промпт. Для читателя полезны её выводы, поэтому схема показывает, как проверять любую правку инструкции агента:

ШАГ 1: Прогнать исходный скил несколько раз → узнать его собственный разброс
ШАГ 2: Прогнать новый скил столько же раз   → принять правку, только если разница больше разброса
ШАГ 3: Для каждого нового правила спросить   → сколько ходов оно добавит?
ШАГ 4: Удалить / объединить правила          → не только дописывать
ШАГ 5: Показать редактору цену прошлых правил → прежде чем он пишет новые

Шаги 1–2 делаются вручную или в автоматизации. Шаги 3–5 можно сделать промптом в обычном чате (см. шаблон ниже).

Задача: Вы ведёте небольшую студию, которая делает сайты на Битриксе. Агент Claude Code правит вёрстку и скрипты. После каждого сбоя вы дописывали в CLAUDE.md правило: «проверь ещё раз», «после каждого изменения запусти сборку», «читай файлы по одному». За полгода набралось 90 строк. Агент стал работать медленнее, а токены в тарифе заканчиваются к середине месяца. Нужна ревизия.

Промпт:

Ты — редактор инструкций для ИИ-агента. Ниже мой CLAUDE.md. 
Он разросся: правила дописывались после каждого сбоя, и никто их не пересматривал.

Контекст: агент правит сайты на 1С-Битрикс (PHP, JS, вёрстка). 
Каждый ход агента заново отправляет модели всю переписку, поэтому лишний ход 
стоит дороже, чем строка в инструкции.

Сделай ревизию в 4 шага:

ШАГ 1. Раздели каждое правило на категорию: 
«проверь» (повторная верификация), «по одному» (действуй одним вызовом за раз), 
«читай» (что и сколько читать), «формат», «границы» (чего нельзя), «прочее».

ШАГ 2. Для каждого правила оцени, сколько ДОПОЛНИТЕЛЬНЫХ ХОДОВ агента оно 
порождает: 0 / 1–2 / много. Правила «проверь» и «по одному» оценивай особенно строго.

ШАГ 3. Найди дубли и противоречия. Предложи, какие правила УДАЛИТЬ, 
какие ОБЪЕДИНИТЬ в одно. Для каждого решения — одна строка причины.

ШАГ 4. Выдай новую версию файла. Правило проверки оставь одно: 
«перед заявлением о завершении выполни свежую полную проверку». 
Правила, которые порождают много ходов, оставляй только если они закрывают 
реальный сбой из моих заметок.

Вот мои заметки о реальных сбоях: {список_сбоев}
Вот CLAUDE.md: {текст_файла}

Результат: Модель выдаст таблицу правил с категориями и оценкой ходов, затем список «удалить / объединить» с причинами и новую короткую версию файла. Правило проверки будет сведено к одному. Дальше нужно прогнать агента на 5–10 типовых задачах по несколько раз и сравнить расход токенов со старой версией.

Слабость. Агент выполняет инструкции буквально. Правило «проверь результат» он превращает в лишний вызов инструмента, а «пиши по одному» — в серию ходов вместо одного. Каждый ход заново отправляет модели всю переписку, поэтому в длинной задаче лишний ход почти удваивает стоимость самого себя (в статье это называется «эластичностью по ходам»). Инструкция выглядит короткой, а счёт растёт.

Почему накопление не ловится. Правку оценивают целиком и по малой выборке. Нельзя понять, какое из десяти добавленных правил помогло, а какое просто стоит денег. Если выбирать лучшего из нескольких шумных результатов, победитель почти всегда «выигрывает» за счёт удачи.

Сильная сторона и как метод её использует. Модель хорошо классифицирует и сокращает текст. Поэтому ей можно поручить ревизию: разложить правила по категориям, найти дубли, объединить. Исходный скил в исследовании был именно таким: одно общее правило «свежая полная проверка перед заявлением о готовности». Он оказался не хуже всего, что выучили автоматы.

Рычаги управления: - Категории правил → добавьте свои (например, «безопасность»), чтобы не удалять нужное. - Шкала цены в ходах → замените на «токены» или «секунды», если считаете их. - Список реальных сбоев → оставляйте правило, только если оно закрывает сбой из списка. Это защита от «мёртвых» правил. - Число прогонов для сравнения → чем шумнее задача, тем больше нужно повторов.

Это применение принципов 2–4 из статьи для ручной или чатовой ревизии. Авторы сами такой промпт не тестировали.

Ты — редактор инструкций для ИИ-агента. Нужно сократить и очистить инструкцию, 
не потеряв полезных правил.

Что делает агент: {задача_агента}
Реальные сбои, ради которых писались правила: {список_сбоев}

Инструкция:
{текст_инструкции}

Сделай:
1. Для каждого правила укажи категорию: проверка / по одному / чтение / формат / границы / прочее.
2. Оцени, сколько дополнительных ходов агента оно порождает (0 / 1–2 / много). 
   Каждый ход заново отправляет всю переписку, поэтому считай цену в ходах, а не в длине.
3. Предложи УДАЛИТЬ правила без привязки к реальному сбою, 
   ОБЪЕДИНИТЬ дубли и пересекающиеся правила.
4. Выдай новую версию. Она должна быть короче исходной. 
   Правил типа «проверь» — не больше одного.

Формат ответа: таблица (правило | категория | ходы | решение | причина), затем новая версия.

Подставьте: {задача_агента} — одной фразой, что агент делает; {список_сбоев} — реальные случаи, из-за которых вы дописывали правила; {текст_инструкции} — ваш CLAUDE.md, AGENTS.md или скил целиком.

⚠️ Проверялось на длинных агентных задачах: терминал, поддержка клиентов, бизнес-процессы. Для коротких одиночных запросов (вопрос-ответ) выводы про стоимость ходов не обязательно переносятся.

⚠️ Агент без сжатия истории: в исследовании переписка отправлялась целиком на каждом ходу. Если ваш инструмент сжимает историю или кэширует, лишние ходы обходятся дешевле. Токены в отчёте не равны рублям.

⚠️ Диагностика требует логов и кода: сам BiPA (повтор отбора, граф ходов) вам не доступен без инженера. Из статьи берутся выводы, а не инструмент.

⚠️ Принципы не проверены как вмешательство: авторы вывели четыре принципа из анализа, но в доступной части текста не показали, что оптимизатор с ними становится лучше. Шаблон выше — наше применение, а не проверенный метод.

⚠️ Малые выборки: на одном из бенчмарков в тесте всего 18 задач, разброс большой.

⚠️ Вредные правила тоже бывают нужны: статья не говорит «не проверяй результат». Она говорит, что правила проверки накапливаются и дорожают. Одно общее правило хорошо работает.

Исследователи взяли три опубликованных оптимизатора скилов (GEPA, SkillOpt, SkillAdam) и три агентных бенчмарка: Terminal-Bench 2.1 (починка терминальной среды), τ³-bench (поддержка клиентов с симулированным пользователем) и AutomationBench (бизнес-процессы). Агентом были две модели в harness OpenCode без сжатия истории. Все оптимизаторы стартовали с одного ручного скила: общего правила «свежая полная проверка перед заявлением о готовности». В итоге получилось 16 выученных скилов. Каждый скил, включая исходный и вариант «без скила», прогнали на тесте по три раза.

Главная идея: прогнать правило приёма оптимизатора на кандидатах, абсолютно идентичных исходному скилу. Если «ничего не менявшие» кандидаты показывают такой же прирост, значит, прирост даёт сам отбор. Так и вышло. Неизменённые кандидаты воспроизводили заявленные приросты с вероятностью от 0,25 до 0,94. Заявленные 3–17 пунктов на dev-выборке на тесте не подтвердились: итог в среднем плюс 0,1 пункта, а у девяти скилов под DeepSeek даже минус 1,4. Скилы примерно столько же задач выигрывали, сколько проигрывали (57 против 62). То есть они не расширяли возможности агента, а лишь делали его поведение более однообразным.

Цену изучали отдельно. Каждый прогон записали как граф «ходы ↔ тексты, которые они читают». Все девять скилов под DeepSeek читали на 8–43% больше токенов и делали на 3–22% больше ходов. Среди 337 добавленных правил ни одно не просило читать меньше, половина просила проверять, 18 просили «по одному». На AutomationBench 56% записей у исходного скила шли группой, у выученных — не больше 0,3%: записи стали идти по одной. Удивило ещё одно: стоимость переезжает вместе со скилом на другую модель и другой бенчмарк, а польза — нет. Практический инсайт: правила дороги, польза от них сомнительна, и её надо мерить с учётом шума.

Полного текста исходного скила (verification-before-completion, Vincent, 2025) в доступной части статьи нет. Описано лишь, что он просит свежую, полную проверку перед любым заявлением о завершении. Блок пропущен.

💡 Адаптация для проверки любой правки инструкции: вместо «стало лучше на двух запусках» используйте протокол с учётом шума.

Copy

Я изменил инструкцию агента. Помоги спланировать проверку.
Задача агента: {задача}. Типовых задач для прогона: {число}.
1. Предложи, сколько раз прогнать СТАРУЮ версию, чтобы оценить её собственный разброс.
2. Предложи правило: новая версия считается лучше, только если разница 
   превышает этот разброс.
3. Предложи, что фиксировать кроме «решил / не решил»: число ходов, расход токенов.

🔧 Техника: добавить в промпт ревизии «цена ходов» → агент перестаёт плодить проверки. Фраза в инструкции: «Перед заявлением о готовности выполни одну свежую полную проверку. Не повторяй её после каждого шага». Заменяет россыпь правил «перепроверь» одним.

🔧 Техника: независимые вызовы → в один ход. Если нужно записать несколько файлов или сделать несколько независимых действий, просите: «Независимые вызовы инструментов делай в одном ходу». Статья показывает, что запись «по одной за ход» — одна из главных причин роста ходов.

• Работа: Does Your Generalist Skill Optimizer Really Incentivize Agentic Tasks? Rethinking Skill Optimization via Bipartite Attribution
• Код: github.com/valleysprings/BiPA
• Авторы: Jiawei Zhou, Bo Peng, Yuxuan Huang, Ming Zhang, Youbang Sun, Xiang Wang, Chaochao Lu
• Организации: Shanghai AI Laboratory, Fudan University, Shanghai Jiao Tong University, USTC, Tsinghua University
• Упомянутые оптимизаторы и бенчмарки: GEPA, SkillOpt, SkillAdam; Terminal-Bench 2.1, τ³-bench, AutomationBench; harness OpenCode