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

Меня зовут Карим, я занимаюсь автоматизацией в NODA, и главная новость подсайта в этот понедельник — фреймворк Harness² от Google Research: агент сам переписывает свою обвязку (системный промпт, память, скиллы, инструкции к инструментам и ограничения), проверяет правки на задаче и оставляет те, что сработали. Лицензия Apache 2.0, 10,9 тысячи звёзд, 975 форков и три коммита в истории. Разбираю в шести карточках: что случилось, как устроен цикл, где подвох, что это меняет в деньгах и что из этого можно сделать у себя завтра, даже если Vertex AI у вас никогда не будет.

Короткий ответ: главное в новости — список того, что агенту разрешили менять. В README восемь компонентов, и guardrails среди них на втором месте. Метод Harness² (предложить варианты, проверить, оставить лучшее) стоит забрать себе для промптов и скиллов. Ограничения и права из этого списка нужно вынести до первого запуска, иначе граница, которую агент может редактировать, перестаёт быть границей.

Google Research выложила Harness², «plug-and-play фреймворк рекурсивной оптимизации харнесса». Харнесс в их терминах — всё вокруг модели: промпты, инструменты, память, скиллы, оркестрация. Веса модели не трогаются; меняется только обвязка. Заявленная задача — открытый мир, где агент встречает работу, под которую харнесс никто не проектировал.

Агент может редактировать восемь компонентов: системный промпт, guardrails, память, инструкции к инструментам, субагентов, скиллы, скрипты, плагины. Исполнители: OpenCode по умолчанию и Codex; модели подключаются через Vertex AI, авторизация через Google Cloud CLI. Заявленный прирост за один шаг: до 11,5 пункта на WorkBuddy-Bench (офис, веб, код), 4,5 на JobBench (профессиональные задачи), 11,8 процентного пункта partial pass rate на LAB (юридическая работа) — для GLM-5 и Gemini 3.5 Flash. В README отдельно: «не официально поддерживаемый продукт Google», программа вознаграждений за уязвимости на проект не распространяется.

Два уровня. На уровне задачи шаг Propose–Probe–Compose: редактор харнесса предлагает правки, общие и доменные; пробы выполняют каждую правку на той же задаче; композитор собирает из контрастов поведения уточнённый харнесс. Эталонные ответы не нужны: сравнивается поведение вариантов между собой. На уровне харнессинга работает постоянный «харнесс улучшения», который хранит принятые версии и подтверждённые доказательствами выводы и направляет следующие правки.

Два режима масштабирования: parallel, K общих и K доменных кандидатов одновременно, и sequential, K шагов подряд, глубже. Бюджет задаётся параметром k. Всё принятое складывается в runs/: результаты, принятые харнессы, заметки рефлексии.

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

Guardrails редактируемы. В списке из восьми компонентов они стоят рядом с промптами, и никакой защиты ограничений от правок самим агентом README не описывает. Цикл выбирает то, что улучшает результат на задаче; ограничение, которое мешает результату, по этому критерию — кандидат на правку.

Отката и человека в цикле в README нет. Описаны принятие харнесса и возобновление запуска той же командой. Кто смотрит diff принятой версии, не сказано.

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

Сеть не ограничена, Codex запускается с отключённой песочницей. И сам README советует перед оценкой настроить сетевые ограничения, чтобы агент не нашёл в интернете рубрики бенчмарков, то есть ответы к собственному экзамену. Это честная оговорка авторов, и она же лучшее описание того, что делает оптимизирующий агент без ограды: ищет самый короткий путь к оценке.

Цифры собственные. Сравнение идёт с базовыми харнессами тех же моделей, независимой проверки нет, в истории репозитория три коммита. И это исследовательский проект, что авторы повторяют дважды.

В статье про токены как статью расходов я считал стоимость завершённой операции. Harness² добавляет к ней стоимость улучшения, и она считается просто. В режиме parallel один шаг — это базовый запуск плюс 2K проб плюс композиция. При k = 4 одна задача стоит порядка десяти обычных прогонов, при k = 8 около двадцати. Если операция агента обходится в 10 рублей токенов, самоулучшение на ней стоит 100–200 рублей, и это до того, как кто-то посмотрел результат.

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

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

Хранить харнесс как код. Промпты, скиллы и память лежат файлами в репозитории; правка приходит пулл-реквестом с diff; принимает человек; откат — одна команда. Harness² складывает принятые версии в runs/; у вас это должен быть git, потому что там есть blame.

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

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

Хранить доказательство рядом с правкой. Не просто «стало лучше»: на каких задачах, с каким результатом до и после, кто принял. Это тот самый отчёт о себе, который не считается проверкой, пока к нему не приложен след.

Первое. Я внедряю агентов и продаю их сопровождение; мне выгодно, чтобы «человек принимает правки» выглядело обязательным. Возможно, через год самоулучшение в песочнице с автопроверкой станет нормой, и ревью каждой правки покажется ручным тормозом.

Второе. Я читал README и структуру репозитория, а не весь код. Защита guardrails может быть реализована в коде и не описана в документации. Если найдёте — напишите, поправлю карточку 3 со ссылкой на файл.

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

Вопрос к тем, у кого агенты уже работают: где лежат ваши промпты и скиллы — в репозитории с ревью, в админке или в голове того, кто их писал? И менял ли их агент хоть раз сам?