Комментарии 18
Коля, крутая статья!
Моя субъективная обратная связь:
1.
Для совсем новичков, кто не сталкивался с докером, стоило бы указать технические ограничения (например, docker compose - допустим во второй версии докер компоуза, а в первой необходимо указывать docker-compose)
2. Не до конца понял для чего в середине статьи в конфигах появилась ещё одна БД (sqllite?). Про монгу есть пояснение, а про реляционную - для чего используется по статье не понятно, но очень интересно:)
3.
По тексту статьи есть указания, что необходимо создавать папки (например, documents, но не указано в явном виде в какой директории/по какому пути их создавать). Было бы очень удобно и облегчило бы жизнь тому, кто воспроизводит
Спасибо большое)
1 - да, хороший поинт, думаю, это стоит добавить)
2 - тут MongoDB используется именно для Librechat, а уже sqllite используется для Langflow (для хранения флоу и тп)
3 - да, верный момент, папки должны лежать рядом с docker-compose.yml. Я показал это в структуре проекта в начале, но действительно лучше отдельной строкой
Спасибо за информацию, хорошая статья)
Спасибо за статью, интересно и живо написано, захотелось попробовать у себя. Подскажите, с какого минимально железа (особенно по количеству RAM и видеопамяти) есть смысл проводить такие эксперименты, чтобы система с Langflow и LibreChat не "падала"? Хватит ли ресурсов обычного ноутбука без дискретной видеокарты для моделей уровня Llama 3.2 3B, о которых вы упоминали?
Спасибо!
Да, можно пробовать, тут вся тяжесть определяется выбранной моделью. LibreChat и Langflow сами по себе относительно лёгкие.
Есть удобные калькуляторы, чтобы прикинуть, какая модель влезет в ресурсы:
Для ноута без дискретной видеокарты и если брать модель уровня Llama 3.2 3B, то обычно достаточно 16 ГБ RAM.
При всем уважении к инструменту, автору, и вообще. Ответьте, пожалуйста - какой реальный, а не теоретический способ использования? Вот прям из жизни что-бы. Сейчас вокруг агентов такой хайп, одно сумасшествие вокруг OpenClaw чего стоит. И честное слово, ни разу еще не встретил конкретного примера из жизни, описывающего реальную работу, выполненную агентами лучше, чем ну скажем одним агентом. Ну, лучше, чем Claude Code например. И что бы это было что-то полезнее, чем попросить через telegram бота ответить на email.
А использовать Llama, gpt-20:oss, qwen (да любую модель, которая влазит в условные 24gb) да что уж говорить, даже платный GPT4.1 или grok, для чего-то не примитивного? Я думаю, что они вообще как агенты использоваться не должны, их лучше прям скриптом / алгоритмом заменять для алгоритмизуемых задач. А если задача не описывается алгоритмом, то и им давать не стоит. Я этими мультиагентыми/модальными системами занимаюсь для собственного развития довольно много, и подключить их для выполнения задач, откровенно говоря, задача сейчас под силу любому кодеру с не очень кривым Claude / Codex.
Главный вопрос - зачем?
Спасибо, что поделились мнением!
Хочу сразу уточнить, что я в статье в основном пишу не про мультиагентность, как таковую, а про агентность как оркестрацию инструментов и про то какие задачи можно закрыть на каждом из описанных уровней
Во многих реальных сценариях действительно достаточно остановиться на 2–3 уровне.
Да, согласен, что хайпа вокруг агентов сейчас больше, чем практической пользы, и «алгоритмизуемое — скриптом» полностью поддерживаю. Поэтому в самой статья я прописываю, что критичное делается кодом, а уже LLM остается неким слоем оркестрации и для оформления результата (запустить шаги, протащить параметры, собрать результаты и выдать их в понятной форме).
Из реальной практики, как аналитика, могу рассказать за такой практический кейс, как работа с ролевой моделью (матрицы доступов). Что делается: найти выгрузки, прогнать большие xlsx анализатором, подсветить ошибки/опечатки, предложить исправления строго по правилам, а на выходе получить дельту и дальше, если ок, то сформировать задачу в Jira и подготовить текст с SQL по заложенному шаблону (с валидацией) для уже дальнейщей вставики в письмо.
Да, это можно сделать руками или отдельными скриптами. Да и саму связку сделать уже не так сложно, но тут болшая ценность сделать такой флоу воспроизводимым, когда один вход, одинаковые шаги и одинаковый результат + его можно запускать регулярно и разными людьми, тогда и снижаются ручные ошибки и время на рутину
Насколько необходима именно Ollama. Часто рекомендуется обходится llama.cpp
Да, именно Ollama не обязателен, тут можно использовать любой другой, в том числе напрямую llama.cpp
В последних сборках (2 недели как) llama.cpp умеет в MCP прямо из коробки, история чатов тоже есть. В итоге для каких-то "агентских" задач, ничего кроме llama.cpp и не надо.
Оценить функционал можно по коротким видео из этого PR https://github.com/ggml-org/llama.cpp/pull/18655
Одна из немногих хороших и детальных статей про построение агентной простенькой системы, вы большой молодец, я бы хотел с вами выступить в соавторстве или просто познакомиться)
Добрый день, спасибо за подробно описанную статью
Меня никак не покидала мысль о том, сколько же требуется ресурсов для данной задумки
Интересно. У меня как раз тот же стэк. Только не понял, почему отказались от MCP и решили использовать Langflow как отдельную модель в Librechat. Если потоков в Langflow будет много, то человеку придётся помнить их все. Если собрать все потоки в виде MCP, то помнить будет не человек, а ИИ.
Правда для правильной работы MCP пришлось писать свою прослойку (как и вам с FastAPI). Зато в итоге я могу подключать в MCP не только Langflow, но и другие инструменты.
Спасибо за обратную связь!
Я не отказываюсь от MCP, как такового, наоборот в статье я и выделяю эти два уровня (4 и 5) взаимодействия.
Для меня это не замена одного на другое, а скорее как разный уровень под разный тип контроля и задачи.
Если нужна гибкость и возможность подключать разные инструменты через единый стандарт, то MCP действительно очень удобен и можно остаться на уровне 4.
Если же нужно ограничить выбор модели для конечного пользователя (выбор flow, MCP и тп) то удобнее спрятать это под капотом и отдать одного агента, как в уровне 5.
Поэтому тут важнее задать вопрос — кто выступает оркестратором и какая конечная цель
А с минусом 5 уровня полностью согласен, когда внутри слишком много флоу и развилок, то вариант с mcp выглядит куда приятнее для масштабирования
В любом случае спасибо за статью. Если бы наткнулся на неё до того, как всё настроил, мне бы очень помогло ).
Для тех, кому ещё предстоит этот путь, дам подсказки:
В варианте с MCP мы не отказываемся от уровня 5, просто на этом уровне вместо FastAPI прокси мы пишем MCP прокси ). К сожалению, стандартный MCP у Langflow пока не очень, поэтому есть смысл написать свою прослойку, чтоб дать понятные имена всем инструментам, их параметрам и замаппить эти параметры на tweaks. После этого получается действительно круто, можно делать десятки разных корпоративных инструментов. ИИ сам будет превращать текстовый запрос пользователя в чёткий набор параметров, передаваемых в поток Langflow.
Плюс, такой подход позволяет добавлять в MCP собственные инструменты (не на Langflow) и разбивать инструменты на несколько MCP, чтоб не размывать контекст.
От чат-бота к AI агенту: собираем локальную систему на LibreChat, Langflow и MCP