Агенты в производстве: четыре реальных примера использования

Демонстрации агентов впечатляют. Их развёртывание — настоящий беспорядок. Разрыв между «работает на моём ноутбуке» и «работает в продакшене» заполнен граничными случаями, неожиданными расходами и режимами отказов, к которым не готовит ни один учебник.

Мы все видели красивое демо: агент бронирует рейс, пишет отчёт и заводит баг — всё за двухминутную запись экрана. Чего вы не видите — это 40% случаев эскалации на первой неделе, счёт в $12 за запрос к API или агент, который «исправил» проблему с повреждением данных, сделав её ещё хуже.

Эти четыре примера закрывают этот разрыв. Они охватывают реальные архитектуры, реальные цифры и реальные ошибки из производственных развёртываний агентов. Каждый пример самодостаточен — читайте все четыре или сразу переходите к тому, который соответствует вашему случаю.

Что вы узнаете:

• Как была спроектирована каждая система и почему
• Что сработало, а что с треском провалилось
• Конкретные метрики: точность, стоимость, задержка и частота ручного переопределения
• Извлечённые уроки, применимые в разных областях

Пример 1: Агент сортировки обращений в службу поддержки

Проблема

Среднего размера SaaS-компания (программное обеспечение как услуга) получает более 500 обращений в службу поддержки ежедневно. Ответы первого уровня — сбросы паролей, вопросы по выставлению счетов, известные обходные пути для ошибок — занимают примерно 60% рабочего времени команды поддержки. Инженеры, которые должны решать сложные задачи, копируют и вставляют ответы на одни и те же десять вопросов.

Бизнес-цель была ясна: автоматизировать разрешение обращений первого уровня без снижения удовлетворённости клиентов.

Архитектура

┌─────────────────────────────────────────────────┐
│                 Incoming Ticket                  │
└──────────────────────┬──────────────────────────┘
                       │
                       ▼
              ┌────────────────┐
              │  Router Agent  │
              │ (Intent Class.)│
              └──┬───┬───┬──┬─┘
                 │   │   │  │
        ┌────────┘   │   │  └────────┐
        ▼            ▼   ▼           ▼
   ┌─────────┐ ┌────────┐ ┌──────┐ ┌──────────┐
   │ Billing │ │Technical│ │Account│ │ Feature  │
   │ Handler │ │ Handler │ │Handler│ │ Request  │
   └────┬────┘ └───┬────┘ └──┬───┘ └────┬─────┘
        │          │         │           │
        └──────────┴────┬────┴───────────┘
                        ▼
              ┌──────────────────┐
              │ Confidence Check │
              │  ≥ 0.85 → Reply │
              │  < 0.85 → Human │
              └──────────────────┘

Инструменты и интеграции:

• API системы обращений (Zendesk) для чтения и ответа на заявки
• Поиск по базе знаний (векторное хранилище статей справки)
• Поиск данных клиента (статус аккаунта, уровень подписки, последние взаимодействия)

Ключевая конфигурация:

router_agent:
  model: gpt-4o-mini
  system_prompt: |
    You are a support ticket classifier. Classify into exactly one category:
    billing, technical, account, feature_request.
    Return JSON: {"category": "...", "confidence": 0.0-1.0, "summary": "..."}
  temperature: 0.0

handler_agents:
  escalation_threshold: 0.85
  max_knowledge_base_results: 5
  response_tone: "professional, empathetic, concise"

Результаты

Что не сработало

Чрезмерная эскалация на первой неделе. Начальная частота эскалации составляла 40%. Агент-маршрутизатор был слишком осторожен — любое обращение с неоднозначными формулировками передавалось человеку. Решение: снижение порога уверенности с 0,95 до 0,85 и добавление нескольких примеров пограничных обращений в подсказку маршрутизатора.

Граничные случаи в выставлении счетов. Частичные возвраты, спорные списания и многоаккаунтное выставление счетов требовали тонкого суждения человека. Агент иногда предлагал полный возврат, тогда как политика допускала только частичный. Решение: жёстко закодированные правила для финансовых действий. Агент может объяснить политику, но не может выполнять финансовые операции на сумму свыше $20 без одобрения человека.

Устаревшая база знаний. Агент сослался на статью справки, описывавшую интерфейс, изменившийся два месяца назад. Клиент следовал инструкциям, запутался и эскалировал ситуацию с раздражением. Решение: автоматические проверки актуальности — статьи, не обновлявшиеся 90 дней, помечаются флагом, а агент добавляет предупреждение при ссылке на устаревший контент.

Извлечённые уроки

• Начните с самой простой категории. Вопросы в формате FAQ имели наибольший уровень автоматизации. Выставление счетов — последним.
• Измеряйте удовлетворённость клиентов, а не только уровень решения. Закрытое обращение с недовольным клиентом — не успех.
• Актуальность базы знаний так же важна, как и качество агента. Лучший в мире агент не компенсирует устаревшую документацию.

Пример 2: Агент исследований и генерации отчётов

Проблема

Консалтинговая команда тратит 8–12 часов в неделю на составление отчётов по анализу рынка из нескольких источников данных: новостных API, финансовых баз данных и внутренних документов. Отчёты имеют единообразную структуру, но сбор данных — утомительный и чреватый ошибками процесс. Аналитики тратят большую часть времени на сбор информации, а не на её анализ.

Архитектура

┌────────────────────────────────────┐
│         Research Brief (User)      │
└──────────────────┬─────────────────┘
                   ▼
         ┌──────────────────┐
         │ Orchestrator Agent│
         │ (Task Decomposer)│
         └──┬──────┬──────┬─┘
            │      │      │
     ┌──────┘      │      └──────┐
     ▼             ▼             ▼
┌──────────┐ ┌──────────┐ ┌───────────┐
│  News    │ │ Financial│ │ Internal  │
│  Worker  │ │  Worker  │ │ Doc Worker│
└────┬─────┘ └────┬─────┘ └─────┬─────┘
     │             │             │
     └──────┬──────┴─────────────┘
            ▼
    ┌───────────────┐
    │Synthesis Agent│
    │(Report Writer)│
    └───────┬───────┘
            ▼
    ┌───────────────┐
    │ Review Agent  │
    │(Verification) │
    └───────┬───────┘
            ▼
    ┌───────────────┐
    │ Final Report  │
    │ (w/ Citations)│
    └───────────────┘

Инструменты и интеграции:

• Новостной API (NewsAPI, Google News) для актуальных событий и отраслевого покрытия
• API финансовых данных (Alpha Vantage, внутреннее хранилище данных) для рыночных данных
• Поиск по внутренним документам (векторное хранилище прошлых отчётов и брифов клиентов)
• Генерация структурированного вывода (конвейер Markdown → PDF)

Ключевая конфигурация:

orchestrator:
  model: gpt-4o
  decomposition_strategy: "parallel_by_source"
  max_sub_tasks: 8

synthesis_agent:
  citation_requirement: "Every factual claim MUST include [Source: ...] inline"
  output_format: "structured_markdown"
  sections:
    - executive_summary
    - market_overview
    - competitive_landscape
    - financial_highlights
    - risks_and_opportunities
    - appendix_sources

review_agent:
  checks:
    - contradiction_detection
    - citation_verification
    - data_recency (max_age_days: 30)
    - completeness (all_sections_present: true)

Результаты

Связанные статьи

• Восстановление Агентов После Ошибок: 5 Паттернов для Продакшн-Надёжности
• Мультиагентные паттерны: оркестраторы, воркеры и конвейеры
• Отладка и Наблюдаемость в Системах Автономных Агентов
• Стратегии кэширования для AI-агентов: снижение затрат без потери качества
• Паттерны использования инструментов: надёжные интерфейсы агент-инструмент