6 структурных Lego-блоков для автономного агентного флота 24/7

Самая частая ошибка при построении агентной системы — попытка сделать одного суперагента, который «умеет всё». Это путь к монолиту, который падает целиком, не масштабируется и требует постоянного присмотра.

Рабочий подход — декомпозиция. Шесть специализированных блоков, каждый с одной зоной ответственности. Как Lego: блоки стандартизированы, взаимозаменяемы и комбинируются в любой конфигурации.

Блок 1: Orchestrator — диспетчер без состояния

Orchestrator — это не «главный агент». Это маршрутизатор задач. Он принимает запрос, определяет, какой агент или цепочка нужна, и передаёт управление. Сам не хранит контекст разговора.

Почему это важно. Когда оркестратор хранит состояние, возникает state drift — рассинхронизация между тем, что он «думает» о задаче, и тем, что реально происходит. При трёх и более агентах это становится неуправляемым.

Как реализовать. PocketBase как диспетчер задач — легковесная БД с REST API, которая работает как очередь. Оркестратор проверяет очередь, маршрутизирует задачу и забывает о ней. Состояние задачи живёт в самой задаче. Альтернативы: Redis Streams, SQLite, файловая система с директориями-очередями.

Блок 2: Memory — эволюционная память

Стандартный chat history — это лог, а не память. Память — структурированное хранилище знаний, которое растёт и уточняется.

Три уровня:

Эпизодическая — что произошло. Логи выполнения, результаты, ошибки.
Семантическая — что мы знаем. Выводы из опыта, правила, паттерны.
Процедурная — как мы делаем. Шаблоны, workflow, проверенные цепочки.

Ключевой принцип — human-approved lessons. Уроки не попадают в память автоматически. Человек проверяет обобщение, после чего оно структурно включается во все будущие сессии. Это решает проблему «отравления памяти» — когда агент запоминает ошибочный вывод и воспроизводит его.

Практическая реализация: иерархия Markdown-файлов. AGENTS.md → memory/YYYY-MM-DD.md → тематические файлы. Файловая система версионируется через Git, легко читается человеком, не требует инфраструктуры.

Блок 3: Tool Layer — слой инструментов

Если каждый агент напрямую вызывает API — хаос: дублирование кода, несогласованные форматы, невозможность аудита. Tool Layer принимает запрос от любого агента, нормализует его, проверяет разрешения и возвращает результат в стандартном формате.

Model-agnostic agility: несколько моделей работают параллельно, задачи маршрутизируются к наиболее подходящей. Gemini пишет SVG-код, Claude проверяет логику. Если локальная модель Mistral лучше справляется с ролью watchdog — задача уходит на неё. Выбор модели — часть маршрутизации инструментов.

Блок 4: Observer — наблюдатель

Агенты не могут объективно оценивать себя. Модель, которая генерирует ответ, не может одновременно оценивать его качество. Для этого нужен внешний процесс.

Cross-model peer review. Ни одна модель не аудитит сама себя. Если Gemini сгенерировал код — Claude проверяет логику. Это реальный антагонизм, а не вежливое «LGTM».

Метрики: время выполнения vs. ожидаемое, количество повторных попыток, расход токенов, паттерны ошибок (tool loops, context bloat, RAG empty retrieval), деградация качества во времени.

Блок 5: Guard — охранник

Guard — это enforcement layer, слой принудительного исполнения правил.

Три рубежа защиты:

Vault-first security. Никаких .env файлов. Ключи инжектируются через Infisical при старте. Если пакет скомпрометирован — на диске нечего красть.
Разрешения на уровне действий. Агент-писатель читает файлы и пишет в свою директорию. Удаление файлов, отправка email, shell-команды — запрещены.
Pre-action enforcement. Перед каждым действием Guard проверяет разрешения и бюджет. Действие блокируется до выполнения, а не после.

Промпт — не защита. Системный промпт «не делай плохих вещей» — рекомендация, не барьер. Guard работает на уровне кода. Промпт можно обойти, код — нет.

Блок 6: Scheduler — планировщик

Scheduler превращает «набор агентов» в «систему 24/7». Heartbeat-паттерн: система регулярно проверяет состояние каждого агента. Если агент не отвечает — перезапуск. Если задача зависла — таймаут и повторная постановка в очередь.

Self-healing. Краш одного агента не роняет систему. Scheduler замечает падение и перезапускает компонент.

Cron-задачи: ежечасный сбор данных, ежедневный отчёт по метрикам, еженедельная ротация ключей, периодический health check. Scheduler управляет приоритетами — срочная задача прерывает фоновый мониторинг.

Как блоки работают вместе

Сценарий «написать статью по теме X»:

Scheduler принимает задачу, ставит в очередь с приоритетом
Orchestrator определяет: нужен агент-исследователь → агент-писатель
Memory подгружает прошлые статьи, стилевые правила, фидбек редактора
Tool Layer маршрутизирует: поиск, анализ, написание через разные модели
Guard проверяет: агент-писатель не выполняет shell, не превышает бюджет
Observer фиксирует время, расход токенов, качество через кросс-модельную проверку

Каждый блок заменяется независимо. Хотите Redis вместо PocketBase — замените Scheduler, остальное не трогайте.

Чего не хватает в этой архитектуре

Human-in-the-loop остаётся bottleneck масштабирования — human-approved memory требует присутствия человека.

Стоимость кросс-модельной проверки — каждая задача через две модели удваивает расход токенов. Для критических задач оправдано, для рутинных — overkill.

Сложность отладки — шесть компонентов с асинхронным взаимодействием. Без хорошего Observer это кошмар.

Выводы

Шесть блоков — Orchestrator, Memory, Tool Layer, Observer, Guard, Scheduler — минимальный набор для автономной системы. Уберите любой — система деградирует: без Observer вы слепы, без Guard уязвимы, без Scheduler привязаны к клавиатуре.

Начинайте с двух блоков: Orchestrator + Scheduler. Это даёт базовую автономность. Затем: Memory (качество) → Guard (безопасность) → Observer (видимость) → Tool Layer (гибкость).

Lego-принцип работает: собирайте по блоку, тестируйте, добавляйте следующий.