Выбор UI‑инструмента для быстрого прототипирования в AI‑продуктах: Open WebUI

[MayaButo]

Очень знакомая проблема с многошаговым взаимодействием. В своих AI-workflow я тоже довольно быстро упиралась в то, что обычный чат перестаёт быть удобной моделью интерфейса, как только появляется state, human-in-the-loop и необходимость продолжать процесс после вмешательства пользователя, а не запускать его заново. Мне кажется, что здесь UI уже действительно становится частью orchestration layer, а не просто оболочкой над моделью.
Интересен момент с одним endpoint и невозможностью нормально различать start new run и resume from interrupted state. Вы это в итоге решали на уровне собственной state-machine поверх Open WebUI или именно это и стало одной из причин перехода к другому UI-слою? И ещё интересно, где у вас хранится source of truth по состоянию такого процесса: внутри LangGraph state/checkpointing или отдельно во внешнем storage, чтобы UI мог безопасно восстанавливать текущий этап после паузы?

[true_engineer]

Вы это в итоге решали на уровне собственной state-machine поверх Open WebUI или именно это и стало одной из причин перехода к другому UI-слою?

Это стало одной из главных причин перехода к assistamt-ui - про это подробнее рассказали во второй части, можно посмотреть статью в профиле.

И ещё интересно, где у вас хранится source of truth по состоянию такого процесса: внутри LangGraph state/checkpointing или отдельно во внешнем storage, чтобы UI мог безопасно восстанавливать текущий этап после паузы?

Чекпоинты для восстановления после прерываний мы храним в памяти процесса, отдельно в mongo db мы после каждого узгла сохраняли для логов все состояние. Когда мы добавляли чекпоинты, в основном пакете langgraph mongo не поддерживалась, и в целом это mvp, поэтому пока in-memory чекпоинтер. В планах было переходить на postgres и сохранять все туда, он официально поддерживается.