Архитектура AAF: как GraphRAG и EventBus решают проблемы памяти и безопасности в автономных ИИ-агентах

Автономный агент - это шизофреник с кратковременной амнезией

Вы запускаете своего LLM-агента на сложную задачу. Сначала он строит блестящий план. Проходит два шага. И он забывает, зачем вообще начал. Он спрашивает у вас то, что вы только что ему сказали. Он зацикливается, пытаясь выполнить одно действие разными способами, пока не исчерпает все токены. В лучшем случае - тупик. В худшем - он выполняет rm -rf / в продакшене, потому что "так было в инструкции". Знакомо?

Это не баги. Это системные болезни архитектуры. Проблема памяти (или ее отсутствия) и проблема безопасности - два кита, на которых проваливаются 90% проектов автономных агентов. Старые подходы - просто кидать больше контекста в промпт или надеяться на RAG с эмбеддингами - уже не работают. Нужна новая архитектура.

AAF: архитектура, которая не забывает и не ломается

Autonomous Agent Framework (AAF) - это не один фреймворк. Это паттерн, архитектурный стиль. Его суть в разделении трех критических систем: Памяти (GraphRAG), Коммуникации (EventBus) и Безопасного Исполнения (Docker Sandbox).

Почему именно так? Потому что все попытки запихнуть эти функции в одну монолитную LLM заканчиваются плачевно. Это как заставить одного человека и помнить все, и общаться со всеми, и выполнять физическую работу. Он сломается.

GraphRAG: память, которая помнит связи

Обычный RAG - это тупая поисковая система. Вы кидаете запрос, получаете куски текста. Агент не понимает, как эти куски связаны. GraphRAG меняет правила.

Вместо плоских чанков текста вы храните знания в графе. Сущности - это узлы. Отношения - это ребра. Когда агент узнает что-то новое, он не просто сохраняет текст. Он разбивает его на сущности и связи, и вплетает в существующую сеть знаний.

# Пример структуры узла в GraphRAG (используя библиотеку Neo4j 6.0+ на 2026 год)
# Это псевдокод, отражающий концепцию
from neo4j import GraphDatabase

class GraphRAGMemory:
    def __init__(self, uri, auth):
        self.driver = GraphDatabase.driver(uri, auth=auth)

    def store_experience(self, agent_id, experience_text):
        # LLM (например, GPT-5) извлекает сущности и связи
        entities_relations = llm_extract(experience_text)
        
        with self.driver.session() as session:
            # Создаем узлы для сущностей
            for entity in entities_relations.entities:
                session.run("""
                    MERGE (e:Entity {name: $name, type: $type})
                    ON CREATE SET e.created_at = timestamp()
                    ON MATCH SET e.last_seen = timestamp()
                    WITH e
                    MATCH (a:Agent {id: $agent_id})
                    MERGE (a)-[:KNOWS]->(e)
                """, name=entity.name, type=entity.type, agent_id=agent_id)
            
            # Создаем связи между сущностями
            for rel in entities_relations.relations:
                session.run("""
                    MATCH (source:Entity {name: $source_name})
                    MATCH (target:Entity {name: $target_name})
                    MERGE (source)-[r:RELATES {type: $rel_type}]->(target)
                    SET r.confidence = $confidence,
                        r.context = $context,
                        r.timestamp = timestamp()
                """, source_name=rel.source, target_name=rel.target, 
                       rel_type=rel.type, confidence=rel.confidence, 
                       context=rel.context)

Плюс такого подхода? Когда агент спрашивает "Какие проекты связаны с микросервисной архитектурой?", GraphRAG не ищет текстовые совпадения. Он проходит по графу от узла "микросервисная архитектура" ко всем связанным проектам. И находит связи, о которых прямо не сказано в тексте.

EventBus: нервная система агента

Теперь о второй проблеме. Как агенты общаются между собой? Как они обрабатывают события? Прямые вызовы функций - это ад зависимостей и deadlock-ов.

EventBus (шина событий) - это канал, куда компоненты кидают события, и откуда другие компоненты их подбирают. Агент не знает, кто обработает его событие. Он просто говорит: "Событие X произошло".

Практическая реализация на 2026 год часто использует Redis Streams или Apache Kafka с protobuf-схемами для сериализации. Вот почему это важно:

• Асинхронность: агент не блокируется, ожидая ответа.
• Декoupling: вы можете добавлять новые обработчики событий, не переписывая существующий код.
• Надежность: события не теряются, их можно реплейить.
• Масштабируемость: несколько агентов могут слушать одно событие.

# Пример публикации события через EventBus
import redis
import json

redis_client = redis.Redis(host='localhost', port=6379, decode_responses=True)

def publish_event(event_type, data, agent_id):
    event = {
        "type": event_type,
        "data": data,
        "agent_id": agent_id,
        "timestamp": time.time(),
        "event_id": str(uuid.uuid4())
    }
    # Публикуем в поток Redis
    redis_client.xadd('agent_events', event, maxlen=10000)
    
# Где-то в другом месте - подписчик
def event_listener():
    last_id = '0-0'
    while True:
        events = redis_client.xread({'agent_events': last_id}, count=1, block=5000)
        for stream, stream_events in events:
            for event_id, event_data in stream_events:
                process_event(event_data)
                last_id = event_id

Эта архитектура спасает от зацикливания. Представьте: агент-планировщик создает задачу. Он публикует событие "task_created". Агент-исполнитель подхватывает его, выполняет, публикует "task_completed". Планировщик получает это событие и создает следующую задачу. Если что-то пошло не так, событие "task_failed" запускает агента-дебаггера. Все изолировано. Нет бесконечных циклов в одном промпте.

Docker-песочница: клетка для бешеного кода

Самая страшная часть. Агент решает, что для решения задачи нужно выполнить код. Какой код? Python-скрипт? Bash-команда? Безопасность - это не "надеюсь, модель не сгенерирует rm -rf". Это архитектурное ограничение.

В AAF любой код, который генерирует агент, выполняется в Docker-контейнере с жесткими ограничениями:

• Только read-only файловая система, кроме выделенного временного тома.
• Нет доступа к сети (или только к определенным хостам).
• Ограничения по CPU, памяти, времени выполнения.
• Пользователь без привилегий.

Контейнер создается для каждой задачи и уничтожается после выполнения. Это не просто "запустить код". Это подход zero-trust к исполнению.

# docker-compose.sandbox.yml - конфигурация песочницы на 2026 год
version: '3.8'
services:
  code-executor:
    image: python:3.12-slim
    read_only: true
    tmpfs:
      - /tmp:rw,noexec,nosuid,size=100M
    networks:
      - isolated-network
    cpus: '0.5'
    mem_limit: '512m'
    memswap_limit: '512m'
    pids_limit: 50
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    user: '1000:1000'
    stdin_open: false
    tty: false

tmpfs: true

Собираем пазл: полная архитектура AAF

Как это все работает вместе? Давайте пройдем по шагам выполнения задачи.

1 Агент-приемник получает задачу

Пользователь говорит: "Проанализируй репозиторий на GitHub и предложи улучшения архитектуры". Агент-приемник (Receiver Agent) берет эту задачу, публикует событие task_received с деталями в EventBus.

2 GraphRAG ищет связанные знания

Агент-планировщик (Planner Agent) ловит событие. Он запрашивает у GraphRAG: "Что мы знаем об анализе репозиториев? Какие паттерны улучшения архитектуры мы применяли раньше?" GraphRAG возвращает не просто тексты, а граф связанных концепций: "микросервисы", "тестирование", "CI/CD", с примерами из прошлых задач.

3 Планирование с учетом контекста

Планировщик, вооруженный знаниями из графа, строит подробный план. Не абстрактный "проанализируй", а конкретный: "1. Клонировать репозиторий через GitHub API. 2. Проанализировать структуру папок. 3. Найти зависимости между модулями...". Каждый шаг - это событие, которое будет опубликовано.

4 Безопасное выполнение в песочнице

Агент-исполнитель (Executor Agent) получает событие "execute_step_1". Он генерирует код для клонирования репозитория. Но не выполняет его напрямую! Он запускает Docker-контейнер с песочницей, загружает туда код, выполняет, получает результат. Если код пытается сделать что-то запрещенное, контейнер его останавливает.

5 Обогащение памяти и цикл обратной связи

После каждого шага результаты анализируются. Новые знания ("репозиторий использует монолитную архитектуру с сильной связностью модулей X и Y") сохраняются в GraphRAG как новые узлы и связи. Публикуется событие "step_completed", планировщик корректирует следующий шаг.

Весь этот цикл работает асинхронно. Агенты не блокируют друг друга. Память постоянно обогащается. Безопасность не нарушается.

Под капотом: технические детали реализации

Хватит теории. Вот как это выглядит в коде. Основные компоненты:

Критичный момент: LLM Gateway. Это не просто обертка вокруг API. Это умный маршрутизатор, который выбирает модель под задачу. Код-генерация? Возможно, Claude Code или специализированная модель. Анализ текста? GPT-5. И все запросы кэшируются, чтобы не платить дважды за одно и то же.

Ошибки, которые убьют ваш AAF (и как их избежать)

Я видел десятки попыток внедрить эту архитектуру. Вот где все ломается:

1. Граф без семантики: хранить только явные связи из текста. Надо: использовать LLM для выявления скрытых связей ("этот паттерн похож на тот, но адаптирован под микросервисы").
2. События без схемы: кидать JSON-объекты с разными полями. Надо: использовать protobuf или Avro-схемы. Иначе через месяц у вас 15 версий события task_created, и никто не знает, что где.
3. Песочница без мониторинга: запускать код и надеяться. Надо: логировать все системные вызовы, лимитировать не только время, но и количество системных вызовов.
4. Одна LLM на всех: использовать GPT-5 для всего, от планирования до генерации кода. Это дорого и неэффективно. Надо: подбирать модель под задачу. Иногда маленькая локальная модель справится лучше.

Самая частая ошибка - пытаться внедрить все сразу. Начните с EventBus. Потом добавьте GraphRAG для одного типа знаний. Потом внедрите песочницу для самых опасных операций.

AAF в 2026: куда движется архитектура

Тренды на 2026 год ясны. GraphRAG станет стандартом де-факто для памяти агентов, особенно с появлением специализированных баз данных, которые совмещают графы, векторы и полнотекстовый поиск в одном движке.

EventBus эволюционирует в направлении стандартизации протоколов обмена между агентами разных вендоров. Появятся что-то вроде "gRPC для AI-агентов".

Но главный сдвиг - в безопасности. Песочницы будут использовать не только Docker, но и аппаратную виртуализацию (Firecracker), и даже выделенные изолированные хост-зоны в облаках. Потому что стоимость взлома агента растет.

Мой совет: не гонитесь за самой сложной архитектурой. Возьмите за основу AAF, но реализуйте постепенно. Сначала научите агента помнить (GraphRAG). Потом научите его безопасно выполнять код (песочница). И только потом стройте сложные многоагентные системы на EventBus.

Потому что агент, который помнит все, но может сломать вашу систему, опаснее, чем глупый агент, который ничего не помнит.

Подписаться на канал