Спор «какая модель умнее» почти всегда оказывается спором о другом. И это уже не мнение, а измеренная величина.
Вышла работа с прямолинейным названием — «Хватит сравнивать агентов, не раскрывая обвязку». Авторы взяли одни и те же модели и прогнали их под разными обвязками. Разброс результатов, вызванный обвязкой, оказался примерно в восемь раз больше разброса от выбора модели. В шести случаях из девяти при смене обвязки менялся сам рейтинг моделей: та, что была лучше, становилась хуже.
| Функция | Описание | Пример |
|---|---|---|
| Constrain | Ограничить, что агент физически может сделать | Права доступа, песочница, лимиты итераций |
| Inform | Сообщить, что он должен сделать | Промпт, системные инструкции |
| Verify | Проверить, что он сделал это правильно | Инварианты, эвристики, LLM-судья |
| Correct | Поправить, когда пошло не так | Автоматические исправления, эскалация |
Отдельно исследователи из Фуданьского и Пекинского университетов дали обвязке эволюционировать самостоятельно: на каждой итерации система смотрела на провалы агента и правила собственные правила и инструменты. На бенчмарке Terminal Bench 2 это дало рост с 70 до 77 процентов, тогда как обвязка, собранная вручную, остановилась около 72. Модель при этом не трогали.
В 6 из 9 случаев смена обвязки меняла рейтинг моделей.
И самый показательный случай — не из лаборатории. Полтора месяца пользователи жаловались, что Claude поглупел. Разбор показал три независимых бага в обвязке: понизили reasoning effort, сломали очистку истории так, что она срабатывала каждый ход, и добавили ограничение многословности в системный промпт. Модель не меняли вообще.
Что такое harness
Harness — это весь код вокруг модели. Модель делает ровно одну вещь: принимает контекст и выдаёт следующий шаг. Всё, что происходит до и после, — обвязка: инструменты, память, лимиты, проверки, оркестрация, наблюдаемость, политики доступа.
Слово не новое: harness-тестирование — обвязка вокруг тестируемого кода — существует не первый десяток лет. Новое здесь только то, что у обвязки появился новый потребитель.
Термин закрепился в феврале 2026 года, когда Митчелл Хашимото — основатель HashiCorp и создатель Terraform — опубликовал разбор собственной работы с агентом и назвал это harness engineering. Сформулированный им принцип стоит того, чтобы привести его целиком: Каждый раз, когда агент ошибается, ошибку нужно сделать структурно невозможной. Не промптом и не инструкцией, а кодом.
Логика простая. Агент эффективен, когда выдаёт правильный результат с первого раза. Надёжнее всего этого добиться не уговорами, а инструментами, которые сами сообщают ему, где он ошибся. Линтер, тесты, CI — обратная связь приходит автоматически, без человека в цикле.
Четыре функции: определение OpenAI
В феврале 2026 OpenAI описали обвязку как систему из четырёх функций. Формулировка Райана Лопополо:
Constrain — ограничить, что агент физически может сделать. Inform — сообщить, что он должен сделать. Verify — проверить, что он сделал это правильно. Correct — поправить, когда пошло не так.
За каждым словом стоит конкретный инженерный слой и конкретная цена за его отсутствие. Разберём по порядку — и заодно станет видно, откуда берётся статистика провалов.
Constrain: ограничение — это когда физически нельзя
Ключевая ошибка в этом слое формулируется так: ограничение, написанное в промпте, ограничением не является.
Агент с широкими правами доступа, которому в инструкции сказано «не удаляй ничего в продакшене», удалит. А потом процитирует эту инструкцию в объяснении, почему так делать было нельзя. Уверенность модели в собственной правоте не коррелирует с правотой.
Что реально относится к этому слою: токен-бюджеты на пользователя и на сессию, жёсткие лимиты итераций цикла, детектор повторяющихся вызовов с теми же аргументами, права доступа на уровне инфраструктуры, песочница, circuit breaker на внешние API, деградация вместо падения. Всё то же самое, что вы ставите на обычный сервис — только защищает оно не от падения, а от бесконечной уверенной активности.
Inform: промпт как инженерный артефакт
Промпт — это должностная инструкция агента, и относиться к нему нужно соответственно: он лежит в репозитории, версионируется, и у каждой версии есть измерение.
Отсюда неочевидное следствие. Промпт — не документ, который постепенно растёт по мере накопления пожеланий. Это система уравнений, где каждое новое условие может сломать предыдущие. Больше инструкций не значит лучший результат: новые правила конфликтуют со старыми, и модель не объяснит, какое из них выбрала и почему.
Практический вывод: каждое правило должно прослеживаться до конкретного сбоя, из-за которого оно появилось. Правила, добавленные «на всякий случай», ухудшают результат и при этом невидимы для отладки.
Verify: три уровня, и они стоят по-разному
Самый содержательный слой. Проверки бывают принципиально разного типа, и главная ошибка — пытаться делать их одним инструментом.
Уровень первый: инварианты в коде. Срабатывают мгновенно, не могут ошибиться, ничего не стоят. Это утверждения, верные про ответ всегда, при любом запросе: выборка не может быть больше исходной базы, сумма платежей не может быть отрицательной, количество шагов не может превысить лимит.
Уровень второй: эвристики и эмбеддинги. Проверяют, что ответ похож на то, что ожидалось. Стоят дёшево, но могут ошибаться. Например, проверка, что сумма в ответе совпадает с суммой в заказе, — это эвристика, которая не ловит все случаи.
Уровень третий: LLM-судья. Дорогой, но гибкий. Может оценить, соответствует ли ответ намерению пользователя. Однако LLM-судья сам может быть обманут, поэтому его нужно использовать как дополнение, а не замену.
Correct: как чинить, когда сломалось
Когда проверка не прошла, агент должен уметь исправиться. Это может быть повторный запрос с уточнением, вызов инструмента для получения дополнительных данных, или эскалация человеку. Важно, чтобы процесс исправления был автоматическим и не требовал ручного вмешательства.
Практические выводы
Если вы меряете две модели на своём агенте, а обвязка при этом разная — вы меряете не модели. Вы меряете обвязки. Это главный вывод исследования.
Для тех, кто строит агентов, это означает: инвестиции в обвязку окупаются больше, чем в саму модель. Улучшение обвязки может дать рост на 7 процентных пунктов (как в эксперименте с Terminal Bench 2), тогда как смена модели на более новую часто даёт меньше.
Прогноз о том, что 40% агентских проектов закроют к 2027 году, основан на том, что многие команды не уделяют должного внимания обвязке. Они фокусируются на выборе модели, а проблемы возникают из-за плохой обвязки.
Чтобы избежать провала, нужно:
1. Инвестировать в обвязку как в инженерный артефакт. 2. Использовать принцип Митчелла Хашимото: делать ошибки структурно невозможными. 3. Разделять функции обвязки: Constrain, Inform, Verify, Correct. 4. Версионировать промпты и связывать правила с конкретными сбоями. 5. Использовать автоматические проверки на всех уровнях.
