Как ИИ-агент за несколько дней собрал играбельный шутер

Когда агенту мало одного прохода

Одна из главных проблем агентов для программирования давно видна всем, кто пробовал поручить им что-то больше функции на 50 строк. На короткой задаче всё выглядит бодро. На длинной — агент быстро запутывается в собственных шагах, чинит одно, ломает другое, теряет из виду исходные требования и слишком рано объявляет работу законченной.

Авторы работы Harness-of-Harness предлагают новую обвязку для долгой автономной разработки. Идея простая: не ждать, что один запуск агента сразу соберёт целый продукт, а заставить его работать циклами — спланировал, написал, проверил, пошёл дальше.

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

Разговор об автономной разработке давно вышел за пределы аккуратных демок. Вопрос уже не в том, умеет ли LLM написать кусок кода. Вопрос в том, может ли она вести проект неделями и не потерять нить.

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

Что такое Harness-of-Harness

Термин в названии сначала звучит тяжеловато. Но по смыслу всё довольно ясно.

У современных агентов для программирования уже есть своя обвязка: доступ к файлам, терминалу, командам сборки, иногда к тестам и репозиторию. Авторы не переписывают эту обвязку. Они строят обвязку над обвязкой. То есть внешний слой, который организует работу агента на длинной дистанции.

Вместо одного большого запуска система делает повторяющийся цикл из трёх ролей:

🟠 Планировщик проекта решает, что делать в следующей итерации, опираясь на требования и результаты прошлых проверок

🟠 Разработчик вносит изменения в проект и прогоняет локальные тесты по ходу работы

🟠 Тестировщик независимо проверяет, что получилось, и фиксирует, что реально работает, а что нет

Ключевой момент здесь не в самих ролях. Такие схемы уже встречались. Важнее другое: между циклами система переносит не только код, но и состояние знаний о проекте.

Авторы разделяют две вещи:

🟣 Артефакт проекта — текущий код, ресурсы, конфиги, всё, что уже собрано

🟣 Свидетельства выполнения — что проверено, какие ошибки найдены, что сломалось, что надо сохранить в следующей итерации

Это и есть центральная идея работы: агент должен помнить не только то, что он написал, но и то, что уже было проверено. Без этого каждая новая попытка почти заново угадывает состояние проекта по одному лишь коду.

Схема Harness-of-Harness: планировщик, разработчик и тестировщик работают вокруг растущего проекта, а система сохраняет код и проверенные свидетельства между итерациями.

Почему обычный агент проваливает длинные задачи

Авторы довольно точно описывают проблему длинной автономной разработки.

Когда проект растёт, у агента начинаются типичные сбои:

🟠 Теряются ранние решения: почему архитектура устроена так, а не иначе, какие ограничения уже были приняты

🟠 Локальные исправления дают регрессии: починили меню — сломали сохранение, добавили механику — испортили ввод

🟠 Появляется цикл «смотрим, чиним, снова смотрим» без заметного прогресса в продукте

🟠 Пропуски маскируются под завершение: код есть, но целостного поведения нет

Если говорить проще, агенту трудно держать в голове длинную историю проекта. Контекстное окно конечно. История переписки заканчивается. А код сам по себе плохо хранит объяснение, что уже было подтверждено проверкой, а что только кажется рабочим.

Поэтому авторы не делают ставку на память как отдельный модуль. Вместо этого они сохраняют документы, отчёты, историю итераций и дают агенту доставать нужное по индексу, а не тащить весь проект целиком в каждый промт.

Это инженерный подход. Не «пусть модель сама всё удержит». А «пусть система аккуратно хранит важное снаружи».

Как устроен цикл работы

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

Например:

🟣 исправить конкретный блокер сборки и добавить базовый экран результата

🟣 сохранить уже работающий ввод и достроить механику столкновений

🟣 не переписывать полпроекта, а закрыть один наблюдаемый сценарий

Такой подход решает сразу две проблемы. Во-первых, область изменений меньше, значит легче найти источник поломки. Во-вторых, результат проще проверять.

Ещё один ход: тестирование встроено и в разработку, и после разработки.

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

Это убирает частую проблему мультиагентных схем, где агент сам себя и пишет, и тут же сам себя убеждает, что всё готово.

Что показали бенчмарки

Авторы гоняли HoH на трёх разных наборах задач:

🟠 GameCraft-Bench — создание играбельных игр в Godot по текстовому описанию

🟠 FrontierSWE — сложные задачи по разработке и оптимизации программных систем

🟠 ProgramBench — восстановление программы с нуля по исполняемому файлу и документации

Проверяли три связки «обвязка + модель»:

🟣 Codex с GPT-5.5

🟣 OpenCode с DeepSeek-V4-Pro

🟣 Pi с MiniMax-M3

Во всех случаях HoH сравнивали с базовым режимом, где тот же агент просто делает один обычный проход без внешнего цикла.

Итеративная схема почти везде даёт большой прирост.

Коротко по цифрам:

🟠 На GameCraft-Bench средний итоговый балл вырос на 16.6–22.1 пункта в зависимости от связки

🟠 На FrontierSWE прирост по доминированию составил 19–29 процентных пунктов

🟠 На ProgramBench улучшение доходило до 16.85 пункта по доле пройденных скрытых тестов

🟠 Средний относительный выигрыш по всем экспериментам авторы оценивают в 52.25%, максимум — 82.86% после трёх итераций

Выжимка по результатам:

🟣 HoH улучшает результат на всех трёх бенчмарках

🟣 Прирост виден у разных моделей, а не только у самой сильной связки

🟣 Выигрыш даёт именно организация цикла, а не просто лишний проход

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

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

Это практический вывод. Прогресс здесь идёт не только от «дайте модель получше», но и от правильной организации процесса.

Улучшение идёт от итерации к итерации

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

На игровом бенчмарке баллы у всех трёх связок росли от HoH@1 к HoH@3. На FrontierSWE для связки Codex + GPT-5.5 систему прогнали до десяти циклов. Там доминирование выросло с 27.33% у базового режима до 72.67% на десятой итерации, а лучший чекпойнт на девятом цикле дал 76%.

На FrontierSWE качество растёт по мере увеличения числа циклов: HoH продолжает улучшать результат далеко за пределами трёх итераций.

То есть перед нами не просто «агенту дали ещё один шанс». Система действительно накапливает полезное состояние между проходами.

Авторы отдельно проверили и другой вопрос: может, всё дело в том, что HoH просто тратит больше токенов? Для этого они сравнили HoH с режимом, где базового агента просто просят «продолжить разработку» ещё на один и ещё на один проход.

Результат показателен. При одинаковом числе проходов HoH всё равно впереди. Более того, HoH после двух циклов обгоняет базовый режим после трёх, хотя токенов у него даже меньше.

Что из этого следует:

🟠 Дело не сводится к грубой силе

🟠 Дополнительные токены сами по себе не объясняют прирост

🟠 Работает именно структура цикла: план, реализация, независимая проверка, перенос свидетельств дальше

Что именно помогает

Авторы сделали и абляцию — по очереди вынимали ключевые части схемы.

Если:

🟣 не обновлять план между итерациями, качество заметно падает

🟣 не передавать результаты проверки в следующий цикл, тоже падает

🟣 не продолжать работу с прошлого состояния проекта, а каждый раз начинать почти заново, качество падает, а расход токенов растёт

Из этого получается простая мысль: HoH работает не потому, что «три агента лучше одного» сами по себе. Он работает потому, что есть три сквозных механизма:

🟠 обновляемый план

🟠 обратная связь от проверки

🟠 непрерывность артефакта проекта

Уберите любую из этих опор — и система начинает хуже держать длинную задачу.

Многодневная разработка шутера

Самая заметная часть статьи — не бенчмарки, а длинный кейс с автономной разработкой игры-шутера от первого лица. Система получила только документ с требованиями продукта и дальше более 70 итераций вела проект сама.

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

Итоговый проект включал:

🟠 связный сценарий

🟠 боевую механику

🟠 оружие и взаимодействие с врагами

🟠 навигацию для игрока

🟠 интерфейс и меню

🟠 анимации, визуальную подачу и звук

Важно не только то, что игра вообще появилась. Интереснее динамика. За 70 циклов система завела 81 задачу, закрыла 65, а 17 задач позже пришлось открыть заново из-за регрессий. Это очень похоже на обычную жизнь программного проекта. Продукт растёт, ошибки всплывают, часть исправлений ломается позже, затем их снова чинят.

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

Коротко о кейсе:

🟣 Более 70 итераций без ручного ведения проекта

🟣 81 заведённая задача, 65 закрытых, 17 повторно открытых

🟣 Регрессии возникают даже в успешном длинном цикле

🟣 История проекта и результаты проверок нужны не меньше, чем сам код

Что это меняет

Автономная разработка — это проблема процесса, а не только модели.

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

🟣 короткие проверяемые шаги вместо одного гигантского захода

🟣 разделение ролей между планированием, реализацией и проверкой

🟣 сохранение истории проекта в виде кода и свидетельств

🟣 независимая проверка, которая не может сама подправить результат

Отсюда и более широкий вывод. Вокруг LLM всё чаще обсуждают модели мира, рассуждение, агентность. Но в задачах по программированию часто решает более приземлённая вещь: умеет ли система организовать собственную работу на длинной дистанции.

Вывод

Harness-of-Harness показывает, что прогресс в автономной разработке можно получить без новой модели и без дообучения. Достаточно сделать то, что в обычной инженерии давно считается нормой: разбить работу на многошаговый цикл, сохранять историю решений, отделить написание кода от проверки и переносить вперёд не только файлы, но и знание о том, что уже подтверждено.

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