Почему я строю Local Mission Control вместо централизованного графа агентов
Централизованный граф — стандарт оркестрации агентов. Но при трёх и более агентах начинается state drift: контекст расползается, состояние становится непредсказуемым. Альтернатива — локальное хранение состояния каждым агентом при минимальной координации.
Централизованный граф — красивая идея, которая ломается на практике
Когда запускаешь первый мультиагентный пайплайн, централизованный граф выглядит идеально. Один state-объект, через который проходят все агенты. Каждый узел читает состояние, обрабатывает, записывает обратно. LangGraph, CrewAI, AutoGen — все построены вокруг этой модели.
Проблема появляется, когда агентов становится больше двух. Я столкнулся с этим, строя систему из пяти агентов: один собирал данные, второй анализировал, третий писал, четвёртый проверял, пятый публиковал. На бумаге — конвейер. На практике — хаос.
State Drift: корень проблемы
State drift — это когда общее мутабельное состояние становится непредсказуемым из-за конкурентных записей нескольких агентов.
- Агент A читает state, начинает обработку
- Агент B параллельно читает тот же state и пишет обратно
- Агент A завершает обработку и перезаписывает state — изменения B потеряны
- Агент C получает state, в котором смешаны устаревшие и свежие данные
В классических системах это называют «гонка состояний» (race condition). Но у мультиагентных систем есть дополнительная сложность: каждый агент — это LLM, которая не просто модифицирует данные, а интерпретирует их. Если контекст загрязнён, модель галлюцинирует на основе мусорных данных.
Почему стандартные решения не работают
Очевидный ответ — блокировки и транзакции. Но это противоречит самой идее агентов:
- Блокировки превращают параллельный пайплайн в последовательный — зачем тогда несколько агентов?
- Версионирование state раздувает контекст: каждый агент получает полную историю изменений всех предыдущих
- Чекпоинты частично помогают, но не решают фундаментальную проблему: один мутабельный объект — одна точка отказа
LangGraph v2 добавил persistence layer и ветвление. CrewAI ввёл memory. Но архитектурная модель не изменилась: всё равно есть центральное состояние, которое все модифицируют.
Паттерн Local Mission Control
Альтернатива, к которой я пришёл (и которую недавно увидел в красивой реализации под названием Flotilla): каждый агент хранит своё состояние локально, а координатор управляет только потоком задач — без общего мутабельного state.
Decoupled State — состояние принадлежит агенту
Каждый агент записывает результаты работы в собственное хранилище. В реализации Flotilla это PocketBase — лёгкая embedded-база на Go. Принцип: агент не лезет в чужой state.
Когда агенту нужны данные от другого агента, он получает их как входные параметры задачи — иммутабельные, сериализованные, без ссылок на живой объект. Это создаёт детерминированный аудит-трейл: можно воспроизвести любой шаг, потому что входные данные фиксированы.
Mission Control — координатор, а не хранилище
Mission Control не хранит состояние агентов. Его задача — раздавать задачи и маршрутизировать результаты. Он знает: какие задачи в очереди, какой агент свободен, какие зависимости между задачами. Но он не знает внутреннее состояние каждого агента. Mission Control — это диспетчер аэропорта, а не пилот.
Model Diversity как встроенный паттерн
Когда агенты изолированы по состоянию, ничто не мешает использовать разные модели для разных задач. В Flotilla: Gemini пишет, Codex тестирует, Claude ревьюит. Каждый работает со своими данными, передача между ними — через явный контракт (задача → результат).
Это даёт побочный эффект: мультимодельный peer review. Одна модель не может «уговорить» другую продолжить галлюцинацию, потому что каждая получает данные заново и оценивает их независимо.
Native Resilience — агенты как сервисы
В Flotilla агенты запущены через macOS launchd как persistent services. Если агент падает или упирается в rate limit, launchd перезапускает его — и агент продолжает с того места, где остановился, потому что его состояние сохранено локально.
Это решает вторую проблему централизованного графа: при сбое одного агента не нужно откатывать весь граф.
Когда использовать каждый подход
Централизованный граф остаётся хорошим выбором когда:
- Два агента, последовательная обработка — граф проще и надёжнее
- Прототипирование — централизованный state позволяет быстрее итерировать
- Тесно связанные агенты, которые обмениваются данными на каждом шаге — overhead от сериализации перевесит пользу
Local Mission Control оправдан, когда агентов 3+, они работают параллельно и нужна устойчивость к сбоям.
Выводы
Централизованный граф — инструмент прототипирования. Хорош, когда нужно быстро собрать и протестировать пайплайн. Но при масштабировании до production-системы с несколькими агентами state drift становится архитектурным ограничением.
Local Mission Control — это shift в мышлении: от «общего мозга» к «команде специалистов». Каждый агент самостоятелен, координатор занимается логистикой, а не хранением общей памяти.
Мультиагентные системы — это распределённые системы. И к ним применимы те же принципы, которые десятилетиями работают в распределённых вычислениях: изоляция состояния, message passing, eventual consistency. Не нужно изобретать велосипед — нужно перестать делать вид, что агенты работают иначе.