AI-агенты для бизнеса: платформа, компоненты, каналы

Введение

AI-агенты — это не просто чат-боты, отвечающие по скрипту. Это интеллектуальные системы, которые понимают контекст, подключаются к вашим базам данных и документам, вызывают API и принимают решения. Для бизнеса это означает: меньше рутины, быстрее ответы, ниже затраты, выше качество.

Мы выделяем четыре типа агентов, закрывающих ключевые потребности любой компании:

Но за каждым из этих агентов стоит общая платформа — и именно она определяет, будет ли агент удобным, безопасным и управляемым. В этом документе мы разбираем бизнес-компоненты платформы и каналы доставки.

Бизнес-компоненты платформы

1. Аналитика диалогов

Без аналитики агент — чёрный ящик. Бизнесу нужно понимать, что происходит внутри.

Что даёт аналитика:

Аналитика — opt-in: по умолчанию не учитывается ни один агент, включается глобально или на конкретный шаблон.

Пример, как это может выглядеть (числа условные):

📊 Дашборд за июль 2026
├─ Всего диалогов: 8 230
│  ├─ Решено агентом: 5 760 (70%)
│  ├─ Эскалировано: 1 810 (22%)
│  └─ Не решено (нет в базе): 660 (8%) ⚠️
├─ Топ-5 тем:
│  1. Статус заказа — 2 140
│  2. Возврат/брак — 1 520
│  3. Доставка в регионы — 980
│  4. Сравнение товаров — 890
│  5. Гарантия — 720
├─ Среднее время ответа: 1.2 сек
└─ Средняя оценка пользователя: 4.7 / 5

2. Безопасность

AI-агент работает с данными компании — документами, базой клиентов, финансовой информацией. Безопасность не опция, а фундамент.

Уровни защиты:

Пример: как работает маскирование ПДн

Пользователь: Мой паспорт 4512 345678, проверьте заказ
Агент (видит):  Мой паспорт [PASSPORT_MASKED], проверьте заказ
В логах:        [PASSPORT_MASKED] — исходные данные не
                сохраняются, только факт обнаружения ПДн

3. База знаний и данные

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

Как агент получает знания:

Актуализация. Архив пересобирается краулером — вручную, скриптом или по cron. Автоматической индексации документов (Confluence, Google Docs, 1С) и версионирования базы знаний нет.

4. Контроль качества

Агент должен не просто отвечать, а отвечать хорошо. Качество держится на управляемых механизмах.

5. Интеграционный слой

Агент не существует в вакууме — он подключается к ИТ-ландшафту компании.

Встроенные интеграции:

В планах: 1С/ERP, amoCRM/Bitrix24, Active Directory/LDAP, ClickHouse, Jira/Kaiten/Notion, платёжные шлюзы (ЮKassa и др.), службы доставки (СДЭК, ПЭК, Почта России), WhatsApp Business API. Нативной поддержки у них пока нет — часть достижима только произвольным HTTP через site_tool.

Каналы доставки

Агент должен быть там, где пользователь. Не пользователь идёт к агенту, а агент — к пользователю.

1. Виджет на сайте

Самый очевидный канал для внешних клиентов.

Пример размещения:

Сайт университета
├─ Главная — виджет с предложением: «Я отвечу на вопросы
│  о поступлении, расписании и студенческой жизни»
├─ Страница приёмной кампании — виджет автоматически предлагает:
│  «Хотите узнать проходной балл на ваш факультет?»
└─ Личный кабинет студента — виджет в контексте: «Нужна справка
   об обучении? Я помогу оформить»

2. Telegram-бот

Самый популярный канал в России для внутренних коммуникаций и поддержки.

Сценарий для производства (производственная компания):

Сотрудник цеха открывает Telegram на смартфоне → @CompanyHelperBot
→ «Оформить отгул» → одна кнопка → готово.

Не нужно: искать компьютер, заходить в 1С, помнить пароль,
разбираться в интерфейсе.

3. VK, Яндекс Мессенджер, email и API

Кроме виджета и Telegram, агент подключается к другим каналам:

Сравнение каналов

Дополнительно: результат работы агента-наблюдателя уходит в sink — вебхук, Telegram, VK, Яндекс Мессенджер, email, другой агент или storage (S3/WebDAV/FTP).

Архитектура: как это работает

flowchart TB
    subgraph channels["📱 КАНАЛЫ"]
        Widget["Виджет на сайте"]
        Messengers["Telegram · VK · Яндекс"]
        Api["HTTP API (SSE)"]
        Email["Email"]
    end

    subgraph triggers["⏰ ТРИГГЕРЫ — запуск без человека"]
        Cron["Cron"]
        Webhook["Webhook"]
        Monitor["Monitor (RSS и др.)"]
    end

    Host["🌐 Хост — HTTP-сервер<br/>аутентификация · админ-UI"]

    subgraph kernel["🧠 ЯДРО — операционная система для агентов"]
        direction TB
        Sched["Планировщик<br/>конкурентность и очередь"]
        Processes["Таблица процессов<br/>агент = процесс (PID, состояние)"]
        Ctx["Контекст (аналог RAM)<br/>вытеснение и сжатие"]
        Budg["Бюджеты (аналог cgroups)<br/>token bucket · группы"]
        Hooks["Хуки жизненного цикла<br/>guard · rag · memory · cache"]
        Ipc["IPC и системные вызовы<br/>spawn · fork · send/recv"]
    end

    subgraph providers["⚙️ ИНФЕРЕНС (аналог CPU)"]
        Router["Маршрутизация моделей<br/>и кэш инференса"]
        Llm["LLM<br/>OpenAI-совместимый · DeepSeek · Ollama"]
    end

    subgraph tools["🔧 ИНСТРУМЕНТЫ (аналог устройств I/O)"]
        Web["Сеть · сайты · браузер"]
        Know["Архив поиска (BM25) · PDF · документы"]
        Db["SQL · DuckDB · файлы"]
        Act["Скрипты · субагенты · почта · S3"]
    end

    subgraph store["💾 ХРАНИЛИЩА"]
        Transcripts["Транскрипты диалогов"]
        Events["Журнал событий (аудит)"]
        State["State store"]
    end

    subgraph modules["🧩 МОДУЛИ — фичи поверх ядра"]
        Wf["Workflow (DAG)"]
        Analytics["📊 Аналитика диалогов"]
        Approvals["Approvals · эскалация"]
        Connectors["Коннекторы (OAuth)"]
    end

    Widget --> Host
    Messengers --> Host
    Api --> Host
    Email --> Host
    Cron --> Host
    Webhook --> Host
    Monitor --> Host
    Host --> Sched
    Sched --> Processes
    Processes --> Ctx
    Processes --> Budg
    Processes --> Hooks
    Processes --> Ipc
    Hooks --> Router
    Router --> Llm
    Processes --> Web
    Processes --> Know
    Processes --> Db
    Processes --> Act
    Processes --> Transcripts
    Processes --> Events
    Processes --> State
    Events -.-> Analytics
    Hooks -.-> Approvals
    Ipc -.-> Wf
    Act -.-> Connectors

Ключевые принципы:

• Агент — это процесс. Каждый агент запускается как самостоятельный процесс со своим PID, контекстом, набором инструментов и бюджетом. Шаблон агента (agent.yaml) — это рецепт; процесс создаётся лениво, на первый запрос. Воркфлоу и субагенты — тоже процессы, с семантикой spawn/fork.
• Ядро — это порядок. Один асинхронный рантайм планирует все процессы, держит лимит конкурентности и распределяет бюджеты (token bucket, группы на пользователя и сессию). Ядро посредничает в каждом вызове инструмента: валидирует аргументы, ограничивает по времени, логирует и считает стоимость.
• Модель — сменный процессор. Ядро не делает инференс само, а планирует его на подключаемом провайдере (OpenAI-совместимый API, DeepSeek, Ollama). Маршрутизация моделей выбирает модель под запрос, кэш инференса убирает повторные вызовы.
• Управляемость через хуки. Хуки перехватывают жизненный цикл в точках «до/после сообщения, вызова инструмента, инференса, стрима токенов, компакции контекста». Отсюда DLP и маскирование ПДн (guard, pseudonymize), заземление ответа (groundedness), память (memory), RAG (rag), кэши (faq_cache, tool_cache), разрыв циклов (loop_guard).
• Модульность. Ядро — только механизм; фичи (workflow, cron, каналы, аналитика, коннекторы, память, маршрутизация моделей, документация) — отдельные модули, подключаемые к ядру через единый шов сервисов. Отключённая подсистема отвечает «не настроено», а не ломает платформу.
• Автономность через триггеры. Агент запускается не только сообщением: cron — по расписанию, webhook — внешним push, monitor — при появлении новых данных (RSS). Результат уходит в sink: вебхук, Telegram, email, другой агент.
• Контроль и изоляция. Агент не читает чужой контекст и не тратит чужой бюджет. Все шаги пишутся в транскрипты и журнал событий (аудит). Рабочая база знаний — поисковый архив BM25; доступ к внешним БД и системам — только через инструменты, с настраиваемым read-only и подтверждением.

Заключение

AI-агенты для бизнеса — это не магия и не хайп. Это инженерное решение, которое сшивает три вещи:

1. Модель — большая языковая модель, понимающая естественный язык.
2. Данные компании — документы, базы, регламенты, товарный каталог.
3. Каналы — сайт, Telegram, VK, Яндекс Мессенджер, email — там, где пользователь.

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

И всё это — с окупаемостью от недели.