Когда мы начали встраивать AI-агента в BPM-платформу, перед нами встала знакомая enterprise-задача: десятки клиентов, у каждого своя онтология, словарь, роли и ограничения безопасности. В одной компании «заявка на покупку» — это «реестр заявок», в другой — «карточкой закупки». Один клиент работает на изолированном контуре с локальной моделью, другой не даёт ассистенту доступ к почте и репозиториям.
Традиционный ответ — форк репозитория под каждого клиента — при масштабировании превращается в ад поддержки: багфиксы не попадают автоматически, стоимость растёт экспоненциально, качество падает. Мы решили эту проблему иначе: per-tenant overlay позволяет кастомизировать поведение агента без изменения кода.
Что такое overlay
Overlay — это конфигурация, которая загружается после базовой и переопределяет её значения. Это похоже на CSS-override для веб-страниц: есть базовый стиль, а поверх него можно добавить свои правила, которые меняют цвет, шрифт или отступы, не трогая саму разметку. В нашем случае базовая конфигурация описывает стандартное поведение AI-агента для production-версии, а overlay клиента меняет то, что нужно именно ему.
Процесс загрузки выглядит так. Сначала система загружает базовую конфигурацию из продакшна. Затем подгружается слой с подстройкой под конкретного клиента. При конфликте значений побеждает overlay. Полученная runtime-конфигурация используется для обработки всех запросов на этом стенде. Код остаётся неизменным, меняются только данные — промпты, словари, маршрутизация, параметры модели.
Точки расширения
Мы выделили четыре точки расширения, которые покрывают 90% кастомизаций, необходимых клиентам. Эти границы позволяют менять поведение агента без изменения логики кода.
Первая точка — persona_paths. Это конфигурация соответствия функциональных областей и файлов с промптами. В production-версии агент может использовать стандартные промпты для проектного управления, HR и финансов. На клиентском стенде можно переопределить пути к этим файлам, чтобы использовать кастомные промпты, учитывающие терминологию и специфику клиента. Например, вместо базового промпта для проектного менеджера загружается файл с описанием процессов и терминологии конкретной организации.
{
"crm": [
"clients/{client}/boxes/crm/persona-sales.md", // Кастомная экспертиза для CRM
"boxes/crm/persona-analytics.md" // Стандартная экспертиза
]
}Пример подмены промпта на кастомный уже на клиентской инсталляции
Вторая точка — root_section_map. Это маршрутизатор запросов по категориям. Когда пользователь задаёт вопрос, система определяет, к какой функциональной области он относится, и направляет его в соответствующую «коробку». В production-версии конфигурация может содержать несколько десятков записей: «управление проектами» идёт в коробку pm, «подбор персонала» — в hr, «бюджетирование» — в finance.
{
"sales": "crm", // Категория «Продажи» → коробка CRM
"clients": "crm", // Категория «Клиенты» → коробка CRM
"meetings": "crm", // Категория «Встречи» → коробка CRM
"proposals": "library" // Категория «Коммерческие предложения» → Библиотека
} Пример маршрутизации категории
На крупном клиентском стенде конфигурация может содержать несколько тысяч записей, каждая из которых переопределяет маршрутизацию под терминологию клиента.
Третья точка — disabled_toolsets. Список инструментальных наборов, которые недоступны на площадке. Базовый набор включает десять наборов:
поиск по коду,
работа с почтой,
веб-поиск,
продажи,
персональные утилиты,
локальные MCP-серверы,
контейнеры,
интеграция с 1С,
доступ к данным,
работа с персонами.
На клиентском стенде можно отключить всё, что не соответствует требованиям безопасности или не нужно пользователю. Например, один из наших клиентов отключил восемь из десяти наборов, оставив только доступ к данным и работу с пользователями, а также Диадок через root_section_map. Это превратило многофункционального агента в специализированный ассистент для работы с документооборотом.
Четвёртая точка — model_config. Параметры модели, которые можно переопределить под клиента: провайдер, размер контекстного окна, алиас модели. В production-версии по умолчанию используется облачный провайдер вроде OpenAI с определённым контекстным окном. На клиентском стенде можно переключиться на локальный вывод, увеличить или уменьшить контекст, использовать собственную модель вместо стандартной.
Как это работает на практике
Рассмотрим конкретный пример. Наш клиент — крупная организация с чувствительными данными, которая категорически не позволяет отправлять информацию за периметр. У компании собственный инфраструктурный контур с мощными вычислительными ресурсами и развёрнутая локальная модель.
Overlay-конфигурация для этого клиента выглядит так:
В
persona_pathsпрописаны пути к кастомным промптам для проектного управления, HR, финансов и документооборота.В
root_section_mapдобавлены маршрутизации для тысяч терминов, которые используются внутри организации.В
disabled_toolsetsперечислены восемь наборов инструментов, которые нужно отключить.В
model_configуказан провайдерlocal-inference, увеличенный контекст и алиас кастомной модели.
Роутер берёт ID категории вопроса, находит его в конфигурации из 3000 записей и направляет в нужную коробку. Затем через persona_paths выбирается промпт — сначала система ищет кастомный файл в директории клиента, а если его нет, использует базовый. Далее фильтруется набор инструментов и финально переопределяются параметры модели.
Как бороться с расхождениями
Главный риск кастомизации — клиентский стенд постепенно расходится с production и перестаёт принимать обновления. Чтобы этого не произошло, мы контролируем метрики совпадения кодовой базы по хэшу SHA-256. Из основных модулей агента на клиентском стенде 95% файлов полностью совпадают с production-версией. Только три файла имеют намеренные расхождения, и каждое такое изменение закреплено в deploy-tool как патч.
При запуске агента система загружает базовые настройки из ядра, затем — overlay клиента, и объединяет их. Для полей-объектов значения из overlay перезаписывают базовые, для полей-массивов — объединяются, а для вложенных параметров модели работает частичное переопределение. Промпты загружаются через запасные варианты: сначала система ищет кастомный файл по пути из overlay, а если не находит — берёт базовый из ядра.
Процесс деплоя при выпуске новой версии выглядит так: копируется production-код, применяется overlay клиента (конфигурация, промпты, патчи), запускается health-check. При следующем обновлении production свежий код автоматически подтягивается на все клиентские стенды — overlay накладывается поверх новой базовой версии.
Патчи, которые не помещаются в overlay, используются крайне редко и только по обоснованным причинам: критический багфикс, который нельзя отложить до следующего релиза, или уникальная интеграция. Каждый патч привязан к клиенту, задокументирован и не должен блокировать доставку production-обновлений.
Что можно и что нельзя менять
Через этот дополнительный слой клиент может переопределять промпты, настраивать маршрутизацию запросов, отключать инструменты по требованиям безопасности, менять параметры модели. Это покрывает подавляющее большинство потребностей в кастомизации.
Через патчи, которые применяются только по согласованию, можно вносить критические улучшения и уникальные интеграции. Патчи используются редко, тщательно документируются и не должны блокировать доставку production-обновлений.
Нельзя менять логику роутера, добавлять новые точки расширения, менять протоколы MCP или вносить изменения, которые мешают автоматическому обновлению. Эти границы чётко определены и доведены до клиентов. Если клиенту нужно что-то за пределами этих границ, это рассматривается как изменение в production-версии, которое получат все.
Метрики и roadmap
Сейчас мы работаем с десятками клиентских стендов. Среднее время деплоя на клиентский стенд не превышает пяти минут, а доставка production-обновлений автоматизирована полностью.
Per-tenant overlay позволяет одной кодовой базе работать на десятках клиентских площадок. Он закрывает 90% потребностей enterprise-кастомизации. Результат: клиент получает адаптированного ассистента, мы поддерживаем единый продукт.