← Университет

Реальный опыт практиков: AI Agents в production

Что сработало, что провалилось, грабли и уроки (2025-2026)

Введение: За что страдают практики

AI agents (автономные агенты на базе LLM) активно внедряются в production, но реальность оказалась жестче пилотов и демонстраций. По данным Composio (2025), 95% пилотов AI agents падают при масштабировании — не из-за качества моделей, а из-за инженерных ошибок, интеграционных проблем и фундаментальных ограничений архитектуры.

Практики из Medium, Hacker News, блогов и Reddit делятся конкретными историями отказов. Вот что работает и что не работает в реальности.

1. Вероятностные отказы: "Loop of Death" и каскадные ошибки

Проблема: Умножение вероятности

Одна из главных открытий практиков — multi-step agents — это распределённые системы. При точности 95% на каждом шаге, 10-шаговая задача имеет вероятность полного успеха:

0.95^10 ≈ 0.60 (только 60% успеха)

Как описывает Wassim Chegham (DEV Community): "Multi-step AI agents are distributed systems" — каждый вызов tool calling может зависнуть, вернуть неполные данные или выбрать неправильный инструмент.

Пять типичных сбоев в цепи:

  1. Неправильный выбор инструмента — агент выбирает отель вместо трекера маршрутов
  2. Таймауты API — внешние сервисы медленные, агент галлюцинирует результаты вместо retry
  3. Частичные ошибки — API возвращает 2 результата вместо 15, агент выбирает из неполного набора
  4. Несогласованность — на шаге 1 выбран Париж, на шаге 5 рекомендует ресторан в Лондоне
  5. Каскадные ошибки — ошибка на шаге 2 разрушает весь план к шагу 7

"Loop of Death" (Sattyam Jain, Medium, Jan 2026)

Agentsзастревают в бесконечном цикле исправления ошибок:

  1. Агент пишет код с ошибкой
  2. Среда выполнения выдает ошибку
  3. Агент пытается "исправить" проблему
  4. "Исправление" создает новую ошибку
  5. Цикл повторяется — "Each iteration burns your most expensive, high-latency tokens"

Компания решила эту проблему через архитектуру с трёхуровневыми вычислениями (Tiered Computation): - Smart Routing — малая модель классифицирует задачи, простые → дешевые модели (GPT-3.5, Claude Haiku), сложные → frontier (GPT-4, Claude Opus) - Semantic Caching — промежуточные результаты кешируются; 40% подзадач обслуживаются из кеша без токенов - Sandboxed Execution — код выполняется в изолированных контейнерах с таймаутом и лимитом повторов (max 3 попытки)

Результат: снижение расходов на 70%, надежность 99.9%, задержка −40%.

2. Интеграционные проблемы: Brittle Connectors, RAG Hallucinations, Polling Tax

"Dumb RAG" Галлюцинации

Composio (2026) выявил, что главная причина падения пилотов — не модель, а интеграция:

"Dumping all your Confluence docs into a vector database, hoping the LLM figures it out" — это classic Dumb RAG.

Вместо фильтрации релевантных документов, система загружает весь контекст, что приводит к: - Галлюцинациям на основе шума в данных - Конфликтам между устаревшей и текущей информацией - Потере точности при большом объеме контекста

Решение: семантическая фильтрация + ранжирование по релевантности перед передачей в агент.

Brittle Connectors: API интеграции падают

Когда агент пытается интегрироваться с legacy системами: - Недокументированные поля в API ответах - Версионные изменения API без предупреждения - Таймауты и rate limiting не обработаны - Агент не различает 404 (нет данных) от 500 (ошибка сервера)

Пример: стартап потратил €5,000 на оптимизацию времени отправки писем, но агент просто не проверял statuses от почтового сервиса.

Polling Tax: 95% запросов впустую

Система постоянно опрашивает (polls) API вместо event-driven архитектуры: - Агент каждые 5 секунд проверяет статус задачи - 95% запросов возвращают "no change" - Пропорционально растут затраты на API и сбои от rate limiting

Решение: webhooks и event streams вместо polling.

3. Архитектурные ошибки: 7 критических просчётов

Отсутствие постоянной идентичности (Persistent Identity)

Агент теряет память между сессиями: - Повторяет старые ошибки - Меняет стиль общения - Переоткрывает одну информацию множество раз

Решение: memory layer (вектор-база с session state, short-term context buffer).

Крайние подходы к автономности

  1. Полная зависимость от одобрения — каждое действие требует approval → узкое место (может обработать только 10-20 задач/день)
  2. Полная автономия — агент отправляет неправильные письма, постит в соцсети ошибки, разворачивает broken код

Работающий подход: tiered autonomy: - Низкий risk (чтение данных) → автономия 100% - Средний risk (отправка письма) → требуется approval - Высокий risk (платежи, удаления) → требуется человек + double-check

Игнорирование модели затрат (Cost Model)

Проблема: 70% оплаченных токенов не приносят реальной ценности.

Многоагентные системы требуют 15x больше токенов vs простой чат: - Каждый агент имеет локальный контекст (дублирование) - Постоянные переключения контекста между агентами - Отсутствие кеширования prompts

Пример чисел (Michael Hannecke): - GPT-4 agent: $0.03-0.05 за одну задачу - Claude Opus: $0.01-0.02 за одну задачу - Чистый чат: $0.0005 за одну задачу

Решение: маршрутизация по стоимости + семантический кеш.

Нет одобрения для внешних действий

Агент выполняет необратимые действия без проверки: - Отправляет письма - Постит в соцсети - Создаёт ресурсы (инстансы, базы данных) - Удаляет данные

Случай: McDonald's AI для ответов на жалобы клиентов давал сарказм и оскорбления — стал вирусным, компания отключила систему.

4. Specification Issues: Агенты игнорируют ограничения

14 паттернов отказов (по Michael Hannecke):

  1. Игнорируют ограничения — задача говорит "максимум 5 попыток", агент делает 100
  2. Повторяют шаги — циклятся на уже выполненных операциях
  3. Теряют контекст диалога — в многошаговом разговоре забывают о целях
  4. Не распознают условия завершения — не понимают, когда задача готова

Пример: - Задача: "Найди товар дешевле $50" - Агент находит товар за $48 - Но продолжает искать, создав 50 запросов вместо одного

Inter-Agent Misalignment

Когда несколько агентов работают параллельно: - Скрывают информацию друг от друга - Игнорируют рекомендации коллег-агентов - Отклоняются от целей при разных интерпретациях задачи

Проблема координации (Codemanship Blog): При использовании нескольких агентов параллельно они создают конфликты интеграции, которые "breaks the build, and once the build's broken, everybody's blocked."

5. Production vs Demo: Математика надежности

Почему демо работают, но production падает

Пять причин (Wassim Chegham, DEV Community):

  1. Дизайн для happy path — demo тестирует только идеальный сценарий
  2. Отсутствие таймаутов — demo работает локально, нет сетевых задержек
  3. Малый размер контекста — demo использует 100 записей, production — 1 млн
  4. Нет обработки edge cases — demo не тестирует пустые результаты, null значения
  5. Отсутствие трассировки — нет логирования промежуточных шагов для отладки

Решение: Selective Autonomy + Operation Tracing

Selective Autonomy: - Вставьте человеческие проверки перед дорогостоящими решениями - Каждая проверка "перезагружает" вероятность ошибки (0.95^5 вместо 0.95^10)

Operation Tracing:

"Capture the full execution path: reasoning, tool calls, latency, outputs"

Для каждого шага логируйте: - Какой инструмент выбран и почему - Входные параметры - Время ответа (latency) - Полный вывод - Какое решение принято на основе вывода

Практический пример: Компания потеряла €50k, потому что агент молча вернул неверные результаты. После добавления трассировки идентифицировали проблему за 30 минут.

6. Claude Code / Coding Agents: Реальные lessons learned

Sanity's Experience: "First Attempt Will Be 95% Garbage"

Vincent Quigley, staff engineer в Sanity (2025), поделился тремя ключевыми открытиями:

Проблема обучения (Learning Problem)

"AI doesn't learn from mistakes. You fix the same misunderstandings repeatedly."

Моделям нужно напоминать о контексте на каждом шаге. Нет накопления опыта в рамках сессии.

Решение: explicit error annotations в промпте:

# Вы допустили ошибку в file.ts строка 42:
# Неправильно: const x = JSON.parse(data) // может выбросить исключение
# Правильно: const x = JSON.parse(data); } catch { ... }

Трёхэтапный workflow

  1. Первая попытка (95% мусора) — AI строит контекст, вы выявляете реальные проблемы
  2. Вторая попытка (50% мусора) — нюансы уточнены, но может быть ещё неработаемо
  3. Третья попытка — получается итерируемый результат

Управление несколькими agents: - Не параллелизируйте одну проблему (конфликты) - Отслеживайте в Linear/Jira - Помечайте отредактированный код явно

Конкретные метрики

Метрика Значение
Скорость доставки фич 2-3x быстрее
Стоимость/месяц (senior) $1000-1500
Код из AI 80% начальных реализаций
Сфокусированность инженера На архитектуре и review вместо рутины

Sankalp's Claude Code 2.0 Best Practices

Правильный workflow: - Opus 4.5 для исходящей разработки и кодирования - GPT-5.2-Codex для проверки кода и поиска ошибок (дешевле) - Черновой подход — первый проход для понимания, второй для улучшения

Критические ошибки: 1. Переполнение окна контекста — эффективное окно вероятно 50-60% от заявленного 2. Не начинайте сложные задачи на половине разговора — качество деградирует 3. Использование /compact перед новой сессией — сжимает старый контекст

Обязательные фичи: - Sub-agents (Explore, Plan) для сложного поиска в больших кодобейсах - /context для явного контроля использования токенов - Custom commands для повторяющихся задач - Checkpointing для перемотки

Избегайте: - Множественные MCP серверы (раздувают контекст непредсказуемо) - Излишние кастомные sub-agents без необходимости

7. Метрики отказов: Числа, которые должны вас насторожить

Tool Calling Failure Rates

Метрика Значение
Частота отказов tool calling 3-15% в production
Уязвимость к prompt injection 11.2% (улучшено с 23.6%)
Точность Microsoft ChatDev 33% на базовых задачах программирования
Процент "бесценных" токенов 70% оплаченных не приносят ROI
Переиспользование токенов 15x больше в многоагентных vs простой чат

Real-World Failures

8. Полная автономность — ошибка (Codemanship, Feb 2026)

Почему 100% автономное кодирование не работает

Фундаментальные ограничения:

  1. Out-of-distribution problem — LLM не могут надёжно обнаружить, когда задача выходит за рамки знаний

    "Out-of-distribution problems will always be a feature of generative transformers. It's an unfixable problem."

  2. Ложные нарраторы — множество "объяснений" приводят к бесконечным попыткам решить неразрешимую проблему

  3. Координация — параллельные агенты создают конфликты интеграции (breaks the build)

Работающий подход

Успешные команды отказались от поиска полной автономности:

"Hold the firehose in short, controlled bursts" — небольшие автоматизированные фазы с проверками между ними

Комбинирование: - Автоматизированные тесты (unit, integration) - Экспертное суждение инженера - Incremental deployment с коротким feedback loop

9. Практические рекомендации: Как успешные компании решают эти проблемы

1. Начните с одного конкретного use case

Не: - "Автоматизируем весь наш workflow" - "Создаём универсального помощника"

Да: - "Автоматизируем обработку счётов ($X/час экономии)" - "Агент для классификации поддержки ($Y% faster resolution)"

2. Инвестируйте в наблюдаемость (Observability)

Инструменты: - LangSmith (LangChain ecosystem) - Galileo AI (hallucination detection) - AgentOps (execution tracing) - Custom логирование (execution path, latency, outputs)

Что логировать:

{
  "timestamp": "2026-01-15T10:30:00Z",
  "agent_id": "agent_classifier_v2",
  "task_id": "ticket_12345",
  "step": 3,
  "action": "call_tool",
  "tool": "search_knowledge_base",
  "input": { "query": "refund policy", "limit": 5 },
  "latency_ms": 450,
  "output_tokens": 120,
  "success": true,
  "decision_reasoning": "Found matching docs, proceeding to next step"
}

3. Многослойная безопасность

4. Реалистичные ожидания по надежности

Не ожидайте: - 99.99% uptime (как традиционные системы) - Правильный ответ в 100% случаев

Ожидайте: - 85-95% успеха на простых задачах (с human-in-the-loop) - Требуется оператор для обработки сложных случаев - ROI появляется на месяце 3-6, не день 1

5. Tiered Autonomy: Дифференцируйте по risk

Task Risk Level | Autonomy | Requirements
---
Read-only       | 100%     | None
Create/Update   | 50%      | Approval от owner
Delete          | 0%       | Human decision only
Payment/Legal   | 0%       | Human + legal review

6. Event-Driven вместо Polling

Не:

while True:
    status = api.check_task_status(task_id)
    if status == "done":
        break
    time.sleep(5)  # Polling tax

Да:

# Webhook/Event listener approach
api.subscribe_to_task_completion(task_id, on_complete_callback)

10. The 2026 Roadmap: Как масштабировать успешно

Два паттерна масштабирования (Composio)

Pattern A: Централизованная "Agent Team"

Pattern B: "Self-Serve Platform"

Ключ успеха: построить "Agent-Native Integration Layer" - Унифицированный API для tool calling - Управление секретами и permissions - Обработка ошибок и retry logic - Логирование и мониторинг

Выводы: Что нужно помнить практикам

  1. Multi-step agents — распределённые системы с вероятностной надежностью. 95% точность × 10 шагов = 60% успех.

  2. Интеграция важнее модели. Brittle connectors, RAG hallucinations и polling tax убивают пилоты чаще, чем слабый LLM.

  3. "Loop of Death" решается архитектурой: smart routing + semantic caching + sandboxed execution → 70% экономия, 99.9% надежность.

  4. 100% автономность — ошибка. Успешные компании комбинируют автоматизацию с human-in-the-loop, особенно для high-risk действий.

  5. Claude Code + coding agents работают, но требуют: черновой подход (95% garbage → итерации), tiered autonomy, explicit error annotations, трёхэтапный workflow.

  6. Наблюдаемость — главное. Логируйте execution path, latency, reasoning — иначе отладка в production невозможна.

  7. Стоимость растёт на 15x vs простой чат. Маршрутизируйте задачи по сложности (cheap model → frontier model), кешируйте промежуточные результаты.

  8. Selective autonomy побеждает полную автономию. Вставьте чек-поинты перед дорогостоящими действиями — каждый чек перезагружает вероятность ошибки.

  9. Первые 3-6 месяцев — затраты. ROI появляется позже, на месяце 3-6 минимум. Не ожидайте instant wins.

  10. Мониторинг hallucinations, tool selection errors и API timeouts — это 80% работы, не prompting.

Источники и ссылки

Основные статьи о production failures

Claude Code и coding agents

Масштабирование и roadmap

Архитектура и контроль

Безопасность и reliability

Дата исследования: июль 2026
Фокус: личный опыт практиков, production lessons, конкретные архитектуры и цифры
Исключено: маркетинговые статьи, необоснованные обещания, theoretical discussions без примеров