В первой части серии я ввёл формулу: агент — это модель плюс harness, и всё интересное происходит во втором слагаемом. Формула хороша как лозунг, но плоха как инструкция. Когда я начал разбирать свои собственные обвязки — ту, что вокруг QA-агентов, и ту, что выросла вокруг кодогенерации, — мне понадобилось что-то более конкретное, чем «всё вокруг модели».
Оказалось, что и мои куски, и то, что пишут команды, которые запускают агентов в продакшн, раскладывается на пять слоёв. Не семь и не три — я пробовал и так, и так, получалось или дробно, или бессмысленно. Пять. В этом посте разберу каждый на одной сквозной задаче.
Сквозная задача
Чтобы не говорить абстрактно, возьмём обычный тикет: «форма регистрации принимает пустой email, нужен фикс и тест». Отдаём его агенту и смотрим, какой слой harness включается на каждом шаге. И что происходит, если слоя нет.
Слой первый: оркестрация инструментов
Агент начинает с того, что ему нужно что-то делать: прочитать файлы формы, найти валидацию, запустить тесты. Для всего этого у него есть инструменты. Первый слой harness отвечает на вопросы: какие инструменты вообще существуют, как агент узнаёт, как их вызывать, и что он видит в ответ.
Три вещи, которые я считаю обязательными в этом слое. Первая — реестр инструментов с машиночитаемыми схемами. Я писал про правило «сначала схема, потом вызов» в посте про QA-агентов, и с тех пор только укрепился в нём: агент, который читает схему перед вызовом, на порядок реже передаёт строку вместо массива. Схема — это контракт, а не документация для галочки.
Вторая — узкие инструменты вместо универсальных. «Выполни произвольную команду» — плохой инструмент. «Запусти тесты в этой директории» — хороший. Чем шире инструмент, тем больше способов применить его не по назначению.
Третья — осмысленные ответы. Инструмент, который на ошибку отвечает «exit code 1», заставляет модель гадать. Инструмент, который отвечает «тест упал: ожидался статус 422, получен 200, пустой email прошёл валидацию», даёт агенту следующий шаг.
Уберите этот слой, и агент долбится в инструменты вслепую, а половина бюджета уходит на ошибки вызовов.
Слой второй: верификационные петли
Агент написал фикс. Кто сказал, что он работает? Второй слой — это петли, которые проверяют работу агента до того, как её увидит человек.
Базовый паттерн тут — цикл «план, исполнение, проверка». Агент сначала описывает, что собирается сделать, потом делает, потом обязан доказать результат: запустить тест, прогнать линтер, собрать проект. В нашем тикете это выглядит так: агент пишет тест на пустой email, убеждается, что тест падает на старом коде, чинит валидацию, убеждается, что тест зелёный, и только потом докладывает.
Мелочь, которая важна: проверка должна быть детерминированной. Правило в промпте «убедись, что всё работает» модель может «убедиться» декларативно — напишет, что убедилась. Запуск теста обмануть нельзя. Любое текстовое правило, которое вы цените, должно со временем стать проверкой или генератором, делающим ошибку структурно невозможной. Проза лжёт, exit code — нет.
Без этого слоя: вы получаете правдоподобный код, который не работает, и узнаёте об этом из CI. Или из продакшна.
Слой третий: контекст и память
Наш тикет маленький, но реальные задачи длиннее одного экрана. Агент читает форму, валидацию, тесты, логи. Контекстное окно конечно, и третий слой решает, что в него попадает, что вытесняется и что агент будет помнить завтра.
Практики, которые работают у меня. Чекпоинты: на длинной задаче агент периодически сбрасывает в файл сжатое состояние — что сделано, что узнал, что дальше. Если сессия умерла или контекст переполнился, следующая сессия начинается с чекпоинта, а не с нуля. Явное забывание: черновые эксперименты, неудачные гипотезы и отладочный шум не должны копиться в контексте, они вытесняют полезное. И разведка с маленьким следом: инструменты «только чтение», которые не тащат в контекст простыни DOM или логов, а возвращают выжимку.
Отдельно скажу про память между сессиями. Тут соблазн построить «базу знаний проекта» и скармливать её всем агентам. У меня лучше работает скромный вариант: файл правил в репозитории плюс короткие записи о повторяющихся ошибках. Всё остальное быстро превращается в помойку, которой никто не доверяет, включая агента.
Когда этого слоя нет, агент на шаге сорок забывает, что он делал на шаге пять, и начинает передумывать собственные решения.
Слой четвёртый: ограничения
Агент с инструментами и без рамок — это не автономность, это риск. Четвёртый слой отвечает за «что нельзя»: лимиты попыток и бюджеты, запретные зоны, действия, требующие человека.
Из прошлых постов сюда переезжают почти дословно: явный лимит попыток (у меня 15–20 на задачу в зависимости от платформы), коммит только по запросу, никакого доступа к продакшн-данным, минимальный diff. Добавлю то, что стало стандартом за последний год: исполнение в песочнице — команды агента выполняются в изолированном окружении, где просто физически нет доступа к секретам и боевым системам. Это снимает целый класс проблем разом, включая часть атак через prompt injection: вредоносная инструкция, подсунутая в текст тикета, упрётся в стену песочницы.
Про запретные зоны важен принцип: «нельзя» должно быть реализовано механизмом, а не просьбой. «Не трогай миграции» в AGENTS.md — просьба. Отдельный CODEOWNERS на миграции и обязательное одобрение человека — механизм. Просьбы модель игнорирует под давлением контекста, механизм — нет.
Цена его отсутствия простая: однажды утром вы обнаружите, что агент «починил» продакшн-конфиг. Или потратил месячный бюджет токенов за ночь, героически решая задачу, которую надо было вернуть человеку после пятой попытки.
Слой пятый: наблюдаемость
Последний слой — возможность ответить на вопрос «что вообще произошло?». Агент — недетерминированная система, которая принимает решения. Без трассы вы не отладите ни её поведение, ни её стоимость.
Минимум, который нужен: трасса каждой сессии — какие инструменты вызваны, с какими аргументами, что вернули, сколько токенов ушло на шаг. По трассе вы отвечаете на вопросы «почему агент выбрал этот путь», «где он потерял половину бюджета», «какая проверка ловит больше всего его ошибок». Именно из трасс растут и лимиты, и evals, и понимание, куда вкладываться дальше. Второй минимум — агрегированные метрики: стоимость на задачу, доля задач, закрытых без человека, доля откаченных правок. К метрикам мы ещё вернёмся в финальной части серии.
Без этого слоя: каждая проблема агента — это детектив без улик. «Почему он это сделал?» — «не знаем, логи не ведём».
Как слои работают вместе
Вернёмся к тикету. Оркестрация даёт агенту инструменты со схемами. Контекст подсказывает, где лежит валидация и какие у проекта правила. Ограничения запрещают лезть в соседние модули и считают попытки. Верификация заставляет доказать фикс тестом, который сначала красный, потом зелёный. Наблюдаемость записывает всё это в трассу, по которой вы за две минуты понимаете, что и почему произошло.
Уберите любой слой — и задача или развалится, или выполнится так, что результату нельзя доверять. Причём заметно, что слои не равнозначны по зрелости у большинства команд: инструменты есть у всех, верификация — у многих, а вот ограничения и наблюдаемость чаще всего отсутствуют полностью. Именно на них и горят.
Главный вывод
Harness — не монолит, а пять слоёв: оркестрация инструментов, верификационные петли, контекст и память, ограничения, наблюдаемость. Каждый слой отвечает на свой вопрос: чем агент действует, кто проверяет, что он помнит, куда ему нельзя и как мы смотрим, что произошло.
Строить все пять сразу не нужно. Нужно честно определить, каких слоёв у вас нет, и закрывать дыры в порядке цены ошибки. Обычно первой дырой оказываются ограничения, второй — верификация. У вас может быть иначе, чеклист ниже как раз для этой диагностики.
Практический чеклист
Пройдитесь по слоям и отметьте, что реально работает в вашем проекте, а не «вроде есть»:
- У каждого инструмента агента есть машиночитаемая схема, и агент читает её перед вызовом.
- Агент обязан доказать результат проверкой: тест, линтер, сборка. «Уверяю, что работает» не считается.
- Есть чекпоинты на длинных задачах: упавшую сессию можно продолжить не с нуля.
- Лимит попыток и бюджет заданы явно, и агент останавливается по ним, а не по истечении контекста.
- Запретные зоны реализованы механизмом: права доступа, CODEOWNERS, одобрения. Не просьбой в промпте.
- Команды агента исполняются в изолированном окружении без доступа к секретам и продакшну.
- По любой сессии агента можно поднять трассу и понять, что он делал и сколько это стоило.
Дальше по серии: часть про переносимый слой — AGENTS.md, схемы и MCP. Это те инвестиции, которые не сгорят при смене вендора агента. Если прошлись по чеклисту — напишите, сколько пунктов закрыто. У меня, когда я первый раз честно его прошёл, было три из семи.
Обсуждение
Комментариев пока нет — начните тему.