Архитектура платформы строится как слоистая среда, в которой каждый слой отвечает за свою часть работы и взаимодействует с соседними через контролируемые интерфейсы. Наверху находятся сотрудники, которые разговаривают со своими ИИ-Напарниками через корпоративный мессенджер. Напарники координируют функциональных агентов, у каждого из которых свои инструменты, свои данные и свои ограничения. Под ними лежит инфраструктура данных и инструментов, доступная агентам через управляемые коннекторы. Всё обёрнуто в слой безопасности, аудита и governance, который работает на уровне платформы, а не на уровне инструкций модели.
Главная идея архитектуры состоит в том, что безопасность, изоляция и контроль встроены в конструкцию, а не добавлены поверх неё. Агент получает только те инструменты, которые ему явно выданы. Данные менеджера A недоступны Напарнику менеджера B. Критические действия проходят через подтверждение человека. Каждое действие каждого агента логируется и аудируется. Эти свойства не зависят от того, что написано в инструкциях модели, потому что они реализованы на уровне платформы.
Эти принципы прошиты в каждый слой архитектуры. Они работают как ограничения при проектировании новых агентов, интеграций и сценариев. Если конкретное архитектурное решение противоречит любому из них, нужно либо найти другой способ, либо сознательно зафиксировать исключение и его обоснование.
Безопасность по умолчанию
Новый агент по умолчанию не умеет ничего. Каждое право (чтение данных, запись, отправка сообщений, обращение к другим агентам) выдаётся явно. Это принцип least privilege. Агент видит только то, что ему нужно для работы, и ничего больше.
Изоляция контекстов
Данные одного сотрудника недоступны Напарнику другого, кроме случаев явной межагентской коммуникации по управляемой политике. Сессии, память, файлы и credentials изолированы на уровне агента и сессии.
Платформенный контроль
Инструментальные политики (какие инструменты доступны агенту), Tier-модель автономии (какие действия требуют подтверждения человека) и правила межагентского взаимодействия (кто кому может писать) работают на уровне платформы. Никакая модификация промпта не может их обойти.
Аудируемость
Каждый ход (turn) каждого агента логируется. Каждое обращение к данным содержит ссылку на источник. Любое действие любого агента можно воспроизвести по журналу. Audit trail встроен в архитектуру и не является опцией.
Vendor-neutral
LLM-провайдер, агентный runtime, мессенджер, хранилище данных, MCP-коннекторы рассматриваются как заменяемые компоненты. Конкретный выбор делается под ИТ-политику и инфраструктуру заказчика. Архитектура не завязана на единственного вендора.
Постепенное наращивание
Платформа проектируется так, чтобы можно было начать с минимального контура (один Напарник, два-три функциональных агента, одна интеграция) и наращивать без перестройки. Добавление нового агента, нового коннектора или нового Напарника представляет собой операцию конфигурации, а не проект архитектурной переработки.
Платформа состоит из девяти слоёв. Они расположены от пользователя (сверху) к данным и инфраструктуре (внизу). Каждый слой решает свою задачу, и взаимодействие между слоями проходит через определённые интерфейсы.
┌──────────────────────────────────────────────────────────────────────┐│ СЛОЙ 1. ПОЛЬЗОВАТЕЛЬСКИЙ СЛОЙ ││ Сотрудники: категорийные менеджеры, логисты, прайс-менеджеры, ... ││ Канал: корпоративный мессенджер (мобильный + десктоп) │└────────────────────────────────┬─────────────────────────────────────┘ │┌────────────────────────────────▼─────────────────────────────────────┐│ СЛОЙ 2. ИИ-НАПАРНИКОВ ││ По одному персональному агенту на сотрудника ││ Персональный контекст, оркестрация, проактивность │└────────────────────────────────┬─────────────────────────────────────┘ │┌────────────────────────────────▼─────────────────────────────────────┐│ СЛОЙ 3. ОРКЕСТРАЦИИ ││ Делегирование задач, параллельный запуск, синтез результатов, ││ управление сессиями, A2A-коммуникация между Напарниками │└────────────────────────────────┬─────────────────────────────────────┘ │┌────────────────────────────────▼─────────────────────────────────────┐│ СЛОЙ 4. ФУНКЦИОНАЛЬНЫХ АГЕНТОВ ││ Специализированные исполнители: аналитика, переговоры, OOS, ││ промо, встречи, Text2SQL, алерты, базы знаний │└────────────────────────────────┬─────────────────────────────────────┘ │┌────────────────────────────────▼─────────────────────────────────────┐│ СЛОЙ 5. ПАМЯТИ И КОНТЕКСТА ││ Личная память Напарника, корпоративная база знаний, ││ коллективная память команды │└────────────────────────────────┬─────────────────────────────────────┘ │┌────────────────────────────────▼─────────────────────────────────────┐│ СЛОЙ 6. ИНСТРУМЕНТОВ И СКИЛЛОВ ││ Встроенные и плагинные инструменты по группам, ││ скиллы (инструкции по использованию инструментов), ││ команды и workflow │└────────────────────────────────┬─────────────────────────────────────┘ │┌────────────────────────────────▼─────────────────────────────────────┐│ СЛОЙ 7. ИНТЕГРАЦИЙ ││ MCP-коннекторы, API-интеграции, RAG, event-шины, ││ инструментальные политики │└────────────────────────────────┬─────────────────────────────────────┘ │┌────────────────────────────────▼─────────────────────────────────────┐│ СЛОЙ 8. ДАННЫХ ││ DWH, BI, ERP, WMS, CRM, почта, календарь, внешние источники, ││ семантические модели и метаданные │└──────────────────────────────────────────────────────────────────────┘
╔══════════════════════════════════════════════════════════════════════╗║ СЛОЙ 9. НАБЛЮДАЕМОСТИ И КОНТРОЛЯ (сквозной, пронизывает все слои) ║║ Безопасность, governance, audit trail, мониторинг, ║║ Tier-модель автономии, инструментальные политики ║╚══════════════════════════════════════════════════════════════════════╝Сотрудник общается с платформой через корпоративный мессенджер с мобильной и десктопной версиями. Это может быть Telegram, MAX, eXpress, Mattermost или другой инструмент, допустимый ИТ-политикой заказчика. Мессенджер остаётся основным каналом, потому что менеджер и без платформы проводит в мессенджере значительную часть дня, и порог входа в этом случае стремится к нулю.
Веб-интерфейс и дашборды добавляются позже, под конкретные сценарии с длинными аналитическими артефактами, визуализациями и интерактивными досками. Голосовой канал (ассистент на переговорах) рассматривается как отдельный сценарий в 04-usecases.
В мессенджере сотрудник видит не только собственный диалог с Напарником. Через тот же канал приходят уведомления о действиях, которые инициированы межнапарниковой коммуникацией. Например, когда Напарник коллеги попросил собрать статусы по промо или согласовал с другим Напарником слот для встречи, в мессенджере появляется короткое сообщение с описанием того, что произошло и где в этом процессе требуется явное подтверждение сотрудника. Этот канал работает как единый интерфейс ко всему, что Напарник делает от имени человека и что другие Напарники делают по обращению к нему.
У каждого сотрудника в мессенджере свой бот (или свой DM-канал), и все сообщения из него маршрутизируются к его персональному Напарнику. Конкретный механизм маршрутизации (правила привязки источников к агентам, приоритеты, межканальные сценарии) разобран в «Открытые архитектурные вопросы» как часть routing topology под конкретного заказчика.
Каждый сотрудник работает с одним персональным Напарником. Это полноценный изолированный агент со своей рабочей директорией, своей памятью, своими credentials и своей историей сессий. Пользовательская модель Напарника подробно описана в 02-partner.
С точки зрения архитектуры у каждого Напарника есть рабочая директория с файлами личности (инструкции по роли и зоне ответственности, профиль сотрудника, стиль коммуникации, оперативная память), хранилище сессий с историей всех диалогов, изолированные credentials (профили доступа к корпоративным системам в рамках прав конкретного сотрудника) и набор инструментов для оркестрации, межагентской коммуникации, работы с памятью, уведомлений и расписания.
Напарник не имеет прямого доступа к корпоративному хранилищу. Все обращения к данным идут через функциональных агентов, у каждого из которых свои ограничения. Это не просто удобство архитектуры, это граница безопасности. Напарник оркеструет, но сам по себе не может написать произвольный SQL или прочитать произвольную таблицу.
Оркестрация охватывает механизм, через который Напарник координирует работу функциональных агентов и общается с Напарниками коллег. Подробнее этот слой описан в разделах «Модель взаимодействия агентов» и «Оркестрация задач».
Два основных механизма оркестрации. Первый механизм называется делегированием. Напарник порождает изолированную задачу для функционального агента, агент работает асинхронно, результат доставляется обратно. Можно запустить несколько агентов параллельно. Второй механизм представляет межагентская коммуникация. Напарник одного сотрудника обращается к Напарнику другого сотрудника с конкретным запросом. Это управляется через явный белый список (кто кому может писать и по каким поводам) на уровне платформы.
Функциональные агенты представляют собой специализированных исполнителей. Каждый закрывает один класс задач. Это может быть факторный анализ, Text2SQL, поиск по регламентам, подготовка досье на поставщика, мониторинг аномалий. Подробный каталог агентов и принципы их проектирования описаны в 03-agents.
В архитектурном плане функциональный агент представляет собой отдельную сущность, у которой есть своя рабочая директория, своя инструментальная политика и свой набор доступных данных. Один экземпляр функционального агента используется всеми Напарниками в системе, но каждый вызов изолирован в отдельной сессии. Контексты разных вызовов не пересекаются.
Функциональный агент вызывается Напарником через механизм делегирования. Напарник порождает для агента изолированную задачу с конкретными параметрами (период, регион, категория, набор гипотез). Агент работает асинхронно, не блокируя Напарника. По завершении результат возвращается Напарнику для синтеза. Несколько агентов могут работать параллельно, и Напарник ждёт все результаты, прежде чем собрать ответ для сотрудника.
Память платформы устроена в три слоя. Подробнее она разобрана в разделе «Память и контекст».
Корпоративная база знаний хранит регламенты, стандарты, прецеденты и аналитические отчёты. Этот слой курируется людьми и служит источником истины для формальных правил и накопленного опыта. Личная память Напарника накапливает историю диалогов и решений конкретного сотрудника. Сюда входят поправки, стиль формулировок, активные переговоры и профили контрагентов. Она изолирована от других сотрудников. Коллективная память содержит обезличенные паттерны успешных решений, выявленные на масштабе команды. Наполняется через куратора.
Этот слой описывает, какие действия доступны агентам и как агенты обучены ими пользоваться. Подробно инструменты и скиллы разобраны в разделах «Инструменты агентов» и «Скиллы».
Каждый инструмент подключается один раз и используется всеми агентами в рамках их прав. Это позволяет наращивать каталог интеграций без переделки агентов. Новый коннектор к WMS добавляется в слой инструментов, и все агенты, которым он нужен, получают к нему доступ по инструментальной политике.
Интеграционный слой обеспечивает подключение к корпоративным системам через MCP-коннекторы, API и event-шины. Подробно этот слой разобран в 06-integrations.
Корпоративные данные остаются в корпоративных системах. Платформа не дублирует хранилище, не создаёт собственный Data Lake и не перемещает данные в свой периметр. Вместо этого агенты обращаются к данным через инструменты (MCP-коннекторы, API, RAG), и каждое такое обращение проходит через инструментальную политику.
Это архитектурное решение важно для compliance. Данные не покидают тот периметр, в котором они были до появления платформы. Если хранилище стоит on-premise, то и запросы к нему идут on-premise. Если доступ к хранилищу идёт через VPN или корпоративный шлюз, платформа использует тот же маршрут.
Источники данных удобно разделить на четыре группы. У каждой свой темп обновления, свои паттерны доступа и своя роль в работе агентов.
Аналитический слой
DWH, BI, аналитические витрины, семантические модели. Источник аналитической фактуры. К нему обращаются Text2SQL, агент факторного анализа, агент промо, агент финансового эффекта. Доступ как правило read-only, через коннекторы и семантические модели.
Операционные системы
ERP, WMS, TMS, системы ценообразования, промо-планирования, документооборота. Источник фактов о текущей операционной картине. Здесь живут поставки, остатки, договоры, цены и фактические даты прихода. К ним обращаются агент OOS, агент переговоров, агент ассортимента. Запись в эти системы по умолчанию закрыта и идёт только под Tier 2.
Коммуникационный контекст
Корпоративный мессенджер, почта, календарь, таск-трекер. Источник того, что происходит вокруг сотрудника прямо сейчас. К ним обращаются Напарник и агент встреч и follow-up. Чувствительная зона по compliance, потому что здесь часто лежат персональные данные и переписка с внешними контрагентами.
Документы и регламенты
Корпоративная база знаний, регламенты, стандарты, прецеденты, аналитические отчёты, инструкции. Подключаются через RAG-индекс или семантический поиск. К ним обращаются агент базы знаний, агент регламентов, агент переговоров (за прецедентами). Сюда же относятся внешние источники, такие как индексы цен и публичные отчёты.
В реальном внедрении эти группы редко покрываются одинаково. Аналитический слой обычно зрелый, а семантический ещё нет. Операционные системы хорошо описаны, но сложные по правам. Коммуникационный контекст требует отдельной проработки compliance. Документы и регламенты часто разбросаны по нескольким системам, и RAG приходится собирать поверх неоднородного хранения. Эту картину важно держать в голове на пресейле, потому что от стартовой зрелости конкретной группы зависит, какие сценарии и какие агенты входят в первый этап пилота. Подробный список систем, протоколов и интеграционных паттернов разобран в 06-integrations.
Отдельного внимания заслуживает семантический слой. Агентам нужна не только сырая таблица, но и понимание её бизнес-смысла. Подробнее эта тема разобрана в разделе «Семантический слой данных».
Этот слой не стоит отдельным уровнем. Он пронизывает все остальные и обеспечивает безопасность, governance, аудит и мониторинг. Подробно разобран в разделах «Безопасность и права доступа», «Governance мультиагентной среды», «Audit trail и журналирование действий», «Observability и мониторинг».
Инструменты охватывают всё, что агент может делать помимо генерации текста. Каждый инструмент соответствует конкретному действию (прочитать файл, выполнить запрос к базе данных, отправить сообщение, запустить субагента). Агент получает только те инструменты, которые ему разрешены через инструментальную политику.
Инструменты делятся на встроенные (доступны сразу при создании агента) и плагинные (устанавливаются дополнительно под конкретные задачи). Для удобства конфигурации они сгруппированы в четыре профиля (full, coding, messaging, minimal). Каждый профиль определяет базовый набор, который потом дополнительно сужается или расширяется для конкретного агента.
В контексте retail-платформы инструменты делятся на следующие категории.
Работа с данными. Инструменты для чтения данных из корпоративных систем. Сюда входят запросы к DWH, обращения к API ERP и WMS, поиск по RAG-индексу корпоративной базы знаний. Большинство аналитических агентов работают только с этой группой.
Файловая работа и память. Чтение и запись файлов в рабочей директории агента, семантический поиск и чтение из памяти. Используются Напарниками для хранения заметок, профилей контрагентов и истории решений.
Оркестрация. Порождение субагентов, отправка сообщений другим агентам, просмотр истории сессий, ожидание результатов от параллельных задач. Основная группа для Напарников.
Исполнение кода. Запуск произвольных команд и скриптов, управление фоновыми процессами. Используется в Text2SQL агентах и сценариях с вычислениями.
Веб. Поиск и чтение веб-страниц. Актуально для агентов мониторинга внешней среды. Сюда входят новости о поставщиках, индексы цен, публичные отчёты.
Обмен сообщениями. Отправка сообщений во все подключённые каналы. Используется агентами алертов для уведомления Напарников.
Медиа и UI. Анализ изображений, генерация визуальных материалов, управление браузером для автоматизации веб-интерфейсов. Подключаются дополнительно под специализированные сценарии.
Планирование и управление платформой. Запуск задач по расписанию, управление конфигурацией платформы. Доступны служебным агентам с соответствующими правами.
Каждый агент в каталоге (03-agents) получает строго ограниченный набор инструментов. Аналитический агент работает только с инструментами чтения данных. Напарник добавляет к ним оркестрацию и память, но не получает прямого доступа к DWH.
Скилл (skill) представляет собой файл с инструкциями, который платформа автоматически добавляет в системный контекст агента. Скиллы учат агента когда и как использовать инструменты, какие форматы ответов предпочтительны в конкретных ситуациях, как интерпретировать специфические данные или ситуации.
Скиллы работают на трёх уровнях, и при конфликте имён побеждает более специфичный уровень.
Встроенные скиллы поставляются вместе с платформой и покрывают базовые паттерны работы (как структурировать ответ, как ссылаться на источник, как обращаться с внешним контентом). Общие скиллы (shared) доступны всем агентам на платформе и создаются командой внедрения под специфику компании. Индивидуальные скиллы создаются для конкретного агента и живут в его рабочей директории.
В retail-платформе скиллы быстро становятся одним из главных способов передачи знания между агентами и сотрудниками. Несколько типичных примеров.
Скилл методологии
Общий скилл «как считать каннибализацию промо» с фиксированной формулой, перечнем источников и правилами интерпретации. Используется агентом промо, агентом финансового эффекта, агентом ассортимента. Раньше эта методология жила в головах двух-трёх аналитиков, после оформления в скилл становится общей для всей платформы.
Скилл предметной области
Общий скилл «как выглядит хорошая диагностическая карточка факторного анализа» с примерами оформления, обязательными разделами (главный вывод, доказательная база, отвергнутые гипотезы, следующий шаг) и стандартом ссылок на источники. Применяется агентом факторного анализа во всех вызовах от любого Напарника.
Скилл конкретного сотрудника
Индивидуальный скилл Напарника категорийного менеджера с его предпочитаемым форматом отчётов, специфическими правилами работы с конкретным пулом поставщиков, типичной длиной ответов. Сюда же ложатся «не дёргай меня по отклонениям меньше 5%» и «при подготовке к комитету сразу добавляй разрез по конкуренту».
Скилл организационного стандарта
Общий скилл с правилами компании (например, «при упоминании любой цифры по марже всегда даём разрез до и после промо» или «при подготовке досье поставщика всегда подсвечиваем долю SKU в категории»). Этот слой обеспечивает методологическую дисциплину на уровне всей сети, а не отдельного менеджера.
Жизненный цикл скилла напоминает жизненный цикл агента. Сначала паттерн появляется в работе одного агента или Напарника как удачное решение. Дальше его описывают и оформляют как индивидуальный скилл. Если паттерн воспроизводимый и применим шире, после валидации куратора он переходит в общий слой и становится доступен всей платформе. Это один из главных механизмов накопления коллективной экспертизы, и он подробно разобран в разделе «Память и контекст».
Основная модель взаимодействия с Напарником остаётся диалоговой. Сотрудник пишет обычным языком, Напарник распознаёт ситуацию и собирает ответ. Так живут все сценарии в 04-usecases и пользовательская модель в 02-partner. Поверх диалога платформа поддерживает два дополнительных механизма для повторяющихся операций, у которых уже сложилась устойчивая форма.
Текстовые команды начинаются с / и обрабатываются платформой напрямую, минуя языковую модель. Они работают мгновенно и не расходуют токены. Например, /статус показывает активные задачи Напарника, /брифинг генерирует утренний обзор, /переговоры Saverio запускает сбор досье по конкретному поставщику. Это удобно для операций, которые менеджер делает каждое утро или несколько раз в день. Команды никогда не заменяют диалог. Если у сотрудника есть нестандартный вопрос, он формулирует его обычным языком, как и раньше.
Программируемые workflow позволяют описать многошаговый процесс как детерминированную последовательность с контрольными точками. Это не диалог с моделью, а заранее заданный сценарий. Агент выполняет шаги по порядку, в нужных местах останавливается и ждёт подтверждения от сотрудника. Workflow хорошо подходят для стандартных операций, где важна предсказуемость. Например, процедура подготовки к квартальным переговорам включает сбор данных, проверку досье, формирование повестки и финальное согласование с менеджером. Workflow также удобны там, где конкретный сценарий должен исполняться одинаково у всех менеджеров (например, чтобы методология подготовки к ассортиментному комитету не расползалась по людям).
Сырые данные из хранилища сами по себе мало полезны агентам без понимания их бизнес-смысла. Агент, который не знает, что avg_fill_rate_30d означает средний уровень выполнения заявок за 30 дней в разрезе поставщика, не сможет правильно интерпретировать аномалию в этой метрике.
Семантический слой решает эту проблему. Он включает несколько видов информации.
Дата-каталог содержит описание витрин данных. Там указано, что в них хранится, как таблицы связаны друг с другом, какие поля актуальны для каких задач. Если дата-каталог ведётся в корпоративном хранилище, агенты могут обращаться к нему напрямую. Если нет, платформа поддерживает собственный реестр семантических моделей.
Корпоративный словарь бизнес-терминов фиксирует, что значит «выполнение заявок», «промо-акция», «каннибализация», «чистый прирост» в контексте конкретной компании. Без этого слоя разные агенты могут интерпретировать одни и те же термины по-разному.
Описание метрик и KPI объясняет, как именно считается каждый ключевой показатель. Зафиксированы источники (таблицы, периоды, правила отбора). Это критично для агентов факторного анализа и Text2SQL.
На практике поддержание семантического слоя в актуальном состоянии вырастает в отдельную операционную задачу. Платформа поддерживает служебных агентов, которые берут эту работу на себя. Агент семантического слоя следит за изменениями в структуре хранилища и обновляет описания витрин. Агент корпоративного словаря помогает вести и пополнять глоссарий. Оба работают как фоновые сервисы и не требуют ручного участия при каждом изменении схемы.
Семантический слой не существует сам по себе, он подключается через тот же интеграционный контур, через который агенты ходят в DWH и BI. На практике это либо отдельный коннектор к корпоративному дата-каталогу (например, DataHub, Amundsen, Atlan), либо собственный реестр платформы, синхронизируемый с источниками. Конкретные интеграционные паттерны и приоритеты подключения семантического слоя в первой версии MVP разбираются в 06-integrations.
Субагент представляет собой технический способ запустить агента в одноразовой изолированной сессии. Это не отдельный класс сущностей рядом с Напарником и функциональными агентами, а механизм исполнения, поверх которого реализуется Вариант A из раздела «Механики вызова функциональных агентов».
Когда Напарнику нужен функциональный агент для разовой задачи (факторный разбор, подготовка досье, расчёт финансового эффекта), платформа порождает субагент с профилем нужного функционального агента. Субагент получает ту же инструментальную политику и тот же набор инструкций, что и постоянный экземпляр этого агента, но живёт ровно столько, сколько нужно для выполнения одного задания. После завершения он возвращает результат инициатору через механизм announce и автоматически архивируется.
Субагент работает в урезанном контексте. Он не получает личность инициатора и историю его диалогов, только задание и рабочие инструкции. Это намеренное ограничение. Субагент должен качественно закрыть свою предметную задачу, а не вести диалог.
Это форма исполнения удобна там, где важны изоляция и предсказуемая стоимость. Каждый разовый разбор это отдельный контекст, и он не загрязняет историю предыдущих вызовов. Параллельная оркестрация (Напарник запускает несколько субагентов одновременно для разных частей одной ситуации) тоже хорошо ложится на эту форму. Для субагентов как правило используется более экономичная языковая модель, поскольку их задачи обычно хорошо определены и не требуют сложных рассуждений.
Альтернатива (Вариант B, обращение к постоянному экземпляру функционального агента) подходит тем агентам, у которых есть собственное накопленное состояние. Например, агент алертов держит историю аномалий, агент коллективной памяти накапливает знания команды. Их важно вызывать как постоянные сессии, а не пересоздавать при каждом обращении. Выбор между формами делается архитектурно при проектировании конкретного агента, а не на каждом вызове.
Агенты в платформе взаимодействуют по нескольким типовым паттернам. Каждый паттерн решает свой класс задач и имеет свои правила безопасности.
Основной паттерн. Напарник получает ситуацию от сотрудника и делегирует её функциональному агенту (или нескольким). Каждая делегированная задача запускается в изолированной сессии. Агент получает конкретное задание с параметрами, работает асинхронно, возвращает результат.
Когда ситуация требует нескольких агентов, Напарник запускает их параллельно. Напарник может вызвать sessions_yield(), чтобы гарантированно дождаться результатов от всех запущенных задач. Результаты доставляются через механизм announce. После получения всех ответов Напарник синтезирует итог для сотрудника.
Сотрудник: «Почему упала молочка в Сибири?» │Напарник │ ├── → Агент факторного анализа (период, регион, категория) ── параллельно ├── → Агент OOS (SLA, поставки) ── параллельно │ [sessions_yield: ждём оба результата] └── ← Результаты: факторная карточка + данные по SLA │ └── → Синтез + следующий шаг → сотрудникуДля подготовки к переговорам Напарник может запустить четыре-пять агентов одновременно.
Напарник (подготовка к переговорам) │ ├── → Агент переговоров (досье поставщика) ── параллельно ├── → Агент финансового эффекта (сценарии) ── параллельно ├── → Агент OOS (SLA и недопоставки) ── параллельно ├── → Агент базы знаний (прецеденты) ── параллельно │ [sessions_yield: ждём все четыре] └── ← Четыре результата → синтез → сотрудникуПлатформа ограничивает максимальное количество параллельных задач на одного Напарника и глобально. Обычно это до пяти задач на одного Напарника и до десяти глобально. Этот лимит предотвращает неконтролируемое размножение задач (fan-out) и защищает бюджет токенов.
Ключевое свойство делегирования состоит в том, что контексты вызовов изолированы. Агент факторного анализа, вызванный Напарником менеджера A, не видит контекст вызова от Напарника менеджера B. Это обеспечивается тем, что каждый вызов порождает отдельную сессию со своим ключом.
Напарник может задействовать функционального агента двумя способами.
Вариант A связан с порождением субагента с профилем функционального агента. Напарник порождает временного субагента, который получает инструкции и инструментальную политику нужного функционального агента. Субагент живёт только пока выполняет задачу. После завершения он архивируется, и никакого состояния не остаётся. Этот вариант подходит для разовых аналитических запросов, где важна изоляция и контроль стоимости.
Вариант B строится на обращении к постоянному агенту. Напарник отправляет сообщение в постоянную сессию функционального агента. Агент отвечает в контексте своей накопленной истории. Этот вариант подходит для агентов с собственным состоянием. Например, агент алертов держит историю аномалий, а агент коллективной памяти накапливает знания команды. Их важно вызывать как постоянные сессии, а не пересоздавать при каждом обращении.
Напарники разных сотрудников могут обращаться друг к другу с конкретными запросами. Это управляется через явный белый список на уровне платформы.
Напарник менеджера A: «Собери статусы по промо у коллег» │ ├── → Напарник менеджера B: «Статус промо Q2 по кондитерке?» ├── → Напарник менеджера C: «Статус промо Q2 по молочке?» │ ├── ← Напарник B: «Акция запущена, ROI +12%, каннибализация 8%» ├── ← Напарник C: «Акция перенесена на июль, бюджет утверждён» │ └── Синтез → менеджеру AA2A-коммуникация по умолчанию выключена. Включается явно и содержит белый список допустимых пар. Функциональные агенты в A2A-список не входят. Они работают только через делегирование от Напарника.
Та же механика используется для согласования совместных действий, а не только для запроса данных. Например, при постановке межфункциональной встречи Напарник инициатора обращается к Напарникам приглашённых, те проверяют у своих сотрудников предпочтения по слотам и накладывают свободные окна в календаре, между собой согласуют общий слот, ставят встречу и каждый готовит своему сотруднику бриф под её повестку. Со стороны людей это выглядит как одно сообщение «договорились на четверг 15:00», без переписки на троих и без человеческой обвязки. Подробный сюжет такого сценария разобран в 04-usecases, раздел «Межфункциональная встреча через Напарников». Архитектурно он реализуется на тех же механизмах, что описаны выше. A2A с белым списком пар, календарь как инструмент с правом read+book, явное подтверждение от каждого сотрудника на постановку встречи в его календаре.
Часть работы выполняется без запроса от сотрудника. Планировщик (cron) по расписанию запускает агентов мониторинга. В их числе агенты алертов, аномалий и контроля договорённостей. При обнаружении значимого события результат передаётся Напарнику соответствующего сотрудника, и тот формулирует уведомление.
[Планировщик, каждые 2 часа] │Агент алертов ├── Запрос аномалий в хранилище ├── Проверка входящей почты │ ├── Обнаружена аномалия: -15% по кондитерке │ └── → Напарник менеджера: «⚠️ Аномалия: ...» │ └── Обнаружено письмо: срыв поставки └── → Напарник менеджера: «🔴 Критично: ...»Поддерживаются одноразовые запуски (по абсолютному времени), периодические (через интервал) и классические cron-выражения.
Сессия в контексте работы агента представляет собой контейнер для одного диалога, аналог ветки переписки. Напарник всегда работает в своей основной сессии, которая служит «домашним» диалогом с сотрудником. Задачи, запущенные по расписанию, могут выполняться в новых изолированных сессиях или передавать результаты прямо в основную сессию Напарника, в зависимости от настройки.
Любая задача в платформе проходит через стандартный жизненный цикл.
Инициация. Сотрудник формулирует ситуацию, или триггер (алерт, расписание, событие) запускает задачу автоматически.
Маршрутизация. Напарник определяет, какие функциональные агенты нужны, формулирует задание для каждого с конкретными параметрами.
Делегирование. Напарник порождает изолированные сессии для функциональных агентов. Агенты работают параллельно или последовательно, в зависимости от зависимостей между задачами.
Исполнение. Каждый функциональный агент выполняет свою работу. Он обращается к данным, считает, ищет, формирует структурированный ответ.
Синтез. Напарник получает результаты всех агентов и собирает единый ответ для сотрудника. Это именно синтез (главный вывод, доказательная база, следующий шаг), а не склейка трёх отчётов.
Доставка. Результат возвращается сотруднику в мессенджер. Если требуется действие (отправка письма, постановка задачи), Напарник предлагает его и ждёт подтверждения.
Обратная связь. Сотрудник может пометить результат как верный или неверный, уточнить или дополнить. Напарник запоминает поправку и учитывает её в следующий раз.
Для сложных задач платформа поддерживает иерархию глубиной два. Напарник порождает агента-оркестратора, который сам может запускать агентов-исполнителей. Результаты поднимаются обратно по цепочке. Исполнитель передаёт оркестратору, оркестратор Напарнику, а Напарник сотруднику.
Глубина вложенности ограничена платформой (типично максимум два уровня). Это сознательное решение. Глубокая иерархия создаёт проблемы с наблюдаемостью и контролем бюджета, а на практике двух уровней хватает для подавляющего большинства задач.
Каждый порождённый агент работает в изолированной сессии. Он получает конкретное задание с параметрами, доступ к инструментам в рамках своей инструментальной политики и рабочие инструкции (роль, специализация, формат ответа).
Он не получает историю диалога сотрудника с Напарником, данные других сотрудников, инструменты не предусмотренные его политикой и возможность порождать собственных агентов (кроме случаев многоуровневой оркестрации с явным разрешением).
Это свойство критично для безопасности. Функциональный агент не видит ничего лишнего, даже если модель, стоящая за ним, теоретически может интерпретировать более широкий контекст.
Память платформы решает три задачи одновременно. Она поддерживает персональный контекст каждого сотрудника, хранит организационное знание и обеспечивает преемственность при смене людей. Для этого она устроена в три слоя с разными правилами доступа, наполнения и жизненного цикла.
Курируемое людьми хранилище формализованного знания. Сюда входят регламенты, стандарты, переговорные прецеденты, аналитические отчёты и нормативные документы. Это слой read-only для агентов. Они могут искать и читать, но не могут вносить изменения напрямую.
Обновления в корпоративную базу знаний вносят ответственные сотрудники. Агент базы знаний обеспечивает поиск по ней (через RAG, семантический поиск или полнотекстовый индекс). Подробности интеграции описаны в 06-integrations.
У каждого Напарника есть собственное хранилище, в котором накапливается контекст конкретного сотрудника. Сюда попадают оперативные заметки (что на столе, какие дедлайны, какие переговоры активны), история решений (что делал в похожих ситуациях, какие поправки вносил к результатам агентов), профили контрагентов и коллег (стиль, чувствительные темы, прецеденты встреч) и предпочтения по коммуникации (как формулирует письма, какую длину ответов предпочитает).
Этот слой привязан к конкретному Напарнику и изолирован от других сотрудников. Когда Напарнику менеджера B нужны данные из контекста менеджера A, это идёт через межнапарниковую коммуникацию (A2A) с явным разрешением и видимым обменом.
Личная память подчиняется политике хранения. Данные, которые больше не нужны, архивируются или удаляются по расписанию. Политика согласовывается с compliance и зависит от типа данных. Оперативные заметки могут жить 90 дней, история решений хранится год, а профили контрагентов живут пока существует рабочее отношение.
Обезличенные паттерны успешных решений, выявленные на масштабе команды. Сюда попадают проверенные тактики переговоров, удачные диагностики, типовые решения в стандартных ситуациях. Этот слой не содержит персональных данных и не привязан к конкретному Напарнику.
Наполнение коллективной памяти требует внимания. Задача деликатная и нетривиальная. Платформа поддерживает три механизма, применимых в зависимости от зрелости организации и чувствительности данных.
Для низкорисковых операционных паттернов (типовые диагностики, форматы отчётов) агент коллективной памяти может искать повторяющиеся паттерны в сессиях разных Напарников, оценивать их по частоте и устойчивости и автоматически выносить в общий слой. Применимо там, где ошибочная публикация паттерна не создаёт коммерческого риска.
Для коммерчески значимых паттернов (тактики переговоров, нестандартные ходы). Агент предлагает кандидатов, человек-куратор валидирует. Куратор здесь есть роль в организации (например, руководитель направления), формально ответственный за качество коллективной памяти. Этот механизм уже работает в сценариях 04-usecases. Например, успешная переговорная тактика попадает в коллективную память после валидации куратора.
Для регламентов, стратегических решений и прецедентов. Полностью ручное ведение, аналогично корпоративной базе знаний, но с фокусом на паттерны и уроки, а не на формальные документы.
Профили поставщиков, контактных лиц и коллег занимают особое место в архитектуре памяти. Базово они лежат в личной памяти Напарника. Менеджер A видит поставщика через свои переговоры и в своём контексте. Менеджер B видит того же поставщика через свои. Автоматически склеивать эти наблюдения было бы ошибкой, потому что у разных менеджеров разный фокус и разный уровень отношений с поставщиком.
Менеджеры могут также строить и поддерживать собственные профили менеджеров, которые становятся доступны Напарникам коллег через механизм A2A. Это позволяет сотрудникам видеть зону ответственности друг друга, текущие приоритеты и предпочитаемые форматы коммуникации. Полезно при подготовке совместных переговоров или при передаче ведения переговоров другому менеджеру.
По мере зрелости платформы становится разумно наводить мост между личным и коллективным. Общие факты (fill rate, история контрактов, публичные данные) выносятся в коллективную память, а субъективные наблюдения (стиль переговоров, эмоциональные триггеры) остаются в личном слое. Этот мост требует отдельной проработки под конкретного заказчика и не включается автоматически.
Граница автономии агентов относится к числу ключевых архитектурных решений платформы. Она определяет, какие действия агент может делать сам, какие требуют подтверждения человека, и какие допускаются только после явного разрешения с отдельной санкцией.
Tier 1. Чтение и подготовка
Сбор данных, анализ, факторный разбор, подготовка черновиков писем, презентаций, досье. Разрешено по умолчанию. Никаких внешних эффектов. Всё, что делается на Tier 1, остаётся внутри платформы и не покидает её.
Tier 2. Действие после санкции
Отправка черновика по почте, изменение в учётной системе, бронирование встречи с внешним участником, постановка задачи коллеге. Каждое такое действие требует явного подтверждения сотрудника. Агент предлагает действие, сотрудник нажимает кнопку в мессенджере.
Tier 3. Автономные действия по правилам
Стандартные операции по расписанию или триггеру в заранее согласованных границах. Сюда входят утренние брифинги, контроль договорённостей, рутинные напоминания и стандартное переключение между РЦ при OOS ниже порога. Включается точечно, после периода доверия и согласования с compliance.
| Действие | Tier | Обоснование |
|---|---|---|
| Факторный разбор, аналитика, поиск | Tier 1 | Только чтение, без внешних эффектов |
| Подготовка черновика письма, досье | Tier 1 | Результат остаётся внутри платформы |
| Отправка письма от имени сотрудника | Tier 2 | Внешняя коммуникация, необратимо |
| Изменение данных в ERP/CRM | Tier 2 | Запись в учётную систему |
| Бронирование встречи с внешним участником | Tier 2 | Создаёт обязательство |
| Листинг/делистинг поставщика | Tier 2 | Коммерчески значимое, необратимое |
| Утренний брифинг | Tier 3 | Стандартная операция, согласована |
| Напоминание коллеге о дедлайне | Tier 3 | Внутренняя коммуникация, низкий риск |
| Стандартное переключение РЦ при OOS | Tier 3 | Согласованный сценарий с явными границами |
На пилоте рекомендуется начинать с Tier 1 и точечных Tier 2. Tier 3 включается после наработки доверия, и каждый конкретный Tier 3 сценарий согласовывается с compliance.
В корпоративном мессенджере подтверждение реализуется через inline-кнопки. Агент предлагает действие, показывает его содержание (например, текст письма, параметры задачи, суть изменения) и ждёт нажатия кнопки «Подтвердить» или «Отменить». Без подтверждения действие не выполняется.
Этот механизм работает на уровне платформы, а не на уровне инструкций модели. Даже если инструкции модели изменены или обойдены (например, через prompt injection), платформа не позволит выполнить Tier 2 действие без нажатия кнопки человеком.
Безопасность платформы строится на четырёх эшелонах доверия. Каждый эшелон работает независимо от остальных и не зависит от инструкций модели.
Доступ к платформе. Аутентификация сотрудника через корпоративную SSO/LDAP или через белый список в мессенджере. Каждый сотрудник может обращаться только к своему Напарнику. Посторонний пользователь не может послать сообщение боту без явного разрешения.
Изоляция данных между сотрудниками. Каждый Напарник работает в своей изолированной среде. Это означает собственную рабочую директорию, собственные credentials и собственную историю сессий. Данные менеджера A физически недоступны Напарнику менеджера B, за исключением явной межагентской коммуникации.
Инструментальные политики. Каждый агент получает доступ только к тем инструментам, которые ему нужны. Функциональные агенты обычно работают в режиме read-only. Запись, отправка, обращение к другим агентам выдаются отдельно. Политики работают на уровне платформы и действуют по принципу «каждый уровень может только сузить». Нижние уровни не могут восстановить доступ, закрытый выше.
Защита от внешнего контента. Данные из внешних источников (письма поставщиков, URL, ответы на запросы) оборачиваются в служебные теги и помечаются как недоверенные. Агент может анализировать их содержимое, но не может выполнять инструкции из них. Это особенно важно для агентов, работающих с почтой и внешним вебом.
Инструментальные политики определяют, какие инструменты доступны конкретному агенту. Они настраиваются на нескольких уровнях, и каждый уровень может только сузить набор. Сначала действует глобальная политика платформы, затем политика по провайдеру модели, потом политика конкретного агента, затем политика для порождённых субагентов и наконец политика для песочницы (sandbox).
Типичные политики для разных типов агентов
| Тип агента | Разрешено | Запрещено |
|---|---|---|
| Напарник | Оркестрация, межагентская коммуникация, память, уведомления, расписание | Прямой доступ к DWH, запись в системы, системное администрирование |
| Аналитический агент | Чтение данных (DWH, Text2SQL) | Запись, отправка сообщений, межагентская коммуникация, браузер |
| Агент переговоров | Чтение данных, поиск по базе знаний | Запись, отправка сообщений, администрирование |
| Агент алертов | Чтение данных, отправка уведомлений Напарнику | Запись в системы, браузер, администрирование |
Для функциональных агентов, которые выполняют произвольный код (например, Text2SQL с запуском SQL), платформа поддерживает исполнение в изолированном контейнере. Sandbox ограничивает среду выполнения. Агент не может выйти за пределы своего контейнера, прочитать файлы других агентов или обратиться к сервисам, не предусмотренным его политикой.
Режим sandbox настраивается по агенту и по сессии. Типичная конфигурация такова, что Напарники работают без sandbox (им нужен доступ к файлам личности и памяти), а функциональные агенты работают в sandbox.
Внешний контент (письма, ответы API, содержимое веб-страниц) оборачивается в XML-теги с пометкой «внешний контент» и предупреждением для модели. Это advisory-мера. Она снижает вероятность того, что модель выполнит инструкцию из внешнего содержимого, но не гарантирует этого на 100%.
Основная защита от prompt injection имеет архитектурную природу. Даже если модель интерпретирует внешние данные как инструкцию, инструментальные политики не позволят ей выполнить запрещённое действие. Агент, у которого нет права на запись, не сможет записать, что бы ни стояло во внешнем содержимом.
Governance отвечает на вопрос о том, кто и как управляет платформой, агентами и правилами их работы.
Администратор платформы
Управляет конфигурацией. Добавляет агентов, настраивает инструментальные политики, маршрутизацию, интеграции. Обычно это ИТ-команда заказчика совместно с командой внедрения.
Куратор организационной памяти
Валидирует паттерны перед публикацией в коллективную память. Обычно это руководитель направления или эксперт, ответственный за методологическое качество базы знаний.
Compliance-офицер
Согласует Tier 3 сценарии (автономные действия по правилам), проверяет политики хранения данных, контролирует доступ к audit trail. Обычно это ИТ-безопасность или внутренний аудит.
Владелец бизнес-сценария
Определяет, какие сценарии приоритетны, какие метрики отслеживать, какие пороги чувствительности настроить для алертов. Обычно это руководитель функции (коммерческий директор, директор по категориям).
Каждый новый агент в каталоге проходит стандартный цикл, который включает проектирование, разработку, тестирование, пилотирование и вывод в промышленную эксплуатацию.
Проектирование. Формулировка назначения, определение инструментальной политики, выбор модели, описание формата ответа. Главным артефактом этапа выступает заполненная карточка агента по шаблону из 03-agents, раздел «Шаблон карточки агента». Девять полей карточки (назначение, пользователи, типовые вопросы, используемые данные, доступные действия, взаимодействие с другими агентами, ограничения, бизнес-эффект, метрики) одновременно служат техническим заданием на разработку и контрольным списком для приёмки на следующих этапах.
Разработка. Создание рабочей директории, написание инструкций, настройка инструментов и коннекторов. Тестирование на исторических данных.
Пилотирование. Ограниченное внедрение у нескольких Напарников. Обратная связь от менеджеров, калибровка качества.
Промышленная эксплуатация. Добавление в общий каталог, доступ для всех Напарников. Мониторинг метрик качества, регулярный пересмотр инструментальной политики.
Эволюция. Обновление по обратной связи, расширение источников данных, уточнение инструкций. Агент живёт и развивается, а не остаётся в первоначальной конфигурации.
Правила A2A-коммуникации (кто кому может писать и по каким поводам) настраиваются на уровне платформы и пересматриваются при изменении организационной структуры. Например, Напарники менеджеров одного направления могут обращаться друг к другу; Напарник руководителя может запрашивать данные у Напарников его подчинённых; функциональные агенты не участвуют в A2A, только принимают делегирование; агент алертов может отправлять уведомления Напарникам, но не может запрашивать у них информацию.
Каждый ход (turn) агента означает расход токенов LLM. Ход (turn) представляет собой один полный цикл работы агента. Он включает получение входящего сообщения, его обработку, вызов нужных инструментов и формирование ответа. Платформа поддерживает несколько механизмов контроля стоимости.
Разные модели для разных ролей снижают стоимость без потери качества. Напарники работают на сильной модели (нужно суждение, синтез, персонализация), а функциональные агенты и субагенты могут работать на более экономичной (нужна надёжность исполнения, а не креативность).
Тайм-ауты ограничивают каждую делегированную задачу по времени. Если агент не вернул результат за отведённое время, задача прерывается.
Лимиты параллелизма ограничивают количество одновременных задач и предотвращают неконтролируемый расход.
Бюджеты задают квоты на агента, на Напарника или на отдел. Опциональная мера, но полезная при масштабировании.
Обнаружение зацикливания (loop detection) отслеживает повторяющиеся вызовы инструментов без прогресса. Если агент начинает вызывать одни и те же инструменты без движения к результату, платформа предупреждает или останавливает его, чтобы не расходовать токены впустую.
Каждый ход каждого агента полностью логируется. В журнале фиксируются входящее сообщение (от сотрудника, от другого агента, от планировщика), системный контекст (какие файлы личности были загружены, какие инструменты доступны), каждый вызов инструмента с параметрами и результатом, ответ модели (включая reasoning, если включён) и метрики выполнения (токены, стоимость, время).
Журналы хранятся в структурированном формате (JSONL). Доступ к ним имеет только compliance-офицер и администратор платформы. Агенты могут читать историю своих собственных сессий, но не сырые журналы.
Любая цифра, которую возвращает агент, содержит ссылку на источник в корпоративном хранилище. Указываются таблица, период, набор фильтров. Сотрудник может провалиться в источник и проверить. Это не только помогает доверию, но и создаёт верифицируемый audit trail для каждого аналитического вывода.
Платформа поддерживает несколько уровней наблюдаемости.
Здоровье платформы
Статус шлюза платформы (gateway), подключённых каналов, активных агентов, очередей задач. Шлюз платформы (gateway) работает как центральный серверный процесс, который принимает входящие сообщения, маршрутизирует их к агентам, управляет сессиями и контролирует исполнение инструментов. Мониторинг ресурсов охватывает CPU, память, диск и сетевые подключения. Автоматические алерты при сбоях.
Активность агентов
Количество ходов (turns), среднее время ответа, количество ошибок, расход токенов. По каждому агенту и в агрегате. Позволяет видеть, кто из агентов перегружен, кто простаивает, где растёт стоимость.
Качество работы
Оценки менеджеров по диагностикам (5-балльная шкала), доля уточняющих вопросов, доля результатов, которые менеджер принял без изменений. Это метрики зрелости, по ним калибруется качество каждого агента.
Безопасность
Попытки доступа за пределами разрешённого, нетипичные запросы, аномалии в использовании инструментов. Автоматический мониторинг плюс ручной аудит по расписанию.
Напарник вводится не одним релизом, а растёт по уровням зрелости (подробно эта лестница описана в 02-partner, раздел «Уровни зрелости ИИ-Напарника»). Архитектурные требования у разных уровней разные. Некоторые слои и интеграции нужны с первого дня, другие подключаются позже. Эту картину полезно держать перед глазами на пресейле, чтобы не обещать заказчику Уровень 4, когда у него ещё не закрыт Уровень 1.
| Уровень | Что Напарник делает | Архитектурный минимум |
|---|---|---|
| 1. Операционный | Почта, календарь, голос, транскрипты, поиск по корпоративным источникам. | Слои 1–3, базовая память (личная + база знаний), коннекторы к мессенджеру, почте, календарю, RAG поверх документов. Из агентов нужны агент встреч и follow-up и агент регламентов. |
| 2. Аналитический | Доступ к данным и BI, факторный анализ, генерация презентаций, проактивный мониторинг. | Добавляются Слой 4 (функциональные агенты), коннекторы к DWH/BI, семантический слой, Text2SQL, агент факторного анализа, агент аномалий, проактивный цикл (cron). |
| 3. Коммуникационный | Профили контактов, симулятор коммуникаций, реалтайм-подсказки, второе мнение. | Дозревает Слой 5 (память) с расширенными профилями контрагентов, добавляются агент переговоров и агент финансового эффекта. Усиливаются требования к compliance вокруг personal data. |
| 4. Мультиагентный координатор | Общение Напарников между собой, горизонтальный обмен паттернами, вертикальная агрегация. | Включается A2A-слой с белым списком, появляется коллективная память с куратором, дозревает governance (роли управления, политики A2A). Становится критичным cost management. |
Это не жёсткий план перехода, а карта зависимостей. На реальном пилоте уровни обычно перекрываются, например, базовый аналитический контур (часть Уровня 2) подключается одновременно с операционным помощником (Уровень 1), потому что без него ценность платформы видна только частично. Привязка уровней к фазам внедрения собрана в 07-roadmap.
На уровне концепта рассматриваются три модели развёртывания. Выбор между ними делается под конкретного заказчика и зависит от ИТ-политики, compliance-требований, бюджета и стратегических предпочтений.
Данные on-premise, LLM через корпоративный шлюз.
Шлюз платформы и все данные размещаются на инфраструктуре заказчика (on-premise или в корпоративном облаке). Обращения к LLM-провайдеру идут через корпоративный API-шлюз с шифрованием, аутентификацией и логированием.
Данные не покидают периметр. Лучшее качество моделей (доступ к top-tier LLM) и быстрый старт без развёртывания локальных моделей. Ограничения связаны с зависимостью от внешнего LLM-провайдера, потому что промпты и ответы проходят через внешний API (хотя данные остаются в запросах агентов, а не передаются напрямую).
Подходит там, где заказчик допускает использование внешних LLM-сервисов через корпоративный шлюз и compliance разрешает передачу промптов наружу при условии шифрования и обезличивания.
Всё на инфраструктуре заказчика, включая модели.
Шлюз, данные и LLM-модели размещаются внутри корпоративного периметра. Модели запускаются на собственном оборудовании или на выделенных серверах в корпоративном ЦОД.
Полный контроль. Ничего не покидает периметр. Соответствие самым строгим compliance-требованиям. Но требуются вычислительные ресурсы для LLM (GPU-серверы), качество локальных моделей может уступать top-tier провайдерам, и эксплуатация обходится дороже.
Подходит там, где заказчик категорически не допускает передачу любых данных наружу и располагает собственными GPU-ресурсами или готовностью их приобрести.
Данные и модели в российском облачном сервисе.
Использование российских LLM-провайдеров (YandexGPT, GigaChat и др.) и российской облачной инфраструктуры. Данные остаются в российской юрисдикции.
Соответствие требованиям по локализации данных, отсутствие зависимости от зарубежных провайдеров. Качество моделей пока может отличаться от top-tier провайдеров (хотя разрыв сокращается), и выбор инструментов экосистемы пока ограничен.
Подходит там, где заказчик обязан хранить и обрабатывать данные на территории РФ или отдаёт стратегическое предпочтение отечественным решениям.
Чтобы концепт не воспринимался как идеальная система, важно явно зафиксировать ограничения и риски, с которыми столкнётся реальное внедрение.
| Ограничение | Описание | Рекомендация |
|---|---|---|
| Качество LLM | Модели ошибаются. Качество факторного анализа, Text2SQL и интерпретации ситуации полностью зависит от качества модели. Hallucinations остаются проблемой. | Ссылка на источник в каждом факте. Обратная связь от менеджера. Проверка критических выводов человеком. |
| Prompt injection | Внешний контент (письма, URL) может содержать инструкции для модели. | Архитектурная защита (инструментальные политики, Tier-модель). XML-обёртки как дополнительная мера. Tier 2 для чувствительных действий. |
| Стоимость токенов | Каждый ход агента расходует токены. На масштабе сотни Напарников стоимость может быть значительной. | Дифференциация моделей (дешёвые для workers, дорогие для Напарников). Тайм-ауты. Бюджеты. |
| Латентность | Параллельная оркестрация нескольких агентов плюс обращения к DWH могут занимать десятки секунд. | Кэширование частых запросов. Преемптивная подготовка (досье готовится до запроса). Прогрев данных. |
| Зависимость от данных | Если DWH содержит некачественные или неполные данные, агенты вернут некачественные результаты. | Агент качества данных в каталоге (03-agents). Проверка целостности данных перед каждым аналитическим запросом. |
| Масштабирование | Один шлюз платформы (gateway) обрабатывает все запросы. На масштабе сотен одновременных пользователей нужна горизонтальная масштабируемость. | Архитектурная готовность к горизонтальному масштабированию. На пилоте не блокер. |
| Зрелость организации | Платформа требует готовности к изменениям, а именно формализации процессов, назначения куратора памяти, согласования Tier-модели. Без организационной поддержки техническое внедрение не даёт полного эффекта. | Организационные условия описаны в 07-roadmap. Включаются с Фазы 0. |
Здесь темы, по которым у концепта пока нет финального решения. Они требуют проработки под конкретного заказчика или отдельного technical deep-dive.
Темы, которые можно вынести в отдельные technical notes по мере необходимости. На первой версии концепта они не требуют полного описания.
Документ описывает концептуальную архитектуру платформы. Пользовательская модель Напарника описана в 02-partner. Каталог функциональных агентов лежит в 03-agents. Бизнес-сценарии собраны в 04-usecases. Интеграционный слой и инструменты агентов разобраны в 06-integrations. Дорожная карта внедрения лежит в 07-roadmap.