Архитектура AI-агентов на Nodul.ru: tool-centric vs sub-agentic vs action-routing подходы

В рамках проектирования AI-агентов на платформе Nodul.ru есть два основных архитектурных подхода к работе с инструментами и маршрутизацией логики. Оба подхода валидны, но применимы в разных ситуациях. Разберем их подробнее.

Подход 1: Работа только через тулы внутри агента (tool-centric)

Суть: Агент получает вход, сам определяет логику, вызывает подключенные инструменты (тулы) и формирует финальный ответ. Вся логика происходит внутри агента.

Плюсы:

  • Простота в реализации.
  • Минимум внешней логики: все в одном агенте.
  • Удобно для MVP, пилотных решений, простых ассистентов.

Минусы:

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

Пример кейса (скриншот выше): Кастомер саппорт бот с полным набором тулов в агенте:

  • Get Contact - получить данные клиента
  • Update Contact - обновить данные клиента
  • Create Ticket - создать тикет
  • Update Ticket - обновить статус тикета
  • Documentation - поиск в документации

Клиент пишет “хочу сменить email”. Агент сам вызывает все нужные тулы последовательно и отправляет готовый ответ через Reply To Message.


Подход 1.5: Работа через субагентов (sub-agents orchestration)

Суть: Главный агент вызывает узкоспециализированных субагентов, которые действуют только в рамках конкретных задач. Например, агент по управлению аккаунтов имеет доступ только к инструментам Get Contact Info и Update Contact, агент тикетов - к Create Ticket и Update Ticket, и т.д.

Плюсы:

  • Четкое распределение ролей между агентами.
  • Уменьшение вероятности галлюцинаций - каждый субагент специализирован.
  • Модульность: можно развивать каждого субагента независимо.
  • Переиспользование субагентов в разных сценариях.

Минусы:

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

Пример кейса(скриншот выше): Клиент пишет “хочу сменить email”. Главный агент анализирует запрос, понимает, что это касается управления контактами, и вызывает только Contact Manager (агент 53). Ticket Manager (агент 52) даже не задействуется. Contact Manager использует свои специализированные тулы Get Contact Info и Update Contact, выполняет задачу и возвращает результат главному агенту.

Подход 2: Работа через тулы + JSON-выход (action-output routing)

Суть: Агент получает вход, вызывает нужные тулы (поиск, базы, HTTP-запросы и т.д.), затем формирует структурированный JSON, содержащий ответ и инструкции для дальнейших действий: reply, create_ticket, escalate, assign, priority и т.д. Далее платформа маршрутизирует действия на основе этого JSON. Для этого в агентах и существует JSON output или JSON Schema - это опция, которая позволяет ограничить поведение агента, задать чёткие ожидания и валидировать результат.

Плюсы:

  • JSON-вывод гарантирует стабильную структуру ответа и исключает своевольные отклонения от сценария.
  • Высокая прозрачность и предсказуемость.
  • Легкий дебаг и логирование.
  • Более простое масштабирование

Минусы:

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

Пример кейса (скриншот выше): Кастомер саппорт бот с JSON-выходом и маршрутизацией:

У агента только тулы для анализа:

  • Get Contact - получить данные клиента
  • Documentation - поиск в документации

Операционные действия выполняются платформой после агента:

  • Create Ticket, Update Contact, Update Ticket - отдельные узлы

Клиент пишет “хочу сменить email”. Агент анализирует ситуацию и возвращает JSON:

{
  "reply": "Понял, меняю ваш email",
  "action": "update_contact", 
  "field": "email",
  "value": "[email protected]"
}

Платформа маршрутизирует запрос на узел “Update Contact”, который выполняет обновление и отправляет ответ клиенту.

Сценарий берет этот JSON и автоматически выполняет нужные действия: создаёт тикет, логирует, отправляет ответ, присваивает команду и т.д. В этом случае агент выполнил только “умственную работу”, а механическую часть - весь остальной сценарий.

Когда лучше использовать JSON-выход?

  • Когда бизнес-логика выходит за рамки “ответа в чат”.
  • Когда критична структурированность и предсказуемость вывода - JSON позволяет это обеспечить.
  • Когда нужно управлять назначением, эскалациями, статусами, тикетами.
  • Когда важны прозрачность, логирование, валидация.

Комбинированный подход

Можно оставить часть логики внутри агента (вызовы тулов), но вынести финальное решение (действие) наружу - через JSON. Это даёт баланс между “интеллектом” агента и контролем платформы.

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

Это:

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

Также важно понимать: если агенту требуется действовать гибко, на фристайле - например, свободно исследовать проблему, делать промежуточные выводы, обращаться к различным источникам - тогда можно и нужно использовать toolcalls. Но если агент выполняет четко определённую бизнес-функцию, как “встроенный сотрудник” в систему, его поведение должно быть предсказуемым, а действия - структурированы. В таких случаях JSON-output будет предпочтительнее.

Заключение

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

Главное - научиться правильно делить ответственность: агент - думает, платформа - действует.

1 лайк

Спасибо! Очень полезно!

1 лайк