Консистентность в MAS (Multi-Agent Systems)
Базовые паттерны транзакций в микросервисе ложатся на MAS, но AI-архитектура усложняет консистентность двумя факторами: - недетерминированностью LLM и - большой длительностью самих процессов:
Idempotency Key критически важен, так как агенты часто срываются по таймауту, ошибаются в парсинге и пытаются дернуть один и тот же внешний API повторно, защита Tool Calling.
Transactional Outbox защищает от рассинхрона между «памятью» агента и реальностью, жестко разделяя генерацию намерения Reasoning и само физическое действие Action.
Паттерн Saga в MAS лишен классических откатов rollback - их заменяет рефлексия, когда при сбое графа агенту возвращается контекст ошибки для переосмысления задачи.
Optimistic Locking становится неизбежной болью, когда несколько автономных агентов параллельно пытаются обновить общую память — например, профиль пользователя или узел в GraphRAG.
State Consistency в MAS появляется требование: весь контекст и промежуточные выводы должны писаться в единый внешний Thread State, так как локальные переменные ломают логику при масштабировании.
Epistemic (семантическая) консистентность - необходимость избегать противоречий в знаниях агентов, при этом для тяжелых RAG-систем здесь доступен только подход Eventual Consistency.
По CAP-теореме: CP(Консистентность) движок оркестрации и State (Temporal, LangGraph) требуют строгой CP-модели, иначе потеря состояния приведет к сбросу контекста или дублированию шагов: AP(Доступность) В RAG и базы знаний (Vector DB, GraphRAG) работают в AP-модели, где агент адаптируется к секундному лагу данных или падениям через fallback.