ExploreRepair: три независимых агента-специалиста и двухступенчатая сборка вместо одного «универсального» агента

ФАЗА 1 — Исследование (3 агента, независимо, не видят друг друга)
  Агент СТРУКТУРА: как внешний ввод доходит до функции, валидаторы, похожие пути → диагноз + патч
  Агент НАМЕРЕНИЕ: 4 вопроса о контракте и доверии, до 5 ограничений → диагноз + патч
  Агент PoV:       написать тест-воспроизведение, запустить, чинить причину → диагноз + патч

ФАЗА 2 — Сборка
  ШАГ 1: отдельный вызов LLM сжимает траекторию + патч каждого агента → короткий «урок»
  ШАГ 2 (параллельно):
     Сборщик уроков  ← 3 урока   → патч A
     Сборщик патчей  ← 3 диффа   → патч B
  ШАГ 3: сжать работу обоих сборщиков в уроки
  ШАГ 4: Финальный сборщик ← патч A + патч B + их уроки
         → сверяет с кодом → берёт один / объединяет / отвергает общие допущения / пишет новый

Шаги требуют отдельных запросов или сессий. В одном промпте это не соберёшь.

Задача: Вы ведёте бэкенд на Python для сервиса доставки: интернет-магазин с выгрузкой накладных клиентам. Сканер зависимостей и аудит указали на функцию download_invoice(): возможен path traversal (выход за пределы папки через ../). Описания уязвимости нет, готового эксплойта тоже. Нужен безопасный патч, который не сломает остальное.

Промпт (Агент «Намерение», в отдельной сессии Claude Code или Cursor):

Ты исследуешь уязвимость в репозитории. Подозрительная функция: download_invoice() в services/invoices.py, строки 40–95.
Твоя специализация — реконструкция замысла разработчика. Не пиши код, пока не ответишь на вопросы по порядку:
1. Какая спецификация или контракт API управляет этим кодом?
2. Кто может до него достучаться и кто контролирует входные данные?
3. Какие ресурсы он защищает?
4. Какие ограничения должны выполняться для недоверенных данных?
На основе ответов сформулируй до 5 ограничений безопасности, которые должны соблюдаться.
Каждое утверждение подкрепляй ссылкой «файл:строка». Если репозиторий не даёт достаточно данных — прямо пометь «неизвестно».
Затем найди, где реализация нарушает ограничения, и предложи патч.
Верни: диагноз, список ограничений, неопределённости, патч (diff).

Два других агента получают тот же файл и те же строки, но другую специализацию. Затем запускаются три шага сборки.

Результат: Три независимые сессии вернут три диагноза и три патча с разных сторон: «как ввод доходит до функции», «что было задумано», «вот тест, который воспроизводит выход из папки». Сжатие превратит каждую сессию в короткий урок. Два сборщика выдадут два предложения. Финальный сборщик сверит их с кодом и предложит итоговый diff с пометкой, какие допущения отвергнуты.

Слабость. Когда одному агенту дают сразу все типы данных, он рассуждает хуже. Первое правдоподобное объяснение закрепляется, и дальше агент подгоняет под него всё остальное. Длинный контекст из трёх разных «историй поиска» ещё и путает рассуждение. Если агенты обсуждают задачу вместе, неверный начальный вывод одного заражает остальных.

Сильная сторона. Модель хорошо решает узкую задачу с чёткой рамкой («ответь на эти четыре вопроса», «напиши тест и запусти»). Она хорошо сжимает длинные траектории в короткие итоги. И она неплохо сверяет чужие предложения с реальным кодом, если ей прямо сказать «любое из них может быть ошибочным».

Как метод это использует. Независимость не даёт ошибке одного агента заразить остальных. Узкая специализация даёт каждому свой тип доказательств. Сжатие в «уроки» убирает шум, но патчи остаются отдельно, чтобы не потерять детали вроде «в какое место вставить проверку». Два сборщика видят разное (диагнозы и реализации), а финальный сводит их. Поэтому он может починить то, что не смог ни один специалист.

Рычаги управления: - Состав специалистов. Замени «структуру / намерение / PoV» на углы под свою задачу. Лучше брать разные типы доказательств, а не разные «личности». - Какой специалист сильнее, зависит от модели. В статье у одной модели выигрывал агент по структуре, у другой по намерению. Прогони всех трёх на нескольких своих случаях, не гадай. - Фраза «любое из предложений может быть неверным» держит сборщика критичным. Не убирай её. - Права финального сборщика. Он может принять один вариант, объединить, отвергнуть допущения, общие для обоих, или написать новое. Если сузить это до «выбери лучший», пропадёт случай «все ошиблись». - Запрет читерства у PoV-агента. Не ослаблять свой тест и не чинить под конкретный вход.

Шаблон разбит на роли. Каждая запускается отдельно: три сессии исследования, затем сжатие и сборка.

=== АГЕНТ 1: СТРУКТУРА (отдельная сессия) ===
Исследователь структуры кода

Уязвимость/проблема: {описание_или_алерт}. Место: {файл_и_строки}.
Проследи, как внешний ввод доходит до этой функции (вызывающие функции, импорты).
Найди помощников и валидаторы. Сравни с похожими путями в коде, делающими то же самое.
Проверь, нет ли других мест в репозитории, где нужно такое же исправление
(файлы, которые обычно меняются вместе: {git_история_если_есть}).
Диагностируй проблему и предложи патч.

Диагноз; пути, которые ты проследил; патч (diff)

=== АГЕНТ 2: НАМЕРЕНИЕ (отдельная сессия) ===
Реконструктор замысла разработчика

Место: {файл_и_строки}. Отвечай по порядку, до написания кода:
1. Какая спецификация или контракт API управляет кодом?
2. Кто может до него достучаться и контролировать вход?
3. Какие ресурсы он защищает?
4. Какие ограничения должны выполняться для недоверенных данных?
Сформулируй до 5 ограничений безопасности. Каждое утверждение — со ссылкой «файл:строка».
Если данных не хватает — пиши «неизвестно».
Найди, где реализация нарушает ограничения, и предложи патч.

Ограничения; неопределённости; диагноз; патч (diff)

=== АГЕНТ 3: PoV (отдельная сессия) ===
Исследователь через воспроизведение

Место: {файл_и_строки}. Проследи ввод атакующего от публичной точки входа ({API/CLI/эндпоинт}) до этого кода.
Напиши тест, который демонстрирует нарушение, и запусти его на текущем коде.
Дорабатывай тест, пока он не покажет именно подозреваемое нарушение.
Затем исправь первопричину в рабочем коде и перезапусти тот же тест.


- Нельзя ослаблять тест, чтобы он прошёл.
- Нельзя делать исправление под конкретный вход из теста.
- Чини причину, а не симптом.

Что показал запуск; диагноз; патч (diff)

=== СЖАТИЕ (для каждой из трёх сессий) ===
Сожми ход работы и патч агента «{роль}» в короткий урок:
подозреваемая уязвимость; подтверждающие места в коде или результаты запуска; предложенное изменение; нерешённые утверждения.
Акцент по роли: {структура: пути и места правки | намерение: ожидаемое поведение и границы доверия | PoV: наблюдаемое нарушение и эффект патча}.

=== СБОРЩИК УРОКОВ ===
Вот три урока: {урок_1}, {урок_2}, {урок_3}.
Собери исправление на основе диагнозов. Любой из уроков может быть ошибочным — проверяй по коду репозитория.

=== СБОРЩИК ПАТЧЕЙ (отдельная сессия, параллельно) ===
Вот три патча: {diff_1}, {diff_2}, {diff_3}.
Собери исправление на основе реализаций. Любой из патчей может быть ошибочным — проверяй по коду репозитория.

=== ФИНАЛЬНЫЙ СБОРЩИК ===
Вот два предложения: патч A + его урок: {A}; патч B + его урок: {B}.
Проверь их утверждения по репозиторию. Ты можешь: принять один, объединить совместимые изменения,
отвергнуть допущения, общие для обоих, или написать новый патч.
Верни итоговый патч и кратко: что принял, что отверг, почему.

Подставляйте: описание проблемы, файл и строки (подсказка, где искать, нужна всегда), точку входа атакующего, если известна, и результаты предыдущих шагов вместо {урок_N}, {diff_N}.

🚀 Быстрый старт — вставь в чат:

Вот шаблон ExploreRepair. Адаптируй под мою задачу: [опиши баг/уязвимость и стек].
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит, где в коде проблема, какая точка входа у пользователя, есть ли тесты и как их запускать. Это нужно, чтобы каждый из трёх агентов получил свою рамку и чтобы PoV-агент смог проверить гипотезу запуском.

⚠️ Узкая задача: метод проверен только на исправлении уязвимостей в коде с готовой подсказкой, где искать. Перенос на другие баги и другие задачи — ваша догадка, статья его не проверяла.

⚠️ Цена: три полные сессии агентов, затем сжатие и три шага сборки. Это в разы больше токенов и времени, чем у одного агента. Для простых багов не окупается.

⚠️ Выигрыш от последнего шага невелик: финальная сборка добавила лишь одну-четыре уязвимости к лучшему из отдельных сборщиков. Основной прирост даёт связка «независимые специалисты + любая разумная сборка».

⚠️ Нужна проверка запуском: исход в статье мерили тестами. Без тестов вы не узнаете, какой патч «успешный», и можно получить уверенный, но неправильный итог.

⚠️ Инженерная часть: граф кода и поиск по эмбеддингам авторы написали кодом. В обычном агенте их заменяют обычный поиск по коду и чтение файлов, но точный эффект такой замены не проверен.

⚠️ Не универсальный лучший специалист: какой из трёх агентов сильнее, зависит от модели. Заранее выбрать одного нельзя.

⚠️ Текст усечён: часть раздела об агрегаторах и приложения с оригинальными промптами в доступном материале отсутствуют. Шаблон выше составлен по описанию в тексте статьи.

Команда взяла 169 реальных уязвимостей на Python, JavaScript и Go из PatchEval и 35 на C/C++ из VulnLoc+. Агенту дали только репозиторий и подсказку, где искать. Описание уязвимости, тип слабости и готовый эксплойт были спрятаны. Успехом считали патч, который проходит тест на эксплойт и не ломает тесты проекта.

Сравнивали с одним агентом, с обычным «много субагентов», с современным агентом Codex и с лучшими на тот момент методами. Главный контроль: «3-в-1», один агент со всеми тремя инструментами сразу. Он оказался слабее каждого специалиста. Метод показал около 40% и около 72% успешных починок на двух моделях. Одиночный агент дал около 33% и 57%. Это прирост примерно в 7 и 14 процентных пунктов. Над одним из прежних лучших методов, EvoRepair, разрыв составил 16 и 25 пунктов.

Любопытные детали: - Самый сильный специалист на одной модели оказался не самым сильным на другой. Универсального «лучшего угла» нет. - Обычная многоагентная схема без специализации оказалась хуже одиночного агента. - На 11 уязвимостях (с одной моделью) и 3 (с другой) итоговая сборка сработала там, где ни один из трёх специалистов не справился. Информация из неудачных попыток сложилась в рабочий патч.

Вывод для практики: ценность в разнообразии доказательств и независимости, а не в числе агентов.

💡 Адаптация для разбора причин инцидента (не проверено в статье): тот же принцип «независимые специалисты по типам доказательств» можно применить к расследованию, например падения конверсии на сайте. Три отдельных чата: «логи и метрики по воронке», «что менялось в продукте и по каким причинам» (аналог намерения), «воспроизведи сбой руками на тестовом аккаунте» (аналог PoV). Потом четвёртый чат сводит три итога с инструкцией «любой вывод может быть неверным, проверь по данным».

🔧 Техника: убрать общий контекст → меньше заражения ошибкой. Не показывайте агентам выводы друг друга до сборки. Если дать второму агенту диагноз первого, он, скорее всего, подтянется к нему.

🔧 Техника: сборщику разрешить «ничего из этого не годится» → ловит общие ошибки. В шаблоне финальный сборщик может отвергнуть допущения, общие для обоих предложений. Это возможность, которую легко забыть и тем самым потерять самый ценный случай.

• Название работы: ExploreRepair: Evidence-Specialized Agents for Vulnerability Repair under Information Constraints
• Авторы: Duc Manh Tran, Ratnadira Widyasari, Ivana Clairine Irsan, Huihui Huang, Ting Zhang, David Lo, Rahul Gopinath, Hong Jin Kang
• Университеты: University of Sydney, University of Victoria, Singapore Management University, Monash University
• Бенчмарки: PatchEval (Wei et al., 2025), VulnLoc+ (Ye et al., 2026)
• Связанные методы: IntentFix (Heo et al., 2026) — источник четырёх вопросов про намерение; EvoRepair (Hu et al., 2026); LoopRepair (Ye et al., 2026); ContraFix (Liu et al., 2026)
• Ссылок на код или сайт в доступном тексте нет.