SWE-Exp: как агент переносит опыт исправления ошибок
Агент однажды нашёл причину ошибки, исправил её и прошёл проверки. Через неделю он сталкивается с похожим симптомом в другом проекте. Что стоит перенести из первой работы: весь разговор, готовую правку или способ искать причину? Разберём это различие на SWE-Exp и условной истории с повторяющимися заявками.
Стрелки показывают, откуда берётся следующий шаг. Условия и ограничения разобраны в статье.
SWE-Exp — работа Silin Chen и соавторов Experience-Driven Software Issue Resolution. Здесь рассматривается редакция v2 от 2 февраля 2026 года; первая появилась 31 июля 2025 года. Ниже кратко изложен механизм, затем предложены самостоятельный пример и проверки. Это авторский разбор исследования, без собственной репликации его экспериментов.
От истории действий к подсказке
Агент разработки читает код, запускает инструменты и меняет файлы. Последовательность его действий вместе с ответами среды называют траекторией. В SWE-Exp прошлые успешные и неудачные траектории становятся сырьём для банка опыта. Система извлекает понимание проблемы и обобщённые стратегии правки; тип ошибки и описание помогают искать подходящую запись. Затем модель отбирает полезный опыт и приспосабливает его к новой задаче. Эта последовательность описана в официальном репозитории проекта.
В описанном авторами сборе данных успешность правки размечают с опорой на эталонное решение; затем отдельный агент извлекает опыт из успешных и неудачных попыток. Поэтому источник метки успеха здесь — проверка относительно эталона, а не только оценка модели.
В §3.3–3.4 статьи различены две категории опыта: понимание проблемы и изменение кода. Планирующий агент Instructor задаёт направление, Assistant выполняет конкретные операции. Работа построена поверх поиска по дереву Монте-Карло (MCTS): система рассматривает альтернативные цепочки действий. Память влияет на выбор шагов; извлечённая запись не становится доказательством правильности новой правки.
Для читателя здесь полезно различать два вопроса: «Что я мог упустить при диагностике?» и «Как безопаснее изменить уже найденное место?». Один и тот же текст не обязательно одинаково хорошо отвечает на оба.
Условный пример: заявка появилась дважды
Представим сервис импорта заявок со склада. Оператор загружает файл, интерфейс долго ждёт ответа и сообщает об ошибке соединения. Оператор повторяет загрузку. В базе появляются два экземпляра каждой заявки. Это вымышленный пример, придуманный для этого разбора.
Первая попытка агента ограничивает повторное нажатие кнопки. Проверка на обычном соединении проходит, но при обрыве связи дубликаты возвращаются. Вторая попытка исследует момент сохранения: сервер успел записать строки, а ответ до клиента не дошёл. Повторная отправка создаёт их снова.
Для этого сервиса команда вводит идентификатор операции и сохраняет результат обработки. Повтор с тем же идентификатором возвращает уже известный результат. Такое свойство называют идемпотентностью: повторное выполнение операции не добавляет нового эффекта. В нашем примере оно относится к одной операции импорта, а не ко всем похожим файлам вообще.
Из этой истории можно вынести разные записи. «При дубликатах отключай кнопку» закрепляет первую неудачную попытку. «Всегда добавляй идентификатор» превращает частное решение в слишком широкую команду. Полезнее сохранить диагностическое различие: отсутствие ответа ещё не показывает, что действие на сервере не произошло.
Следующая таблица — мой вариант разбора опыта этой условной команды, а не формат данных SWE-Exp.
| Что сохраняем | Содержание записи | Что потребуется проверить в новом проекте |
|---|---|---|
| Наблюдение | Ответ потерян после сохранения заявок | Есть ли свидетельство, что первая операция завершилась |
| Неудачный путь | Блокировка кнопки не устранила повтор после сетевой ошибки | Где возникает повтор: в интерфейсе, очереди или сервере |
| Диагностическая подсказка | Разделить результат операции и доставку ответа | Можно ли проследить одну операцию через все этапы |
| Стратегия правки | Повтор с тем же идентификатором использует прежний результат | Что считается той же операцией и где хранится её результат |
| Граница | Проверены повторы одного импорта | Должны ли два независимых импорта оставаться разными |
Запись сохраняет рассуждение вместе с границей. Это даёт следующему агенту возможность проверить сходство, а не только узнать знакомый симптом.
Похожий симптом ещё не означает прежнюю причину
Теперь в другом сервисе дублируются уведомления о готовности заказа. Банк опыта может подсказать проверить повтор после потери ответа. Агент добавляет эту гипотезу к диагностике и смотрит журнал событий.
Однако предположим, что событие создано один раз, а обработчик зарегистрирован дважды при запуске приложения. Идентификатор операции мог бы замаскировать повтор, но не объяснил бы лишнюю регистрацию. Если агент продолжает искать сетевую ошибку вопреки журналу, память уже направляет работу по неверному пути.
В нашем сценарии разумная последовательность начинается с наблюдаемого различия: сколько событий создано и сколько обработчиков их получили. Затем проверяется способ запуска приложения. Только после этого выбирается место правки. Старый опыт оказался полезен как первая проверяемая гипотеза; результаты новой проверки ограничили его применение.
Отсюда мой практический вывод: возле извлечённой рекомендации полезно задавать вопрос «Какое наблюдение заставит меня от неё отказаться?». Ответ должен быть конкретным. Здесь это единственное созданное событие при двух вызовах обработчика. Формулировка «проверить, подходит ли опыт» слишком расплывчата для управления дальнейшим действием.
Что показывает эксперимент
В таблице 1 авторы сообщают 73,0% решённых задач SWE-bench Verified для SWE-Exp с Claude 4 Sonnet против 70,8% у SWE-Search с той же моделью. Набор содержит 500 задач; оценка касается исправления ошибок в проектах на языке Python. Один оцениваемый результат может потребовать многих внутренних действий и вариантов правки.
Сами авторы признают риск неуместного переноса опыта и отсутствие достаточно надёжной проверки его применимости в новом контексте (§6.4–7). Поэтому эти результаты не определяют ожидаемый выигрыш для нашего сервиса заявок.
Для собственного выбора я дополнительно проверил бы состав памяти относительно тестовых задач, правила доступа к эталонным решениям и полный бюджет подготовки опыта. Сравнение готового банка с агентом, которому не дали ни дополнительных примеров, ни времени на их обработку, отвечает только на часть инженерного вопроса. Команде ещё важно понять стоимость получения и поддержки этого банка.
Как проверить пользу на своих ошибках
Для условной команды я предложил бы небольшую проверку на задачах, отложенных до подготовки памяти. Это собственный план испытания, не протокол из статьи.
Сначала зафиксировать версию модели, набор инструментов и лимиты работы. Затем дать одной конфигурации доступ к банку опыта, другой — тот же рабочий контекст без банка. Оценивать итоговые изменения одинаковыми проверками. Отдельно учитывать расходы на извлечение, поиск и применение записей: быстрый ремонт может опираться на дорогую подготовку.
Набор должен содержать разные отношения между прошлым и настоящим:
- Та же причина, другой интерфейс. Повторная отправка снова создаёт записи после потери ответа. Проверяем, помогла ли память быстрее установить последовательность событий.
- Тот же симптом, другая причина. Уведомление обработано дважды из-за регистрации обработчика. Проверяем, способен ли агент отказаться от прежней гипотезы.
- Похожая операция, другой смысл повтора. Два отдельных импорта одинакового файла должны сохраняться раздельно. Проверяем, не запретила ли правка допустимое действие.
- Противоречивые воспоминания. Одна запись советует повторять запрос, другая предупреждает о дубликатах. Проверяем, уточняет ли агент условия вместо механического объединения советов.
Результатом такой пробы станет список конкретных изменений поведения: какую гипотезу агент проверил раньше, где отказался от подсказки, какую ошибку принёс из памяти. Только после этого имеет смысл решать, расширять ли банк и какие записи требуют исправления.
SWE-Exp даёт повод рассматривать опыт ремонта как отдельный рабочий материал. В нашей истории его ценность проявляется в проверяемом переходе от старого наблюдения к новой диагностике. Начать можно с одного завершённого исправления и вопроса: что из него поможет увидеть причину следующей ошибки, сохранив возможность обнаружить другую?
Термины
- Траектория — последовательность действий агента и полученных от среды результатов.
- Банк опыта — сохранённые выводы из прошлых попыток, доступные при решении новых задач.
- Поиск по дереву Монте-Карло (MCTS) — способ выбирать дальнейшие действия, рассматривая альтернативные пути решения.
- Идемпотентность — свойство операции сохранять тот же эффект при её повторном выполнении.
- SWE-bench Verified — проверенный людьми набор задач исправления ошибок в программных проектах.
Источники
- Silin Chen, Shaoxin Lin, Yuling Shi, Heng Lian, Xiaodong Gu, Longfei Yun, Dong Chen, Lin Cao, Jiyang Liu, Nu Xia, Qianxiang Wang. SWE-Exp: Experience-Driven Software Issue Resolution, arXiv:2507.23361v2, 2 февраля 2026 года. Основной источник: §3 — механизм, §4–5 — оценка, §6–7 — ограничения.
- Официальный репозиторий SWE-Exp. Проверен 16 октября 2026 года; описание этапов сбора, извлечения, выбора и использования опыта. Код и эксперименты самостоятельно не запускались.
Все материалы по теме: «Организационная и агентская память».
Хотите внедрить это у себя?
Помогаю командам перейти на агентную разработку: как советник, через обучение команды или внедрение изменений с проверкой эффекта по данным. Короткие заметки между статьями выходят в Telegram-канале.