Нужен ли процессу AI-агент: как выбрать между правилами, автоматизацией и автономностью

Фраза «давайте построим агента» часто появляется раньше, чем описание проблемы.

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

Такой порядок повышает вероятность получить впечатляющее демо и дорогую операционную проблему.

AI-агент — не высшая ступень любой автоматизации. Это один из архитектурных вариантов. Он полезен, когда система должна самостоятельно выбирать следующий шаг в изменяющемся контексте. Вместе с гибкостью он добавляет:

• вариативность;
• стоимость;
• latency;
• управление состоянием;
• новые режимы отказа;
• требования к оценке качества;
• полномочия и контроль;
• более сложное восстановление.

Поэтому практический вопрос звучит не так:

Какой агентный framework использовать?

А так:

Какая часть процесса действительно требует самостоятельного выбора пути, а какая должна остаться обычной, проверяемой автоматизацией?

Короткий ответ

Используйте детерминированный workflow, когда:

• последовательность шагов известна;
• бизнес-правила можно сформулировать;
• входы структурированы;
• исключения перечислимы;
• результат должен быть повторяемым;
• ошибка имеет существенные последствия.

Используйте AI-помощника, когда:

• нужно интерпретировать текст, изображение или голос;
• полезен черновик, классификация или рекомендация;
• человек остаётся владельцем решения;
• результат можно быстро проверить.

Используйте ограниченного агента, когда:

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

Используйте multi-agent архитектуру только тогда, когда задача действительно выигрывает от параллельной специализации и её ценность оправдывает дополнительную стоимость координации.

Автономность — не функция, а цена

В обычном workflow код определяет, какой шаг будет следующим. В агентной системе часть этого решения передаётся модели.

Это создаёт полезную адаптивность, но одновременно означает, что два запуска с одинаковым началом могут:

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

Для исследовательской задачи такая вариативность может быть преимуществом. Для обновления цены в CRM — дефектом.

Мнение Methodfield

Сложность должна быть заработана.

Не следует добавлять автономность потому, что она доступна в платформе или лучше выглядит в презентации. Её стоит добавлять после того, как более простой уровень перестал решать измеримый bottleneck.

Если процесс можно исправить правилом, формой или интеграцией, агент не делает решение более зрелым. Он делает его менее предсказуемым.

Лестница зрелости: пять уровней

Уровень 0. Удалить или изменить процесс

До автоматизации нужно проверить, нужен ли процесс в текущем виде.

Полезные вопросы:

• Почему этот шаг существует?
• Кто использует результат?
• Что произойдёт, если его удалить?
• Какие данные запрашиваются повторно?
• Где решение ожидает согласования без необходимости?
• Какое исключение на самом деле стало обычным случаем?

Удаление трёх лишних шагов может дать больше эффекта, чем AI, и одновременно сократить поверхность будущих ошибок.

Уровень 1. Детерминированная автоматизация

Подходит для:

• синхронизации полей;
• создания задач по событию;
• расчёта по формуле;
• проверки обязательных данных;
• маршрутизации по известному правилу;
• отправки фиксированного уведомления;
• формирования документа из утверждённых блоков.

Преимущества:

• повторяемость;
• низкая стоимость;
• простое тестирование;
• понятная ответственность;
• лёгкий audit;
• предсказуемый rollback.

Не нужно использовать модель, чтобы проверить, заполнено ли поле email.

Уровень 2. AI-помощник

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

Примеры:

• классифицировать обращение;
• извлечь требования;
• суммировать разговор;
• найти противоречия в документе;
• подготовить черновик ответа;
• предложить варианты;
• отметить неопределённость.

Система определяет момент вызова модели, формат результата и следующий шаг. Человек или детерминированное правило решает, что делать дальше.

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

Уровень 3. Ограниченный агент

Агент самостоятельно выбирает путь внутри заранее определённого контура.

Например, агенту поручено подготовить briefing по потенциальному клиенту. Он может:

• выбрать несколько разрешённых источников;
• искать дополнительный контекст;
• менять поисковые запросы;
• сравнивать сведения;
• остановиться при достаточном объёме evidence;
• создать структурированный результат.

При этом он не может:

• писать клиенту;
• менять CRM;
• покупать данные;
• выходить за бюджет;
• использовать неизвестный инструмент;
• продолжать работу бесконечно.

Цель ясна, путь вариативен, последствия ограничены.

Уровень 4. Multi-agent система

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

Anthropic описывает этот подход для открытого исследования: ведущий агент разбивает задачу, специализированные агенты ищут информацию по разным направлениям, затем результат синтезируется и проверяется.

Но сама Anthropic отмечает высокую цену: по их внутренним данным агенты использовали примерно в четыре раза больше токенов, чем обычный чат, а multi-agent системы — примерно в пятнадцать раз больше. Это не универсальный benchmark, а данные конкретной системы, но направление важно.

Multi-agent архитектура оправдана, когда:

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

Она плохо подходит, когда:

• все исполнители должны постоянно видеть одно состояние;
• шаги строго последовательны;
• задача проста;
• результат нужен за секунды;
• координация дороже самой работы;
• ошибку трудно локализовать.

Матрица выбора

Эта матрица не выбирает продукт. Она определяет уровень автономности.

Детерминированный каркас вокруг AI

Большинство production-систем не обязаны быть полностью детерминированными или полностью агентными.

Более практичная архитектура:

Детерминированный trigger
→ проверка входов
→ AI для неопределённого шага
→ детерминированная валидация
→ согласование по риску
→ внешнее действие
→ измерение конечного состояния

Текстовая альтернатива: событие запускает проверяемые правила; AI используется только для интерпретации или поиска; результат проходит детерминированную валидацию; действия с высокими последствиями подтверждает человек; после выполнения система проверяет конечное состояние.

Microsoft описывает похожий спектр: для каждого шага можно выбрать детерминированный executor, агентный executor или human-in-the-loop gate. Это полезнее, чем объявлять агентом весь процесс.

Пример: входящее обращение клиента

Рассмотрим workflow:

Письмо клиента
→ извлечь требования
→ определить недостающие данные
→ подготовить ответ
→ подтвердить цену и условия
→ отправить
→ обновить CRM

Не все шаги требуют одинаковой архитектуры.

Весь workflow можно назвать «AI-системой», но только один или два шага действительно требуют агентности.

Почему демо обманывает

Демо обычно показывает прямой успешный путь:

1. дан хороший запрос;
2. данные доступны;
3. инструмент отвечает;
4. модель выбирает разумный шаг;
5. результат принимается.

Production добавляет:

• неполные входы;
• устаревшие правила;
• повторные события;
• недоступные API;
• изменение схемы данных;
• конкурентные обновления;
• задержки;
• лимиты;
• частично выполненные операции;
• необходимость продолжить run после сбоя.

Anthropic отмечает, что агенты сохраняют состояние на протяжении большого числа tool calls, а ошибки накапливаются. Поэтому нужны checkpoints, возобновление, tracing и детерминированные safeguards.

Последняя миля часто становится большей частью проекта.

Экономика: считать нужно проверенный результат

Сравнивать только цену одного model call недостаточно.

Полная стоимость включает:

• токены и tool calls;
• повторные попытки;
• инфраструктуру состояния;
• наблюдаемость;
• evals;
• ручное согласование;
• исправление ошибок;
• поддержку интеграций;
• обновление правил;
• восстановление после частичного выполнения.

Google Cloud сообщает, что 83% участников их исследования считают необходимым обновить инфраструктуру для production-grade agentic AI, а 81% называют операционную сложность и инженерные накладные расходы существенными неожиданными затратами. Исследование относится прежде всего к корпоративной инфраструктуре, поэтому его проценты нельзя напрямую переносить на малый бизнес. Но направление универсально: agentic load создаёт больше работы вокруг модели.

Для малого бизнеса полезная метрика:

Стоимость проверенного результата =
модель
+ инструменты
+ инфраструктура
+ review
+ исправления
+ поддержка

Если агент экономит пять минут, но требует десять минут проверки и регулярного восстановления, автоматизация не окупается.

Метрики по уровням

Для детерминированного workflow

• completion rate;
• время выполнения;
• число технических ошибок;
• повторные операции;
• ручное время на исключения.

Для AI-помощника

• correction rate;
• время review;
• доля принятых черновиков;
• ошибки извлечения;
• стоимость одного принятого результата.

Для агента

• task success по конечному состоянию;
• среднее и предельное число шагов;
• tool error rate;
• доля runs, остановленных лимитом;
• восстановление после сбоя;
• нарушения permission policy;
• стоимость одного проверенного результата;
• доля ручных эскалаций.

Для multi-agent системы

• полнота результата;
• дублирование работы между агентами;
• стоимость координации;
• время самой медленной ветви;
• качество синтеза;
• потеря evidence при handoff;
• разница с single-agent baseline.

Нельзя оценивать multi-agent систему только по тому, что она «использовала несколько специалистов».

Десять вопросов до выбора архитектуры

1. Какой измеримый bottleneck мы устраняем?
2. Можно ли удалить или упростить шаг?
3. Известна ли правильная последовательность?
4. Где требуется интерпретация, а где достаточно правила?
5. Как проверить конечный результат?
6. Какова цена ошибки?
7. Какие действия обратимы?
8. Кто владеет исключениями?
9. Сколько времени и денег разрешено одному run?
10. Что должен доказать простой prototype до расширения автономности?

Если ответы неясны, модель и framework выбирать рано.

Типичные ошибки

Автоматизировать сломанный процесс

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

Называть набор интеграций «AI-сотрудником»

Термин скрывает ответственность. Лучше перечислить конкретные действия, полномочия и точки согласования.

Давать агенту задачу с неясным результатом

Автономность не создаёт бизнес-ясность. Она автоматизирует неоднозначность.

Использовать multi-agent архитектуру без параллелизма

Несколько агентов последовательно пересказывают друг другу один контекст, увеличивая стоимость и риск потери информации.

Считать успешным красивый финальный текст

Нужно проверять конечное бизнес-состояние: создан ли правильный объект, обновлена ли нужная версия, выполнено ли разрешённое действие.

Добавлять человека после каждого шага

Избыточные подтверждения превращаются в механические клики. Human review должен соответствовать последствиям, а не компенсировать отсутствие архитектуры.

Рекомендуемый путь внедрения

Шаг 1. Зафиксировать baseline

Измерить:

• объём операций;
• ручные минуты;
• время ожидания;
• error/rework rate;
• стоимость исключений.

Шаг 2. Упростить процесс

Удалить повторные вводы, лишние согласования и шаги без потребителя результата.

Шаг 3. Автоматизировать известное

События, правила, маршрутизацию и записи реализовать детерминированно.

Шаг 4. Добавить один AI-шаг

Выбрать интерпретацию или черновик, который легко проверить.

Шаг 5. Проверить на репрезентативной выборке

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

Шаг 6. Добавить ограниченную автономность

Только если данные показывают, что фиксированный путь не справляется с реальной вариативностью.

Шаг 7. Расширять после доказательства

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

Итоговая позиция

AI-агент полезен не тогда, когда он может выполнить много шагов.

Он полезен тогда, когда:

• результат ясен;
• путь действительно меняется;
• контур полномочий ограничен;
• конечное состояние проверяемо;
• стоимость оправдана;
• восстановление спроектировано.

Большинство практических систем должно оставаться детерминированным вокруг того небольшого участка, где AI действительно добавляет ценность.

Используйте правила для известного. AI — для интерпретации. Агента — для ограниченной неопределённости. Человека — для решений с существенными последствиями.

Источники

• Microsoft Learn, Workflows (откроется в новой вкладке), версия, доступная 29 июля 2026 года.
• Microsoft Learn, Workflow-oriented multi-agent patterns (откроется в новой вкладке), обновлено 20 мая 2026 года.
• Microsoft Learn, Use the agent design framework (откроется в новой вкладке), версия, доступная 29 июля 2026 года.
• Anthropic, How we built our multi-agent research system (откроется в новой вкладке), 13 июня 2025 года.
• Anthropic, Demystifying evals for AI agents (откроется в новой вкладке), версия, доступная 29 июля 2026 года.
• Google Cloud, State of AI infrastructure report and the Agentic Data Cloud (откроется в новой вкладке), 23 июля 2026 года.