Harness Engineering для самосовершенствования моделей

Перевод/заметки Weng, Lilian. “Harness Engineering for Self-Improvement”. Lil’Log (Jul 2026)

---

Идея рекурсивного самосовершенствования (recursive self-improvement, или RSI) восходит к Ирвингу Гуду (1965 год). Он описал «сверхинтеллектуальную машину» как систему, которая превосходит человека во всех интеллектуальных сферах и может проектировать ещё более совершенные машины. В 2008 году Элиезер Юдковский сузил это понятие: при RSI искусственный интеллект использует свои текущие способности для улучшения когнитивных механизмов, которые эти способности и создают.

В контексте современного генеративного ИИ такая петля обратной связи не обязательно означает, что модель должна напрямую перезаписывать свои веса. В более широком смысле речь идёт об оптимизации конвейера обучения (training pipeline) и среды выполнения (deployment system). Модель автоматизирует исследовательскую и инженерную работу, что позволяет обучить модель-преемницу, которая лучше справляется с экономически полезными задачами. В ведущих лабораториях вроде Anthropic и OpenAI этот процесс уже значительно ускорил темпы исследований.

Среда выполнения здесь упомянута не случайно. Прослойка между «голой» моделью и реальным окружением важна не меньше, чем базовые способности нейросети на тестах сразу после предобучения. Ключевым компонентом здесь выступает harness (обвязка или среда выполнения) - система, которая оркеструет работу модели. Именно harness определяет, как модель планирует задачи, вызывает инструменты, управляет контекстом и памятью, хранит файлы и оценивает результаты. Это хорошо видно на примере коммерческих продуктов вроде Claude Code или Codex.

Этот пост посвящён исследованиям в области harness engineering и их вкладу в развитие RSI. Вокруг этой темы строятся многие недавние работы по автоматизации исследований (auto-research), самообучающимся агентам и эволюционному поиску программ. Другие направления вроде self-play, генерации синтетических данных, обучения во время инференса (test-time training) и непрерывного обучения (continual learning) тоже укладываются в концепцию RSI, но сегодня мы сосредоточимся именно на инженерии harness-систем (например, Yuan et al. 2024, Chen et al. 2024, Zhao et al. 2025, Choi et al. 2026).

Паттерны проектирования harness-систем

Ранние агентские фреймворки описывались простой формулой: «агент = языковая модель + память + инструменты + планирование + действие». Современный harness engineering ушёл далеко вперёд. Он включает проектирование рабочих процессов (workflow design и loop engineering), системы автоматической оценки результатов, управление правами доступа и постоянным состоянием. Это уже не просто шаблоны промптов, а полноценное проектирование рантайма: того, как модель наблюдает за средой, совершает действия, сохраняет историю, проверяет результат и повторяет цикл.

Такие системы проектируют намеренно простыми и универсальными, чтобы они могли адаптироваться к разным задачам. При этом разработчики часто опираются на привычные практики программной инженерии - так модели проще использовать знания, полученные при предобучении. Здесь напрашивается аналогия с операционными системами: harness должен инкапсулировать сложную логику управления ресурсами и контекстом, оставляя для модели простой интерфейс взаимодействия. Со временем конфигурации и интерфейсы инструментов, скорее всего, придут к единым стандартам.

Паттерн 1: Автоматизация рабочих процессов (Workflow Automation)

Модели нужен чёткий сценарий, в рамках которого она может запускать код, тестировать решения и вносить правки. Хорошим примером служит репозиторий autoresearch Андрея Карпатого. Стандартный рабочий процесс строится вокруг целевого цикла: составить план, выполнить действия, проанализировать результаты и тесты, исправить ошибки и повторить цикл до достижения цели. При этом система может сама обращаться к пользователю за уточнениями, если задача сформулирована неясно или требует подтверждения действий.

(Схематичный цикл работы агента Codex: агент вызывает инструменты, и их ответы влияют на генерацию следующего шага модели; источник: OpenAI).

Граф рабочего процесса показывает, что модель анализирует собственные траектории выполнения и ошибки, а затем дорабатывает решение через рантайм агента (agent runtime), не ограничиваясь статическими шаблонами промптов.

Паттерн 2: Файловая система как постоянная память

При выполнении длинных последовательностей задач (long-horizon tasks) агенту нужно управлять сложным состоянием и множеством артефактов. Держать весь рабочий процесс и логи в контекстном окне неэффективно. Вместо этого harness сохраняет состояние в файлах на диске. В долгих циклах работы логи экспериментов, diff-файлы, выжимки статей, трассировки ошибок и истории прошлых попыток быстро выходят за рамки любого контекстного окна.

Умение читать, записывать и редактировать файлы (обычно через команды оболочки) - это базовый навык для больших языковых моделей. Поэтому по мере роста базовых способностей моделей улучшается и их работа с постоянной памятью в виде обычных файлов.

Паттерн 3: Субагенты и фоновые задачи (Sub-agents & Backend Jobs)

Современный harness умеет запускать субагентов параллельно и отслеживать фоновые процессы. Это полезно, когда главному агенту нужно проверить несколько гипотез одновременно, запустить параллельные тесты или делегировать изолированную подзадачу, не засоряя свой контекст. В таком случае родительскому агенту требуется встроенный менеджер процессов: запускать задачи, читать логи, отменять зависшие процессы и объединять результаты в основном потоке.

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

Практический пример: Harness для coding agents

Интерфейсы популярных ИИ-ассистентов для разработки (таких как Claude Code, Codex, OpenCode или Cursor) уже во многом стандартизированы. Имея доступ к набору инструментов, coding agent может самостоятельно разрабатывать функции и исправлять баги в репозитории, подобно разработчику с IDE.

Вот типичные группы инструментов, которые предоставляет harness (список не полный, пример взят из этого репозитория):

• Файловая система: поиск файлов (glob, grep, ls), чтение (read, read_many), изменение (запись нового файла, точечное редактирование edit по совпадению строк, мульти-замена multi_edit, наложение патчей apply_patch).
• Выполнение в шелле: запуск консольных команд (bash, PowerShell).
• Ввод-вывод и интеграции: LSP (Language Server Protocol), инструменты контроля версий (git_status, git_diff, git_commit).
• Внешний контекст: протоколы MCP (Model Context Protocol), библиотеки готовых навыков (Skills).
• Поиск в веб: web_search, web_fetch, управление браузером.
• Артефакты: чтение документации и изображений, генерация HTML или медиафайлов.
• Фоновые процессы: планирование задач (CronCreate, CronDelete, CronList).
• Делегирование: управление субагентами (spawn_agent, resume_agent, wait_agent, list_agents, interrupt_agent).

Harness и базовые возможности модели

Сложно предсказать, насколько будущее RSI будет зависеть именно от инженерии harness-систем. Однако в ближайшей перспективе рекурсивное самосовершенствование вряд ли начнётся с того, что модель начнёт переписывать собственные веса. Практичный путь выглядит иначе:

Harness-системы будут развиваться в сторону мета-методологии - улучшения механизмов поиска решений, а не просто ответов на конкретные вопросы. Сам harness станет объектом оптимизации, в котором ручные эвристики уступят место общим алгоритмам. Зрелые harness-системы позволят запустить цикл автоматических исследований (auto-research) для улучшения моделей, а поумневшие модели уберегут harness от избыточного усложнения.

Вполне вероятно, что со временем многие оптимизации среды выполнения перейдут на уровень базовой модели (как это случилось с трюками промпт-инжиниринга по мере развития instruction tuning). Тем не менее интерфейсы взаимодействия с внешним миром и инструментами сохранятся: потребность формулировать цели, ограничения и метрики никуда не исчезнет.

Оптимизация harness-систем

Объект оптимизации в harness-системах усложняется по цепочке: текстовые промпты → структурированный контекст → сценарий выполнения (workflow) → код самого harness → код оптимизатора. Чем умнее становится модель, тем к более общим методам оптимизации мы переходим.

Инженерия контекста (Context Engineering)

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

Метод Agentic Context Engineering (ACE; Zhang et al., 2025) предлагает относиться к контексту как к динамическому руководству (playbook), а не просто удлиняющемуся промпту. ACE поддерживает структурированный список тезисов, каждый из которых имеет свой идентификатор и описание. Система состоит из трёх компонентов:

• Генератор (Generator): строит траекторию выполнения задачи, опираясь на текущие тезисы.
• Рефлектор (Reflector): извлекает инсайты из успешных и провальных попыток.
• Куратор (Curator): точечно обновляет список тезисов на основе этих инсайтов.

(Схема архитектуры Agentic Context Engineering; источник: Zhang et al., 2025).

Чтобы избежать потери деталей и чрезмерного сжатия при переписывании, куратор в ACE не меняет весь промпт целиком. Вместо этого он генерирует пары (идентификатор, описание), которые затем по детерминированным правилам объединяются со старым списком. Тезисы периодически очищаются от дублей.

Хотя ACE извлекает уроки из опыта, правила обновления её контекста всё ещё прописаны вручную. Чтобы сделать шаг к самосовершенствованию, метод Meta Context Engineering (MCE; Ye et al., 2026) отделяет механизм управления контекстом от его содержимого. MCE запускает эволюцию навыков на мета-уровне, а оптимизацию контекста - на базовом уровне.

В MCE каждый навык $s \in \mathcal{S}$ определяет функцию контекста $c_s=(\rho_s,F_s)$ и преобразует входные данные $x$ в контекст $c = F_s(x;\rho_s)$, где:

• $\rho_s = \{\rho_1,\dots,\rho_m\}$ - статические компоненты (базовые промпты, базы знаний, библиотеки кода).
• $F_s = \{F_1,\dots,F_k\}$ - динамические операторы (поиск, отбор, фильтрация, форматирование).

Двухуровневая оптимизация формулируется так: внутренний цикл ищет лучший контекст $c_s^*$ для конкретного навыка на обучающих данных, а внешний цикл подбирает сам навык по результату на валидационной выборке:

$$\text{Внутренний цикл: }c_s^*=\arg\max_{c_s}J_\text{train}(c_s;s)$$$$\text{Внешний цикл: }s^*=\arg\max_{s\in\mathcal{S}}J_\text{val}(c_s^*)$$

База данных навыков хранит историю прошлых итераций: $\mathcal{H}_{k-1} = \{(s_i,c_i,J_i^\text{train}, J_i^\text{val})\}_{i=1}^{k-1}$. Агент мета-уровня скрещивает (crossover) успешные прошлые навыки и создаёт новый навык для задачи $\tau$: $s_k=\text{crossover}(\tau,\mathcal{H}_{k-1})$.

Затем базовый оптимизатор выполняет навык $s_k$ и уточняет функцию контекста на основе обратной связи $\mathcal{R}_k$: $c_k=\text{engineer}(\tau,s_k;c_{k-1}^*,\mathcal{R}_k)$.

(Схема Meta Context Engineering (MCE): мета-эволюция ищет механизмы управления контекстом, а базовый уровень оптимизирует сам контекст; источник: Ye et al., 2026).

MCE не навязывает жёстких правил структурирования, как ACE. Она использует гибкие форматы описания навыков и развивает их совместно с контекстом. На практике функция контекста $c$ хранится как набор файлов в каталоге, включая статические инструкции (skill.md) и динамические данные трассировки. Оптимизация на обоих уровнях запускается в программных средах разработки с базовым набором инструментов:

$$\mathcal{T}=\{\texttt{Read},\texttt{Write},\texttt{Edit},\texttt{Bash},\texttt{Glob},\texttt{Grep},\texttt{TodoWrite}\}$$

Проект Meta-Harness (Lee et al., 2026) идёт ещё глубже: объектом оптимизации становится сам код, который решает, какую информацию сохранять, извлекать и показывать модели. Приставка «meta-» означает, что это harness для оптимизации других harness-систем.

(Алгоритм внешнего цикла оптимизации в Meta-Harness; источник: Lee et al., 2026).

Генерацией новых вариантов harness занимается специальный coding agent, а результатом работы становится набор кандидатов на границе Парето.

Вся история выполнения сохраняется в файловой системе. Агент читает её через утилиты вроде grep или cat, не перегружая контекст промпта. Предложенный вариант harness хранится в виде каталога с исходным кодом, метриками и траекториями работы. Цикл итеративно генерирует новые решения и оставляет только лучшие.

(Результаты работы Meta-Harness на задачах классификации текстов и бенчмарке TerminalBench-2; источник: Lee et al., 2026).

Важный вывод: как только архитектура harness превращается в формализованное пространство поиска, сильный coding agent может работать с теми же вариантами устройства системы, которые рассматривают инженеры.

Проектирование рабочих процессов (Workflow Design)

Обычно сценарии работы агентов проектируются экспертами вручную. Например, в сфере автоматизации исследований (auto-research) фреймворк The AI Scientist (Lu et al., 2026) реализует полный цикл: генерация идей, написание кода, запуск экспериментов, анализ результатов, написание статьи и рецензирование. Проект ScientistOne (Meng et al., 2026) делает упор на проверяемость результатов: каждое утверждение в научной статье (будь то цитата, число или вывод) должно ссылаться на источник данных и проверяться через цепочку доказательств (Chain-of-Evidence).

(Схема конвейера The AI Scientist: от идеи до рецензии; источник: Lu et al., 2026).

Система Autodata (Kulikov et al., 2026) берёт на себя роль специалиста по данным для генерации обучающих и тестовых примеров. Главный агент управляет четырьмя ролями: генератором задач (challenger), слабым решателем (weak solver), сильным решателем (strong solver) и валидатором (verifier). Цель - синтезировать данные «оптимальной» сложности: такие, с которыми справляется сильный решатель, но спотыкается слабый.

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

(Схема генерации данных в Autodata; источник: Kulikov et al., 2026).

Пространство поиска для рабочих процессов огромно. Логично представить проектирование workflow как задачу поиска и решать её алгоритмически, а не вручную. Проект ADAS (Automated Design of Agentic Systems; Hu et al., 2025) формулирует разработку агентов как задачу мета-поиска, где один агент (meta-agent) проектирует сценарии работы для других.

Алгоритм ADAS выглядит так:

1. Создаётся библиотека базовых сценариев (например, Chain-of-Thought или self-refine).
2. Мета-агент пишет код новых агентов, опираясь на существующие примеры из библиотеки. Сначала он создаёт текстовое описание идеи, а затем реализует её в коде.
3. Код проходит две итерации self-refine: модель сначала критикует получившуюся программу, а затем дорабатывает её с учётом замечаний (Madaan et al., 2023).
4. Новый кандидат тестируется. В случае успеха он добавляется в библиотеку. Цикл повторяется.

(Схема работы системы ADAS; источник: Hu et al., 2025).

Проект AFlow (Zhang et al., 2025) представляет рабочий процесс в виде графа: узлы вызывают языковые модели, а рёбра реализуют логику переходов в коде. Оптимизация графа выполняется с помощью алгоритма поиска по дереву Монте-Карло (MCTS):

1. Инициализируется базовый граф $W_0$.
2. Выбирается узел на основе баланса метрик эффективности и случайного исследования (exploration).
3. Узел расширяется: модель генерирует изменённую логику графа на основе данных о прошлых ошибках.
4. Новый граф запускается и оценивается.
5. Если результаты улучшились, новый вариант добавляется в дерево. Процесс повторяется, пока средний балл топ-кандидатов не выйдет на плато.

(Схема оптимизации в AFlow и результаты сравнения с ручными методами и ADAS; источник: Zhang et al., 2025).

Эксперименты показали, что AFlow превосходит как ручные сценарии разработки, так и систему ADAS на задачах QA, математики и программирования.

Самосовершенствующиеся harness-системы (Self-Improving Harness)

Инженерия контекста и проектирование рабочих процессов - это лишь части harness-системы. В идеале нужно совместно оптимизировать всё пространство проектных решений: логику управления контекстом, workflow, права доступа и другие компоненты. В проектах Meta-Harness, ADAS и AFlow ключевым элементом является код - универсальный язык описания программ. По сути, harness - это программный код, определяющий взаимодействие промптов, вызовов инструментов, субагентов, логики ветвления и памяти. Если модель умеет оптимизировать этот код, она получает доступ к огромному пространству вариантов, недоступному при простом переписывании текстовых инструкций.

Проект STOP (Self-Taught Optimizer; Zelikman et al., 2023) стал одним из первых примеров рекурсивного улучшения программного каркаса (scaffolding). Базовый оптимизатор $I_0$ на шаге $t=0$ принимает начальное решение $s$, функцию полезности $u$ и языковую модель $M$, а затем возвращает улучшенное решение $s' = I(u, s; M)$. Цель STOP - улучшать не само решение $s$, а алгоритм оптимизации $I$.

Определим мета-полезность как среднюю полезность алгоритма $I$ на наборе задач $\mathcal{D}$:

$$\hat{u}(I) \triangleq \frac{1}{|\mathcal{D}|}\mathbb{E}_{(u,s)\sim \mathcal{D}}[u(I(u,s; M))]$$

Поскольку улучшение алгоритма оптимизации - это тоже задача оптимизации, мы можем рекурсивно получать новую версию $I_t$ на основе результатов работы предыдущей версии $I_{t-1}$:

$$I_t=I_{t-1}(\hat{u},I_{t-1};M)$$

(Схема алгоритма STOP и примеры найденных им стратегий; источник: Zelikman et al., 2023).

В экспериментах оптимизатор самостоятельно находил сложные стратегии: генетические алгоритмы, разбиение задачи на части, многорукие бандиты для выбора промптов, имитацию отжига, изменение температуры генерации, поиск по дереву и лучевой поиск. Этот результат показывает, что логику harness-систем можно представить как объект программной оптимизации.

Однако важная оговорка из статьи: STOP улучшал средний результат на прикладных задачах при использовании GPT-4, но с более слабыми моделями вроде GPT-3.5 и Mixtral результат ухудшался. Сама по себе рекурсивная структура не сработает - базовая модель должна быть достаточно способной, чтобы развивать этот механизм. Улучшение harness раскрывает потенциал модели, но её собственные возможности остаются ключевым фактором.

Работа Lin et al. (2026) детально разбирает зависимость эволюции harness от способностей моделей. Авторы разделили две способности:

1. Harness-updating: способность генерировать полезные правки для кода harness.
2. Harness-benefit: способность эффективно использовать обновлённый harness для решения конечных задач.

Эксперименты привели к неожиданному выводу: модели разного масштаба (от Qwen3.5-9B до Claude Opus 4.6) показывают примерно одинаковую способность обновлять код harness. Модель на 9 млрд параметров способна предложить навык, по структуре похожий на вариант от Opus. Однако польза от обновлённого harness зависит от масштаба нелинейно: больше всего выиграли модели среднего уровня. Чтобы использовать harness, модель должна вовремя и правильно вызывать инструменты, а также следовать инструкциям в длинных задачах.

(Результаты работы Lin et al. 2026; способность обновлять harness стабильна у разных моделей, но польза от него распределяется нелинейно).

Проект Self-Harness (Zhang et al., 2026) предлагает агентам улучшать собственный harness через цикл «предложение - оценка - принятие».

(Этапы работы Self-Harness; источник: Zhang et al. 2026).

Цикл Self-Harness включает три стадии:

1. Поиск слабых мест (Weakness mining). Запуск текущего harness $h_t$ на задачах и сбор логов. На поверхности разные запуски могут падать с одинаковой ошибкой (например, таймаут), но иметь разные причины. Поэтому система собирает детальный отчёт: конечную ошибку, действия агента и логику принятия решений, чтобы докопаться до первопричины сбоя.
2. Предложение изменений (Harness proposal). Модель предлагает точечные правки кода harness. Ей передаётся контекст: доступные для редактирования части harness, выявленные паттерны ошибок, примеры успешных запусков (которые нельзя ломать) и история прошлых попыток. Правки должны устранять повторяющиеся системные ошибки, а не специфические сложности конкретных задач.
3. Валидация изменений (Proposal validation). Кандидаты проверяются регрессионными тестами на обучающей выборке $D_\text{in}$ (решена ли проблема) и отложенной выборке $D_\text{out}$ (не сломалось ли что-то другое). Изменения принимаются и переходят в версию $h_{t+1}$ только при улучшении результатов без регрессии на обеих выборках.

На бенчмарке Terminal-Bench-2 модели MiniMax M2.5, Qwen3.5-35B-A3B и GLM-5 находили инструкции для собственного harness, которые учитывали слабые места каждой модели и повышали долю решённых задач на отложенной выборке.

Тем не менее такой подход вызывает опасения. Если программа может менять код собственной ОС (или среды выполнения), это нарушает границы абстракции. Доступные для редактирования интерфейсы должны жёстко ограничиваться, а механизмы безопасности и контроля доступа обязаны находиться за пределами этого цикла оптимизации. В противном случае сохраняется высокий риск взлома метрик (reward hacking).

Фреймворк Agentic Harness Engineering (AHE; Lin et al., 2026) сосредоточен на наблюдаемости (observability): при сбое выполнения нужно определить, какой компонент за него отвечает, а каждое изменение связать с конкретными данными о работе системы.

AHE строит замкнутый цикл оптимизации на трёх столпах наблюдаемости:

• Наблюдаемость компонентов (Component observability): каждый изменяемый элемент harness представлен файлом в репозитории. Harness делится на 7 частей: системный промпт, описания инструментов, их реализация, промежуточное ПО (middleware), навыки (skills), конфигурации субагентов и долгосрочная память. Каждая ошибка сопоставляется с конкретным компонентом.
• Наблюдаемость опыта (Experience observability): траектории запусков анализируются агентом-отладчиком (Agent debugger). Вместо чтения сырых логов он генерирует структурированные отчёты о причинах успеха или сбоя для каждой задачи, которые затем собираются в общий обзор. Это экономит контекст модели.
• Наблюдаемость решений (Decision observability): каждая правка сопровождается гипотезой. Агент-эволюционер (Evolve agent) решает, какой компонент редактировать, описывает логику и делает предсказание результатов.

В AHE действуют жёсткие ограничения для защиты от взлома наград: код валидатора, среда выполнения и параметры LLM доступны только для чтения (менять можно лишь рабочую директорию harness). Каждая правка фиксируется в «манифесте» с указанием конкретной ошибки, её причины, метода исправления и прогноза изменений. На Terminal-Bench-2 AHE превзошёл созданные людьми обвязки OpenCode, Terminus-2 и Codex на большинстве уровней, но не на Hard tier; некоторые другие методы автоматической эволюции harness тоже оказались сильнее. Полученный harness без дополнительной эволюции перенесли на SWE-bench Verified, где он также улучшил результаты.

Эволюционный поиск (Evolutionary Search)

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

Ранее эволюционный поиск применялся в промпт-инжиниринге. Проект Promptbreeder (Fernando et al., 2023) оптимизировал промпты мутациями, причем инструкции по мутации промптов тоже развивались в процессе отбора. Система GEPA (Agrawal et al., 2025) объединила эволюционный поиск с рефлексией модели над прошлыми ошибками выполнения.

Проект AlphaEvolve (Novikov et al., 2025) реализует эволюционный поиск в среде coding-агентов. Система хранит пул программ-кандидатов и просит LLM генерировать diff-файлы для их улучшения.

(Схема работы AlphaEvolve; источник: Novikov et al., 2025).

Особенности дизайна AlphaEvolve:

• Промпт включает родительские программы, их результаты, инструкции и мета-информацию.
• У агента есть доступ к репозиторию, но редактируемые блоки кода чётко выделены комментариями # EVOLVE-BLOCK-START и # EVOLVE-BLOCK-END.
• Мета-промпты развиваются вместе с кодом программ по указаниям LLM. Исследования абляций подтверждают пользу совместной эволюции программ и мета-инструкций.

(Графики абляций AlphaEvolve; источник: Novikov et al., 2025).

Новые модификации алгоритма развивают эту идею. ThetaEvolve (Wang et al., 2025) объединяет эволюционный поиск с обучением с подкреплением (RL), а DemoEvolve (Che et al., 2026) добавляет в базу примеров демонстрации от инженеров-людей в качестве ориентира. Проект ShinkaEvolve (Lange et al., 2025) повышает эффективность генерации кандидатов (sampling efficiency) за счёт трёх приёмов:

• Балансировка выбора родителей по качеству решений и числу потомков.
• Фильтрация дубликатов по косинусному сходству эмбеддингов кода (code-novelty rejection sampling).
• Анализ успешных шаблонов во встроенном черновике (meta-scratchpad) для направления мутаций.

В отличие от оптимизации конкретных алгоритмов, Darwin Gödel Machine (DGM; Zhang et al., 2025) нацелена на эволюцию репозитория самого harness. Coding agent изменяет собственный код harness. Развитием этой идеи стали «Гиперагенты» (Hyperagents; Zhang et al., 2026), где мета-агент управляет изменением рабочих агентов для решения новых задач.

Алгоритм DGM работает по шагам:

1. Инициализируется пул с одним базовым агентом.
2. На каждой итерации выбирается родительский агент. Вероятность выбора пропорциональна его эффективности и обратно пропорциональна числу его «детей».
3. Выбранный агент анализирует логи тестов и предлагает изменения в код своего harness, создавая ветку репозитория для нового агента. Правки вносятся инструментами bash и editor.
4. Новые агенты проходят оценку качества. Прошедшие фильтр добавляются в пул. Цикл повторяется.

DGM запускает эволюцию кода harness при замороженной базовой модели. В экспериментах с Claude 3.5 Sonnet агенты, созданные DGM, улучшили показатели на SWE-bench Verified с 20% до 50%, а на Polyglot - с 14,2% до 30,7%.

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

Совместная оптимизация с весами модели (Joint Optimization)

Эволюция harness меняет внешнюю непараметрическую систему. Более широкий цикл самосовершенствования может одновременно обновлять и harness, и веса модели. Это можно реализовать через автоматическое исследование конвейера обучения или через непрерывное обучение (continual learning) прямо во время инференса.

Фреймворк SIA (Hebbar et al., 2026) - одна из первых попыток объединить доработку harness и обновление параметров модели в одном цикле. Он включает три роли:

• Мета-агент (Meta-Agent): проектирует базовый harness.
• Рабочий агент (Task-Specific Agent): выполняет целевую задачу.
• Агент обратной связи (Feedback-Agent): решает, что именно обновлять на основе логов траекторий - код harness или веса модели.

(Схема принятия решений в SIA; источник: Hebbar et al., 2026).

Пока результаты SIA сложно интерпретировать однозначно из-за особенностей экспериментов. Например, рабочий агент был значительно слабее мета-агента и агента обратной связи: gpt-oss-120b сравнивали с Claude Sonnet 4.6. Базовые методы сравнения также были слишком слабыми, поэтому доказательства пока нельзя считать убедительными. Тем не менее направление выглядит перспективно. Проблемы стабильности обучения и закона Гудхарта здесь по-прежнему актуальны.

Проект Continual Harness (Karten et al., 2026) тестировал этот подход в условиях долгих игровых сессий, сочетая развитие harness с дообучением модели стратегии через дистилляцию меток сильного учителя.

Вызовы будущего

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

В работе Trehan & Chopra (2026) авторы проверяли, могут ли языковые модели превратить исследовательскую идею в готовую статью с минимальным каркасом и базовым набором инструментов (read_file, write_file, llm_search, list_files). Агенты работали в изолированном пространстве в трёх областях (модели мира, мультиагентный RL, ИИ-безопасность). Каждое направление содержало около 50 авторитетных документов для вдохновения. Эксперты отобрали только 4 идеи для полного прохождения конвейера, и лишь одну удалось развить до полноценной статьи. Авторы выделили 6 типичных ошибок в работе агентов:

1. Смещение к привычным решениям из обучающих данных. Агенты используют старые библиотеки, устаревшие консольные команды и шаблоны, не соответствующие реальному репозиторию.
2. Искажение реализации под давлением сложности (Implementation drift). Столкнувшись с техническими трудностями при реализации сложной идеи, модель незаметно упрощает её до стандартного решения.
3. Деградация памяти и контекста. В долгих проектах ключевые детали быстро теряются, если логи не фиксируются в виде постоянных артефактов на диске.
4. Излишний оптимизм. Модель рапортует об успехе, игнорируя шумные или провальные результаты экспериментов. Бубек и др. (2025) описывают это как паттерн «p-hacking and eureka-ing», когда модель маскирует костылями шум в данных и заявляет о победе (подробнее см. Bubeck et al., 2025).
5. Нехватка неявного опыта (craft knowledge). Модели сложно спрогнозировать реальную трудоёмкость реализации, оценить достоверность результатов эксперимента или выбрать корректные базовые методы (baselines) для сравнения.
6. Слабый научный вкус. Эксперименты могут быть технически выполнимыми, но бесполезными, поскольку не отвечают на ключевые исследовательские вопросы.

На пути к полноценному RSI исследователи сталкиваются со следующими фундаментальными ограничениями:

1. Слабые и нечёткие валидаторы. Многие задачи не имеют быстрых и точных способов автоматической проверки. Циклы самосовершенствования лучше работают там, где критерии объективны и их можно превратить в сигнал для обучения с подкреплением. Научную новизну и долгосрочную ценность измерить сложнее. «Научный вкус» включает умение ставить задачи, планировать эксперименты и отличать ценную аномалию в результатах от обычного бага.
2. Жизненный цикл контекста и памяти. С ростом автономности агентов объём сохраняемой ими информации увеличивается. Harness должен эффективно сжимать и структурировать память. Здесь напрашивается аналогия с человеческим мозгом: инженерия контекста со временем должна стать частью структуры интеллекта модели, а не внешней программной надстройкой.
3. Управление отрицательными результатами. Научная литература страдает от систематической ошибки выжившего (публикуют только успехи). Языковые модели, обученные на этих данных, плохо умеют вовремя отказываться от неверных гипотез, признавать неудачи и фиксировать отрицательный результат. Хороший harness должен сохранять и анализировать неудачные попытки - это лучший способ сократить пространство поиска решений.
4. Схлопывание разнообразия (Diversity collapse). Циклы эволюционного поиска и RL быстро скатываются к эксплуатации известных высокоэффективных паттернов. Нужны специальные механизмы, удерживающие популяцию от вырождения в копии одного и того же решения. Это критично для фундаментальных исследований, где перспективный путь на первых порах может выглядеть невыигрышно с точки зрения текущих метрик.
5. Взлом награды (reward hacking). Оптимизационный цикл максимизирует целевой сигнал любой ценой. Если награда привязана к юнит-тестам, агент начнет подгонять код под тесты; если к оценке модели-судьи - научится льстить судье; если к бенчмаркам - эксплуатировать их недоработки. Валидаторы и контроль прав доступа должны находиться за пределами контура оптимизации harness. Разработка масштабируемых и безопасных механизмов автоматического надзора остается открытой темой.
6. Долгосрочная перспектива. Стандартные награды в учебной песочнице оценивают отдельный запуск и редко учитывают последствия для системы. Например, coding agents уже ускорили повседневную разработку, но их цели обычно ограничены текущей задачей. Такие проверки не измеряют сопровождаемость, границы владения кодом, стоимость миграции, обратную совместимость и будущую сложность отладки. Чтобы учитывать эти факторы, стандартные методы обучения с подкреплением в песочницах, включая RLVR, придётся дополнить более долгосрочными критериями.
7. Роль человека в цикле. Люди должны переходить на более высокие уровни абстракции, а не полностью исключаться из процесса. При проектировании ИИ-систем нужно заранее определить, когда и в какой форме привлекать экспертов для надзора и обратной связи.

Приложение: Полезные бенчмарки

• PaperBench: воссоздание с нуля 20 научных статей ICML 2024 (уровня Spotlight и Oral), включая понимание вклада авторов, создание кодовой базы и проведение экспериментов.
  • Каждая задача воссоздания разбивается на подзадачи, оцениваемые по отдельности.
  • Всего 8 316 проверочных критериев, разработанных совместно с авторами статей.
  • Лучшая модель на момент бенчмарка (Claude 3.5 Sonnet) набрала ~21%, не превзойдя исследователей с докторской степенью в машинном обучении.
  • Включает сам PaperBench, облегчённую версию PaperBench Code-Dev и систему JudgeEval.
• CORE-Bench: оценка вычислительной воспроизводимости опубликованных исследований.
  • 270 задач на основе 90 статей из компьютерных и социальных наук, а также медицины.
  • Задачи требуют воспроизвести результаты по готовому коду и данным.
  • Содержит разные уровни сложности, задачи только с текстом и мультимодальные задания (vision-language).
  • Лучшие агенты на момент публикации (GPT-4o и GPT-4o-mini) достигли лишь 21% точности на самом сложном уровне.
• ScienceAgentBench: оценка LLM-агентов в задачах научного анализа данных.
  • 102 задачи из 44 рецензируемых публикаций в четырёх дисциплинах: математика, химия, биология и география.
  • Охватывает базовую обработку данных, разработку моделей, анализ и визуализацию информации.
• RE-Bench: сравнение передовых ИИ-агентов и экспертов в реальных задачах ML-разработки.
  • 7 сложных открытых сред машинного обучения.
  • Каждая задача включает функцию оценки, стартовое и эталонное решение и может быть выполнена не более чем на 8 ускорителях H100.
  • Примеры: оптимизация GPU-ядер, запуск scaling-law экспериментов, исправление эмбеддингов, файнтюнинг GPT-2.
  • Включает данные о 71 попытке длительностью по 8 часов от 61 эксперта.
  • Эксперты набрали ненулевой балл в 82% попыток; в 24% случаев сравнялись или превзошли эталон.
  • При ограничении времени в 2 часа ИИ-агенты набрали в 4 раза больше баллов, но при 8- и 32-часовых лимитах люди показали лучшую динамику и обогнали модели.
• MLE-bench: оценка ML-агентов в оффлайн-соревнованиях Kaggle.
  • Содержит 75 соревнований Kaggle для проверки навыков подготовки данных, обучения моделей и отправки прогнозов на проверку.
  • Лучшая конфигурация (модель o1-preview с фреймворком AIDE) смогла получить условную бронзовую медаль в 16,9% соревнований.
• KernelBench: проверка корректности и скорости сгенерированных GPU-ядер.
  • 250 задач PyTorch для оценки способности LLM писать быстрые ядра CUDA/Triton.
  • Ключевая метрика - процент сгенерированных ядер, которые работают корректно и при этом быстрее базового решения.

Литература

1. Good, I. J. “Speculations Concerning the First Ultraintelligent Machine.” Advances in Computers, 6:31-88, 1965.
2. Yudkowsky, Eliezer. “Recursive Self-Improvement.” LessWrong, 2008.
3. Choi, et al. “Anchored Self-Play for Code Repair.” ICML 2026.
4. Zhao, et al. “Absolute Zero: Reinforced Self-play Reasoning with Zero Data.” arXiv preprint arXiv:2505.03335, 2025.
5. Yuan, et al. “Self-Rewarding Language Models.” arXiv preprint arXiv:2401.10020, 2024.
6. Chen, et al. “Self-Play Fine-Tuning Converts Weak Language Models to Strong Language Models.” ICML 2024.
7. Zhang, et al. “Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models.” ICLR 2026.
8. Ye, et al. “Meta Context Engineering via Agentic Skill Evolution.” arXiv preprint arXiv:2601.21557, 2026.
9. Lee, et al. “Meta-Harness: End-to-End Optimization of Model Harnesses.” arXiv preprint arXiv:2603.28052, 2026.
10. Lu, et al. “Towards end-to-end automation of AI research.” Nature, 651:914-919, 2026.
11. Meng, et al. “ScientistOne: Towards Human-Level Autonomous Research via Chain-of-Evidence.” arXiv preprint arXiv:2605.26340, 2026.
12. Kulikov, et al. “Autodata: An agentic data scientist to create high quality synthetic data.” arXiv preprint arXiv:2606.25996, 2026.
13. Hu, Lu, and Clune. “Automated Design of Agentic Systems.” ICLR 2025.
14. Madaan, et al. “Self-Refine: Iterative Refinement with Self-Feedback.” NeurIPS 2023.
15. Zhang, et al. “AFlow: Automating Agentic Workflow Generation.” ICLR 2025.
16. Zelikman, et al. “Self-Taught Optimizer (STOP): Recursively Self-Improving Code Generation.” COLM 2024.
17. Zhang, et al. “Self-Harness: Harnesses That Improve Themselves.” arXiv preprint arXiv:2606.09498, 2026.
18. Fernando, et al. “Promptbreeder: Self-Referential Self-Improvement Via Prompt Evolution.” arXiv preprint arXiv:2309.16797, 2023.
19. Agrawal, A. et al. “GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning.” arXiv preprint arXiv:2507.19457, 2025.
20. Novikov, et al. “AlphaEvolve: A coding agent for scientific and algorithmic discovery.” arXiv preprint arXiv:2506.13131, 2025.
21. Lange, Imajuku, and Cetin. “ShinkaEvolve: Towards Open-Ended And Sample-Efficient Program Evolution.” arXiv preprint arXiv:2509.19349, 2025.
22. Wang, et al. “ThetaEvolve: Test-time Learning on Open Problems.” arXiv preprint arXiv:2511.23473, 2025.
23. Zhang, et al. “Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents.” arXiv preprint arXiv:2505.22954, 2025.
24. Zhang, et al. “Hyperagents.” arXiv preprint arXiv:2603.19461, 2026.
25. Yuksekgonul, et al. “Learning to Discover at Test Time.” arXiv preprint arXiv:2601.16175, 2026.
26. Riaz, et al. “Epistemic Uncertainty for Test-Time Discovery.” arXiv preprint arXiv:2605.11328, 2026.
27. Hebbar, et al. “SIA: Self Improving AI with Harness & Weight Updates.” arXiv preprint arXiv:2605.27276, 2026.
28. Trehan and Chopra. “Why LLMs Aren’t Scientists Yet: Lessons from Four Autonomous Research Attempts.” arXiv preprint arXiv:2601.03315, 2026.
29. Bubeck, et al. “Early science acceleration experiments with GPT-5.” arXiv preprint arXiv:2511.16072, 2025.
30. Starace, et al. “PaperBench: Evaluating AI’s Ability to Replicate AI Research.” ICML 2025.
31. Wijk, et al. “RE-Bench: Evaluating frontier AI R&D capabilities of language model agents against human experts.” ICML 2025.
32. Chan, et al. “MLE-bench: Evaluating Machine Learning Agents on Machine Learning Engineering.” arXiv preprint arXiv:2410.07095, 2024.
33. Chen, et al. “ScienceAgentBench: Toward Rigorous Assessment of Language Agents for Data-Driven Scientific Discovery.” ICLR 2025.
34. Siegel, et al. “CORE-Bench: Fostering the Credibility of Published Research Through a Computational Reproducibility Agent Benchmark.” TMLR 2024.
35. Ouyang, et al. “KernelBench: Can LLMs Write Efficient GPU Kernels?” arXiv preprint arXiv:2502.10517, 2025.
36. Lin, et al. “Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents.” arXiv preprint arXiv:2605.30621, 2026.
37. Lin, et al. “Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses.” arXiv preprint arXiv:2604.25850, 2026.
38. Karten, et al. “Continual Harness: Online Adaptation for Self-Improving Foundation Agents.” arXiv preprint arXiv:2605.09998, 2026.
39. Che, et al. “DemoEvolve: Overcoming Sparse Feedback in Agentic Harness Evolution with Demonstrations.” arXiv preprint arXiv:2605.24539, 2026.