В цикле · S1E01 Жизненный цикл агента
Агент или workflow: как выбрать архитектуру
Когда хватает одного вызова модели, как устроены основные workflow и за что приходится платить при переходе к автономному агенту.
В AI-продукте легко начать с самого сложного варианта: дать модели инструменты, разрешить ей планировать и ждать, что получится универсальный помощник. Но свобода выбора следующего шага полезна только там, где заранее заданный маршрут мешает решить задачу. Во всех остальных случаях за неё приходится платить дополнительными вызовами, задержкой и менее предсказуемым поведением.
В первом выпуске «В цикле» мы разбираем архитектурное различие из статьи Anthropic Building effective agents. Здесь превратим его в способ выбрать устройство своего продукта. Примеры ниже — учебные сценарии, а не результаты клиентских проектов neonix.
Кто выбирает следующий шаг
В workflow маршрут задаёт код. Модель может классифицировать запрос, извлечь данные или написать ответ, но приложение определяет допустимые переходы. Например: получить обращение → определить тему → найти информацию → подготовить ответ → проверить обязательные поля.
В агенте следующий шаг выбирает модель. Она может сначала прочитать документ, затем поискать недостающие сведения, проверить предположение инструментом и пересмотреть план. Разработчик задаёт инструменты, ограничения и условия остановки, но не всю последовательность действий.
Наличие LLM, нескольких инструментов или повторных вызовов само по себе ещё не делает систему автономным агентом. Полезнее спросить: какие решения принимает модель и какие из них действительно нельзя заранее описать в коде?
Сначала определите место, где нужна гибкость. Один агентный шаг внутри понятного workflow часто практичнее, чем автономность всего процесса.
Начните с контрольного варианта
Возьмём помощника поддержки. Если нужно ответить на вопрос по базе знаний, первым решением может быть один вызов модели с найденными фрагментами и примерами хорошего ответа. Так появляется контрольный вариант: его качество, стоимость и время ответа можно измерить.
Дальше разбираем ошибки. Не найдены нужные сведения — улучшаем поиск. Ответ нарушает формат — уточняем контракт и проверку. Нужен актуальный статус заказа — добавляем инструмент чтения. Ни одна из этих проблем автоматически не требует автономного планирования.
Агент становится обоснованным, если успешные траектории действительно различаются: одному обращению достаточно ответа из документации, другому нужно проверить несколько систем, третьему — задать уточняющий вопрос и продолжить расследование. При этом результат должен поддаваться проверке.
Пять способов усложнить систему постепенно
В материале Anthropic описаны пять композиционных паттернов. Их удобно рассматривать как набор вариантов, а не обязательные ступени зрелости.
| Паттерн | Когда полезен | Что проверить |
|---|---|---|
| Цепочка | Этапы известны: план → проверка → текст | Ошибки раннего этапа не должны бесконтрольно переходить дальше |
| Маршрутизация | Различимые классы обращений требуют разных процессов | Качество классификации и путь для неопределённых случаев |
| Параллельная обработка | Есть независимые части или несколько оценок одного результата | Правило объединения и стоимость всех вызовов |
| Оркестратор и исполнители | Состав подзадач зависит от конкретного входа | Полноту разбиения, зависимости и проверку общего результата |
| Оценщик и оптимизатор | Замечания по ясным критериям помогают улучшить ответ | Измеримый выигрыш и предел числа итераций |
У цепочки между этапами может стоять программная проверка — например, план содержит все обязательные разделы. Это не то же самое, что согласование человеком. Проверка оценивает определённое условие, а человек принимает решение там, где нужны полномочия или суждение.
При маршрутизации ветки остаются известными заранее. Она полезна, например, чтобы отделить справочный ответ от возврата покупки. У каждой ветки будут свои данные, инструкции и разрешённые действия. Ошибку выбора ветки важно измерять отдельно от качества ответа внутри неё.
Оркестратор отличается от обычного распараллеливания тем, что сам определяет состав работы. Для изменения программы это могут быть разные файлы; для исследования — разные вопросы. Но делегирование не решает проблему согласованности: результаты всё равно нужно собрать и проверить.
Что меняется при переходе к агенту
Агент работает в цикле: получает состояние, выбирает действие, наблюдает результат и решает, что делать дальше. Важна именно обратная связь из среды. Фраза модели «изменение выполнено» не заменяет подтверждение инструмента или проверку состояния системы.
За гибкость платят не только токенами. Длинная траектория даёт больше возможностей ошибиться, а повторные действия могут менять внешнее состояние. Поэтому нужны общий бюджет времени, ограничения числа шагов и расходов, правила повторов и понятный выход к человеку.
Для действий с последствиями границу задаёт приложение. Модель может предложить возврат, но код проверяет пользователя, заказ, лимиты и необходимые подтверждения. Текст системного промпта не заменяет проверку прав на стороне сервиса.
Как понять, что сложность окупилась
Сравнивать стоит на одном наборе задач. Доля успешно решённых обращений показывает полезность, время до результата — пользовательский опыт, а полная стоимость траектории — экономику. Отдельно учитывайте долю передачи человеку и ошибки с последствиями.
Если качество выросло только на простых демонстрациях, оснований усложнять продакшен мало. Добавьте неоднозначные запросы, недоступные инструменты, противоречивые данные и задачи, которые система должна отклонять. Для этого пригодится система продуктовых evals.
Фреймворк может ускорить разработку, но не снимает эти вопросы. Команда должна видеть реальные запросы модели, результаты инструментов и причины переходов. Без такой наблюдаемости трудно отличить ошибку промпта от ошибки orchestration-кода.
Перед первым прототипом
- Сформулируйте результат, который можно проверить независимо от слов модели.
- Соберите простейший вариант и измерьте его на характерных задачах.
- Назовите конкретное решение, которое требуется передать модели.
- Определите доступные действия, условия остановки и передачу человеку.
- Сравните улучшение качества с дополнительным временем и стоимостью.
Следующий технический шаг — контракт вызова инструментов: как превратить выбранное моделью действие в проверяемое исполнение.
Источники
Статья подготовлена по главам 1–2 материалов «Жизненный цикл агента» и сценарию S1E01. Архитектурные паттерны опираются на Building effective agents — Anthropic. Исходный материал опубликован в 2024 году; названия библиотек и моделей меняются, поэтому здесь разбираются принципы выбора архитектуры.
