Как развивать webrtc-komaroff
Проверенный исходник — 772de4a, дата 16.09.2026. Ни одно предложение ниже не реализовано в приложении. Архитектура описывает текущий код, evidence ledger отделяет наблюдение от вывода.
Оценка выбранного подхода
Разделение медиасоединений, распознавания, модели и состояния разговора соответствует разным типам нагрузки. В пользу сохранения этих границ говорят разные жизненные циклы: peer connection живёт в Core, GPU принадлежит внешнему владельцу, диалог переживает запрос в Postgres. Слабее обоснован разрез между Agent и workflow: они вместе завершают один turn и передают полный runtime туда и обратно.
Три workflow реализации полезны как экспериментальная площадка. Как постоянный продуктовый контур они требуют parity и увеличивают объём сопровождения. Пока не доказано, что два движка не имеют consumers, называть их мёртвым кодом преждевременно. Каталоги src_* корректны и к legacy-проблеме не относятся.
Варианты по возрастанию вмешательства
| Изменение | Проверяемый эффект | Цена и условие |
|---|---|---|
| 01. Карта: переиспользовать HTTP-соединения и убрать последовательное ожидание | 2 последовательных GET → параллельные запросы или один общий; session на время жизни приложения | Низкая |
| 02. Сценарии: тратить модель на неоднозначность, а не на готовые координаты | 2 → 1 LLM call; 0 для явной команды UI | Низкая → средняя |
| 03. Потоки и LLM: ограничить очередь до создания задач | Предел pending bytes/tasks; общая отмена и deadline | Средняя |
| 04. Один turn: один результат, атомарная запись и безопасные реплики | Одна логическая фиксация turn при retries и replicas | Средняя |
| 05. Сократить legacy через выбор одного workflow runtime | 3 → 1 поддерживаемый production runtime после проверки эквивалентности | Средняя |
| 06. Выдать браузеру поток его сессии и восстанавливаемый результат | 0 чужих событий; восстановление terminal result | Средняя → высокая |
| 07. Объединить Agent и выбранный workflow в один сервис диалога | Минус один request/reply boundary и один orchestration process | Высокая |
| 08. Полная замена orchestration: сохранённые задания и возобновляемые шаги | Сохранность принятых jobs и recovery по crash matrix | Очень высокая; условный вариант |
Номер отражает вмешательство, а не срочность. Сначала я бы закрыл 04 и 03, поскольку они влияют на корректность при нагрузке и отказах. 01 можно сделать отдельно. Затем — 02, корпус совместимости для 05 и решение по identity в 06. 07 стоит проверить прототипом. 08 нужен только при доказанных требованиях к recovery.
Общая база измерений
До сравнения записать commit, модель и её параметры, dataset revision, cold/warm режим, replicas и limits. Использовать одинаковые текстовые/audio inputs; реальные персональные данные в fixtures не переносить. Для задержек фиксировать минимум p50/p95, размер выборки и долю ошибок. Нагрузку задавать ступенями, а не увеличивать replicas без ограничений.
Разложить время turn на ingress, ожидание очереди, state read, routing, params, tool, LLM, commit и UI delivery. trace_id в JSON полезен для корреляции, но не подтверждает сквозную передачу W3C trace context. OpenTelemetry traces описывает parent/child spans; здесь это основа плана измерений, не заявление о уже работающем trace.
Нельзя обещать процент ускорения без baseline. Структурные результаты — количество calls, процессов и bounded capacity — проверяются отдельно от latency, качества ответа и стоимости.
Актуальные внешние материалы
Через Context7 16.09.2026 получены NATS queue groups/JetStream, aiohttp pooling, PostgreSQL transactions и LangGraph persistence/idempotency. Дополнительно сверены официальные страницы. Запросы, версии и границы применимости сохранены рядом. Эти материалы обосновывают свойства механизмов; выбор новой границы сервиса остаётся инженерным предложением по этому репозиторию.