Оркестратор агентов поддержки

Первая линия поддержки разбирала около 4 000 обращений в месяц. Половина из них — повторяющиеся вопросы про биллинг, доступы и настройку интеграций. Ответы существовали в документации и в истории тикетов, но найти их было быстрее у коллеги, чем в поиске.

Обычный чат-бот на FAQ уже пробовали: он отвечал общими фразами и раздражал пользователей, потому что не мог посмотреть состояние аккаунта. Нужна была система, которая читает контекст конкретного клиента, умеет выполнять действия и при этом не имеет права ошибиться в биллинге и правах доступа.

Граф из четырёх агентов с явными границами ответственности. Классификатор определяет тип обращения и уровень риска. Retrieval-агент собирает контекст из документации, changelog и похожих закрытых тикетов. Action-агент работает с CRM и биллингом строго по allowlist инструментов. Supervisor проверяет ответ на соответствие политике и решает: отправить, запросить уточнение или эскалировать оператору. Все операции с деньгами и правами всегда требуют подтверждения человека.

1. Обращение принято

   Тикет из хелпдеска или сообщение из чата попадает в единую очередь. Определяются язык, тональность и признак срочности.

2. Классификация и оценка риска

   Агент относит обращение к одной из 18 категорий и присваивает уровень риска. Всё, что касается денег, персональных данных и прав доступа, сразу получает высокий уровень.

3. Сбор контекста

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

4. Подготовка решения

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

5. Проверка и исполнение

   Supervisor сверяет ответ с политикой поддержки. Низкий риск — отправка автоматически. Высокий — карточка с готовым решением уходит оператору на подтверждение в один клик.

6. Обратная связь в систему

   Правки оператора и оценки пользователей попадают в набор для evals. Раз в неделю набор прогоняется на регрессиях перед выкаткой изменений промптов.

• Zendesk API
• HubSpot CRM
• Stripe Billing (только чтение)
• Slack — эскалации и дежурства
• Внутренний Docs API

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

• Набор из 320 размеченных обращений как регрессионный eval, прогон на каждый релиз промптов
• Allowlist инструментов: агент видит только 9 разрешённых операций, всё остальное недоступно физически
• Human-in-the-loop обязателен для биллинга, прав доступа и удаления данных
• Ответ без найденных источников не отправляется — обращение уходит оператору
• Трейсинг каждого шага через OpenTelemetry, в логи не попадает текст сообщений пользователей
• Лимиты по токенам, времени и стоимости на обращение; при превышении — мягкая деградация в эскалацию
• Ежедневный отчёт по расхождениям между решением агента и правкой оператора

• −42%

  Ручные обращения первой линии

  Сравнение трёх месяцев после запуска с тремя месяцами до, при сопоставимом объёме входящих.

• 6 мин → 40 с

  Медианное время первого ответа

  Медиана по всем каналам, включая обращения, ушедшие на эскалацию.

• 94%

  Точность на регрессионном наборе

  Доля ответов, принятых оператором без правок, на 320 размеченных обращениях. Замер на релизе.

• $0.11

  Стоимость обработки обращения

  Средние расходы на модель и инфраструктуру, без учёта работы оператора.

• Архитектура графа агентов, границы ответственности и модель рисков — лично
• Retrieval-слой, гибридный поиск и стратегия чанкинга — лично
• Каркас evals и регрессионный набор — лично, разметка — совместно с командой поддержки
• Интеграции с Zendesk и HubSpot — команда клиента, я вёл ревью и приёмку
• Фронтенд карточки подтверждения для операторов — дизайнер и фронтенд-разработчик клиента

• TypeScript
• Python
• LangGraph
• Claude
• pgvector
• PostgreSQL
• Temporal
• OpenTelemetry