Проще говоря, shared state - это общий рабочий лист команды агентов. Один шаг добавил результат поиска, второй проверил источник, третий создал задачу, четвертый отправил ответ пользователю. Все они смотрят не на разрозненные сообщения, а на согласованное состояние процесса.
В AI-агентах shared state особенно важен для многошаговых сценариев. Если агент должен сначала понять запрос, потом вызвать инструмент, потом проверить результат, потом согласовать действие и только потом записать данные в CRM, ему нужен общий объект состояния. Иначе шаги начнут терять контекст, дублировать действия или противоречить друг другу.
Shared state может жить в памяти процесса, Redis, PostgreSQL, state graph, очереди задач или отдельном workflow-движке. Выбор зависит от надежности: для простого прототипа хватит объекта в памяти, для production лучше использовать устойчивое хранилище с логами, версиями и контролем доступа.
Важно отличать shared state от conversation context. Context - это то, что модель видит в конкретном запросе. Shared state - это данные процесса, которые могут жить дольше одного запроса и использоваться разными компонентами системы. Перед вызовом модели из shared state выбирают только нужную часть.
Главный риск shared state - гонки и конфликты. Если два агента одновременно меняют один и тот же объект, можно получить потерянное обновление, неверный статус или повторное действие. Поэтому нужны статусы, блокировки, версии, idempotency key и понятные правила, кто имеет право менять какое поле.
Еще один риск - смешивание данных разных пользователей или задач. Shared state должен быть жестко привязан к session, thread, task, deal, ticket или другому идентификатору. Нельзя хранить общий контекст так, чтобы один пользователь случайно получил данные другого.
В production shared state лучше проектировать как схему: какие поля есть, кто их пишет, кто читает, какие поля обязательны, какие данные чувствительные, как работает TTL, где хранится audit log и что происходит при ошибке или откате.
Примеры
- В LangGraph несколько узлов читают и обновляют общий state: запрос пользователя, найденные документы, выбранное действие и финальный ответ.
- Агент поддержки сохраняет в shared state тикет, клиента, последние проверки и решение, чтобы следующий шаг не начинал с нуля.
- Multi-agent система хранит общий список задач: researcher добавляет факты, reviewer отмечает риски, executor выполняет подтвержденные действия.
- Workflow для CRM держит deal_id, статус проверки, черновик ответа и approval, пока запись не будет безопасно обновлена.
- Redis используется как временное shared state-хранилище для долгого сценария, который проходит через несколько очередей задач.
Где используется
- многошаговые AI-агенты
- multi-agent системы
- workflow с несколькими инструментами
- согласование действий перед write-back
- хранение промежуточных результатов
- контроль статуса долгих задач
- связка model call, tool calling и approval
- восстановление процесса после ошибки
- разделение данных между узлами state graph
Связанные термины
Agent state
Approval workflow
Artifact memory
Checkpoint
Checkpointer
Context engineering
Conversation context
Idempotency key
Частые вопросы
Что такое shared state простыми словами?
Это общее состояние задачи, которое используют разные шаги, агенты или инструменты, чтобы видеть одну актуальную картину процесса.
Чем shared state отличается от контекста модели?
Контекст модели - это данные, переданные в конкретный запрос к LLM. Shared state может жить дольше и хранить состояние всего workflow между разными вызовами.
Где хранить shared state?
В прототипе можно хранить в памяти. В production чаще используют Redis, PostgreSQL, workflow engine или state graph с версиями, логами и контролем доступа.
Какие риски есть у shared state?
Гонки обновлений, потеря данных, повторные действия, смешивание контекстов разных пользователей, утечка чувствительных данных и отсутствие audit log.
Как сделать shared state надежным?
Задать схему, владельцев полей, версии, блокировки или idempotency key, TTL, права доступа, лог изменений и правила восстановления после ошибок.
