Если шаги процесса известны заранее, начни с обычного workflow. Добавляй агентный цикл только там, где системе нужно выбирать следующий шаг по результату предыдущего. Граница между workflow и агентом не всегда жёсткая: приложение может сочетать фиксированные переходы с ограниченным выбором модели. Чем больше решений и инструментов отдают циклу агента, тем больше становится точек отказа и сложнее отлаживать поведение.
Представь процесс разбора входящих обращений. На входе письмо, на выходе — категория, краткое содержание и предложение ответа. Возможны три архитектуры.
Вариант A: фиксированный workflow
- Проверить формат письма.
- Извлечь текст.
- Передать текст модели для структурированной классификации.
- Проверить обязательные поля.
- Положить черновик в очередь сотруднику.
Порядок заранее известен. Если классификация неуверенная, процесс ставит статус «ручная проверка». Такая схема проще отлаживается: можно посмотреть отдельный шаг и воспроизвести сбой.
Вариант B: модель как один шаг
Модель читает письмо и возвращает JSON по схеме: категория, краткое описание, уверенность/причина эскалации. Программа проверяет формат, допустимые категории и длину. Дальше детерминированный код решает, куда отправить результат. Здесь модель интерпретирует язык, но не выбирает произвольные инструменты.
Вариант C: агентный цикл
Агент может сначала запросить историю обращения, затем проверить статус заказа, задать уточняющий вопрос или передать дело человеку. Здесь модель выбирает инструмент и следующий шаг на основе наблюдений. В официальной документации OpenAI руководство по agents описывает композицию агентных приложений и управление tool handoffs (Agents guide); Microsoft Agent Framework, например, описывает загружаемые во время выполнения Agent Skills как пакеты инструкций и ресурсов — это продуктовая реализация, а не универсальная схема (документация Agent Skills).
Решающее дерево
| Вопрос | Если «да» | Если «нет» |
|---|---|---|
| Все шаги и условия известны заранее? | Начни с workflow | Рассмотри модельный выбор шага |
| Нужна интерпретация свободного текста? | Модель может решить ограниченную подзадачу | Используй правила/код |
| Следующий шаг зависит от результата инструмента? | Может быть оправдан ограниченный агентный цикл | Оставь последовательный workflow |
| Есть безопасная граница остановки? | Определи лимит шагов и эскалацию | Не давай агенту автономный доступ |
| Ошибку можно обнаружить до внешнего действия? | Добавь проверку и подтверждение | Сначала построй защитный контур |
Минимальные ограничения для агента
- Разрешён короткий список конкретных инструментов.
- Максимальное число шагов и время выполнения заданы заранее.
- Повторный вызов не создаёт дубли (идемпотентность или проверка).
- Любая отправка клиенту, изменение заказа или удаление требует подтверждения.
- При пустом, противоречивом или недоступном результате агент прекращает работу и передаёт человеку.
- Логи не сохраняют лишние персональные данные и секреты.
Начни с самого простого решения, которое закрывает процесс. Поставь измеримые критерии: доля корректно заполненных полей, доля ручной эскалации, время и стоимость одного обращения. Не заявляй «агент справляется» по одной удачной демонстрации. Сначала собери реальные тестовые случаи и проверь сбои.
Когда агент действительно нужен
Например, обращение может требовать сначала поиска документа, затем сверки версии продукта, а потом выбора между ответом и эскалацией. Если набор допустимых действий ограничен, а каждое действие проверяется, агентный цикл может быть полезен. Если же процесс всегда «извлечь три поля и положить в очередь», фиксированное приложение дешевле и прозрачнее.
Пример: новое обращение → извлечены поля → не хватает данных → запрос уточнения → готов черновик → подтверждён сотрудником → отправлен. Для каждого перехода запиши условие и владельца. Если система сообщает confidence, не считай это вероятностью правильного ответа без отдельной калибровки на размеченных примерах.
Добавь таймаут и бюджет: максимум вызовов, допустимая стоимость, срок ожидания инструмента. Без верхней границы цикл может повторять поиск, пока не исчерпает лимит или не создаст несколько одинаковых заявок. Зафиксируй request_id, чтобы повтор одного события не выполнял side effect дважды.
Пилот начинай в режиме shadow: система предлагает категорию или действие, но не применяет его. Сотрудник сравнивает предложение с реальной обработкой и помечает несогласия. Только после проверки ограниченного набора случаев имеет смысл обсуждать постепенное расширение полномочий.
Порог, после которого нужен человек
Эскалация должна быть конкретной: неизвестный идентификатор, несколько совпадений, низкое качество поиска, конфликт источников, отказ инструмента, превышение бюджета, неожиданное действие. Не проси агента «самому понять, когда нужен человек» без определения сигналов и маршрута. Для каждого состояния укажи, что показать оператору: исходный запрос, найденные данные, уже выполненные действия и причина остановки.
Перед пилотом ответь, кто следит за очередью эскалаций и за какое время она должна быть разобрана. Иначе система может переводить сложные случаи в ручную очередь, которую никто не мониторит. Внеси эти состояния в тестовый набор и проверь удачный проход, отказ инструмента, неоднозначный поиск, таймаут и запрет на действие. Пример набора — в руководстве по проверке ИИ-агента.
Пример разумного выбора
Разбор короткого сообщения «не пришёл заказ» можно сделать фиксированным workflow: извлечь order ID, проверить заполнение, найти заказ, подготовить статус и передать оператору. Агентный выбор шага нужен лишь если сообщение неполное и система должна решить, что спросить дальше или какие из нескольких безопасных справок открыть. Изменять адрес доставки или обещать компенсацию без подтверждения не следует в обоих вариантах.
Сравни архитектуры на той же очереди входов: скорость, число ручных передач, частота ошибок в полях и стоимость обработки. Не включай реальные аккаунты на первом прогоне.
Если workflow уже покрывает процесс, агентный цикл может добавить расходы и состояния без полезного результата. Сравни варианты на одной очереди тестовых входов и вернись к решению после пилота. Проектная разработка агентных workflow — тема MK Ultra.