Спор «какая модель умнее» почти всегда оказывается спором о другом. И это уже не мнение, а измеренная величина.
Цифра, после которой спор выглядит иначе
Вышла работа с прямолинейным названием — «Хватит сравнивать агентов, не раскрывая обвязку». Авторы взяли одни и те же модели и прогнали их под разными обвязками. Разброс результатов, вызванный обвязкой, оказался примерно в восемь раз больше разброса от выбора модели. В шести случаях из девяти при смене обвязки менялся сам рейтинг моделей: та, что была лучше, становилась хуже.
Отдельно исследователи из Фуданьского и Пекинского университетов дали обвязке эволюционировать самостоятельно: на каждой итерации система смотрела на провалы агента и правила собственные правила и инструменты. На бенчмарке Terminal Bench 2 это дало рост с 70 до 77 процентов, тогда как обвязка, собранная вручную, остановилась около 72. Модель при этом не трогали.
И самый показательный случай — не из лаборатории. Полтора месяца пользователи жаловались, что Claude поглупел. Разбор показал три независимых бага в обвязке: понизили reasoning effort, сломали очистку истории так, что она срабатывала каждый ход, и добавили ограничение многословности в системный промпт. Модель не меняли вообще.
Источники: препринт о сравнении агентов и раскрытии обвязки; исследование Fudan/Peking по саморазвивающейся обвязке; публичный разбор инцидента Anthropic.
Отсюда практическое следствие, которое стоит повесить на стену: если вы меряете две модели на своём агенте, а обвязка при этом разная — вы меряете не модели. Вы меряете обвязки.
Что такое harness
Harness — это весь код вокруг модели. Модель делает ровно одну вещь: принимает контекст и выдаёт следующий шаг. Всё, что происходит до и после, — обвязка: инструменты, память, лимиты, проверки, оркестрация, наблюдаемость, политики доступа.
Слово не новое: harness‑тестирование — обвязка вокруг тестируемого кода — существует не первый десяток лет. Новое здесь только то, что у обвязки появился новый потребитель.
Термин закрепился в феврале 2026 года, когда Митчелл Хашимото — основатель HashiCorp и создатель Terraform — опубликовал разбор собственной работы с агентом и назвал это harness engineering. Сформулированный им принцип стоит того, чтобы привести его целиком:
Каждый раз, когда агент ошибается, ошибку нужно сделать структурно невозможной. Не промптом и не инструкцией, а кодом.
Логика простая. Агент эффективен, когда выдаёт правильный результат с первого раза. Надёжнее всего этого добиться не уговорами, а инструментами, которые сами сообщают ему, где он ошибся. Линтер, тесты, CI — обратная связь приходит автоматически, без человека в цикле.
Четыре функции: определение OpenAI
В феврале 2026 OpenAI описали обвязку как систему из четырёх функций. Формулировка Райана Лопополо:
Constrain — ограничить, что агент физически может сделать.
Inform — сообщить, что он должен сделать.
Verify — проверить, что он сделал это правильно.
Correct — поправить, когда пошло не так.
За каждым словом стоит конкретный инженерный слой и конкретная цена за его отсутствие. Разберём по порядку — и заодно станет видно, откуда берётся статистика провалов.
Constrain: ограничение — это когда физически нельзя
Ключевая ошибка в этом слое формулируется так: ограничение, написанное в промпте, ограничением не является.
Агент с широкими правами доступа, которому в инструкции сказано «не удаляй ничего в продакшене», удалит. А потом процитирует эту инструкцию в объяснении, почему так делать было нельзя. Уверенность модели в собственной правоте не коррелирует с правотой.
Что реально относится к этому слою: токен‑бюджеты на пользователя и на сессию, жёсткие лимиты итераций цикла, детектор повторяющихся вызовов с теми же аргументами, права доступа на уровне инфраструктуры, песочница, circuit breaker на внешние API, деградация вместо падения. Всё то же самое, что вы ставите на обычный сервис — только защищает оно не от падения, а от бесконечной уверенной активности.
Inform: промпт как инженерный артефакт
Промпт — это должностная инструкция агента, и относиться к нему нужно соответственно: он лежит в репозитории, версионируется, и у каждой версии есть измерение.
Отсюда неочевидное следствие. Промпт — не документ, который постепенно растёт по мере накопления пожеланий. Это система уравнений, где каждое новое условие может сломать предыдущие. Больше инструкций не значит лучший результат: новые правила конфликтуют со старыми, и модель не объяснит, какое из них выбрала и почему.
Практический вывод: каждое правило должно прослеживаться до конкретного сбоя, из‑за которого оно появилось. Правила, добавленные «на всякий случай», ухудшают результат и при этом невидимы для отладки.
Verify: три уровня, и они стоят по‑разному
Самый содержательный слой. Проверки бывают принципиально разного типа, и главная ошибка — пытаться делать их одним инструментом.
Уровень первый: инварианты в коде
Срабатывают мгновенно, не могут ошибиться, ничего не стоят. Это утверждения, верные про ответ всегда, при любом запросе: выборка не может быть больше исходной базы, дата не может выходить за запрошенный период, сумма возвратов не может превышать сумму заказа, идентификатор либо есть в справочнике, либо ответ невалиден.
Отдельно и важно: проверять нужно не только ответ. Модель формирует ещё и вызов инструмента, и вот аргументы вызова стоит проверять до того, как вызов случился. Плохой ответ вы просто выбросите. Удалённую базу не вернёте. Валидатор стоит перед инструментом, а не после него.
Уровень второй: замеры на эталонных запросах
Дорого, долго, запускается по событию — обычно при смене модели или значимой правке обвязки. Зато ловит то, что инвариантом не предскажешь: изменившийся стиль ответов, деградацию на конкретном домене, поломки, о существовании которых вы не догадывались, пока не увидели.
Публичные бенчмарки этого не заменяют. Они говорят о среднем по индустрии, а вам нужен ответ про ваш домен и ваши данные.
Уровень третий: человек
Всё, что не поймали первые два уровня. И правило, по которому вся конструкция живёт: каждый инцидент — это попытка спустить проверку на уровень ниже. Человек заметил глазами — переносим в замеры. Замеры ловят регулярно и выяснилось, что нарушение всегда ошибка — переносим в инвариант.
Это ровно то, о чём говорил Хашимото: последовательное превращение ошибки в структурно невозможную.
Где проходит граница детерминированного
Хочется унести в код как можно больше. Но не всё туда влезает, и попытка запихнуть лишнее обходится дороже, чем кажется.
Простая проверка на пригодность: если ваша проверка сама зовёт модель, чтобы вынести вердикт, — это не инвариант. Это ещё один вероятностный слой, который сам нуждается в проверке. Модель в роли судьи — нормальная практика, но в детерминированном слое ей не место.
Вторая проверка: бывают ли законные исключения. Если есть хоть один случай, когда правило можно нарушить, — перед вами эвристика, а не инвариант. И в код её класть нельзя: она будет блокировать правильные ответы. Пропущенную ошибку вы хотя бы увидите и обсудите. Заблокированный правильный ответ не увидит никто.
Correct: тихий успех опаснее падения
Инженер OpenAI назвал это дырой в состоянии. Пользователь просит агента что‑то запомнить. Агент отвечает, что запомнил. Ошибок в интерфейсе нет. На следующем ходу агент этого факта не знает — запись никуда не сохранилась.
Чем это хуже обычного падения: падение вы замечаете. А тихий успех — это ложь, поверх которой агент продолжает уверенно рассуждать, опираясь на сломанную историю.
Если агент не просто отвечает, а совершает действия, здесь возникает чистый инвариант: не может быть ответа пользователю без записи о действии. Замкнуто, без исключений, на уровне кода.
От промптов к циклам
Второе, что даёт обвязка помимо защиты от ошибок, — возможность агенту работать без вас.
В марте 2026 Андрей Карпаты показал проект AutoResearch: маленький репозиторий, одна видеокарта, около 630 строк тренировочного кода. Агенту ставится задача ускорить обучение небольшой модели, после чего человек уходит. Агент правит код, запускает тренировку на фиксированные пять минут, смотрит метрику: улучшилось — оставляет, ухудшилось — откатывает, и заново.
Через двое суток: порядка семисот экспериментов, около двадцати улучшений, время обучения до целевого уровня упало примерно на одиннадцать процентов.
Существенно вот что: он не написал семьсот промптов. Он один раз спроектировал цикл — фиксированный бюджет времени, автоматическая метрика, автоматическое решение. Всё остальное цикл сделал сам.
В июне 2026 Борис Черни, создатель Claude Code, сформулировал то же самое короче: он больше не пишет промпты для модели — он пишет циклы, которые пишут промпты за него.
Разница принципиальная. Промпт — это один выстрел. Цикл итерирует до результата. А обвязка делает эти итерации безопасными и предсказуемыми по стоимости.
Три фазы, и почему промпт‑инжиниринг никуда не делся
Индустрия прошла три стадии, и каждая не отменяет предыдущую, а вбирает её в себя:
Промпт‑инжиниринг — узкое место в формулировке.
Контекст‑инжиниринг — узкое место в том, что попадает в контекстное окно.
Harness‑инжиниринг — узкое место в среде выполнения.
Промпт не исчез: он стал версионируемым артефактом внутри обвязки. Контекст не исчез: он стал слоем, который собирается кодом. Профессия «промпт‑инженер» закончилась не потому, что навык обесценился, а потому что он стал подсистемой чего‑то большего.
Семь слоёв: полная картина
Академический обзор, сводящий больше сотни работ и два десятка живых систем в одну таксономию, раскладывает обвязку на семь слоёв. Первые четыре — структурное ядро, последние три — контрольный контур поверх него.
Среда исполнения: где и в какой изоляции запускается код агента.
Тулинг: протоколы инструментов, валидация схем, формат возвращаемых ошибок.
Контекст: что модель видит на коротком горизонте, на горизонте сессии и постоянно.
Жизненный цикл: оркестрация, поток управления, машина состояний, применение политик.
Наблюдаемость: метрики по каждому инструменту, трассировка, алёрты, расследование инцидентов.
Верификация: оценка и обратная связь — те самые три уровня.
Governance: безопасность и политики поверх всего, включая защиту от инъекций в промпт.
Про наблюдаемость стоит сказать отдельно: без неё все остальные слои работают вслепую. Вы узнаёте о дефекте, когда о нём напишет пользователь. Или не напишет — и агент будет тихо работать криво.
Пятый и седьмой слои чаще всего отсутствуют в готовых фреймворках и в агентах, которых берут с GitHub. Демо на них собирается за вечер. Продакшен — нет.
Почему это хорошая новость для бэкендера
Скептики говорят, что harness‑инжиниринг — переименованный платформенный инжиниринг: middleware, SRE, control plane. Они практически правы, и именно поэтому это хорошая новость.
Ретраи, лимиты, изоляция, идемпотентность, версионирование, CI, наблюдаемость — ни один из этих навыков не обесценится, если завтра хайп вокруг агентов уляжется. Это тот же стек, у которого появился новый потребитель. Причём потребитель специфический: он ошибается часто, непредсказуемо и очень уверенно.
Раньше вы строили инфраструктуру для кода, который пишет человек. Теперь — для исполнителя, который пишет код сам, но не умеет сомневаться.
Формулировка OpenAI о том, куда сместилась работа: с написания кода на проектирование среды, формулирование намерения и построение обратных связей. Это описание того, чем всегда занимались сильные инженеры и лиды. Код теперь пишет агент. Среда, спецификация и обратная связь — по‑прежнему на человеке.
Сколько обвязки нужно именно вам
Gartner прогнозирует, что более сорока процентов агентских проектов будут закрыты к 2027 году — из‑за неконтролируемых расходов, неясной бизнес‑ценности и недостаточного контроля рисков.
Наложите это на четыре функции. Неконтролируемые расходы — отсутствует Constrain. Неясная ценность — отсутствует Verify, нечем доказать, что стало лучше. Недостаточный контроль рисков — снова Constrain и Governance. Прогноз описывает ровно те дыры, о которых шла речь выше.
При этом строить все слои сразу не нужно. Объём обвязки пропорционален цене ошибки, а не громкости темы. Прототип на выходные для себя не требует ни kill switch, ни эталонных замеров. Слой имеет смысл строить тогда, когда вы посчитали, во что обходится его отсутствие.
И последнее по этой части. Модели дешевеют и становятся товаром. Обвязка — нет: в неё вложены ваши эксперименты, инциденты и домен. Она переживает модель под собой. Это делает её активом, а не технической деталью.
Четыре вопроса к вашему агенту
Лимит итераций у вас в коде или в промпте?
Есть ли автоматический замер качества при смене модели — или вы проверяете вручную, написав пару сообщений в чат?
Можете ли вы откатиться на предыдущую версию промпта и сравнить, что стало лучше, а что хуже?
Может ли ваш агент выполнить необратимое действие, пока вы спите?
Сколько ответов вас устроило — столько слоёв обвязки у вас и есть.
Теперь честно про нас: обвязка есть, модели в ней нет
Дальше — про собственный опыт, и начну с оговорки, без которой всё остальное читалось бы нечестно. Агента, который крутится в проде у клиента, у нас пока нет. Есть система, которую мы собрали для собственного маркетинга, и в ней нет ни одного обращения к модели. Ни одного, намеренно.
Рассказываю именно про неё, потому что это ровно про ту границу, о которой шла речь выше: что имеет смысл отдавать модели, а что — нет.
Задача
Контроль качества контента в команде из нескольких человек. Черновик пишет копирайтер, редполитику держит руководитель, метрики вносит аналитик. Нужно, чтобы текст нельзя было выпустить в обход проверки, чтобы было видно, что изменилось между черновиком и финалом, и чтобы источник лида не терялся между задачей и публикацией.
Первый порыв — поставить туда модель
Тема на слуху, задача выглядит подходящей: пусть читает текст и говорит, что не так. Мы выписали список проверок, которые нам реально нужны, и обнаружили, что почти все они имеют однозначный ответ.
Есть ли в тексте стоп‑слова из редполитики.
Заполнены ли обязательные поля задачи.
Проставлена ли UTM‑метка.
Есть ли призыв к действию и ведёт ли он куда надо.
Уложились ли в объём.
У каждого пункта есть правильный ответ, не зависящий ни от модели, ни от формулировки, ни от того, какая сегодня версия у провайдера. Отдавать это вероятностному слою — значит сделать медленнее, дороже и менее надёжно одновременно. Мы не стали.
Что в итоге построено
Node.js и Express, SQLite рядом с проектом, фронт без фреймворков. Выбор стека объясняется одним требованием: система должна подниматься одной командой на ноутбуке любого из четверых, без окружения и отдельной СУБД. Вся работа с базой собрана в одном файле, поэтому переезд на PostgreSQL — правка одного места, а не переписывание.
Constrain: права проверяются на сервере, а не в интерфейсе
Копирайтер не может править базу знаний и вносить факт по метрикам. Аналитик не может проводить ревью. Апрув доступен только руководителю. Ключевое — не список ролей, а место проверки: подмена запроса в браузере не помогает, сервер отказывает. Ограничение, которое живёт во фронтенде, ограничением не является ровно по той же причине, по которой им не является ограничение в промпте.
Verify: апрув не доверяет тому, что пришло из браузера
Вот эта деталь мне кажется самой важной во всей системе. Автопроверка текста может быть выполнена на клиенте — так быстрее и удобнее. Но в момент утверждения сервер пересчитывает её заново, у себя, с нуля.
Причина простая: «проверено» из клиента — это не факт, а утверждение клиента о факте. Между ними разница ровно та же, что между «агент отчитался об успехе» и «действие выполнено».
Утвердить текст с блокерами всё‑таки можно — отдельной кнопкой «несмотря на блокеры». Это осознанное действие, оно попадает в журнал, и потом видно, кто и когда так поступил. Запрещать полностью мы не стали: у редполитики бывают законные исключения, а правило без исключений в таком месте начало бы блокировать нормальные тексты. Заблокированный правильный текст никто не заметит — в отличие от пропущенной ошибки.
Состояние: снимок перед каждым изменением
Версия сохраняется перед каждой правкой, при каждой проверке и при утверждении — с оценкой, автором и временем. Любую можно вернуть. Это тот же принцип, что и версионируемый промпт: если у изменения нет предыдущего состояния, с которым можно сравнить, вы не узнаете, стало лучше или хуже.
Что проверено
51 тест API и 23 теста интерфейса в реальном браузере. Отдельно — что стоп‑слова ловятся с учётом русской морфологии: конструкция «партнёром, а не подрядчиком» находится в любом падеже, а слово «данные» в значении data не путается с канцелярским «данный». Это, кстати, хороший пример того, почему детерминированный слой — не всегда простой слой. Словарь с морфологией писать дольше, чем промпт. Зато он даёт один и тот же результат сегодня и через год.
Где потолок
Автопроверка на правилах не понимает смысла. Она надёжно ловит нарушения редполитики и не заменяет чтение текста человеком — и никогда не заменит. Это её потолок.
Но потолок известен заранее, и в этом всё дело. У детерминированного слоя предсказуемый предел: вы точно знаете, что он поймает, а что нет. У вероятностного предела нет — есть распределение, которое меняется при смене модели, при росте контекста и просто со временем. Поэтому строить имеет смысл снизу вверх: сначала то, что можно замкнуть, потом то, что нельзя.
Что дальше
Следующий слой — оценка смысла, и вот здесь модель уже нужна: соответствует ли текст задаче, не потерян ли основной тезис, попадает ли в аудиторию. Это то, что не замыкается на самом тексте и не имеет однозначного ответа.
И когда мы этот слой добавим, Constrain и Verify уже будут стоять. Права, журнал, версии, откат, пересчёт на сервере — всё это не придётся строить задним числом, после первого инцидента. Из четырёх функций у нас закрыты две, и это честная позиция: не «мы всё умеем», а «мы начали с того слоя, который не требует модели, и знаем, зачем».
