State Recovery Playbooks в 2026: как восстанавливать agent workflow после сбоя, а не начинать заново

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

Хороший recovery playbook в 2026 обычно описывает:

1. Checkpoint boundaries
2. Replay-safe steps
3. Human recovery path
4. State validation before resume
5. Terminal failure criteria

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

• не каждый шаг можно безопасно переигрывать;
• recovery должен отделять read-only и side-effect steps;
• перед resume state надо валидировать, а не просто грузить;
• у оператора должен быть понятный manual path для stuck workflows.

Почему сохранённый state ещё не гарантирует безопасное восстановление?

1. Recovery начинается с правильных checkpoint boundaries

Особенно полезно ставить checkpoints:

• перед risky tool call;
• после подтверждённого side effect;
• перед human approval;
• после retrieval or planning phase;
• на границе subtask completion.

Так команда понимает, где можно resume, а где уже нужен отдельный расследовательский шаг.

2. Read-only и side-effect steps нужно разводить

Без этого невозможно ответить на ключевой вопрос: можно ли safely replay-ить шаг.

Обычно:

• retrieval и analysis replay-safe;
• send_email, submit_form, issue_refund, delete_file требуют отдельной защиты;
• mixed steps стоит разделять на dry-run и commit phase.

3. State validation перед resume обязательна

Перед восстановлением полезно проверить:

• schema version;
• required fields;
• credential freshness;
• tool availability;
• existence of referenced entities;
• unresolved human approvals.

Иначе workflow может продолжиться из формально сохранённого, но фактически уже невалидного состояния.

4. Human recovery path нужен не только для редких аварий

Оператор должен понимать:

• что именно сломалось;
• где остановился workflow;
• был ли side effect;
• какой следующий safe action возможен;
• когда нужно terminate вместо resume.

Это превращает stuck workflow из хаотичного инцидента в управляемую операцию.

5. Recovery playbook полезно иметь по типам сбоев

Например:

Timeout during read-only analysis

Resume from last checkpoint.

Timeout after external commit attempt

Check external system, confirm side effect, then continue or terminate.

Human approval expired

Rebuild approval packet or route to manual handling.

State schema mismatch after deploy

Run migration or terminate old run safely.

6. Что команды ломают чаще всего

Persistence without recovery semantics

State есть, но resume unsafe.

No side-effect markers

Непонятно, что уже произошло.

Blind replay

Workflow просто запускают снова.

No operator tooling

Manual recovery существует только в головах инженеров.

No terminal criteria

Система бесконечно пытается воскресить безнадёжный run.

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

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

• resume success rate;
• percent of runs requiring human recovery;
• duplicate side-effect incidents;
• average time to recovered state;
• terminal failure rate by workflow type;
• schema-mismatch recovery rate.

Пример recovery decision record

{
  "run_id": "run_1842",
  "checkpoint_id": "cp_after_plan",
  "failure_type": "timeout_after_external_commit_attempt",
  "side_effect_status": "unknown",
  "resume_allowed": false,
  "next_action": "manual_verify_external_system"
}

Практический checklist

1. Define checkpoints around risky boundaries
2. Separate replay-safe and side-effecting steps
3. Validate state before resume
4. Give operators explicit recovery paths
5. Define when to terminate instead of retrying

Практический совет: хороший recovery playbook экономит не только compute. Он защищает систему от самого дорогого класса ошибок: повторного side effect после неясного сбоя.