От промпта до агента в продакшене: 5 слоёв, без которых ваш ИИ-агент развалится

Вокруг ИИ-агентов сейчас крутятся пять модных терминов: context engineering, loop engineering, Jev engineering, harness engineering и eval engineering. Кажется, что это конкурирующие подходы, но на деле это пять слоёв одной системы, и каждый отвечает на свой вопрос. Автор популярного гайда в X под ником Yarchi предлагает простую метафору: представьте, что вы наняли нового сотрудника. Модель это сам человек, а пять слоёв описывают всё, что его окружает: что лежит у него на столе, работает ли он по чек-листу или сам решает, что делать дальше, кто сортирует ему почту, в каком офисе он сидит и какой экзамен сдаёт каждый месяц.

Разберём каждый слой: что это, как работает и как построить его своими руками.

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

Больше контекста не значит лучше. В исследовании Стэнфорда модели давали от 20 до 30 документов, и точность на документах из середины падала примерно до 50 процентов. Без документов вовсе та же модель набирала 56 процентов: ответ был в окне, а результат оказался хуже, чем без него. Модели лучше всего видят начало и конец окна, а каждый лишний токен стоит денег и времени.

Главная механика, которую стоит знать, это prompt caching. Провайдер запоминает начало промпта, и кэшированный токен стоит примерно в десять раз дешевле свежего. Но кэш работает, только если начало совпадает байт в байт. Поменяли один символ наверху, и всё, что ниже, оплачивается по полной цене. Отсюда правило: стабильное в начало, изменяемое в конец.

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

Инструменты тоже съедают место. Anthropic насчитала, что 58 описаний инструментов занимают около 55 000 токенов ещё до первого слова пользователя, а поиск нужного инструмента вместо загрузки всех сразу поднял Opus 4 с 49 до 74 процентов на их бенчмарке. Ориентир простой: до 20 инструментов держите загруженными, больше переходите на поиск. Для крупных задач отправляйте субагента: он прочитает 50 файлов в своём окне и вернёт сводку на одну страницу.

Сотруднику можно дать чек-лист: открой файл, поправь строку 12, сохрани. А можно цель: сделай так, чтобы тест прошёл. Чек-лист это workflow, цель это loop. Цикл состоит из четырёх ходов: подумать, сделать, посмотреть на результат и решить, что дальше. Сто шагов, написанных вами, всё равно остаются workflow. Три шага, выбранных моделью, уже цикл.

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

Без любой из четырёх частей цикл ломается. Нужна цель с понятным критерием готовности: не «почини баг», а «падающий тест в auth_test.py проходит, и больше ничего не сломалось». Нужен внешний проверяющий вроде тестов, компилятора или линтера: самокоррекция работает только с реальной обратной связью, а когда модель проверяет сама себя, получаются просто бесконечные траты. Нужно правило остановки и бюджет в шагах и долларах. В коде всё это умещается в несколько строк:

Лучший опубликованный продакшен-пример гибридный. В Atlan сначала работает детерминированный фильтр, и до агента доходит лишь около 14 процентов алертов. Цикл получает максимум три итерации, и если уверенность после них ниже 50 процентов, управление забирает фиксированный Python-воркфлоу. Сначала фильтр, потом короткий цикл, потом запасной путь.

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

Заявленные цифры впечатляют: от 70 до 500 миллисекунд на ответ и $0,042 за миллион входных токенов при бесплатном выводе. Но автор честно предупреждает, что инструменту всего две недели. В классификации писем обычная логистическая регрессия показала 98,9 процента против 98,6 у Jev, а в поиске фишинга Jev набрал 62,6 процента против 81,3 у Claude Haiku 4.5. «Ноль галлюцинаций» означает лишь, что ответ всегда соответствует схеме, а оценка уверенности не является настоящей вероятностью, и пороги нужно подбирать на своих размеченных данных.

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

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

Я регулярно разбираю такие гайды по косточкам: как устроены ИИ-агенты, что реально работает в продакшене и какие инструменты экономят время команде. Больше экспертных разборов про ИИ и технологии в моём Telegram-канале, подписывайтесь!

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

В 2026 году harness стал отдельной дисциплиной, потому что измерения показали, как много от него зависит. Anthropic поменяла только ресурсы контейнера и сдвинула результат бенчмарка на 6 пунктов. LangChain заморозила модель и сдвинула тот же бенчмарк на 13,7 пункта одной лишь обвязкой, а затем настроила её вокруг открытой модели в десять раз дешевле и получила 0,86 против 0,87 у Opus 4.8. Вы больше не покупаете модель, вы покупаете модель вместе с обвязкой.

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

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

Хуки это принудительная версия той же идеи. В Claude Code хук запускается перед вызовом инструмента и может его заблокировать, поэтому правило «никогда не пушь в main» надёжно работает как хук, а не как строчка в промпте. И важное предупреждение: каждый элемент обвязки это ставка на то, что модель чего-то не умеет, а такие ставки устаревают. Перечитывайте свой harness раз в несколько месяцев и удаляйте то, из чего модель уже выросла.

Как понять, что новый сотрудник стал лучше? Дать ему тот же тест, что и месяц назад, и сравнить. Без этого каждое изменение агента остаётся догадкой. Evals это набор задач с заранее известным правильным ответом, который прогоняется после каждого изменения.

Проверки бывают двух видов. Сквозные смотрят, верен ли итоговый ответ, но не объясняют, почему сдвинулся результат. Поведенческие проверяют конкретное действие по трассе агента: вызвал ли он поиск перед ответом, задал ли уточняющий вопрос, убедился ли в результате, прежде чем сказать «готово». Правило Google: такой набор должен выполняться меньше чем за пять секунд, чтобы его можно было запускать на каждое изменение. Если оценивает модель-судья, её тоже нужно проверять. В Airbnb обнаружили, что около трёх четвертей эталонных ответов, сгенерированных моделью, менялись при повторных прогонах, и их eval по сути измерял собственный шум.

Начинайте с реальных провалов и превращайте каждый в тест-кейс с одной проверкой. Золотые наборы Airbnb содержат от 50 до 100 примеров, и провалы там обязательны. Сверяйте судью с ручной оценкой и постоянно подмешивайте свежие данные: Airbnb ежедневно берёт 5 процентов живого трафика. Один кейс может выглядеть так:

И не смотрите только на общий процент прохождения. Он может расти, пока одно конкретное поведение тихо ломается.

Пять слоёв, пять вопросов. Контекст отвечает за то, что агент видит. Цикл решает, кто выбирает следующий шаг. Jev берёт на себя дешёвые решения. Harness определяет, до чего агент может дотянуться и кто его проверяет. Evals показывают, стало ли на самом деле лучше.

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

Вывод автора звучит трезво: модель больше не самая сложная часть системы. Сложность в пяти слоях вокруг неё. Большинству команд стоит взять первые три готовыми и потратить собственное время на два слоя, которые определяют качество: дешёвые решения и evals.

А какой из пяти слоёв в вашем проекте самый слабый? Пишите в комментариях.