TL;DR
Meta-skills (мета-навыки) — это короткие правила для модели-«прораба» (Builder). Прораб не решает задачу сам. Он строит исполнителю (Target) рабочее окружение: инструкции, чеклисты, инструменты проверки, память, заготовки файлов. Каждое правило записано в три поля: когда нужна поддержка, что построить, как исполнитель должен этим пользоваться. Правила прораб набирает сам: смотрит, где исполнитель споткнулся на тестовых задачах, и записывает урок.
Главная находка: один и тот же набор знаний работает намного лучше, когда его воплощают в окружение, чем когда его просто вставляют исполнителю в промпт. Совет вроде «проверяй результат перед сдачей» модель-исполнитель читает, но применяет по-своему: то забывает, то делает формально. А если прораб превратил совет в скрипт проверки, который запускается перед сдачей, пропустить его труднее. Средний выигрыш от «построенного» окружения над «врученным» советом — около 12 пунктов. Прямая подача тех же правил исполнителю местами даже вредила.
Метод работает циклом из трёх шагов. Прораб строит окружение для тренировочных задач. Исполнитель работает, и прораб читает его логи и оценки. Затем прораб добавляет или правит одно правило и обязан сослаться на доказательство. После этого банк правил замораживают и для каждой новой задачи прораб строит свежее окружение.
Схема метода
ЭТАП 1 (обучение, на 10% задач):
Прораб + текущий банк правил → строит окружение для задачи
Исполнитель работает в нём → лог + оценка
Прораб разбирает ошибки → ОДНО действие за пачку:
добавить правило | исправить правило | ничего не менять
(обязательно со ссылкой на доказательство из логов)
Повторить 2 прохода по тренировочным задачам
ЭТАП 2 (работа):
Банк заморожен → ВЕСЬ банк кладём прорабу в контекст
Прораб строит под каждую новую задачу своё окружение
Исполнитель решает задачу внутри него и сам отвечает за итог
ФОРМАТ ПРАВИЛА: когда → что дать → как использовать
Шаги этапа 1 идут отдельными запросами, этап 2 — тоже отдельным запросом на каждую задачу.
Пример применения
Задача: Вы ведёте аналитику для селлера на Ozon и Wildberries. Дешёвая модель в автоматизации собирает еженедельный отчёт по юнит-экономике. Она регулярно ломается одним и тем же образом: посчитала маржу, потом поправила комиссию в таблице и сдала отчёт со старой маржой. Раньше вы дописывали в промпт «обязательно перепроверяй». Не помогало.
Промпт для сильной модели (Builder):
Ты — Builder. Ты не решаешь задачу, а готовишь рабочее окружение для
исполнителя — более слабой модели.
Правило 1.
КОГДА: исполнитель меняет файл или таблицу после того, как проверил результат.
ЧТО ДАТЬ: чек-лист «версия данных → дата последней проверки» и скрипт,
который сравнивает текущие значения маржи с пересчётом по формулам.
КАК ИСПОЛЬЗОВАТЬ: перед сдачей исполнитель запускает скрипт, читает его
вывод и сам исправляет расхождения. Смысл цифр — его ответственность.
Правило 2.
КОГДА: в данных больше 3 источников (выгрузки Ozon, WB, себестоимость).
ЧТО ДАТЬ: единый шаблон таблицы со столбцами «источник», «период», «валюта».
КАК ИСПОЛЬЗОВАТЬ: исполнитель сначала сводит все выгрузки в шаблон и
только потом считает.
Задача исполнителя: собрать недельный отчёт по юнит-экономике
(выручка, комиссии, логистика, возвраты, маржа в ₽ и %) по трём SKU.
Сделай:
1. Выбери из правил те, что применимы к этой задаче.
2. Подготовь для исполнителя: инструкцию, шаблон таблицы, скрипт проверки,
порядок шагов и условие «сдавать можно только после зелёной проверки».
3. Оставь исполнителю принятие решений по содержанию. Окружение не должно
считать за него.
Результат: Модель выберет подходящие правила и выдаст пакет для исполнителя: короткую инструкцию, шаблон таблицы, скрипт или формулы проверки и порядок шагов с жёстким условием сдачи. В нём будет видно, какое правило породило какой элемент. Исполнитель затем работает уже внутри этого пакета, а не по одному лишь совету «перепроверяй».
Почему это работает
Слабость. Совет в промпте исполнителя — это просто текст. Модели приходится самой решить, когда он применим, и самой его выполнить. Слабые модели делают это нестабильно. В исследовании прямая подача правил исполнителю у части моделей была хуже, чем правила, превращённые в окружение. Для некоторых моделей она не лучше, чем вообще без них.
Сильная сторона. Модель-прораб хорошо переводит абстрактное правило в конкретные артефакты: файл с шаблоном, скрипт, чеклист, порядок шагов. Это переносит работу «понять и применить» с исполнителя на момент до запуска. Исполнителю остаётся то, что он делает лучше всего: рассуждать о содержании и принимать решения.
Как метод обходит слабость. Формат «когда / что дать / как использовать» заставляет описывать не абстрактное «будь аккуратнее», а наблюдаемое условие и конкретный ресурс. Ограничение «одна правка за пачку, только с доказательством» не даёт банку правил разрастаться из догадок.
Рычаги управления: - Размер банка. Весь банк в контексте прораба выиграл у отбора двух правил по поиску почти во всех случаях. Пока правил десяток-другой, давайте все. - Поле «как использовать». Оно оставляет исполнителю ответственность за суть. Уберёте — окружение начнёт «считать за него», и тогда оно ломается на нестандартных задачах. - Число проходов. На одной из задач прирост появился только после второго прохода рефлексии. Не останавливайтесь на первом. - Условие правки. Требуйте ссылку на конкретный эпизод. Без неё правила превращаются в общие слова.
Шаблон промпта
Шаблон А. Прораб строит окружение под задачу (рабочий режим):
Ты — Builder. Ты не решаешь задачу, а готовишь рабочее окружение для
исполнителя ({модель_исполнитель}).
{банк_правил}
{описание_задачи}
Инструкции, память/журнал, организация контекста, составные инструменты,
управление выполнением, проверка и восстановление, подготовка рабочего
пространства.
Действуй так:
1. Для каждого правила из банка проверь условие КОГДА. Выпиши, какие
правила сработали, и почему.
2. По сработавшим правилам построй компоненты: что именно дать
исполнителю и в каком виде (текст, чеклист, скрипт, шаблон файла).
3. Опиши, КАК исполнитель должен использовать каждый компонент, и что
остаётся его ответственностью.
4. Не решай задачу за исполнителя.
Выведи: список сработавших правил → список компонентов → тексты и
скрипты компонентов → итоговую инструкцию исполнителю.
Шаблон Б. Обновление банка правил (обучение):
Ты — Builder. Ниже текущий банк правил, окружение, которое ты построил,
и лог работы исполнителя с оценкой.
{банк_правил}
{построенное_окружение}
{лог_и_оценка}
Найди одну наблюдаемую ошибку или повторяющуюся нагрузку, которую можно
было бы снять лучшей поддержкой. Сравни урок с текущим банком и выбери
ОДНО действие:
- REVISE — если доказательство исправляет или усиливает существующее правило;
- ADD — если это новая отдельная потребность в поддержке;
- KEEP — если обновление не оправдано.
Любое изменение сопровождай цитатой из лога как доказательством.
Формат правила: КОГДА (наблюдаемое условие) → ЧТО ДАТЬ (ресурс/механизм)
→ КАК ИСПОЛЬЗОВАТЬ (что делает исполнитель и за что отвечает он сам).
Что подставлять: {банк_правил} — сначала пустой, потом накопленные правила. {описание_задачи} — публичная постановка. {лог_и_оценка} — то, что исполнитель сделал, и ваша оценка результата. {модель_исполнитель} — на чём будет работать.
🚀 Быстрый старт — вставь в чат:
Вот шаблоны метода мета-навыков (Builder строит окружение для исполнителя
и обновляет банк правил). Адаптируй под мою задачу: {твоя повторяющаяся
задача, где исполнитель стабильно ошибается}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблоны выше]
LLM спросит, в чём исполнитель ошибается, чем вы это проверяете и какие инструменты ему доступны. Эти ответы нужны, чтобы сформулировать поля «когда» и «что дать» на реальных эпизодах, а не из общих соображений. Она возьмёт структуру из шаблонов и соберёт стартовый банк правил под вашу задачу.
Ограничения
⚠️ Нужен код для полной версии: в статье Builder пишет скрипты, инструменты и хранилища, а исполнитель вызывает их. В обычном чате без выполнения кода можно воспроизвести только «текстовую» часть: инструкции, чеклисты, шаблоны. Самые сильные эффекты строились на исполняемых проверках.
⚠️ Эффект неровный: прирост зависит от пары «прораб — исполнитель» и от задачи. На разнородных задачах, где всё упирается в планирование самого исполнителя, выигрыш заметно меньше. Лучше всего работает там, где одни и те же сбои повторяются из раза в раз.
⚠️ Передача правил исполнителю напрямую может навредить: на части моделей тот же банк, положенный в промпт исполнителя, дал результат ниже, чем окружение без правил вообще.
⚠️ Поздняя регрессия: на одном из бенчмарков качество в какой-то момент рефлексии снижалось. Больше проходов — не всегда лучше. Сверяйте на отложенных задачах.
⚠️ Нужны тренировочные задачи с оценкой: без способа понять, хорошо ли отработал исполнитель, прораб не извлечёт урок. Все эксперименты — с одной моделью-прорабом и с бенчмарками, а не реальными рабочими процессами. Затраты на работу прораба в бюджет не входили.
Как исследовали
Идея была простой: вместо того чтобы учить исполнителя, учим того, кто готовит ему рабочее место. Взяли два бенчмарка: Harness-Bench (106 задач про агентные рабочие процессы) и NewtonBench (324 задачи на «открытие» научных законов). На обучение отложили 10% задач, остальное оставили для проверки. Прорабом была одна сильная модель, исполнителями — три разные: Gemini, Qwen и GPT-OSS-120B. Банк правил начинался пустым и обновлялся за два прохода по тренировочным задачам.
Сравнивали по-честному, с пятью вариантами. Это исполнитель без помощи, прораб без правил (проверка «а может, он просто хорошо строит»), правила, отданные исполнителю напрямую, и два вида навыков, добытых из самих запусков исполнителя. Итог: полный банк правил у прораба дал 65.31% против 56.36% без правил — прирост 8.95 пункта. Тот же банк, отданный исполнителю напрямую, дал на 12.02 пункта меньше. Навыки, добытые из запусков исполнителя, дали ещё меньше.
Удивило несколько вещей. Правила работают как «язык для организации поддержки», а не как подсказки для решения. Весь банк обычно обгонял отбор двух правил поиском: правила дополняют друг друга, и поиск по словам этого не видит. Прирост на одной из задач почти весь пришёл со второго прохода: первый дал меньше 1.1 пункта, второй — 12–13. Когда одна и та же модель выступала и прорабом, и исполнителем, средний прирост составил 18.71 пункта. Практический вывод: сильной модели выгодно строить окружение, а не давать советы, и учиться на реальных сбоях стоит минимум в два захода.
Оригинал из исследования
Пример одного правила в формате «когда / что дать / как использовать». Автор приводит его как иллюстрацию:
Consider an artifact edited after validation, making the earlier check
potentially outdated. A meta-skill's when field identifies this condition;
provide requests version tracking and revalidation; and use directs the
Target to inspect the current validation result before submitting, while
retaining responsibility for content judgment and correction. The Builder
could then implement this principle with file-version memory and a
validation tool.
Контекст: это единственный развёрнутый пример правила в основном тексте. Реальные запуски (с кодом Builder и вызовами Target) вынесены авторами в приложение, которого в нашей версии нет.
Адаптации и экстраполяции
💡 Адаптация для файла инструкций агента (CLAUDE.md / AGENTS.md): вместо абстрактных советов («проверяй тесты») попросите агента превратить правило в артефакт.
Вот три повторяющихся сбоя, которые ты допускал в этом репозитории:
{сбои}.
Для каждого сбоя напиши правило в формате КОГДА → ЧТО ДАТЬ → КАК ИСПОЛЬЗОВАТЬ.
Затем сам создай в репозитории то, что указано в «ЧТО ДАТЬ»: скрипт
pre-commit проверки, шаблон файла, чеклист. В CLAUDE.md оставь только
короткие ссылки на эти артефакты и условия запуска.
🔧 Техника: убрать «КАК ИСПОЛЬЗОВАТЬ» → окружение начнёт решать за исполнителя. Поле нужно, чтобы смысловые решения оставались у исполнителя. Если его убрать, получится «костыль», который ломается на нестандартной задаче. Это вывод из логики метода, а не из отдельной проверки.
Экстраполяция: ручная рефлексия с другой моделью. Прогоните 10–20 типовых задач на дешёвой модели. Загрузите логи и ваши оценки в сильную модель с шаблоном Б. Принимайте по одному правилу за заход. После каждого сверяйтесь на 5 отложенных задачах: этот приём в статье не проверялся, но следует из её цикла.
Ресурсы
- Работа: Learning Meta-Skills for Agent Harness Design in Test-Time AI4AI
- Авторы: Cheng Qian, Kunlun Zhu, Beibin Li, Zhenhailong Wang, Heng Ji
- Код: https://github.com/qiancheng-apodex/MetaSkill-AI4AI
- Бенчмарки: Harness-Bench, NewtonBench
- Связанные идеи из статьи: Meta Context Engineering, Agentic Context Engineering, ExpeL, Voyager, Meta-Harness, SkillsBench