Google Cloud AI Research и Northwestern University опубликовали препринт Harness² 9 октября 2026. Суть: система учится на своих ошибках, но веса модели не трогает. Меняется только обвязка вокруг неё: системный промпт, ограничения, работа с памятью, скрипты.

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

Идею можно проверить на трёх задачах за вечер.

Как работает Harness²

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

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

В итог попадают только правки, которые подтвердились запуском. После задачи система записывает принятую обвязку и файл EXPERIENCE.md. На следующей задаче выбирает и приспосабливает подходящие уроки.

Результаты одного шага улучшения: WorkBuddy-Bench (офисные задачи: код, веб, документы) вырос до +11,5 балла, JobBench до +4,5, юридический набор LAB до +11,8 процентного пункта. При пяти параллельных попытках ещё +2,6–6,7.

Исполнители в опытах: Gemini 3.5 Flash и GLM-5. Прирост у разных моделей сильно отличается. На LAB у Gemini всего +0,6 процентного пункта.

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

Сценарий на вечер: релизные заметки

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

Заведите два файла. В instruction.md стартовая инструкция:

Ты пишешь релизные заметки для разработчиков. Задача: объяснить, что изменилось и как это использовать.

Структура:
- Что добавлено
- Что исправлено
- Что изменилось в API

Пиши конкретно: не "улучшена производительность", а "запросы к базе стали выполняться на 30% быстрее".

lessons.md пока пустой.

Обновление 1: вебхуки и кэш

Возьмите обновление. Добавили поддержку вебхуков и исправили баг с кэшем. Отправьте инструкцию и описание обновления в модель.

Модель написала:

Добавлена поддержка вебхуков. Теперь можно получать уведомления о событиях.

Исправлен баг с кэшем, который приводил к некорректной работе.

Слишком общо. Нет примеров, нет деталей о том, как настроить вебхук.

Напишите два варианта правки. Вариант A: общая слабость, модель не приводит примеры. Добавьте в инструкцию:

Для каждой новой фичи давай пример использования: код или команду.

Вариант B: особенность задачи, вебхуки требуют настройки:

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

Проверим оба варианта. Запустите два запроса в одной модели: первый с инструкцией + правка A, второй с инструкцией + правка B. Задача одинаковая (описание обновления), инструкции разные. Например, на Claude Sonnet 5.5 из прайса.

Результат A даёт пример запроса. Результат B даёт и пример, и последовательность шагов:

Добавлена поддержка вебхуков. Настройка:
1. Создайте эндпоинт для получения событий
2. Зарегистрируйте его через POST /webhooks
3. Укажите, какие события слушать

Пример запроса:
POST /webhooks
{
  "url": "https://example.com/callback",
  "events": ["user.created"]
}

B лучше. Добавьте в lessons.md:

Задача: релизные заметки для вебхуков
Проблема: слишком общо, нет деталей о настройке
Что помогло: "Для фич, которые требуют настройки, укажи минимальный набор шагов для запуска"
Результат: модель дала последовательность шагов и пример кода

Примите правку B в instruction.md.

Обновление 2: фильтры и баг с памятью

На втором обновлении добавили фильтры в API поиска, исправили баг с памятью в долгоживущих процессах. Модель справилась с фильтрами, но написала про баг: «Исправлен баг с памятью» без контекста.

Снова два варианта правки. A про общую слабость: модель не объясняет, что конкретно изменилось:

Для исправлений багов укажи, что было до и что стало после.

B про особенность задачи: баг влиял на производительность:

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

Два запроса в одной модели, два варианта инструкции. Результат A даёт конкретное сравнение поведения:

Исправлен баг с памятью. До: память не освобождалась после обработки запросов. После: память корректно очищается.

Результат B привязывает к сценарию, но менее универсален. A лучше для любых багов. Урок в lessons.md:

Задача: релизные заметки с исправлением бага
Проблема: непонятно, что конкретно изменилось
Что помогло: "Для исправлений багов укажи, что было до и что стало после"
Результат: модель дала конкретное сравнение поведения

Обновление 3: подписки и формат ошибок

Третье обновление: GraphQL подписки и изменение формата ошибок API. Модель справилась с подписками, но про ошибки написала: «Теперь ошибки возвращаются в формате JSON с полем “error”».

Тут важно: в lessons.md уже есть урок про баги: «укажи, что было до и что стало после». Примените его к изменению формата:

Для breaking changes покажи старый и новый формат рядом.

Модель написала:

Изменён формат ошибок API.

До:
{
  "message": "Not found"
}

После:
{
  "error": {
    "code": "NOT_FOUND",
    "message": "Resource not found"
  }
}

Лучше. Урок в lessons.md:

Задача: релизные заметки с breaking change
Проблема: новый формат показан без контекста старого
Что помогло: "Для breaking changes покажи старый и новый формат рядом" (адаптация урока из задачи 2)
Результат: модель дала сравнение форматов

Что интересно

Инструкция растёт медленно, и каждое правило проверено на конкретном промахе. После трёх задач получается пять-шесть правил вместо длинного документа.

Сравнение двух вариантов показывает, какая формулировка точнее. Без запуска непонятно, что «укажи последовательность шагов» работает лучше, чем «давай примеры». Одна и та же модель с разными инструкциями ведёт себя по-разному, и разница видна сразу.

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

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

Заведите два файла. Возьмите три типовые задачи. На первой задаче сравните два варианта правки в одной модели (два запроса с разными инструкциями, одинаковый запрос), запишите урок и проверьте его на второй задаче. Через три задачи получится инструкция, которая выросла из реальных промахов, а не из предположений о том, что может пойти не так.

Попробуйте на моделях из прайса и напишите, какой урок из lessons.md сработал на вашей задаче и сколько правил накопилось за три задачи.