Агентам нужен control flow, а не больше промптов
Почему надёжные AI-агенты требуют детерминированного control flow в коде, а не бесконечного усложнения промптов — разбор архитектуры и практики.
Агентам нужен control flow, а не больше промптов
Если вы когда-нибудь добавляли в промпт слова ОБЯЗАТЕЛЬНО или НИ В КОЕМ СЛУЧАЕ НЕ ПРОПУСКАЙ — вы достигли потолка промптинга. Это не вина вашей формулировки. Это фундаментальное ограничение архитектуры, в которой логика управления потоком выполнения доверена самой языковой модели.
Надёжные агенты, решающие сложные задачи, нуждаются в детерминированном control flow, закодированном в программном обеспечении, а не во всё более запутанных цепочках промптов. Эта идея — не просто мнение разработчика-блогера, она подтверждается реальной практикой построения агентных систем в 2025–2026 годах. Разберёмся, почему.
Промпт — это не программа
Промпт — это команда, которую человек даёт инструменту, обеспечивая рассуждение. AI-агент — это автономная система, которая самостоятельно планирует, выполняет и итерирует для достижения цели.
Ключевое слово здесь — самостоятельно. Когда мы пишем промпт, мы описываем желаемый результат на естественном языке. Но естественный язык по своей природе неоднозначен, и LLM не «исполняет» инструкции как процессор — она генерирует наиболее вероятный следующий токен в контексте.
Способность LLM как бы «размывать» жёсткие запреты — так что «НИКОГДА НЕ ДЕЛАЙ X» может в итоге восприниматься как «ПОЖАЛУЙСТА, СДЕЛАЙ X» — похоже, является фундаментальным свойством того, как они работают.
Из этого следует жёсткий практический вывод: нельзя программировать надёжное поведение агента только через текст в промпте. Чем сложнее задача — тем больше мест, где модель может «свернуть не туда».
Что происходит, когда агент контролирует себя сам
Центральная проблема агентных AI-воркфлоу состоит в следующем: когда агент контролирует собственный поток выполнения, вы получаете системы, которые сложно отлаживать, трудно доверять и почти невозможно масштабировать. Агент не делает ничего «неправильного» — он делает именно то, что делают языковые модели: генерирует правдоподобные следующие шаги на основе контекста. Но «правдоподобный» — это не то же самое, что «корректный», и без внешних ограничений ошибки накапливаются.
Представьте агента, который обрабатывает заявки клиентов в 15 шагов. На шаге 7 модель решила интерпретировать задачу чуть иначе, чем задумывалось. На шаге 10 это отклонение усилилось. На шаге 15 — катастрофа. И вы не знаете, где именно всё пошло не так.
Когда что-то идёт не так в 15-шаговом агентском воркфлоу, найти первопричину крайне сложно.
К этому добавляется проблема наблюдаемости. В отличие от традиционного программного обеспечения, у агентов control flow управляется самим LLM, что делает observability не просто полезной, но совершенно необходимой.
Control flow в коде vs. контроль через промпты
Посмотрим на разницу концептуально:
| Параметр | Промпт-контроль | Control flow в коде |
|---|---|---|
| Предсказуемость | Низкая (зависит от контекста) | Высокая (детерминированные пути) |
| Отладка | Трудная (логика размыта в тексте) | Простая (каждый этап виден) |
| Стоимость ошибки | Накапливается незаметно | Перехватывается на gate-проверках |
| Масштабируемость | Плохая (промпт раздувается) | Хорошая (модульная архитектура) |
| Версионирование | Произвольное | Как обычный код |
Воркфлоу обеспечивают контроль и предсказуемость для хорошо определённых задач, тогда как агенты предлагают гибкость и автономию для сложных, открытых проблем.
Ключ — в правильном разграничении: что решает модель, а как организован поток исполнения — решает разработчик.
Архитектура: воркфлоу, который контролирует агента
Правильная архитектура выглядит не как «умный промпт», а как программная система с явными точками контроля.
graph TD
A[Входящий запрос] --> B[Классификатор / Router]
B --> C{Тип задачи}
C -->|Простая| D[Одиночный LLM-вызов]
C -->|Составная| E[Оркестратор воркфлоу]
E --> F[Шаг 1: LLM]
F --> G{Validation Gate}
G -->|Ок| H[Шаг 2: LLM]
G -->|Ошибка| I[Retry / Fallback]
I --> F
H --> J{Validation Gate}
J -->|Ок| K[Шаг 3: Действие]
J -->|Ошибка| L[Эскалация человеку]
K --> M[Результат]
Что здесь принципиально важно:
1. Validation Gates (точки валидации)
Каждая точка валидации требует определённого пути при сбое. Варианты: Retry — попросить агента попробовать снова, опционально с дополнительным контекстом о том, что пошло не так; Fallback — использовать более простую или ограниченную альтернативу; Escalate — передать на человеческую проверку или в более мощный процесс.
2. Управление состоянием вне агента
Необходимо структурировать AI-воркфлоу так, чтобы слой оркестрации оставался главным: управлял маршрутизацией, восстановлением после ошибок и состоянием системы.
3. Ограничение доступных инструментов
Разрешение модели свободно выбирать из десятков или сотен инструментов увеличивает вероятность некорректных или неэффективных действий. Динамическое добавление или удаление инструментов в процессе выполнения усугубляет проблему, меняя смысл предыдущих шагов. Ограничение доступных действий в конкретный момент — без перезаписи предыдущего состояния — производит более стабильное поведение.
4. Промпты как код
Промпты — это код. Они должны быть под контролем версий, тестироваться и деплоиться намеренно. Когда вы меняете промпт, вы должны понимать, что именно может сломаться downstream — в частности, может ли изменение формата вывода или семантики повлиять на ваши validation gates.
Почему масштабирование промптов не работает
Когда агент ведёт себя непредсказуемо, первый инстинкт разработчика — добавить больше инструкций в системный промпт. Это создаёт порочный круг.
Исследование Datadog показало, что 69% всех входящих токенов в трассах клиентов приходится на системные промпты: внутренние инструкции, определения политик и руководство по инструментам. Это говорит о том, что большинство усилий по context engineering тратится на оптимизацию повторяющихся системных промптов в сильно скаффолдированных агентных системах. Командам стоит сокращать системные промпты там, где это возможно, чтобы снизить использование токенов, и модуляризировать переиспользуемые компоненты для кэширования.
«Следующая волна сбоев агентов будет связана не с тем, что агенты не могут сделать, а с тем, что команды не могут наблюдать.» — Datadog State of AI Engineering, 2026
Помимо роста стоимости, раздутые промпты ухудшают контроль. По мере того как системы переходят от изолированных взаимодействий к длительному выполнению, ограничивающим фактором становится не качество генерации, а то, как обрабатывается состояние выполнения со временем. Промпт-инжиниринг улучшал взаимодействие, когда взаимодействие было единицей работы. Но сейчас единицей работы стал многошаговый агентный воркфлоу.
Когда промпт — правильный инструмент, а когда нет
Важно не впасть в другую крайность: полностью отказаться от промптов в пользу жёсткой детерминированности. Выбор инструмента зависит от задачи.
В сравнении AI Workflow и AI Agent: воркфлоу обеспечивает предсказуемость (фиксированные пути) и простоту отладки (каждый этап виден), тогда как агент адаптируется к новым ситуациям, но с переменной стоимостью и более сложной отладкой.
Практический алгоритм выбора:
1. Можно ли решить задачу одним хорошо написанным промптом? → Используй промпт.
2. Задача многошаговая, но последовательность шагов фиксирована? → Используй воркфлоу с промптами на каждом шаге.
3. Задача требует адаптивных решений в непредсказуемых условиях? → Используй агента внутри управляемого воркфлоу.
Воркфлоу — лучший выбор примерно для 80% корпоративных приложений.
Агентные задачи могут стоить в 10–100 раз дороже простых промптов. Это ещё один аргумент не переусложнять систему без необходимости.
Безопасность и governance: ещё один аргумент за явный контроль
По мере того как AI-агенты становятся всё более автономными и способными, обеспечение их безопасности от уязвимостей — таких как prompt injection — становится критически важным.
Когда контроль потока вынесен в код, security-политики можно применять детерминированно, а не надеяться, что модель «прочитает и запомнит» запреты в промпте.
Фундаментальные элементы управления включают: таблицы разрешений агентов для определения и ограничения системного доступа; управление жизненным циклом агентов для отслеживания создания, деплоя и вывода из эксплуатации; чётко определённые guardrails, чтобы агенты работали в заданных границах.
Проще жёстко ограничить привилегии AI-агентов, создав отдельную копию агента для каждой задачи и поместив каждый экземпляр в изолированную виртуальную песочницу, которая предоставляет доступ именно к той информации и тем ресурсам, которые нужны агенту.
Заключение
Промпт-инжиниринг — мощный инструмент, но не серебряная пуля для построения надёжных AI-агентов. Когда агент управляет собственным потоком выполнения на основе языковых инструкций, вы получаете систему, которую сложно отлаживать, предсказывать и масштабировать.
Главный вывод прост:
Промпт описывает задачу для одного шага. Control flow в коде определяет, как шаги связаны между собой, что происходит при ошибке и кто принимает решение о следующем действии.
ЛLM — блестящий интерпретатор, но плохой архитектор собственного поведения. Дайте ей чёткую задачу в рамках явно заданного контекста и ограничений. Всё остальное — ответственность вашего кода.
Это не значит писать меньше промптов. Это значит писать меньше, но лучше — и окружать их надёжной программной инфраструктурой.