# Как воспроизвести сбой программирующего агента на разных версиях модели? > Сохраните весь запуск как версионируемый тестовый fixture, а затем повторите один и тот же промпт, commit, контракт инструментов, среду и правила остановки на закрепленных ID моделей. Сравнивайте структурированные события и итоговое состояние репозитория, а не только текст агента. # Как воспроизвести сбой программирующего агента на разных версиях модели? Полезное воспроизведение является исполняемым экспериментом, а не копией переписки. Начните с состояния репозитория, в котором произошел сбой, зафиксируйте все доступные агенту входы и определите сбой машинно проверяемым утверждением. Затем несколько раз повторите fixture на закрепленных версиях модели. Запуск агента сочетает модель, инструменты, файлы, сеть, оркестрацию и время. Если меняется хотя бы один элемент, другой результат не доказывает, что модель вызвала или исправила проблему. ## Определить сбой как проверяемое условие Запишите минимальное наблюдаемое условие, отличающее сбой от успеха: тест остается красным, изменен неожиданный файл, выполнена запрещенная команда, пропущена миграция или patch компилируется, но меняет поведение. Избегайте критериев вроде «ответ выглядит хуже». Для исправления можно потребовать: * исходный регрессионный тест проходит; * все существующие тесты продолжают проходить; * файлы вне разрешенного списка не меняются; * агент останавливается в пределах заданного числа вызовов; * финальный diff не содержит сгенерированных секретов или случайного изменения lockfile. ## Сохранить полную оболочку запуска Промпт является лишь одним входом. Сохраните вместе с fixture: | Слой | Что фиксировать | Почему это меняет результат | |---|---|---| | Репозиторий | Commit, submodule, незакоммиченный patch, неотслеживаемые файлы | Агент работает с точным состоянием кода | | Инструкции | Системный промпт, правила, задача пользователя | Небольшая формулировка меняет план | | Модель | Провайдер, неизменяемый ID, параметры | Алиасы и значения по умолчанию меняются | | Инструменты | Имена, JSON schema, разрешения, timeout | Доступные возможности формируют план | | Среда | Образ, ОС, архитектура, lock-файлы | Команды и тесты могут вести себя иначе | | Внешние данные | Смоделированный HTTP, часы, случайные входы | Живые сервисы создают дрейф | | Оркестратор | Лимит циклов, повторы, сжатие контекста | Та же модель может получить другую историю | Удалите секретные значения, но сохраните факт наличия и область учетных данных. ## Записывать структурированные события, а не только текст Сохраняйте каждый запрос и ответ модели, вызов и результат инструмента, повтор и решение об остановке как упорядоченное событие. Для больших результатов добавляйте hash, а исходный артефакт храните отдельно. ```json { "run_id": "agent-regression-042", "fixture": "sha256:...", "model": "provider/model-version", "event": "tool_result", "tool": "run_tests", "exit_code": 1, "stdout_sha256": "..." } ``` Так видно, выбрала ли новая модель другой инструмент, иначе поняла ту же ошибку или получила другие доказательства. ## Зафиксировать версии и убрать живую вариативность Используйте датированные или неизменяемые ID. Не сравнивайте исторический сбой с `latest`, который уже может указывать на другую сборку. Запускайте в чистом контейнере или VM. Замените живой поиск и меняющиеся реестры пакетов записанными ответами или внутренними snapshots. Зафиксируйте часы, если важна дата. Если сеть обязательна, запишите каждый ответ и обозначьте тест как частично контролируемый. Seed помогает, но не фиксирует распределенный inference, время инструментов и изменения провайдера. ## Воспроизводить матрицу, а не одну пару Один запуск на версию не отличает регрессию от вариативности. Сохраняйте fixture неизменным: | Версия модели | Повторы | Доля успеха | Медиана вызовов | Сигнатура сбоя | |---|---:|---:|---:|---| | Закрепленный baseline ID | 5 | 4/5 | 9 | Пропущен граничный тест | | Закрепленный candidate ID | 5 | 1/5 | 13 | Изменен сгенерированный файл | | Candidate со старым промптом | 5 | 1/5 | 12 | Та же сигнатура | Пять повторов являются полезным началом. Увеличьте выборку для непостоянных или критичных сбоев. Держите temperature и другие параметры одинаковыми, если они сами не тестируются. ## Сравнивать решения и состояние репозитория отдельно Сравнивайте отдельные уровни: * нормализованные события модели и инструментов; * команды и коды выхода; * итоговое дерево файлов и patch; * приемочные тесты и ресурсы. Текст рассуждения не обязан совпадать. Разные пути могут дать эквивалентные правильные изменения, а похожий текст может скрывать существенную разницу команд. ## Минимизировать fixture после воспроизведения После устойчивого повтора удаляйте по одному несвязанные файлы, инструменты, абзацы промпта и внешние вызовы. Малый fixture работает быстрее и лучше показывает причинную границу. Сохраните полный повтор инцидента для аудита и минимальный регрессионный тест для постоянной оценки. Добавьте минимальный случай в проверку обновлений модели. ## Использовать переносимый адаптер модели Шлюз вроде Atlas Cloud может скрыть несколько моделей за OpenAI-совместимым клиентом, но совместимость не означает одинаковое поведение. ID и специальные настройки храните в адаптерах; общий стенд управляет fixtures, событиями, повторами и проверками. Так одно воспроизведение работает у разных провайдеров без переписывания оценки. ## Итог Зафиксируйте оболочку запуска, несколько раз повторите закрепленные модели и оценивайте исполняемый результат. Если все условия инцидента воспроизвести нельзя, укажите оставшиеся живые входы и называйте результат сравнительным исследованием, а не доказательством регрессии модели. ## FAQ ### Что нужно сохранить для воспроизведения сбоя агента? Сохраните commit и незакоммиченный patch, промпты и системные инструкции, ID и параметры модели, схемы и результаты инструментов, образ среды, lock-файлы, политики учетных данных и сети, а также точное условие успеха. ### Следует ли повторять сбой с алиасом latest? Нет. Используйте неизменяемые или датированные ID. Алиас latest может измениться во время теста и не позволит правильно связать успех или сбой с версией. ### Почему фиксированного случайного seed недостаточно? Seed не фиксирует инфраструктуру провайдера, время работы инструментов, результаты поиска и ревизии модели. Это лишь один контроль, а не гарантия детерминизма. ### Какой критерий успеха лучше для программирующего агента? Используйте исполняемые проверки: тесты, lint, ожидаемый diff файлов, запрет изменения файлов и коды выхода. Сходство текста обычно недостаточно для задач программирования. ### Сколько повторов нужно для каждой версии? Столько, чтобы отделить детерминированную регрессию от вариативности. Пять запусков являются практичной начальной выборкой, а критичные сбои могут потребовать двадцати и более. ### Можно ли одним стендом сравнивать модели разных провайдеров? Да, если нормализовать запрос, контракт инструментов, журнал событий и проверки результата, а специфические настройки вынести в адаптеры.