State и memory в AI-агенте: что хранить между шагами
Versioned checkpoints keep progress; scoped memory supplies evidence
Freshness, tenant, permissions and execution receipts
Original STATE-LEDGER-7 synthetic contract without client metrics
state memory AI agent architecture and safe recovery
$ resume --contract STATE-LEDGER-7
> load: versioned checkpoint / owner
> retrieve: scoped and fresh memory
> gate: policy / current source
> act: idempotent call / receipt
> route: verified / reconcile / reviewState memory AI agent — вопрос о том, какие факты должны пережить очередной шаг, повтор вызова и новую сессию. Контекстное окно модели не заменяет журнал транзакций и не выдаёт разрешения на будущие действия. Ниже — авторский синтетический контракт STATE-LEDGER-7: он разделяет состояние задачи, долговременную память и квитанции исполнения. Это проектная схема, а не результаты клиентского внедрения.
Если нужен общий выбор исполнителя AI-проекта в Армении, смотрите страницу AI-специалиста. Здесь разбирается узкий технический вопрос: что сохранять и проверять между шагами агента.
Проблема и требования
Представим агента, который сверяет заявку поставщика с CRM, готовит изменение и ждёт согласования. После перезапуска он должен продолжить задачу, не повторив запись и не приняв старое значение CRM за актуальное. При этом не стоит переносить весь диалог, персональные данные и устаревшие инструкции в каждую новую задачу.
Сначала задайте владельца, tenant, критерий приёмки, доступные инструменты, срок хранения и границу ручного review. Разделите факты по сроку жизни: на время задачи, для повторного применения и для проверки уже выполненного действия. Сводка модели может помочь как контекст, но для её утверждений нужны источник и дата истечения.
Архитектура решения: STATE-LEDGER-7
Авторский контракт STATE-LEDGER-7 задаёт семь границ: bind → checkpoint → classify → retrieve → validate → act → reconcile. Версионированный checkpoint хранит текущую задачу и шаг. Избирательная память предлагает прошлые сведения как недоверенное evidence. Отдельный журнал квитанций фиксирует вызовы и подтверждённые результаты. Права определяет приложение, а не извлечённый текст.
| Граница | Сохраняемый вход | Проверка |
|---|---|---|
| Bind | ID задачи, владелец, tenant, scope | Определены identity и допустимый результат |
| Checkpoint | Шаг, версия плана и объекта | Атомарная проверка версии исключает устаревшее возобновление |
| Classify | Факт и чувствительность | Указаны цель, срок и правило удаления |
| Retrieve | Запрос и ссылки-кандидаты | Проверены tenant, источник, свежесть и права |
| Validate | Evidence и текущий источник | Противоречия и устаревшие значения видны |
| Act | Разрешённый вызов | Проверены политика и idempotency key |
| Reconcile | Квитанция и read-back | Неизвестный эффект сверяется до повтора |
Checkpoint относится к текущему запуску; долговременная память содержит только намеренно сохраняемые сведения; квитанция нужна для восстановления и аудита. Не сводите всё к одному тексту диалога. Разбор planning и execution показывает переход между шагами, а разбор tool calling — проверку одного вызова.
Ключевые компоненты и контракты
Рабочее состояние хранит taskId, planVersion, stepId, статус, ссылки на входные данные, версию объекта и остаток бюджета. Обновляйте его атомарно с проверкой версии. После перезапуска читайте последний подтверждённый checkpoint, а не выводите прогресс из последней фразы модели.
Долговременная память хранит минимальный повторно используемый факт вместе с владельцем, tenant, ссылкой на источник, временем наблюдения, сроком действия, классом данных и маршрутом удаления. Фильтр доступа должен сработать до ранжирования. Извлечённая заметка может поддержать предложение, но не может открыть инструмент или заменить запись основной системы.
Квитанция исполнения связывает ID вызова и idempotency key с хешем аргументов, версией политики, статусом и read-back системы назначения. Чувствительное содержимое не должно попадать в стандартные логи. Таймаут означает неизвестный исход: сначала сверка, потом возможный повтор.
Куратор памяти решает, какой факт вообще стоит удерживать. Для памяти между задачами нужен явный критерий, иногда ручная проверка. Устаревшее предпочтение, неподтверждённая сводка или отозванная инструкция удаляются либо изолируются. У каждого класса данных должны быть владелец и срок.
Минимальный псевдокод
async function resume(taskId: string) {
const checkpoint = await state.loadVersioned(taskId);
const candidates = await memory.search({
tenant: checkpoint.tenant,
purpose: checkpoint.purpose,
query: checkpoint.nextStep.query,
});
const evidence = candidates.filter(item =>
item.source && item.expiresAt > now() && policy.canRead(checkpoint.actor, item)
);
const current = await source.read(checkpoint.nextStep.objectId);
if (current.version !== checkpoint.objectVersion) return review("stale_state");
const proposal = await model.propose({ checkpoint, evidence, current });
if (!policy.allows(checkpoint.actor, proposal.action)) return review("forbidden");
const key = `${taskId}:${checkpoint.planVersion}:${checkpoint.nextStep.id}`;
const result = await tools.executeOnce(proposal, key);
if (result.unknown) return reconcileBeforeRetry(key);
return state.commitIfVersion(checkpoint.version, await verify(result));
}Это эскиз контракта без готовой обработки транзакций, шифрования и ошибок. Их надо проектировать и тестировать отдельно. Модель не записывает факты в долговременную память и не продвигает checkpoint без проверки приложения.
Ошибки и failure modes
- Диалог становится источником истины. Сохраняйте структурированный checkpoint и сверяйте результат с системой назначения.
- Старая память вытесняет текущие данные. Фиксируйте время и источник; проверяйте свежесть и версию объекта.
- Извлекается запись другого tenant. Применяйте фильтр доступа до ранжирования и тестируйте изоляцию.
- Модель сохраняет секреты и персональные данные «для удобства». Классифицируйте, редактируйте и ограничивайте срок хранения до записи.
- После таймаута повторяется запись. Используйте стабильный ключ и сверяйте систему назначения до повторного вызова.
- Сводка придумывает прежнее согласование. Approval — отдельная запись приложения со scope и сроком, а не утверждение памяти.
- Удаление не охватывает производные копии. Отслеживайте происхождение и индексы, чтобы удалить связанные данные.
Тестирование и production-чек
Проверьте перезапуск до вызова и после вызова, но до записи квитанции; устаревшую версию CRM; параллельных исполнителей; истёкшую память; отзыв доступа; другой tenant; противоречивый источник; удаление; неизвестный исход записи. Для каждого случая проверьте маршрут и отсутствие запрещённого эффекта. Измеряйте корректность возобновления, устаревшие и отклонённые retrieval, повторные записи и задержку удаления на собственных данных. Здесь нет заявленных показателей эффективности.
Перед пилотом задайте владельца хранилища, политику доступа, сроки, шифрование, redaction, резервирование, удаление и условия остановки. Начните с read-only retrieval и контролируемых checkpoint. Для конкретного процесса запросите архитектурное ревью с примером задачи, классами данных и сценарием сбоя. Смежные вопросы разобраны в AI-автоматизации и prompt engineering.
require(checkpoint.version && policy.canRead(memory));
if (source.version !== checkpoint.objectVersion) return review;
result = await executeOnce(step.idempotencyKey);
if (result.unknown) return reconcileBeforeRetry;
return commitIfVersion(checkpoint.version, verify(result));