Журнал «Отинофф»
Схема тестирования связки LLM-модели с агентским harness с помощью Harness Bench

Harness Bench: как тестировать связку модель + harness и не потерять 30%

ИИ-инструменты 1 июля 2026 г.

Вы выбрали модель для AI-агента. Запустили в production — и результаты упали на 20–30% по сравнению с тестами. Причина не в модели, а в программной обвязке, которая передаёт ей команды и инструменты. Эту обвязку называют агентским harness, и от неё зависит, сколько задач агент решит правильно.

Источник: Habr

Команда R&D-лаборатории red_mad_robot выпустила открытый фреймворк Harness Bench, который позволяет тестировать связки «модель + harness» в одинаковых условиях и видеть, где обвязка снижает результат. Если ваша команда выбирает между Hermes, OpenClaw, OpenCode или пишет свою обвязку, этот инструмент стоит проверить до того, как решение попадёт в продакшен.

Что такое агентский harness и почему его нужно тестировать отдельно

Модель большого языка (LLM) сама по себе умеет только предсказывать следующий токен — генерировать текст. Чтобы она могла планировать шаги, писать и запускать код, искать информацию в интернете, ей нужна программная обвязка — harness. Он обращается к модели, предоставляет ей инструменты и среду выполнения.

Раньше такие обвязки писали вручную под каждую задачу. Сейчас есть готовые фреймворки: Hermes, OpenClaw, OpenCode. Они дают оркестрацию и песочницы «из коробки», но ведут себя по-разному. Одна и та же модель, обёрнутая в разные harness, может показывать совершенно разные результаты.

Создатели SWE-bench выпустили отдельную версию SWE-bench Verified и обнаружили, что разница в результатах одной модели на разных harness достигает десятков процентов. В мае 2026 года появился проект WildClawBench, который пытается отделить интеллект модели от качества обвязки. Anthropic в своих гайдах подчеркнул: оценивать агента нужно в реальной среде, где он будет ошибаться и восстанавливать контекст.

Проблема в том, что стандартные бенчмарки вроде SimpleQA или SWE-bench создавались под completion-модели — они жёстко привязаны к статичному формату и не рассчитаны на автономный многошаговый цикл AI-агента.

Как устроен Harness Bench: три независимые оси вместо монолита

Авторы Harness Bench отказались от монолитной архитектуры, вдохновившись подходом Inspect AI. Система держится на трёх принципах:

  • Независимые оси — компоненты не знают друг о друге и стыкуются только при запуске.
  • Инфраструктура как данные — окружение задачи описано прямо в её данных, а не настраивается вручную.
  • Жёсткая изоляция сред — всё работает в отдельных контейнерах (Docker-out-of-Docker), агент получает доступ к рабочей среде только через MCP.

Архитектура разложена на три оси:

Ось Вопрос Что делает
Harness Кто выполняет Получает сообщения от оркестратора, доставляет их агенту и возвращает ответ. Суть задачи ему неизвестна.
Benchmark Что выполняется Готовит задачи и разворачивает под каждую своё окружение. Кто будет их решать — не имеет значения.
Scorer Как оценивается Проверяет результат.

Такое разделение позволяет подключать новые бенчмарки без переписывания половины системы. Если вы хотите прогнать свою модель через SWE-bench, SimpleQA или другой стандарт, вам не нужно писать адаптер с нуля — достаточно описать окружение задачи в данных.

Что меняет Harness Bench для команды, собирающей AI-агента

Раньше вы выбирали модель по бенчмаркам, а harness — «на глаз» или по популярности. Harness Bench позволяет сделать выбор воспроизводимым и измеримым.

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

Это особенно важно, если ваша команда:

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

Где лежат риски и ограничения

Фреймворк новый — статья на Habr опубликована 30 июня 2026 года. Это значит, что:

  • Сообщество ещё не наработало практику. Возможны недокументированные ограничения, баги в адаптерах harness, неполная поддержка бенчмарков.
  • Зависимость от Docker и MCP. Если ваша инфраструктура не использует контейнерную изоляцию или MCP, внедрение потребует дополнительных настроек.
  • Стоимость прогонов. Запуск нескольких моделей на нескольких harness через несколько бенчмарков — это вычислительные ресурсы и время. Особенно если задачи многошаговые и требуют внешних вызовов.
  • Свежесть бенчмарков. Стандарты вроде SWE-bench обновляются. Нужно следить, чтобы версия бенчмарка в Harness Bench соответствовала актуальной.

Автор статьи — Андрей Иванов, NLP-исследователь red_mad_robot. Это даёт определённый уровень доверия, но не отменяет необходимости самостоятельной проверки.

Что можно проверить за неделю без перестройки компании

  1. Скачайте Harness Bench из репозитория (ссылка в статье на Habr). Убедитесь, что ваша среда поддерживает Docker-out-of-Docker.
  2. Выберите одну модель и два harness — например, ту модель, которую вы уже используете, и два harness из списка: Hermes, OpenClaw, OpenCode.
  3. Запустите прогон на одном бенчмарке — например, на SWE-bench или SimpleQA. Не гонитесь за полнотой, важно увидеть, работает ли фреймворк в вашей среде.
  4. Сравните результаты. Если разница между harness превышает 5–10%, это повод копнуть глубже: возможно, обвязка теряет контекст, неправильно передаёт инструменты или ломает формат ответа модели.
  5. Задокументируйте конфигурацию. Запишите версии harness, модели, бенчмарка и параметры запуска. Без этого результаты невоспроизводимы.
  6. Проверьте логи ошибок. В статье упоминаются баги опенсорсных обвязок, которые ломают автоматический прогон. Если прогон упал, это не обязательно проблема вашей настройки — возможно, баг в адаптере harness.

Что делать, если Harness Bench показал неожиданный результат

Не делайте вывод по одному прогону. Возможные причины разброса:

  • Случайность генерации. Модели могут выдавать разный результат на одном и том же промпте. Запустите каждый сценарий 3–5 раз и возьмите среднее.
  • Разная обработка инструментов. Один harness может передавать модели больше контекста о доступных инструментах, другой — меньше. Проверьте, как каждый harness формирует промпт.
  • Разное управление памятью. В многошаговых задачах harness решает, сколько истории хранить и когда её обрезать. Это напрямую влияет на качество.
  • Разная обработка ошибок. Один harness может корректно обработать таймаут или невалидный ответ модели, другой — упасть.

Если разница сохраняется после нескольких прогонов, это сигнал, что выбор harness не менее важен, чем выбор модели.

Источники

Темы журнала

Что почитать дальше

Теги

Андрей Отинов

Рекомендуем