Обвязка ИИ-агента: шесть решений

Знакомая картина. Агент рапортует, что задача закрыта, хотя тестовый прогон он так и не сделал. Первые двадцать минут он собран, потом забывает правило, которое вы дали ему в самом начале. Каждую сессию вы заново вставляете одни и те же три инструкции. И отойти нельзя: где-то обязательно висит очередное окно с запросом подтверждения.

Смена модели на более сильную тут не спасает. Всё перечисленное живёт в софте вокруг модели: что ей сообщают, что она запоминает, к чему её пускают и кто проверяет результат. Эта обвязка называется harness. Она у вас уже есть. Вопрос только в том, проектировал ли её кто-нибудь.

Что такое harness

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

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

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

Как это выглядит на практике

DoorDash собрал обвязку как платформу. Каждый агент поднимается в одноразовой виртуальной машине, где уже лежат репозитории, инструменты и учётные данные. Работа описана YAML-плейбуками, где шаги агента перемешаны с обычными скриптовыми шагами. Всё, что идёт во внутренние системы, проходит через единый шлюз: он выдаёт только объявленные в плейбуке инструменты и логирует каждый вызов. За месяц они прогнали 130 000 автоматических задач, включая больше 25 000 код-ревью в неделю.

OpenAI пошли другим путём и сделали обвязкой сам репозиторий. Никакой платформы. Файл инструкций держат примерно в сотне строк и используют как оглавление к нормальной папке с документацией, а архитектурные правила вынесены в собственные линтеры вместо текста, который модель может пролистать по диагонали. Три инженера так вмержили около 1500 пул-реквестов за пять месяцев.

Anthropic разделили роли. Три агента с разными задачами: один превращает одно предложение в спецификацию, второй реализует, третий открывает готовое приложение в браузере и выставляет оценку. Общаются они только через файлы. Работает, но обошлось в 6 часов и 200 долларов там, где прогон без обвязки занял 20 минут и 9 долларов. Больше чем двадцатикратная разница в цене за заметно лучший результат, и об этом размене обычно молчат.

Три совершенно разные конструкции. Общее у них одно: ничего из этого не было в коробке.

Решение первое. Цикл и точка остановки

Обвязка отправляет модели вашу задачу плюс всё, что уже произошло. Модель отвечает либо запросом на вызов инструмента, либо финальным сообщением. Если это запрос, обвязка выполняет инструмент, приклеивает результат к истории и отправляет всё заново. И так до тех пор, пока модель не перестанет просить инструменты. Вот и весь цикл, одинаковый во всех продуктах на рынке.

Внутренний цикл принадлежит вендору. Вам принадлежит всё вокруг: что происходит, когда цикл останавливается, и запускается ли он снова.

Сформулируйте правило остановки одним предложением, до начала работы. Например: готово значит, что тестовый набор проходит и приложение поднимается. По умолчанию у вас сейчас работает другое правило: готово значит, что агент так сказал.

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

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

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

Кто-то вручную разобрал пятьдесят опубликованных агентских циклов. Только 74% из них вообще формулировали, что считается завершением, и только 32% хранили хоть какую-то память между запусками. Это самая дешёвая правка в списке и одновременно та, которую пропускают чаще всего.

Решение второе. Инструменты, которые агент видит

Модель не видит ваших систем. Она видит меню из описаний функций, и это меню для неё и есть весь мир.

Перестаньте грузить все инструменты сразу. Если у вас подключено несколько MCP-серверов, описания всех их инструментов попадают в контекст на каждом шаге, нужны они задаче или нет. Лечится тем, что инструменты кладут на диск файлами и дают агенту открывать только нужные. У Anthropic есть разобранный пример: 150 000 токенов превратились в 2000.

Перепишите тексты ошибок. Большинство инструментов падают фразой, написанной для человека: «неверный запрос». Модели это не говорит ничего, поэтому она гадает и обычно гадает мимо. Возвращайте структуру: какое поле неверное, как выглядит валидное значение, что попробовать дальше. Siemens измерили это аккуратно и получили прирост в 37 до 40 пунктов по доле выполненных задач примерно за половину токенов на успех.

Сократите меню. Посмотрите, к скольким инструментам у агента сейчас есть доступ, и уберите всё, чем он не пользовался месяц. Два инструмента с похожими названиями обойдутся вам дороже, чем один отсутствующий.

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

Всё это можно пропустить, если у вас один агент на одном репозитории и только встроенные инструменты. Экономия токенов реальна, но пока это не ваше узкое место.

Решение третье. Что остаётся в памяти

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

Не заполняйте его. На модели с миллионом токенов работайте до 300 или 400 тысяч и останавливайтесь. Дальше сбои перестают быть похожи на растерянность и начинают быть похожи на небрежность: агент удаляет конфиг, который трогать не следовало.

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

Прибейте правила гвоздями. Факты и правила ведут себя по-разному. Факты можно пересказать и забыть. Правила нельзя: никогда не трогать прод, никогда не коммитить секреты, этот контракт API зафиксирован. Держите их в файле, который агент перечитывает после каждого сброса, и дублируйте в системном промпте. Намеренная избыточность.

Перезапускайтесь, когда модель начинает со всем соглашаться. Если она приняла пять ваших предложений подряд без единого возражения, сессия закончилась. Что-то неверное попало в контекст рано, и всё последующее считает это установленным фактом.

Одно исследование измеряло, как часто агент нарушает записанное правило. Нарушений было ноль, пока правило оставалось в контексте целиком, 30% после сжатия и 59% на худшей модели. Там, где правило переживало пересказ, нарушения оставались на нуле. У той работы один автор и нет рецензирования, так что относитесь к цифре как к сильному намёку, а не как к установленному факту. Починка в любом случае стоит одного вечера.

Решение четвёртое. Что переживает падение

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

Лечится четырьмя файлами в репозитории, которые агент обязан держать актуальными. SPEC.md описывает, что вы строите: его пишете вы, агент его не редактирует, и именно он не даёт цели уплывать на длинной дистанции. PLAN.md содержит шаги, у каждого внятный критерий приёмки. Формулировка «улучшить обработку ошибок» не годится, годится «запрос к /orders без id возвращает 400 с сообщением, и тест на это проходит». PROGRESS.md хранит, что сделано, что дальше и что пробовали безуспешно: это первый файл, который читает свежий агент. DECISIONS.md пишется только на дописывание, каждое решение и причина. Без него следующая сессия заново пережёвывает вопрос, закрытый два часа назад.

Дальше заставьте агента коммитить после каждого рабочего изменения. Мелкие коммиты с осмысленными сообщениями. Откат превращается в git revert, ревью в чтение диффов, а история появляется бесплатно, вместо того чтобы строить систему чекпойнтов.

Если фич много и они независимы, добавьте пятый файл: обычный JSON-список всех фич с отметкой passing или failing. Самый дешёвый трекер прогресса из существующих, и агент может вести его сам.

Правило простое: чего нет в файле, того не существует.

Решение пятое. К чему агенту разрешено прикасаться

Агент, запущенный на вашем ноутбуке, располагает вашими SSH-ключами, вашей VPN-сессией и всеми CLI, куда вы залогинены. Чтобы это плохо кончилось, ему не нужно быть злонамеренным. Достаточно одной отравленной веб-страницы в контексте.

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

Перестаньте полагаться на окна подтверждения. Люди подтверждают 93% из них. Запрос, который вы всегда прокликиваете, перестал быть контролем безопасности и стал задержкой, которую вы построили себе сами. Оставьте подтверждения для той горстки случаев, где вы действительно остановитесь, а всё остальное закройте границами.

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

Никогда не кладите в песочницу долгоживущие учётные данные. Только короткоживущие токены, ограниченные одной задачей. Если агент может прочитать ключ, считайте, что ключ уже лежит в чьём-то контекстном окне.

Anthropic сообщила, что нормальная песочница сократила количество запросов на подтверждение внутри компании на 84%. Вот настоящий аргумент: становится безопаснее и заодно сильно менее раздражающе, поэтому такая практика приживается.

Решение шестое. Кто говорит, что готово

Агент, написавший код, худший из доступных судей о том, работает ли код. Он оценивает сам себя и оценивает щедро.

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

Заставьте его реально запустить результат. Для веб-приложения открыть в настоящем браузере. Для CLI выполнить команду. Прочитать дифф и объявить его правильным значит получить второе мнение о той же догадке.

Соберите набор эвалов из ваших собственных прошлых провалов. Двадцати или пятидесяти задач достаточно для старта. Настоящих, из вашего репозитория, где вы своими глазами видели, как агент ошибся.

Гоняйте каждую задачу три раза и судите по худшему прогону. Это важнее, чем кажется. Успех в 75% на попытку означает, что все три попытки проходят только в 42% случаев. Агенты недетерминированы, и один зелёный прогон не говорит почти ни о чём.

Следите за уверенным неверным ответом. Характерный отказ агента выглядит не как падение. Он натыкается на ошибку и пишет гладкий абзац о том, почему она не важна. В одном продакшен-исследовании около 70% таких случаев ловил человек, заметивший неладное, и почти ни одного не поймали тесты. Прогрепайте логи на текст, похожий на объяснения, рядом с обработкой ошибок.

Про политику ретраев данных нет вообще. Сколько раз повторять, с какой задержкой, повторять ли или перезапускаться с нуля. У всех есть мнение, ни у кого нет цифр. Если вы ловите себя на том, что неделю крутите эти настройки, знайте, что находитесь на неисследованной территории.

Версия на выходные

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

Итог

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

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

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

Источник: How to Design an Agent Harness