Легковесность vs Тяжёлая артиллерия: по какому пути должны развиваться ИИ-агенты?

💥Статья на Habr

В нашем чате уже не первый день живёт агент @vega_exactly_not_ai.

Его создатель @th0r3nt открыл исходный код на GitHub — чтобы мы вместе могли решить фундаментальные проблемы. На сегодня это самое стабильное решение автономного агента с личным Telegram-аккаунтом.

Автор попросил рассказать об архитектуре и поставить ряд вопросов перед сообществом. Думаю, вместе мы способны разобраться.

TL;DR
AAF — это не очередной чат-бот-обёртка. Это автономный агент-сисадмин на Python с тройной памятью (вектор + SQL + граф), тремя циклами работы (реакция, проактивность, рефлексия), Docker-песочницей для выполнения кода, роем субагентов и механизмом самовосстановления. Ниже — разбор архитектуры и 5 открытых вопросов к сообществу.

—

AAF (Autonomous-Agent-Framework) — хардкорная, «тяжеловесная» попытка создать ИИ-сисадмина, который живёт на уровне ОС. Проект на Python и решает проблемы, с которыми часто сталкиваются лёгкие фреймворки: потеря контекста (амнезия) и бесконечные циклы вызовов тулзов.

В чём концептуальная разница подходов (и почему фреймворк назван «тяжеловесным»):

🧠 Тройная гибридная память вместо Markdown-файлов

Лёгкие фреймворки хранят контекст в памяти или простых файлах. AAF использует три слоя, чтобы убить «амнезию»:
· ChromaDB (вектор) — семантический поиск
· PostgreSQL — жёсткие правила, долгосрочные задачи, логи
· KuzuDB (GraphRAG) — агент сам строит графовые связи между объектами, формируя «интуицию»

✍️ Асинхронный EventBus

Это не линейный скрипт. Телеметрия ПК, сообщения из Telegram (через MTProto) и фоновые ошибки падают в единую очередь. У агента три независимых цикла:
· Event-Driven — моментальная реакция на запросы или критические ошибки
· Proactivity — агент сам просыпается по динамическому таймеру; фоновый шум (переписка в чате) ускоряет наступление цикла
· Introspection — глубокий фоновый анализ: рефлексия над прошлыми действиями, чистка графовой БД, консолидация долгосрочной памяти, запись выводов в векторный «дневник»

🎱 Docker-in-Docker песочница

Нужно написать скрипт? Агент сам поднимает изолированный Linux-контейнер, выполняет код и убивает его после завершения.

💻 Agent Swarm

Главный мозг динамически спавнит «демонов» (бессмертные процессы для мониторинга) или «воркеров» (одноразовые агенты для гуглинга, анализа, рутины) и передаёт им задачи по эстафете. Классы субагентов: Researcher, SystemAnalyst, Chronicler и другие.

🔧 Self-Healing: агент, который чинит сам себя

Пожалуй, самая амбициозная фишка. Встроенный WatchDog мониторит все модули. Если системный файл падает с ошибкой — агент просыпается с максимальным приоритетом, читает traceback, находит файл через архитектурную карту, анализирует собственный исходный код и пытается создать патч. По сути — занимается собственным дебагом.

—

Вопросы к комьюнити:

1️⃣ Безопасность vs свобода. AAF пробрасывает Docker-сокет (/var/run/docker.sock) для создания песочниц. Это даёт безграничные возможности, но является дырой в безопасности. Как решать проблему выполнения LLM-сгенерированного кода? WASM? Firecracker microVM?

2️⃣ GraphRAG vs VectorDB. Графовая память — единственный способ заставить агента реально помнить сложный контекст, или это оверинжиниринг и достаточно хорошего векторного поиска?

3️⃣Демон vs Serverless. Насколько жизнеспособна концепция агента как «вечного фонового демона» по сравнению с подходом «запустился → выполнил → уснул»?

4️⃣ Один мозг vs Swarm. Что эффективнее — скормить тяжёлую задачу одной мощной модели или делегировать стае дешёвых субагентов (Gemini Flash / Claude Haiku)?

5️⃣ Self-Healing. Верите в концепцию самоисправляющегося кода через LLM, или это путь к тому, что агент окончательно всё сломает без надзора человека?

Делитесь мнениями в комментариях или чате 👇

Чат | Канал