Проектирование ИИ-агентов: как спроектировать систему искусственного интеллекта

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

Что такое ИИ-агент и чем он отличается от обычного чат-бота

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

При этом ее самостоятельность ограничивают правила.

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

Из чего состоит архитектура ИИ-агента

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

База знаний с RAG (генерация с дополненным поиском) помогает находить актуальные сведения в документах и корпоративных ресурсах. Инструменты связывают модель с CRM, календарем, поиском и другими сервисами, чтобы ИИ мог не только отвечать, но и выполнять действия. 

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

Так выглядит базовая схема: 

модель и инструкции → знания → инструменты → контекст, память и состояние → управление и контроль

Уровни сложности архитектуры ИИ-систем

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

1. Детерминированная автоматизация. Обычный алгоритм работает по заранее заданным правилам. Языковая модель либо не участвует в процессе, либо выполняет одну узкую задачу. Например, определяет тему обращения.
2. Ассистент на основе языковой модели отвечает на вопросы и создает тексты, но не обращается к внешним ресурсам и не выполняет действия. Такой помощник может составить ответ клиенту, но не проверит его заказ.
3. Ассистент с RAG. Перед ответом система находит сведения в базе знаний, к примеру, актуальные правила возврата.
4. ИИ-агент с инструментами сам выбирает подходящий инструмент, запрашивает данные из CRM и выполняет разрешенные действия: проверяет заказ и создает заявку на возврат после подтверждения клиента.
5. Агентный процесс проходит несколько этапов, сохраняет состояние задачи и проверяет промежуточные результаты. Если материалов не хватает или инструмент недоступен, меняет маршрут либо обращается к сотруднику.
6. Мультиагентная система. Несколько специализированных агентов распределяют роли. Один изучает обращение, второй проверяет правила, третий готовит решение, а отдельный компонент контролирует результат.

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

https://www.youtube.com/watch?v=hPE4ye0r0ms&

Этапы проектирования ИИ-агента

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

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

От идеи к требованиям

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

Определение цели и бизнес-задачи агента

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

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

Сбор требований и определение метрик успеха

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

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

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

Оценка рисков и планирование ресурсов

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

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

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

Проектирование и разработка архитектуры агента

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

Выбор модели: какая LLM подходит для вашей задачи

Большая языковая модель (LLM) станет основой. Она будет понимать вопросы клиентов, выбирать следующий шаг и формировать ответы. При выборе проверим не только качество текстов, но и скорость, стоимость, размер контекста, поддержку русского языка и умение работать с инструментами.

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

Проектирование системы инструментов (tools) и их интеграция

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

Сначала разрешим только безопасные операции: 

• найти товар, 
• проверить наличие 
• или узнать статус заказа. 

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

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

Организация памяти агента: краткосрочная и долгосрочная

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

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

Сбор и подготовка данных

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

Формирование базы знаний для ИИ-ассистента

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

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

Подготовка данных для RAG-компонента

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

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

Обеспечение качества и релевантности данных

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

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

Разработка промптов и системных инструкций

На этом этапе проектирование ИИ-систем превращается в набор конкретных инструкций для языковой модели. 

Создание персонажей (persona) агентов

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

Одного описания характера недостаточно. Добавим правила поведения:

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

Проектирование цепочек рассуждения (Reasoning) и планирования

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

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

Чтобы не заблудиться в этапах разработки ИИ-ассистента, пользуйтесь дорожной картой

Оркестрация ИИ-агентов: как организовать совместную работу

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

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

Последовательная оркестрация (Sequential / Pipeline)

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

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

Параллельная оркестрация (Concurrent / Parallel)

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

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

Групповой чат и коллаборативная оркестрация (Group Chat)

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

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

Тестирование, валидация и итеративное улучшение агента

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

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

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

Протестируем отдельные компоненты: 

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

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

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

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

Развертывание, мониторинг и эксплуатация

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

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

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

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

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

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

Если агент даст неверный ответ, мы изучим весь путь выполнения задачи: 

• исходный вопрос, 
• найденные сведения, 
• вызванные инструменты,
• принятое решение. 

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

Как освоить проектирование ИИ-агентов на практике

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

Необходимые навыки формируют на практическом интенсиве «Создание ИИ-агентов». Обучение начинается с прототипа без кода, а затем переходит к поиску по собственным документам, подключению внешних сервисов через MCP, обработке ошибок и созданию Telegram-ассистента. В результате студент разберется в проектировании ИИ-систем и создаст прототип, который можно доработать под задачи своей команды. 

Заключение

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