Крутое падение! Даже самая мощная ИИ не справляется с долгосрочной разработкой: чем больше кода накапливается, тем быстрее система рушится

Покупать акции нужно по отчетам аналитиков Golden Qilin — это авторитетно, профессионально, своевременно и всеобъемлюще, поможет вам раскрыть потенциальные темы и возможности!

（Источник：DeepTech深科技）

Напишите функцию — ИИ почти непобедим; но почему, поддерживая систему, ИИ начинает рушиться?

Сейчас искусственный интеллект уже вошел в «вторую половину». По мере того как растут способности ИИ к программированию, такие продукты, как OpenClaw, постепенно появляются и усиливаются — «CLI everything» становится реальностью: ИИ не нужно управлять компьютером, а вместо этого все интерфейсы преобразуются в интерфейсы командной строки (CLI), и одна за другой его «навыки» превращаются в функции программного обеспечения.

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

Главный AI-ученый в «офисе CEO/президента» Tencent Яо Шуньюй в блоге под названием «The Second Half» отмечал, что реальные задачи программирования имеют непрерывную зависимость, а не независимы и не выполняются параллельно, но в академической среде на сегодняшний день нет таких бенчмарков для оценки того, какие именно способности ИИ требуется в этом сценарии, более того, не хватает смелости нарушить широко принятую гипотезу независимости задач — очень давно используемую для упрощения проблем.

Недавно совместная команда из Университета Южной Калифорнии, Университета Калифорнии в Риверсайде, Стэнфордского университета, Принстонского университета, OpenHands и др. опубликовала новый оценочный бенчмарк EvoClaw, предложив решение указанной проблемы. Исследовательская команда извлекла историю высококачественной эволюции кода из открытых проектов, чтобы агент в одной и той же кодовой базе последовательно выполнял десятки итераций функциональных изменений, взаимозависимых друг от друга.

Результаты показывают: топовый ИИ демонстрирует отличные показатели в независимых оценочных задачах (80%+), но при входе в реальный сценарий длительного цикла даже у суммарно лидирующего Claude Opus 4.6 итоговый результат лишь 38.03%. Это означает, что ИИ при выполнении задач с большей свободой легко отклоняется от траектории, и все еще существует заметный разрыв до того, чтобы он действительно мог обрабатывать длительную, непрерывную программную эволюцию.

（Источник：arXiv）

Это исследование раскрывает, что в долгосрочной эволюции ИИ крайне легко впадает в технологический долг по принципу «снежного кома». Хотя он может продолжать добавлять новые функции, он не способен контролировать возврат и накопление ошибок, что в итоге приводит к потере контроля над системой. Это также означает, что программирование ИИ меняется: оно переходит от написания кода к управлению системой.

Соответствующая статья называется «EvoClaw: Evaluating AI Agents on Continuous Software Evolution»（EvoClaw: Evaluating AI Agents on Continuous Software Evolution） и в последнее время опубликована на сайте препринтов arXiv[1].

Рисунок丨 Соответствующая статья (Источник：arXiv)

Существующие оценки программирования ИИ не совпадают с реальным опытом — где проблема?

Почему топовые модели получают высокие баллы в независимых тестах, но в EvoClaw терпят коллективную неудачу? Корень проблемы в том, что изменился подход к оцениванию.

В прежних исследованиях основной акцент в бенчмарках программирования (benchmark) в большинстве случаев делался на независимые задачи: задается тема (issue) или pull request (PR, Pull Request), модель на статическом снимке кода завершает исправление, а проверка пройдена — и на этом оценивание заканчивается.

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

（Источник：arXiv）

Первый автор статьи, студент PhD Южно-Калифорнийского университета Дэн Ганъда, рассказал DeepTech: «Текущая гранулярность commit и release либо слишком мелкая, либо слишком грубая. Поэтому эти истории разработки не отражают процесс эволюции ПО».

Рисунок丨 Дэн Ганъда (Источник：опрошенный)

Исследовательская команда впервые ввела временное измерение в оценку возможностей программирования ИИ, применив новую иерархию — вехи (Milestone), чтобы реконструировать историю эволюции ПО. Это позволяет получать функциональные единицы, которые одновременно сохраняют семантическую целостность и способность сохранять зависимости эволюции. Ей требуется, чтобы ИИ на одной и той же кодовой базе последовательно, в порядке очередности, завершал множество функциональных единиц: так сохраняется выход на каждом шаге и он становится точкой отсчета для следующего шага.

（Источник：arXiv）

Чтобы поддержать извлечение высококачественной истории эволюции ПО из большого числа репозиториев с открытым кодом, исследователи, опираясь на сильные возможности топового ИИ, предложили набор агент-ориентированного автоматизированного конвейера DeepCommit, впервые реализовав реконструкцию шумных Git-записей в верифицируемый, функционально связный граф зависимостей задач-вех (Milestone DAG), а также построение оценочной среды для каждой вехи. Он включает три этапа: предварительная обработка Git-истории, построение DAG под управлением Agent и настройка среды вех и верификация.

На самом деле реконструировать агентную историю эволюции с помощью Milestone непросто, потому что нужно не только сконструировать статический, чисто наблюдаемый DAG, но и выстроить целую цепочку исполнимых оценочных сред; при этом требуется обеспечивать корректность при изменении зависимостей эволюции.

Это означает, что при перемешивании общего порядка commit и их повторной кластеризации могут возникнуть ситуации, когда commit нельзя применить, интерфейсы не совпадают и возникают масштабные ошибки компиляции. Для решения этой проблемы исследователи разработали итерационный цикл исправлений: Agent сам анализирует логи ошибок, динамически модифицирует Dockerfile, чтобы гарантировать исполнимость.

Ключевое же в том, что он дополнительно включает пропущенные неявные зависимости, опираясь на исходный DAG: за счет корректировки отношений ограничений «веха-до/после» проблемы конфликта интерфейсов удается должным образом устранить. После многократных итераций в итоге получилось корректно собрать 87.1% исходных тестовых случаев.

«По сравнению со сценарием одиночной задачи программирования, стабильное, надежное и эффективное долгосрочное автономное программирование — это более передовой фокус исследований. Например, Anthropic и OpenAI прямо указывают, что они сместили центр тяжести на тренировку моделей долгосрочным навыкам программирования». — сказал Дэн Ганъда.

Рисунок丨 Схема архитектуры конвейера DeepCommit (Источник：arXiv）

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

В частности, вехи человеческих экспертов обычно располагаются в локальном временном окне: сначала фиксируется тема, затем собираются commit — это семантическое разбиение сверху вниз. DeepCommit, чтобы обеспечить абсолютную точность, исходит из зависимостей между коммитами, и реконструирует эволюцию ПО снизу вверх, при этом сильнее делает акцент на топологической структуре и ограничениях на исполнение.

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

Почему как только модель попадает в реальную разработку, результаты «проваливаются вдвое» коллективно?

EvoClaw охватывает пять распространенных языков: Python, Java, Go, Rust и TypeScript. Выбранные проекты имеют максимальный реальный цикл разработки до 750 дней.

Что касается оценочных метрик, исследовательская команда не использовала простую метрику прохождения, а ввела два более ключевых измерения — F1 с весовой интеграцией Recall (полнота) и Precision (точность) — в качестве оценки каждой Milestone. При этом recall используется для измерения полноты реализации функций, а precision фиксирует, насколько сильно модель при добавлении новых функций разрушает существующий код.

Исследовательская команда тестировала множество комбинаций фреймворков и моделей, включая Claude Code, OpenHands и др. Результаты показывают: в независимых оценках баллы в большинстве случаев у топовых моделей находятся в диапазоне 80%-90%, но после проведения бенчмарк-тестов EvoClaw они резко и коллективно падают. Даже у Claude Opus 4.6, набравшего самый высокий результат, итог лишь 38.03%.

Рисунок丨 Основные результаты экспериментов EvoClaw (Источник：arXiv）

GPT 5.3 Codex с комплексным баллом 28.88% идет сразу после Opus4.6, занимая второе место. По разбиению на репозитории: GPT 5.3 Codex слабее всего показал себя в двух Rust-проектах (Nushell、ripgrep), а в остальных репозиториях способен быть близко к Opus4.6 или даже превосходить его. В полной решаемости (полностью решенные случаи) у лидера Gemini 3 Pro всего 13.37%, и подавляющее большинство правильно реализованных задач — это те, у которых нет предварительных зависимостей.

По имеющимся сведениям, исследователи держали общие расходы в разумных пределах: например, для Claude Opus 4.5 стоимость полного прогона оценки составляет около 500 долларов; Kimi K2.5 и Gemini 3 Flash — в пределах 50 долларов; расходы малых моделей будут ниже.

（Источник：arXiv）

Тогда если дать моделям более длинное окно разработки, смогут ли они в итоге на 100% довести проект до готовности?

Исследование дает отрицательный ответ: независимо от того, насколько длинным будет окно разработки, в конечном итоге все модели упрутся в «потолок». Чем позже выполняется порядок задач и чем глубже уровень в DAG, тем ниже будут баллы и коэффициент решения. Результаты экстраполяции за пределы функции насыщения доказывают, что даже у оптимального Opus 4.6 накопленный балл будет «зажат» примерно на 45% по асимптотической линии.

«Хотя Opus 4.6 на сайте Anthropic упоминает, что он лучше 4.5 в задачах долгого цикла, но там не приводятся подробные оценочные показатели. EvoClaw можно считать проверкой их утверждения с другого ракурса». — сказал Дэн Ганъда.

Кроме того, в экспериментах также видны заметные различия между семействами моделей. В частности, у Claude и GPT в сценариях непрерывной эволюции показатели стабильно улучшаются с обновлениями версий. Причем Opus 4.6 в программировании долгого цикла демонстрирует, что его способности к обслуживанию системы лучшие; GPT 5.3 снижает баллы из-за слабых результатов на Rust-датасете и занимает второе место.

（Источник：arXiv）

Особенно неожиданно, что у семейства Gemini наблюдается полностью иной тренд: от 3 Flash к 3 Pro и далее к 3.1 Pro — каждая новая генерация быстрее стартует на ранних стадиях и демонстрирует более сильное начало, но ее дальнобойные результаты почти не улучшаются. Дэн Ганъда объяснил: «Явный спад качества работы Gemini в долгосрочных запусках означает, что ухудшается не только соблюдение инструкций, но и все больше игнорируются требования спецификаций программного обеспечения (SRS), а также проявляется недостаток обслуживания построенной программной системы».

Когда исследователи разложили общий балл дальше на recall и precision, появилось еще более интересное явление: recall почти постоянно растет, близко к линейному увеличению. Это означает, что даже если кодовая база становится все более хаотичной и хрупкой, агент все еще хорошо справляется с реализацией текущих новых целевых функций.

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

Рисунок丨 Слева: схема цепочки ошибок; справа: распределение цепочки ошибок (Источник：arXiv）

Чтобы глубже понять коренную причину того, почему модель выходит из-под контроля в итерациях, исследовательская команда предложила аналитическую рамку «цепочки ошибок» (Error Chains). Они отслеживали каждый тест, начиная с первого возникновения ошибки, и наблюдали, наследуется ли ошибка в последующих Milestone, распространяется, пропускается или исправляется.

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

Для отладки AI Harness — универсальное оценивание

В последнее время очень популярна концепция «Harness Engineering»: надеется настроить весь процесс разработки ПО так, чтобы среда подходила для участия Agent. Бенчмарк EvoClaw предоставляет такую универсальную песочницу, которая подходит для отладки AI Harness и оценки долгосрочной эволюции кода.

Например, в провальных кейсах, упомянутых в этом исследовании, если Agent внезапно начинает проявлять чрезмерную активность в итерациях или бесконечно редактирует и снова и снова проверяет, вероятно, Agent столкнулся с трудностями. В таком случае можно заранее обнаружить проблему и вовремя вмешаться вручную, выстроив ограждения (guards) в соответствующих местах — так повышается эффективность.

Раз уж архитектура модели наделяет Agent общим свойством, при котором он «сильнее реализует новые функции, чем поддерживает старые долгосрочные», то может ли в будущем это привести к появлению новых форм программного обеспечения и новых моделей разработки?

Например, ПО будет сильнее подчеркивать гибкость и совместимость; а также более надежно — за счет крупных перестроек и реорганизаций. Либо оно станет более одноразовым: конкретная бизнес-логика генерируется в реальном времени и не требует обслуживания; акцент будет сделан на усилении повторно используемых компонентов и инфраструктуры.

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

Дэн Ганъда отметил: «Это исследование доказывает, что мы идем по правильному пути: долгосрочная способность ИИ к программированию еще не уперлась в узкое место, и она может стабильно расти со временем. Есть потенциал, что в один прекрасный день количественное изменение в рейтинговых баллах перейдет в качественное изменение, меняющее мир».

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

Список литературы：

1. Соответствующая статья：

2. Домашняя страница проекта：

Верстка: Лю Якун

Огромный поток новостей и точная интерпретация — все в Sina Finance APP