Полная замена оркестрации: сохранённые задания и возобновляемые шаги
Статус: предложение, не реализовано. Инвазивность: Очень высокая; условный вариант. Основа: webrtc-komaroff@772de4a, 16.09.2026.
Полное переписывание имеет смысл, если появляются долгие операции, обязательное восстановление после crash, несколько независимых исполнителей или ожидание пользователя между шагами. Сейчас граф выполняется внутри одного вызова, его промежуточные await results находятся в RAM, а Agent сохраняет только итоговый runtime. При рестарте незавершённый шаг сам по себе не восстановится.
Ingress принимает turn как задание. Durable store хранит его статус и checkpoint. Worker выполняет шаг, пишет результат и только затем подтверждает обработку. UI получает event stream, а LLM/tools остаются за адаптерами.
Что именно переписывать
Заменить Agent и workflow layer как единую область orchestration, сохранив Core/WebRTC и совместимые model/tool boundaries. Новая версия может использовать persistent LangGraph checkpointer либо другой workflow engine с подтверждённой семантикой retry/resume. Название библиотеки не снимает ответственность за idempotency внешних effects.
JetStream можно использовать для устойчивой очереди job IDs, если нужны управление backlog и независимые workers. Сообщения содержат идентификаторы и небольшой immutable input, а не все PCM frames или большие аудиофайлы. Для live audio сохраняется session owner; потерянный WebRTC peer нельзя «восстановить» из durable queue.
Один источник истины должен владеть шагами. Если checkpoint engine и job store независимы, требуется явно определить commit/ack sequence и reconciliation. Добавлять одновременно свой event sourcing, JetStream и отдельный workflow engine без нужного требования — новая сложность, а не сокращение legacy.
Измеримые причины выбрать этот путь
До начала согласовать recovery objective: какие принятые turn обязаны пережить crash и за какое время возобновиться. Числа RPO/RTO не установлены текущим проектом.
Приёмочный crash matrix: до model call, после model result до checkpoint, после tool effect до ack, после commit до UI event. На размеченных idempotent fixtures: 0 потерянных принятых jobs, 0 двойных логических effects, один terminal state. Дополнительно измерить resume p95, backlog age, write amplification, retained bytes/job и стоимость одного completed turn.
Queue delivery at-least-once не означает exactly-once tool effect. Для неопределённого исхода внешней операции нужен idempotency key либо запрос статуса и reconciliation. Если backend этого не умеет, такой предел должен оставаться в контракте.
Почему не начинать с этого
Появятся новые storage schemas, retention, migrations, cleanup и эксплуатационные задачи. Для коротких трёхсценарных диалогов цена может превысить пользу. Сейчас нет замеров, доказывающих, что именно отсутствие workflow platform ограничивает систему сильнее queue/idempotency ошибок и лишнего модельного шага.
Рациональный контрольный этап — предложения 03–07. Если после них остаются подтверждённые потери заданий или необходимость долгих приостановок, проектировать замену. «Переписать все сервисы с нуля» без сохранения корпусных contracts я не рекомендую.
Как мигрировать
Ввести versioned turn API и новые сессии направлять в новый engine. Старые завершаются прежним owner. Импорт истории отделить от импорта pending checkpoint; для непереносимого pending предложить явный restart пользователю. Сначала мигрировать один read-only сценарий, потом сценарии с эффектами. Удалять старые сервисы только после coverage и наблюдаемого завершения их сессий.
Основания
RAM request_results, Python compile без checkpointer, Agent persistence. Context7: /websites/langchain_oss_python_langgraph, /nats-io/nats.docs, 16.09.2026. LangGraph persistence и functional API idempotency требуют persistent state и корректной организации side effects. JetStream consumers описывает ack/redelivery и MaxAckPending. Найденная Context7 документация новее минимального langgraph>=0.2.55 проекта; новая реализация требует выбора и фиксации версии, а не копирования примеров поверх текущего dependency range.
Все предложения · Фактическая архитектура