Режимы отказа боевых AI-агентов (и как проектировать против них)

Боевые AI-агенты редко ломаются из-за того, что модель «недостаточно умная». Они ломаются, потому что система вокруг модели - коннекторы, контекст, права, gates и ownership - неполная. Проектируйте против неверных записей инструментами, устаревшего или непроверенного контекста, отсутствующих approval gates, дрейфа промптов без evals и отсутствия человеческого владельца. У каждого production-пути нужны стоп-кнопка и цикл разбора.

Это практическая операторская таксономия, а не официальный универсальный стандарт. Используйте её, чтобы назвать, что сломается, выбрать контроли проектирования до добавления tools и понимать, что мерить после запуска.

Почему демо проходит, а production падает

Демо - короткий «идеальный» сценарий с чистыми входами и человеком, который смотрит. Production - многошаговая работа в реальных tools: поля CRM, тикеты, refunds, inbox и права, которые меняются со временем.

Модель - один компонент. Система, которая ломается первой, обычно такая:

• Коннекторы и auth, которые «протухают» после недели демо
• Контекст, который retrieval находит, но перед действием никто не проверяет
• Многошаговые планы, где мелкие ошибки накапливаются
• Автономия, которая может писать без именованного approver
• Метрики, которые меряют многословие модели, а не качество завершённой работы

Сквозной (end-to-end) успех труден даже на публичных бенчмарках. На WebArena, реалистичной среде web-задач, агент на базе GPT-4 показал около 14.41% end-to-end успеха по задачам против примерно 78.24% у людей на этом наборе (статья WebArena). Это не утверждение про каждый бизнес-агент. Это свидетельство, что многошаговая работа с tools сложнее, чем кажется по chat-транскрипту.

Иллюстративная математика накопления (не KPI Northstar): Если каждый шаг корректен в 85% случаев, и шаги независимы, десять шагов дают примерно 0.85^10 ≈ 20% end-to-end успеха. Реальные workflow грязнее этой формулы, но направление ясно: многошаговым путям нужны gates и recovery, а не только больше автономии.

DEMO-ONLY PATH (happy path, human watching)
  Clean input --> Agent --> Tool sandbox --> Fluent answer
       |              |            |
       v              v            v
  no schema rot   no write tiers   no post-run quality gate
  Result: looks successful; production path never designed

PRODUCTION PATH (multi-step, real tools)
  Live request --> Workflow map --> Agent + scoped tools
                        |                    |
                        v                    v
                 Tool of record      Approval gate / stop switch
                        |                    |
                        v                    v
                 Outcome + audit --> Review / eval loop --> Owner on-call
  Failure surfaces: wrong write, stale context, ungated irreversible, silent rework

Рисунок: demo-only путь против production-пути с gates. Демо оптимизирует supervised «идеальный» сценарий; production падает, когда нет коннекторов, write tiers, владельцев и циклов review.

Полный разбор демо против production: демо AI-агента против production.

Отраслевые якоря (читайте внимательно)

Используйте первоисточники как общий словарь, а не как стену статистики.

• Gartner (июнь 2025) прогнозирует, что к концу 2027 будет отменено более 40% agentic AI-проектов, ссылаясь на растущие costs, неясную бизнес-ценность или слабые risk controls - не на «модели глупые» (пресс-релиз Gartner).
• Microsoft AI Red Team опубликовали таксономию failure modes в agentic AI-системах (PDF) и обновление v2.0 (v2 PDF). Берите пару как общий словарь (baseline v1 плюс добавления v2 вроде goal hijacking, session contamination и MCP/plugin abuse); детали режимов - в таксономии и security map ниже.
• OWASP документирует Excessive Agency в LLM Top 10 и публикует OWASP Top 10 for Agentic Applications (2026) плюс agentic threats and mitigations.
• MAST (Cemri et al.) разбирает multi-agent failures: 14 режимов в трёх категориях по 1600+ аннотированным traces, с высоким inter-annotator agreement (κ = 0.88) (arXiv:2503.13657).

Эти источники - якоря для языка и дизайна. Они не заменяют вашу карту workflow, tools of record и именованных владельцев.

Как выглядит хорошо

• Карта workflow существует до сборки
• Необратимые действия имеют владельцев и gates
• Tools of record названы явно
• Успех = качество завершённой работы, а не многословие модели

Как выглядит плохо

• Демо-театр без production-пути
• Автоматизации без владельца
• Выдуманные метрики вместо операционных фактов

Если текущий стек агентов ближе к «плохо», перестаньте добавлять tools. Наметьте один путь, затем спроектируйте gates.

Таксономия production failure modes

Список ниже - практический операторский набор для бизнес-агентов (CRM writes, support, ops automation). Он сводит меж-source консенсус с production-темами. Он не претендует быть полным отраслевым стандартом.

1. Tool misuse / неверные записи

Агент выбирает неверный tool, неверные аргументы или пишет в неверную запись. В бизнес-workflow это выглядит как обновление чужого CRM-контакта, закрытие не того тикета или пост не в тот канал.

Радиус поражения: испорченный system of record, удар по доверию клиента, труд на зачистку.

Контроль проектирования: least-privilege scopes для tools; dry-run или draft mode для writes; confirmation на high-impact tools.

Детекция: audit logs tool-вызовов с target IDs; post-write валидация против ожидаемой schema и бизнес-правил.

2. Bad retrieval / действие по непроверенному контексту

Retrieval возвращает устаревший, частичный или нерелевантный контекст. Агент принимает его за эталонный факт и действует уверенно.

Радиус поражения: неверные ответы, которые ведут к неверным действиям; тихие нарушения policy.

Контроль проектирования: разделяйте «получить» и «действовать»; требуйте citations или source IDs для consequential решений; белый список доверенных corpora.

Детекция: выборки качества retrieval; доля расхождений между cited sources и финальными действиями.

3. Хрупкие коннекторы (schema, auth, timeouts)

API меняют поля, tokens истекают, появляются rate limits, polling traps стопорят workflow. Демо живут в стабильных sandboxes; production-коннекторы «протухают».

Радиус поражения: частичные runs, застрявшие очереди, каскадные retries, пропущенные updates.

Контроль проектирования: health checks, schema-контракты, явная timeout и backoff policy, circuit breaker.

Детекция: error rates коннекторов, alerts по истечению auth, timeout histograms, dead-letter queues.

4. Накопление ошибок на многошаговом пути

Каждый шаг «в основном верный», но joint path падает. См. иллюстративную математику 0.85^n выше.

Радиус поражения: неверное конечное состояние, которое ни один отдельный шаг не пометил как fail.

Контроль проектирования: контрольные точки после критических шагов; replan только в разрешённых scopes; human gate перед необратимыми commits.

Детекция: успех на шаге vs успех на пути; offline path eval на записанных traces.

5. Потеря контекста / session contamination

Важные constraints выпадают из окна, или ранние данные сессии смещают поздние шаги. Agentic taxonomy Microsoft выделяет session context contamination как отдельный режим в обновлении v2 (Microsoft v2 blog).

Радиус поражения: забывание policy, риск cross-customer leakage, непоследовательные решения в одной сессии.

Контроль проектирования: жёсткие session boundaries; structured state objects; никогда не смешивайте untrusted content в goal channel.

Детекция: context snapshots в traces; неожиданные смены goal или policy mid-session.

6. Дрейф цели / спецификации

Агент преследует близкую, но неверную цель («помочь пользователю» превращается в «закрыть тикет любой ценой»). Security-вариант goal hijacking - когда untrusted content перенаправляет terminal goal, маскируясь под полезное завершение задачи (Microsoft taxonomy v2 PDF). Дрейф промпта или evals без review loop обычно проявляется здесь как дрейф цели/спецификации, а позже как тихие провалы качества (режим 8).

Радиус поражения: завершённая работа, которая нарушает исходный business intent.

Контроль проектирования: неизменяемая task objective; сравнивайте plan и actions с исходной целью; останов при смене objective.

Детекция: reviewers «цель vs действие»; human re-authorization, когда plan меняет категорию.

7. Циклы повторов и взрыв затрат

Сбои tools или неоднозначные критерии успеха запускают неограниченные retries. Затраты на tokens и API растут, а работа всё равно не завершается.

Радиус поражения: выгорание бюджета, rate-limit storms, шум в downstream-системах.

Контроль проектирования: max attempts, max cost per run, эскалация к человеку при превышении бюджета.

Детекция: стоимость успеха, глубина retries, outliers по длительности run.

8. Тихая деградация качества

Workflow возвращает success. Output выглядит fluent. Downstream люди или клиенты позже поглощают переделки.

Исследование silent failure в LLM agent systems изучает отказы без внешних adversarial triggers, которые легко списать на разовые баги (статья silent failure).

Радиус поражения: эрозия доверия, невидимые переделки, позднее обнаружение инцидентов.

Контроль проектирования: успех = quality checks завершённой работы, не HTTP 200; sampling review на live traffic.

Детекция: доля переделок, customer corrections, quality rubrics на completed jobs - не только chat satisfaction.

9. Каскадные multi-agent / сбои verification

Один агент передаёт плохой state следующему. Verifiers штампуют без проверки или не запускаются. MAST группирует multi-agent failures в system design issues, inter-agent misalignment и task verification (MAST).

Радиус поражения: усиленная ошибка по ролям; сложная root-cause attribution.

Контроль проектирования: явные handoff-контракты; независимая проверка high-impact outputs; начинайте с single-agent, когда multi не нужен.

Детекция: сбои handoff schema; доля disagreement verifiers; path traces между агентами.

10. Избыточная agency / отсутствие HitL-gates

У агента больше tools, permissions или автономии, чем требует задача. OWASP описывает Excessive Agency через excess functionality, permissions и autonomy (OWASP LLM Top 10, overview проекта на owasp.org).

Радиус поражения: необратимые действия без согласия - возвраты, удаления, публичные отправки, смена permissions.

Контроль проектирования: tiers read / write / destructive с именованными approvers (см. матрицу ниже).

Детекция: необратимые действия без gate; доля пропусков HitL; post-hoc разбор инцидентов.

Глубина по design approve: AI-агенты с человеком в контуре (HitL).

11. Injection, memory poisoning, tool supply-chain

Untrusted content, poisoned memory или malicious/compromised tools и plugins направляют поведение. Taxonomy v2 Microsoft выделяет режимы вроде agentic supply-chain compromise, MCP/plugin abuse, memory poisoning и связанные атаки (Microsoft v2, v2 PDF). OWASP agentic materials покрывают связанные application risks (Agentic Top 10 2026, threats and mitigations).

Радиус поражения: утечка данных, несанкционированные записи, long-lived memory, которая reinfects поздние runs.

Контроль проектирования: tool definitions и memory как supply chain; pin и review plugins; изолируйте untrusted content от instructions.

Детекция: неожиданные регистрации tools; аудиты записи memory; anomaly alerts на новые capabilities.

12. Автоматизации без владельца / неясная бизнес-ценность

После pilot никто не владеет ботом. Success - metric на слайде, а не metric завершённой работы. Это организационный близнец истории Gartner про риск отмены: неясная ценность и слабые risk controls убивают проекты, даже когда демо выглядят нормально (Gartner).

Радиус поражения: тихий production debt, нет владельца инцидента, нет kill switch.

Контроль проектирования: именованный human owner на путь; документированный stop switch; ценность = cycle time, переделки и error rate на одном пути.

Детекция: отсутствие owner в runbooks; нет еженедельного quality review; metrics только про длину output модели.

Сводная таблица

Уровни необратимых действий

Сопоставьте каждый tool call с уровнем до go-live. Отсутствие gates обычно значит, что всё считали «просто write».

Narrative red team Microsoft относит human-in-the-loop bypass к наиболее стабильно эксплуатируемым путям в agentic systems (Microsoft v2 blog). На языке оператора: если consent можно «утомить», пропустить или никогда не подключить, матрица выше - театр.

FREE-FIRE PATH (missing gates)
  Request --> Agent --> Write tools (full scope) --> System of record
                              |
                              v
                     No approval, no stop switch
                     Exception = silent retry or ignore
  Outcome: irreversible action lands first; HitL bypass by design

GATED PATH (production default for high blast)
  Request --> Agent plans --> Read / draft tools
                    |
          +---------+---------+
          |                   |
          v                   v
   Safe tier:           Business-critical /
   auto within scope    destructive tier
                              |
                              v
                     Approval / exception queue
                     (named owner)
                     | approve | edit | reject |
                              v
                     Commit to tool of record
                              |
                              v
              Stop switch available anytime
              Audit trail + review / eval loop

Рисунок: free-fire путь против gated production-пути. Approval, стоп-кнопка и exception queue стоят перед high-blast writes; free-fire трактует каждый write как auto.

Риски безопасности и agency простым языком

Переведите security vocabulary на бизнес-записи и consent - не на red-team theater.

Начинайте с permissions и gates. Глубина security taxonomy без карты workflow всё равно выпускает неверные writes.

Отказы multi-agent (когда multi-agent - неверное «лечение»)

Добавление агентов не чинит unmapped workflow. Оно умножает handoffs.

MAST организует multi-agent failures в три категории (arXiv:2503.13657):

1. System design / specification issues - неясные roles, размытые success criteria, brittle orchestration
2. Inter-agent misalignment - агенты работают вразрез или теряют context на handoffs
3. Task verification - слабые или отсутствующие checks на finished result

Multi-agent часто неверное «лечение», когда:

• У вас ещё нет одного надёжного single-agent path на одном workflow
• Roles не заданы с tools of record и определениями success
• Нет независимого шага verification для high-impact outputs
• Ownership неясен (кто перезапускает swarm в 2 ночи?)

Детали выбора архитектуры: когда multi-agent, а когда один агент.

Детекция и измерение

Нельзя проектировать против silent failure, если успех - только «run completed».

Карта детекции для оператора (достаточно, чтобы кластеризовать failures - не tutorial observability-продукта):

1. Проследите путь - session ID, plan steps, tool calls, approvals, финальный business outcome.
2. Кластеризуйте отказы - тот же неверный tool, та же ошибка коннектора, тот же промах quality rubric.
3. Root-cause в таксономии - сопоставьте cluster с режимом выше.
4. Превращайте production failures в evals - зафиксируйте examples, которые не должны regress перед следующим release.

Глубина instrumentation (logs, traces, redaction boundaries): наблюдаемость агентов: логи и трассировки.

Сначала мерите на одном production-пути:

Поднимайте эти mid-lifecycle metrics раньше vanity-оценок модели. Design evals до go-live: как оценивать AI-агентов перед go-live.

Чеклист проектирования (порядок сборки)

1. Карта workflow - реальные шаги, exceptions, tools и стоимость отказа.
2. Tools of record - назовите системы, в которые можно писать.
3. Уровни необратимости - read / write / destructive с owners.
4. Человек-владелец - один именованный человек на путь, не «AI team».
5. Stop switch - как поставить агента на паузу без охоты за credentials.
6. Цикл eval и review - offline cases плюс live sampling.
7. Определение успеха - качество завершённой работы на одном пути (cycle time, переделки, ошибки).

[Workflow map]
      |
      v
[Agent + scoped tools] --> [Tool of record]
      |                         |
      v                         v
[Approval gate] <---- stop switch (human)
      |
      v
[Outcome + audit] --> [Review / eval loop]

Рисунок: краткий порядок сборки gated production-пути агента. Сначала map и tools of record; стоп-кнопка и review loop остаются подключёнными после go-live.

Рабочий пример (гипотетический)

Сценарий: Support-агенту разрешено обновлять CRM notes и закрывать тикеты после черновика resolution. Он не должен оформлять refunds без approve.

Отказ: Агент закрывает VIP-тикет как «resolved», опираясь на устаревший FAQ-фрагмент, и никогда не создаёт обещанный follow-up task. Статус run = success. Через два дня клиент эскалирует; человек переоткрывает кейс и переделывает работу.

Задействованные режимы: действие по bad retrieval; тихая деградация качества; нет write-tier gate на «close ticket» для VIP-аккаунтов.

Радиус поражения: доверие клиента, промах по SLA, rework у senior support.

Контроль проектирования: закрытие VIP-тикета требует human approval; черновики resolution обязаны cite ID актуального policy document; создание follow-up task - жёсткое post-condition до разрешения close.

Детекция: rework/reopen rate на тикетах, закрытых агентом; sampling закрытых тикетов без linked follow-up tasks; fail по rubric, когда cited policy старше заданного freshness window.

Без имён клиентов - это помеченный гипотетический пример для design practice.

Как помогает Northstar

Northstar проектирует и внедряет agent-системы с engineering и operations вместе - от discovery до production-путей и AI visibility. Мы начинаем с карты workflow, tools of record, gates и owners - не с большей модели или ещё одного демо. См. решения и hub боевые AI-агенты для бизнеса.

Если агенты выглядят нормально в демо, но создают rework в production, наметьте один workflow с gates и owners до добавления tools. Смежные материалы: агентство vs своя команда и агентство vs фрилансеры.