TL;DR
Исследование проверяет простую схему. Агент решает задачу, записывает «скилл» (заметки о том, что он понял), и эти заметки целиком вставляют в промпт свежей попытки на ту же задачу, но в другой среде. Заметки идут как есть, без фильтра. Код и ход рассуждений первой попытки не передаются, только текст заметок. Авторы называют это переносом знаний и измеряют, стала ли вторая попытка лучше, чем если бы агент работал с нуля.
Главная находка: заметки не гарантируют улучшения. В среднем они помогают, но у каждой из шести моделей в каждом направлении часть задач стала хуже: от 16% до 45%. Результат зависит не от того, «получилось» ли у источника, а от того, кто был лучше: источник или тот, кого заметки должны были улучшить. Если автор заметок справился заметно лучше, помощь была в 71% случаев. Если хуже, заметки навредили в 54%. Провальные заметки иногда тоже помогали, а успешные иногда мешали. Заметки с категоричными выводами без доказательств («так делать не надо», «этот путь не работает») чаще встречались среди навредивших.
Метод по сути простой: агент по директиве ведёт заметки, где отделены подтверждённые факты, условия применимости и открытые вопросы. Затем заметки подаются новой попытке под нейтральным заголовком «это записано в прошлой попытке на ту же задачу». Для практика главное не сам протокол, а вывод: не вставляйте заметки прошлого прогона в агента вслепую.
Схема метода
ШАГ 1: Агент решает задачу в среде A. Параллельно ведёт скилл (текст, без кода)
→ скилл: подтверждённые находки, разделение работы, причины провалов,
условия применимости, открытые вопросы
ШАГ 2: Скилл передают как есть, даже если попытка провалилась
→ вставка в промпт под нейтральным заголовком
ШАГ 3: Новый запуск агента на ту же задачу в среде B, скилл — единственный доп. вход
→ код и ход рассуждений первой попытки НЕ передаются
ШАГ 4: Сравнение с запуском B «с нуля» при том же бюджете
→ выиграл / проиграл / без разницы
Шаги 1 и 3 — отдельные сессии агента.
Пример применения
Задача: Вы делаете ежедневный отчёт по продажам на Wildberries. Сначала агент в Claude Code собрал его на Python (API → пандас → Google Таблицы). Теперь заказчик просит ту же логику в n8n без кода. Хочется не терять то, что агент узнал: лимиты API, подводные камни с возвратами, порядок агрегации. Но и не утащить в новую сборку его ошибочные догадки.
Промпт для конца первой сессии:
Ты закончил задачу: ежедневный отчёт по продажам Wildberries на Python.
Сейчас та же задача будет решаться заново в другой среде (n8n, без кода).
Составь заметку для новой попытки. Правила:
- Только текст. Без кода, команд и названий функций Python.
- Раздел «Подтверждено»: выводы, которые ты проверил на реальных ответах API. К каждому — чем подтверждено.
- Раздел «Как делить работу»: что делать на стороне API-запроса, что при агрегации, что при выгрузке.
- Раздел «Что не получилось и почему».
- Раздел «Условия применимости»: когда вывод верен, а когда нет.
- Раздел «Открытые вопросы»: что не проверено.
- Выводы, которые ты не проверял, не формулируй как запреты и не исключай ими альтернативы.
Промпт для новой сессии (n8n):
Задача: ежедневный отчёт по продажам Wildberries в n8n.
Ниже заметка из прошлой попытки на ту же задачу в другой среде.
Заметка может быть неполной или ошибочной.
{вставить заметку}
Результат: Агент вернёт структурированную заметку с пятью разделами. Подтверждённое будет отделено от гипотез. Новая сессия получит её как дополнительный контекст. После запуска сравните результат с запуском «с нуля». Если заметка пришла из неудачной попытки, особенно внимательно смотрите на её запреты.
Почему это работает
Слабость. Агент не знает, какие из его выводов верны. Заметка — это текст, и по форме правильный вывод неотличим от случайной догадки. Новая попытка читает заметку как инструкцию и идёт за ней. Сильные модели в статье чаще ошибались именно так: они следовали заметке в неверную сторону. Слабые чаще ломались на собственном исполнении.
Сильная сторона. Модель хорошо переносит принципы (избегай лишних промежуточных данных, делай тяжёлую часть в одном месте), если они отделены от синтаксиса и привязаны к условиям. Заметка без кода вынуждает записывать суть. Перенос ценен, когда источник реально продвинулся дальше.
Как метод использует это. Директива требует доказательств, условий применимости и списка открытых вопросов. Благодаря этому заметка содержит меньше «приговоров» без обоснования. Авторы не проверяли, насколько это улучшает результат: они лишь показали, что именно безосновательные выводы чаще среди навредивших.
Рычаги: - Раздел «Подтверждено» → требуй источник («на каком запуске проверено»). Это отсекает догадки. - Раздел «Открытые вопросы» → оставь, чтобы новая попытка не принимала их за факты. - Запрет кода → убери, если среда та же. Тогда можно передавать и сниппеты. - Заголовок вставки → нейтральный. Если написать «проверенный рецепт», вы усилите слепое следование.
Шаблон промпта
Директива для агента (оригинал-протокол авторов, адаптация на русский):
В течение всей работы веди заметку (скилл) на естественном языке.
Заметка может быть передана новой попытке на ту же задачу в другой среде ({среда_B}).
В заметке записывай:
1. Находки, подкреплённые доказательствами ({чем_подтверждено}).
2. Как поделить работу между {готовые_инструменты} и {новая_среда}.
3. Причины неудач.
4. Условия применимости каждого вывода.
5. Открытые вопросы.
Правила:
- Выводы не должны зависеть от синтаксиса и API среды {среда_A}.
Детали допустимы только там, где нужны для объяснения доказательства.
- Не пиши код, команды и инструкции по API.
- Если не уверен, помечай «не проверено».
Заголовок для вставки в новую сессию:
Ниже заметка, записанная в предыдущей попытке на ту же задачу в другой среде.
{заметка}
Подставьте: {среда_A} и {среда_B} — две среды или два инструмента, {чем_подтверждено} — как проверяли (запуск, ответ API, тест), {готовые_инструменты} — то, что работает в обеих средах без изменений.
🚀 Быстрый старт — вставь в чат:
Вот шаблон директивы для ведения заметок агента между попытками.
Адаптируй под мою задачу: {твоя задача и две среды}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие две среды, что общего у них, чем в твоей задаче можно подтвердить вывод. Это нужно, чтобы отделить принципы от синтаксиса и задать, что считать доказательством.
Ограничения
⚠️ Нет гарантии выигрыша: в каждой модели и каждом направлении часть задач стала хуже. Средний плюс скрывает заметный процент проигравших.
⚠️ Слабый источник вредит: если заметки написал агент, который справился хуже, чем получилось бы у принимающего, они вредят чаще, чем помогают.
⚠️ Нужна оценка источника: «прошла проверка» не равно «заметка полезна». Успешный источник не гарантирует пользу, а провальный не исключает её. Полезно сравнивать с тем, что вы получили бы без заметки.
⚠️ Совет по формулировке не проверен как вмешательство: авторы измеряли содержание заметок задним числом. Они не сравнивали «с требованием доказательств» и «без него». Что безосновательные выводы чаще у навредивших, показано. Что запрет на них улучшит результат, нет.
⚠️ Узкая область и один домен: оптимизация GPU-ядер в двух языках. Перенос на ваши задачи придётся проверять самому.
⚠️ Результат шумный: по одной попытке на задачу, а положительные цифры у части моделей держатся на одном-двух семействах задач.
Как исследовали
Исследователи собрали 74 задачи оптимизации GPU-ядер, каждую в двух вариантах, которые различались только языком программирования: CuTe DSL и TIRx. Шесть моделей (три крупные и три «Flash») сначала решали каждый вариант в одиночку по 40 минут. Заодно им велели записывать заметки-скиллы без кода. Потом заметка из одного языка целиком вставлялась в свежую попытку на ту же задачу в другом, независимо от того, прошла ли первая проверку. Принимающую попытку сравнивали с «одиночной» при том же бюджете. Измеряли корректность и скорость. Смена статуса (спасли или сломали) весила как максимальное изменение скорости.
Итог: от −19% до +29% по моделям и направлениям. У четырёх моделей выигрыш в обе стороны, но вред встречался везде. Помощь отмечена в 277 сравнениях, вред в 223. Неожиданности. Во-первых, результат определяет положение источника относительно цели, а не его «успешность»: при источнике выше цели помогло в 71%, при источнике ниже навредило в 54%. Во-вторых, вред асимметричен: если заметки помогли в одну сторону, то в обратную чаще вредили (41% против 23%). Значит, это эффект именно заметок, а не случайность. В-третьих, у крупных моделей ошибки чаще от следования заметке в неверную сторону, а у слабых — от собственных сбоев. Для практики вывод такой: заметки полезны, но их надо проверять, а не вставлять вслепую.
Адаптации и экстраполяции
🔧 Техника: вставка со статусом проверки → меньше слепого следования
Добавьте в заголовок: «Заметка может быть ошибочной. Утверждения в разделе "Подтверждено" можно использовать как точку отсчёта, остальное проверь сам, прежде чем применять». Авторы использовали нейтральный заголовок. Эффект такой формулировки не измерен, это просто логичное следствие их находки про безосновательные выводы.
Экстраполяция: сравнивайте не «успешность», а «лучше ли заметка вашего текущего результата». Перед вставкой попросите агента:
Вот твой текущий результат: {результат_B}.
Вот заметка, записанная в другой попытке, чей результат был {результат_A}.
Сравни, где заметка автора реально продвинулась дальше, а где нет.
Оставь только то, чего у тебя нет и что подтверждено.
Это моя идея, не из статьи, но она следует из главного результата.
Ресурсы
- MetaKernelBench: Measuring GPU Kernel Knowledge Transfer Beyond Code
- Страница проекта: https://yige24.github.io/MetaKernelBench
- Авторы: Xueyi Chen, Shiyu Liu, Xin Jin, Yuhua Zheng, Xin Li, Haolei Bai, Junhan Zhu, Huan Wang (Westlake University, Shanghai Jiao Tong University, Zhejiang University)
- Упоминаются: Terminal-Bench (Terminus-2), SOL-ExecBench, FlashInfer-Bench, vLLM, flash-linear-attention