Почему ваши AI-агенты теряют контекст и падают: как persistent file-based planning спасает прод

Я — Denis Shokhirev, Enterprise AI Architect из Эрлангена, Германия, управляю DennisCraft AI Studio. За последние полгода я вывел в продакшн 14 AI-агентов для B2B-клиентов из DACH, используя стек Claude, Supabase, n8n, Doppler и self-hosted Postgres. Самая частая причина падения агентов в реальных условиях — потеря контекста после перезапуска или сбоя окружения.

Почему стандартные AI-агенты теряют контекст?

В большинстве open-source workflow-фреймворков (например, LangChain, Haystack) и даже в кастомных решениях на базе n8n, история действий и промежуточные состояния агента хранятся только в памяти процесса или в краткоживущих временных таблицах. Как только контейнер перезапускается, любой незавершённый workflow теряет всю временную информацию. Это не теория — я лично ловил production-баги, когда агенты в логистических задачах «забывали» о предыдущих шагах после сбоя кластера. В условиях B2B и особенно в регулируемых секторах (финтех, индустриальная автоматизация) подобные сбои недопустимы.

Persistent file-based planning: принцип работы

Persistent file-based planning — это паттерн, при котором каждый шаг агента (интермедиатные результаты, план, исходные промпты, артефакты) сохраняется в отдельные файлы или в versioned-объекты в S3-совместимом хранилище. Это не «логирование», а именно атомарная фиксация состояния между шагами. Для этого я использую Supabase Storage или локальный MinIO, а метаданные фиксирую в Postgres.

Зачем это реально нужно?

• Гарантия воспроизводимости: можно восстановить workflow с любого шага.
• Диагностика: полная трассировка цепочки решений агента.
• Аудит (критично для финтеха, регуляторов): есть доказательство хода выполнения.

Пример: сохранение состояния в Supabase Storage

import os
import supabase_py

client = supabase_py.create_client(os.environ["SUPABASE_URL"], os.environ["SUPABASE_KEY"])

def save_agent_step(agent_id, step_num, data):
    filename = f"agent-{agent_id}/step-{step_num}.json"
    client.storage().from_("agent-steps").upload(filename, data)
    # Сохраняем метаданные в Postgres
    client.table("agent_steps_metadata").insert({
        "agent_id": agent_id,
        "step_num": step_num,
        "filename": filename
    }).execute()

Сравнение подходов хранения состояния

Практика: file-based planning для Claude Code и n8n

В связке Claude Code + n8n я реализую паттерн, где каждый «шаг» workflow (например, генерация спецификации, валидация, деплой) фиксируется отдельным JSON-файлом и артефактами в Supabase Storage. n8n выполняет orchestration, а для каждого шага прописан кастомный action, который после выполнения записывает всё в хранилище и фиксирует ссылку в Postgres.

Фрагмент кастомного node для n8n

// n8n custom node
import { IExecuteFunctions } from 'n8n-core';

export async function execute(this: IExecuteFunctions) {
  const stepData = this.getInputData();
  // ... выполнение шага агента ...
  await supabase.storage.from('agent-steps').upload(`agent-${agentId}/step-${stepNum}.json`, JSON.stringify(stepData));
  await supabase.from('agent_steps_metadata').insert({ agent_id: agentId, step_num: stepNum, filename: `agent-${agentId}/step-${stepNum}.json` });
  return this.helpers.returnJsonArray([{ status: "ok" }]);
}

Аудит и compliance: как persistent planning закрывает требования

В regulated-секторах (финтех, индустриалка) часто требуется не только логировать финальный output, но и иметь полный audit trail всех промежуточных решений. Persistent file-based planning позволяет сохранять не только промпты, но и все версии артефактов, что критично для прохождения аудита, например, по стандарту ISO 27001 и требованиям BaFin. В моих проектах часто именно этот паттерн позволяет пройти due diligence на этапе согласования с DACH-клиентами.

FAQ

Почему нельзя просто писать всё в БД?

Postgres отлично подходит для метаданных, но плохо работает с большими бинарными файлами и вложенными структурами (например, многостраничные отчёты, изображения). File-based подход масштабируется проще.

Что делать при race conditions между шагами?

Использую optimistic locking на уровне метаданных (Postgres), а сами файлы именую уникально (SHA256 от содержимого или UUID).

Как удалять старые файлы?

В проде реализую retention policy на уровне Supabase Storage — автоматическая очистка по времени жизни или размеру.

Это медленно?

Для большинства B2B-задач задержка в 100–200 мс на запись в хранилище не критична. Если нужен real-time, можно писать в память, а потом синхронизировать асинхронно.

Как обеспечить консистентность между storage и БД?

В каждом action сначала пишу файл, потом atomically обновляю метаданные в Postgres. Если что-то падает — откатываю шаг.

На каком этапе ваши агенты чаще всего выпадают в проде: после перезапуска контейнера, из-за race conditions или из-за утери промежуточных артефактов? Напишите в комментариях. Я делаю бесплатный 30-мин аудит стека для основателей DACH, кто строит AI в регулируемых секторах. Пишите в личку или в телегу @ger_dennis_ai.