Сбер выпустил гайд по мультиагентным системам — вот почему он может быть вам полезен
Если вы работаете с AI-продуктами, автоматизацией или только готовите инфраструктуру под это — обратите внимание на свежий документ от GigaChat (Сбер). Это не маркетинговая обёртка, а технический гайд на 70+ страниц, посвящённый созданию и применению AI-агентов и мультиагентных систем в корпоративной среде.
Он описывает:
- как устроены современные AI-агенты (спойлер: это больше, чем просто LLM в оболочке),
- как такие агенты могут действовать автономно, планировать, вызывать API и взаимодействовать друг с другом,
- какие технические и организационные условия нужны, чтобы они реально работали в продукте или бизнес-процессе.
Если вы продакт или техлид, документ стоит хотя бы пролистать — там есть конкретные архитектурные схемы, примеры с кодом, подходы к планированию и исполнениям, работа с памятью, протоколы взаимодействия и даже чек-листы по внедрению.
В этой статье — коротко о том, что там есть, на что обратить внимание и зачем это может пригодиться. Без пересказа теории — только полезные фрагменты, которые помогут вам решить конкретные задачи или открыть новые возможности.
Больше кейсов на канале “AI для продакта”.
AI-агенты: что это вообще и почему это больше, чем просто «обёртка» над LLM
Одна из первых мыслей, которую авторы гайда проговаривают чётко: AI-агент — это не чат-бот с доступом к GPT. И даже не «интерфейс к LLM». Это автономная система, у которой есть три обязательных свойства:
- Планирование действий — агент может сам понять цель и построить план.
- Исполнение — он умеет выполнять действия, в том числе с помощью инструментов (например, API, поисковых сервисов, баз данных).
- Автономность — он действует без ручного подтверждения на каждом шаге.
Внутри таких агентов, как правило, используются LLM (например, GigaChat), но они — только часть системы, а не сама система.
Для продакта это означает:
агент — это не помощник, которого нужно спрашивать, а исполнительно-координационный механизм, которому можно ставить задачу, а он дальше сам разбирается, что и как делать.
Также в документе есть простая, но меткая эволюционная схема:
- 💬 Чат-бот: отвечает на запрос.
- 🔄 Полуавтономный агент: может делать несколько шагов, но по жёсткому сценарию.
- ⚙️ Автономный агент: сам строит план и действует.
- 🤝 Мультиагентная система: команда агентов с распределёнными ролями.
Всё, что выше уровня чат-бота, требует другого подхода к архитектуре продукта — и это основная мысль, которую стоит унести.
Мультиагентные системы: когда одного AI-агента уже недостаточно
В документе много внимания уделено не отдельным агентам, а взаимодействию между ними. Логика такая: один агент — хорошо, но он ограничен в специализации. Когда нужно решать сложные задачи, выигрывает не «универсальный AI», а команда узкоспециализированных агентов, каждый из которых отвечает за свой участок работы.
Так появляется мультиагентная система — архитектура, в которой агенты:
- координируют действия друг друга,
- делят ответственность по ролям,
- и вместе доводят задачу до результата.
Что это даёт на практике:
- Можно разделить логику на независимые блоки: один агент работает с текстами, другой делает валидации, третий коммуницирует с CRM.
- Систему проще масштабировать и тестировать — потому что каждый агент отвечает за свой кусок.
- Появляется возможность переносить продуктовую логику из людей в машинных исполнителей. Прямо как команды, только цифровые.
Типы агентов, которые предлагает гайд:
- Пользовательский агент — общается с человеком, уточняет вводные, принимает запрос.
- Координационный агент — управляет другими агентами, разбивает задачу на подзадачи.
- Продуктовый агент — работает напрямую с внешними системами: вызывает API, агрегирует данные, пишет в базы.
Вместе они могут, например:
- Собрать Lean Canvas по описанию идеи,
- Провести конкурентный анализ,
- Проверить корректность данных,
- Подготовить презентацию.
Для продакта это открывает интересный инструмент:
можно проектировать не интерфейс, через который пользователь вручную проходит процесс, а механику, где пользователь ставит цель, а агенты делают всё остальное.
Как агенты планируют и действуют: внутренняя механика
Если вам казалось, что агент — это просто LLM, который отвечает на промпт, то гайд быстро разрушит это представление.
AI-агенты в нём — это исполнители, которые умеют:
- строить план (а не просто отвечать),
- вызывать функции и инструменты,
- адаптироваться по ходу выполнения задачи.
Важно: речь не про «жёсткий сценарий», а про динамическое поведение — с условиями, ветвлениями, ошибками и взаимодействием с внешними системами.
Какие есть подходы к планированию:
В гайде описаны три основных способа, как агент может построить свой план действий:
- Граф предопределённых шагов
Самый промышленный вариант: логика заранее задана в виде графа, но внутри шагов — агент использует LLM. Подход хорошо работает в продуктах, где важна прозрачность и контроль.
Используется, например, во фреймворках типа LangGraph. - Plan & Execute
Агент сначала генерирует план действий в текстовом виде, а потом по шагам его исполняет. Подходит для задач со сложной структурой, где важно видеть весь процесс заранее. - ReAct (Reasoning + Acting)
Самый гибкий: агент действует «на лету», реагируя на промежуточные результаты. Стратегия ближе всего к человеческому размышлению, особенно когда заранее предсказать всё нельзя.
Что вызывает на исполнение?
- Внутренние функции (например, вычисления, логика принятия решения).
- Внешние вызовы — через API (например, поиск, генерация документа, обращение к базе).
- Инструменты (в терминах гайда): это всё, чем агент может пользоваться. Чтобы инструмент работал, ему нужно описание — что он делает, какие параметры принимает и что возвращает.
👉 Это значит, что добавить в продукт нового агента — это не только про промпт, но и про «набор инструментов», которыми он может оперировать. Именно они превращают его из текстового интерфейса в исполнителя.
Здесь есть важный вывод:
вы проектируете не просто интеллект, а поведение. А значит — можно заранее определять границы, вводить защитные механизмы, чекпоинты, предусматривать откаты.
Всё это подробно разобрано в гайде — с кодами, схемами и примерами.
Память и знания: что агенту нужно, чтобы не быть золотой рыбкой
Чтобы AI-агент был полезен в продукте, ему мало просто «отвечать на вопросы». Он должен помнить контекст: что уже обсуждали, какие шаги были пройдены, какие данные ввёл пользователь, а иногда — и что делалось в предыдущем сеансе.
Гайд делит память агентов на два ключевых типа — и это полезное разделение с точки зрения проектирования:
Краткосрочная и долгосрочная память
- Краткосрочная — всё, что связано с текущим диалогом или задачей: последние сообщения, шаги, параметры.
Пример: "Что только что сказал пользователь?" или "На каком этапе мы остановились?" - Долгосрочная — накопленные знания: истории взаимодействий, результаты прошлых задач, постоянные правила.
Пример: "Какие решения агент принимал в подобных кейсах раньше?"
Важно: такие вещи можно проектировать как отдельные сервисы памяти — а не грузить всё в один state.
Контекстная и сущностная память
- Контекстная — всё, что связано с текущим процессом: роль агента, цель, этап.
- Сущностная — данные о людях, объектах, системах (графовая память, онтологии).
Для продакта это значит:
агент может выделять ключевые сущности и строить карту взаимодействий, а не просто помнить «что-то».
Знания: как подключить данные компании
AI-агенты не обучаются на данных компании по умолчанию — и это правильно. Гайд показывает, как можно:
- дообучить модель на доменной информации (SFT, RLHF, DPO, LoRA),
- или использовать RAG (Retrieval Augmented Generation) — подход, при котором агент сам подтягивает нужные данные из базы, не храня их в модели.
Это критично для безопасности: агент может знать только то, к чему у него есть доступ, без риска утечки всего корпоративного архива в модель.
Что с этим делать продакту?
- Если вы проектируете диалоговый интерфейс — подумайте, что агент должен помнить между шагами.
- Если автоматизируете процессы — определите, какие решения должны быть запомнены, чтобы влиять на поведение в будущем.
- Если работаете с корпоративными данными — решите, что важнее: дообучение модели или подключение внешнего источника знаний через RAG.
Гайд описывает архитектуры, инструменты, библиотеки и даже примеры кода с чекпоинтингом, векторной памятью и структурированными выходами. Всё это применимо в реальных продуктах — особенно если ваш агент делает больше, чем просто отвечает на вопрос.
Встраиваемость: как агенты живут внутри интерфейсов, а не рядом с ними
Многие представляют себе AI-агента как отдельного «ассистента в чате». Но гайд даёт более зрелую картину: агенты могут (и должны) быть частью бизнес-логики приложения, а не его надстройкой.
Не интерфейс с агентом, а продукт с агентной логикой
Один из интересных моментов в гайде — концепция обогащённых агентами приложений (agent-augmented apps):
- Агент не просто «живёт» в чате — он встраивается в существующий интерфейс и разделяет состояние приложения.
- Это означает, что агент:
знает, что видит пользователь,
может сам инициировать действия в интерфейсе,
и обновлять данные напрямую в бизнес-логику приложения.
Почему это важно:
- Вы не строите новый интерфейс, а расширяете текущий.
- Пользователь не ощущает перехода «в режим бота» — всё выглядит как единый опыт.
- Агент может быть контекстно-чувствительным: он знает, где вы в интерфейсе, и предлагает действия в тему.
Что для этого нужно:
- Общий state между агентом и приложением (например, через store, shared memory, события).
- Механизмы обратной связи — чтобы агент мог запросить уточнение, получить фидбек или приостановить выполнение.
- Гибкая интеграция: например, через библиотеки типа CopilotKit или LangGraph, которые позволяют встроить агента в React-приложение.
Что стоит унести продакту:
Не обязательно строить «AI-чат». Можно встроить агента прямо в привычные сценарии: например, в редактор отчётов, настройки CRM, процесс заполнения заявки или личный кабинет клиента.
Это даёт не просто автоматизацию, а переосмысленный пользовательский опыт, где AI — часть логики, а не кнопка в углу.
Как внедрять AI-агентов: с чего начать и что почерпнуть из гайда
Хорошая новость — гайд не ограничивается теорией. В финале есть чёткий набор рекомендаций для команд, которые хотят перейти от экспериментов с LLM к полноценным агентным системам. Это особенно полезно продактам, которые смотрят на AI не как на фичу, а как на архитектурный подход.
С чего начать:
- Оцените, где агент действительно нужен
Не всё надо автоматизировать. Начинайте с процессов, где уже понятны шаги, но они рутинны или масштабируются плохо. - Определите роли
Какие действия будут выполнять агенты? Нужен ли только пользовательский агент, или стоит выделить координационные и продуктовые? - Постройте минимальный пайплайн
Один агент + один инструмент (например, вызов API или доступ к базе знаний через RAG) — уже достаточно, чтобы понять, как это работает. - Внедрите фидбек-петлю
Агент должен получать отклик: получилось или нет. Это важно для доверия и итеративного улучшения. - Не делайте ставку только на чат
Встраивайте агента в интерфейс, как часть логики. Чем ближе к реальному UX, тем выше шанс на полезность.
Что есть в гайде:
- Архитектуры: как строить мультиагентные системы и запускать их в проде.
- Примеры: как работают Plan & Execute, ReAct, вызовы API, память, чекпоинты.
- Код: LangGraph, LangChain, LangMem, CopilotKit — всё с живыми кусками.
- Безопасность: RAG, управление доступом, защита памяти, изоляция моделей.
- Подходы к дообучению: SFT, RLHF, DPO, LoRA.
В завершение
Этот документ от GigaChat — один из самых практичных гайдов по мультиагентным системам на русском языке. Он не про фантазии, а про реальную архитектуру: как проектировать, интегрировать, защищать и масштабировать агентов в продуктовой среде.
📎 Ссылка на документ: Разработка и применение мультиагентных систем в корпоративной среде (PDF)
Если вы продакт и хотите использовать AI в продукте не как фичу, а как механику, — очень рекомендуем хотя бы пролистать.
Больше кейсов на канале “AI для продакта”.