Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Набор правил для кодирующего агента можно автоматически переписывать так, чтобы агент выдавал более короткий код и не чаще ошибался. В препринте Duke University, который не прошёл рецензирование и содержит собственные замеры авторов, RuleEvolve сократил среднюю длину кода более чем на 60% в связке OpenAI SDK и gpt-5.3-codex без снижения доли пройденных тестов. Для команд, которые используют AGENTS.md или системные инструкции, это превращает правила из ручной документации в оптимизируемую часть агента.
Как RuleEvolve мутирует и отбирает правила
Кодирующие агенты добавляют файл с правилами к контексту базовой LLM. В нём команда задаёт порядок работы, требования к коду и другие общие инструкции. Такие файлы обычно пишут вручную и оставляют неизменными, хотя одна формулировка может влиять и на правильность решения, и на длину ответа.
RuleEvolve начинает с исходного набора правил и создаёт из него пул вариантов. LLM-мутатор меняет формулировки, переставляет и объединяет шаги, а также пробует другой стиль инструкций. После этого модуль оценки запускает агента на программных задачах, выполняет полученный код и проверяет его тестами.
Оценка сочетает два сигнала. Непройденный тест получает штраф относительно запуска без дополнительных правил, а среди достаточно правильных вариантов выигрывает тот, который генерирует меньше символов. Число символов служит приближением для длины кода и расхода выходных токенов, поэтому метод напрямую не оптимизирует задержку API или стоимость по тарифу поставщика.
Новые мутации распределяются не поровну. Больше попыток получают варианты с нестабильными результатами и кандидаты, которые близки к текущему лидеру: первые могут скрывать удачное направление, вторые проще улучшить небольшим изменением. Новый вариант наследует историю оценок родителя, после чего система оставляет лучшие правила и повторяет цикл.
Основная часть улучшений пришлась на первые 5 итераций, а к 20-й показатели вышли на плато. Для настройки использовали 1 000 задач BigCodeBench, а итог проверяли на отдельных выборках по 100 задач из BigCodeBench, BigCodeBench-Hard и HumanEval. Эксперименты охватили OpenAI SDK, OpenHands, несколько проприетарных моделей и Qwen-Coder-30b; отдельно метод запустили на задачах уровня репозитория из SWE-Bench Lite.
Более короткий ответ не потребовал жертвовать тестами
На BigCodeBench с OpenAI SDK правила RuleEvolve дали 49% пройденных задач против 47% у агента без правил. Средний ответ при этом сократился с 1 156 до 453 символов. Ручные правила в этом же сравнении делали код длиннее и не повышали правильность.
Результат не одинаков для всех сочетаний агента, модели и набора задач. С OpenHands метод в целом давал более выгодный баланс правильности и длины, но на одном из основных тестов немного уступил запуску без правил. Prompt-Ops иногда расходовал меньше токенов, однако чаще терял пройденные задачи, поэтому простая оптимизация короткой инструкции не заменила отбор по исполняемым тестам.
Повторные запуски с разными случайными начальными условиями сохранили тот же вывод: доля правильных решений осталась на уровне запуска без правил, а код стал короче. На SWE-Bench Lite RuleEvolve также показал лучшую правильность среди сравнений, но агент работал дольше. Значит, выигрыш по выходным токенам нельзя автоматически считать выигрышем по полной задержке агента.
Когда автоматическая эволюция правил меняет план разработки
Работа меняет планы команд, у которых уже есть повторяемый набор задач и автоматическая проверка результата. В таком контуре AGENTS.md стоит хранить как версионируемый артефакт, а его изменения проверять примерно так же, как новую модель или инструмент агента: на обучающей части задач подобрать вариант, затем подтвердить результат на отложенной части.
Без исполняемых тестов модуль оценки не отличит лаконичное правильное решение от лаконичной ошибки. Ручная экспертная оценка здесь плохо масштабируется, потому что каждый кандидат требует полного запуска агента. Поэтому внедрение начинается не с мутации текста, а с корпуса типовых задач и проверок, которые отражают реальные требования продукта.
Целевая функция RuleEvolve остаётся узкой: тесты контролируют функциональную правильность, а число символов поощряет краткость. Если для продукта важнее поддерживаемость, безопасность, совместимость или размер изменения в репозитории, эти свойства придётся добавить в проверку. Иначе система честно оптимизирует не тот результат, который нужен команде.
Правила в работе эволюционировали отдельно для каждой базовой LLM. При замене модели или агентского каркаса переносить найденный файл без повторного испытания рискованно: одна и та же инструкция может изменить стиль генерации и расход токенов. Практичный пилот — зафиксировать модель и агента, сравнить отсутствие правил, текущий ручной файл и RuleEvolve, а затем учитывать не только выходные токены, но и полное время выполнения.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
