Инжиниринг harness-систем для самоулучшения

Концепция рекурсивного самоулучшения (RSI) восходит к И. Дж. Гуду (1965), который определил «сверхразумную машину» как систему, способную превзойти человека во всех видах интеллектуальной деятельности и проектировать более совершенные машины для собственного улучшения. Юдковский (2008) использовал термин «рекурсивное самоулучшение» для конкретного контура обратной связи: ИИ использует текущие возможности, чтобы улучшать механизм, который эти возможности порождает.

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

Я отдельно подчеркиваю «систему развёртывания», потому что слой между «сырой» моделью и реальным контекстом, по-видимому, столь же важен, как и базовый интеллект модели (то есть метрики сразу после предобучения). Harness-системы — важная часть внедрения ИИ; это видно по успеху кодовых агентов вроде Claude Code и Codex. Harness — инфраструктура вокруг базовой модели: она оркестрирует выполнение, задаёт, как модель рассуждает и планирует, вызывает инструменты, управляет контекстом, хранит артефакты и оценивает результат.

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

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

По сравнению с ранними агентными фреймворками, где «агент = LLM + память + инструменты + планирование + действие», harness-инжиниринг дополнительно включает проектирование рабочих процессов (например, loop engineering), оценивание, контроль прав доступа и управление постоянным состоянием. Это уже не просто шаблоны промптов; это ближе к проектированию runtime и программных систем: как модель наблюдает, действует, запоминает, проверяет себя и улучшается.

Дизайн должен быть намеренно простым и обобщаемым, с опорой на существующие практики software engineering, чтобы использовать накопленные знания. Есть и сильная аналогия между операционными системами и harness-системами. Как и ОС, harness должен инкапсулировать сложную логику, сохраняя простой интерфейс. Одновременно конфиги, интерфейсы инструментов и другие протоколы, вероятно, будут постепенно стандартизироваться в индустрии.

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

Определение рабочего процесса, в рамках которого модель может работать, тестироваться и итерировать, — ключ к автоматизации. Репозиторий Карпати autoresearch (https://github.com/karpathy/autoresearch) — наглядный пример того, как такой процесс можно построить. Типичный рабочий процесс следует целевому циклу: спланировать, выполнить, наблюдать/протестировать, улучшить и снова выполнить до тех пор, пока цель не достигнута. В процессе могут возникать проактивные запросы к пользователю для уточнения постановки задачи или предпочтений по выполнению.

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

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

Повторяющийся паттерн в системах с длинным горизонтом планирования — простой контроль над богатыми состояниями и артефактами. Harness не должен держать весь рабочий процесс и все логи только в контексте; вместо этого долговечное состояние должно храниться в файлах. В длинных агентных прогонах артефакты вроде логов экспериментов, diff’ов кода, саммари статей, трасс ошибок и прошлых траекторий часто вырастают далеко за пределы контекстного окна, под которое обучалась модель.

Навык читать, писать и редактировать файловую систему (обычно через команды bash) — базовый для LLM; поэтому управление постоянной памятью в простой форме файлов естественно выигрывает от роста базовых способностей модели.

Паттерн 3: Субагенты и фоновые задачи

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

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

Кейс: Harness кодового агента

Базовый интерфейс массовых кодовых агентов уже стабилизировался между Claude Code, Codex, OpenCode и агентами в стиле Cursor. Обычно используется цикл вида:

Имея доступ к набору инструментов, кодовый агент способен разрабатывать и отлаживать задачи в репозитории — подобно тому, как разработчики работают в IDE.

(Список не исчерпывающий; приведен для демонстрации. Если интересно, см. это.)

Группа	Определения инструментов
Файловая система	Поиск файлов: glob, grep, ls Чтение файлов: read, read_many Изменение файлов: write (полная перезапись файла), edit (точная замена строки по совпадению), multi_edit, apply_patch (применение структурированного patch/diff)
Выполнение в shell	Запуск команд: bash, PowerShell
IO	lsp, git-инструменты вроде git_status, git_diff, git_commit
Внешний контекст	MCP-инструменты, Skills
Веб-поиск	web_search, web_fetch, browser-инструменты
Артефакты	Чтение документов и изображений; генерация HTML и изображений
Фоновые процессы	Например: CronCreate, CronDelete, CronList
Делегирование агентам	Например: spawn_agent, resume_agent, wait_agent, list_agents, close_agent, interrupt_agent и т.д.

Слой harness vs базовый интеллект?

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

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

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

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

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

Context engineering

Если просто добавлять в контекст все ответы инструментов и все генерации модели, объём быстро выходит из-под контроля. Это особенно заметно, когда горизонт агентной задачи существенно растёт. Управление контекстом — это слой, который формирует более структурированный и компактный контекст для LLM и управляет постоянным состоянием. Нет сомнений, что исследования длинного контекста будут продолжаться, но на практике интеллект при работе с длинным контекстом и context engineering сейчас нередко переплетены.

Agentic Context Engineering (ACE; Zhang et al. 2025) рассматривает контекст как эволюционирующую «книгу правил», а не как постоянно удлиняющийся промпт. В ней три компонента, поддерживающие единый контекстный playbook в виде пунктов, каждый с идентификатором и описанием.

1. Generator: создает траектории выполнения задачи, опираясь на пункты.
2. Reflector: извлекает инсайты из успешных и неуспешных траекторий.
3. Curator: обновляет структурированный контекст инкрементальными, поэлементными записями.

Чтобы предотвратить коллапс контекста и смещение к излишней краткости при итеративных переписываниях, в ACE принято важное решение: curator не переписывает целиком большой prompt blob. Вместо этого он выдает набор структурированных пунктов в формате (identifier, description), а затем эти пункты сливаются в структурированный контекстный журнал детерминированной логикой. Контекстные элементы периодически уточняются и дедуплицируются.

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

Навык 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^*\) для фиксированного навыка \(s\) на обучающих данных, а внешний уровень ищет оптимальный навык, который дает лучшую метрику на валидации:

\[ \text{Inner: }c_s^*=\arg\max_{c_s}J_\text{train}(c_s;s)\quad \text{Outer: }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}\). Мета-агент выполняет кроссовер над предыдущими навыками, чтобы создать новый навык для задачи \(\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)\).

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

\[ \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-систем.

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

• Вся история выполнения доступна через файловую систему, поэтому coding-агент использует команды вроде grep или cat, чтобы читать ее, вместо того чтобы «заталкивать» все в один prompt-контекст.
• Предложенный harness — это словарь в файловой системе, содержащий собственный исходный код, метрики, траектории прогонов и обновления состояния.
• Цикл meta-harness итеративно создает новые harness-системы, и сохраняются только прошедшие квалификацию.

Ключевой вывод ясен: как только дизайн harness превращается в исполнимое пространство поиска, сильный coding-агент может использовать то же пространство дизайна, что и инженеры-люди.

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

Рабочие процессы в harness-инжиниринге могут проектироваться вручную доменными экспертами. На примере auto-research предложено и протестировано много фреймворков. Система AI Scientist (Lu et al. 2026) строит pipeline для предложения исследовательских идей, написания кода, запуска экспериментов, анализа результатов, написания рукописи и рецензирования.

Meng et al. (2026) делают верифицируемость центральным ограничением дизайна в ScientistOne: каждое утверждение (цитата, число, метод, вывод) должно трассироваться к источнику доказательства и проходить проверки Chain-of-Evidence.

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

В Autodata промпт challenger итеративно обновляется по обратной связи от solver’ов и верификатора. Ограничение подхода в том, что синтезированные задачи используются для дообучения weak solver, но не strong solver; если цикл не может итеративно усиливать сильную модель, это скорее косвенная дистилляция по распределению сгенерированных промптов и слабее напоминает полноценное RSI.

Пространство дизайна рабочих процессов огромно, и естественно рассматривать их проектирование как задачу поиска; следовательно, хорошие решения должны находиться алгоритмически, а не только ручной настройкой. В этом направлении Automated Design of Agentic Systems (ADAS; Hu et al. 2025) формулирует дизайн агентов как задачу оптимизации — «поиск мета-агента», где мета-агент предлагает новые конструкции агентных рабочих процессов.

1. Инициализировать архив агентных рабочих процессов простыми агентами, например CoT и self-refine.
2. Попросить мета-агента программировать новых агентов, целиком в коде, опираясь на существующие решения из архива.
   • Сначала мета-агент генерирует высокоуровневое описание нового рабочего процесса, затем реализует его в коде.
   • Затем черновая программа проходит два шага self-refine (то есть сначала модель дает обратную связь, а затем та же модель улучшает ранее сгенерированный результат на основе этой обратной связи; Madaan et al. 2023), чтобы проверить новизну.
3. Оценить каждого нового кандидата и возвращать успешные варианты в архив.
4. Повторять шаги 2-3, пока не достигнуто максимальное число итераций.

AFlow (Zhang et al. 2025) представляет агентный рабочий процесс как граф, где узлы — действия с вызовом LLM, а рёбра реализуют логические операции в коде. Оптимизация рабочего процесса основана на MCTS (Monte Carlo Tree Search):

1. Инициализировать в дереве стартовый рабочий процесс \(W_0\) шаблоном.
2. Выбрать узел рабочего процесса с мягкой смесью score и равномерного exploration.
3. Расширить его, попросив LLM сгенерировать модифицированный рабочий процесс с учётом результатов оценки.
4. Исполнить и оценить новый рабочий процесс.
5. Добавить его обратно в дерево, если новый рабочий процесс улучшился в рамках бюджета \(N\) раундов.
6. Повторять шаги 2-5 и остановиться, когда top-\(k\) средний score выходит на плато или исчерпан бюджет.

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

Самоулучшающийся harness

И context engineering, и проектирование рабочих процессов — лишь части harness-системы. Нужно искать по всему пространству дизайна и совместно оптимизировать логику управления контекстом, рабочие процессы, права доступа и многие другие компоненты harness. Как видно в работах Meta-Harness, ADAS и AFlow, ✨код✨ — это универсальный язык задания программ и систем. Проще говоря, harness — это код, который программирует, как вместе работают промпты, вызовы инструментов, субагенты, управление потоком, память и логика рабочего процесса. Если LLM может оптимизировать код, исполняющий агентов, он получает доступ к гораздо более широкому пространству дизайна, чем при ручных промптах.

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

Сначала определим мета-utility как среднюю полезность заданной функции-улучшателя \(I\) на наборе нижестоящих задач \(\mathcal{D}\):

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

Поскольку улучшение самой функции-улучшателя — тоже задача оптимизации, можно рекурсивно получать новую версию \(I_t\) из производительности \(I_{t-1}\), измеренной мета-utility, через обновление самоулучшения:

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

В экспериментах Zelikman et al. (2023) улучшенный улучшатель обнаруживал разные стратегии: генетические алгоритмы, декомпозицию и улучшение частей, multi-armed prompt bandits, simulated annealing, варьирование temperature и beam/tree search. Это аналогично тому, как рабочий процесс harness-системы можно представить как объект оптимизации.

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

Более свежая работа, Self-Harness (Zhang et al. 2026), использует LLM-агентов для улучшения собственного harness через цикл propose-evaluate-accept.

Цикл Self-Harness состоит из трех стадий:

1. Weakness mining: кластеризация сбоев в паттерны ошибок, привязанные к верификатору.
   • Текущий harness \(h_t\) используется для оценки на задачах, и собираются трассировки выполнения для анализа.
   • Важно, что два прогона могут иметь одинаковый результат верификатора в логах ошибок (например, timeout или missing artifact), но разные причинные механизмы. Поэтому нужна подробная запись о сбое: итоговая причина на уровне верификатора, причинный статус релевантного поведения агента и абстрактный механизм агента, проявившийся в трассировке — чтобы находить корневые причины.
2. Harness proposal: предложение ограниченных правок harness на основе найденных паттернов сбоев.
   • Та же модель вызывается под \(h_t\) в роли proposer.
   • Модель получает ограниченный контекст предложения: (1) редактируемые поверхности текущего harness, (2) паттерны сбоев, привязанные к верификатору, из системы оценки, (3) записи успешного поведения, которое нужно сохранить, и (4) сводки ранее пробованных правок.
   • Правки harness должны преимущественно устранять повторяющиеся адресуемые ошибки (например, не специфическую сложность отдельной задачи), которые можно исправить узкими изменениями.
   • Кандидаты правок harness должны быть различными и разнообразными.
3. Proposal validation: валидация и слияние квалифицированных правок для создания нового harness \(h_{t+1}\).
   • Кандидатные правки оцениваются регрессионными тестами на обучающей выборке \(D_\text{in}\) (проверка, устранена ли выявленная слабость) и контрольной выборке \(D_\text{out}\) (проверка, не внесены ли другие неизвестные проблемы).
   • Кандидаты принимаются только при отсутствии регрессии и на обучающей, и на контрольной выборке.
   • Принятые кандидаты сливаются для обновления harness до \(h_{t+1}\); отклоненные — логируются без изменения активного harness.

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

Работы типа Self-Harness вызывают у меня опасение: если программе разрешить редактировать операционную систему, нарушаются границы абстракции. Редактируемая поверхность должна быть грамотно спроектирована, а контуры контроля прав доступа и безопасности должны находиться вне этого цикла. Все вызовы, связанные с reward hacking, остаются актуальными.

Эволюционный поиск

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

Эволюционный поиск ранее применялся в prompt engineering. Promptbreeder (Fernando et al. 2023) оптимизирует task-specific промпты через богатый набор операций мутации, и что интересно, сами mutation prompts (инструкции для LLM по мутации task prompt) тоже улучшаются эволюционно. GEPA (Agrawal et al. 2025) сочетает prompting на базе рефлексии с эволюционным поиском и использует рефлексию на естественном языке по траекториям проб и ошибок для предложения обновлений промпта.

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

В дизайне AlphaEvolve важны несколько деталей:

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

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

Недавние варианты, такие как ThetaEvolve (Wang et al. 2025), объединяют эволюционный поиск с RL и in-context learning. ShinkaEvolve (Lange et al. 2025), в свою очередь, добавляет три новых компонента для повышения эффективности сэмплирования LLM:

• Более эффективное исследование пространства за счёт выбора родителей, балансирующего ранг производительности и число потомков.
• Rejection sampling по новизне кода: отбрасываются кандидаты, слишком похожие на текущую популяцию по косинусной близости эмбеддингов.
• Выделение хороших паттернов в успешных решениях в мета-блокноте (meta-scratchpad) для направления будущих мутаций.

В отличие от перечисленных методов, сосредоточенных на улучшении решения, Darwin Gödel Machine (DGM; Zhang et al. 2025) явно нацелен на эволюцию редактируемого репозитория harness-кода с LLM-based coding-агентом. Точнее, этому агенту разрешено модифицировать собственный harness. В последующей работе по Hyperagents (Zhang et al. 2026) введен мета-агент, управляющий тем, как модифицировать существующих task-агентов для создания новых.

1. Начать с одного coding-агента в пуле.
2. На каждой итерации выбирать одного родителя с вероятностью, пропорциональной его производительности и обратно пропорциональной числу его «детей», чтобы модифицировать его и породить новых агентов.
3. Выбранный родительский агент анализирует собственный benchmark evaluation log и предлагает улучшения в своей harness codebase для получения новой версии coding-агента. Редактирование кода реализовано двумя базовыми инструментами: (1) bash (аргументы: <bash_command>) и (2) editor (аргументы: view/create/edit <file_path>).
4. Новые coding-агенты оцениваются, и только варианты с достаточно высокой производительностью добавляются обратно в пул.
5. Повторять шаги 2-4 до выполнения критериев остановки.

DGM — это эволюция harness при фиксированной модели. В экспериментах с Claude 3.5 Sonnet как базовой LLM и простыми начальными конфигами harness агенты, найденные DGM, сопоставимы или превосходят вручную собранных агентов на SWE-bench Verified (с 20% до 50%) и Polyglot (с 14.2% до 30.7%).

Это семейство методов хорошо работает там, где кандидаты автоматически оцениваемы и их fitness легко количественно измерить — например, умножение матриц, оптимизация GPU kernels, алгоритмические соревнования, планирование в дата-центрах. Оно хуже работает в доменах, где оценка медленная, неоднозначная или в основном эвристическая. Также остаются вопросы эффективности вычислений и эффективности самой эволюции.

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

Эволюция harness изменяет непараметрическую систему вокруг модели. Чтобы обеспечить полное самоулучшение, можно одновременно разрешить модели обновлять собственные веса. Обновление весов может реализовываться через улучшения training pipeline модели или continual learning во время инференса. Тема continual learning заслуживает отдельного поста в будущем.

SIA (Hebbar et al. 2026) — ранняя попытка объединить улучшение harness и обновление параметров модели в одном оптимизационном цикле с тремя компонентами:

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

В экспериментах SIA есть несколько смешивающих факторов, из-за которых результаты трудно интерпретировать. Например, task-specific агент существенно слабее моделей, используемых для Meta-Agent и Feedback-Agent (gpt-oss-120b vs Claude Sonnet 4.6), а baseline’ы слишком слабы, чтобы чисто сопоставлять с родственными методами. Я считаю направление интересным, но текущие доказательства — предварительными. При этом многие проблемы, такие как стабильность обучения и эффект Гудхарта, по-прежнему открыты.

Будущие вызовы

Линия AI Scientist — сильная демонстрация того, что экспертно спроектированный harness способен координировать большую часть цикла auto-research, в частности в формате написания исследовательских статей. Но производство статей не тождественно научному открытию. Система может написать правдоподобную рукопись и при этом содержать вымышленные цитаты, дрейф реализации или слабые экспериментальные результаты.

Trehan & Chopra (2026) проверяли, могут ли LLM пройти путь от исследовательской идеи до статьи с минимальной вспомогательной инфраструктурой (scaffolding) и базовыми инструментами (то есть read_file, write_file, llm_search, list_files). Для каждой идеи выделялось отдельное рабочее пространство, где агенты могли генерировать и читать документы как часть контекста. Эксперименты проводились в трех доменах (world models, multi-agent RL, AI safety & alignment), по 45-50 качественных seed-документов в каждом для вдохновения новых идей. Полный pipeline запустили только для четырех идей, и лишь одна была полностью доведена до статьи. Авторы наблюдали шесть повторяющихся режимов сбоев:

• Смещение к дефолтам обучающих данных: использование старых библиотек, устаревших команд, стандартных форматов или допущений, не основанных на реальном репозитории или датасете.
• Дрейф реализации под давлением выполнения: когда реализация становится технически сложной, модель может смещаться к более простому типичному решению вместо предложенного метода.
• Деградация памяти и контекста: в проектах с длинным горизонтом теряются критические детали, если логи не сохраняются как постоянные артефакты.
• Избыточный оптимизм: модель объявляет успех, несмотря на шумные или провальные эксперименты; это похоже на паттерн «p-hacking and eureka-ing», отмеченный Bubeck et al. (2025), где модели могут добавлять «костыли из чисел» (numerical duct tape) и объявлять победу, когда сигналы всё ещё являются шумом.
• Недостаточный доменный интеллект: модели не хватает неявных ремесленных знаний, например предсказания сложности реализации, оценки правдоподобности экспериментального результата или понимания, какие baseline’ы действительно важны.
• Слабый научный вкус: эксперименты могут быть исполнимыми, но не отвечать на правильный вопрос.

На пути к полноценному RSI достигнут реальный прогресс, но остается ряд узких мест.

1. Слабые и размытые оценщики. Для многих научных утверждений нет быстрого и точного верификатора; то же верно и для многих реальных задач. Текущие циклы самоулучшения лучше всего работают там, где метрики оценки измеримы и объективны — аналогично тому, как работает RL.

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

2. Жизненный цикл контекста и памяти. По мере роста автономности и самостоятельности ИИ-агентов память разрастается. Полезный harness должен управлять контекстом и памятью, компенсируя текущие ограничения генерации с длинным контекстом и одновременно максимизируя успех задач с длинным горизонтом. Поскольку люди умеют поддерживать память на протяжении жизни, я вижу здесь аналогию: context engineering может и должен стать ядром интеллекта, а не оставаться только слоем программной системы.

3. Негативные результаты. Исследователи мотивированы публиковать успешные результаты, из-за чего литература смещена в сторону успехов. LLM, обученные на огромных массивах данных (пока в основном созданных людьми), могут плохо решать, когда нужно отказаться от гипотезы, сообщить отрицательный результат или просто признать провал — из-за дисбаланса между кейсами успеха и неуспеха в данных. Research-harness должен облегчать сохранение неудачных попыток, потому что обучение на провалах — лучший способ сузить пространство поиска.

4. Коллапс разнообразия. Эволюционные и RL-циклы склонны эксплуатировать уже известные высоконаградные паттерны. Нужны механизмы, предотвращающие схлопывание популяции в вариации одного и того же решения. Это особенно критично для open-ended исследований, где лучший путь сначала может выглядеть хуже по текущему оценщику.

5. Reward hacking. Цикл самоулучшения оптимизирует любой сигнал, который ему задан. Если награда основана на unit-тестах, агент может переобучиться под тесты; если на модели-судье — выучить трюки reward hacking именно под этого судью; если на benchmark-скоринге — эксплуатировать артефакты бенчмарка.

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

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

Если взять кодового агента: он уже повысил повседневную продуктивность в software engineering, но многие цели оптимизации по-прежнему слишком краткосрочны. Агент часто может закрыть текущую задачу, но менее ясно, как ему защищать долгосрочное здоровье репозитория, который коллективно поддерживают сотни или тысячи инженеров. Стандартное sandbox-based обучение в стиле RLVR редко захватывает maintainability, границы ответственности, стоимость миграций, обратную совместимость и будущую нагрузку на отладку.

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

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

Цитирование

Пожалуйста, цитируйте эту работу так:

Weng, Lilian. "Harness Engineering for Self-Improvement". Lil'Log (Jul 2026). https://lilianweng.github.io/posts/2026-07-04-harness/

Или используйте BibTeX-цитирование:

@article{weng2026harness,
  title = {Harness Engineering for Self-Improvement},
  author = {Weng, Lilian},
  journal = {lilianweng.github.io},
  year = {2026},
  month = {July},
  url = "https://lilianweng.github.io/posts/2026-07-04-harness/"
}

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

• PaperBench: воспроизведение с нуля 20 статей ICML 2024 уровня Spotlight/Oral, включая понимание вклада статьи, разработку кодовой базы и успешный запуск экспериментов.
  • Каждая задача репликации декомпозирована на более мелкие, индивидуально оцениваемые подзадачи.
  • Всего 8,316 рубрик, разработанных совместно с авторами статей.
  • Лучшая на тот момент модель (Claude 3.5 Sonnet, ~21%) не превосходит PhD в ML.
  • Включает PaperBench, PaperBench Code-Dev (облегченную версию) и JudgeEval.
• CORE-Bench: оценка вычислительной воспроизводимости опубликованных исследований.
  • 270 задач на основе 90 научных статей из computer science, social science и медицины.
  • Задачи включают воспроизведение результатов по предоставленным коду и данным.
  • Есть несколько уровней сложности, а также language-only и vision-language задачи.
  • Лучший опубликованный результат для агента на тот момент (GPT-4o и GPT-4o-mini) достиг лишь 21% точности на самой сложной задаче.
• ScienceAgentBench: оценка LLM-агентов для data-driven научного открытия.
  • Извлекает 102 задачи из 44 peer-reviewed публикаций в четырех дисциплинах (математика, химия, биология, география).
  • Покрывает базовые data-science задачи в этих доменах: обработка данных, разработка моделей, анализ данных и визуализация информации.
• RE-Bench: оценка frontier AI-агентов в реалистичных ML research-engineering средах против экспертов-людей.
  • 7 сложных, open-ended сред ML research-engineering.
  • Каждая среда = (функция скоринга, стартовое решение, референсное решение); каждая может запускаться на 8 или менее GPU H100.
  • Примеры: оптимизация kernel, эксперимент по scaling laws, исправление embedding, fine-tune GPT-2 для QA и т.д.
  • Включает данные 71 попытки длительностью по 8 часов от 61 уникального эксперта-человека.
  • Эксперты-люди достигали ненулевого score в 82% 8-часовых попыток; 24% совпали или превзошли сильные референсные решения.
  • Лучшие AI-агенты набирали score в 4 раза выше людей при бюджете 2 часа, но у людей отдача от большего бюджета была лучше, и при 8 и 32 часах они превосходили агентов.
• MLE-bench: оценка ML engineering-агентов на офлайн-соревнованиях Kaggle.
  • Содержит 75 ML engineering соревнований, отобранных из Kaggle.
  • Проверяет обучение моделей, подготовку датасетов, запуск экспериментов и отправку предсказаний в grading scripts.
  • Использует публичные leaderboard’ы Kaggle как baseline людей.
  • Лучшая конфигурация в статье, o1-preview с вспомогательной инфраструктурой AIDE, достигала как минимум уровня бронзовой медали Kaggle в 16.9% соревнований.
  • Включает анализ масштабирования ресурсов и contamination.
• KernelBench: оценка корректности и скорости сгенерированных GPU kernels.
  • 250 задач PyTorch для проверки, может ли LLM писать быстрые и корректные kernels.
  • Метрика оценки fast_p = процент сгенерированных kernels, которые корректны и быстрее baseline.

Ссылки

[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.

• Языковые модели
• Агенты
• Авто-исследования
• Самоулучшение
• Промптинг

Источник: https://lilianweng.github.io/posts/2026-07-04-harness/