От статьи к репозиторию: где рвётся цепочка
Научная публикация — это не инструкция по сборке. Даже подробный текст с формулами и графиками не содержит всего, что нужно, чтобы запустить код и получить те же числа. Именно эту пропасть исследует работа под названием ReproAgent: Contract-Guided Paper-to-Code Reproduction — она формализует задачу paper-to-code reproduction: научный ИИ-агент должен превратить статью в исполняемый репозиторий, в котором сохранены метод, протокол экспериментов и артефакты.
Причина сложности, по мысли авторов, не в «слабости» моделей, а в раздробленности спецификации. Явная часть — алгоритмы, метрики, состав артефактов — в статье присутствует, но на длинных траекториях агента эти детали постепенно теряются, вымываются из рабочего контекста. Неявная часть — умолчания фреймворков, конвенции, унаследованные от смежных работ, — в тексте вообще не упоминается: для авторов статьи это настолько очевидно, что не требует слов. Восстановить такие детали «по общим соображениям» нельзя, а без них код либо не запускается, либо даёт другие результаты.
Формальные данные препринта: arXiv:2608.24291, основная категория — cs.AI, дополнительно указана cs.SE; подан 25 августа 2026 года. Авторы — Xue Hu, Zewei Pan, Zhongyuan Wang, Zhou Liu, Zeli Su и Wentao Zhang, отправитель — Xue Hu. Работа принята в Findings of EMNLP 2026, DOI: 10.48550/arXiv.2608.24291.
Контракт реализации как якорь для агента
Главная идея ReproAgent — не давать агенту «просто читать статью и писать код». Вместо этого строится постоянный контракт реализации (implementation contract) — артефакт, который живёт на протяжении всей работы и переживает длинные траектории, в отличие от исходного текста в контексте.
Контракт наполняется из двух независимых каналов:
- канал требований (implementation-requirement) — превращает фрагменты статьи в конкретные обязательства по коду: что именно должно быть реализовано, какие метрики считаться, какие данные загружаться;
- канал свидетельств (reference-evidence) — вытаскивает содержательные и структурные подсказки из связанных репозиториев, то есть подтягивает те самые неявные конвенции, которых нет в тексте.
Дальше оба потока сходятся: они привязываются к work packages — пакетам работ, — а затем проецируются в контракты уровня отдельных файлов. Такая проекция важна, потому что именно на уровне файлов агенту и приходится действовать, и именно там обычно теряется связь между «задумкой из статьи» и «строкой в коде».
Смысл конструкции в том, что обязательство первично, а генерация вторична. Агент не пытается вспомнить нужную деталь в момент написания кода — он сверяется с уже зафиксированным требованием.
Четыре стадии и роль починки
Работа описана как конвейер из четырёх последовательных стадий, которые складываются в аббревиатуру Prepare — Plan — Generate — Repair.
- Prepare — подготовка: разбор статьи и связанных материалов, первичное наполнение контракта.
- Plan — планирование: разбиение задачи на пакеты работ и привязка к ним обязательств и свидетельств.
- Generate — генерация кода по контрактам уровня файлов.
- Repair — починка: контракт используется повторно, чтобы понять, что именно разошлось с требованием, а не латать ошибки наугад.
Обратите внимание на асимметрию: контракт нужен не только на входе, но и в самом конце — при исправлении ошибок. Это, пожалуй, самая практичная часть замысла. Большинство агентных пайплайнов сильны на этапе написания и слабы на этапе отладки, потому что к моменту первой ошибки исходная спецификация уже размыта. Здесь она остаётся под рукой.
Проверка: PaperBench Code-Dev
Авторы проверяли подход на PaperBench Code-Dev — бенчмарке, где агент должен воспроизводить код по научным статьям. Результат: наивысший средний балл среди скаффолдов с тем же backbone. Важно, что эффект наблюдается с двумя разными базовыми моделями — Claude Sonnet 4.5 и Gemini 3 Flash.
Что означают эти термины. Backbone — базовая модель, «мозг» агента. Scaffold — обвязка вокруг неё: правила, память, порядок шагов, инструменты. Сравнение при одинаковом backbone — корректный способ показать, что выигрыш даёт именно архитектура, а не более сильная модель. ReproAgent — как раз вклад в класс скаффолдов.
Дополнительно авторы провели абляции по каналам: если отключить канал требований или канал свидетельств, качество end-to-end падает. Плюс разборы отдельных статей, где видно, какой именно вклад вносит каждый канал на конкретных примерах. Такой двойной контроль — общий замер плюс качественный разбор — делает выводы убедительнее, чем одна цифра в таблице.
Код и экспериментальные артефакты, по заявлению авторов, находятся в открытом доступе.
Что это меняет на практике
Ценность работы не только в результате на бенчмарке, а в самой формулировке проблемы. «Раздробленность спецификации» — удачное объяснение того, почему агенты уверенно пишут код, который выглядит правильным, но не воспроизводит результаты. Явные детали теряются по мере удлинения траектории, неявные — отсутствуют изначально.
Контракт реализации предлагает обходной путь: вынести обязательства из хрупкого контекста в отдельный устойчивый объект и обращаться к нему на всех стадиях, включая отладку. Такой приём выглядит переносимым — похожие «зафиксированные требования» могут пригодиться и в других задачах, где агенту нужно долго удерживать исходные условия: миграции, воспроизведение инфраструктуры, длинные инженерные задачи.
Ограничения тоже понятны из логики метода: качество контракта напрямую зависит от качества извлечения требований и от того, насколько подходящие связанные репозитории нашлись. Если по теме нет публичного кода, канал свидетельств работает вслепую. Но как минимум один тезис авторов звучит убедительно уже сейчас: воспроизводимость научной работы — это задача про спецификацию, а не про скорость генерации кода.
