Что такое agent state management (состояние агента между вызовами)?

Краткий тезис

Agent state management — это механизм сохранения и восстановления внутреннего состояния AI-агента между вызовами. Без него агент не способен поддерживать контекст, выполнять многошаговые задачи и обучаться на предыдущем опыте. Основные компоненты: буфер диалога, долгосрочная память, рабочая память и контрольные точки. Правильная реализация state management — ключевое отличие простого stateless LLM-запроса от полноценного автономного агента.

1. Термин: Agent State (состояние агента)

Agent state — это вся информация, которую агент «помнит» между вызовами (от одного LLM-запроса до другого). Состояние включает историю диалога, извлечённые факты, промежуточные результаты выполнения инструментов, конфигурацию и т.д.

• Stateless вызов: каждый запрос к LLM самодостаточен, агент не помнит прошлого.
• Stateful вызов: агент передаёт и обновляет состояние в каждом цикле, что позволяет строить цепочки рассуждений (reasoning chains) и сохранять контекст.

2. Компоненты управления состоянием

3. Conversation Buffer (буфер диалога)

память|Conversation buffer — это память|краткосрочная память, которая хранит последние сообщения пользователя и ответы агента. Обычно реализуется как скользящее окно фиксированной длины (например, последние 20 сообщений) или по времени (TTL 1 час).

• Зачем: LLM не имеет внутренней памяти, поэтому весь контекст нужно передавать в промпт. Буфер — самый простой способ сохранить нить разговора.
• Где хранить: Redis с ключом session_id и полем messages. TTL гарантирует, что устаревшие сессии не занимают память.
• Проблема: слишком длинный буфер превышает контекстное окно LLM → нужно применять summarization или sliding window.

Пример структуры в Redis:

{
  "session_id": "abc123",
  "messages": [
    {"role": "user", "content": "Привет, расскажи о погоде"},
    {"role": "assistant", "content": "В каком городе?"},
    {"role": "user", "content": "Москва"}
  ],
  "ttl": 3600
}

4. Long-term Memory (долгосрочная память)

Long-term memory позволяет агенту запоминать факты между сессиями: предпочтения пользователя, извлечённые знания, результаты предыдущих задач.

• Хранилище: векторная БД (ChromaDB, Qdrant, Pinecone). Каждый факт — это эмбеддинг + метаданные (текст, время, session_id).
• Операции:
  • Запись: агент решает, что факт важен (например, «пользователь веган»), и сохраняет его.
  • Поиск: перед ответом агент извлекает релевантные факты по эмбеддингу запроса.
• Пример: если пользователь в прошлой сессии сказал «я не ем мясо», агент при следующем разговоре предложит вегетарианские рецепты.

Схема записи в ChromaDB:

collection.add(
    embeddings=[embedding],
    metadatas=[{"session_id": "abc123", "timestamp": "2025-04-01T10:00:00"}],
    documents=["Пользователь не ест мясо"]
)

5. Working Memory (рабочая память)

Working memory — это временное хранилище переменных, которые агент использует в рамках одной задачи (сессии). Например: ID вызванного API, промежуточный результат запроса к базе данных, статус выполнения подзадач.

• Отличие от conversation buffer: там хранятся сообщения, а здесь — произвольные структуры данных (словари, списки, JSON).
• Реализация: in-memory dict (если агент работает на одном сервере) или Redis с коротким TTL (10–30 минут).
• Пример использования: агент планирует поездку — в working memory лежат выбранные авиабилеты, отель, бюджет; каждый шаг обновляет эти поля.

6. Serialization (сериализация)

Serialization — преобразование сложного состояния агента в строку (обычно JSON) для сохранения или передачи между экземплярами.

• Для чего: если агент запускается в распределённой среде или после перезапуска, состояние должно быть восстановлено.
• Требования:
  • Все объекты должны быть JSON-serializable (строки, числа, списки, словари).
  • LLM-ответы, вызовы функций — сохранять как структурированные записи.
• Пример схемы состояния:

{
  "session_id": "abc123",
  "buffer": [...],
  "long_term_refs": ["id_23", "id_45"],
  "working_memory": {"current_task": "book_flight", "retry_count": 2},
  "checkpoint": 5
}

7. Checkpointing (контрольные точки)

Checkpointing — периодическое сохранение полного снимка состояния агента (например, каждые 5 шагов). Позволяет восстановиться при сбое, не начиная задачу с нуля.

• Где хранить: Redis, S3, локальный файл.
• Когда восстанавливать: при тайм-ауте, краше, или если пользователь перезагрузил страницу.
• Trade-off: частые чекпоинты увеличивают нагрузку на хранилище, редкие — потерю прогресса при сбое.

def save_checkpoint(state, step):
    state["checkpoint"] = step
    redis.set(f"checkpoint:{state.session_id}", json.dumps(state))

8. Технические детали реализации на Python

Пример простого класса управления состоянием с Redis:

import redis
import json
from typing import List, Dict

class AgentStateManager:
    def __init__(self, redis_host="localhost", ttl=3600):
        self.redis = redis.Redis(host=redis_host, decode_responses=True)
        self.ttl = ttl

    def get_state(self, session_id: str) -> Dict:
        data = self.redis.get(f"state:{session_id}")
        if data is None:
            return self._new_state(session_id)
        return json.loads(data)

    def save_state(self, state: Dict):
        self.redis.setex(f"state:{state['session_id']}", self.ttl, json.dumps(state))

    def _new_state(self, session_id: str) -> Dict:
        return {
            "session_id": session_id,
            "buffer": [],
            "long_term_memory": [],
            "working_memory": {},
            "checkpoint": 0
        }

    def append_message(self, state: Dict, role: str, content: str):
        state["buffer"].append({"role": role, "content": content})
        if len(state["buffer"]) > 20:  # sliding window
            state["buffer"] = state["buffer"][-20:]
        self.save_state(state)

9. Проблемы и best practices

10. Сравнение Stateful vs Stateless агентов

11. Пет-проект для закрепления

Задача: Создать агента-помощника по планированию путешествий, который сохраняет предпочтения пользователя между сессиями и восстанавливает ход задачи после сбоя.

Инструменты: Python, Redis, ChromaDB, LangGraph или простой цикл с OpenAI API.

Шаги:

1. Реализовать класс TravelStateManager с методами save_state, load_state, append_message.
2. Настроить Redis для хранения conversation buffer и working memory.
3. Настроить ChromaDB для долгосрочной памяти: при каждом упоминании предпочтения (бюджет, тип отдыха) сохранять эмбеддинг.
4. В цикле агента каждые 3 шага делать checkpoint в Redis.
5. Имитировать сбой (например, обнулить in-memory переменные) и восстановить состояние из последнего чекпоинта.
6. Убедиться, что диалог продолжается с того же места и долгосрочные факты (например, «люблю горы») доступны в новой сессии.

Ожидаемый результат:

• Агент помнит историю последних 20 сообщений.
• После сбоя и восстановления пользователь видит последний ответ агента и может продолжить.
• При новом сеансе (например, на следующий день) агент спрашивает: «Вы по-прежнему предпочитаете горы?» — на основе данных из ChromaDB.

12. Связь с другими вопросами

13. Навигация

• Предыдущий: 585
• Следующий: 587
• Индекс: 00. Индекс разборов

Навигация

• Предыдущий: 585
• Следующий: 587
• Индекс: 00. Индекс разборов