Agent harness: шесть решений, после которых ИИ-агента можно оставить одного

Агент рапортует, что задача готова, а тесты так и не запускались. Первые двадцать минут он соображает быстро, потом забывает правило, которое вы дали в самом начале. Каждую сессию вы заново вбиваете одни и те же три инструкции. Отойти от компьютера нельзя: всегда висит очередной запрос на подтверждение.
Более сильная модель ничего из этого не исправит. Все эти проблемы живут в софте вокруг модели: что ей сообщают, что она запоминает, к чему у нее есть доступ и кто проверяет результат. Эту обвязку называют agent harness. Она есть у каждого, кто работает с ИИ-агентами. Вопрос лишь в том, проектировал ли ее кто-нибудь осознанно.
Из чего состоит harness
Между моделью и работой стоят шесть вещей: цикл, который гоняет агента, инструменты, которые он может вызывать, содержимое его памяти, то, что переживет падение, границы доступа и тот, кто решает, что работа закончена.
Половина приходит из коробки. Цикл, встроенные инструменты и управление контекстом сделал вендор, и повлиять на них почти нельзя. Вторая половина ваша: файл с инструкциями, тесты, права доступа, определение готовности. Она существует независимо от того, думали вы о ней или нет. Любое правило, которое вы раз за разом копируете в чат, уже ее часть.
Термин harness закрепился в начале 2026 года. До этого у слоя не было общепринятого названия, и во многом поэтому им так долго никто не управлял.
Как это устроено у DoorDash, OpenAI и Anthropic
DoorDash сделал harness платформой. Каждый агент запускается в собственной одноразовой виртуальной машине, где уже лежат репозитории, инструменты и доступы. Работа описана YAML-плейбуками, в которых шаги агента перемешаны с обычными скриптами. Все обращения к внутренним системам идут через единый шлюз: он выдает только те инструменты, которые объявлены в плейбуке, и логирует каждый вызов. За месяц так прошло 130 000 автоматических задач, включая больше 25 000 код-ревью в неделю.
OpenAI обошлась без платформы и превратила в harness сам репозиторий. Файл инструкций ужат примерно до 100 строк и работает как оглавление к нормальной папке с документацией. Архитектурные правила проверяют кастомные линтеры: абзац текста модель может пропустить, упавшую сборку пропустить не получится. Три инженера смержили так около 1500 пулл-реквестов за пять месяцев.
Anthropic разделила роли между тремя агентами. Первый превращает одно предложение в спецификацию, второй ее реализует, третий открывает готовое приложение в браузере и ставит оценку. Общаются они только через файлы. Схема работает, но стоит 6 часов и $200, тогда как прогон без обвязки занял 20 минут и $9. Результат сильно лучше, цена выше в двадцать с лишним раз, и об этом компромиссе обычно молчат.
Три совершенно разные формы, и ни одна из них не пришла из коробки.
Решение 1. Цикл и точка остановки
Harness отправляет модели задачу и всю историю. Модель отвечает либо запросом на вызов инструмента, либо финальным сообщением. В первом случае harness выполняет инструмент, приклеивает результат к истории и отправляет все заново. Так продолжается, пока модель не перестанет просить инструменты. Этот цикл одинаков во всех продуктах на рынке.
Внутренний цикл принадлежит вендору. Ваша зона ответственности начинается там, где он останавливается: что происходит дальше и запускается ли он снова.
Сформулируйте правило остановки одним предложением до старта, например «готово, когда проходят тесты и приложение запускается». Сейчас по умолчанию у вас действует другое правило: готово, когда агент сказал, что готово. Заранее решите, что делать с оборванным прогоном: перезапускать с заметкой о том, что сломалось, или ставить на паузу до вашего возвращения. Если ответа нет, агент молча придумает свой. Поставьте жесткий лимит по числу ходов или минутам. Агент, который сорок раз переписал один файл, на сорок первый его не починит, зато охотно потратит ваши деньги. Для автономных запусков пишите каждый ход в лог-файл, потому что восстановить шестичасовую сессию по памяти невозможно.
Кто-то вручную разобрал пятьдесят опубликованных агентных циклов. Только в 74% было прописано, что считается завершением, и только 32% хранили хоть какую-то память между запусками. Это самое дешевое исправление из всего списка, и его пропускают чаще остальных.
Решение 2. Какие инструменты видит агент
Модель не видит ваших систем. Перед ней меню из описаний функций, и для нее это весь мир.
Перестаньте грузить все инструменты сразу. Если подключено несколько MCP-серверов, описания всех их инструментов попадают в контекст на каждом ходу, даже если задаче они не нужны. Положите инструменты на диск в виде файлов и дайте агенту открывать только нужные. В Anthropic показали рабочий вариант такого подхода: расход упал со 150 000 токенов до 2 000.
Перепишите сообщения об ошибках. Большинство инструментов падают с фразой для человека вроде «invalid request». Модели это ничего не говорит, она гадает и обычно ошибается. Возвращайте структуру: какое поле неверно, как выглядит допустимое значение, что попробовать дальше. Siemens аккуратно это измерил и получил прирост доли завершенных задач на 37-40 пунктов при примерно вдвое меньшем расходе токенов на успешную задачу.
Сократите меню. Посмотрите, сколько инструментов доступно агенту сейчас, и уберите все, чем он не пользовался месяц. Два инструмента с похожими названиями вредят сильнее, чем отсутствие одного. Если пишете свои инструменты, учтите, что имена и группировка заметно меняют поведение модели, так что префиксы и суффиксы тут влияют на результат.
Если у вас один агент, один репозиторий и только встроенные инструменты, этот шаг можно отложить: экономия токенов реальная, но узкое место у вас пока в другом месте.
Решение 3. Что остается в памяти
Все, что модель знает о задаче, лежит в одном буфере. Когда он заполняется, старое содержимое сжимается в саммари и выбрасывается. Вы не выбираете, что уйдет, и модель не сообщает, что это произошло.
Не заполняйте контекст до конца. На модели с окном в миллион токенов остановитесь на 300 или 400 тысячах. Дальше ошибки похожи уже на небрежность: агент может удалить конфиг, который трогать было нельзя.
Сжимайте контекст сами, в выбранных точках. Разбейте работу на этапы: исследование, документ, план, реализация. Каждый этап начинайте в чистом окне, где есть только документ с предыдущего шага, и читайте этот документ между этапами. Медленнее, зато намного надежнее.
Закрепите правила. Факты можно сжимать, правила нельзя: не трогать прод, не коммитить секреты, этот API-контракт фиксирован. Вынесите их в файл, который агент перечитывает после каждого сброса, и продублируйте в системном промпте.
Перезапускайте сессию, когда агент начинает со всем соглашаться. Если модель приняла пять ваших предложений подряд без единого возражения, сессия испорчена: в начале туда попало что-то неверное, и дальше это считается установленным фактом.
В одном исследовании нарушения письменного правила росли с нуля, пока правило было на виду, до 30% после сжатия контекста и до 59% на худшей модели. Там, где правило пережило саммари, нарушений не было вовсе. Работа написана одним автором и не прошла рецензирование, так что цифры стоит считать сильным сигналом. Само исправление в любом случае занимает полдня.
Решение 4. Что переживет падение
Агент обязательно упадет посреди задачи: переполнится окно, вылетит процесс, вы закроете ноутбук. Все, что существовало только в переписке, пропадет.
Заведите в репозитории четыре файла и попросите агента держать их актуальными. SPEC.md описывает, что вы строите. Его пишете вы, агент его не редактирует, и именно он не дает цели уплыть за долгий прогон. PLAN.md содержит шаги, у каждого простой критерий приемки. Формулировка «улучшить обработку ошибок» не годится, нужно что-то вроде «запрос к /orders без id возвращает 400 с сообщением, и тест на это проходит». PROGRESS.md хранит, что сделано, что дальше и что пробовали без успеха. Новый агент читает его первым. В DECISIONS.md записи только добавляются: каждое решение и его причина. Без него следующая сессия заново начнет спорить о том, что вы решили два часа назад.
Пусть агент коммитит после каждого рабочего изменения, маленькими коммитами с нормальными сообщениями. Откат превращается в git revert, ревью в чтение диффов, а полная история достается бесплатно.
Если в проекте много отдельных фич, добавьте пятый файл: простой JSON со списком фич и статусом passing или failing. Это самый дешевый трекер прогресса, и агент обновляет его сам.
Если чего-то нет в файле, этого не существует.
Решение 5. К чему у агента есть доступ
Агент на вашем ноутбуке получает ваши SSH-ключи, VPN-сессию и все CLI, где вы залогинены. Злой умысел для катастрофы не нужен, хватит одной отравленной веб-страницы в контексте.
Поставьте две границы на уровне операционной системы: ограничьте каталоги для записи и пустите сеть через прокси со списком разрешенных доменов. Ограничение внутри агента легко обойти: он вызовет скрипт, тот вызовет curl, и запрет останется позади. Ограничение на уровне ОС распространяется на все порожденные процессы.
Перестаньте полагаться на запросы подтверждения. Люди одобряют 93% из них. Если вы всегда жмете «разрешить», вы построили себе задержку, защиты в этом нет. Оставьте подтверждения для пары действий, на которых вы действительно остановитесь, а все остальное закройте границами.
Если агенты нескольких людей работают с общими системами, поставьте перед ними единый шлюз, который выдает только заявленные инструменты и логирует каждый вызов. Именно лог позволяет потом разобрать инцидент. И никогда не кладите в песочницу долгоживущие ключи, только короткие токены под одну задачу. Если агент может прочитать ключ, считайте, что ключ уже лежит в чьем-то контексте.
По данным Anthropic, нормальная песочница сократила число запросов на подтверждение внутри компании на 84%. Безопасность здесь идет в комплекте с удобством, поэтому такая настройка и приживается.
Решение 6. Кто решает, что работа готова
Агент, написавший код, хуже всех способен оценить, работает ли этот код. Он сам себя проверяет и ставит себе завышенные оценки.
Проводите ревью в отдельной сессии, в свежем окне без памяти о написании. Модель может быть та же, важно, чтобы в контексте не осталось рассуждений, которые породили баг. Заставьте ревьюера запускать результат: веб-приложение гонять в настоящем браузере, CLI выполнять. Прочитать дифф и объявить его верным значит получить второе мнение о той же догадке.
Соберите набор эвалов из сбоев, которые у вас уже случались. Для начала хватит 20-50 настоящих задач из вашего репозитория. Запускайте каждую трижды и судите по худшему прогону. При 75% успеха на попытку все три попытки проходят лишь в 42% случаев, так что один зеленый прогон почти ничего не говорит.
Отдельно следите за уверенными неправильными ответами. Типичный провал агента выглядит как гладкий абзац о том, почему ошибка не важна. В одном исследовании на проде около 70% таких случаев поймал человек, тесты их пропустили. Ищите в логах текст в духе объяснений рядом с обработкой ошибок.
Опубликованных данных о политике ретраев нет: сколько раз повторять, с какой задержкой, повторять ли вообще или начинать заново. Мнения есть у всех, цифр нет ни у кого.
Версия на выходные
Если строить только пять вещей, то в таком порядке. Файл инструкций короче ста строк, который работает как оглавление к папке документации. Линтер для всего, что сломалось дважды: правило, которое валит сборку, работает лучше вежливой просьбы в тексте. Четыре файла (спецификация, план, прогресс, решения) и коммит после каждого рабочего изменения. Закрепленные правила, которые не должны исчезать при сжатии контекста: безопасность, политики, жесткие лимиты. И двадцать задач по три прогона с оценкой по худшему. Все остальное уже оптимизация.
Итог
Отказаться от harness нельзя, он у вас уже есть. Это все, что накопилось само: обходные пути, добавленные в два часа ночи, правила, вставленные в конфиг и забытые, разрешения, которые проще было нажать, чем прочитать. Все решения в нем приняты, просто не вами.
И бесплатным он не бывает. Прогон Anthropic с обвязкой обошелся в двадцать с лишним раз дороже. Harness окупается на работе, которую иначе вообще нельзя было бы отдать агенту, и не окупается там, где вы хотели сэкономить двадцать минут.
Начните с правила остановки и четырех файлов. На это уйдет полдня, и оба решения переживут выход следующей модели.
Источник: статья Yarchi в X






