---
title: "Функциональные агенты"
description: "Каталог функциональных агентов платформы. Что это такое, как они отличаются от ИИ-Напарника, по каким принципам проектируются, какие классы существуют и какие пять агентов имеет смысл собрать в первую очередь под пилот."
sidebar:
order: 4
label: "03. Функциональные агенты"
---
import { Card, CardGrid, Steps, Badge } from '@astrojs/starlight/components';
Функциональные агенты это специализированные ИИ-исполнители: они решают узкие классы задач и работают под координацией ИИ-Напарника. Здесь сведены принципы проектирования, классификация, шаблон карточки и подробный разбор пяти агентов, с которых имеет смысл начинать пилот.
## Из этого раздела вы узнаете
- что такое функциональный агент и какие три свойства отличают его от прочих сущностей платформы
- чем функциональный агент отличается от ИИ-Напарника и где проходит граница между ними
- как устроена классификация каталога на бизнес-функциональные и сервисные агенты
- какие пять агентов имеет смысл собрать первыми под MVP и пилот
- по каким принципам проектируется любой новый агент и из чего состоит шаблон его карточки
---
## Коротко
Функциональный агент это узкоспециализированный ИИ-исполнитель для одного класса задач. Это может быть например анализ продаж, поиск по регламентам, подготовка досье поставщика или мониторинг аномалий. Каждую такую работу закрывает отдельный агент: у него собственные инструменты и память, а правила и права доступа настроены под его узкую специализацию.
Сотрудник обычно этих агентов не видит. Запросы к ним отправляет ИИ-Напарник, он же собирает результаты в один ответ и приносит сотруднику. Так выглядит правильное разделение ответственности. Напарник имеет доступ к контексту сотрудника и [оркестрирует](/05-architecture/#оркестрация-задач) работу, а функциональный агент качественно и предсказуемо закрывает свою предметную область.
В этом документе мы не описываем весь возможный каталог функциональных агентов. Для начала рассмотрим [пять агентов](#карточки-приоритетных-агентов), которые ложатся в понятные бизнес-сценарии и на наш взгляд быстрее всего показывают ценность платформы. [Остальных агентов](/03-agents/#развитие-каталога-агентов) обозначим одним абзацем, и они появятся (или будут заменены другими) по мере роста зрелости внедрения.
:::tip[Главный тезис документа]
Функциональный агент это узкоспециализированный исполнитель для одного класса задач, который сотрудник напрямую не видит. Запросы к нему отправляет и собирает результаты [**ИИ-Напарник**](/02-partner/), а каталог таких агентов можно расширять без роста когнитивной нагрузки на человека.
:::
---
## Что такое функциональный агент
У функционального агента три отличительных свойства, и важны они все вместе.
Во-первых, у него один класс задач. Например, один агент разбирает отклонения в продажах, другой готовит досье на поставщика, третий следит за аномалиями. Размывать специализацию плохая идея, потому что универсальный агент тяжелее настраивать, его сложнее аудировать и сложнее улучшать по обратной связи. Лучше иметь пять агентов с понятными границами, чем один, который умеет всё подряд.
Во-вторых, у него узкая [инструментальная политика](/05-architecture/#инструментальные-политики). Функциональный агент видит только те данные и инструменты, которые ему нужны для его специализации. Например, у Text2SQL агента есть доступ (только на чтение) к корпоративному хранилищу и больше ничего. А агенту аномалий разрешено читать данные и отправлять сигнал Напарнику, но он не пишет в системы и не имеет доступ к веб-поиску.
В-третьих, функциональный агент стоит на одну роль выше слоя данных и на одну ниже Напарника. К нему как правило обращается не сотрудник напрямую, а Напарник от имени сотрудника. У функционального агента основная ответственность — качество исполнения предметной задачи, а не работа с контекстом конкретного человека. Контекст сотрудника находится на уровне Напарника.
:::tip[Один агент, один класс задач]
Практический признак для проверки. Если внутри одного агента появляются сразу две функции, которые требуют разных инструментов или разных прав, его пора делить. На старте такой дисциплины придерживаться сложно, но на среднем и длинном горизонте она окупается.
:::
---
## Роль функциональных агентов в платформе
Функциональные агенты дают платформе предметную глубину. Напарник без них умеет вести диалог, удерживать контекст пользователя и принимать решения о маршрутизации, но сам по себе не сделает качественный факторный анализ и не напишет SQL. Умение качественно решать такие задачи приходит через подключение нового функционального агента.
С точки зрения внедрения это достаточно удобно. Каталог функциональных агентов может расти постепенно. Сначала закрывают самые болезненные сценарии. На пилоте, например, это может быть разбор отклонений продаж и подготовка к переговорам. Остальное добавляется по мере того, как заказчик видит ценность и подтягиваются интеграции с источниками данных. Каждый новый агент работает как отдельная единица поставки с понятными границами, понятными тестами и измеримым эффектом.
Заметим, что каталог функциональных агентов можно расширять без увеличения когнитивной нагрузки на сотрудника. В мессенджере он по-прежнему пишет своему Напарнику тем же языком, что и вчера, просто Напарник теперь умеет ещё одну вещь. Это и даёт [четвёртой эпохе](/01-vision/#эпоха-4-ии-напарник-и-мультиагентная-среда) главное преимущество перед [третьей](/01-vision/#эпоха-3-функциональные-ии-агенты). В третьей эпохе каждый новый агент подключается к менеджеру напрямую и означает ещё одну вкладку, приложение или отчёт, которые нужно держать в голове. В четвёртой все они стоят за Напарником, и рост каталога сотруднику не виден.
---
## Отличие функционального агента от ИИ-Напарника
На словах эти сущности легко путаются. Различить их помогает простой тест границы:
- Если у сущности есть личный контекст конкретного сотрудника (его приоритеты и история решений), и она закреплена за человеком, то это часть Напарника.
- Если у сущности есть узкая инструментальная политика и она работает «под капотом», то это функциональный агент.
Когда границы соблюдаются, платформу проще аудировать и развивать.
Таблица отличий по семи критериям (за кем закреплён, кто вызывает, что знает, что возвращает, какой доступ к данным) лежит в [02-partner, раздел «Отличие ИИ-Напарника от функционального агента»](/02-partner/#отличие-ии-напарника-от-функционального-агента).
---
## Классификация функциональных агентов
Каталог функциональных агентов удобно разнести по двум большим группам. Это не строгая таксономия для технической документации, а скорее способ быстро ориентироваться при разговоре с заказчиком. Сразу видно, создаёт ли агент прямую бизнес-ценность или обслуживает работу остальных.
Граница между группами проходит по тому, закрывает ли агент самостоятельный бизнес-сценарий. Бизнес-функциональные агенты привязаны к конкретной предметной задаче коммерции, операций или работы с клиентами, и их эффект виден в P&L. Сервисные агенты живут в более технической и обслуживающей плоскости. Сами по себе они редко закрывают сценарий целиком, чаще их вызывает Напарник или другой агент как инструмент, но без них остальные агенты в некоторых случаях не смогут решить свою задачу.
### Бизнес-функциональные агенты
Эти агенты привязаны к конкретной бизнес-задаче, и их эффект виден в P&L. Внутри группы удобно различать три направления. Коммерция — повседневная работа категорийного менеджера и коммерческого блока: анализ продаж и маржи, разбор промо, подготовка к переговорам, ассортиментные решения, ценообразование (здесь больше всего агентов, P&L-эффект виден быстрее всего, и в пилоте область обычно берут первой). Операции — работа с поставками, остатками и доступностью товара: OOS, недопоставки, альтернативные маршруты при сбоях, оборачиваемость, списания (часто появляются на втором шаге пилота). Клиенты — сегментация, поведенческие паттерны, отклик на промо и удержание (полезны там, где у сети есть программа лояльности и сильная аналитика клиентского поведения).
### Сервисные агенты
Эти агенты живут в технической и обслуживающей плоскости. Сами по себе они редко закрывают бизнес-сценарий целиком, чаще их вызывает Напарник или другой агент как инструмент. Сервисные агенты удобно разнести по трём направлениям. Технические — слой, на котором держится почти всё остальное: Text2SQL, факторный анализ, прогнозирование, обнаружение аномалий, проверки качества данных. Коммуникационные отвечают за встречи и тексты: запись и краткий пересказ расшифровок встреч, follow-up, профили контактов, помощь с письмами и презентациями, поддержку в реальном времени во время переговоров. Сотрудников на пилоте такие агенты часто радуют сильнее всего, потому что экономия времени видна почти сразу. Организационные накапливают и переиспользуют опыт команды: коллективная память, поиск по регламентам, поддержка адаптации нового сотрудника, управление прецедентами. Их обычно подключают на втором-третьем этапе, когда у платформы уже есть данные о реальной работе менеджеров.
---
## Принципы проектирования агентов
Эти принципы прошиты в архитектуру, и им следует каждый новый функциональный агент.
Один агент закрывает один класс задач. У каждого агента есть короткое назначение в одну строку. Если объяснить его сложно, скорее всего, агент собран неправильно и его пора разделить.
Агент получает только те инструменты, которые ему нужны для работы. По умолчанию права только на чтение. Право на запись, отправку и обращения к другим агентам агент получает отдельно, под явное разрешение.
Любая цифра, которую возвращает агент, опирается на конкретный источник. Это может быть таблица в хранилище с периодом и набором фильтров или страница регламента. Сотрудник может в один клик провалиться и проверить.
У каждого агента есть свой формат вывода. Например, для аналитического агента это может быть диагностическая карточка с главным выводом, доказательной базой, отвергнутыми гипотезами и следующим шагом. Это нужно, чтобы Напарник смог качественно собирать ответы разных агентов в один результат для сотрудника.
Агент умеет принимать поправки от сотрудника. Реплика *«это был не OOS, а списание по сроку годности»* сохраняется как сигнал и учитывается в следующих похожих разборах. Без этой петли агент быстро упирается в потолок качества.
Несколько Напарников вызывают один и тот же агент параллельно, и контексты их вызовов не пересекаются. Технически изоляцию обеспечивает уровень сессий, это описано в [05-architecture, раздел «Модель взаимодействия агентов»](/05-architecture/#модель-взаимодействия-агентов).
Агенты не разговаривают с внешним миром от имени сотрудника. Внешние коммуникации, изменения в учётных системах, листинг и делистинг проходят через Напарника и через явное подтверждение человека. Эта граница описывается через Tier-модель автономии и подробно разбирается в [05-architecture, раздел «Tier-модель автономии»](/05-architecture/#tier-модель-автономии). В шаблоне карточки агента Tier фиксируется в пункте «Доступные действия и Tier автономии».
Удачные паттерны работы агента может быть полезно отчуждать в [скиллы](/05-architecture/#скиллы). Когда у конкретного агента закрепляется хорошо работающий подход (например, формат диагностической карточки факторного анализа или способ считать каннибализацию промо), его описывают как платформенный скилл и делают доступным всему каталогу. Это часть жизненного цикла агента и один из главных механизмов накопления коллективной экспертизы.
:::caution[Защита от prompt injection]
Внешние данные, которые попадают функциональному агенту на вход (например, письма поставщиков, ответы на запросы, содержимое веб-страниц), платформа оборачивает в служебные теги и помечает как недоверенные. Агент может их анализировать, но не может выполнять инструкции из их содержимого. Это особенно важно для агентов, работающих с почтой и внешним вебом. Любое действие с внешним эффектом, которое следует из такого содержимого, всё равно проходит через Напарника и Tier 2, то есть требует явного подтверждения сотрудника. Подробности лежат в [05-architecture, раздел «Защита от prompt injection»](/05-architecture/#защита-от-prompt-injection).
:::
---
## Когда агент, а когда скилл Напарника
Каталог выше неявно предполагает, что каждый бизнес-сценарий это отдельный функциональный агент. На практике это не всегда так. Часть сущностей, которые удобно называть «агентами», на деле не имеют собственного цикла рассуждений, собственных инструментов и собственной памяти. Они лишь маршрутизируют запрос к сервисным агентам (Text2SQL, база знаний, финансовый эффект) и склеивают ответы в нужный формат. С такой работой Напарник справляется сам, и тогда сущность правильнее оформить не как агента, а как [скилл Напарника](/05-architecture/#скиллы), то есть структурированную инструкцию в его промпте.
В разделе [«Принципы проектирования агентов»](#принципы-проектирования-агентов) описано прямое направление, когда удачный паттерн работы агента отчуждается в скилл. Бывает и обратное направление: сущность, которую интуитивно хочется назвать агентом, на старте может быть всего лишь скиллом и дорастать до полноценного агента по мере накопления собственной экспертизы.
Функциональный агент оправдан как отдельная сущность, а не скилл, когда у него есть хотя бы три из пяти свойств.
| Свойство | Что это значит |
|----------|----------------|
| **Собственный цикл рассуждений** | Агент перебирает гипотезы, итерирует, принимает промежуточные решения, а не выполняет линейный рецепт «вызови A, вызови B, склей». |
| **Собственные инструменты** | У агента есть инструменты, которых нет у Напарника, например SQL-доступ к хранилищу, RAG-поиск по документам или вызов ML-модели. |
| **Собственная память** | Агент накапливает доменные прецеденты, паттерны и метрики качества своей работы. |
| **Изолированная политика прав** | Агенту нужен доступ к данным, который по принципу минимальных прав не должен быть у Напарника. |
| **Переиспользование** | Одного и того же агента вызывают Напарники разных сотрудников. |
Если свойств нет совсем или есть только переиспользование, это скилл Напарника. Граница подвижна, и сущность может начинать жизнь как скилл и дорастать до агента ровно так же, как удачный паттерн агента может, наоборот, отчуждаться в общий скилл.
---
## Шаблон карточки агента
У всех функциональных агентов в каталоге один и тот же шаблон. Это нужно, чтобы карточки были сравнимы между собой и чтобы при внедрении не приходилось каждый раз изобретать структуру с нуля.
1. **Назначение.** Одна-две строки про то, какой класс задач закрывает агент. Если объяснить сложно, стоит вернуться к [принципам проектирования](/03-agents/#принципы-проектирования-агентов).
2. **Пользователи.** Кто из сотрудников будет ожидаемым или самым частым пользователем агента. Как правило, это не Напарник, а человек за ним. Например, категорийный менеджер коммерческой дирекции, логист направления, руководитель промо.
3. **Типовые вопросы.** Список реальных формулировок, с которыми сотрудник приходит к Напарнику и которые в итоге попадают этому агенту. Это нужно для отладки настройки агента.
4. **Используемые данные.** Источники, к которым агент обращается. Желательно с пометкой режима, например read-only, read+draft, read+write.
5. **Доступные действия и Tier автономии.** Что агент умеет делать и в каком [уровне автономии](/05-architecture/#tier-модель-автономии) каждое из этих действий выполняется. По умолчанию большинство функциональных агентов работают на Tier 1 (чтение, расчёты, подготовка артефактов внутри платформы). Действия с внешним эффектом (отправка письма, запись в учётную систему, бронирование встречи с внешним участником) идут под Tier 2 и требуют явного подтверждения сотрудника. Tier 3 (автономные действия по правилам) включается точечно по согласованным сценариям.
6. **Взаимодействие с другими агентами.** Кого вызывает или с кем работает в паре. Например, агент переговоров подтягивает Text2SQL для индексов цен и агент базы знаний для поиска прецедентов.
7. **Бизнес-эффект.** Какой эффект ожидается на цифрах. Достаточно одного-двух осмысленных тезисов.
8. **Метрики эффективности.** Как мы поймём, что агент работает. Например, время до ответа, точность диагностик, доля сценариев с использованием.
---
## Приоритетные агенты для MVP и пилота
Для первой версии концепта мы рекомендуем стартовый набор из пяти функциональных агентов плюс несколько скиллов Напарника. Состав отражает простой принцип, разобранный в разделе [«Когда агент, а когда скилл Напарника»](#когда-агент-а-когда-скилл-напарника). То, у чего есть собственный инструмент или тяжёлый фоновый цикл, выносится в отдельного агента, а сценарии, которые сводятся к [оркестрации](/05-architecture/#оркестрация-задач) сервисных агентов, остаются скиллами Напарника. Эти агенты закрывают самые понятные коммерческие сценарии, ложатся в одну архитектурную картинку и не требуют интеграций, которые невозможно собрать за разумное время.
Пост-анализ эффективности промо-акций, каннибализация, влияние на маржу. Помогает разбираться, почему одна акция сработала, а соседняя нет. Вынесен в отдельного бизнес-агента из-за тяжёлой аналитики. Подробная карточка лежит в разделе [«Агент промо»](/03-agents/#1-агент-промо).
Фоновый поиск аномалий и алгоритмический top-down разбор причин падения продаж по множеству срезов (группа, категория, бренд × сеть, регион, магазин). Выявляет проблему раньше, чем она доходит до отчёта. Подробная карточка лежит в разделе [«Агент мониторинга и аномалий»](/03-agents/#2-агент-мониторинга-и-аномалий).
Оценивает влияние решений на маржу, выручку, оборачиваемость и списания. Работает как кросс-функциональный калькулятор последствий, к которому обращаются почти все остальные агенты. Подробная карточка лежит в разделе [«Агент финансового эффекта»](/03-agents/#3-агент-финансового-эффекта).
Поиск по корпоративной базе знаний, куда входят регламенты, стандарты, прецеденты и переговорные практики. Отвечает «как мы делали это раньше» и дописывает новые прецеденты обратно в корпус. Подробная карточка лежит в разделе [«Агент базы знаний и регламентов»](/03-agents/#4-агент-базы-знаний-и-регламентов).
Переводит вопросы на естественном языке в SQL к корпоративному хранилищу и отдаёт срез данных. Базовый поставщик цифр, на котором держится работа остальных агентов. Подробная карточка лежит в разделе [«Text2SQL»](/03-agents/#5-text2sql).
Отдельных агентов под подготовку к переговорам, сравнение поставщиков, ведение досье контактов и обвязку встреч в стартовом наборе нет. Эти сценарии Напарник закрывает своими скиллами, опираясь на пятёрку агентов выше. Скилл переговоров собирает досье из Text2SQL, базы знаний и финансового эффекта, скилл встреч ищет свободный слот и работает с почтой и календарём. Подробнее о том, почему они оформлены как скиллы, в разделе [«Когда агент, а когда скилл Напарника»](#когда-агент-а-когда-скилл-напарника), а механизм скиллов разобран в [05-architecture, раздел «Скиллы»](/05-architecture/#скиллы). Полноценный [агент OOS](/03-agents/#7-агент-oos-и-запасов) и [агент встреч](/03-agents/#8-агент-встреч-и-follow-up) с расшифровками и таск-трекером отнесены в [развитие каталога](#развитие-каталога-агентов) и подключаются на следующих шагах.
:::note[Это стартовая гипотеза]
Под конкретного заказчика стартовый набор может смещаться. Если у сети нет отдельной системы ведения промо, то агент промо может уехать в бэклог, а вместо него поднимается, например, агент ценообразования и конкурентного мониторинга. Важно сохранить саму логику. Несколько сервисных агентов как фундамент (данные, финансовая модель, знания), два-три бизнес-агента на самых болезненных сценариях, а остальное закрывают скиллы Напарника поверх этого фундамента.
:::
---
## Карточки приоритетных агентов
### 1. Агент промо
**На старте.** В стартовой сборке вынесен в отдельный бизнес-агент. У него собственные расчётные скрипты разбора эффективности акций (uplift, ROI, каннибализация) и прямой доступ к данным, поэтому изоляция тяжёлой аналитики в отдельного исполнителя оправдана. По формальным критериям он пограничен, и точечный факторный разбор по конкретному срезу («почему упало вот это») остаётся скиллом Напарника ([почему](/03-agents/#когда-агент-а-когда-скилл-напарника)).
1. **Назначение.** Разбирает эффективность промо-акций. Что окупилось, что нет, где была каннибализация, где промо просто перенесло продажи во времени без прироста.
2. **Пользователи.** Категорийный менеджер, руководитель промо, коммерческий директор.
3. **Типовые вопросы.** *«Почему акция на молочку не дала ожидаемого роста?»*, *«Сравни эффективность февральских акций по кондитерке»*, *«Где в апреле была каннибализация между промо?»*, *«Готовь разбор летней промо-кампании к комитету»*.
4. **Используемые данные.** Из корпоративного хранилища приходят продажи, маржа, остатки, цены до и после. Из систем промо-планирования берутся параметры акции и планы. Данные о конкурентах подтягиваются из внешних источников, если подключены.
5. **Доступные действия и Tier автономии.** Всё, что делает агент промо, работает на [Tier 1](/05-architecture/#tier-модель-автономии). Это чтение данных, факторный анализ отклонений, оценка чистого эффекта промо, проверка гипотез о каннибализации, формирование диагностической карточки. Любые внешние действия по итогам разбора (например, отправка письма поставщику или изменение параметров будущей акции в системе планирования) проходят через Напарника и подтверждение менеджера, то есть уходят на [Tier 2](/05-architecture/#tier-модель-автономии).
6. **Взаимодействие с другими агентами.** Внутри обычно работает связкой с [агентом финансового эффекта](/03-agents/#3-агент-финансового-эффекта) (тот считает влияние на маржу) и [Text2SQL](/03-agents/#5-text2sql) (вытаскивает нужные срезы). По запросу подтягивает [агент базы знаний](/03-agents/#4-агент-базы-знаний-и-регламентов), например, чтобы найти прецеденты похожих акций.
7. **Бизнес-эффект.** Меньше промо, которые повторяются «по инерции». Раньше виден провал плохой акции, и есть шанс закрыть её или переформатировать на ходу. На горизонте квартала ожидается снижение доли неэффективных промо.
8. **Метрики эффективности.** Доля неэффективных промо на горизонте квартала. Точность оценки чистого эффекта промо по факту. Доля промо-разборов, по итогам которых принято решение (закрыть, переформатировать, повторить).
---
### 2. Агент мониторинга и аномалий
**На старте.** Полноценный агент. Несёт собственный фоновый цикл поиска аномалий и алгоритмический top-down разбор причин по множеству срезов, поэтому вопрос «агент или скилл» для него не стоит ([почему](/03-agents/#когда-агент-а-когда-скилл-напарника)).
1. **Назначение.** Находит и объясняет аномальные отклонения KPI, прежде всего падение продаж, раньше, чем они доходят до отчёта. Алгоритмически сканирует продажи по множеству срезов (группа, категория, бренд в разрезе всей сети, региона и магазина), выделяет проблемные зоны и разбирает причину каждой через drill-down.
2. **Пользователи.** Категорийный менеджер, руководитель категории, коммерческий директор.
3. **Типовые вопросы.** *«Найди аномалии в продажах за апрель»*, *«Где у нас проседает по категориям и регионам?»*, *«Почему не выполнен план продаж по моей категории?»*, *«Просканируй категории на проблемные зоны»*.
4. **Используемые данные.** Основной источник это корпоративное хранилище, откуда приходят продажи, план, остатки и цены, всё только на чтение. Для нестандартных и уточняющих срезов опирается на [Text2SQL](/03-agents/#5-text2sql).
5. **Доступные действия и Tier автономии.** На [Tier 1](/05-architecture/#tier-модель-автономии) агент сканирует данные, ищет аномалии, выполняет top-down разбор причин, формирует диагностические карточки и сводную панель, отвечает на уточняющие вопросы и отправляет сигнал Напарнику. Любое внешнее действие по итогам разбора (письмо поставщику, изменение заказа) проходит через Напарника и [Tier 2](/05-architecture/#tier-модель-автономии).
6. **Взаимодействие с другими агентами.** Отдаёт находки Напарнику. Подтягивает [агент финансового эффекта](/03-agents/#3-агент-финансового-эффекта) для оценки масштаба потерь и [Text2SQL](/03-agents/#5-text2sql) для нестандартных срезов. Работает в паре с [агентом промо](/03-agents/#1-агент-промо), когда аномалия связана с акцией.
7. **Бизнес-эффект.** Проблемы в категории видны практически сразу. Меньше «слепых зон», системные сбои всплывают раньше и с готовой фактурой для разбора.
8. **Метрики эффективности.** Время от появления аномалии до сигнала. Доля аномалий с объяснённой причиной. Доля ложных срабатываний.
---
### 3. Агент финансового эффекта
**На старте.** Полноценный сервисный агент. Имеет собственный инструментарий сценарного моделирования, поэтому вопрос «агент или скилл» для него не стоит ([почему](/03-agents/#когда-агент-а-когда-скилл-напарника)).
1. **Назначение.** Считает последствия коммерческих решений. Трансформирует гипотезы на человеческом языке в количественные метрики (цифры например по марже, выручке, оборачиваемости и списаниям).
2. **Пользователи.** Любой сотрудник, принимающий коммерческое решение. Это категорийный менеджер, прайс-менеджер, руководитель промо, директор по категориям.
3. **Типовые вопросы.** *«Что будет с маржой категории, если согласимся на +5% закупочной цены от Danone?»*, *«Сравни два варианта матрицы по эффекту на оборачиваемость»*, *«Если уберём этот SKU, что произойдёт за квартал?»*, *«Посчитай эффект промо на маржу с учётом каннибализации»*.
4. **Используемые данные.** Из хранилища берутся продажи, закупочные цены и цены продажи, маржа, остатки, списания. Финансовые модели и нормативы включают собственные нормы списаний и целевые показатели по марже. Параметры промо подтягиваются для расчёта чистого эффекта.
5. **Доступные действия и Tier автономии.** Агент финансового эффекта полностью живёт на [Tier 1](/05-architecture/#tier-модель-автономии). Это сценарное моделирование, расчёт чистого эффекта решений, сравнение вариантов, формирование короткого финансового резюме для разговора с руководителем. Никаких внешних действий он не делает по построению.
6. **Взаимодействие с другими агентами.** Этого функционального агента вызывают [агент промо](/03-agents/#1-агент-промо) (эффект акции), [агент мониторинга и аномалий](/03-agents/#2-агент-мониторинга-и-аномалий) (масштаб потерь), [агент переговоров](/03-agents/#6-агент-переговоров-и-поставщика) (последствия уступок), [агент OOS](/03-agents/#7-агент-oos-и-запасов) (стоимость потери), а также [агент ассортимента](/03-agents/#9-агент-ассортимента) (последствия делистинга), когда он подключён. В общем, практически все функциональные агенты так или иначе с ним взаимодействуют.
7. **Бизнес-эффект.** Управленческие решения принимаются с подкреплённой цифровой фактурой.
8. **Метрики эффективности.** Доля значимых решений с предварительной оценкой эффекта. Точность прогноза по факту через квартал. Оценка качества разбора менеджером.
---
### 4. Агент базы знаний и регламентов
**На старте.** Полноценный сервисный агент. RAG-индекс и семантический поиск по корпусу работают как собственный инструмент, которого нет у Напарника ([почему](/03-agents/#когда-агент-а-когда-скилл-напарника)).
1. **Назначение.** Поиск по корпоративной базе знаний. Сюда входят регламенты, стандарты, прецеденты, переговорные практики и аналитические отчёты. Умеет дописывать новые прецеденты обратно в корпус.
2. **Пользователи.** Любой сотрудник, но чаще агента вызывает не человек напрямую, а Напарник и другие агенты (переговоры, промо), когда нужны прецеденты или регламент.
3. **Типовые вопросы.** *«По какому шаблону подаётся заявка?»*, *«Какие сроки согласования промо?»*, *«Что у нас по делистингу мелких поставщиков?»*, *«Как мы раньше решали похожий спор с поставщиком?»*.
4. **Используемые данные.** Корпоративный корпус регламентов, прецедентов и переговорных практик. Режим read + write-back. Агент читает корпус и дописывает в него новые прецеденты по итогам разборов.
5. **Доступные действия и Tier автономии.** На [Tier 1](/05-architecture/#tier-модель-автономии) агент ищет по корпусу, цитирует с обязательной ссылкой на источник, формирует краткую выжимку и дописывает новый прецедент. Запись идёт во внутренний корпус платформы, поэтому остаётся в пределах Tier 1, в отличие от внешних действий.
6. **Взаимодействие с другими агентами.** Вызывается [агентом переговоров](/03-agents/#6-агент-переговоров-и-поставщика) (прецеденты и регламенты), [агентом промо](/03-agents/#1-агент-промо) (похожие акции) и Напарником напрямую. Технически роль может расщепляться на агент регламентов и агент прецедентов, если они живут в разных системах (см. [открытые вопросы](#открытые-вопросы)).
7. **Бизнес-эффект.** Знания перестают жить «в головах» двух-трёх человек. Прецеденты и регламенты переиспользуются, адаптация нового сотрудника ускоряется.
8. **Метрики эффективности.** Доля ответов с корректной ссылкой на источник. Покрытие корпуса. Частота переиспользования прецедентов в реальных сценариях.
---
### 5. Text2SQL
**На старте.** Полноценный сервисный агент и фундамент всего набора. Собственный инструмент это SQL-доступ к хранилищу, которого по принципу минимальных прав нет у Напарника ([почему](/03-agents/#когда-агент-а-когда-скилл-напарника)).
1. **Назначение.** Переводит вопросы на естественном языке в SQL к корпоративному хранилищу и возвращает срез данных. Базовый источник цифр, на который опираются остальные агенты.
2. **Пользователи.** Напрямую человеком почти не вызывается. Его вызывают Напарник и другие агенты, когда нужен нестандартный срез, которого нет в готовых витринах.
3. **Типовые вопросы.** Приходят в основном от других агентов. Например, *«продажи и маржа по молочке за март в разрезе регионов»*, *«доля SKU поставщика в категории»*, *«остатки на РЦ по списку SKU»*.
4. **Используемые данные.** Корпоративное хранилище (DWH, реляционная база) строго в режиме read-only. Доступ ограничен по принципу минимальных прав, без права записи.
5. **Доступные действия и Tier автономии.** Только [Tier 1](/05-architecture/#tier-модель-автономии): строит и выполняет читающие запросы, формирует выборки. Никаких записей и внешних действий по построению.
6. **Взаимодействие с другими агентами.** Вызывается практически всеми, а именно [агентом промо](/03-agents/#1-агент-промо), [агентом мониторинга и аномалий](/03-agents/#2-агент-мониторинга-и-аномалий), [агентом финансового эффекта](/03-agents/#3-агент-финансового-эффекта) и [агентом переговоров](/03-agents/#6-агент-переговоров-и-поставщика). Сам никого не инициирует, работает как инструмент.
7. **Бизнес-эффект.** Данные хранилища становятся доступны на естественном языке, без знания SQL и без аналитика-посредника между вопросом и цифрой.
8. **Метрики эффективности.** Доля корректных и исполнимых запросов. Время до ответа. Доля вопросов, закрытых без ручной доработки SQL.
---
## Развитие каталога агентов
После пяти приоритетных идёт развитие каталога. Первыми на очереди три сценария, которые в стартовой сборке закрыты скиллами Напарника или отложены, но имеют проработанные карточки, потому что входят в ближайший контур развития. Дальше идёт длинный хвост, по абзацу на агента, чтобы заказчик и команда внедрения видели, куда платформа может расти.
### 6. Агент переговоров и поставщика
**На старте.** Реализован как скилл Напарника, а не как отдельный агент. Собирает досье из сервисных агентов по устойчивому рецепту, собственного цикла рассуждений пока нет. До агента дорастает по мере накопления переговорной памяти и паттернов ([почему](/03-agents/#когда-агент-а-когда-скилл-напарника)).
1. **Назначение.** Готовит досье на поставщика и аргументацию к встрече. Подсвечивает сильные и слабые позиции и собирает прецеденты и цифры, которые должны лежать перед менеджером во время разговора.
2. **Пользователи.** Категорийный менеджер, руководитель направления, директор по закупкам.
3. **Типовые вопросы.** *«Поставщик X просит +5% к закупочной цене, встреча завтра»*, *«Подготовь досье на Saverio к четвергу»*, *«Что у нас в прецедентах по делистингу мелких поставщиков»*, *«Что предъявить Danone по SLA за квартал»*.
4. **Используемые данные.** Из корпоративного хранилища берутся закупки, продажи, маржа, доля в категории. Информация о SLA включает фактический fill rate, недопоставки, штрафы. Дополняют картину внешние индексы цен на сырьё и упаковку, а также корпоративная база знаний со стандартами переговоров, прецедентами прошлых уступок и историей переписки с поставщиком.
5. **Доступные действия и Tier автономии.** На [Tier 1](/05-architecture/#tier-модель-автономии) агент собирает досье, рассчитывает основные индикаторы поставщика, ищет прецеденты, формирует аргументационный пакет и готовит слайды по корпоративному шаблону. Всё это остаётся внутри платформы. Любая внешняя коммуникация с поставщиком (письмо, запрос на пересмотр условий, инициирование штрафной процедуры) идёт через Напарника и [Tier 2](/05-architecture/#tier-модель-автономии), то есть подтверждается менеджером явно.
6. **Взаимодействие с другими агентами.** Вызывает Text2SQL для коммерческих срезов, [агент финансового эффекта](/03-agents/#3-агент-финансового-эффекта) для оценки последствий уступок, [агент базы знаний](/03-agents/#4-агент-базы-знаний-и-регламентов) для прецедентов и регламентов. Часто работает в паре с [агентом OOS](/03-agents/#7-агент-oos-и-запасов), если претензия касается поставок.
7. **Бизнес-эффект.** Доля встреч с подготовленным досье растёт с типичных 20% до подавляющего большинства. На переговорной марже это даёт прямой P&L-эффект, на масштабе крупной сети речь идёт о десятках миллионов рублей в год.
8. **Метрики эффективности.** Доля переговоров с готовым досье. Оценка качества досье менеджером после встречи. Эффект на бэк и фронт маржу в когорте подготовленных встреч против неподготовленных.
---
### 7. Агент OOS и запасов
**На старте.** Пограничный случай. В проактивном причинно-следственном режиме это полноценный агент, в реактивном «ответь по запросу» скорее скилл Напарника ([почему](/03-agents/#когда-агент-а-когда-скилл-напарника)).
1. **Назначение.** Отслеживает доступность товара, разбирает причины out-of-stock и предлагает действия. Агент работает преимущественно в фоне и инициативно сигналит, когда видит проблему. Но может работать и по запросу.
2. **Пользователи.** Категорийный менеджер, логист направления, операционный руководитель кластера.
3. **Типовые вопросы.** *«Почему по этим SKU третий день нулевой остаток?»*, *«Какие SKU сейчас под угрозой OOS на следующей неделе?»*, *«Разбери, что произошло с поставками молочки за март»*, *«Где у нас регулярные сбои по моей категории на конкретных РЦ»*.
4. **Используемые данные.** Основной источник данных это корпоративное хранилище. Оттуда приходят остатки на РЦ и в магазинах, продажи, прогноз спроса, поставки, графики и фактические даты прихода (обычно эти данные WMS регулярно выгружает в DWH). SLA-данные поставщиков включают fill rate, отказы, замены. Календарь промо нужен, чтобы понимать ожидаемый всплеск спроса. Прямое подключение к WMS возможно как исключение для сценариев, где нужна оперативность, которой суточная выгрузка не обеспечивает.
5. **Доступные действия и Tier автономии.** На [Tier 1](/05-architecture/#tier-модель-автономии) агент считает текущий и прогнозный OOS, разбирает причины (недопоставка, недостаточный заказ, ошибка прогноза, всплеск спроса), формирует рекомендации (переключение на альтернативный РЦ, экстренный заказ, временная замена SKU) и отправляет алерт Напарнику. Само исполнение рекомендации (размещение заказа, изменение графика поставок) подтверждается менеджером или логистом и проходит под [Tier 2](/05-architecture/#tier-модель-автономии). Стандартное переключение между РЦ при OOS ниже согласованного порога может быть точечно вынесено в [Tier 3](/05-architecture/#tier-модель-автономии), но только по отдельно согласованному сценарию.
6. **Взаимодействие с другими агентами.** Работает в паре с [агентом переговоров](/03-agents/#6-агент-переговоров-и-поставщика), когда речь идёт о систематических сбоях у поставщика. Подтягивает [агент финансового эффекта](/03-agents/#3-агент-финансового-эффекта) для оценки потерянной выручки. Использует Text2SQL для нестандартных срезов.
7. **Бизнес-эффект.** Время от появления проблемы до её обнаружения сокращается с часов и дней до минут. Системные проблемы у конкретных поставщиков становятся видны раньше, и появляется фактура для разговора с ними. На полке становится меньше пустых мест, и выручка категории растёт.
8. **Метрики эффективности.** Время от события OOS до алерта. Доля OOS-инцидентов с предложенным решением до принятия менеджером. Динамика fill rate по проблемным поставщикам.
---
### 8. Агент встреч и follow-up
**На старте.** Полноценным агентом в стартовый набор не входит. Его обвязку (поиск свободного слота, создание встречи, работа с почтой и календарём) на старте закрывают скиллы Напарника. Отдельным агентом с расшифровками встреч, памятью по участникам и таск-трекером он становится на следующем шаге, когда выполняются все пять критериев ([почему](/03-agents/#когда-агент-а-когда-скилл-напарника)).
1. **Назначение.** Этот агент делает работу со встречами более осмысленной. Логистику (поиск свободного слота, создание встречи, приглашения) он оставляет календарному скиллу Напарника, а сам отвечает за содержание. До встречи готовит участникам короткий бриф, во время встречи фиксирует договорённости, после превращает их в задачи, рассылает Напарникам участников и (опционально) сам контролирует исполнение. Ищет по расшифровкам всех встреч.
2. **Пользователи.** Любой сотрудник, у которого встречи занимают значимую часть дня. Это категорийный менеджер, руководитель направления, директор.
3. **Типовые вопросы.** *«Что было на встрече с поставщиком в прошлый четверг?»*, *«Кто что обещал сделать к среде по итогам комитета»*, *«Напомни, на чём мы остановились с Ивановым по промо»*.
4. **Используемые данные.** Расшифровки встреч, корпоративный мессенджер для напоминаний и сбора статусов, таск-трекер для постановки задач. Доступ к календарю сотрудника и его коллег идёт через календарный скилл Напарника.
5. **Доступные действия и Tier автономии.** На [Tier 1](/05-architecture/#tier-модель-автономии) агент формирует повестку, расшифровывает встречу, выделяет договорённости и дедлайны, готовит черновики follow-up. Бронирование встречи с внешним участником, постановка задачи коллеге в таск-трекере и отправка приглашений идут под [Tier 2](/05-architecture/#tier-модель-автономии) и проходят через подтверждение сотрудника (само бронирование и приглашения выполняет календарный скилл Напарника). В [Tier 3](/05-architecture/#tier-модель-автономии) могут быть вынесены рутинные напоминания об уже поставленных задачах и стандартные эскалации при пропуске согласованных сроков. Каждый Tier 3 сценарий согласовывается с комплаенсом отдельно.
6. **Взаимодействие с другими агентами.** Часто работает в паре с [агентом переговоров](/03-agents/#6-агент-переговоров-и-поставщика) и [агентом базы знаний](/03-agents/#4-агент-базы-знаний-и-регламентов). Они готовят содержательное наполнение брифа, а агент встреч обеспечивает «обвязку», то есть время, формат и постановку задач после.
7. **Бизнес-эффект.** Сотрудник перестаёт быть контролёром. Договорённости со встреч не теряются, follow-up не превращается в работу самого менеджера. На горизонте месяца это видно по сокращению просроченных задач и по числу встреч, которые начинаются с готовой повестки.
8. **Метрики эффективности.** Доля встреч с автоматически сформированной повесткой. Доля договорённостей, превратившихся в задачи в течение часа после встречи. Число просроченных follow-up'ов до и после внедрения.
---
После трёх карточек ближайшего контура идёт длинный хвост. На первой версии каталога описывать его подробно не будем, обозначим пока одним абзацем на агента.
### 9. Агент ассортимента
Помогает работать с матрицей. Подсвечивает, где избыточные SKU, где, наоборот, не хватает позиций под спрос, какие листинги стоят дороже, чем приносят. Полезен в момент пересмотра матрицы и при подготовке ассортиментного комитета.
*На старте это скилл Напарника. Оркестрирует Text2SQL и финансовый эффект по линейному рецепту, дорастает до агента с собственной библиотекой паттернов матрицы.*
### 10. Агент ценообразования и конкурентного мониторинга
Анализирует ценовое позиционирование, оценивает эластичность по категориям и подсказывает, где переоценка даст эффект. Сам собирает рыночные данные о ценах, ассортименте и промо конкурентов, сравнивает с собственным предложением и выявляет разрывы. Полезен прайс-менеджерам и руководителям категорий, тесно связан с агентом финансового эффекта. На пилоте чаще всего идёт через внешние источники данных и требует отдельной интеграции.
*Полноценный агент. У него собственный внешний сбор конкурентных данных и изолированный доступ к внешним источникам, которых нет у Напарника, а на зрелом этапе возможен и собственный движок оценки эластичности.*
### 11. Агент факторного анализа
Раскладывает изменение показателя (выручка, маржа, средний чек, трафик) на вклад отдельных факторов (цена, объём, микс, промо, потери, списания) и помогает понять, что именно сдвинуло результат. Отвечает на вопрос «почему изменилось», в отличие от агента финансового эффекта, который отвечает «что будет, если».
*Скорее скилл. Это аналитический метод без собственных инструментов и данных. Точечный факторный разбор Напарник уже делает скиллом, а более тяжёлый отдаёт агенту промо. Выделять в отдельного агента имеет смысл, только когда у него появляется собственная библиотека факторных моделей.*
### 12. Агент прогнозирования
Прогноз спроса по SKU и категориям. Под капотом обычно стоит ML-модель, задача агента — обернуть её в удобный интерфейс, подтянуть промо-календарь и сезонность, сделать прогноз пригодным для разговора. Часто вызывается агентом OOS и агентом ассортимента.
*Полноценный агент. Под капотом у него собственная ML-модель, то есть инструмент, которого нет у Напарника.*
### 13. Коллективная память и агент-куратор
Накопление паттернов успешных решений всей команды (разборы кейсов, удачные тактики переговоров, нестандартные диагностики) это **слой памяти платформы**, но не отдельный функциональный агент. У него нет ни собственного класса бизнес-задач, ни цикла рассуждений, поэтому в каталоге агентов самой памяти не место. Подробно роль слоя описана в [05-architecture, раздел «Коллективная память»](/05-architecture/#коллективная-память).
Отдельно от хранилища стоит **агент-куратор коллективной памяти**, и вот он уже полноценный фоновый агент. Он ищет повторяющиеся паттерны в сессиях разных Напарников, оценивает их по частоте и устойчивости и предлагает кандидатов на вынос в общий слой (механизм описан в том же разделе [05-architecture](/05-architecture/#коллективная-память)). По свойствам он близок к [агенту мониторинга и аномалий](/03-agents/#2-агент-мониторинга-и-аномалий), то есть несёт собственный фоновый цикл, своё состояние и проактивность. Эту сущность и осмысленно оставлять в каталоге, а не «память» как таковую.
---
## Открытые вопросы
Здесь темы, по которым у концепта пока нет финального ответа. Часть из них требует отдельной проработки, часть решается только под конкретного заказчика.
:::caution[Где граница между скиллом Напарника и отдельным агентом]
Тест из раздела [«Когда агент, а когда скилл Напарника»](#когда-агент-а-когда-скилл-напарника) даёт практический ориентир (отдельный агент оправдан при трёх свойствах из пяти), но сам порог это скорее соглашение, но не строгое правило. Ряд сущностей сидит ровно на этой границе. Агент промо, агент OOS и агент ценообразования по формальным критериям пограничны, и отнесение их к агенту или скиллу меняется в зависимости от режима работы и зрелости внедрения. Сложнее то, что граница подвижна в обе стороны. Скилл дорастает до агента по мере накопления собственной экспертизы, а удачный паттерн агента, наоборот, отчуждается в общий скилл. Кто принимает это решение, по какому сигналу и в какой момент скилл «выпускается» в отдельного агента, концепт не формализует. Ошибка стоит дорого в обе стороны. Поспешно вынесенный агент добавляет инфраструктуру и стоимость там, где хватило бы инструкции в промпте, а запоздалое решение раздувает промпт Напарника линейными рецептами, которые давно просятся в отдельного исполнителя. На старте этот выбор делается экспертно и пересматривается под конкретного заказчика.
:::
:::caution[Где именно резать перекрытие между агентами]
Принцип «один агент, один класс задач» звучит как правило, но на практике это скорее суждение. Агент финансового эффекта («что будет, если») и агент факторного анализа («почему изменилось») работают с одними данными и легко сливаются в один. То же касается агента OOS и агента прогнозирования, который легко растворяется внутри него. Где проходит граница между «здоровой специализацией» и «искусственным дроблением», документ не формализует.
:::