Харнесс-инжиниринг учит ИИ-агентов не просто работать, а проверять себя

ИИ-агент может написать код, запустить команды и даже самостоятельно исправить ошибку. Но есть проблема: модель не всегда понимает, что задача действительно выполнена правильно. Именно здесь появляется harness engineering — подход, который переносит внимание с одного промпта на всю систему управления агентом.

Разработчик опубликовал подробную памятку по harness engineering, рассчитанную прежде всего на тех, кто активно работает с ИИ-агентами и хочет перейти от простого управления промптами к построению надёжных рабочих процессов.

Под harness engineering обычно понимают проектирование среды, в которой работает ИИ-агент: правил, инструментов, контекста, ограничений, тестов и механизмов проверки результата.

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

Именно поэтому harness можно рассматривать как своеобразный контрольный слой между моделью и реальным выполнением задачи.

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

Обычная схема выглядит просто: пользователь формулирует задачу, агент генерирует решение и сообщает о завершении.

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

Поэтому важен принцип: агент не должен сам определять, достаточно ли хорошо он выполнил работу.

Это решение лучше вынести за пределы модели — в правила и проверяемые условия.

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

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

Третий элемент — проверка результата.

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

Получается замкнутый цикл:

задача → действие агента → проверка → исправление → повторная проверка.

Если проверка не пройдена, работа не должна просто завершаться сообщением «готово».

Именно циклы проверки являются одной из самых важных идей harness engineering.

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

Так появляется feedback loop — цикл обратной связи.

В более сложных системах проверять можно не только техническую корректность. Например:

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

Есть важная разница между инструкцией и ограничением.

Фраза «не изменяй файлы вне этой директории» остаётся обычной рекомендацией, если система технически позволяет агенту сделать обратное. Надёжный harness должен по возможности закреплять критические правила на уровне среды выполнения.

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

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

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

При таком подходе ИИ-агент перестаёт быть просто чат-ботом, которому периодически приходится напоминать о требованиях. Он становится частью управляемого процесса.

Для тех, кто хочет разобраться с подходом глубже, разработчик собрал материалы в отдельный PDF. Скачать памятку по harness engineering можно по ссылке.

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

КОД — журнал о технологиях

💻 Новости и обзоры из мира технологий, полезные материалы, интересные факты и всё, что связано с современными цифровыми решениями.

😎 Подписывайтесь на наш Telegram-канал: https://t.me/kodjournal