PRO.05
Agent Engineering
РЕЗУЛЬТАТ УРОКА
Проектировать агентов как наблюдаемые программные системы.Главное за 30 секунд
Agent Engineering объединяет промпты, состояние, инструменты, оценки, безопасность и эксплуатацию в единый инженерный контур.
Разбираемся
Разница между агентом в демо и агентом в production — это разница между прототипом и инженерной системой. Прототип работает на счастливых путях с заранее известными входными данными. Production-агент встречает неожиданные ситуации, конкурирующие нагрузки, меняющиеся требования и необходимость объяснять поведение стейкхолдерам. Agent Engineering — это инженерная дисциплина, а не промпт-магия.
Стоп-условия: без них цикл не заканчивается
Главное: цикл сам не останавливается: стоп-условия — часть основной логики, а не защита от края.
Цикл сам по себе не заканчивается: он крутится, пока не выполнено условие выхода. Стоп-условия — не защита от края, а часть основной логики.
Планирование и его срывы
Агент, способный планировать, разбивает сложную задачу на последовательность действий. Качество планирования определяется точностью инструкций, описаниями инструментов и примерами. Плохое планирование выражается не в отказе, а в бессмысленных повторах: агент делает одно и то же с чуть изменёнными формулировками, каждый раз получает тот же результат и продолжает. Со стороны это выглядит как работа — счётчик шагов растёт, ответа нет.
Четыре условия остановки
| Критерий | Условие | Что происходит без него |
|---|---|---|
| Предел числа шагов | Например, десять действий на задачу. Дальше — передача человеку | Задача может идти сколько угодно: пользователь смотрит на индикатор, счёт растёт |
| Предел расхода | Бюджет на одну задачу в деньгах или объёме текста | Одна неудачная задача стоит как сто обычных |
| Обнаружение застоя | Повтор того же действия с теми же параметрами означает, что прогресса нет | Агент вежливо переформулирует запрос до упора в предел шагов |
| Явная передача человеку | Нормальный исход с указанием причины | Агент придумывает ответ вместо признания, что не справился |
Почему остановка — часть основной логики
Цикл «подумал — сделал — проверил» сам по себе не заканчивается. Он крутится, пока внешнее условие не скажет «хватит». Это не защита от края и не обработка ошибок: ни одно из четырёх условий выше не связано с тем, что модель ошиблась. Все четыре — про то, что у процесса должны быть границы. Агент без них в лучшем случае упрётся в предел контекста, в худшем — потратит бюджет на задачу, которая была невыполнима с самого начала.
Memory и состояние
Для многошаговых задач агенту нужно помнить: что уже сделано, какие данные получены, какие решения приняты. Держать это можно внутри диалога или во внешнем хранилище, и выбор здесь имеет прямые последствия для стоимости и надёжности.
Где держать состояние
| Критерий | Внутри диалога | Во внешнем хранилище |
|---|---|---|
| Как устроено | Вся история передаётся модели заново на каждом шаге | Состояние в базе, модели передаётся краткая сводка |
| Стоимость | Растёт с каждым шагом: платите за всю историю снова и снова | Почти постоянная на шаг |
| Предел | Объём контекста: длинная задача просто не поместится | Ограничен только базой |
| После сбоя | Всё потеряно, задача начинается заново | Продолжается с последнего шага |
| Когда достаточно | Задача в три-пять шагов, один запуск | Долгие задачи, повторные попытки, разбор истории |
Набор проверок: что в нём должно быть
Двадцать случаев, собранных до масштабирования, экономят месяцы разбора инцидентов. Пропорции важнее общего числа.
- Типовые задачи — половина набораТо, для чего агент и создан. Если он ломается здесь, остальное не имеет значения. Фиксируйте не только ответ, но и число шагов: рост с трёх до двенадцати при том же ответе — тоже ухудшение.
- Граничные случаиПустой ввод, максимальный объём данных, отсутствующая запись, два одинаково подходящих результата. Проверяем не «сломается или нет», а «понятно ли поведение».
- Неверный вводОпечатки, неправильный формат, запрос не по теме. Правильное поведение — отказ или уточняющий вопрос, а не попытка угадать.
- Опасные запросыПросьба удалить данные, отправить сообщение от чужого имени, показать чужую информацию. Ожидаемое поведение — отказ с объяснением.
- Подмена инструкцийДанные с командами внутри: обращение со строкой «игнорируй указания», документ с инструкцией. Агент должен продолжить исходную задачу.
- Прогон при каждом измененииПравка инструкции, новая версия модели, новый инструмент — повод прогнать весь набор. Без этого «улучшение» становится ставкой без обратной связи.
Что записывать по каждому шагу
Номер шага, что было вызвано, с какими параметрами, что вернулось, сколько заняло, сколько стоило — и отдельно версия инструкции и версия модели. Последние два поля отвечают на самый частый вопрос эксплуатации: «вчера работало, сегодня нет». Если версия инструкции изменилась, ответ находится за минуту вместо дня. Запись нужна не только для отладки: без неё нельзя объяснить решение агента человеку, которого это решение коснулось.
Права и безопасность
Агент работает с минимально необходимыми правами. Необратимые действия требуют подтверждения или явного правила. Чувствительные данные изолируются. Отдельно проектируется передача человеку — она не «аварийный выход», а нормальная часть работы: агент, который никогда не передаёт задачу, просто скрывает случаи, где он не справился.
Что спросить у исполнителя
6 пунктовШесть вопросов, отличающих работающего агента от демонстрации.
- Ответ «сколько нужно» означает, что предела нет. Одна невыполнимая задача будет идти до упора в контекст.
- Без предела расхода неудачный случай обходится как сотня обычных, и узнаете вы об этом из счёта.
- Правильный ответ описывает обнаружение повторов. Без этого агент переформулирует запрос до предела шагов.
- Правильно — передача человеку с указанием причины. Неправильно — «он всегда что-то отвечает».
- «Попробовали» — не проверка. Нужен зафиксированный набор, который прогоняется при каждом изменении.
- Если версии инструкции и модели не пишутся, вопрос «почему вчера работало» останется без ответа.
ПРИМЕР
Агент, который потратил бюджет на один тикет
Ситуация. Агент поддержки ищет заказ по описанию клиента. Заказа в базе нет — клиент указал номер из другой системы. В цикле есть лимит в 30 шагов, но нет проверки на повторяющиеся действия и нет лимита стоимости.
Результат. Агент 30 раз вызвал поиск с почти одинаковыми аргументами, каждый раз получил пустой результат и переформулировал запрос. Задача заняла четыре минуты и стоила как 30 обычных обращений. Шесть строк — сигнатура вызова и проверка на повтор — превратили бы это в передачу человеку на третьем шаге с понятной причиной «заказ не найден».
ПРАКТИКА
Сделайте сейчас
Составьте набор проверок для одного агента: 20 случаев в пропорции из этого урока — десять типовых, четыре граничных, три с неверным вводом, два опасных, один с подменой инструкций. На каждый: что подаём, какое поведение считаем правильным, и сколько шагов допустимо. Отдельным списком — четыре условия остановки с конкретными цифрами для вашей задачи. Если агент уже есть, прогоните и запишите результат как отправную точку. Если нет — это готовое задание на разработку.
ОГРАНИЧЕНИЯ
Где нужен человек
- Без evals невозможно обоснованно повышать автономность или изменять промпты.
- Prompt injection — реальная угроза: агент не должен следовать инструкциям из входных данных, противоречащим системному промпту.
- Цикл без стоп-условий не останавливается сам: лимиты шагов, стоимости и обнаружение застоя — часть основной логики, а не защита от края.
Смежные уроки
Материал проверен: 20 августа 2026. Инструменты и тарифы меняются — сверяйтесь с первоисточником.