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

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

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

Почему один агент на всё плохо масштабируется

Самая частая ошибка в начале AI-внедрения — сделать одного агента, который «умеет всё». Он читает сообщения, выбирает действие, ходит в CRM, пишет клиенту, создаёт задачи, обновляет файлы, помнит правила, проверяет себя и ещё объясняет, что произошло. Для прототипа это выглядит быстро. Для рабочей системы это почти всегда тупик.

Проблема не в том, что модель слабая. Проблема в том, что смешиваются разные виды ответственности. Принять решение, выполнить действие и проверить результат — это разные роли. Если они находятся в одном месте, становится трудно ответить на простые вопросы:

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

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

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

Оркестратор: не «главный ум», а диспетчер процесса

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

В простом виде оркестратор отвечает на вопросы:

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

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

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

Такой подход хорошо сочетается с идеей из статьи про провайдеры и клиенты AI-системы: внешний канал не должен диктовать внутреннюю архитектуру. Telegram, почта или CLI — это разные входы, но внутри система должна работать по единому протоколу.

Инструменты: маленькие действия с понятным контрактом

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

Чем меньше в инструменте «творчества», тем лучше. Инструменту не нужно рассуждать о стратегии. Ему нужен контракт:

  • какие входные данные он принимает;
  • что именно он имеет право сделать;
  • какой результат возвращает;
  • какие ошибки возможны;
  • можно ли безопасно повторить вызов;
  • что он пишет в журнал.

Если инструмент может удалить данные, отправить сообщение наружу, изменить права или опубликовать материал, его контракт должен быть ещё уже. В таких местах полезны режимы dry-run, подтверждения, allowlist, проверка статуса до и после действия, запрет на массовые операции без явного основания.

Главный принцип: языковая модель не должна «придумывать», как безопасно выполнить опасное действие. Опасное действие должно быть оформлено как инструмент с заранее заданными границами. Тогда исполнитель может попросить инструмент сделать работу, но не может выйти за его рамки.

В инструментальном ядре я разделяю tools, skills, интеграционные прослойки и LLM-провайдера. Tools ближе всего к коду и API. Skills задают способ работы: порядок действий, ограничения, типовые ошибки. Интеграционный слой подключает внешние сервисы через управляемый интерфейс. Модель важна, но она не должна быть архитектурой. В статье «Как выбрать LLM для бизнеса» я отдельно разбираю, почему выбор модели вторичен по отношению к процессу, контексту и проверке результата.

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

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

Я не люблю проектировать исполнителей как «умный помощник для всего». Гораздо практичнее делать узкие роли:

  • редактор черновика;
  • аналитик источников;
  • агент технической проверки;
  • классификатор входящих сообщений;
  • помощник поддержки;
  • агент подготовки отчёта;
  • verifier, который ищет ошибки в результате.

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

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

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

Артефакты: память, которая не живёт в голове агента

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

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

Без артефактов AI-система вынуждена каждый раз заново «вспоминать» правила из длинной истории. Это хрупко: история может обрезаться, инструкция может устареть, договорённость может потеряться. Артефакт делает знание переносимым. Узкий агент не обязан знать всю историю проекта. Ему достаточно получить нужные правила, источник, критерии проверки и прошлые решения.

Как разделить ответственность на практике

Когда я проектирую AI-контур, сначала описываю не модели и не инструменты, а ответственность.

Событие — это причина запуска: сообщение человека, cron, webhook, новая запись, файл, изменение статуса, команда из CLI. Провайдер или клиент принимает событие и приводит его к внутреннему формату.

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

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

Внешнее действие делает инструмент. Не агент «как-нибудь отправляет письмо», а конкретный инструмент отправки письма принимает адрес, тему, текст, режим подтверждения и возвращает статус. Так проще контролировать безопасность: исполнитель может подготовить действие, но не выполнять его без отдельного подтверждения.

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

Типовые ошибки при разделении слоёв

Ошибка 1. Оркестратор превращается в склад инструкций

Если в оркестратор складывать все правила подряд, он быстро станет самым сложным и самым опасным местом системы. Лучше держать в нём маршруты, состояния и границы, а предметные правила выносить в skills, артефакты и отдельных исполнителей.

Ошибка 2. Инструменты получают слишком широкие права

Инструмент «выполни команду» удобен для прототипа, но опасен как постоянный интерфейс. Рабочий инструмент должен быть уже: «прочитай файл», «проверь сборку», «создай задачу», «получи запись». Чем точнее контракт, тем легче ограничить действие.

Ошибка 3. Исполнитель сам выбирает себе роль

Если агенту написали «будь полезным и реши задачу», он будет пытаться решать слишком широко. Роль должна быть задана снаружи: что можно делать, какие источники читать, какие инструменты использовать, когда остановиться.

Ошибка 4. Проверка смешана с генерацией

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

Практический сценарий: подготовка экспертной статьи

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

  1. Провайдер или cron создаёт событие: есть плановая тема и локальный источник.
  2. Оркестратор открывает рабочую сессию и проверяет условия: slug свободен, источник существует, целевой каталог доступен.
  3. Оркестратор подбирает артефакты: правила автора, память проекта, существующие статьи для внутренних ссылок, требования к frontmatter.
  4. Исполнитель-редактор пишет черновик от первого лица, использует только разрешённые факты и не выдумывает опыт.
  5. Инструменты проверяют файл: frontmatter, внутренние ссылки, кавычки, отсутствие служебных маркеров, сборку сайта.
  6. Verifier или человек смотрит, можно ли материал выпускать наружу.
  7. Если проверка не пройдена, система не публикует «почти готово», а возвращает понятную причину остановки.

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

Чек-лист перед сборкой AI-системы

Перед тем как подключать модели и инструменты, я прохожу короткий чек-лист.

  • Есть ли список событий, которые запускают систему?
  • Понятно ли, где заканчивается внешний провайдер и начинается внутренняя сессия?
  • Есть ли отдельный оркестратор маршрута, а не один агент «на всё»?
  • Разделены ли исполнители по ролям и зонам ответственности?
  • У каждого инструмента есть узкий контракт, ошибки и правила повторного запуска?
  • Опасные действия требуют подтверждения или отдельного безопасного механизма?
  • Долгосрочные правила и результаты вынесены в артефакты?
  • Проверка результата отделена от генерации?
  • Для публичных и приватных сессий разные права доступа?
  • При недоступном источнике, модели или сервисе система останавливается понятным образом?

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

Для бизнеса это разница между демонстрацией и рабочим контуром. Демонстрация может впечатлить. Рабочий контур должен переживать ошибки, смену каналов, новые задачи и рост ответственности. Поэтому в серьёзных внедрениях я начинаю не с вопроса «какую модель выбрать», а с вопроса «кто здесь оркестрирует, кто исполняет и какой инструмент имеет право действовать».

Автор материала

Антон Ветров Разработка сайтов, поисковая доступность, автоматизация и эксплуатация.