Когда модель заморожена, агента всё равно можно улучшать
У ИИ-агентов есть неудобная правда: качество зависит не только от самой модели. Часто всё решает обвязка — системный промт, инструменты, память, правила выбора следующего шага, проверки перед ответом. Одна и та же LLM может вести себя как аккуратный инженер или как хаотичный стажёр просто из-за того, как вокруг неё собран пайплайн.
Работа DarwinX предлагает смотреть на это как на эволюцию. Модель не дообучают и не меняют. Меняют только обвязку. Причём не в одной линии «попробовали правку — оставили лучшую», а через популяцию вариантов, отбор, сохранение полезных веток и их последующее объединение.
Сегодня у индустрии есть перекос: почти всё внимание уходит в веса модели. DarwinX показывает более приземлённую вещь: если у вас уже есть сильная LLM, большой запас качества может лежать не в новой модели, а в том, как именно агент устроен вокруг неё.
Что такое DarwinX
Идея простая: агент улучшается не через обучение модели, а через отбор версий его обвязки.
Авторы называют обвязкой всё внешнее по отношению к модели:
🟠 системные промты и инструкции
🟣 набор инструментов
🟠 навыки и накопленные заметки
🟣 управляющую логику: когда запускать инструмент, когда перепроверять, когда продолжать поиск решения
Обычно самоулучшающиеся агенты идут по одной линии. Они меняют свою процедуру, измеряют результат и оставляют последнюю удачную правку. У такого подхода две старые проблемы.
🟠 Он зависит от ранних решений: если в начале вы пошли не туда, дальше вся ветка может застрять
🟣 Локальная победа по одной группе задач может незаметно испортить результаты по другой
DarwinX решает это через «естественный отбор» версий обвязки. Делается много вариантов. Каждый прогоняется на задачах. Выживают те, кто научился решать что-то новое и не сломал уже освоенное.
Схема DarwinX: обвязка агента развивается при замороженной модели, а полезные ветки сохраняются и могут объединяться.
Ключевой ход здесь — не искать одного победителя слишком рано. Даже версия, которая в среднем хуже, может решить один редкий класс задач. DarwinX не выбрасывает такие ветки сразу. Он складывает их в архив, а потом пытается объединять взаимодополняющие улучшения.
Если упростить, логика такая:
🟠 сделать небольшую правку в обвязке
🟣 проверить, стало ли лучше на части задач
🟠 убедиться, что старые навыки не просели слишком сильно
🟣 сохранить удачную ветку в архив
🟠 позже скрестить несколько веток, если они полезны на разных задачах
Это уже не похоже на «покрутили промт». Это похоже на инженерный пайплайн поиска устойчивой конфигурации агента.
Как устроен отбор
Самая интересная часть работы — правило, по которому новая версия получает право жить дальше.
Авторы вводят контракт «сохрани и расширь». Новая обвязка должна:
🟠 решить хотя бы что-то новое
🟣 не потерять слишком много из того, что умел родительский вариант
DarwinX поощряет не хаотические скачки, а накопление навыков. Если версия починила одну задачу, но сломала три старых, это плохая мутация. Если добавила новую способность почти без регресса, её сохраняют.
Цикл отбора в DarwinX: правило «сохрани и расширь», архив альтернативных веток и общая память между поколениями.
Ещё одна деталь: система отделяет быстрый поиск от строгого подтверждения. Сначала можно пропустить вариант по более шумному сигналу, чтобы не тормозить эволюцию. Но прежде чем такой вариант начнёт влиять на следующие поколения, его перепроверяют тщательнее.
Это сделано из-за проблемы всех агентных бенчмарков: они шумные. Один и тот же агент может случайно пройти задачу один раз и провалить в другой. Если бездумно верить единичным удачам, эволюция быстро начнёт подстраиваться под шум.
В DarwinX это гасят двумя способами:
🟠 оценивают решения через верификатор самого бенчмарка, а не по «золотым» ответам
🟣 повторно измеряют кандидатов, прежде чем делать их новыми предками
Отдельно полезна общая память между поколениями. Система собирает типичные причины провалов: долгий сетап, ошибка инструмента, неверный формат ответа, слабая проверка результата. Эти повторяющиеся темы потом влияют на следующие правки. DarwinX пытается учить агента не латать одну задачу, а вырастить общий навык для похожих провалов.
Откуда берутся правки
DarwinX не меняет веса модели. Значит, все улучшения надо извлекать из анализа поведения агента. Для этого есть три типа сигналов.
DarwinX хранит и использует общую память о том, что сработало, что сломалось и какие типы ошибок повторяются.
Первый — из неудач. Если агент провалил задачу, система анализирует траекторию и пытается понять, чего не хватило: проверки артефакта, лучшего сетапа, другой последовательности действий.
Второй — от более сильного решателя. Если у самой системы нет удачной попытки, можно взять чужую успешную траекторию и перегнать её в изменение обвязки. По сути это не копирование ответа, а извлечение подхода.
Третий — из собственных контрастов. Если на одной и той же задаче у агента были и успешные, и провальные прогоны, можно сравнить их и найти, что именно делает успех воспроизводимым.
В сжатом виде методология выглядит так:
🟠 провалы превращаются в диагноз
🟣 удачные чужие прогоны превращаются в демки
🟠 разница между своими удачами и провалами превращается в правило
🟣 всё это записывается как изменение обвязки, а не как дообучение модели
Это важное ограничение. Авторы хотят доказать одно: даже замороженная модель — это ещё не фиксированный агент.
Что получилось на бенчмарках
Авторы проверяют DarwinX не на одном тесте, а на четырёх режимах, где всё сильнее расходятся сигнал эволюции и финальная оценка. Так проще понять, выучила ли система общий способ работать лучше или просто подогналась под конкретный набор задач.
Результаты на четырёх бенчмарках: одна и та же идея улучшает агента без изменения весов модели и переносится между задачами.
Главные цифры такие:
🟠 Terminal-Bench 2.1: рост с 75.5% до 83.2% на GPT-5.5, то есть +7.7 пункта
🟣 На более сильной базе результат доходит до 84.7%
🟠 TerminalWorld на отложенных задачах: 68.3%, выше базовой версии и выше нескольких готовых агентов
🟣 WebArena-Infinity: рост с 43.5% до 93.0% на реальных веб-задачах после эволюции только на синтетических задачах
🟠 Перенос с Terminal-Bench 2.1 на SWE-bench Verified без изменений обвязки: 84.2%
Коротко по цифрам:
🟠 Средний прирост по четырём режимам — около 17 пунктов
🟣 Улучшения идут без смены модели
🟠 Есть перенос между задачами
🟣 Рост виден и в терминале, и в браузере
Самый заметный результат — WebArena-Infinity. Там агент учился не на реальных задачах бенчмарка, а на синтетических намерениях. DarwinX не видел финальные тесты и даже пользовался другим сигналом при отборе. Несмотря на это, на реальных задачах получилось 93% чистого pass@1 после аудита.
Это особенно важно, потому что веб-агенты часто «читерят»: трогают скрытое состояние, лезут во внутренние технические детали страницы, используют то, что обычному пользователю недоступно. Авторы отдельно проверили траектории и показали, что после эволюции число невалидных решений резко упало — с 293 до 17. Агент стал не только чаще проходить задачи, но и чаще делать это правильным способом.
Короткая выжимка по результатам:
🟠 Улучшения идут без смены модели
🟣 Рост есть и в терминале, и в браузере
🟠 Есть перенос на другой бенчмарк
🟣 Веб-агент стал аккуратнее, а не просто агрессивнее
Что именно эволюционирует
В работе есть один повторяющийся мотив: DarwinX часто выращивает у агента привычку сначала формулировать контракт задачи, а потом проверять результат перед финализацией.
Общая память и цикл отбора подталкивают DarwinX к накоплению процедурных навыков, а не к разовым заплаткам.
На Terminal-Bench улучшения особенно заметны там, где проблема процедурная, а не связана со знаниями:
🟠 задачи по машинному обучению и научным вычислениям
🟣 задачи с данными и базами данных
🟠 длинный сетап окружения
🟣 многошаговая работа с инструментами
🟠 проверка выходных файлов и форматов
DarwinX не делает модель ещё умнее. Он делает агента дисциплинированнее. Агент чаще проверяет, что именно считается правильным ответом, сравнивает итог с контрактом задачи, прогоняет дополнительную валидацию, не завершает работу слишком рано.
В браузерных задачах проявляется тот же паттерн. Вместо того чтобы обходить интерфейс через сомнительные сокращения, агент после эволюции чаще:
🟠 формулирует условие успеха
🟣 действует через доступные операции приложения
🟠 проверяет и видимое состояние, и сохранённый результат
🟣 убеждается, что изменение действительно закрепилось
Это выглядит как набор процедурных навыков, а не как подгонка под конкретные ответы.
Почему это важно для индустрии
DarwinX показывает: вычисления на оценку можно превращать в постоянное улучшение агента, даже если вы вообще не трогаете модель.
Сегодня компании часто делают так: берут новую LLM, накидывают поверх минимальную обвязку и идут сравнивать результаты. Эта работа показывает, что такой подход оставляет много качества на столе.
Если вы строите ИИ-агентов, из статьи следуют четыре практических вывода:
🟠 Обвязка — это отдельный слой оптимизации, а не техническая мелочь
🟣 Один лучший агент хуже архива разных полезных вариантов
🟠 Нужны проверки на сохранение старых способностей, иначе правки будут тихо ломать уже работающие кейсы
🟣 Эволюция по верификатору задачи может быть полезнее, чем ручной подбор «правильных» правок
Ещё один вывод касается шума в агентных оценках. Если вы хотите улучшать агента автоматически, нельзя верить единичным успехам. Нужны повторные прогоны, аккуратный отбор и защита от случайных побед. DarwinX строится именно вокруг этого.
Ограничения
Работа не закрывает все вопросы.
Во-первых, здесь тестируют систему целиком. Архив, отбор родителей, объединение веток, разные сигналы правок — всё работает вместе. Поэтому трудно точно сказать, какой кусок даёт основную долю прироста.
Во-вторых, не везде перенос одинаково большой. На SWE-bench прирост есть, но он намного скромнее, чем в исходных задачах.
В-третьих, в некоторых режимах выборки невелики. Например, в TerminalWorld отложенных задач всего 41, и один успех заметно сдвигает итоговый процент.
Но эти ограничения не меняют главное наблюдение: улучшать агента можно через обвязку, и это работает не только в одной песочнице.
Вывод
DarwinX предлагает смотреть на ИИ-агента как на объект отбора, а не только обучения. Модель остаётся той же. Меняется обвязка. Если новая версия решает больше задач и почти не портит старые навыки, она выживает. Если разные ветки хороши на разных задачах, их можно объединить.
Из этого выходит практичная идея: фиксированная LLM — это ещё не фиксированный агент. Поведение агента можно накапливать, проверять и переносить между задачами без дообучения модели.
Самые заметные улучшения приходят из дисциплины: лучше формулировать контракт задачи, аккуратнее работать с инструментами, чаще проверять результат перед финальным ответом. Для агентных систем это может быть важнее очередного скачка в размерах модели.
ИИ-обзоры простыми словами
Каждый день читаем свежие статьи об ИИ и пересказываем главное естественным языком — без хайпа и воды. Если хотите понимать, куда движутся ИИ-агенты раньше остальных, — подписывайтесь.
Новые обзоры — каждый день
В Telegram