Объединить Agent и выбранный workflow в один сервис диалога

Статус: предложение, не реализовано. Инвазивность: Высокая. Основа: webrtc-komaroff@772de4a, 16.09.2026.

Agent сейчас владеет session state, вызывает workflow через NATS, сохраняет его результат и публикует UI commands. Workflow получает полный runtime в запросе, исполняет сценарий и отдаёт новый runtime. Оба компонента участвуют в одной последовательной операции turn. Этот разрез добавляет transport и два набора lifecycle/error handling, но граница независимого владения данными здесь слабее, чем между диалогом и GPU.

Сервис диалога принимает прежний Agent request, вызывает выбранный движок локально и фиксирует результат через одну persistence boundary. Core, модель и реальные внешние инструменты остаются отдельными.

Варианты реализации

Если оставить Ruby AsyncGraph, перенести тонкие Agent persistence/history/event adapters в Ruby с сохранением SQL и wire contract. Если выбрать Python, перенести необходимые сценарии в один Python engine и встроить его в Agent. Выбор должен опираться на parity и опыт поддержки команды; из наличия двух языков не следует необходимость перейти на Go или Rust.

Workflow engine оформить модулем с портами LLM, tools и persistence. Отделить domain decisions от транспортных DTO. Не переносить GPU-inference или WebRTC peer connection в этот процесс: их ресурсная нагрузка и lifecycle действительно отличаются.

Можно сначала встроить движок за адаптером и сохранить старый NATS endpoint как временную совместимость. Это позволяет переключать Agent calls постепенно, не меняя frontend одновременно.

Что выигрывает и что теряется

На каждом turn исчезает 1 NATS request/reply boundary Agent → workflow, а runtime больше не сериализуется туда и обратно. Это минимум 2 прикладных сообщения меньше на turn, без учёта service logging и broker overhead. Число обязательных процессов orchestration снижается 2 → 1. Конкретное число байтов определяется реальным размером context.

Выигрыш p95 нельзя заранее приравнять времени LLM: inference может полностью доминировать. Измерять нужно serialization CPU, bytes/turn, broker RTT, количество timeout/error adapters и время изменения сценария. Приёмка: эквивалентность обязательных сценариев, атомарность turn, отсутствие нового bottleneck, p95 не хуже baseline.

Цена — Agent и workflow теряют независимый deployment/scale boundary. Если их нагрузка действительно различается и отдельные consumers используют workflow напрямую, объединение может быть невыгодно. Эти consumers сначала нужно установить.

Переход

Сначала выполнить consistency из предложения 04 и выбрать runtime по предложению 05. Затем создать новый service root по корпоративному naming contract, добавить contract tests и переключать новые сессии. Старые pending sessions остаются на прежнем engine до завершения или явной миграции версии runtime.

Shadow execution допускается на recorded inputs и fake tools; два живых исполнения side effects запрещены самой логикой приёмки. Rollback переключает новые сессии назад, сохраняя версию owner у уже начатых.

Основания

AgentRunner, AgentServer, Workflow DTO, GraphRunner. Strangler Fig поддерживает постепенную замену за стабильным интерфейсом. Решение объединить эти конкретные сервисы — архитектурный вывод по coupling и ownership, не правило «микросервисы плохи».

Все предложения · Фактическая архитектура