Но ведь по логике трансформации к этому все и движется, что в угоду финансовой составляющей, не берутся во внимание социальные риски. И это не говоря уже про всякие корпоративные "войны" и как теперь это может заиграть красками в таких раскладах.
Для подстраховки нужно будет держать постоянный резерв для одного супер-инженера по всем проектам - еще одного на случай увольнения, второго на случай болезни.
Есть ли риски для компаний, когда экспертизой и по сути владельцем продукта или вовсе базой продуктов станет 1 человек, как итог такого развития разработки? По сути такие люди будут создавать индивидуальные экосистемы разработки под себя и тем самым замыкать на себя огромное количество процессов.
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'и.
По сути, агентная архитектура — это модулит, где каждый модуль внутри недетерминирован. Отсюда и потребность в более жёстких контрактах на границах.
Но ведь по логике трансформации к этому все и движется, что в угоду финансовой составляющей, не берутся во внимание социальные риски. И это не говоря уже про всякие корпоративные "войны" и как теперь это может заиграть красками в таких раскладах.
Для подстраховки нужно будет держать постоянный резерв для одного супер-инженера по всем проектам - еще одного на случай увольнения, второго на случай болезни.
Есть ли риски для компаний, когда экспертизой и по сути владельцем продукта или вовсе базой продуктов станет 1 человек, как итог такого развития разработки? По сути такие люди будут создавать индивидуальные экосистемы разработки под себя и тем самым замыкать на себя огромное количество процессов.
Что можно дополнить:
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'и.
По сути, агентная архитектура — это модулит, где каждый модуль внутри недетерминирован. Отсюда и потребность в более жёстких контрактах на границах.