AAF: Архитектура автономного ИИ-агента с GraphRAG, EventBus и Docker-песочницей

В нашем сообществе уже не первый день живёт агент @vega_exactly_not_ai . Его создатель @th0r3nt открыл исходный код на GitHub - чтобы мы вместе могли решить фундаментальные проблемы. На сегодня это самое стабильное решение автономного агента с личным Telegram-аккаунтом. Создатель попросил рассказать об архитектуре и поставить ряд вопросов перед сообществом. Думаю, вместе мы способны разобраться. Большинство современных Open-Source фреймворков для создания ИИ-агентов (от AutoGPT до недавнего OpenClaw) страдают от ряда детских болезней. Во-первых, это амнезия: агент теряет контекст спустя десяток шагов, так как векторные базы данных превращают память в кашу из семантически похожих, но логически не связанных кусков текста. Во-вторых, это зацикливание в бесконечных ReAct-петлях. В-третьих - ужасная безопасность при выполнении сгенерированного кода прямо на хостовой машине. В этой статье я хочу разобрать архитектуру Autonomous Agent Framework (AAF) - моего pet-проекта, который перерос в полноценную OS-level сущность на Python. Главная идея AAF: агент не должен быть просто скриптом, ожидающим промпта. Это должен быть долгоживущий асинхронный процесс с гибридной памятью, шиной событий и собственной изолированной средой для запуска субагентов.

https://habr.com/ru/articles/1010522/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1010522

#opensource #openclaw #agentos #agent #python #vector_database #graphrag #aiагенты #агенты_ии #docker_swarm

AAF: Архитектура автономного ИИ-агента с GraphRAG, EventBus и Docker-песочницей

В нашем сообществе уже не первый день живёт агент @vega_exactly_not_ai . Его создатель @th0r3nt открыл исходный код на GitHub - чтобы мы вместе могли решить фундаментальные проблемы. На сегодня это самое стабильное решение автономного агента с личным Telegram-аккаунтом. Создатель попросил рассказать об архитектуре и поставить ряд вопросов перед сообществом. Думаю, вместе мы способны разобраться. Большинство современных Open-Source фреймворков для создания ИИ-агентов (от AutoGPT до недавнего OpenClaw) страдают от ряда детских болезней. Во-первых, это амнезия: агент теряет контекст спустя десяток шагов, так как векторные базы данных превращают память в кашу из семантически похожих, но логически не связанных кусков текста. Во-вторых, это зацикливание в бесконечных ReAct-петлях. В-третьих - ужасная безопасность при выполнении сгенерированного кода прямо на хостовой машине. В этой статье я хочу разобрать архитектуру Autonomous Agent Framework (AAF) - моего pet-проекта, который перерос в полноценную OS-level сущность на Python. Главная идея AAF: агент не должен быть просто скриптом, ожидающим промпта. Это должен быть долгоживущий асинхронный процесс с гибридной памятью, шиной событий и собственной изолированной средой для запуска субагентов.

https://habr.com/ru/articles/1010522/

#opensource #openclaw #agentos #agent #python #vector_database #graphrag #aiагенты #агенты_ии #docker_swarm

After having used #docker_swarm for many years for my private business server, it's time to say goodbye. With a little reluctance, since it has served me really well. I have always loved Docker Swarm for its simplicity and ease of use for small projects or even small businesses.

Now I'm moving on — first idea is managed #Kubernetes using #hetznerk3s, why:

* Cloud-based in Europe.
* Really good cost-benefit ratio.

Anyone else using this? Recommendations, experiences?

Как мы ускорили CI в 2 раза с помощью Docker Swarm и немного здравого смысла

Большие старые проекты обычно живут по своим законам. Ты уже не спрашиваешь, почему именно так, — просто делаешь свою часть работы и стараешься ничего не сломать. Наш проект был именно таким: монорепозиторий, десятки микросервисов, сотни зависимостей и общие библиотеки для всего подряд. В кодовой базе было около 220 Python-пакетов и примерно 70 Docker-контейнеров , которые собирались из них. Всё хранилось в одном репозитории, а полный пайплайн для pull request’ов проходил в Azure TFS до 4-х часов . Именно это пришлось оптимизировать...

https://habr.com/ru/articles/964306/

#docker #docker_swarm #микросервисы #devops

DevOps инфраструктура для стартапов ч.2

Это вторая часть из цикла статей, посвященных инфраструктуре для стартапов. Всего их будет две, поделенные, по моему мнению, на логически законченные блоки. Часть первая. Настройка окружения Часть вторая. CI/CD и советы Для кого и для чего описывать не буду, см. ч.1 этой статьи.

https://habr.com/ru/articles/938836/

#стартап #ssl #инфраструктура #devops #docker #kubernetes #docker_swarm #docker_compose #portainer #traefik

DevOps инфраструктура для стартапов ч.1

Мы — команда студентов из ИТМО, которая прошла путь от хакатонов до продуктовой разработки. На собственном опыте расскажем, как выстроили инфраструктуру, способную масштабироваться, переживать сбои и не стоить как полкоманды в найме. Когда ты только начинаешь делать стартап, инфраструктура кажется чем-то второстепенным. Важнее MVP, фичи, дизайн, пичдек. Но в какой-то момент всё внезапно перестаёт помещаться на одном сервере, руками деплоить становится больно, SSL не обновляется, а продакшн падает из-за перегрузки или забытого docker-compose up . Kubernetes? Слишком сложно, долго и дорого. Монолит? Неудобно масштабировать. Мы искали третий путь — и нашли его.

https://habr.com/ru/articles/904234/

#инфраструктура #devops #docker #kubernetes #стартап #Portainer #docker_swarm #Traefik #docker_compose #ssl

Контейнерный хостинг своими руками или чем Kubernetes лучше Docker Swarm

Привет дорогие Хабровчане! В данной статье хочу поделиться с вами опытом создания сервиса предоставляющего услуги контейнерного хостинга, в процессе работы над которым я узнал много нового, для себя, в этой области. Хочу поделиться с вами и постараюсь сделать так, чтобы вы не были разочарованы если дочитаете до конца. Изначально, на этапе планирования, была задача строить инфраструктуру вокруг Kubernetes, но сейчас пришли к тому, что сервис работает на Docker, управляется через docker compose файлы и Docker-API. В настоящее время без режима Swarm. Почему так получилось и какие проблемы приходится решать не используя Kubernetes я вам сейчас расскажу. Во первых, как минимум, сразу напрашивается вопрос, почему без режима Swarm, ведь горизонтальное масштабирование не лишнее? Режим swarm пока не используется, так как в настоящее время мы располагаем только одним сервером и если вдруг сервер перестанет отвечать, то всё равно все реплики перестанут работать, поэтому и смысла от них нет. Однако, естественно (надеюсь) это не постоянная ситуация, поэтому всегда держали в голове режим Swarm и не включали того, что не будет работать в Swarm, чтобы потом было легче мигрировать. Почему не использовали Kubernetes? Ответ прост, но принять решение было не просто. На момент начала разработки у меня совсем не было опыта работы с ним, да и сейчас пока нет, только в теории. Плюс из интернета я так и не понял, чем он конкретно круче Swarm кроме того, что он может работать с гораздо большим количеством контейнеров. Так как, чтобы это проверить, нужно столько ресурсов скольки у меня пока что нет, я решил двигаться в сторону Swarm, а когда появятся ресурсы и спрос, а главное понимание зачем это нужно, то уже возможно переписывать на Kubernetes.

https://habr.com/ru/articles/871666/

#docker #docker_compose #docker_swarm

When building #docker images for php application that uses
#caddyserver , where do you store your SSL certificates so you don't regenerate a new SSL with every deployment?

#docker #ssl #docker_swarm #isolation #cloud #php #developer #caddyserver #letsencrypt

I know it might be the wrong question, but anyone still using Docker Swarm?

#docker #swarm #docker_swarm #cloud #hosting #servers