LLM ломают системный дизайн 20-летней давности

Cloud-native архитектура последнего десятилетия опирается на предпосылку 20-летней давности: состояние живёт в базе данных, вычисления не имеют состояния (stateless). База данных масштабируется вертикально, серверы приложений - горизонтально, любой запрос может попасть на любой сервер. Аргумент Zknill'а заключается в том, что LLM-агенты незаметно нарушают эту схему в трёх аспектах, а подходящего примитива маршрутизации, чтобы это исправить, у нас пока нет.

Три нарушения

1. Долгая работа - 10-минутная задача агента - это не запрос, а асинхронный процесс.
2. Вычисления с состоянием - многошаговые диалоги, вызовы инструментов, накопленный контекст. Это память агента, а не состояние в базе данных.
3. Двунаправленное взаимодействие - пользователь хочет наблюдать за ходом мыслей агента, прерывать его, направлять в другую сторону. Это диалог с процессом, а не разовый запрос.

Durable execution решает часть проблемы

Temporal, Inngest и Restate делают исполнение надёжным (durable) и устойчивым к сбоям. Но на нижнем уровне слой исполнения всё ещё делает вид, что работает без состояния. Как только клиенту требуется обратиться к конкретному запущенному процессу, связка из HTTP, балансировщика нагрузки и stateless-сервера не может доставить запрос по адресу. Поэтому все возвращаются к polling'у.

Polling использует базу данных как шину сообщений - ровно так делали до появления самих шин сообщений. Это лишь костыль вокруг проблемы маршрутизации: компромиссы по задержке при выборе частоты опроса, нагрузка на базу данных, пустые запросы, отвратительный UX при потоковой передаче. Проблему это на самом деле не решает.

Недостающий примитив маршрутизации

Zknill формулирует это так: маршрутизируемое имя транспорта, которое не привязано к серверу. Хочется сказать "доставь это сообщение тому, кто выдаёт результат для workflow X", не зная конкретную машину, реплику или процесс. HTTP и балансировщики нагрузки выразить такое не способны.

WebSocket выглядит подходящим кандидатом - долгоживущий, двунаправленный, на уровне транспорта, - но это соединение, а не адрес. Если WebSocket обрывается, "адрес" теряется. Переподключиться к тому же процессу нельзя, потому что нет имени, по которому можно маршрутизировать запрос.

Каналы pub/sub меняют схему владения

Ни сервер, ни клиент не имеют прямого адреса. Адрес есть у транспорта. Обе стороны подключаются к каналу по имени и получают двунаправленную связь с сохранением состояния и возможностью возобновления. Канал персистентен: если одна из сторон отключается, обе переподключаются по тому же имени, не теряя возможности маршрутизации к тому же процессу.

В случае durable execution шаг workflow подключается к каналу, названному по workflow ID. Клиент подключается к тому же каналу для получения обновлений, отправки прерываний и управляющих сообщений. Никакого протаскивания данных через базу данных, никакого polling'а и никаких проблем с адресацией процесса, который реально выполняет работу.

Проблема не сводится к LLM

LLM лишь обнажили проблему, потому что их ответы недетерминированы и дороги. Раньше при обрыве соединения повторная попытка стоила дёшево и обычно возвращала тот же ответ. В случае с LLM не хочется платить токенами дважды из-за того, что клиент заехал в тоннель, и не хочется прогонять каждый токен через базу данных только ради отказоустойчивости. Stateless-веб не плох сам по себе - просто это неподходящая архитектура для агентных приложений.

Как выглядит архитектура

Три компонента, каждый из которых решает одну задачу:

• Durable execution для workflow.
• Pub/sub для адресуемого транспорта.
• Stateless HTTP для всего остального.

Этот материал стоит в одном ряду с agents-vs-daemons (ИИ по инициативе человека против ИИ по собственной инициативе), microvm-2026 (слой изоляции под агентом) и статьёй Кроушоу в agent-principal-agent-problem (где тот же сдвиг рассматривается со стороны код-ревью). Там, где Кроушоу видит слом как проблему сигналов между автором и ревьюером, Zknill видит его как проблему транспортного уровня. Оба смотрят на одно и то же с разных сторон.