Инжиниринг 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-инжиниринг дополнительно включает дизайн workflow (например, loop engineering), оценивание, управление правами и постоянным состоянием. Это уже не просто шаблоны промптов; это ближе к проектированию runtime и программных систем: как модель наблюдает, действует, запоминает, проверяет себя и улучшается.

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

Паттерн 1: Автоматизация workflow¶

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

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

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

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

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

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

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

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

Кейс: 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 вряд ли начнется с того, что модель напрямую переписывает собственные веса. Мой практический прогноз на ближайшее время:

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

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

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

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

Context engineering¶

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

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

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

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

То, что ACE учится на rollout-траекториях, двигает нас к самоуправляемой памяти, но правила обновления и общий workflow все еще задаются вручную. Чтобы приблизиться к более самоулучшающемуся циклу, 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$ и обучает функцию контекста по rollout-фидбеку $\mathcal{R}_k$ под управлением текущего навыка: $c_k=\text{engineer}(\tau,s_k;c_{k-1}^*,\mathcal{R}_k)$.

MCE не навязывает эвристическое правило структурирования контекста, как ACE. Он использует свободно определяемые навыки для хранения важнейших знаний по задаче и итеративно совместно эволюционирует навык и контекст, обусловленный этим навыком. На уровне реализации функция контекста $c$ представляется как набор файлов в выделенной директории, включающий и статические (skill.md), и динамические (контекст и data rollouts) компоненты. И мета-, и базовая оптимизация выполняются в agentic 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 — это словарь в файловой системе, содержащий собственный исходный код, метрики, rollout-траектории и обновления состояния.
Цикл meta-harness итеративно создает новые harness-системы, и сохраняются только прошедшие квалификацию.

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

Проектирование workflow¶

Workflow в 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 и verifier/judge, чтобы синтезировать данные «правильной» сложности: strong solver должен справляться, а weak solver — нет.

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

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

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

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

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

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

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

И context engineering, и workflow design — лишь части harness-системы. Нужно искать по всему пространству дизайна и совместно оптимизировать логику управления контекстом, workflow, права и многие другие компоненты harness. Как видно в работах Meta-Harness, ADAS и AFlow, ✨код✨ — это универсальный язык задания программ и систем. Проще говоря, harness — это код, который программирует, как вместе работают промпты, вызовы инструментов, субагенты, control flow, память и логика workflow. Если 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$ на наборе downstream-задач $\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. Это аналогично тому, как workflow harness-системы можно представить как объект оптимизации.

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

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

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

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

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

Работы типа Self-Harness вызывают у меня опасение: если программе разрешить редактировать ОС, нарушаются границы абстракции. Редактируемая поверхность должна быть грамотно спроектирована, а контуры permission control и security должны находиться вне этого цикла. Все вызовы, связанные с 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:

Более sample-efficient exploration за счет выбора родителей, балансирующего rank производительности и число потомков.
Rejection sampling по новизне кода: отбрасываются кандидаты, слишком похожие на текущую популяцию по cosine similarity эмбеддингов.
Выделение хороших паттернов в успешных решениях в meta-scratchpad для направления будущих мутаций.

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

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

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

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

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

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

6. Долгосрочный успех. Внешний цикл оптимизации работает с наградами вне отдельных rollout’ов, которые мы можем симулировать в 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 задачи.
- Лучший reported агент на тот момент (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 scaffolding, достигала как минимум уровня бронзовой медали 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/