Комментарии 4
Спасибо. Не всё понятно, но есть интерес.
Я правильно понимаю, что в текущий момент Вы топите больше за LanggGraph? Если да, то насколько мне кажется, он довольно сложен, особенно начинающим. Имеет ли смысл в него залазить, если хочешь использовать его в своём PET-проекте, не потратив на него много времени, а компетенций в области AI/ML не имеешь?
Зависит от задачи которая будет реализована в пет проекте. Если все достаточно просто, то нет смысла использовать фреймворки. Если ваш проект - сложная система в которой есть логика / сценарии и тд то стоит задуматься о фреймворке. Какой фреймворк - опять таки зависит от задачи. Где то подойдет более детерминированный ландграф, где то не детерминированные подходы. Так что не могу сказать что я призываю везде и всегда использовать лангграф. В любом случае, если хотите развиваться в этой области и делать агентские системы, рано или поздно погрузиться придется, так как фреймворки во многом ускоряют разработку. Насчет сложности лангграфа - думаю что это так выглядит только на первый взгляд. Уверен, что прочитав несколько вводных статей / примеров вы точно разберетесь!
Что можно дополнить:
Human-in-the-loop. Статья почти не затрагивает интеграцию человеческого контроля. В production-системах узлы подтверждения человеком — критически важный паттерн, особенно для операций с необратимыми последствиями (транзакции, удаление данных).
Evaluation & Testing. Как тестировать агентов? Это огромный пробел в индустрии. Для декларативных систем можно тестировать отдельные узлы изолированно, для недекларативных — это сложнее. Можно было упомянуть подходы: golden datasets, LLM-as-judge, regression testing на trace'ах.
Управление стоимостью. В мультиагентных системах токены накапливаются экспоненциально. Полезно упомянуть паттерн model routing — когда разные узлы используют разные модели по мощности/цене (Claude Opus для планирования, Haiku для простых операций).
Типы памяти. State упомянут, но можно глубже: short-term (текущий trace), working memory (активные артефакты), long-term (векторная база, persistent storage). Управление памятью — отдельная архитектурная задача.
Error handling. Что делать, когда узел падает? Retry с exponential backoff, fallback на альтернативную модель, graceful degradation — всё это важно для production.
И небольшие уточнения...
Сравнение с микросервисами — интересная аналогия, но есть нюанс: микросервисы детерминированы, а здесь каждый узел — стохастичная LLM. Это принципиально другой уровень неопределённости.
Structured Output — можно отметить разницу между JSON mode (мягкое ограничение) и function calling/tool use (жёсткая схема). Для критичных переходов второй вариант надёжнее.
Инференс-грамматики — помимо vLLM есть библиотеки Outlines и Guidance, которые дают похожий контроль над генерацией.
Также имело бы смысл рассмотреть разные варианты архитектур, кроме микросервисов - монолитную, модулитную.
Монолит → Один ReAct-агент Всё в одном: агент сам планирует, выполняет, проверяет. Общий контекст, нет накладных расходов на «передачу данных». Быстро прототипируется, но сложно масштабировать и отлаживать.
Модулит → Декларативный граф с общим state Чёткие границы между узлами (модулями), но единый runtime и общая память. Контракты на входы/выходы (Structured Output). Внутри модуля — свобода реализации. Это очень близко к тому, что описывают авторы.
Микросервисы → Handoff между автономными агентами Независимые агенты, сами решают кому передать задачу. Нет гарантии общего контекста — отсюда «испорченный телефон».
Модулит получается более честная аналогия. В декларативном графе узлы работают с общим state напрямую — это как модули в монолите, которые шарят память. Нет сетевых вызовов, нет сериализации/десериализации между сервисами. Границы логические, а не физические.
Но стохастичность всё равно вносит элемент, которого нет в классической разработке. Даже в модулите ты ожидаешь, что модуль A при одинаковых входах даст одинаковый результат. С LLM — нет. Поэтому архитектурные паттерны переносятся, но нужны дополнительные механизмы: валидация выходов, retry-логика, fallback'и.
По сути, агентная архитектура — это модулит, где каждый модуль внутри недетерминирован. Отсюда и потребность в более жёстких контрактах на границах.
Контроль против гибкости: два подхода к созданию AI-агентов