5 уровней AI-агентов: от промпта до продакшена

Сейчас в разговорах об агентах постоянно мелькают пять терминов: context engineering, loop engineering, Jev engineering, harness engineering и eval engineering.

Звучит так, будто это пять конкурирующих подходов. Но нет. Это пять слоёв одной системы, и каждый отвечает на свой вопрос.

Проще всего понять их, если представить, что вы только что наняли нового сотрудника:

• Context — что лежит у него на столе, когда вы задаёте вопрос
• Loop — идёт ли он по вашему чек-листу или сам решает, какой шаг будет следующим
• Jev — ресепшен, который сортирует почту, чтобы до него доходило только важное
• Harness — его кабинет. Инструменты, ключи и то, кто проверяет его работу
• Evals — один и тот же тест каждый месяц, чтобы вы понимали, стал ли он реально лучше

ИИ-агент — это и есть такой сотрудник. Модель — сам человек, а эти пять слоёв — всё, что его окружает. Настройте их правильно, и небольшая команда потянет объём работы, ради которого раньше пришлось бы нанимать людей. Рутина уходит агенту, который стабильно работает в проде, а ваши люди оставляют за собой решения. Вот так на практике выглядит масштабирование без раздувания штата.

По каждому слою я разберу, что это, как работает, где применять и как собирать.

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

Viktor — это ИИ-сотрудник, который живёт в вашем Slack или Microsoft Teams. Он сидит в тех же каналах, что и все остальные, и работает как коллега, которого можно добавить в команду без открытия новой вакансии.

Работа с ним выглядит как работа с человеком:

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

Настройка элементарная. Просто добавьте Viktor в рабочее пространство, и он появится в списке участников как любой другой член команды. Если хотите попробовать его прямо во время чтения, используйте код YARCHI100.

pic1. Пять слоёв агента

1. Context engineering

Определение

Перед каждым вопросом вы кладёте сотруднику на стол бумаги. Положите три нужные страницы — и он ответит за секунды. Положите триста — и ответ потеряется где-то в середине стопки. Он его просто пропустит.

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

Context engineering — это решение о том, что положить на стол и куда именно.

Как это работает

Больше контекста не значит лучше ответы. После определённого предела это значит хуже.

В Стэнфорде проверили это напрямую. Дайте модели от 20 до 30 документов, и её точность на тех, что оказались в середине, падает примерно до 50–57 процентов. А вообще без документов та же модель выдавала 56 процентов. Ответ лежал прямо в окне, но модель справилась хуже, чем когда его не было вовсе.

Причин две:

• Модели внимательнее всего смотрят на начало и конец окна, а середину почти игнорируют.
• Каждый токен стоит денег и времени, помогает он или нет.

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

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

Как это собирать

Любой кусок контекста попадает в одно из четырёх мест:

1. Системный промпт. Только то, что истинно при каждом вызове: роль, ограничения, формат вывода. Держите его идентичным байт в байт. Никаких таймстемпов в начале, никаких JSON-ключей в случайном порядке.
2. Инструменты. Не добавляйте и не удаляйте их посреди диалога. Это ломает кэш и заставляет модель вызывать инструменты, которых уже нет. Если нужно ограничить инструмент на каком-то шаге, блокируйте вызов, но оставляйте определение.
3. Диск. Всё крупное или долгоживущее уходит в файл, а в окне остаётся только путь. То же самое с веб-страницей: оставьте URL, уберите тело. Уберите контент, оставьте ключ, по которому его можно достать обратно.
4. Хвост. Каждые несколько шагов заново формулируйте текущую цель ближе к концу контекста. Середину вы не почините, поэтому держите важное подальше от неё.

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

Меньше 20 инструментов — держите загруженными. Больше — переходите на поиск.

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

pic2. Что попадает в один вызов модели

Шорткат

Viktor берёт большую часть этого на себя, потому что его контекст живёт на уровне компании.

• Память. Он хранит постоянную память о вашем бизнесе, общую для всей команды. То, что он узнал от вашего кофаундера на прошлой неделе, сегодня не нужно копипастить в запрос.
• Подключённые источники. Когда подключены Notion, Google Drive или HubSpot, вы перестаёте вставлять файлы в чат. Вы называете документ или запись, а он сам читает источник. Это правило «диска», реализованное за вас.
• Навыки (Skills). Вы один раз записываете экран, выполняя задачу. Он превращает запись в текстовую процедуру, вы её правите и утверждаете. С этого момента инструкция зафиксирована и проверена — как хороший системный промпт.

Что остаётся на вашей стороне:

• Один раз напишите короткий бриф о компании: что продаёте, кто покупает, какие цифры важны, чего ему категорически нельзя делать.
• Одна задача на тред, причём в первом сообщении — что значит «готово».
• Если он запомнил что-то неправильно, сотрите его память через настройки, а не поправляйте в каждом треде.

2. Loop engineering

Определение

Вы можете дать сотруднику чек-лист: открой файл, измени строку 12, сохрани. А можете дать цель: сделай так, чтобы тест прошёл.

С целью он пробует что-то, смотрит, что получилось, и решает, что делать дальше. Чек-лист — это workflow. Цель — это loop (цикл).

Как это работает

Цикл — это четыре повторяющихся движения: подумать, сделать, посмотреть, решить. Исправление бага выглядит так:

1. Запускаем тесты. Три падают.
2. Читаем первую ошибку. Не хватает импорта.
3. Добавляем импорт, запускаем снова.
4. Один тест всё равно падает. Читаем ошибку, чиним, запускаем снова.
5. Всё прошло. Стоп.

Никто заранее не прописывал эти шаги. Модель выбирала каждый из них, глядя на предыдущий результат.

В этом вся разница. Сотня шагов, которые написали вы, — всё ещё workflow. Три шага, которые выбрала модель, — это loop.

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

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

Как это собирать

Циклу нужны четыре части. Уберите любую — и он перестанет работать:

1. Цель с понятным критерием «готово». Не «почини баг», а: «падающий тест в auth_test.py проходит, и больше ничего не сломалось».
2. Проверяющий (checker). Что-то вне модели, что говорит «прошёл» или «не прошёл»: набор тестов, компилятор, линтер. Исследования самокоррекции здесь единодушны: она работает с реальной внешней обратной связью и ломается, когда модель просто проверяет сама себя. Нет checker'а — нет цикла, есть только бесконечные траты.
3. Правило остановки. Checker дал «прошёл», либо достигнут лимит ходов, либо последние две попытки дали одинаковый результат.
4. Бюджет. И в ходах, и в деньгах.

В коде всё это умещается в несколько строк:

1for turn in range(MAX_TURNS):
2    action = model.next_step(goal, history)
3    result = run(action)
4    history.append(result)
5
6    if checker(result):       break   # готово
7    if repeated(history, 2):  break   # застряли
8    if spent() > BUDGET:      break   # слишком дорого
9else:
10    fallback_workflow(goal)

Лучшая схема для продакшена, которую я видел в публикациях, — гибридная. Atlan сначала прогоняет детерминированный фильтр, и до агента доходит лишь около 14 процентов входящих алертов.

Затем циклу даётся максимум три итерации. Если после трёх уверенность всё ещё ниже 50 процентов, управление перехватывает фиксированный Python-workflow.

Сначала фильтруй, потом коротко крути цикл, а затем откатывайся на запасной план.

pic3. Как выбрать между workflow и loop

Шорткат

Любая задача, которую вы даёте Viktor в треде, — это цикл. Вы пишете цель, он выбирает шаги, работает через ваши инструменты и возвращается в тред с результатом.

Четыре части ложатся так:

• Цель. Он сопротивляется неполным брифам и спрашивает, а не додумывает. Но всё равно прописывайте, что значит «готово». «Отчёт по выручке за прошлую неделю, суммы бьются со Stripe, опубликовано в #finance до 9 утра понедельника» работает лучше, чем «сделай отчёт».
• Checker. Он подсвечивает подозрительные цифры до публикации. Усилить это можно, указав источник для сверки: сумму в Stripe, количество строк, набор тестов.
• Правило остановки. Чувствительные действия ставятся на паузу для человека, а результат всегда возвращается к вам.
• Бюджет. Кредиты. Уровень рассуждений (reasoning tier) задаёт цену каждого шага, а в регулярных задачах важна частота. Ежечасный отчёт стоит намного дороже еженедельного.

Гибрид от Atlan работает и без кода. Повторяющаяся работа становится задачей по расписанию: он предлагает её, и она висит на паузе, пока вы не одобрите. Это ваш workflow.

Всё, где нет чёткого конца, уходит в тред — и это ваш loop. Запасной план — вы сами.

3. Jev engineering

Определение

Эксперт в офисе не вскрывает каждый конверт. Кто-то на ресепшене сортирует почту: счета в одну стопку, спам в корзину, договоры юристу.

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

Jev — это ресепшен. Он никогда не пишет. Он только выбирает.

Как это работает

Вы заранее даёте Jev вопрос и возможные варианты ответов. Он возвращает одну из трёх вещей плюс показатель уверенности:

• да или нет
• один вариант из набора
• число по шкале

Поскольку он только выбирает, это быстро и дёшево. Заявленные цифры: 70–500 миллисекунд против 3–329 секунд, и $0.042 за миллион входных токенов при бесплатном выходе.

А теперь честно. Jev появился пару недель назад, и независимые тесты только начинают поступать.

• На классификации писем обычная логистическая регрессия выдала 98.9 процента против 98.6 у Jev.
• На детекции фишинга Jev получил 62.6 процента, а Claude Haiku 4.5 — 81.3.
• Цифра «ноль галлюцинаций» идёт с сноской самих авторов: это не эмпирика, это значит лишь то, что вывод всегда соответствует схеме.

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

Как это собирать

Разумная схема — гейт перед дорогой моделью:

1. Входит всё подряд.
2. Jev отвечает на один узкий вопрос по каждому элементу.
3. Уверенно и типично: обрабатывается дёшево. Размечается, маршрутизируется или выбрасывается.
4. Неуверенно или необычно: уходит в основную модель.

1d = jev.choose(item, options=["spam", "order_status", "refund", "other"])
2
3if d.confidence >= 0.7 and d.option != "other":
4    handle_cheap(d.option, item)
5else:
6    main_model(item)   # fail closed: неуверенность уходит в дорогой путь

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

Это полчаса работы, и это тот базовый уровень, который должны побить любые заявления вендоров.

pic4. Три типа вопросов, на которые отвечает Jev

Шорткат

Jev не входит в публичный стек Viktor, но саму идею можно применить в двух местах, которые контролируете вы:

• Уровень рассуждений. У него их три: Smart на Claude Opus, Balanced на Claude Sonnet примерно за половину стоимости и Ultra на Claude Fable примерно вдвое дороже. Для сортировки запросов или вытягивания одной цифры топ-уровень не нужен.
• Гейт перед ним. Если вы хотите, чтобы он обрабатывал поток вроде писем поддержки или алертов, не отдавайте ему весь поток. Сначала поставьте классификатор или вызов Jev, чтобы задачами для него становились только те элементы, где нужно принимать решение.

Это один из двух слоёв, где ваша собственная инженерия всё ещё имеет значение, даже с Viktor.

4. Harness engineering

Определение

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

Навыки те же, результаты совершенно разные. Сотрудник — это модель. Кабинет — это harness (обвязка).

Агент = модель + harness.

Как это работает

Harness — это всё, что не модель: инструменты, права доступа, песочница, файлы с описанием проекта, проверки результата.

Он стал отдельной дисциплиной в 2026 году, потому что люди начали измерять, и модель объясняла меньше, чем ожидалось:

• Anthropic изменили только ресурсы контейнера — и сдвинули результат бенчмарка на 6 пунктов.
• LangChain заморозили модель и сдвинули тот же бенчмарк на 13.7 пункта, меняя только harness.
• Затем они настроили harness вокруг открытой модели, которая в десять раз дешевле, пока она не набрала 0.86 против 0.87 у Opus 4.8.

Вы больше не покупаете просто модель. Вы покупаете модель вместе с harness.

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

Как это собирать

Собирайте снаружи внутрь:

1. Изоляция (Containment). То, до чего агент физически не может добраться. Контейнер, отдельная ветка, read-only-пользователь БД, отсутствие сети кроме allowlist. Делайте это до первого промпта.
2. Гайды (Guides). То, что направляет его до действия. Файл в репозитории вроде AGENTS.md, описания инструментов, достаточно понятные, чтобы модель выбирала правильный, пара примеров хорошего результата.
3. Сенсоры (Sensors). То, что проверяет его после действия. Линтер, проверка типов, набор тестов: быстрые и детерминированные, поэтому прогоняйте их на всём. Медленные проверки, например вторая модель, ревьюящая дифф, — только на том, что важно.
4. Права доступа (Permissions). Когда агенты запрашивают подтверждение, люди одобряют в 93 процентах случаев. Промпт с запросом доступа почти ничего не защищает. Настоящая защита — действия, которые просто недоступны. Оставьте подтверждения для немногих вещей, которые действительно необратимы.

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

1# AGENTS.md
2- Монорепо: /api (FastAPI), /web (Next.js), /jobs (cron)
3- Тесты запускаются через `make test`. Они должны проходить перед любым коммитом
4- Никогда не редактируй /migrations вручную, используй `make migration`
5- Доступ к БД только на чтение. Спрашивай перед любыми изменениями схемы

Хуки — это принудительная версия той же идеи. В Claude Code хук — это небольшой скрипт, который запускается перед вызовом инструмента и может его заблокировать. «Никогда не пушить в main» работает как хук, а не как строчка в промпте.

Одно предупреждение. Каждая деталь вашего harness — это ставка на то, что модель чего-то не умеет, а такие ставки имеют срок годности. Anthropic удалили целый компонент обвязки после того, как обновление модели сделало его ненужным.

Перечитывайте свой harness каждые несколько месяцев и удаляйте то, из чего модель выросла.

pic5. Четыре кольца harness

Шорткат

Если агент = модель + harness, то большая часть того, что вы получаете с Viktor, — это harness. Под капотом стоит Claude. А всё вокруг модели идёт готовым:

• Инструменты. Более 3 200 интеграций: GitHub, Linear, HubSpot, Stripe, Notion, Google Drive и другие. Для инструмента без готового коннекта он может собрать его сам.
• Гайды. Skills. Вместо того чтобы писать AGENTS.md самостоятельно, вы записываете экран, он черновит процедуру, а вы её правите.
• Сенсоры. Он подсвечивает данные, которые не сходятся, и задаёт вопросы, если в брифе чего-то не хватает. И каждый шаг попадает в тред в Slack, который может прочитать команда.
• Права доступа. Письма клиентов и финансовые изменения встают на паузу для подтверждения. Новые автоматизации по расписанию остаются на паузе, пока кто-то их не включит.

То, что ни один продукт не соберёт за вас, — изоляция, потому что она состоит из учётных данных, которые вы передаёте. Помните про 93 процента и подключайте его с минимальным доступом, необходимым для работы:

• read-only-пользователь БД
• ограниченный ключ Stripe
• общий инбокс поддержки, а не ваш личный
• токен GitHub, ограниченный конкретными репозиториями

До чего он не может дотянуться, то он не сломает.

pic6. Harness в Viktor

5. Evals engineering

Определение

Как понять, что новый сотрудник стал лучше? Вы даёте ему тот же тест, что и в прошлом месяце, и сравниваете.

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

Как это работает

Есть два типа проверок:

• End-to-end. Правильным ли получился финальный ответ? Это говорит, что балл сдвинулся, но не почему.
• Поведенческие (Behavioral). Произошло ли одно конкретное действие? Вызвал ли он поиск перед ответом. Задал ли уточняющий вопрос, если запрос был размытым. Проверил ли результат, прежде чем сказать «готово».

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

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

Как это собирать

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

Один кейс может быть вот таким маленьким:

1input: "Refund order #1042, customer says it arrived broken"
2expect:
3  - looks up the order before replying
4  - asks for approval before issuing the refund
5check:
6  - trace has get_order before send_reply
7  - trace has approval_request before refund

Не следите за общим процентом прохождения. Он может расти, пока какое-то конкретное поведение тихо ломается. Следите за отдельными проверками.

pic7. Откуда берутся хорошие eval-кейсы

Шорткат

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

• Через две недели возьмите 20 его тредов, где вы точно знаете правильный ответ. Включите каждый, где вам пришлось его поправлять.
• Напишите по одной простой проверке на кейс. Привёл ли он источник для каждой цифры, спросил ли, когда бриф был размытым, остановился ли перед тем, как что-то покинуло компанию.
• Перепрогоняйте набор после каждого изменения: нового навыка, отредактированного брифа, другого уровня. Переход с Smart на Balanced экономит около половины кредитов, так что протестируйте это, прежде чем переключаться навсегда.
• Раз в неделю оценивайте пять случайных тредов вручную.

Собираем всё вместе

Пять слоёв, пять вопросов. Context — что он видит. Loop — кто решает. Jev берёт на себя дешёвые решения. Harness — до чего он может дотянуться и кто его проверяет. Evals — откуда вы знаете, что всё работает.

С Viktor три из них идут практически встроенными: context, loop и harness. Jev, evals и учётные данные, которые вы передаёте, остаются вашей инженерией.

Если вы начинаете сегодня, вот самое дешёвое полезное действие по каждому пункту:

• Context: перенесите стабильные инструкции в системный промпт и перестаньте их менять.
• Loop: поставьте лимит на ходы и лимит в долларах до того, как оставите его работать.
• Jev: разметьте 200 примеров того, что ваш агент решает чаще всего.
• Harness: запускайте агента от пользователя, который ничего не может удалить.
• Evals: запишите свои последние пять фейлов как тест-кейсы.

С Viktor тот же первый день выглядит так:

• Context: напишите бриф о компании и запишите свой первый навык.
• Loop: в каждой задаче прописывайте, что значит «готово», и осознанно выбирайте уровень.
• Jev: фильтруйте любой поток до того, как он превратится в задачи для него.
• Harness: подключайте его с read-only-доступом и ограниченными учётными данными.
• Evals: сохраните 20 реальных тредов как свой первый тестовый набор.

Это один день работы, и он закрывает все пять слоёв.

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

Спасибо Viktor за спонсирование этой статьи.

Попробуйте бесплатно: @viktor_com. $100 в кредитах, без карты. Полная ссылка в моём первом ответе.

При регистрации используйте код YARCHI100.

Платное партнёрство