В рамках проектирования 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, базами и командами.