Agentic workflow — это повторяемый многошаговый процесс с ИИ, в котором LLM или агент не ограничивается одним ответом, а выбирает следующий шаг, вызывает инструменты, может остановиться на проверку человеком и работает в заданных ограничениях. По состоянию на 2026-08-18 это не формально стандартизированный термин, но официальные документы Anthropic, OpenAI и LangChain сходятся в одной практической идее: речь о контролируемой оркестрации действий, а не просто об одном промпте.
Если нужен короткий критерий: когда система получает триггер, проходит через несколько шагов, использует внешние системы и сама определяет хотя бы часть маршрута внутри ограничений, это уже похоже на agentic workflow.
Английский термин: agentic workflow. Варианты перевода: в источниках из пакета нет единого официального русского эквивалента, поэтому в статье используется английское название.
Редакционное ограничение: ниже дано рабочее инженерное определение. В официальных источниках по состоянию на 2026-08-18 нет единого стандарта, который бы жёстко разделял workflow, agent и agentic workflow одинаково у всех вендоров.
Простыми словами
Можно представить agentic workflow как не одного «умного собеседника», а диспетчера с набором разрешённых действий. Вы даёте ему задачу, а он решает, что делать дальше: сразу ответить, сходить в поиск, вызвать внешний сервис, запросить недостающие данные или отправить результат человеку на согласование.
Это важное отличие от обычного запроса к модели. В обычном режиме вы отправили промпт и получили ответ. В agentic workflow между запросом и ответом появляется маршрут: несколько шагов, инструменты, проверки и остановки.
Как это работает
В актуальных материалах OpenAI для workspace-агентов повторяется простая рамка из трёх частей: trigger, process/skills и tools/systems. В практиках Anthropic дополнительно важно различать, где путь заранее задан кодом, а где модель сама выбирает следующий шаг. В итоге agentic workflow обычно выглядит так:
- Срабатывает триггер. Это может быть входящий запрос, событие в системе или запуск по расписанию.
- Подтягивается контекст и состояние. Система получает историю, правила, доступные инструменты и ограничения на действия.
- Модель определяет следующий шаг. Она решает, можно ли ответить сразу, нужен ли поиск, вызов API, расчёт или передача на человека.
- Вызывается инструмент. OpenAI в текущих рекомендациях отдельно указывает на сценарии reasoning, tool calling и multi-turn workflows, где модель программно вызывает инструменты в ограниченном контуре.
- Срабатывают guardrails. Для чувствительных действий полезны ограничение пространства действий, требование одобрения и возможность прервать выполнение. Именно такие меры отдельно подчёркиваются в документе OpenAI по governance agentic AI systems.
- Система либо завершает задачу, либо делает ещё один шаг. Если данных не хватило, возможен новый цикл: ещё один вызов инструмента, уточнение маршрута или эскалация человеку.
[Триггер] ↓ [Контекст, правила, доступные инструменты] ↓ [LLM/агент выбирает следующий шаг] ↙ ↓ ↘ [поиск] [API/сервис] [запрос человеку] ↘ ↓ ↙ [проверка ограничений и approval] ↓ [следующий шаг или завершение] ↓ [результат и журнал выполнения]
Практически это означает следующее: чем больше вы хотите предсказуемости, тем больше маршрута фиксируете заранее. Anthropic прямо пишет, что workflow с предопределёнными путями обычно предпочтительнее для предсказуемости и консистентности, а более автономные агенты — для гибкости и решений, которые сильнее зависят от самой модели.
Для тестирования OpenAI рекомендует прогонять такие системы на реалистичных примерах в preview и повторно тестировать их после правок. Для agentic workflow это особенно важно, потому что даже небольшое изменение подсказки, инструмента или правила может поменять весь маршрут выполнения.
Где применяется
- Повторяемая структурированная работа. Когда у процесса есть понятный триггер, набор систем и ожидаемый результат, agentic workflow позволяет автоматизировать не только ответ, но и последовательность действий. Это хорошо соответствует описанию workspace-агентов OpenAI: триггер, процесс, инструменты.
- Agentic RAG. LangChain определяет agentic RAG как вариант retrieval, где LLM-агент сам решает, когда и как запрашивать информацию во время рассуждения. Это отличается от 2-step RAG, где retrieval всегда выполняется до генерации.
- Долгие stateful-процессы. Если задача длится дольше одного ответа и требует состояния, памяти, пауз и human-in-the-loop, нужен уже не просто чат, а оркестрация. Именно так позиционируется LangGraph: низкоуровневая оркестрация для долгоживущих stateful-агентов с durable execution, human-in-the-loop, memory и debugging.
- Управляемые асинхронные сессии. Если вы не хотите собирать всю инфраструктуру сами, можно смотреть в сторону managed-подходов. Например, Claude Managed Agents описывается как готовый конфигурируемый harness для долгой асинхронной работы, но в текущем состоянии это beta-функция с отдельными ограничениями по использованию и комплаенсу.
Если вам ближе low-code или продуктовая сборка, полезно посмотреть, как схожие паттерны упаковываются в workflow с Zapier AI Actions, а для приложений с RAG и агентными сценариями — в платформах вроде Dify и LlamaIndex.
Практический пример
Ниже — не документация конкретного вендора, а упрощённый сценарий, который показывает механику на реальном классе задач: внутренний помощник отвечает на вопрос сотрудника по базе знаний компании.
- Триггер: сотрудник задаёт вопрос в чате.
- Решение о маршруте: модель сначала определяет, можно ли ответить без внешних данных. Если нет — включает retrieval.
- Вызов инструмента: система ищет нужные документы в базе знаний.
- Повторный выбор шага: если найденных материалов недостаточно или они противоречат друг другу, модель может сделать ещё один поиск или отправить черновик на человека.
- Approval: если ответ затрагивает чувствительное правило, человек подтверждает финальную версию.
- Завершение: сотрудник получает ответ, а система сохраняет журнал выполнения.
Вопрос → классификация → нужен ли retrieval?
├─ нет → ответ
└─ да → поиск → достаточно ли данных?
├─ да → черновик ответа → нужен ли approval?
│ ├─ нет → финальный ответ
│ └─ да → человек подтверждает → финальный ответ
└─ нет → повторный поиск или эскалация
Почему это именно agentic workflow, а не просто RAG? Потому что retrieval здесь не обязателен на каждом запросе и не стоит жёстко первым шагом. Модель решает, когда к нему обращаться и когда остановиться на проверку человеком. Именно так LangChain проводит грань между agentic RAG и 2-step RAG.
Чем отличается от похожих терминов
| Термин | Кто определяет следующий шаг | Когда полезен | Главный компромисс |
|---|---|---|---|
| Обычный workflow | Код и заранее заданные ветки | Когда нужна максимальная предсказуемость и повторяемость | Меньше гибкости, хуже справляется с неоднозначными случаями |
| Agentic workflow | Часть маршрута фиксирована, часть выбирает модель внутри ограничений | Когда нужны инструменты, несколько шагов и управляемая гибкость | Сложнее тестировать и контролировать, чем фиксированный workflow |
| ИИ-агент | Модель более автономно направляет собственный процесс и использование инструментов | Когда задача плохо раскладывается на жёсткий сценарий и нужна адаптивность | Меньше предсказуемости; требуются сильные guardrails и наблюдаемость |
| Agentic RAG | Модель решает, когда и как делать retrieval во время рассуждения | Когда поиск знаний — лишь один из шагов внутри более широкого процесса | Сложнее, чем 2-step RAG, и не всегда нужен |
Если упростить: обычный workflow — это жёсткий маршрут, агент — более автономный исполнитель, а agentic workflow — промежуточный инженерный паттерн, где автономия есть, но она ограничена рамками процесса.
Ограничения и заблуждения
- Заблуждение: это любой чат-бот. OpenAI прямо отмечает, что простые чат-боты и одношаговые LLM-приложения не считаются агентами. По той же логике одиночный запрос без многошаговой оркестрации не стоит называть agentic workflow.
- Заблуждение: больше автономии всегда лучше. Anthropic рекомендует workflows там, где важны предсказуемость и консистентность, а агенты — там, где нужна гибкость. То есть «агентности» стоит добавлять ровно столько, сколько оправдано задачей.
- Ограничение: термин не стандартизирован. У разных платформ граница между workflow, agent и agentic RAG проходит по-разному. Поэтому при проектировании полезно описывать не только название паттерна, но и конкретные свойства: есть ли триггер, состояние, инструменты, approvals и журнал выполнения.
- Ограничение: безопасность должна быть встроена в маршрут. Для систем, которые что-то делают от вашего имени, одного хорошего промпта мало. В документе OpenAI по governance отдельно подчеркнуты ограничение пространства действий, approval и interruptibility.
- Ограничение: стек быстро меняется. Если вы внедряете конкретный SDK или managed-сервис, фиксируйте версии и перепроверяйте релизные заметки. По страницам из пакета, у OpenAI Agents Python latest release указан как v0.21.1 на 2026-08-16, а у LangGraph на странице репозитория показан релиз 1.2.9 от 2026-07-10.
- Ограничение: managed-платформы имеют особые условия. Например, Claude Managed Agents в текущей документации помечены как beta, требуют заголовок
managed-agents-2026-04-01, включены по умолчанию для API-аккаунтов и не подходят для Zero Data Retention или HIPAA BAA coverage.
Связанные материалы
- AI Agent (ИИ-агент) — если вам нужно понять более автономную сторону этого спектра.
- LlamaIndex — фреймворк для RAG, агентов и workflow — полезен, если у вас знания и поиск являются частью маршрута.
- Dify: платформа для LLM-приложений, RAG и агентных workflow — если вы собираете прикладной контур поверх моделей.
- Как создать workflow с Zapier AI Actions — пример более прикладной триггерной автоматизации.
- Как перенести workflow из LangChain в LangGraph — когда обычных цепочек уже не хватает и нужен явный граф состояния.
Практический вердикт
Если вы проектируете систему с ИИ, разумный старт — не «максимально автономный агент», а повторяемый workflow с точками выбора там, где они действительно нужны: поиск, маршрутизация, эскалация, выбор инструмента. Это обычно даёт лучший баланс между гибкостью и контролем. И ещё раз: agentic workflow полезнее рассматривать как рабочую инженерную метку, а не как строго стандартизированную категорию.
Источники
- Building effective agents | Anthropic
- A practical guide to building agents | OpenAI
- Workspace agents | OpenAI
- Model guidance | OpenAI API
- Practices for Governing Agentic AI Systems
- Retrieval – Docs by LangChain
- GitHub – langchain-ai/langgraph: Build resilient agents. · GitHub
- Releases · openai/openai-agents-python · GitHub
- Claude Managed Agents overview – Claude Platform Docs
Вопросы и ответы
Agentic workflow и ИИ-агент — это одно и то же?
Не совсем. По Anthropic workflow — это скорее заранее оркестрованный процесс, а агент — более автономная система, которая сама направляет собственный процесс и использование инструментов. Agentic workflow обычно находится между этими крайностями.
Нужен ли agentic workflow для любого RAG?
Нет. LangChain отдельно противопоставляет agentic RAG и 2-step RAG. Если retrieval всегда делается до генерации и маршрут не меняется, вам может хватить более простого 2-step RAG.
Где лучше ставить проверку человеком?
Там, где система выполняет значимое действие или может ошибиться с последствиями: отправка во внешнюю систему, изменение записи, публикация чувствительного ответа. Это согласуется с практиками ограниченного пространства действий, approval и interruptibility.
С чего начинать внедрение на практике?
С узкого повторяемого процесса: одного триггера, небольшого набора инструментов и понятного критерия завершения. Затем прогоните реалистичные примеры в preview и повторяйте тесты после каждого изменения маршрута, как рекомендует OpenAI для workspace-агентов.