TL;DR
RegoMender — система из трёх ролей: Orchestrator (диспетчер), Analyzer (диагност) и Repairer (исполнитель). Они чинят код по замкнутому циклу. После каждой правки официальный проверяющий инструмент (линтер, тесты) сообщает, стало ли лучше. Роли обмениваются записями через общую «доску» (Blackboard), а при застое система откатывается к последней рабочей версии.
Главная боль: модель чинит один сбой, а под ним вылезает следующий. Или она ходит по кругу: меняет код, ошибка та же, и так пять раз. Причина в том, что модель не видит состояния процесса. Она не помнит, что уже пробовала, и не знает, когда пора остановиться. Кроме того, ей не хватает контекста о коде вокруг ошибки. В эксперименте убрали инструмент сбора контекста (Context Scan), и именно это просадило результат сильнее всего.
Метод разводит роли. Диспетчер сам код не пишет, а только решает, кому передать работу. Простые ошибки с понятной строкой идут сразу исполнителю, сложные и повторяющиеся сначала диагносту. Если состояние ошибок не меняется несколько попыток подряд, диспетчер откатывает код и просит новый диагноз. Цикл заканчивается, только когда проходят обе проверки: синтаксис и тесты.
Схема метода
ЦИКЛ (до лимита итераций):
ШАГ 1: Orchestrator берёт код с доски → запускает Verify → получает список ошибок
ШАГ 2: Orchestrator фиксирует «сигнатуру ошибок» (категория, количество, серия повторов)
ШАГ 3: Маршрутизация:
• простая ошибка (ясная строка) → Repairer
• неясная / про зависимости / повторная → Analyzer → диагностический отчёт на доску → Repairer
ШАГ 4: Repairer правит: Patch (точечно) или Rewrite (больше 10 ошибок, нужна перестройка блока)
ШАГ 5: Verify снова:
• состояние изменилось → прогресс, серия повторов обнуляется
• не изменилось → новый диагноз от Analyzer
• серия достигла порога → ОТКАТ к снимку до застоя + новый диагноз
ВЫХОД: Done только если прошли и синтаксис, и тесты (или лимит итераций)
Всё это работает как программа с отдельными вызовами модели. В обычном чате цикл придётся вести вручную или поручить агенту с доступом к терминалу.
Пример применения
Метод сильнее всего там, где есть автоматическая проверка с чётким вердиктом: линтер, компилятор, тесты. Статья показала, что подход переносится с Rego на HCL (язык Terraform) и SQL.
Задача: DevOps-инженер в российской финтех-компании переносит инфраструктуру в Яндекс Облако. Terraform-конфиг на 400 строк падает на terraform validate. Он чинит одну ошибку, и вылезают три новые. ChatGPT в чате уже дважды предлагал «переписать всё заново».
Промпт (для Claude Code или другого агента с доступом к терминалу):
Ты работаешь по протоколу ремонта с тремя ролями. Файл: infra/main.tf.
Проверка: `terraform validate` (синтаксис) и `terraform plan` без ошибок (смысл).
Веди файл notes/blackboard.md — это общая доска. В нём три раздела:
- Code: номер версии и что изменено (перед каждой правкой делай git commit как снимок)
- Report: диагнозы Analyzer (категория ошибки, строка, сообщение, контекст, приоритет)
- Signature: <категория ошибки, число ошибок, серия повторов подряд>
Роль Orchestrator: сам код не правишь. Запускаешь проверку, обновляешь Signature,
решаешь, кому передать работу.
- Ошибка локальная и строка ясна → Repairer
- Ошибка неясная, про зависимости между ресурсами или повторяется → сначала Analyzer
- Состояние изменилось → прогресс, серия = 0
- Состояние не изменилось → запрос нового диагноза у Analyzer
- Серия = 3 → git revert к снимку до застоя и запрос нового диагноза
- Лимит: 15 итераций, потом остановись и покажи, что осталось
- Done только когда проходят и validate, и plan
Роль Analyzer: читаешь вывод проверки, раскладываешь каждую ошибку на
категорию / строку / сообщение, собираешь контекст (какие ресурсы и переменные
связаны с этим блоком), записываешь причину в Report. Код не меняешь.
Роль Repairer: берёшь диагноз из Report. Точечная ошибка → правишь одну строку.
Больше 10 ошибок или сломана структура блока → переписываешь блок целиком.
Не удаляй ресурсы, чтобы «пройти проверку».
Начинай с Orchestrator.
Результат: агент создаст файл-доску и будет вести журнал. В каждой итерации будет видно, какая роль работала и что показала проверка. Когда он зациклится, в логе появится откат к снимку. Финал: либо оба вердикта зелёные, либо остановка по лимиту со списком остатка.
Почему это работает
Слабость. Модель «в лоб» делает цикл «правка → ошибка → правка» без памяти о прошлых попытках. Она не замечает, что состояние не меняется, и не умеет откатываться. Часто она «чинит» проблему тем, что удаляет проверяемый код. Ещё одна слабость: модель плохо знает редкие языки и не видит контекст вокруг строки с ошибкой.
Сильная сторона. Модель хорошо работает, когда задача узкая и чётко описана. Она отлично читает вывод проверяющей программы и диагностирует по структурированному отчёту. Лучше всего она справляется, когда вердикт даёт внешний инструмент, а не её собственное мнение.
Как метод это использует. Он выносит «память процесса» наружу: на доску и в счётчик повторов. Решение «что делать дальше» принимает отдельная роль по явным правилам, а не модель между делом. Проверка остаётся единственным источником истины. Откат превращает тупик в управляемую ситуацию.
Рычаги управления: - Порог застоя (в примере 3) → меньше значит быстрее откат, больше значит больше попыток подряд. - Лимит итераций → защита от бесконечного цикла и от расхода токенов. - Порог «более 10 ошибок → переписать» → под свою задачу: когда точечные правки уже не помогают. - Правила маршрутизации → что считать «простой» ошибкой, а что «сложной». - Обязательный сбор контекста → в статье он дал самый заметный вклад, поэтому не выбрасывай эту роль ради экономии.
Шаблон промпта
Починить {файл_или_артефакт}.
Проверка 1 (синтаксис): {команда_проверки_1}
Проверка 2 (смысл): {команда_проверки_2}
Файл доски: {путь_к_файлу_доски}
- Code: версии кода (перед каждой правкой — снимок: {способ_снимка})
- Report: диагнозы Analyzer (категория, строка, сообщение, контекст, приоритет)
- Signature: <категория ошибки, число ошибок, серия повторов>
- Verify: запускает проверки, возвращает список ошибок
- ContextScan: собирает переменные, зависимости, связанные блоки вокруг ошибки
- ErrorTriage: превращает вывод проверки в список «категория / строка / сообщение»
- Patch: точечная правка одной строки
- Rewrite: замена блока целиком
Код не пишет. В каждой итерации:
1. Verify на последней версии кода с доски.
2. Обновить Signature.
3. Маршрут:
- локальная ошибка, строка ясна → Repairer
- неясная / про зависимости / повторяется → Analyzer, затем Repairer
4. После правки снова Verify:
- состояние изменилось → серия = 0
- не изменилось → новый диагноз от Analyzer
- серия = {порог_застоя} → откат к снимку до застоя + новый диагноз
5. Done только когда проходят обе проверки.
6. Стоп при {макс_итераций} итерациях.
ErrorTriage + ContextScan → причина каждой ошибки → запись в Report. Код не меняет.
Берёт диагноз из Report. Ошибок больше {порог_переписывания} → Rewrite, иначе Patch.
Запрещено удалять проверяемый код, чтобы пройти проверку.
Начни с Orchestrator.
Что подставлять:
- {файл_или_артефакт}: конфиг, SQL-запрос, скрипт, политика.
- Команды проверки: то, что даёт чёткий вердикт («прошло» или «упало»).
- {порог_застоя}: обычно 2–3.
- {макс_итераций}: 10–20.
- {порог_переписывания}: в статье 10.
🚀 Быстрый старт — вставь в чат или в агента:
Вот шаблон протокола ремонта RegoMender (Orchestrator, Analyzer, Repairer + доска + откат при застое).
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, чем проверять результат (команды, тесты), где хранить снимки и какие инструменты есть у агента. Метод держится на внешнем вердикте и откате: без них цикл не замкнётся. Она возьмёт паттерн из шаблона и подстроит под твой стек.
Ограничения
⚠️ Нужна внешняя проверка: метод построен вокруг инструмента с чётким вердиктом (линтер, компилятор, тесты). Для текстов, стратегий, креатива, где «правильно» нельзя проверить командой, он не годится.
⚠️ Нужны инструменты: в оригинале вызовы Verify, Context Scan и других реализованы программно (дерево разбора кода, граф зависимостей). В чате без терминала цикл придётся вести руками. Агент с терминалом справится, но в статье такой перенос не проверяли: это адаптация.
⚠️ Узкая область: основная проверка проведена на Rego, языке политик. Перенос на HCL и SQL показан, но на обычные языки вроде Python или JavaScript и на длинные многофайловые проекты оценки нет. Набор тестов брал только исправления в одном файле.
⚠️ Промптов нет в доступной части: текст статьи обрезан, самих системных промптов агентов нет. Структура описана словами, поэтому шаблон выше — реконструкция по описанию, а не копия оригинала.
⚠️ Цена: три роли и повторные проверки дороже одного запроса. Для простых однострочных ошибок оверхед не окупается.
Как исследовали
Сначала авторам пришлось собрать тестовый набор: для ремонта Rego его не существовало. Они взяли 2 847 репозиториев на GitHub и вытащили 54 821 правку. Правки отфильтровали: убрали косметику и случаи, где разработчик просто удалил код, чтобы пройти проверку. Остались только исправления в одном файле, которые воспроизводятся. В итоге набралось 1 159 реальных ошибок семи типов. Три опытных разработчика разметили их по сложности, согласованность оказалась очень высокой. Почти 60% случаев — «цепочки»: починил одну ошибку, и вылезла другая.
RegoMender сравнили с четырьмя существующими методами автоматического ремонта кода. Он добился 82,9% синтаксического и 77,9% смыслового успеха (по тестам), то есть на 13,4% лучше сильнейшего конкурента. Он занял первое место по всем семи типам ошибок. Устойчивость на цепочечных ремонтах удивила: у других методов результат на сложных случаях падал, а у RegoMender почти нет.
Затем авторы по очереди убирали инструменты. Самый сильный удар по качеству дало отключение Context Scan. Вывод для практики: починка кода держится на контексте, а не на «умности» модели. Они проверили метод на HCL и SQL, где он тоже обогнал конкурентов, и на 132 реальных уязвимостях (CVE), где починил 86,4%. Лучший баланс цены и качества дала модель DeepSeek-V3.1-Terminus.
Адаптации и экстраполяции
🔧 Техника: добавить обязательный первый шаг «собери контекст» → меньше слепых правок
Перед любой правкой в Repairer добавь в промпт:
Перед правкой перечисли переменные, импорты и связанные блоки вокруг строки с ошибкой. Только потом меняй.Ablation в статье показывает, что именно этот шаг даёт наибольший вклад.
🔧 Техника: показывать журнал → видеть, где зациклился
Добавь в Orchestrator:
После каждой итерации печатай одну строку: номер, роль, сигнатура до → после, решение.Так застой виден сразу, а не после десятого круга.
Экстраполяция — тот же каркас для тестов в проекте на Python:
Задача: починить падающие тесты в {папка}. Проверка: `pytest -x`.
Роли и доска — как в протоколе выше. Новое правило для Repairer:
нельзя менять или удалять сами тесты, чтобы они прошли.
Порог застоя — 2 прогона подряд с тем же падающим тестом → откат (git reset к снимку).
Ресурсы
- RegoMender: A Multi-agent Framework for Automated Rego Policy Repair (ASE '26, Мюнхен)
- Авторы: Ruijie Zhang, Huaxiao Yin, Li Hu, Fanqi Kong, Haozhe Liang, Shaoyin Cheng, Kun Zhang, Bibo Tu
- Институты: Institute of Information Engineering (CAS), University of Chinese Academy of Sciences, USTC, Peking University
- Упомянуто в работе: RegoBench (1 159 исправлений Rego), Open Policy Agent (OPA), сравнения с ThinkRepair и RepairAgent
- DOI: https://doi.org/10.1145/3832783.3837490