Архитектура ИИ-агента: от обращения до результата

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

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

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

Описания компонентов ниже сверены с материалами Anthropic, OpenAI, Google Cloud и спецификацией Model Context Protocol 25 октября 2026 года. Сценарий работы поддержки — пример проектирования, а не описание внедрения у конкретного заказчика.

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

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

Хорошая отправная точка — augmented LLM в терминологии Anthropic: языковая модель, подключённая к поиску данных, инструментам и памяти. В рекомендациях компании проводится различие между процессом, маршрут которого задан в коде, и агентом, который динамически выбирает следующие действия. Усложнять систему предлагается лишь тогда, когда этого требует задача. Рекомендации Anthropic по созданию агентов

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

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

Как устроен ИИ-агент: слои и связи на схеме

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

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

Модель: понять обращение и предложить следующее действие

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

Инструменты и MCP: подключение к бизнес-системам

Model Context Protocol (MCP) — стандартный интерфейс между ИИ-приложениями и внешними возможностями. Он описывает именованные инструменты с inputSchema, получение их списка через tools/list и вызов через tools/call. Поиск аккаунта можно предоставить через MCP или обычную функцию, которая обращается к бизнес-API. В обоих случаях сервис, выполняющий запрос, обязан проверять аргументы и ограничивать доступ нужным аккаунтом. MCP стандартизирует подключение; подробнее о протоколе и границах доверия — в объяснении MCP. Спецификация инструментов MCP

Память: сохранение нужного контекста

Agent Development Kit (ADK), фреймворк Google для создания агентов, использует Session и state для данных внутри одного взаимодействия и поддерживает память между сессиями через такие компоненты, как Memory Bank. Для поддержки текущее обращение и ожидающее согласование стоит хранить в приложении, актуальные сведения об аккаунте получать из первоисточника, а предпочтения клиента сохранять лишь там, где это уместно. Это разные задачи. Контекст, хранение данных сессии и долговременная память разобраны в руководстве по памяти агентов. Архитектурные рекомендации Google Cloud

Оркестрация: выполнение, паузы и восстановление

В руководстве OpenAI по созданию агентов Agents SDK описан как средство управления циклом вызова инструментов, передачей управления и защитными проверками. Он даёт приложению механизм запуска работы, которой управляет модель. При этом приложение должно сохранять этап обработки обращения: идёт ли разбор, ожидается ли проверка, выполняется ли действие или работа уже завершена. Тогда после перезапуска процесса можно будет восстановить обработку. Как запуски агентов встраиваются в более длительный бизнес-процесс, объясняет руководство по оркестрации. Руководство OpenAI по агентам

Защитные проверки и согласование человеком: контроль последствий

OpenAI Agents SDK разделяет автоматические защитные проверки и остановки для согласования: последние приостанавливают вызов инструмента и возвращают состояние, из которого можно продолжить выполнение. Агент поддержки должен автоматически проверять доступ к аккаунту и предложенные аргументы, а изменение с существенными последствиями выполнять лишь после одобрения уполномоченным сотрудником. Контроль должен находиться непосредственно у инструмента, который совершает действие; подробности — в руководстве по защитным проверкам. Защитные проверки и согласование человеком в OpenAI

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

Трассировка в OpenAI Agents SDK записывает обращения к модели, вызовы инструментов, передачу управления и срабатывания защитных проверок. Рекомендации по оценке трасс объясняют, как оценивать поведение процесса по явным критериям. Наблюдаемость показывает, как обрабатывалось обращение; оценка качества проверяет, выбрал ли агент нужный аккаунт, соблюдал ли правила и подготовил ли ответ, подтверждённый данными. Определите, какие данные собирать и как долго хранить, прежде чем сравнивать инструменты наблюдаемости LLM. Трассировка в SDK, оценка качества агентов

Эталонная архитектура Google Cloud объединяет ADK, Cloud Run, доступ к модели, подключения MCP, Model Armor и наблюдаемость в конкретную схему развёртывания. В документации прямо указано, что память и хранилище сессий на схеме не показаны. Поэтому постоянное хранение состояния обращения нужно продумать отдельно: нельзя считать, что оно уже включено. Эталонная архитектура

От входящего обращения до ответа с решением

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

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

1. 1

   Принять и идентифицировать обращение

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

2. 2

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

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

3. 3

   Подготовить обоснованное предложение

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

4. 4

   Остановиться перед действием в бизнес-системе

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

5. 5

   Выполнить действие и проверить результат

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

6. 6

   Использовать результат для оценки качества

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

Особенно опасен сбой с неизвестным результатом записи: сервис аккаунтов мог применить изменение, хотя ваше приложение так и не получило ответ. Прежде чем повторять попытку, сверьтесь с исходной системой. Фраза «Я восстановлю доступ» в переписке подтверждает намерение, но не факт изменения доступа.

Когда архитектуре нужен ещё один агент

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

OpenAI различает handoffs — передачу диалога специалисту — и agents as tools, когда основной агент вызывает специалиста как инструмент, но сохраняет ответственность за ответ. В рекомендациях предлагается разделять агентов, если их инструкции, возможности или правила существенно различаются. Оркестрация и передача управления

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

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

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

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

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

Что брать готовым, а за что отвечать самим

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

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

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

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

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

Где нужно согласование человека и что записывать с самого начала

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

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

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

Ниже — отправная точка для требований к журналу событий. Трасса (trace) связывает события одного обращения; спан (span) фиксирует отдельную операцию внутри неё.

• Идентификация обращения: идентификаторы обращения и трассы, исходное событие и ссылка на аккаунт с подтверждённой личностью владельца. Используйте ссылки на записи, а не копируйте сведения о клиенте повсюду.
• Конфигурация: идентификатор модели, возвращённый провайдером, версия инструкций, версия схемы инструмента и версия правил. Эти данные показывают, какая конфигурация определяла поведение системы.
• Подтверждающие данные: идентификаторы найденных документов, нужные редакции и область доступа. Фиксируйте основания решения, не копируя конфиденциальные записи без разбора.
• Действия: название инструмента, аргументы со скрытыми конфиденциальными данными, временные отметки, длительность, статус результата и идентификатор повторной попытки или идемпотентности. Сохраняйте достаточно сведений, чтобы отличить предложенное действие от выполненного.
• Решения: результаты проверок, причина передачи вопроса на дальнейшее рассмотрение, статус согласования, ссылка на проверяющего и одобренное предложение.
• Результат и расход ресурсов: итоговый статус обращения, подтверждённые изменения во внешних системах, результат доставки, данные о расходе ресурсов от провайдера и метки оценки качества. Отслеживайте поправки клиентов и повторно открытые обращения, если система поддержки предоставляет эти данные.

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

Какие ограничения важны и что переоценивают

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

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

MCP не выдаёт разрешения. Спецификация его инструментов по-прежнему требует контроля доступа и проверки входных данных. Коннектор с широкими возможностями нуждается в такой же проверке бизнес-полномочий, как и собственный API. Требования безопасности MCP

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

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

Вопросы об архитектуре агентов

Что такое архитектура ИИ-агента?

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

Что такое ИИ-агент?

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

Какие бывают архитектуры агентов?

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

С чего начать: опишите обращение до выбора стека

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

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

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

Чтобы получать практические руководства по созданию и эксплуатации ИИ-систем, подпишитесь на рассылку.