Унифицированный подход к отладке с помощью многоагентной синергии на основе LLM: проверка исправления

Унифицированный подход к отладке посредством взаимодействия нескольких агентов на основе LLM полезен только тогда, когда его агенты оставляют доказательства, которые переживают их собственный разговор. Локализатор может звучать уверенно, ремонтник может выпустить исправление, а рецензент может одобрить его, в то время как первоначальный сбой никогда не был воспроизведен или решающий граничный случай никогда не проверялся. Поэтому разумным решением по умолчанию является следующее: позвольте специализированным агентам предлагать и оспаривать исправление, но продвигайте исправление только после того, как связанная квитанция подтвердит воспроизводство, происхождение, тестовое покрытие, качество оракула и проверку. Это правило соответствует архитектуре документа FixAgent, не путая результаты исследований с гарантией производства. В статье локализация ошибок, генерация исправлений и анализ после ошибок разделены между специализированными агентами. Он также отличает правдоподобное исправление, которое проходит доступные тесты, от правильного исправления, установленного посредством ручной проверки. Это различие является границей здоровья. Что доказывает результат FixAgent, а что нет Опубликованный проект FixAgent более конкретен, чем «попросить несколько моделей отладить». Его методология использует локализатор, средство восстановления и ревизор, а также агент обработки входных данных для дополнительных тестов. Агенты объясняют свои рассуждения, отслеживают важные переменные и передают результаты предыдущего этапа ниже по потоку. Если сгенерированное исправление окажется неудачным, этап восстановления можно будет протестировать еще раз с помощью обратной связи по тестированию. В документе сообщается о сильных результатах по QuixBugs, Codeflaws и ConDefects. Это результаты исследований по наборам данных, моделям, подсказкам и процедуре проверки. Они не устанавливают, что произвольный патч репозитория можно безопасно объединить. Две детали из первоисточника меняют оперативное решение: 1. В документе правдоподобный патч определяется как патч, который проходит тесты, написанные человеком, а корректность требует отдельной ручной проверки. 2. В разделе ограничений говорится, что дополнительный агент тестового ввода не может самостоятельно рассчитать ожидаемые выходные данные. Сгенерированные входные данные без заслуживающего доверия оракула не являются полным тестом. Выпущенная реализация Rudra делает границу доступной для проверки. Его многораундовый запуск рассматривает нулевые наблюдаемые случаи сбоя как успешный ремонт и возвращает этот флаг в средство запуска. Это подходит для тестового цикла эксперимента. Оператору по прежнему необходимо спрашивать, какие пакеты запускались, заслуживает ли их оракул доверия, принадлежит ли результат этому патчу и принял ли рецензент фактические различия. Урок не в том, что проверка агента бесполезна. Разногласия специалистов могут выявить плохую локализацию или слабый патч. Урок заключается в том, что текст одного агента не должен быть единственным доказательством, потребляемым другим. Свяжите каждый этап отладки с квитанцией о ремонте Квитанция о минимальном ремонте может не содержать содержания. Ему не нужны подсказки, исходный код, выходные данные теста или обоснование модели. Ему нужны стабильные личности и вердикты, которые позволят человеческим или детерминированным воротам восстановить границу: Граница Минимальные поля квитанции Отказ он ловит Репродукция идентификатор запуска, хеш команды, обнаружен исходный сбой Патч для ошибки, которая так и не была воспроизведена Локализация идентификатор запуска, версия источника, временная метка доказательства Результат локализатора, повторно использованный из другой версии Патч хеш исправления, родительская версия, количество измененных строк Пустой, устаревший или несвязанный ремонт Проверка требуемые идентификаторы пакетов, наблюдаемые идентификаторы пакетов, количество неудачных попыток «Все тесты пройдены», если необходимый пакет никогда не запускался Оракул проверено, неизвестно или оспорено Сгенерированные случаи без заслуживающего доверия ожидаемого результата Обзор одобрено, отклонено или принадлежит ожидание Типовое соглашение ошибочно принимают за полномочия по слиянию Результат заявление о завершении работ и квитанция о назначении Завершенный запуск, исправление которого не было проверено или доставлено Идентификатор запуска особенно важен. Ответ по локализации от run old не должен молчаливо оправдывать установку патча от run 42 . Хэш патча не менее важен: зеленая тестовая запись для одного дифференциала не может быть прикреплена к более поздней повторной выборке. Это обычное происхождение, но в рабочих процессах агентов оно часто теряется, поскольку контекст разговора заставляет соседние сообщения выглядеть связанными. Вот форма, используемая прилагаемым приспособлением: Строки являются идентификаторами, а не сохраненным содержимым. В реальной системе хэши должны вычисляться на основе канонических входных данных и артефактов, а запись теста должна включать версию инструмента, версию конфигурации, время начала, время окончания и происхождение выхода. Секреты, подсказки, содержимое файлов и необработанные аргументы инструмента должны оставаться за пределами квитанции о работоспособности. Переиграйте девять неудобных состояний, прежде чем довериться зеленому Артефакт статьи содержит девять синтетических случаев и классификатор Node.js в порядке приоритета. Запустите его из каталога отчета статьи: Наблюдаемый результат: Случаи намеренно неудобны: UNREPRODUCED останавливает рабочий процесс до того, как уверенное исправление сможет скрыть отсутствующую базовую линию. LOCALIZATION DRIFT перехватывает получение локализатора от другого запуска. NO EFFECTIVE PATCH отклоняет отсутствующий хэш или изменение нулевой строки. TEST GAP сообщает о необходимом пакете интеграции, который никогда не запускался, даже если наблюдаемые пакеты отмечены зеленым цветом. ORACLE UNCERTAIN сохраняет неопределенность, когда сгенерированные входные данные не имеют проверенных ожидаемых выходных данных. REVIEW REJECTED не позволяет технически «зеленому» патчу стать одобренным. WAITING представляет собой законную зависимость только в том случае, если в квитанции указаны владелец и крайний срок. FALSE COMPLETE имеет преимущество перед заявлением о завершении, если какой либо наблюдаемый тест по прежнему не пройден. VERIFIED REPAIR требует согласования всех предыдущих границ. Порядок имеет значение. Заявление о завершении не может переопределить проваленный тест. Счетчик с нулевым сбоем не может переопределить отсутствующий набор. Сгенерированный граничный случай не может установить корректность без оракула. Ожидание проверки не следует классифицировать как стойло, если у него есть владелец и крайний срок. Этот эксперимент также показывает, почему один показатель работоспособности является плохим артефактом отладки. Оба случая suite gap и verified repair сообщают об отсутствии неудачных тестов, однако их рабочие состояния различаются, поскольку необходимый пакет интеграции никогда не запускался. Недостающие доказательства важнее зеленого счетчика. Добавьте шлюз в реальный рабочий процесс агента кодирования Начните с небольших границ продвижения, а не перестраивайте структуру агента: 1. Заморозить входную версию. Перед локализацией запишите фиксацию репозитория или снимок рабочей области. 2. Воспроизведите ошибку. Сохраните хэш команды/конфигурации и структурированный результат. Если воспроизводство нестабильное, отметьте его как неопределенное и не рассматривайте возможный зеленый запуск как доказательство ремонта. 3. Свяжите каждую передачу. Требуйте, чтобы квитанции локализатора, восстановителя и рецензента ссылались на один и тот же запуск и родительскую редакцию. 4. Привязанная повторная выборка. Цикл обратной связи, описанный в документе FixAgent, полезен, но повторные попытки расходуют бюджет и могут изменить патч. Дайте каждому новому патчу свой собственный хэш, ограничьте количество попыток и аннулируйте предыдущие тестовые данные при изменении различий. 5. Объявите необходимые наборы перед выполнением. В противном случае агент может переопределить «все тесты» после просмотра результатов. 6. Отдельное выполнение теста от полномочий оракула. Сгенерированные входные данные могут улучшить охват, но ожидаемый результат должен обеспечивать человек, спецификация, эталонная реализация или независимое детерминированное правило. 7. Держите полномочия по слиянию или развертыванию под контролем человека. Утвержденная квитанция может подготовить решение; оно не должно расширять полномочия агента. 8. Проверьте место назначения. Если задачей было открыть запрос на включение, обновить проблему или создать артефакт выпуска, проверьте это место назначения независимо. Локальное исправление — это действие, а не обязательно желаемый результат. Для приостановки утверждения используйте явную запись: Не отправляйте пейджер просто потому, что агент молчит, пока эта запись актуальна. Обостряйте ситуацию, когда срок истекает, владелец отсутствует или возобновленный запуск не дает новых доказательств. Ожидание не застревает; повторяющаяся деятельность без дельты результата не является прогрессом. Граница для Sidewisp Поддерживаемый тезис узок: многоагентная отладка становится надежной в эксплуатации, когда результаты специалистов присоединяются к детерминированным доказательствам восстановления, а зеленый цвет удерживается, когда отсутствуют данные о происхождении, покрытии, качестве оракула, проверке или результатах. Прибор из девяти случаев опровергает сокращение «ноль наблюдаемых отказов означает проверенный ремонт», поскольку в двух случаях с нулевым отказом выносятся разные вердикты. Это образец работы, а не утверждение, что Sidewisp в настоящее время запускает FixAgent или отслеживает ремонт агента кодирования. Sidewisp сейчас находится на этапе закрытого предварительного доступа. Это платформа работоспособности AI агента, но механизм производственного мониторинга, адаптеры среды выполнения и исполнитель восстановления обычно не поставляются. Предполагаемый уровень здоровья здесь важен, поскольку он различает полезный прогресс, законное ожидание, ложное завершение и неопределенные доказательства, оставляя при этом полномочия слияния с человеком. Сначала используйте квитанцию ​​в одном повторяющемся рабочем процессе отладки. Если он не может отличить отсутствующий комплект от подтвержденного ремонта, не прочитав стенограмму, контракт на доказательства все еще слишком слаб.