Детерминированность ответа не гарантирует одинаковую правку агента при повторном запуске

Что должно совпасть при повторе? Текст ответа, изменения файлов и работа программы отвечают на разные вопросы. Отчёт агента описывает результат, но не заменяет его.

Детерминированный ответ воспроизводится при одинаковом полном входе. У агента в этот вход попадают и прочитанные файлы, и ответы инструментов.

Разные правки могут пройти одинаковые проверки. Одинаковые правки могут одинаково неверно считать скидку. Это пример различия свойств, не замер нашего продукта.

В документации Anthropic даже temperature 0 не гарантирует одинакового ответа API. В примере OpenAI с seed от 06.11.2023 обещание тоже ограничено.

Почему одинаковый запрос даёт разные правки? Агент получает новые сведения по ходу работы. Другой стартовый код или ответ команды меняет вход следующего обращения к модели.

Сохраняйте задачу для агента с исходной версией проекта. После первой правки код уже другой; независимым попыткам нужен тот же чистый старт.

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

Что показывают три прогона РуБенча? В раунде 2 каждая из 25 задачполучила три независимых захода. Скрытый тест автора починки принимал результат каждого захода.

Скрытый тест оценивает починку задачи. Он не требует одинакового текста ответа или способа исправления. Три зачёта могли бы получиться на разных правках.

Разброс зачёта не равен частоте изменения файлов. Нового эксперимента с неизменным полным входом мы для статьи не проводили. РуБенч показывает исходы в своём протоколе.

У Opus 4.8 преимущество перед Sonnet 5 составляет 4 процентных пункта, а разброс равен ±6,1 пункта. Такого сравнения средних мало, чтобы выбирать инструмент для компании.

Среднее не расскажет, какие задачи проваливались. Для пилота нужны результаты каждой попытки по задачам вашей компании. Общий рейтинг этого не заменяет.

Это урок выбора, а не обещание нашей подписки. Ни процент зачёта, ни число прогонов РуБенча не предсказывают результат на репозитории клиента.

Если результат повторился, можно ли его принять? Совпадение показывает устойчивость к повтору в данных условиях. Правильность задаёт отдельное требование к результату.

Проверяющая модель тоже меняет трактовку правила. У нас вычислимую пунктуацию отдали обычному коду; между прогонами приёмки текст редактировали.

Инженер ведёт машину агентов на сайте; ход работы виден в открытом журнале работы. Истории поломок объясняют наши правила проверки. Они не превращаются в клиентский кейс.

Подмена модели в июльском раунде повторялась при повторе задачи. Такая повторяемость не делала выбранное имя модели верным. Кадр показывает именно это историческое расхождение.

Одного «готово» мало, чтобы восстановить причину расхождения. Сохраняйте ответы инструментов и след действий: неодинаковый diff ещё не диагноз.

Сохраните подготовленный код и повторите его проверки на тех же данных. Новый вызов агента создаёт нового кандидата, а не воспроизводит приёмку старого.

Учебный пример: цена 1 000 ₽, скидка 10 %, итог 900 ₽. Проверка должна отвергать исходные 1 000 ₽; два одинаковых неверных итога не доказывают правильность.

Если та же программа даёт разные результаты, разберите её зависимость от времени, данных и внешних ответов. Менять промпт в этот момент рано.

От исполнителя нужны исходная задача, правка от согласованной версии и результаты проверок. Совпадение переписки не служит критерием готовности.

Зафиксируйте ответственность за ошибку до приёмки. Кто принимает версию, разбирает сбой и возвращает предыдущий код? Ответ модели этого не решает.

Роль руководителя разработки здесь состоит в выборе критериев. Проверяющий сверяет код с исходной задачей; новое требование сохраняет её следующей версией.

Если цикл уже ведёт ваша команда, сравнивайте кандидатов по её проверкам. Если вести его некому, следующий шаг можно обсудить с исполнителем.

В подписке «Один проект» цена составляет 250 000 ₽ в месяц, один поток работы. Тариф проверен 08.10.2026.

Для первой задачи согласуйте сдачу запускаемого кода и проверок с сохранением исходного задания. Одинаковые слова модели не заменяют этот результат.

1. Назовите предмет сравнения: текст ответа, изменение файлов или поведение программы.

2. Для сравнения попыток сохраняйте одинаковую базовую версию, задачу и условия запуска.

3. Принимайте сохранённый код по проверкам, которые обнаруживали исходную ошибку.

4. Повторяйте исполнение проверки; новую генерацию оценивайте как нового кандидата.

5. Совпадение не доказывает правильность. При расхождении сохраняйте след запуска и разбирайте причину.