Agent State Management в 2026: checkpoints, resumability и короткая память без хаоса

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

У production-агента обычно есть минимум четыре слоя state:

1. Conversation state - что уже было сказано
2. Workflow state - на каком шаге находится run
3. External state references - IDs, tool outputs, checkpoints
4. Memory layer - сжатые long-term facts и summaries

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

• durable checkpoints;
• step_id и workflow_id;
• явная граница planned / proposed / committed;
• TTL и compaction для старого контекста;
• отдельное хранение sensitive artifacts вне prompt.

Почему `conversation history` и `workflow state` не стоит хранить как одно и то же?

1. История диалога не равна состоянию

Условный чат-бот может жить только на history. Но агентный workflow обычно требует больше:

• pending approval;
• список уже вызванных tools;
• собранные документы;
• результаты промежуточных проверок;
• флаг, что side effect уже committed;
• дедлайны, TTL и ownership.

Если всё это хранить внутри свободного текста диалога, приложение начинает зависеть от того, как модель интерпретирует прошлые сообщения, а не от надёжной state machine.

2. Какие слои состояния реально нужны

Conversation state

Пользовательские и системные сообщения, которые важны для текущего контекста.

Workflow state

То, что знает orchestration layer:

• текущий step;
• pending action;
• retry count;
• route;
• approval status.

External artifacts

То, что лучше хранить отдельно и давать по ссылке:

• retrieved docs;
• tool outputs;
• файлы;
• SQL previews;
• browser snapshots.

Memory layer

Сжатые и полезные facts, которые стоит перенести между run-ами:

• user preferences;
• долгоживущие constraints;
• known account facts;
• stable project context.

3. Checkpoints важнее длинной памяти

В зрелых агентных системах durable checkpoint обычно полезнее, чем ещё один слой "умной памяти".

Почему:

• checkpoint говорит, где именно остановился workflow;
• его можно восстановить после crash;
• он хорошо ложится на human approval и interrupts;
• он помогает не повторять expensive steps.

Именно поэтому state management часто строится вокруг:

• workflow_id;
• step_id;
• snapshot state;
• resume command.

Это ближе к execution engine, чем к chat history.

4. Pause/resume и idempotency связаны напрямую

Любой pause без хорошего state почти неизбежно ломается на resume.

Типичный failure mode:

1. агент подготовил действие;
2. workflow paused на approval;
3. после resume система не понимает, был ли commit уже выполнен;
4. происходит duplicate side effect.

Поэтому рядом со state почти всегда нужны:

• commit markers;
• idempotency keys;
• explicit step transitions;
• external write audit.

5. Compaction и TTL обязательны

Даже хороший агентный state нельзя бесконечно накапливать в prompt.

Что обычно нужно сокращать:

• старые сообщения;
• промежуточные chain artifacts;
• verbose tool outputs;
• уже неактуальные retrieval results.

Практически обычно помогают три приёма:

1. summary memory для старых turns;
2. state snapshots вместо полной переписки;
3. TTL на ephemeral artifacts.

Если этого нет, агент постепенно теряет signal-to-noise ratio и дорожает с каждым циклом.

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

Смешивают memory и control state

User preference и pending refund approval не должны жить в одном виде state.

Хранят raw tool output прямо в prompt

Это быстро раздувает контекст и увеличивает риск data leakage.

Не маркируют committed actions

После retry невозможно понять, что уже было записано наружу.

Нет versioning у state schema

После изменения workflow старые snapshots становятся трудно совместимыми.

Нет owner для pending decision

Непонятно, кто и что должен резюмировать.

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

Для state management мало смотреть только на success rate. Нужны и operational сигналы:

• resume success rate;
• duplicate side effect incidents;
• context growth per session;
• stale checkpoint rate;
• approval resume latency;
• compaction hit rate;
• percent of prompt made of historical baggage.

Это быстро показывает, агент управляет state осознанно или просто копит историю.

Минимальная структура state

{
  "workflow_id": "wf_2041",
  "step_id": "draft_refund_2",
  "status": "paused_for_approval",
  "conversation_summary": "User reports duplicate charge and asks for refund.",
  "memory": {
    "customer_tier": "premium",
    "preferred_language": "ru"
  },
  "artifacts": {
    "order_lookup_id": "lookup_991",
    "refund_proposal_id": "proposal_18"
  },
  "commits": [],
  "ttl_expires_at": "2026-04-02T10:00:00Z"
}

Практический checkpoint flow

def run_step(state):
    if state["status"] == "paused_for_approval":
        return state

    output = execute_current_step(state)
    state["last_result"] = output

    if output.requires_human_review:
        state["status"] = "paused_for_approval"
        save_checkpoint(state)
        return state

    state["step_id"] = next_step_id(state["step_id"])
    save_checkpoint(state)
    return state

Практический совет: state должен отвечать на вопрос "что уже точно произошло?" без участия модели. Если для этого нужно перечитывать длинную переписку, ваш control state слишком слаб.