Нужен агент или workflow с одним шагом на LLM?
Если все шаги можно записать до запуска процесса, вам нужен workflow. Правила пишутся в коде, а вызов LLM добавляется только там, где иначе человеку пришлось бы что-то прочитать и истолковать: скан счёта, письмо с жалобой, пункт договора. Агент оправдан, когда следующий шаг зависит от находки предыдущего и заранее перечислить возможные пути нельзя. Эту границу провела инженерная команда Anthropic в декабре 2024 года. Workflow оркестрируют LLM и инструменты «через заранее заданные пути в коде». Агенты «сами управляют своим процессом и использованием инструментов». В том же тексте советуют брать самое простое рабочее решение, что «может означать отказ от агентных систем вообще».
На наш взгляд, большинство процессов, которые приходят с ярлыком «агент», относятся к первым двум вариантам.
Тест на этапе оценки у нас простой. Мы просим руководителя операций нарисовать процесс квадратиками и стрелками, включая исключения, которые он разруливает руками в тяжёлый понедельник. Если схема замкнулась (каждая стрелка приходит в известный квадрат), мы строим эту схему как код, а модель ставим в один-два квадрата. Если на схеме растёт квадрат «смотря по обстоятельствам», из которого каждый раз идут к разным инструментам, он кандидат на агента. Всё остальное вокруг него остаётся детерминированным. Агента, который ведёт весь бизнес-процесс от начала до конца, мы рекомендовали бы только для очень необычного процесса.
17% внедрили, больше 40% ждёт отмена
Цифры 2026 года описывают рынок, который купил слово «агент» быстрее, чем научился с ними работать. По опросу Gartner среди CIO и технических руководителей 2026 года, ИИ-агентов внедрили только 17% организаций, а более 60% рассчитывали сделать это в течение двух лет. В Hype Cycle for Agentic AI (опубликован 2 апреля 2026 года) Gartner помещает агентный ИИ на пик завышенных ожиданий и отмечает, что большинство внедрений узкие по охвату.
Прогноз об отменах старше, чем кажется по большинству публикаций. Gartner выпустил его 25 июня 2025 года: более 40% проектов с агентным ИИ будут закрыты к концу 2027 года из-за растущих затрат, неясной бизнес-ценности или недостаточного контроля рисков. В том же релизе назван «agent washing» (переименование ИИ-ассистентов, RPA и чат-ботов в агентов) и оценено, что настоящих среди тысяч вендоров агентного ИИ лишь около 130. С тех пор Gartner добавил два более жёстких прогноза. 26 мая 2026 года он предсказал, что к 2027 году 40% предприятий понизят или выведут из эксплуатации автономных агентов, когда пробелы в управлении вскроются в инцидентах на проде. 29 сентября 2026 года он предсказал, что к 2028 году 70% предприятий откажутся от агентного ИИ, построенного инженерами вендора на стороне заказчика (forward-deployed engineering): из-за растущих затрат и систем, которые клиент не может развивать сам.
Роберт Щерба (Robert Szczerba) в разборе для Forbes от 7 июля 2026 года описал картину как «проблему менеджмента в костюме технологии». Причины у него такие: управление, доступ к данным, ответственность и ROI.
Качества модели нет ни в одном из этих списков. Команда, которая выбрала агента для процесса, где он был не нужен, получает ровно три проблемы из перечня Gartner: стоимость запуска растёт с каждым шагом рассуждения, ценность трудно отделить от того, что дал бы движок правил, а контур контроля приходится выстраивать под самый высокий уровень автономности.
Какие ваши процессы — это workflow под маской?
Всё, где конечный набор исходов и правила, которые можно записать. Обычные подозреваемые:
- Согласование счетов: сверка с заказом и накладной, проверка допуска, маршрутизация по сумме и центру затрат. Трудно только прочитать сам счёт.
- Разбор обращений в поддержку, когда категории известны и стабильны.
- Онбординг сотрудников или клиентов, напоминания о продлении, ревизия доступов.
- ETL и синхронизация учётных данных между CRM, ERP и биллингом.
Два практических разбора августа 2026 года приходят почти к тому же списку. Imversion называет ложными кейсами для агентов маршрутизацию форм, сверку счетов, разбор обращений по известным категориям, ETL, онбординг и ревизию доступов, а правило такое: «если мы можем описать workflow до запуска, так и надо делать». Onplana умещает цену ошибки в одну строку: выбор «решает, будет ли купленная система ломаться громко или правдоподобно». Движок правил на неизвестном случае выбрасывает ошибку. Агент пишет уверенный, разумно выглядящий неверный ответ и идёт дальше.
Диагностика, которую мы применяем к уже работающему «агенту», это трейс. Возьмите несколько сотен запусков и посмотрите на последовательность вызовов инструментов. Если почти каждый запуск делает одни и те же шаги в одном и том же порядке, вы платите планировщику, который ничего не планирует, и эту последовательность пора превращать в код.
Вендоры автоматизации пошли в ту же сторону. UiPath 17 сентября 2026 года выпустила Maestro Flow в общий доступ как третий холст рядом с BPMN и Case на одном движке оркестрации и добавила оценки для Maestro BPMN, которые сочетают детерминированные проверки с LLM-судьями. Агенты там работают шагами внутри смоделированного процесса.
Где шаг на LLM оправдан
Шаг на LLM уместен там, где вход неструктурирован, а выход можно проверить. На практике это три задачи: извлечение полей из PDF и писем, классификация свободного текста по известному набору меток и черновик текста, который человек или шаблон доводит до конца. Наши проекты Invoice AI и Feedback AI построены именно так. Модель читает документ или сообщение, а сверку, проводку и маршрутизацию делает детерминированный код.
У каждого шага на LLM одни и те же три предохранителя:
- Схема. Модель возвращает JSON, проверенный по модели Pydantic или JSON Schema, а ошибка валидации означает повтор или задачу для человека. Наполовину разобранный ответ дальше по цепочке не идёт.
- Нижний порог уверенности с явной меткой
unknown. Ниже порога случай уходит в очередь к человеку вместе с догадкой модели, так что проверяющий начинает с черновика. - Строка в логе на каждый вызов: ID модели, версия промпта и проверенный результат. Аудитор может воспроизвести, почему случай пошёл именно туда.
Очередь для людей работает больше, чем кажется. Её объём показывает, достаточно ли хорош шаг, а решённые случаи становятся набором для оценки следующего изменения промпта или модели. Маршрутизацию моделей и кеширование для этих вызовов мы разбирали в материале о стоимости ИИ-агентов, так что здесь пропускаем.
Когда уместен ограниченный агент и что мы ему ограничиваем?
Ограниченный агент подходит для исключений, которые workflow перечислить не может: спор с поставщиком, где нужны договор, история заказов и письма за прошлый месяц; исследовательская задача, где следующий поиск зависит от предыдущего результата; сорвавшаяся сверка без очевидной причины. Anthropic описывает область применения как «открытые задачи, где трудно или невозможно предсказать нужное число шагов». Мы ставим агента за workflow, так что он видит только те случаи, от которых уже отказались правила и классификатор.
Дальше мы его ограничиваем. Максимум шагов за запуск (Anthropic тоже советует условия остановки, например предел числа итераций). Бюджет токенов на запуск, который контролируется снаружи модели. Белый список инструментов, по умолчанию только чтение, с учётными данными, выданными именно этому агенту. Шаг подтверждения перед любой записью, платежом или исходящим сообщением: это уровень «действует с подтверждения» из майской модели управления Gartner 2026 года (наблюдает, советует, действует с подтверждения, действует автономно). И каждый вызов инструмента попадает в журнал аудита, который агент изменить не может. Поэтому мы запускаем агентов под SealedRun.
Менее заметная цена — поверхность атаки. Каждое письмо, PDF и веб-страница, которые читает агент, это вход, способный попытаться повлиять на его следующий вызов инструмента, а каждый доступный ему инструмент становится мишенью. Классификатор без инструментов в худшем случае выберет не ту метку. Серверы инструментов нужно проверять отдельно, как мы описали в материале MCP-серверы в продакшене.
Четыре архитектуры рядом
Читайте таблицу сверху вниз как лестницу. Каждая строка добавляет гибкость, превращает громкий отказ в тихий, а фиксированную стоимость в переменную. Мы поднимаемся только настолько, насколько требует самый трудный случай процесса. Сравнение качественное: ни один актуальный публичный источник не даёт стоимости запуска, которую можно было бы переносить между процессами.
Сравнение архитектур
| Архитектура | Стоимость запуска | Типичный отказ | Аудируемость |
|---|---|---|---|
| Детерминированный workflow | Фиксированная и близкая к нулю, только вычисления | Громкий: неизвестный вход вызывает ошибку или остановку | Полная: каждое решение привязано к версионируемому правилу |
| Workflow + шаги на LLM | Один или несколько вызовов модели на случай, предсказуемо | Неверная метка или поле, ловится схемой и порогом уверенности | Высокая: путь фиксирован, ответы модели логируются и воспроизводятся |
| Ограниченный агент | Переменная, ограничена лимитами шагов и токенов | Правдоподобное неверное действие, останавливается на шаге подтверждения | Средняя: для восстановления нужны полные трейсы вызовов инструментов |
| Открытый агент | Переменная и неограниченная | Правдоподобное неверное действие, которое выполняется | Низкая: рассуждения меняются от запуска к запуску, воспроизвести трудно |
Что мы сделали бы в следующий раз
Начать с маршрутизатора. Сначала правила, вторым один проверяемый вызов классификатора и только потом агент для того, от чего отказались оба, причём лимиты записаны прямо в вызове. Набросок формы, которую мы используем для процессов типа разбора обращений:
def route(case: Case) -> Decision:
if hit := RULES.match(case): # 1. версионируемые правила
return Decision(hit.queue, source="rule", rule_id=hit.id) label = classify(case.text, schema=Label) # 2. один вызов LLM с валидацией
if label.category != "unknown" and label.confidence >= 0.85:
return Decision(label.queue, source="llm", prompt=label.prompt_version)
if case.priority == "low": # 3. дешёвые случаи уходят людям
return Decision("human_review", source="fallback", guess=label)
return run_agent(case, # 4. ограниченный агент
tools=["crm.read", "kb.search", "orders.read"],
max_steps=8, max_tokens=40_000,
approval_required=["crm.write", "email.send"])
</code></pre>
Пороги здесь условные, мы выставляем их по первым нескольким сотням исторических случаев. Затем каждую неделю смотрим, куда падают случаи. Если шаг 4 берёт растущую долю случаев, которые заканчиваются одинаково, эти концовки становятся правилами, а агент сжимается.
Принесите нам один процесс, и мы скажем, к какой из четырёх строк он относится. Это первый вопрос в каждом проекте по ИИ и автоматизации процессов, который мы оцениваем. Опишите процесс здесь.