AI-порталAI-портал

Degraded Action Policies в 2026: что делать с действиями, когда support path уже ослаблен

Degraded action policies в 2026: как сужать, откладывать или блокировать agent actions при weak retrieval, stale tool results, missing approvals и degraded dependencies.

Degraded action policies в 2026 нужны потому, что слабый support path опаснее для действий, чем для обычных ответов. Пользователь может ещё терпимо пережить cautious summary без citations, но risky action на weak retrieval, stale tool result или missing approval уже превращается в operational problem. Если система умеет degraded answers, но не умеет degraded actions, она остаётся слишком смелой именно там, где цена ошибки выше.

Degraded action policy — это правило, что разрешено агенту делать, когда evidence, tools, approvals или dependencies уже не на нормальном уровне.
Самый вредный anti-pattern - считать, что degraded mode касается только текста ответа. В production самый важный вопрос обычно не "как сформулировать ответ", а "можно ли вообще сейчас что-то коммитить".

Короткая версия

Хорошая degraded action policy в 2026 обычно определяет:

  1. Какие failure modes переводят actions в ограниченный режим
  2. Какие action classes ещё допустимы
  3. Какие actions нужно перевести в draft, queue или review
  4. Какие commits надо жёстко блокировать
  5. Как выйти обратно в normal action mode

Что особенно важно

  • degraded action policy должна быть строже, чем degraded answer policy;
  • разные action classes требуют разной toleration к weak support;
  • queue, draft и manual mode — это полноценные degraded outcomes;
  • нельзя quietly коммитить risky action в weakened state.
Без техники
Система в degraded retrieval mode всё ещё выполняет external send, просто добавляя warning в UI.
С техникой
Policy переводит send в draft-only или manual review, пока support path не восстановится.
ПромптDegraded-action intuition
Почему degraded action policy должна быть строже, чем degraded answer policy?
Ответ модели

Потому что цена ошибочного действия выше, чем цена осторожного или неполного текста. Weak support path для action почти всегда требует более сильных ограничений.

1. Failure modes для actions важнее маршрутизировать отдельно

Особенно опасны:

  • weak retrieval;
  • stale tool confirmation;
  • missing citation or evidence class;
  • degraded provider for execution tool;
  • unavailable approval path;
  • unresolved evidence conflict.

Не все эти режимы одинаково критичны для текста, но для commit-paths почти все значимы.

2. Action classes должны иметь разные degraded outcomes

Например:

  • low-risk internal draft можно оставить;
  • CRM mutation можно перевести в review;
  • external send сделать draft-only;
  • money movement hard-block;
  • browser submit route в manual mode.
Если weak-support route всё ещё может делать тот же irreversible action, что и normal route, degraded policy, скорее всего, слишком мягкая.

3. Degraded action policy должна быть stateful

Полезно хранить:

  • reason for degradation;
  • allowed action classes;
  • blocked action classes;
  • fallback outcome;
  • restoration criteria.

Иначе действия будут ограничиваться хаотично и по-разному на соседних маршрутах.

4. User and operator UX тоже должны меняться

Если action route degraded, полезно явно показывать:

  • draft created instead of send;
  • request queued for manual review;
  • action delayed pending fresh evidence;
  • operation temporarily unavailable.

Это лучше, чем молча ничего не сделать или тихо снизить качество исполнения.

5. Что особенно часто ломают команды

Same actions in degraded mode

Меняется только wording.

No per-action-class rules

Слишком грубая политика.

Hidden draft-only fallback

Пользователь думает, что commit уже произошёл.

No restoration criteria

Система застревает в manual mode или, наоборот, слишком рано выходит.

No dependency-aware blocking

Execution tool degraded, но commit path открыт.

6. Какие метрики полезны

Минимальный dashboard обычно включает:

  • actions downgraded to draft or review;
  • blocked risky actions by failure mode;
  • degraded action attempts that slipped through;
  • time spent in restricted action mode;
  • restore-to-normal latency;
  • incidents caused by weak-support commits.

Плюсы

  • Degraded action policy уменьшает риск dangerous commits при weak support
  • Делает draft, queue и manual mode осмысленными outcomes
  • Связывает reliability signals с реальными control decisions
  • Помогает держать user trust в incident conditions

Минусы

  • Нужно проектировать route-specific restrictions
  • Friction и latency могут вырасти
  • Без хорошей observability трудно выбрать правильную строгость
  • Слишком мягкая и слишком жёсткая policy одинаково вредны

Пример degraded action policy

degraded_actions:
  weak_retrieval:
    allow: [draft]
    review_required: [internal_mutation]
    block: [external_commit, money_movement]

Простой decision sketch

def may_commit(action_class, degraded_state):
    blocked = degraded_state.get("block", [])
    return action_class not in blocked

Практический совет: зрелая degraded mode стратегия сначала отвечает на вопрос "что мы перестаём коммитить", и только потом на вопрос "как именно это объяснить пользователю".

Проверьте себя

1. Почему degraded action policy должна быть строже, чем degraded answer policy?

2. Что особенно полезно делать с risky actions в degraded mode?

3. Какой anti-pattern особенно опасен?

Источники

  1. OpenAI API Docs - Evaluation best practices
  2. OpenAI Agents SDK - Human in the loop
  3. OpenAI Agents SDK - Run state
  4. OpenTelemetry - GenAI semantic conventions
Предыдущая
Customer-Visible AI Status Pages в 2026: как честно объяснять деградацию AI-сервиса клиентам
Следующая
Degraded Answer Policies в 2026: как отвечать честно, когда evidence path уже ослаблен