Введение: ловушка универсального AI-агента
Типичный путь развития AI-ассистента выглядит как гонка вооружений. Начинается всё с простого чата: модель отвечает на вопросы, опираясь на внутренние знания. Потом появляется первый инструмент - поиск по документам. За ним второй - календарь. Третий - CRM. Через полгода ассистент размахивает списком из полусотни инструментов и выглядит внушительно на слайдах для инвесторов.
В production-среде эта внушительность оборачивается проблемами. Команда monday.com прошла этот путь со своим AI-ассистентом Sidekick и публично признала: рост числа инструментов привёл к ухудшению выбора нужного действия, кратному росту стоимости каждого запроса, увеличению задержек и кошмару отладки. Модель, вынужденная держать в контексте описания десятков инструментов, всё чаще ошибалась - и цена каждой ошибки измерялась реальными деньгами и пользовательским разочарованием.
Решение, к которому пришли в monday.com - модульная архитектура с чётким разделением ответственности. Центральный оркестратор, специализированные субагенты, инструменты с ограниченным доступом и песочницы для сложной работы с данными и кодом. Этот кейс - практическое руководство для команд, которые хотят перевести ассистента от прототипа к надёжной production-системе, не утонув в сложности.
Подход monday.com перекликается с более широким трендом: переход от AI-ассистентов к AI-агентам меняет не только архитектуру, но и роли в командах разработки. Платформенный подход к оркестрации становится обязательным для тех, кто планирует масштабироваться.
Проблемы монолитного агента: когда инструментов становится слишком много
Монолитный агент с большим набором инструментов страдает от трёх взаимосвязанных проблем. Первая - деградация качества выбора. Вторая - скрытые финансовые издержки. Третья - экспоненциальный рост сложности отладки. Команда monday.com столкнулась со всеми тремя на практике, когда Sidekick перешагнул отметку в 20-30 доступных инструментов.
Симптомы проявлялись постепенно. Сначала ассистент начал вызывать не те инструменты для очевидных задач. Затем время ответа выросло с сотен миллисекунд до нескольких секунд. Счета за API поползли вверх. Инженеры тратили часы, пытаясь понять, почему модель выбрала конкретный путь выполнения. Каждый новый инструмент, добавленный для расширения возможностей, парадоксальным образом сужал реальную применимость системы.
Почему LLM ошибается с выбором инструмента: когнитивная перегрузка модели
LLM не «понимает» инструменты - она предсказывает наиболее вероятную последовательность токенов на основе контекста. Когда в системном промпте перечислены 50 инструментов с детальными описаниями параметров, модель вынуждена распределять ограниченное внимание между всеми кандидатами. Механизм attention, который должен фокусироваться на релевантной информации, размывается.
Инженеры monday.com наблюдали классическую картину: модель уверенно выбирала неправильный инструмент для задачи, потому что описание этого инструмента имело поверхностное лексическое сходство с запросом пользователя. Запрос «покажи статус проекта» активировал инструмент для генерации отчётов, а не быстрый lookup по API. Причина проста: в контексте было слишком много кандидатов, и модель цеплялась за ближайший семантический паттерн, а не за правильный.
Эта проблема усугубляется с ростом контекстного окна. Модели вроде Claude или GPT-4 технически способны обработать 100+ тысяч токенов, но качество внимания на длинных дистанциях падает. Инструменты, описанные в середине промпта, получают меньше «фокуса», чем те, что в начале или конце. Порядок перечисления начинает влиять на поведение - и это превращает конфигурацию агента в хрупкий артефакт, который боится любых изменений.
Скрытые издержки: как каждый лишний инструмент увеличивает счет за API
Каждый вызов LLM с полным списком инструментов потребляет токены, даже если 95% инструментов не будут использованы в текущем запросе. При 50 инструментах со средним описанием в 200 токенов каждый, только системный промпт с инструментами съедает 10 000 токенов входного контекста. Умножьте на тысячи запросов в день - и получите счёт, который мог бы быть на порядок меньше.
В monday.com зафиксировали, что стоимость одного запроса выросла кратно при переходе от 10 к 30 инструментам. Парадокс: добавление инструментов для экономии времени пользователей увеличивало операционные расходы настолько, что unit-экономика ассистента становилась отрицательной для части клиентских сценариев. Команда, которая раньше разбирала production-архитектуру AI-агентов на Amazon Bedrock, хорошо знала цену каждого вызова.
Задержки росли пропорционально токенам. Модель тратила время на обработку описаний всех инструментов перед тем, как сгенерировать первый релевантный токен. Для пользователя, ожидающего быстрого ответа, задержка в 3-5 секунд вместо 500 миллисекунд - это разница между «работает» и «тормозит». В production-среде такие задержки напрямую влияют на retention.
Новая архитектура: разделение ответственности как ключевой принцип
Команда monday.com перешла от монолита к системе, где каждый компонент имеет чётко ограниченную зону ответственности. Центральный оркестратор понимает намерение пользователя и делегирует задачу. Субагенты выполняют специализированную работу, имея доступ только к релевантным инструментам. Инструменты с ограниченным доступом замыкают цепочку на уровне конкретных операций.
Ключевой архитектурный сдвиг: оркестратор не содержит полного списка всех инструментов системы. Он оперирует на уровне абстракций - «работа с документами», «анализ данных», «коммуникации». Это радикально сокращает его контекст и повышает точность маршрутизации. Когда оркестратор определил домен, он передаёт управление субагенту, который уже работает с конкретными инструментами в своей узкой области.
Такой подход перекликается с идеей, которую мы разбирали в статье про архитектуру самописного AI-агента: оркестрация LLM, память и инструменты требуют продуманного разделения на слои. Без этого даже хорошо спроектированный агент превращается в непредсказуемую систему.
Оркестратор: дирижер, а не исполнитель
Оркестратор в архитектуре Sidekick решает одну задачу: классифицировать запрос пользователя и выбрать подходящий субагент или легковесный инструмент. Он не анализирует данные, не генерирует код, не работает с файлами. Его промпт содержит только описания доступных субагентов и критерии выбора - обычно 5-7 вариантов вместо 50 инструментов.
Пример из практики monday.com: пользователь пишет «покажи динамику продаж за последний квартал и сравни с планом». Оркестратор определяет, что это задача анализа данных, и передаёт её субагенту-аналитику. Сам оркестратор не знает, какие конкретно инструменты будет использовать аналитик - ему достаточно понимать, что домен определён верно. Если пользователь следом спросит «а отправь этот график команде в Slack», оркестратор поймёт смену домена и подключит субагента для коммуникаций.
Оркестратор остаётся простым и предсказуемым. Его поведение легко тестировать: подали на вход запрос - получили метку домена. Никакой сложной бизнес-логики, никаких многошаговых рассуждений. Именно эта простота делает его надёжным фундаментом системы.
Субагенты: эксперты в своей узкой области
Каждый субагент в системе monday.com имеет доступ только к 3-5 инструментам, релевантным его домену. Субагент для работы с документами знает про поиск, чтение, создание и редактирование файлов. Субагент для анализа данных - про запуск запросов, построение графиков, агрегацию. Субагент для коммуникаций - про отправку сообщений, создание встреч, управление уведомлениями.
Специализация резко повышает точность выбора инструментов. Когда у модели перед глазами 5 вариантов вместо 50, вероятность правильного вызова приближается к 100%. Стоимость каждого вызова падает: системный промпт субагента с 5 инструментами потребляет 1 000 токенов вместо 10 000. Задержки сокращаются пропорционально.
Отладка становится осмысленной. Инженер, расследуя неправильное поведение, сразу знает, какой субагент отработал запрос, и может проанализировать его конкретный контекст. Логи перестают быть месивом из полусотни возможных путей выполнения и превращаются в читаемую последовательность: оркестратор выбрал субагента X, субагент X вызвал инструменты Y и Z, результат возвращён пользователю.
Песочницы: ключевой примитив для сложной работы с данными и кодом
Инструменты хороши для атомарных операций: получить запись, отправить сообщение, создать задачу. Но для задач, требующих многошаговых рассуждений, итеративной обработки данных или выполнения кода, инструментов недостаточно. Команда monday.com пришла к выводу, что песочницы - изолированные среды выполнения - должны быть самостоятельным архитектурным примитивом, а не просто ещё одним инструментом.
Песочница предоставляет субагенту безопасное пространство, где можно запускать код на Python, обрабатывать CSV-файлы, строить графики, выполнять сложные вычисления. Субагент работает итеративно: написал код - выполнил - посмотрел на результат - скорректировал - выполнил снова. Весь этот процесс происходит внутри песочницы, не засоряя основной контекст диалога с пользователем. Пользователь видит только финальный результат.
Песочницы стали критическим компонентом для аналитических сценариев Sidekick. Без них анализ данных превращался в последовательность вызовов инструментов, где каждый шаг требовал отдельного обращения к LLM, а промежуточные результаты передавались через контекст. С песочницей субагент получает данные, загружает их в среду выполнения и работает автономно, возвращая только готовый ответ.
Когда инструмента недостаточно: примеры задач для песочниц
Типичный сценарий из практики monday.com: пользователь загружает CSV с данными о продажах за год и просит «найди аномалии и построй график тренда». Инструментальный подход потребовал бы цепочки вызовов: прочитать файл, распарсить, вычислить статистики, определить выбросы, сгенерировать код для графика, выполнить его где-то ещё. Каждый шаг - отдельный вызов LLM с передачей контекста.
В песочнице субагент получает файл, пишет Python-скрипт для анализа, запускает его, видит результат, при необходимости корректирует и запускает снова. LLM вызывается только для генерации кода и интерпретации результатов. Количество обращений к модели сокращается в 5-10 раз. Время выполнения падает с десятков секунд до нескольких.
Другой пример: генерация и тестирование кода для автоматизации. Субагент может написать скрипт, запустить его в песочнице, увидеть ошибку, исправить и перезапустить - и так до получения рабочего результата. Без песочницы каждый цикл «написал-проверил» требовал бы внешнего выполнения и ручной передачи результата обратно в контекст.
Безопасность и контроль: как песочницы предотвращают хаос
Песочница в архитектуре monday.com - это управляемая среда с жёсткими ограничениями. Лимит по времени выполнения: скрипт, который работает дольше 30 секунд, принудительно завершается. Лимит по памяти: доступно фиксированное количество, достаточное для аналитических задач, но недостаточное для злоупотребления. Сетевой доступ ограничен белым списком разрешённых эндпоинтов.
Изоляция означает, что даже если субагент сгенерирует проблемный код, он не повлияет на основную систему. Песочница откатывается после каждого выполнения. Логи всех запусков сохраняются для аудита. Инженеры monday.com могут в любой момент посмотреть, какой код был выполнен, с какими данными и каким результатом.
Воспроизводимость - ещё одно преимущество. Одинаковый входной код и данные всегда дают одинаковый результат. Это упрощает отладку: инженер может взять конкретный запрос пользователя, воспроизвести выполнение в песочнице и пошагово пройти весь путь субагента. В монолитной архитектуре с россыпью инструментов такая воспроизводимость была недостижима.
Принятие решений: когда использовать инструмент, субагента или песочницу?
Практический фреймворк, который просматривается в решениях команды monday.com, сводится к трём вопросам. Первый: насколько атомарна операция? Если ответ требует одного вызова API и не предполагает рассуждений - достаточно инструмента. Второй: требуется ли многошаговое рассуждение с выбором между несколькими действиями? Если да - нужен субагент. Третий: включает ли задача выполнение кода, обработку файлов или итеративную работу с данными? Тогда обязательна песочница.
Границы не всегда жёсткие. Запрос «покажи статус задачи №1234» - это инструмент, прямой вызов API. Запрос «подготовь сводку по проекту за неделю» - субагент, который вызовет несколько инструментов, агрегирует данные и сформулирует ответ. Запрос «проанализируй этот CSV и построй прогноз на следующий квартал» - субагент с песочницей, где выполнится код анализа и визуализации.
Матрица решений: инструмент vs субагент vs песочница
Обобщим критерии выбора в практическую матрицу. Для атомарных операций чтения или записи - используйте инструмент. Стоимость минимальна, задержка минимальна, отладка тривиальна. Для задач, требующих координации нескольких инструментов с промежуточной логикой - делегируйте субагенту. Он справится с выбором последовательности действий и обработкой промежуточных результатов. Для задач с выполнением кода, анализом данных, работой с файлами - запускайте песочницу внутри субагента. Это изолирует риски и радикально сокращает число обращений к LLM.
Пример из практики: пользователь просит «создай задачу для команды с результатами последнего отчёта». Оркестратор видит два домена - анализ данных и управление задачами. Он может последовательно вызвать субагента-аналитика для извлечения данных из отчёта, а затем субагента для управления задачами с передачей полученных результатов. Каждый субагент использует свои инструменты. Оркестратор координирует поток данных между ними.
Эта модель радикально отличается от подхода «один агент со всеми инструментами», где модель должна была одновременно понять структуру отчёта, извлечь данные и правильно заполнить поля задачи - удерживая в контексте описания всех инструментов для всех возможных операций.
Уроки monday.com: как перевести AI-ассистента от прототипа к production
Главный инженерный урок от команды monday.com: архитектурные решения, принятые на стадии прототипа, определяют потолок масштабируемости системы. Монолитный агент с плоским списком инструментов работает на демо, но ломается под реальной нагрузкой. Модульная архитектура требует больше инвестиций на старте, но окупается предсказуемостью, отлаживаемостью и контролируемой стоимостью.
Второй урок: песочницы - не опциональный компонент, а обязательный примитив для любого ассистента, который работает с данными. Попытка эмулировать аналитические возможности через цепочки инструментов приводит к взрывному росту стоимости и задержек. Изолированная среда выполнения с итеративной работой субагента - единственный известный способ решить эту проблему в production.
Третий урок: безопасность нельзя прикручивать потом. Ограничение доступа инструментов, изоляция песочниц, аудит выполнения - эти механизмы должны быть в архитектуре с первого дня production-развёртывания. Команда monday.com, имеющая опыт построения production AI-агентов с Guardrails и confidence-scored auto-merge, закладывала эти принципы сразу.
С чего начать: дорожная карта внедрения модульной архитектуры
Первый шаг - аудит текущих инструментов. Выпишите все инструменты, которые использует ассистент, и сгруппируйте их по доменам. Вы увидите естественные кластеры: работа с документами, коммуникации, аналитика, управление задачами. Каждый кластер - кандидат на выделение в отдельного субагента.
Второй шаг - реализация простого оркестратора. Начните с классификатора, который определяет домен запроса. Не добавляйте сложную логику маршрутизации - просто направляйте запрос в нужный домен. Используйте легковесную модель для классификации, чтобы минимизировать стоимость и задержки.
Третий шаг - выделение одного субагента с ограниченным набором инструментов. Сравните метрики до и после: точность выбора инструментов, стоимость запроса, время ответа. Результаты обычно говорят сами за себя. Четвёртый шаг - внедрение песочниц для аналитических сценариев. Начните с самых дорогих или медленных запросов - именно там эффект будет максимальным.
Итеративный подход критически важен. Команда monday.com не переписывала Sidekick с нуля - они постепенно выделяли субагентов, отлаживали оркестратор и внедряли песочницы, на каждом шаге проверяя метрики. Статья про побочный продукт ИИ-агента хорошо иллюстрирует, что ценность часто обнаруживается не там, где планировалось - итеративный процесс позволяет поймать эти инсайты.
Заключение: меньше значит лучше, когда речь идет об архитектуре AI
Рост числа инструментов не делает ассистента умнее. Он делает его дороже, медленнее и непредсказуемее. Команда monday.com подтвердила это на практике и предложила работающую альтернативу: модульную архитектуру, где оркестратор координирует специализированных субагентов, а песочницы берут на себя сложную работу с данными и кодом.
Ключевой принцип - разделение ответственности. Оркестратор не исполняет, субагенты не координируют, инструменты не рассуждают. Каждый компонент делает одну задачу и делает её хорошо. Результат: точность выбора действий приближается к 100%, стоимость запроса падает кратно, задержки сокращаются, отладка становится осмысленной.
Для команд, которые строят AI-ассистентов сегодня, вывод однозначен: не бойтесь дробить агентов. Инвестируйте в оркестрацию на старте. Внедряйте песочницы до того, как аналитические сценарии начнут разрушать unit-экономику. Опыт monday.com показывает, что модульная архитектура - это способ перевести ассистента от прототипа к надёжной production-системе, которая работает стабильно и предсказуемо масштабируется.