Agent Harness — каркас, который превращает ИИ-модель в агента

Когда говорят про AI-агентов, обычно обсуждают модель: какую модель Claude недавно выпустили и чем она лучше, а может, GPT сильнее или китаец Qween? Обсуждают, сколько параметров и какой бенчмарк модель выбила на прошлой неделе. Но если разобрать любого реально работающего агента, выясняется неудобная вещь: модель нейросети, это едва ли не самая маленькая его часть. Всё остальное — это harness

Если посмотреть на траекторию, по которой развивались AI-системы, она читается как последовательность слоёв. Сначала появились генеративные модели: они научились осмысленно продолжать текст. Потом пришёл контекст: модели научились опираться на то, что им подают на вход, и работать с большими объёмами информации. Затем: интеграция со средой: вызов инструментов, доступ к данным, действия в реальном мире. И теперь на аренду вышел термин agent harness, слой, который связывает всё это в работающую систему. Каждый следующий слой не отменяет предыдущий, а надстраивается над ним

В этой статье разберу, что такое harness, из чего он состоит, почему именно он чаще определяет качество агента и как не наступить на типичные грабли при его построении

Модель — лишь ядро. Всё, что вокруг неё, и есть harness

Термин пришёл из тестирования ПО. Test harness — это обвязка, которая позволяет прогонять код в контролируемых условиях. Agent harness делает ровно то же самое для LLM: это слой инфраструктуры, который превращает модель, предсказывающую токены, в систему, которая надёжно выполняет задачи: с инструментами, состоянием и памятью между сессиями

Сама по себе модель умеет одно: получить текст на вход, выдать текст на выход. Она ничего не запускает, ничего не помнит после завершения запроса, ничего не проверяет. Всё это добавляет harness.

Хорошая аналогия: пилот и самолёт. Модель — это пилот. Harness — сам истребитель: принимает команды, исполняет их в реальном мире, возвращает показания приборов и ждёт следующего решения. Только в отличие от живого пилота, LLM ненадёжна, поэтому harness строят как детерминированный контроллер, который относится к модели как к «генератору предложений, который может ошибаться»: спрашивает «что делать дальше?», проверяет корректность и безопасность ответа, исполняет, возвращает результат в следующий шаг.

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

В основе любого harness: цикл, почти дословно как в обучении с подкреплением: наблюдение → решение → действие → новое наблюдение.

1. Собрать контекст и спросить модель, что делать.
2. Проверить ответ: корректно ли сформирован, безопасно ли действие.
3. Выполнить — вызвать инструмент, API, shell-команду.
4. Вернуть результат в контекст и повторить.

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

На псевдокоде минимальный harness выглядит до неприличия просто:

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

Если разложить production-grade harness на составляющие, получится примерно шесть слоёв, каждый из них является потенциальной точкой отказа.

1. Управление контекстом. Что именно подать модели на каждом шаге. Это главная и самая недооценённая задача. Контекстное окно ограничено, и решение о том, что туда попадёт, а что нет, — это и есть память агента. Есть отличная формулировка: просить «подключить память к harness» — всё равно что просить «подключить вождение к машине». Управление контекстом и есть основная функция harness, а не отдельный модуль сбоку.
2. Инструменты. Глаза, уши и руки агента. Функция, API-вызов, скрипт: реализация почти произвольна. Важно, чтобы инструмент был хорошо описан: что делает, какие принимает аргументы, что возвращает. От качества этих описаний напрямую зависит, поймёт ли агент, когда его применять. Плохое описание инструмента вредит сильнее, чем его отсутствие.
3. Состояние и память. Сохранение между сессиями, чтобы следующий запуск продолжил с того места, где остановился предыдущий. Когда сессия завершается, harness записывает «итог», и следующая стартует не с нуля.
4. Контроль и безопасность. Что агенту вообще разрешено делать, валидация перед исполнением, передача идентичности и сбор аудиторского следа. Этот слой особенно важен, когда агент получает доступ к боевым системам и деньгам.
5. Durable execution. Устойчивость к падениям: возможность продолжить с контрольной точки, а не начинать всё заново после сбоя или долгой паузы. Для долгих задач, идущих часами, это критично.
6. Наблюдаемость и стоимость. Логи, трассировка, аудит и трекинг расходов на уровне отдельных действий, а не «в среднем по команде». Без этого слоя вы не понимаете, почему агент сделал то, что сделал, и сколько это стоило.

Отдельно стоит сказать про память, потому что она тесно связана с harness. Если вы используете закрытый harness за проприетарным API, вы фактически отдаёте контроль над памятью агента третьей стороне. А память — это то, что делает агентов «прилипчивыми» и полезными в долгую: именно она создаёт сильный lock-in.

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

На практике большинство проблем с агентами, это проблемы harness, а не модели. Самые частые:

• Слишком много инструментов. Кажется, что чем больше возможностей у агента, тем лучше. На деле каждый лишний инструмент это шум в контексте и лишний повод ошибиться.
• Плохие описания инструментов. Агент выбирает инструмент по описанию. Расплывчатое или неточное описание гарантированно приведёт к неправильным вызовам.
• «Свалка» в контексте. Подавать модели всё подряд «на всякий случай», верный способ снизить качество и раздуть стоимость. Контекст нужно курировать так же тщательно, как код.
• Отсутствие слоя верификации. Если harness слепо исполняет всё, что предложила модель, он наследует все её ошибки. Модель — советчик, а не источник истины.
• Отношение к модели как к надёжной. LLM ошибается, галлюцинирует и иногда зацикливается. Harness должен это предполагать по умолчанию: лимиты шагов, бюджет токенов, проверки и откаты.

Если вы строите агента, качество вашего продукта определяется harness сильнее, чем выбором модели.

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

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

Модель — это двигатель, но машину делает не один двигатель. Agent harness — это рама, трансмиссия, тормоза и приборная панель, без которых мощность некуда приложить. Спор «большая модель против большой обвязки» не имеет одного ответа на все случаи, но направление понятно: по мере того как модели становятся сильнее, всё больше различий между «вау» и «не работает» прячется именно в harness.

Так что, если хочется лучшего агента, начинать стоит не с вопроса «какую модель взять», а с вопроса «какую обвязку я вокруг неё построю»