Не каждой ИИ-системе нужен агент

8 архитектурных паттернов для бизнес-систем с ИИ

Многие компании сегодня начинают ИИ-проект с вопроса: "Как нам построить для этого ИИ-агента?". Я считаю, что более правильным было бы начать с поиска ответа на другой вопрос: "Как эту работу можно выполнить проще, быстрее и дешевле?". То есть — с определения наиболее релевантной для задачи ИИ-архитектуры.

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

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

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

Поэтому выбор ИИ-архитектуры во многом сводится к вопросу баланса между самостоятельностью модели, детерминированностью системы и человеческим участием.  

Почему словосочетание “ИИ-агент” часто используется не к месту 

Далеко не каждая многошаговая ИИ-система является агентом.

OpenAI, например, относит к агентам системы, в которых LLM управляет выполнением рабочего процесса (workflow), решает, что делать дальше, и динамически выбирает инструменты в рамках установленных ограничений. 

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

Давайте рассмотрим их

Восемь архитектурных паттернов для ИИ-решений

1. Один вызов — один ответ

Схема: Вход → LLM → Выход

Самый простой вариант: модель получает ограниченную задачу, достаточный контекст и четкое описание требуемого результата. Один вызов — один ответ.

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

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

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

2. Детерминированный ИИ-конвейер

Схема: Извлечение → Структурирование → Расчет → Проверка → Генерация

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

В качестве примера можно использовать анализ финансовых документов. LLM может извлечь и нормализовать информацию из неструктурированных файлов, код рассчитывает коэффициенты, а наличие необходимых данных проверяется по заранее заданным правилам. После этого модель уже может объяснить, что означают полученные результаты.

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

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

3. Условный ИИ-процесс или Ветвление

Схема: Анализ → Оценка состояния → Выбор заранее заданной ветви

Например:
Высокая уверенность → Продолжить
Обнаружено противоречие → Проверка
Превышен порог риска → Проверка человеком

Компании часто говорят, что им нужна автономность, хотя на практике им нужна вариативность.

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

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

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

4. Процесс принятия решений с участием человека

Схема: Анализ ИИ → Контрольная точка принятия решения → Проверка человеком → Продолжение

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

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

Google прямо относит необходимость человеческого суждения при решениях с высокими ставками или высокой долей субъективности к факторам, которые должны влиять на выбор архитектуры. Microsoft Agent Framework аналогичным образом поддерживает рабочие процессы, которые могут приостанавливаться и ожидать внешнего ввода от человека.

Уровень автоматизации при этом может расти, не устраняя саму точку человеческого решения.

5. Архитектура с дополнением знаниями / поиском информации

Схема: Вопрос → Поиск релевантного контекста → Рассуждение на основе контекста → Ответ

Если модели нужны внешние, актуальные или закрытые данные, эту информацию необходимо доставить в ее текущий контекст.

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

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

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

Современные промышленные системы уже давно вышли за пределы простого векторного поиска.

Поэтому вопроса "Нужен ли нам RAG?" недостаточно. Важно понять, какая информация требуется модели, на каком этапе, каким способом ее извлекать и как определить, достаточно ли полученного контекста и можно ли ему доверять.

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

6. ИИ-система с использованием инструментов

Схема: Модель определяет потребность → Детерминированный инструмент выполняет задачу → Результат возвращается модели

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

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

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

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

7. Агентный рабочий процесс

Схема: Цель → Модель составляет план → Выполняет действие → Наблюдает результат → Определяет следующее действие → Повторяет цикл

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

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

Но у такой гибкости есть своя цена.

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

Это что-то вроде налога на автономность. Каждая дополнительная степень свободы модели расширяет диапазон возможного поведения, которое системе приходится отслеживать, и увеличивает число типов отказов, которые она должна уметь обрабатывать.

Автономность имеет смысл там, где ценность этой свободы превышает дополнительные затраты на контроль.

8. Многоагентная система

Схема: Оркестратор ↔ Специализированные агенты ↔ Инструменты / внешняя среда

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

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

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

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

Поэтому архитектура вида "агент-исследователь + агент-критик + агент-проверяющий + агент-менеджер" требует отдельного функционального обоснования для каждой роли. Иначе четыре вероятностных компонента могут просто дублировать работу, которую одна модель вместе с детерминированной проверкой выполнит надёжнее.

Эффективные рабочие системы обычно имеют гибридную ИИ архитектуру

Эти восемь вариантов лучше рассматривать как строительные блоки, а не как восемь взаимоисключающих типов систем.

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

Например, система поддержки принятия решений может извлекать внутренние данные и доказательства и передавать их большой языковой модели для интерпретации. Факты и состояние рабочего процесса при этом хранятся в явном виде. Расчеты, правила проверки и часть контрольных процедур выполняются детерминированно. Вызовы инструментов обеспечивают доступ к внешним сервисам. На определенном этапе сохраняется проверка человеком.

По сути, выбирая архитектуру ИИ, вы выбираете способ распределения неопределенности.

Известные и точные операции естественно передавать детерминированному программному обеспечению. Интерпретация — задача модели. Поиск и извлечение информации нужны там, где необходимые знания находятся за пределами текущего контекста. Условные ветвления позволяют менять маршрут, если промежуточные данные изменили состояние системы.

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

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

Инвестиционный скрининг как пример аналитической системы

Возьмем ИИ-систему для первичного анализа стартапов ранних стадий.

Одна из возможных архитектур может выглядеть так:

Материалы стартапа
→ Структурированное извлечение фактов и подтверждений
→ Анализ атрибутов
→ Выявление противоречий
→ Оценка конфигурации атрибутов
→ Условная проверка
→ Инвестиционное суждение
→ Проверка человеком
→ Итоговая аналитическая записка для первичного отбора

Внутри одного процесса здесь одновременно работают несколько архитектур.

Извлечение информации может выполняться моделью, а структурированные факты и состояние процесса — храниться отдельно. Известные противоречия запускают детерминированные проверки или проверки с участием модели. Дополнительная проверка нужна только в тех случаях, где сохраняется существенная неопределенность. Инвестиционная интерпретация требует суждения. Выпуск окончательного решения остается точкой человеческого контроля.

Технически всю эту последовательность можно заменить одним автономным агентом и дать ему инструкцию: "Проанализируй этот стартап и подготовь инвестиционную аналитическую записку".

Однако надежность такого решения будет под большим вопросом. 

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

В аналитических ИИ-системах разбиение процесса на отдельные этапы часто нужно именно для того, чтобы источник ошибки оставался видимым и понятным.

Отсюда мои рекомендации по выбору архитектуры для ИИ-решений.

Как выбрать оптимальную архитектуру для ИИ-продукта

Начните с ответов на следующие вопросы: 

1. Можно ли надежно определить последовательность работы заранее?

Если да, то естественная отправная точка — конвейер или workflow. Передача управления последовательностью действий самой модели требует отдельного обоснования.

2. Нужны ли разные маршруты в зависимости от промежуточного результата?

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

3. Что произойдет, если система ошибется?

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

4. Требуется ли для рассуждения информация за пределами текущего контекста?

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

5. Есть ли этапы, где требуется точный расчет или выполнение конкретного действия?

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

6. Действительно ли следующий шаг трудно определить заранее?

Именно здесь агентный подход становится оправданным. Хороший пример — исследование с открытым сценарием, где каждая новая находка может изменить направление дальнейшей работы.

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

При положительном ответе, имеет смысл рассматривать архитектуру с несколькими агентами.

Сама по себе идея "ИИ-команды" — слабое основание для архитектурного решения. Сейчас, в эпоху роста популярности ИИ-агентов, такая идея звучит понятно и привлекательно, но следование ей легко может привести к системе, которая окажется дороже и сложнее того бизнес-процесса, который должна была улучшить.

И еще. 

Есть соблазн воспринимать эти архитектуры как своеобразную лестницу зрелости для ИИ-решений:

один вызов модели → workflow → агент → многоагентная система.

Такое отношение к вариативности архитектур будет неверным. Речь не идет о том, что какая-то из них лучше других. 

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

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

Иногда для этого нужна значительная автономность. А иногда лучшее инженерное решение — один вызов модели и пару строчек кода.

Проще говоря, хорошая ИИ-система использует ровно столько автономности, сколько действительно требует задача.

Источники:

• Anthropic, Building Effective AI Agents — distinction between predefined workflows and dynamically directed agents; guidance to increase complexity only when needed.
• OpenAI, A Practical Guide to Building Agents — agent definition, tool use, orchestration, single-agent and multi-agent architecture guidance.
• Google Cloud Architecture Center, Choose a Design Pattern for Your Agentic AI System — workload-based architecture selection across complexity, latency, cost and human involvement.
• Microsoft Agent Framework, Human-in-the-Loop Workflows — explicit workflow checkpoints for external human input.
• AWS Prescriptive Guidance, Understanding Retrieval Augmented Generation — production RAG components including retrieval, orchestration, guardrails and access control.
• Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — foundational RAG architecture combining parametric and retrieved non-parametric knowledge.
• Anthropic, How We Built Our Multi-Agent Research System — production experience with multi-agent research, including coordination, evaluation and cost trade-offs.
• Anthropic, Demystifying Evals for AI Agents — why multi-turn autonomy and state changes make agent evaluation more difficult.