Harness-инженерия (Harness Engineering)
Каркас вокруг модели — самый сильный рычаг надёжности агента
Проблема: Вы обернули сильную модель в простой цикл: промпт, запуск её вызовов инструментов, повтор. В демо она выглядит как senior-инженер. В продакшне она уверенно выкатывает сломанный код, застревает при сбое вызова инструмента и сжигает бюджет, зацикливаясь на edge-кейсах, — потому что ничто не проверяет её работу и не восстанавливает после сбоя.
Решение: Harness-инженерия — проектируйте надёжность вокруг модели
Помимо промпта и контекста, самый сильный рычаг надёжности агента — это harness: workflow, набор инструментов, feedback loops, ограничения и жизненный цикл, обёрнутые вокруг модели. Промпт — это то, что вы говорите; контекст — то, с чем модель работает; harness — машинерия вокруг вызова модели, превращающая один ответ в надёжный многошаговый процесс. Harness-инженерия проектирует этот каркас так, чтобы средняя модель работала как senior-инженер — не делая модель умнее, а окружая её инструментами, проверками и логикой восстановления.
Prompt → context → harness: куда сместился рычаг
Если «prompt engineering» и «context engineering» — устоявшиеся термины, то «harness engineering» — формирующаяся формулировка 2026 года для этого третьего рычага. Сначала рычаг был в prompt engineering — хорошо сформулировать инструкцию. Затем он сместился в context engineering — собрать правильную информацию вокруг промпта (retrieval, история, примеры). Третья эволюция — harness-инженерия: теперь рычаг в каркасе вокруг вызова. Идеально составленный промпт с идеальным контекстом всё равно падает на edge-кейсах, если у модели одна попытка; оберни тот же вызов в цикл с верификаторами и retry — и система оправляется от собственных ошибок. Именно harness в основном определяет, надёжен ли агент в продакшне.
Feedback loops, guardrails и наблюдаемость
Основную работу делают три компонента. Feedback loops — это тесты, линтеры, проверки типов и верификаторы, которые запускаются после действия модели и возвращают результат, чтобы она исправилась по ходу задачи: это разница между моделью, выдавшей неверный ответ, и моделью, итерирующей к рабочему. Guardrails и retry ограничивают допустимые действия агента и восстанавливают после сбоев: упавший вызов инструмента запускает retry с backoff или fallback, действие вне политики блокируется, а бюджет ограничивает зацикливание. Наблюдаемость в цикле — логирование, бюджеты и трассировка — делает запуск отлаживаемым и ограниченным, так что при сбое вы видите, где именно, и чините harness, а не гадаете о промпте. Стройте harness в четыре хода: определите цикл и жизненный цикл агента, подключите инструменты и верификаторы, добавьте feedback loops и retry по сбою, затем ограничьте и наблюдайте. Итог eval-driven: каждое изменение harness измеряется на наборе реальных задач, поэтому надёжность проектируется, а не остаётся надеждой.
Представьте это как отличную кухню против отличного шеф-повара. Harness — это кухня: станции, таймеры, чек-листы и проба на каждом шаге — то, что позволяет даже среднему повару стабильно готовить блюдо, потому что кухня ловит ошибки, которые повар иначе бы пропустил:
- 1. Определите цикл и жизненный цикл агента: Определите, как агент делает шаги: план, действие, наблюдение, повтор. Задайте жизненный цикл — стартовое состояние, условия остановки, чекпоинты — чтобы запуск был ограниченным, возобновляемым процессом, а не бесконечным чатом
- 2. Подключите инструменты и верификаторы: Дайте агенту инструменты для действий и верификаторы для проверки результата: тесты, линтеры, проверки типов, валидаторы схем. Именно верификаторы превращают догадку в проверенный ответ, которому агент может доверять или который должен исправить
- 3. Добавьте feedback loops и retry по сбою: Возвращайте вывод верификатора в следующий шаг, чтобы модель исправлялась по ходу задачи. При упавшем вызове инструмента делайте retry с backoff или fallback на альтернативу, а не падайте и не передавайте сбой дальше
- 4. Ограничьте и наблюдайте — guardrails, логирование, бюджеты: Ограничьте агента guardrails (разрешённые действия, политики), бюджетами (лимиты шагов и токенов, останавливающие зацикливание) и наблюдаемостью (логирование и трассировка). При сбое трейс показывает, где именно, — и вы чините harness, а не гадаете о промпте
Где harness-инженерия окупается
- Кодовые агенты: Harness в стиле Claude Code — самый наглядный пример: модель правит файл, затем harness запускает проверку типов, линтер и тесты, возвращает ошибки и даёт модели итерировать, пока всё не станет зелёным. Модель средняя — harness делает цикл надёжным
- Автономные долгие workflow: Агентам, работающим минуты или часы над многошаговой задачей, нужен harness, чтобы выжить: чекпоинты, бюджеты, останавливающие зацикливание, retry для восстановления после нестабильного вызова инструмента и чёткий жизненный цикл, чтобы запуск можно было продолжить, а не перезапускать с нуля
- Инженерия надёжности агентов: Когда агент нестабилен в продакшне, исправление обычно в harness, а не в промпте: добавить пропущенный верификатор, ужесточить guardrail, добавить retry с backoff или улучшить трейс, чтобы видеть, где сломался цикл. Надёжность проектируют вокруг модели, а не «впромптовывают» в неё
- Eval-driven development: Относитесь к harness как к коду под тестами: соберите eval-набор реальных задач, прогоняйте агента по нему на каждое изменение и пусть оценки решают, что выкатывать. Добавление верификатора или retry — изменение, которое вы измеряете, поэтому harness улучшается так же дисциплинированно, как кодовая база
Интересный факт: Значительная часть того, почему кодовые агенты кажутся «умными» в 2026 году, — это harness, а не модель. Поставьте ту же модель в голый цикл без запуска тестов, без обратной связи линтера и без retry — и её доля успеха на реальных задачах резко падает: основную работу делал каркас, а не «IQ» модели.
Попробуйте сами!
Исследуйте интерактивный harness ниже: пройдите по слоям prompt → context → harness, включайте и выключайте компоненты цикла и наблюдайте, как двигается метрика надёжности, и сравните голый цикл модели с полным harness.
Интерактив: Harness Engineering Explorer
Эволюция 2026 года: где живёт рычаг. Нажмите на слой, чтобы увидеть, что он добавляет.
Что добавляет — Harness
Каркас вокруг вызова: цикл, инструменты, верификаторы, feedback loops, retry, guardrails, бюджеты и трассировка. Формирует весь многошаговый процесс — самый сильный рычаг надёжности.
Частые вопросы
Что такое harness-инженерия?
Harness-инженерия — это практика проектирования каркаса вокруг LLM: workflow, набор инструментов, feedback loops, ограничений и жизненного цикла, а не только промпта или контекста. Harness — это то, что превращает один вызов модели в надёжного агента: он подключает инструменты, верификаторы (тесты, линтеры, проверки типов), retry при сбоях, guardrails и наблюдаемость. В 2026 году это называют третьей эволюцией рычага — после prompt engineering и context engineering.
Чем harness отличается от промпта и контекста?
Промпт — это инструкция, которую вы отправляете; контекст — информация, которую вы собираете вокруг неё (найденные документы, история, примеры); harness — это машинерия вокруг вызова модели: цикл, доступные инструменты, верификаторы, проверяющие её работу, логика retry, бюджеты и логирование. Промпт и контекст формируют один ответ; harness формирует весь многошаговый процесс и в основном определяет надёжность.
Почему feedback loops так сильно повышают надёжность агента?
Feedback loops позволяют агенту исправлять себя по ходу задачи, а не уверенно выдавать неверный ответ. Кодовый агент, который запускает тесты, читает вывод линтера и перезапускает проверку типов после каждой правки, ловит собственные ошибки и итерирует — так же, как senior-инженер. Без верификаторов в цикле у модели только одна попытка; с ними средняя модель может оправиться от edge-кейсов и сойтись к рабочему результату.
Попробуй сам
Интерактивное демо этой техники
Сделать кодового агента, который надёжно правит код на edge-кейсах, а не выкатывает сломанное
На простом изменении выглядит как senior. На edge-кейсе (например, null в новом пути) модель уверенно выдаёт код, который компилируется, но падает в рантайме — ничто не проверяет работу. Сломанное уходит в прод.
На том же edge-кейсе тесты падают на null. Модель видит конкретную ошибку, добавляет guard, перезапускает — зелено за 2 итерации. Тот же средний уровень модели, но harness поймал и починил ошибку. В прод уходит рабочий код.
Надёжность даёт не модель, а harness. Добавьте верификаторы и feedback loop — и средняя модель ловит и чинит собственные ошибки вместо того, чтобы выкатывать сломанное.
Создайте бесплатный аккаунт для решения челленджей
3 челленджей с AI-проверкой для этого урока
Этот урок — часть структурированного курса по LLM.
Мой путь обучения