Примитив маршрутизации для stateful-агентов
- title
- Примитив маршрутизации для stateful-агентов
- type
- concept
- summary
- Недостающее звено cloud-native архитектуры для связи с durable-процессом: имя транспорта вместо сервера, подходящее под pub/sub-каналы
- parent
- agents-vs-daemons
- tags
- distributed-systems, ai-agents, pub-sub, architecture
- created
- 2026-05-21
- updated
- 2026-05-21
- lang
- ru
- translation_of
- stateful-agent-routing
- source_updated
- 2026-05-21
- translated
- 2026-09-01
- translator
- lllm/antigravity/gemini-3.7-flash-medium
Паттерн "stateless-сервер за балансировщиком нагрузки, а состояние живёт в базе данных" оставался стандартом cloud-native архитектуры последние 20 лет. Он опирается на допущение, что любой запрос может уйти на любой сервер, а задача сервера - лишь читать из базы и писать в неё. ИИ-агенты ломают это допущение: взаимодействовать приходится не с запросами, а с процессами.
Zach Knill называет недостающим элементом маршрутизируемое транспортное имя, не привязанное к серверу. Нужна возможность сказать: "доставь это сообщение тому, кто сейчас генерирует вывод для workflow X", не зная конкретную машину, реплику или процесс. HTTP и балансировщики нагрузки выразить такое не могут: они маршрутизируют трафик на серверы, а это неподходящая абстракция.
Возможные примитивы
- HTTP + опрос базы данных (polling) - текущий вариант по умолчанию. Использует базу данных как шину сообщений. Неэффективно, даёт высокие задержки и тратит лишние токены (в терминах LLM) при каждом повторе.
- WebSockets - двунаправленный протокол с сохранением состояния (stateful), но это соединение, а не адрес. Если связь оборвалась, переподключиться к тому же самому процессу не выйдет, потому что у него нет имени.
- Pub/sub-каналы - адресуемым становится сам транспорт. И сервер, и клиент подключаются к каналу по имени. При разрыве и повторном подключении маршрут сохраняется. Обеспечивает персистентность (durable).
Когда архитектура складывается
Для систем гарантированного исполнения (durable execution) вроде Temporal, Inngest или Restate:
- Workflow подключается к каналу, названному по ID этого workflow.
- Клиент подключается к тому же каналу, чтобы получать обновления, отправлять прерывания и управляющие сообщения.
- Workflow устойчив к сбоям (durable). Канал тоже персистентный (durable). Любая сторона может отключиться и переподключиться, не теряя возможности адресовать сообщения тому же самому процессу.
Схема чисто декомпозируется: durable execution для workflow, pub/sub как адресуемый транспорт, а stateless HTTP - для всего остального.
Почему именно LLM сделали проблему явной
Два свойства ответов LLM делают отсутствие этого примитива особенно болезненным:
- Недетерминированность - нельзя просто повторить запрос при оборванном соединении и получить в точности тот же ответ.
- Высокая стоимость - оплата за токены превращает потерянный ответ в реальные финансовые затраты, а не просто задержку по времени.
Вместе они делают обходные пути вроде опроса базы (polling) слишком дорогими, поэтому игнорировать недостающий примитив больше нельзя. Stateless-веб не плох сам по себе; он просто плохо подходит для агентов, которым нужны долгоживущие, интерактивные процессы с сохранением состояния (stateful).
Источники
- zknill-llms-breaking-cloud-native - статья, где сформулирован этот недостающий примитив.
- Смежные формулировки: agent-principal-agent-problem (то же наблюдение через призму сигналов автора и проверяющего), agents-vs-daemons (ИИ в формате задач по инициативе человека против ИИ в формате ролей по собственной инициативе).