Когда AI-проект начинается как быстрый прототип, плагинная архитектура обычно кажется лишней. Есть один канал, одна инструкция, одна модель, один скрипт, который что-то принимает и что-то отвечает. На этом этапе действительно можно обойтись без сложных слов.
Проблема появляется позже. К Telegram нужно добавить почту. Потом CRM. Потом расписание. Потом отдельного агента для отчётов. Потом память, права доступа, разные модели, внутренний дашборд и безопасный режим для внешних пользователей. Если всё это прикручивать напрямую к первому скрипту, система быстро превращается в набор исключений: здесь особый формат, там особый доступ, тут нельзя трогать старую функцию, потому что от неё зависит соседний сценарий.
Я поэтому смотрю на AI-систему как на микроядро с подключаемыми возможностями. Ядро отвечает за сессию, контекст, маршрутизацию и правила выполнения. Всё, что может меняться отдельно, становится плагином: провайдер, хранилище артефактов, инструмент, skill, адаптер модели или отдельный безопасный контур.
Что я называю плагинной архитектурой
Плагинная архитектура в AI-системе - это не каталог расширений ради красоты. Это способ удержать границы. У системы есть небольшое ядро, которое знает общий протокол работы, но не содержит всю бизнес-логику сразу.
В ядре остаются вещи, без которых система перестаёт быть системой:
- запуск и продолжение сессии;
- сбор контекста;
- выбор агента, модели или маршрута;
- проверка прав доступа;
- журналирование результата;
- единый способ подключать расширения.
В плагины уходят вещи, которые могут появляться, исчезать или заменяться:
- каналы входа и выхода;
- способы хранения памяти;
- инструменты для внешних сервисов;
- skills и процедуры;
- адаптеры к LLM;
- дополнительные проверки и фильтры.
Если провести параллель с обычной веб-разработкой, ядро похоже на каркас приложения, а плагины - на отдельные интеграции. Только в AI-системе плагин почти всегда влияет не только на код, но и на контекст. Он приносит данные, ограничения, инструкции или действие, которое модель может выполнить.
Почему без плагинов начинается хаос
Главная ошибка - считать, что новая возможность равна ещё одному куску кода рядом со старым. В обычной автоматизации это уже опасно, а в AI-системе особенно. Модель принимает решение на основе контекста, и если источники контекста смешаны без границ, поведение становится трудно объяснить.
Например, агент поддержки должен отвечать внешнему клиенту только по публичной базе знаний. Агент аналитики может читать внутренние отчёты. Если оба сценария используют один общий загрузчик памяти без уровня доступа, рано или поздно приватный фрагмент попадёт не туда. Это не проблема запроса. Это архитектурная ошибка.
Вторая ошибка - делать интеграции напрямую. Сегодня обработчик Telegram сам читает базу знаний, вызывает модель и пишет в CRM. Завтра появляется почта, и приходится копировать половину логики. Потом нужен вебхук, и копируется ещё кусок. Через несколько итераций уже непонятно, где на самом деле живёт правило квалификации лида: в запросе, в Telegram-обработчике, в CRM-инструменте или в отдельном файле.
Третья ошибка - хранить состояние «где получилось». Часть истории в чате, часть в файлах, часть в базе, часть в памяти процесса. Пока задач мало, это терпимо. Когда появляются автономные запуски, несколько агентов и повторные попытки после сбоев, такое хранение начинает ломать предсказуемость.
Плагинная архитектура не делает систему простой магически. Она заставляет заранее ответить на неприятные вопросы: кто имеет право принести данные в контекст, кто имеет право выполнить действие, где фиксируется результат и что произойдёт при ошибке.
Микроядро: что должно быть в центре
Ядро я стараюсь держать скучным. Чем больше умных исключений живёт в ядре, тем тяжелее добавлять плагины. Хорошее ядро не знает, как устроен Telegram, как называется поле в CRM и какой формат у конкретного отчёта. Оно знает контракты.
Условно ядро должно уметь ответить на несколько вопросов:
- какая сессия сейчас выполняется;
- кто инициатор запроса;
- какой тип доступа разрешён;
- какие плагины можно подключить в этом контуре;
- какие артефакты релевантны;
- каким инструментам можно доверять;
- какой результат нужно сохранить.
Это хорошо стыкуется с 4-слойной архитектурой AI-систем: внешний слой приносит событие, сессия держит историю, артефакты дают долгую память, инструменты и модели выполняют работу. Плагины в такой схеме не спорят за власть, потому что у каждого слоя своя ответственность.
Провайдеры: каналы как заменяемые адаптеры
Провайдер - это адаптер к внешнему миру. Telegram, почта, CRM-событие, календарь, форма на сайте или cron-задача могут выглядеть совершенно по-разному снаружи, но внутри системы они должны превращаться в единый формат запроса.
Для меня хороший провайдер делает четыре вещи:
- принимает событие из внешнего сервиса;
- нормализует его в понятный системе формат;
- добавляет технические метаданные;
- передаёт запрос в сессию, а не решает задачу сам.
Это важная граница. Провайдер не должен становиться маленькой копией всей AI-системы. Он не должен сам решать, какие внутренние отчёты подмешивать, какую модель выбрать и можно ли писать в CRM. Он только переводит язык внешнего канала на язык ядра.
Подробнее я разбираю этот слой в статье про провайдеры и клиенты AI-системы. Здесь принцип один: новый канал должен добавляться как новый адаптер, а не как новая версия всей системы.
Артефакты: память тоже должна быть плагином
AI-система без памяти быстро упирается в потолок. Но память нельзя превращать в одну общую папку, откуда всё подмешивается всем. Артефакты должны иметь тип, происхождение, уровень доступа и срок полезности.
В одном проекте достаточно Markdown-файлов: заметки, отчёты, планы, правила. В другом нужно векторное хранилище для поиска по большой базе знаний. В третьем полезна SQL-база для структурированных событий и отчётности. Иногда нужен гибрид: файлы для понятных человеку документов, база для операций, векторное хранилище для семантического поиска.
Если хранение оформлено как плагин, ядро не зависит от конкретной реализации. Оно запрашивает релевантные артефакты по контракту, а не лезет руками в файловую структуру или таблицы. Поэтому можно начать с простого хранения, а потом заменить или дополнить его без переписывания агентов.
Эта тема тесно связана с артефактами как долгосрочной памятью AI-агента. Практически это означает: любой результат, который может понадобиться завтра, должен сохраняться в понятном слое памяти, а не оставаться только в истории ответа модели.
Tools, skills и MCP: возможности без вседоступности
Инструменты - самая рискованная часть AI-системы. Прочитать файл, отправить письмо, создать задачу, изменить карточку в CRM, запустить сборку, сходить во внешний API - всё это реальные действия. Если дать модели один большой набор инструментов без границ, получится не архитектура, а вера в аккуратность.
Я предпочитаю разделять инструменты по плагинам и контурам доступа. Один плагин отвечает за чтение CRM. Другой - за запись. Третий - за поиск по базе знаний. Четвёртый - за работу с файлами. У каждого есть контракт, разрешения, ожидаемый результат и поведение при ошибке.
Skills в этой логике - тоже плагины, только не обязательно кодовые. Это инструкции, процедуры и правила выполнения задач. Например, skill может описывать, как готовить SEO-статью, как проверять безопасность, как проводить аудит интерфейса или как работать с конкретным проектом. Ядро не должно зашивать эти правила внутрь себя. Оно должно уметь подключить нужную процедуру в нужной сессии.
MCP и похожие протоколы подключения внешних инструментов удобно рассматривать так же: не как «магический доступ ко всему», а как ещё один тип плагина с явным списком возможностей. Чем сильнее инструмент, тем строже должны быть контур, журналирование и подтверждение опасных действий.
Безопасность: публичные и приватные контуры
Плагинная архитектура особенно полезна в безопасности. Не потому что плагин сам по себе безопасен, а потому что он даёт место, где можно повесить правила.
Я разделяю как минимум два режима:
- приватный контур для внутренних задач, где агент может работать с рабочими данными;
- публичный контур для внешних пользователей, где доступны только явно разрешённые источники и действия.
Разница должна быть не в просьбе к модели «будь осторожнее», а в составе доступных плагинов. Публичная сессия не должна видеть приватное хранилище. Внешний чат-бот не должен иметь инструмент отправки писем от имени компании, если это не предусмотрено отдельным сценарием с подтверждением. Агент, который отвечает посетителю сайта, не должен иметь тот же набор прав, что внутренний агент поддержки.
Эта логика продолжает тему безопасности AI-агентов через приватные и публичные сессии. Хорошее правило простое: если действие страшно случайно выполнить руками, агент не должен получать его без отдельного ограничителя.
Контекст-инжиниринг как причина, почему всё это работает
В AI-системах архитектура нужна не ради схем. Она нужна ради качественного контекста. Модель отвечает не на «реальность», а на то, что ей дали на вход. Если контекст собран случайно, ответ будет случайным даже на сильной модели.
Плагины помогают собирать контекст слоями:
- провайдер приносит событие и метаданные;
- сессия добавляет историю;
- skill добавляет процедуру;
- артефакты добавляют долговременную память;
- tools добавляют проверяемые данные и действия;
- маршрутизатор выбирает модель или режим выполнения.
Такой подход я отдельно описываю в статье про контекст-инжиниринг. Суть в том, что качество ответа определяется не только моделью, а тем, насколько аккуратно система сформировала вход.
Плагинная архитектура делает этот процесс управляемым. Когда появляется новый источник данных, я не подмешиваю его «куда-нибудь в запрос». Я решаю, какой это тип плагина, в каких сессиях он доступен, какие данные отдаёт, как помечает происхождение и что делать, если источник недоступен.
Как добавлять новую возможность без хаоса
Допустим, в системе уже есть Telegram-агент, а теперь нужно добавить почтовый канал. Плохой путь - скопировать Telegram-обработчик, заменить входящие данные на письма и оставить всю остальную логику внутри. Быстрый запуск получится, но дальше начнутся расхождения.
Нормальный путь начинается с вопроса: что именно добавляется?
Если это новый канал, нужен провайдер. Если новый способ помнить данные - storage-плагин. Если новое действие - tool. Если новая инструкция - skill. Если новый режим доступа - отдельный контур с ограниченным набором плагинов. Если новая модель - LLM-адаптер и правила маршрутизации.
После этого я проверяю контракт:
- что плагин принимает на вход;
- что возвращает;
- какие ошибки возможны;
- какие права нужны;
- какие данные он имеет право отдавать в контекст;
- где будет журналироваться его работа;
- как отключить плагин без остановки всей системы.
Только после этого имеет смысл писать код или подключать готовый инструмент. Иначе новая возможность станет не расширением, а ещё одной скрытой зависимостью.
Типовые ошибки, которые я проверяю до разработки
Перед добавлением плагина я прохожу короткий список неприятных вопросов.
Первая ошибка - плагин знает слишком много. Например, почтовый провайдер не только принимает письма, но и сам решает, какой агент должен отвечать, какие документы подгрузить и можно ли создать сделку. Это уже не провайдер, а монолит внутри монолита.
Вторая ошибка - нет режима отказа. CRM недоступна, векторное хранилище не отвечает, модель вернула ошибку, календарь не принял событие. Система должна понимать, где можно продолжить с пометкой, а где нужно остановиться.
Третья ошибка - нет идемпотентности. Если задача повторилась после сбоя, плагин не должен создать два одинаковых письма, две сделки или два отчёта. Для действий с внешними системами это критично.
Четвёртая ошибка - нет явной границы доступа. Плагин подключили в приватной сессии, потом случайно дали публичной. Если доступы описаны только в голове разработчика, это вопрос времени.
Пятая ошибка - нет наблюдаемости. Плагин вроде бы работает, но непонятно, какие данные он взял, какой результат вернул и почему агент принял именно такое решение. В AI-системе это быстро становится проблемой доверия.
Практический чек-лист подключения плагина
Я бы подключал новую возможность так:
- Определить тип: провайдер, tool, skill, хранилище, модель, проверка или отдельный контур.
- Описать контракт: вход, выход, ошибки, ограничения, формат результата.
- Назначить уровень доступа: публичный, приватный, служебный или отдельный специальный режим.
- Решить, попадает ли результат в контекст, в память, в журнал или только возвращается вызывающему шагу.
- Описать отказоустойчивость: что делать при недоступности источника, таймауте, пустом ответе и частичном успехе.
- Добавить защиту от дублей для действий, которые меняют внешнее состояние.
- Проверить отключение: система должна пережить выключенный плагин, если он не является обязательным для конкретного сценария.
- Прогнать два сценария: штатный и нештатный. Нештатный важнее, потому что именно он показывает, где спрятан хаос.
Для бизнес-задач такая архитектура особенно полезна в проектах уровня проектирования AI-архитектуры и AI First трансформации. Там редко бывает один вечный сценарий. Обычно система растёт: новые каналы, роли, источники данных, проверки и ограничения появляются уже после первого запуска.
Плагинная архитектура не обещает, что любую возможность можно добавить за пять минут. Она обещает другое: новая возможность будет добавляться в понятное место, с понятными правами и понятными последствиями. Для AI-систем это важнее скорости первого прототипа, потому что хаотичный прототип почти всегда приходится переписывать в тот момент, когда он наконец стал полезным.