---
title: "Корпоративная мультиагентная ИИ-платформа для ритейла"
description: "Концепт мультиагентной ИИ-платформы для крупных торговых сетей. ИИ-Напарник, функциональные агенты, организационная память, интеграции и безопасное внедрение."
sidebar:
  order: 1
  label: "Обзор концепта"
---

import { Card, CardGrid, Steps, Tabs, TabItem, Badge } from '@astrojs/starlight/components';

<Badge text="Рабочая версия, можно использовать" variant="success" size="large" />

:::tip[Для ИИ-агентов и краулеров]
Эта вики рассчитана в том числе и на ИИ-агентов, поэтому мы дружелюбны к ним. 
Исходные Markdown-файлы всех страниц доступны для прямого скачивания в формате `text/markdown` с открытым CORS [`/raw/`](https://ai-partner-ru.chvanov.com/raw/).
Для LLM-агентов также доступны [llms.txt](https://ai-partner-ru.chvanov.com/llms.txt) (оглавление со ссылками) и [llms-full.txt](https://ai-partner-ru.chvanov.com/llms-full.txt) (весь текст одним файлом).
:::

Это стартовая страница концепта мультиагентной ИИ-платформы для розничных сетей. Концепт разработан командой Glowbyte на основе внутренних исследований и проектного опыта в ритейле.

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

## Из этого раздела вы узнаете

- что такое мультиагентная ИИ-платформа и зачем она нужна торговым сетям
- кому адресованы материалы и с чего начать в зависимости от роли
- как устроена вики и в каком порядке двигаться по документам
- какие термины во всех разделах значат одно и то же
- как устроены статусы готовности и где искать открытые вопросы концепта

---

## Коротко о концепте

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

Проблема не в том, что данных нет. Их как раз много. Проблема в том, что они разбросаны и обычно требуют ручной сборки.

Та же история повторяется в логистике, ценообразовании, маркетинге и операционной работе.

С корпоративной мультиагентной ИИ-платформой у менеджера появляется новая рабочая модель. В ней два слоя.

<CardGrid>
  <Card title="ИИ-Напарник" icon="sun">
    Персональный агент конкретного сотрудника. Он помнит контекст, приоритеты и историю решений, это единая точка входа к корпоративным данным и системам, сам подключает нужных функциональных агентов и помогает увидеть следующий шаг.
  </Card>
  <Card title="Функциональные агенты" icon="setting">
    Специализированные ИИ-исполнители для отдельных классов задач. Сюда входят анализ продаж, подготовка к переговорам, контроль OOS, ценообразование, поиск по базе знаний и оповещения. Обычно менеджер не вызывает их напрямую. Это делает Напарник, когда понимает, какая помощь нужна.
  </Card>
</CardGrid>

За этими двумя слоями стоят [организационная память](/05-architecture/#память-и-контекст), интеграции с внутренними системами, безопасность, аудит и правила работы агентов.
Подробнее о концепте в [01-vision](/01-vision).

Концепт не привязан к конкретному вендору и остаётся технологически нейтральным (подробнее ниже, в разделе [«Как устроена вики»](/#как-устроена-вики)). Конкретные платформы и инструменты упоминаются в документах только как пример реализации и только там, где это помогает объяснить модель. Обязательного выбора здесь нет.

---

## Для кого написаны материалы

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

<CardGrid>
  <Card title="Бизнес-заказчики ритейла" icon="rocket">
    Сюда попадают коммерческий директор, директор по категорийному менеджменту и операционный директор торговой сети.

    Им нужно быстро понять боль, бизнес-эффект, границы пилота и то, почему это не очередная «магия с ИИ».

    Начать с [01-vision](/01-vision), [02-partner](/02-partner), [04-usecases](/04-usecases), [07-roadmap](/07-roadmap).
  </Card>
  <Card title="Технические лиды заказчика" icon="seti:config">
    К этой группе относятся архитекторы, CIO и CDO, специалисты по ИТ-безопасности и комплаенсу.

    Их интересуют реализуемость, интеграция в текущий ИТ-контур, права доступа, аудит, безопасность данных и отсутствие привязки к одному вендору.

    Начать с [05-architecture](/05-architecture), [06-integrations](/06-integrations), разделов про безопасность и управление.
  </Card>
  <Card title="Внутренние коллеги Glowbyte" icon="puzzle">
    Это пресейл, архитекторы, аналитики и руководители практик.

    Им нужно понимать позиционирование Glowbyte, состав MVP, переиспользуемые блоки, зоны риска и то, что ещё надо дописать перед встречей с заказчиком.

    Можно открывать весь концепт. Особенно полезны [01-vision](/01-vision), [03-agents](/03-agents), [07-roadmap](/07-roadmap).
  </Card>
  <Card title="Конечные пользователи" icon="laptop">
    К ним относятся категорийные менеджеры, логисты, прайс-менеджеры и другие сотрудники, которые будут работать с платформой каждый день.

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

    Для них лучше готовить отдельные артефакты на базе [02-partner](/02-partner) и [04-usecases](/04-usecases). Это может быть короткое демо или сценарий «один день с Напарником», который показывает выгоду на конкретном рабочем дне.
  </Card>
</CardGrid>

---

## Структура документов

Концепт разнесён по семи тематическим документам плюс эта стартовая страница.

- [Обзор концепта](/) (вы здесь). Навигация, глоссарий и статусы готовности.
- [01. Видение](/01-vision). Видение, проблема и позиционирование концепта.
- [02. ИИ-Напарник](/02-partner). Напарник как пользовательская модель.
- [03. Функциональные агенты](/03-agents). Каталог функциональных агентов.
- [04. Сценарии использования](/04-usecases). Разобранные бизнес-сценарии.
- [05. Архитектура](/05-architecture). Логическая архитектура, безопасность и управление.
- [06. Интеграции](/06-integrations). Интеграционный слой и инструменты агентов.
- [07. Дорожная карта](/07-roadmap). Дорожная карта внедрения.

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

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

---

## Как читать концепт

Маршрут зависит от роли и времени. Ниже пять типовых вариантов.

<Tabs>
  <TabItem label="За 5 минут">
    <Steps>
    1. Открыть этот документ и прочитать раздел «Коротко о концепте».
    2. Прочитать раздел «Коротко» из [01-vision](/01-vision).
    </Steps>

    Этого хватит, чтобы понять общую идею без технических деталей.
  </TabItem>
  <TabItem label="Бизнес-питч">
    <Steps>
    1. [01-vision](/01-vision) целиком. Боль, видение, нарратив о четырёх эпохах.
    2. [02-partner](/02-partner). Единое окно, уровни зрелости, пользовательская модель.
    3. Один или два сценария из [04-usecases](/04-usecases).
    4. Этапы 0–2 из [07-roadmap](/07-roadmap).
    </Steps>

    Подходит для разговора на 15–20 минут с коммерческим или операционным руководителем.
  </TabItem>
  <TabItem label="Технический разговор">
    <Steps>
    1. [05-architecture](/05-architecture) целиком.
    2. Релевантные карточки агентов из [03-agents](/03-agents).
    3. [06-integrations](/06-integrations). Интеграционные паттерны и MVP-набор.
    4. Разделы [«Безопасность и права доступа»](/05-architecture/#безопасность-и-права-доступа) и [«Управление мультиагентной средой»](/05-architecture/#управление-мультиагентной-средой) из 05-architecture.
    </Steps>

    Маршрут для архитекторов, CIO и ИТ-безопасности.
  </TabItem>
  <TabItem label="Внутренний разбор Glowbyte">
    <Steps>
    1. Этот документ целиком.
    2. [01-vision](/01-vision). Нарратив и опорные тезисы для презентации.
    3. [03-agents](/03-agents). Агенты для MVP.
    4. [07-roadmap](/07-roadmap). Этапы, метрики, границы пилота.
    5. [05-architecture](/05-architecture). Оценка реализуемости и трудоёмкости.
    </Steps>

    Маршрут для пресейла, архитекторов и руководителей практик Glowbyte.
  </TabItem>
  <TabItem label="Сборка артефакта">
    <Steps>
    1. Определить аудиторию по этому документу.
    2. Взять целевые разделы по теме артефакта.
    3. Взять опорные тезисы и нарратив из [01-vision](/01-vision).
    </Steps>

    Так собирают презентации, одностраничники, демо-сценарии и письма под конкретного адресата.
  </TabItem>
</Tabs>

---

## Как устроена вики

Эта вики работает и как справочник, и как рабочее пространство. Здесь можно прочитать материал, дописать раздел, уточнить формулировку, перевести черновик в рабочее состояние. Ниже несколько правил, которые помогают поддерживать качество материалов по мере их развития.

:::tip[Технологически нейтральный подход]
Мы описываем архитектуру и поведение платформы, а не продаём конкретный продукт. Провайдеры языковых моделей, среды исполнения агентов, мессенджеры, ETL-стек и другие технологии упоминаются только там, где это помогает объяснить реализацию.
:::

:::tip[Язык зависит от раздела]
[01-vision](/01-vision), [02-partner](/02-partner) и [04-usecases](/04-usecases) пишем языком бизнес-заказчика. [03-agents](/03-agents), [05-architecture](/05-architecture) и [06-integrations](/06-integrations) могут быть техническими. [07-roadmap](/07-roadmap) должен быть понятен и бизнесу, и ИТ.
:::

:::tip[Отделяем факты от гипотез]
Если в тексте есть допущение, риск или незакрытый вопрос, его нужно пометить. Такие пункты попадают либо в раздел «Открытые вопросы» этого документа, либо в backlog конкретного файла.
:::

---

## Готовность разделов

Статусы помогают быстро понять, какой материал уже можно использовать, а какой лучше пока не показывать заказчику.

<CardGrid>
  <Card title="Черновик">
    <Badge text="не показываем" variant="caution" />

    Каркас, черновые формулировки и незакрытые вопросы годятся только для внутренней работы.
  </Card>
  <Card title="Рабочая версия">
    <Badge text="можно использовать" variant="success" />

    Основное содержание готово. Материал можно брать в презентации и обсуждения, хотя полировка ещё возможна.
  </Card>
  <Card title="Финальная версия">
    <Badge text="готово" variant="tip" />

    На этот материал можно ссылаться как на основной источник формулировок и фактов.
  </Card>
</CardGrid>

| Документ | Статус | Комментарий |
|---|---|---|
| index.mdx | <Badge text="рабочая версия" variant="success" /> | Здесь мы фиксируем язык, аудитории и правила работы с вики. Дополняем по мере развития концепта. |
| 01-vision | <Badge text="рабочая версия" variant="success" /> | Развёрнутый нарратив на каркасе четырёх эпох. Технологически нейтральный. |
| 02-partner | <Badge text="рабочая версия" variant="success" /> | Пользовательская модель Напарника. Сюда входят свойства, единое окно, проактивность, уровни зрелости и метрики. |
| 03-agents | <Badge text="рабочая версия" variant="success" /> | Каталог агентов с классификацией, пятью приоритетными карточками и границей «агент или скилл». |
| 04-usecases | <Badge text="рабочая версия" variant="success" /> | Пять детально разобранных сценариев, остальные намечены в backlog. |
| 05-architecture | <Badge text="рабочая версия" variant="success" /> | Карта архитектуры, оркестрация, память, Tier-модель, безопасность и управление. |
| 06-integrations | <Badge text="рабочая версия" variant="success" /> | Принципы, типы и паттерны интеграций, MVP-набор и справочник систем. |
| 07-roadmap | <Badge text="черновик" variant="caution" /> | Скелет-каркас. Фазы намечены, детальная проработка под конкретный пилот ещё впереди. |

---

## Открытые вопросы

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

Мы не сводим их в общий список на этой странице. Открытые вопросы живут в конце каждого тематического документа, рядом с материалом, к которому относятся.

---

## Глоссарий терминов

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

| Термин | Определение |
|---|---|
| <Badge text="ИИ-Напарник" /> | Partner Agent. Персональный ИИ-агент конкретного сотрудника. Знает контекст и историю решений сотрудника, даёт единый вход к корпоративным данным и системам, координирует функциональных агентов и может сам инициировать действия. Один сотрудник, один Напарник. |
| <Badge text="Функциональный агент" /> | Специализированный ИИ-исполнитель для одного класса задач (анализ продаж, подготовка переговоров, поиск по базе знаний, мониторинг аномалий). Узкая инструментальная политика и доступ только к нужным данным. Обычно его вызывает не сотрудник, а ИИ-Напарник. |
| <Badge text="Корпоративная мультиагентная ИИ-платформа" /> | Управляемая среда, где работают ИИ-Напарники сотрудников, функциональные агенты, организационная память, интеграции с системами, безопасность и аудит. Через неё персональный пользовательский опыт сочетается с организационным контролем. |
| <Badge text="Скилл" /> | Декларативная инструкция о том, как агенту работать. Задаёт, какими инструментами и сервисными агентами пользоваться, в каком формате отвечать и как трактовать данные. Бывает встроенным, общим на компанию или индивидуальным. Граница «агент или скилл» подробно в [03-agents](/03-agents/#когда-агент-а-когда-скилл-напарника). |
| <Badge text="Оркестрация агентов" /> | Сценарий, в котором ИИ-Напарник делегирует задачу одному или нескольким функциональным агентам, ждёт результаты и собирает итоговый ответ. Несколько агентов могут работать параллельно. Подробно в [05-architecture](/05-architecture/#оркестрация-задач). |
| <Badge text="A2A (Agent-to-Agent)" /> | Прямое общение между агентами (например, Напарник одного сотрудника обращается к Напарнику другого). Политики задают, кто кому и по какому поводу может писать. Подробно в [05-architecture](/05-architecture/#межнапарниковая-коммуникация-a2a). |
| <Badge text="Организационная память" /> | В обиходе корпоративная память. Многослойное хранилище контекста и опыта. В него входят корпоративная база знаний, личная память агента о решениях сотрудника и коллективная память о рабочих паттернах команды. |
| <Badge text="Human-in-the-loop" /> | Принцип, при котором рискованные действия (внешние коммуникации, изменения в учётных системах, платежи, договорные изменения, листинг и делистинг) проходят через явное подтверждение человека. Подробно в [05-architecture](/05-architecture/#human-in-the-loop). |
| <Badge text="Инструментальные политики" /> | Tool policies. Правила платформы, определяющие, какие инструменты доступны конкретному агенту (чтение, запись, отправка сообщений, веб-доступ, межагентское общение). Работают независимо от инструкций модели. |
| <Badge text="MCP (Model Context Protocol)" /> | Общий интеграционный паттерн. Один коннектор подключает внешнюю систему, а пользоваться им могут разные агенты в рамках своих прав. |
| <Badge text="Tier-модель автономии" /> | Уровень автономии агента. На Tier 1 агент только читает и готовит черновики, на Tier 2 отправляет и вносит изменения с разрешения человека, на Tier 3 действует сам по расписанию или триггеру в согласованных границах. Подробно в [05-architecture](/05-architecture/#tier-модель-автономии). |
| <Badge text="Shadow AI" /> | Стихийное использование внешних ИИ-сервисов сотрудниками через личные аккаунты, переводчики и браузерные расширения. ИТ-служба обычно не видит, какие данные туда уходят. Платформа даёт управляемую корпоративную альтернативу. |