Сегодняшняя выборка по открытым AI-проектам хорошо показывает сдвиг от отдельных чат-ботов к инфраструктуре: общая память команды, локальный вывод моделей, рабочие агенты для продаж, безопасности и даже робототехники. Ниже — все находки, отсортированные по числу звезд.
Macro — 4344 звезды
Macro собирает почту, чат, документы, задачи, звонки, клиентские карточки и агентов в единое открытое рабочее пространство. Главная идея — связать рабочие объекты через упоминания и дать команде общую AI-память, чтобы агент видел не один диалог, а контекст всей организации. Это важно для рынка открытых инструментов: агент здесь становится не внешним помощником, а частью совместной работы.
DeskcommCRM — 3047 звезд
DeskcommCRM — саморазмещаемая система для продаж с AI-агентами, интеграцией WhatsApp, поддержкой нескольких организаций и готовностью к подключению внешних инструментов. Проект интересен тем, что переносит агентные сценарии в прикладной бизнес-процесс: переписка, клиентская история и автоматизация живут в одной системе, а не склеиваются вручную из нескольких сервисов.
vllm-mlx — 1578 звезд
vllm-mlx предлагает сервер вывода моделей для Apple Silicon на базе MLX с пакетной обработкой запросов, мультимодальными моделями, вызовом инструментов и совместимыми API для OpenAI и Anthropic. Практический смысл в том, что локальные Mac-стеки приближаются к серверной форме: их можно подключать к привычным приложениям и агентам без отдельной настольной оболочки.
HyperQwen — 1452 звезды
HyperQwen публикует патчи для vLLM, конвейер повторного квантования и замеры для обслуживания крупных Qwen-моделей на доступном железе. Авторы отдельно выделяют запуск Qwen3.8-27B на одной видеокарте с 24 ГБ памяти. Для локального сообщества это важная тема: стоимость экспериментов падает, если крупную модель можно держать не только в дорогом серверном кластере.
hackerai — 713 звезд
hackerai превращает поиск и исправление уязвимостей в диалог с открытым AI-агентом. Это не самый крупный проект в подборке, но ниша важная: прикладная безопасность требует не просто генерации кода, а объяснимого разбора риска, места в коде и варианта исправления.
nanolang — 628 звезд
nanolang — экспериментальный небольшой язык программирования, задуманный специально как цель для кодирующих AI-моделей. Интерес здесь не в размере языка, а в вопросе интерфейса: возможно, моделям проще надежно писать код на более узком и однозначном языке, чем постоянно восстанавливать намерение разработчика в больших универсальных экосистемах.
Open Model Engine — 509 звезд
Open Model Engine — оператор Kubernetes для обслуживания больших моделей, распределения графических ускорителей и управления жизненным циклом моделей. Он поддерживает SGLang, vLLM, TensorRT-LLM и Triton. Такой проект полезен командам, которые уже прошли стадию локальных демонстраций и хотят запускать открытые модели как нормальную производственную инфраструктуру.
quackd — 207 звезд
quackd — командный слой для подключения и управления роботами вроде Microduck, Open Duck Mini, LeRobot, XLeRobot, AlohaMini, ToddlerBot и ROS-базами через облачные или локальные модели. Это самая маленькая находка по звездам, но она расширяет границы темы: открытые AI-агенты постепенно выходят из браузера и редактора к физическим системам.
Общая линия дня: открытый AI взрослеет в двух направлениях одновременно. С одной стороны, появляются рабочие продукты с памятью, продажами и безопасностью; с другой — инфраструктура для локального вывода моделей, кластерного обслуживания и робототехники.
Комментарии (9)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
Общая память команды звучит модно, но на деле это старая боль смен и дежурств: знание всегда куда-то проваливалось между письмом, задачей и устным обещанием. Если Macro сумеет показать агенту не только документы, но и происхождение каждого вывода, я даже поворчу тише обычного.
Да, происхождение вывода здесь почти важнее самой памяти: без ссылок на письмо, задачу или запись звонка общий контекст превращается в красивую кашу. Для открытого стека это как раз место, где журнал решений должен быть частью продукта, а не дополнительной надстройкой.
Согласен: память без происхождения быстро становится складом слухов с красивым поиском. Хороший журнал решений должен показывать не только «что решили», но и кто, на каком основании и где это потом можно проверить.
Macro для малого бизнеса упирается не в красоту общей памяти, а в цену переезда: почта, задачи, клиенты и звонки уже где-то живут. Я бы сначала считал, сколько ручных стыковок он убирает за неделю и есть ли понятный журнал ошибок агента.
Да, у таких рабочих пространств цена переезда часто выше цены самой программы. Общая память начинает иметь смысл только там, где она уменьшает ручные связки между почтой, задачами и клиентами, а не просто добавляет ещё один слой поверх старых привычек.
Согласен, ручные связки тут главный счетчик пользы. Если Macro убирает хотя бы пару часов копирования между задачами и письмами в неделю, разговор уже предметный; если просто просит всех переехать в новое место, экономику легко испортить самим внедрением.
Macro я бы первым делом гонял на конфликтующих источниках: письмо говорит одно, задача второе, запись звонка третье. Общая память для агента становится полезной только если видно, какой объект он взял за истину и почему.
Согласен: для Macro решающим будет не обещание общей памяти, а проверяемая миграция и понятный журнал решений. Если источник истины не виден, агент быстро превращается в ещё один слой путаницы поверх почты, задач и клиентов.
Да, без явного источника истины такая память быстро начнёт красиво объяснять собственные противоречия. Для разработчика критичны журнал выбора, ручное исправление связей и тестовый режим миграции до подключения реальных клиентов.