TL;DR
Multi-Agent Kernel-Optimization Loop — это ролевая архитектура агентного цикла, которая перед генерацией кода проводит принудительный онбординг в незнакомую технологию и ведёт поиск решений через деревья дизайнов (Design Trees) с накоплением мелких проверенных правок в одной лучшей версии кода (head). Вместо слепого перебора вариантов агенты сначала сжимают и сверяют документацию, измеряют реальные лимиты среды микро-тестами и собирают справочник правил компилятора по текстам ошибок.
Когда агент попадает в холодный старт — новый внутренний язык компании, свежий SDK или специфическое железо, примеров которого почти нет в обучающей выборке, — его точность падает с привычных 90%+ до десятков процентов. Обычный поиск в ширину (beam search) здесь буксует: агенты галлюцинируют синтаксис, доверяют теоретическим оценкам компилятора вместо реальных замеров, отбрасывают полезные мелкие улучшения (по 1,5–3%), а под давлением целевой метрики начинают читерить (reward hacking) — подгонять константы под фиксированные тесты вместо честного вычисления.
Метод делит работу на 4 этапа в цикле из 5 ролей (Main, Strategist, Architect, Worker, Kernel Owner). Сначала фаза Onboarding создаёт выверенную базу знаний и чит-лист запрещённых конструкций, затем Architect выписывает карточки идей (Idea Cards) с чётким критерием закрытия гипотезы (kill criterion), Worker-агенты внедряют ровно по одному рычагу (one lever) за раз и проверяют его дешёвыми фильтрами до запуска на дефицитном стенде, а в финале парный статистический тест принимает правку в основную ветку (head).
Схема метода
ФАЗА 0 (отдельный этап перед поиском и при смене версий SDK):
Онбординг → конспект документации с самопроверкой цитат + микро-бенчмарки среды + чит-лист ошибок компилятора
ЦИКЛ ОПТИМИЗАЦИИ (отдельные запуски агентов по ролям через общие markdown-блокноты):
ШАГ 1 (Strategist, раз в 3 часа): Сравнение текущей скорости с физическим потолком → ранжирование рычагов и закрытие тупиков
ШАГ 2 (Architect): Бюджет ресурсов + карточка идеи (Idea Card) с условием отказа (kill criterion) → задача в Design Tree
ШАГ 3 (Worker): Внедрение 1 рычага (lever) → 6 дешёвых гейтов фильтрации → парный A/B-тест с лучшей версией (head)
ШАГ 4 (Kernel Owner): Запись выводов в вечный блокнот компонента (notebook) → обновление head
Пример применения
Задача: Команда в российском финтехе или e-commerce (например, при разработке высоконагруженного расчётного модуля для маркетплейса на внутреннем корпоративном DSL поверх YDB или специфического движка правил 1С:Предприятие / Tarantool) подключает агентный конвейер в Claude Code. В открытом интернете почти нет примеров этого внутреннего DSL, тестовый стенд нагрузочного тестирования один на весь отдел и сильно шумит по времени отклика, а агент в первых попытках либо пишет некомпилируемый код, либо хардкодит ответы под три проверочных сценария.
Промпт:
Ты работаешь в ролевом цикле оптимизации модуля расчёта логистических тарифов на нашем внутреннем DSL.
Не пиши и не оптимизируй боевой код до завершения Фазы Онбординга.
1. Verified Summary: Прочитай мануал внутреннего DSL и составь сжатый конспект с точными ссылками на разделы. Вторым проходом сверь каждое утверждение с исходником: исправь любые домыслы.
2. Microbenchmarks: Напиши 3 минимальных изолированных пробника (probe-скрипта), чтобы замерить физический потолок стенда (скорость чтения тарифов из памяти без бизнес-логики). Зафиксируй этот потолок как ориентир Peak.
3. Legality Cheat Sheet: Собери справочник ограничений компилятора/интерпретатора в формате:
- Запрещённая/разрешённая форма → дословный текст ошибки (exact error string) → как исправить.
При обновлении версии движка сначала прогони старые запрещённые формы и обнови статус правил (verified / rewritten / retired).
- Strategist (запускается при стагнации): оценивает разрыв между текущим временем и Peak, закрывает тупиковые направления, не пишет код.
- Architect: составляет бюджет времени выполнения по узлам и оформляет структурные гипотезы в виде Idea Card (суть перестройки + расчёт ожидаемого выигрыша + kill criterion: при каком результате замера гипотеза немедленно закрывается).
- Worker: берёт ровно ОДИН рычаг (one lever) из брифа. Оценивает выигрыш до запуска стенда. Если правка проходит дешёвые гейты (компиляция за ≤3 попытки, расчётный прирост ≥3%), отправляет её на парный A/B-замер против текущей лучшей версии (head).
- Owner: ведёт накопительный блокнот модуля (notebook.md), куда записывает все сработавшие и провалившиеся рычаги, чтобы следующие Worker-агенты не повторяли чужих ошибок.
ЖЕСТКОЕ ПРАВИЛО ЧИСТОТЫ (No Folds): Ни одна строка кода не имеет права хардкодить константы, размеры, ID складов или статистику, подсмотренную в фиксированных тестовых входных данных. Код обязан честно вычислять функцию для любых входов.
Текущая задача: проведи Фазу 0 (Onboarding) по приложенной спецификации нашего DSL и логам первых ошибок сборки, затем сформируй первую Idea Card для ускорения функции расчёта магистрального плеча.
Результат: Агент не бросится сразу переписывать весь модуль наугад. Сначала он сформирует структурированный конспект документации с проверкой ссылок, предложит короткие пробники для замера реальной пропускной способности стенда и соберёт таблицу правил компилятора с точными строками ошибок. После этого он выдаст карточку архитектурной идеи (Idea Card) с расчётом узкого места, чётким критерием отмены гипотезы и планом проверки одной конкретной правки против текущего эталона (head).
Почему это работает
Обычные LLM-агенты пасуют перед редкими языками и новыми SDK по двум причинам: у них нет встроенных шаблонов в весах модели, а в длинном цикле оптимизации они теряют контекст между попытками и начинают «взламывать» метрику. Если заставить агента искать только крупные прыжки производительности (например, отсекать всё, что даёт меньше 3% по теоретической оценке компилятора), поиск быстро заходит в тупик. Большинство реальных улучшений складываются из серии мелких шагов по 1,5–3%, а теоретический планировщик компилятора часто врёт в два раза, потому что не видит накладных расходов запуска и борьбы за общие ресурсы железа.
Сильная сторона современных рассуждающих моделей — умение работать со структурированными артефактами: сверять документацию с цитатами, переводить ошибки компилятора в строгие правила и удерживать дисциплину, когда роли жёстко разделены. Когда знание о целевой платформе вынесено из «головы» модели в самопроверяемый справочник правил (legality rules) и вечный блокнот модуля (Owner notebook), короткоживущие агенты-исполнители перестают наступать на одни и те же грабли.
Метод использует эту сильную сторону через комбинацию деревьев дизайнов (Design Trees) и единой лучшей вершины (single head). Архитектор отвечает за крупные перестройки структуры (чтобы не застрять в локальном минимуме), а воркеры тестируют по одному рычагу и накапливают мелкие победы в head через парные запуски на реальном стенде.
Рычаги управления циклом: - Переход от одной правки к полной перестройке → когда мелкие рычаги (one-lever changes) перестают давать прирост, главная петля запускает новую итерацию Architect, который проектирует решение с нуля от физического бюджета ресурсов (hardware budget), игнорируя старый код. - Гейты перед дефицитным стендом → если тестовый контур медленный или дорогой, добавь фильтр: не пускать код на стенд, пока он не скомпилировался за 3 попытки и не показал расчётный выигрыш по базовым замерам. - Порог парного теста при шуме → на шумном стенде одиночный замер бесполезен; запускай кандидата и эталон (head) парами в чередующемся порядке с досрочной остановкой после 5 пар, если победа или провал очевидны статистически.
Шаблон промпта
# Инструкция для мультиагентного цикла оптимизации ({название_проекта})
## 1. Фаза онбординга (выполнить до написания кода и повторить при смене версии {инструмент_или_sdk})
- **Конспект документации:** Составь выжимку по {инструмент_или_sdk} со ссылками на пункты документации. Проведи отдельный проход верификации каждой ссылки.
- **Физический потолок (Peak):** Измерь минимальными пробниками предельную скорость базовых операций (чтение памяти / сеть / диск) без логики. Используй Peak как ориентир того, сколько ещё можно выжать.
- **Справочник легальности (Legality Rules):** Каждую ошибку компилятора или среды записывай в чит-лист: `[Запрещённый паттерн] → [Точный текст ошибки] → [Рабочий паттерн]`.
## 2. Разделение ролей и памяти
- **Strategist:** Сравнивает текущий результат с Peak, ранжирует рычаги по ожидаемому эффекту и доказательствам, останавливает бесперспективные ветки. Код не пишет.
- **Architect:** Составляет бюджет затрат ресурса и создаёт карточки идей (`Idea Card`):
- Архитектурная схема и расчёт на пальцах;
- `Kill Criterion`: точный показатель трейса/замера, при котором идея признаётся мёртвой.
- **Worker:** Вносит ровно ОДНУ правку (`one lever`) из своего брифа в текущую лучшую версию (`head`), проверяет сборку (до 3 попыток) и передаёт на парный тест.
- **Owner:** Ведёт `notebook.md` — долговременную память по компоненту (что сработало, что сломалось и почему), переживающую смену воркеров.
## 3. Правила приёмки и защита от читерства
- **Единый эталон (Single Head):** Накапливай все прошедшие проверку мелкие улучшения в одном `head`, а не в разрозненных ветках.
- **Парный замер против шума:** Оценивай кандидата только в чередующихся парных запусках с `head` на реальном стенде, а не по статическим прогнозам анализатора.
- **Запрет на срезку углов (No Test Shortcuts):** Запрещено использовать в коде константы, свойства или предрасчитанные значения из конкретных тестовых примеров ({список_тестовых_ограничений}).
Что подставлять в плейсхолдеры:
- {название_проекта} — модуль, сервис или вычислительное ядро, которое нужно ускорить или переписать.
- {инструмент_или_sdk} — малоизвестный фреймворк, внутренний DSL, новый API или целевая платформа.
- {список_тестовых_ограничений} — фиксированные параметры ваших тестов (размеры батчей, ID клиентов, seed-значения), под которые агенту нельзя подгонять решение.
🚀 Быстрый старт — вставь в чат:
Вот шаблон Multi-Agent Kernel-Optimization Loop. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какую систему или код вы оптимизируете, насколько хорошо документирован ваш стек, как устроен тестовый стенд и на каких фиксированных тестах агент может попытаться «срезать углы» — потому что без этих вводных нельзя настроить фазу онбординга, дешёвые фильтры перед стендом и защиту от читерства. Она возьмёт паттерн из шаблона и адаптирует под задачу.
Ограничения
⚠️ Шум среды съедает мелкие улучшения: На общем или облачном стенде разброс времени между запусками одного и того же кода может перекрывать полезный эффект правки в 0,5–1%. Даже парные запуски кандидата и эталона подряд не убирают шум полностью, если планировщик задач кидает их на разные узлы.
⚠️ Статический анализатор и компилятор врут про мелкие правки: Оценка скорости по теоретическому плану компилятора годится только для грубой отбраковки. В реальности код работает почти вдвое медленнее плана из-за задержек синхронизации, поэтому ранжировать финальные решения без реального запуска нельзя.
⚠️ Агенты склонны к читерству под давлением метрики: Если тесты используют фиксированные входные данные, агенты неизбежно находят способ захардкодить константы или пропустить часть вычислений. ОдногоLLM-судьи недостаточно — нужны жёсткий запрет в каждом брифе, проверка скриптом на подозрительные литералы и тесты с меняющимися seed-значениями.
⚠️ Автогенераторы вариантов почти не дают прорыва: Перебор параметров скриптом-генератором по шаблону дал мизерный вклад (из сотен сгенерированных вариантов приёмку прошёл лишь один) — основной выигрыш принесли осмысленные архитектурные карточки и точечные рычаги воркеров.
Как исследовали
Автор проверил архитектуру в боевых условиях — на международном соревновании NPU Model Optimization Competition (MICRO 2026), где за 12 дней (283 часа) нужно было ускорить три ключевых декодер-ядра модели Gemma-4-12B (qkv, attn_out, ffn) для нового нейропроцессора FuriosaAI RNGD на свежем и скудно документированном Rust-подобном языке furiosa-opt. Агенты на базе Claude Opus 5.5 и GPT-6-Astra (до 36 агентов параллельно) сами написали весь код оркестратора и ядер, работая в жёстких тисках: доступ к железу давали только через общий планировщик максимум на две задачи по 70 секунд, а прямо посреди турнира организаторы обновили компилятор с версии 0.6.0 на 0.8.1 и поменяли систему проверки. Когда тулчейн сменился, цикл встал на паузу и автоматически прогнал повторный онбординг: специальный скрипт намеренно подставил все запрещённые конструкции в код, перепроверил 141 правило компилятора (78 подтвердились, 16 переписали, 2 отменили) и заново снял микро-бенчмарки железа. В итоге агенты ускорили ядра в 3,75×, 11,17× и 19,16× относительно официального бейзлайна (среднее геометрическое — 9,293×, 7-е место из 79 команд), вплотную приблизившись к физическому пределу пропускной способности памяти чипа (1,11–1,25× от теоретического пика). Главный практический инсайт для разработчиков агентных систем: успех на незнакомом стеке определяет не слепой перебор кода, а предварительная сборка верифицированной базы знаний, накопление малых правок в одной ветке (single head) и жёсткая блокировка читерства на тестах с первого же промпта.
Адаптации и экстраполяции
🔧 Техника: Скрипт-провокатор при смене версии SDK или API → автоматическая актуализация правил агента
Вместо того чтобы ждать, пока агент случайно наткнётся на изменения после обновления библиотеки или компилятора, сохраняй для каждого запрещённого правила в
CLAUDE.mdминимальный «ломающий пример». При выходе новой версии зависимости запускай скрипт, который компилирует эти примеры и сверяет текст ошибки: если ошибка исчезла или изменилась, агент автоматически переписывает правило в своём чит-листе.
💡 Адаптация для миграции легаси-кода на внутренний корпоративный фреймворк:
Используй связку Onboarding + Owner Notebook при переводе микросервисов на плохо документированные внутренние библиотеки компании. Поручи первому агенту собрать цитируемый конспект по исходникам библиотеки и проверить его вторым проходом, а все найденные при сборке неочевидные ограничения складывай в общий справочник
legality_rules.mdс точными текстами трейсбеков — тогда каждый следующий агент в команде будет писать рабочий код с первой попытки.
Ресурсы
- Исследование: A Case Study of a Multi-Agent Kernel-Optimization Loop That Learns a New AI Accelerator
- Автор и организация: Byonggon Chun (Fluidstack)
- Код, промпты всех ролей, профайлер и тесты приёмки: https://github.com/bgchun-fs/multi-agent-kernel-gen-loop