Если смотреть только на количество звёзд, можно подумать, что все Agent-проекты, появляющиеся на GitHub — это одно и то же с разными названиями.
Но внимательно посмотрите на позиционирование Agent-проектов в списке Trending этой недели, и вы увидите чёткий паттерн: инфраструктура AI-агентов расслаивается. Не все делают одно и то же — разные проекты решают проблемы на разных уровнях.
Трёхуровневая структура
Заметные Agent-инфраструктурные проекты этой недели можно разделить на три слоя:
Верхний слой: Оркестрация
Представитель — ruflo (48 092 звезды, +11 779 за неделю). Позиционируется как платформа мультиагентной оркестрации для Claude, координирует рабочие процессы нескольких агентов, управляет распределением задач и обрабатывает меж-агентную коммуникацию. Проще говоря, это «командир» — решает, какой агент что делает, когда, и кому передаёт результат.
Средний слой: Движок
Представитель — cocoindex (9 385 звёзд, +1 845 за неделю). Позиционируется как «инкрементальный движок для долгоживущих агентов», обрабатывает задачи агентов, требующие длительного выполнения и управления состоянием. Написан на Rust, 1 741 коммит, недавно обновил trove classifier до Production/Stable, что знаменует выпуск v1. Это «двигатель» — обеспечивает непрерывную работу агентов без потери состояния.
Нижний слой: Память
Представитель — agentmemory (~3 400 звёзд). Позиционируется как постоянная память для AI-агентов программирования, решает ключевую проблему: открываете новую сессию в Claude Code, и предыдущий контекст исчезает. agentmemory пытается поддерживать непрерывность памяти между сессиями. Это «блокнот» — помогает агентам помнить, что они делали в прошлый раз.
Почему расслоение — это хорошо
Если технологическое направление навсегда остаётся одним «универсальным фреймворком», это значит, что оно ещё недостаточно зрелое.
Расслоение означает:
Во-первых, специализация. Каждый слой может оптимизироваться независимо. Слой оркестрации не должен заботиться о постоянстве состояния, слой движка не должен заботиться о UI, слой памяти не должен заботиться о планировании задач. Каждый делает своё и делает это лучше всего.
Во-вторых, компонуемость. Можно выбирать решения из разных слоёв и комбинировать их. Использовать ruflo для оркестрации + cocoindex для движка + agentmemory для памяти — это не просто теоретическая комбинация, а практически работоспособная схема, потому что их интерфейсы дополняют друг друга.
В-третьих, снижение порога входа. Новичкам не нужно строить full-stack с нуля — им нужно просто хорошо сделать один слой. Это ускоряет инновации.
Аналогия: Путь Cloud-Native
Этот паттерн практически идентичен тому, как эволюционировала cloud-native инфраструктура.
Раньше каждая компания строила своё full-stack решение от оркестрации контейнеров до обнаружения сервисов и логирования с мониторингом. Потом Docker занялся контейнерами, Kubernetes — оркестрацией, Prometheus — мониторингом — каждый слой развивался независимо, итерировал независимо, и в итоге комбинировался через стандартные интерфейсы.
Инфраструктура агентов идёт точно по тому же пути.
Но не стоит радоваться слишком рано
Расслоение также приносит новые проблемы:
Стоимость интеграции. Выбор трёх разных проектов для комбинации означает обработку совместимости, сопоставления версий и сложности конфигурации across all three. Для индивидуальных разработчиков это может быть более хлопотно, чем использование одного «не идеального, но работающего» full-stack фреймворка.
Отсутствие стандартов. В настоящее время не существует унифицированных стандартных интерфейсов между слоями оркестрации, движка и памяти. Сегодняшняя комбинация может сломаться завтра, если один проект изменит свой API.
Риск чрезмерного инжиниринга. Не каждое Agent-приложение нуждается в трёхуровневой архитектуре. Использование ruflo + cocoindex + agentmemory для простого скрипта автоматизации — это как запуск Kubernetes для «Hello World» — overkill.
Мой вывод
Расслоение инфраструктуры агентов — это макротренд, который не обратится в краткосрочной перспективе.
Для разработчиков:
- Малые проекты: Используйте full-stack решения для быстрой валидации, не оптимизируйте prematurely
- Средние проекты: Начинайте考虑 расслоение, но выбирайте проекты из одной экосистемы для снижения затрат на интеграцию
- Крупные проекты: Полностью расслаивайтесь, выбирайте лучшее решение для каждого слоя
Расслоение — не цель, а естественный результат технологической зрелости. Когда вы обнаруживаете фреймворк, который «делает всё, но ничего хорошо», пришло время考虑 расслоение.
Основные источники: