Журнал · Rit.work

Revise: выборочное восстановление агентных workflow после правок

Авторы Revise предлагают отслеживать зависимости в агентном DAG, чтобы после правки отменять только затронутые задачи и переиспользовать результаты, чья актуальность подтверждена.

Rit.work
Студия разработки
2 сентября 2026 г.5 мин чтения

Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.

Revise решает узкую задачу агентных систем: как обработать новую инструкцию, пока предыдущая версия workflow ещё выполняется, не перезапуская весь граф и не сохраняя устаревшие результаты. Runtime сопоставляет изменения с зависимостями данных и управления, отменяет затронутую работу и переиспользует только результаты с подтверждённой актуальностью. По замерам авторов, это сократило число вызовов модели на 40,6–56,0% относительно полного перезапуска. Работа опубликована как препринт и не проходила рецензирования, поэтому результаты остаются заявкой авторов.

Что измеряли

Авторы рассматривают revision как изменение входных данных, требований или управляющего решения во время выполнения агентного workflow. В этот момент часть узлов DAG уже завершена, часть работает, остальные ожидают запуска. Полный перезапуск сохраняет соответствие последней версии запроса, но отбрасывает весь прогресс. Пересчёт линейного суффикса от первого конфликта сохраняет больше работы, однако повторно запускает и независимые узлы, расположенные после конфликта.

В Revise каждому артефакту назначается версия, а для узлов записываются обращения к данным и управляющим значениям. Изменение представлено набором затронутых путей. Runtime пересекает их с фактическими чтениями, распространяет влияние по зависимостям графа и назначает узлам одно из пяти действий:

  • Cancel — остановить работающий затронутый узел.
  • Avoid — не запускать затронутый узел из очереди.
  • Recompute — пересчитать необходимый узел на новой версии состояния.
  • Continue — продолжить работающий узел, если его независимость подтверждена.
  • Reuse — сохранить завершённый результат, если его зависимости не изменились.

Продолжение и переиспользование не означают немедленную публикацию результата. Узел выполняется на неизменяемом снимке состояния и получает сертификат с версией журнала, прочитанными данными, управляющими зависимостями и родительскими попытками. Перед commit runtime повторно проверяет сертификат с учётом всех последующих revisions. Эффекты инструментов до проверки остаются staged.

Сначала авторы искали саму возможность вмешательства в 5 825 анализируемых сессиях SWE-chat. В 657 сессиях обнаружился сопоставленный сигнал отложенной правки, а в 118 до её доставки продолжалась наблюдаемая работа ассистента, инструмента или фоновой задачи. Для 167 пересекающихся ответов ассистента медиана интервала от постановки сообщения в очередь до завершения ответа составила 5,54 секунды, p95 — 56,55 секунды.

Runtime оценивали на приложениях LangGraph и LLMCompiler с локальным Qwen3-14B через SGLang. Сравнением служили полный перезапуск и динамический пересчёт суффикса от первого конфликта. Суффиксный вариант получал ту же информацию о зависимостях, поэтому разница должна была отражать гранулярность восстановления, а не качество provenance.

Отдельные проверки включали 300 запусков с конкурирующими revision и commit, поздними чтениями, последовательными правками, неизвестными зависимостями, изменениями состава коллекций и переключением управляющих маршрутов. Нагрузочный эксперимент охватывал 15 000 workflow, 64 tenants, четыре H100 и входную нагрузку от 1,4 до 2,6 workflow в секунду.

Что показали

В таблице корректности авторы свели 15 939 запусков из интеграционных сценариев, LLMCompiler, репозиторных replay, проверки протокола и нагрузочного эксперимента. Во всех запусках результат совпал с oracle, основанным на последней версии и полном перезапуске; устаревших опубликованных результатов и эффектов авторы не зафиксировали. Все 800 проверок сертификатов актуальности заняли менее 0,04 мс каждая.

На LangGraph Revise сократил число вызовов модели на 56,0% относительно полного перезапуска и на 43,6% относительно динамического суффикса. Model-wall time снизился соответственно на 62,7% и 50,2%. В 48 workflow LLMCompiler число вызовов уменьшилось на 40,6% и 31,3%, а расход токенов — на 7,9% и 5,8%.

В репозиторных replay Revise выполнил на 12,94% меньше повторной работы, чем суффиксный вариант, при 95-процентном доверительном интервале 7,77–17,70%. Объём отброшенной завершённой работы уменьшился на 10,38%, доверительный интервал — 2,74–18,81%. Авторы проверяли эквивалентность по итоговому ответу, pytest, состоянию файлов и patch, а также видимым эффектам.

Экономия вычислений не всегда пропорционально сокращала задержку одного запроса. В LangGraph медианная end-to-end задержка улучшилась на 5,9% относительно суффикса, хотя model-wall time снизился на 50,2%. В репозиторном replay изменение end-to-end задержки составило −0,55%, а доверительный интервал от −4,00 до +3,84% включает отсутствие эффекта.

Преимущество проявилось заметнее при конкуренции за GPU. Относительно суффикса Revise сократил число токенов от revision до корректного завершения на 13,26%, а model-wall time — на 14,70%. При нагрузке 1,0× SLO goodput изменился на −0,12%; при 1,1× вырос на 3,07%, при 1,3× — на 5,43%. p99 снизился соответственно на 1,13%, 4,42% и 13,80%.

Ограничения

SWE-chat подтверждает временное пересечение сообщений и работы, но не объём вычислений, который можно было бы безопасно сохранить. В трассах нет токен-прогресса, версий артефактов и полного графа зависимостей. Для ручной классификации авторы выбрали 30 событий из 173 событий с полными временными метками. Эта выборка предназначена для построения таксономии, а не для оценки распространённости локальных revisions.

Репозиторная проверка также ограничена масштабом. Из 100 изученных SWE-Review-Traj авторы выбрали пять локально воспроизводимых workload. Они сохранили репозиторий, patch, замечания reviewer и тесты, но контролировали момент появления revision. Поэтому эксперимент проверяет восстановление на реальных артефактах, но не воспроизводит естественное распределение времени правок.

Основные замеры сделаны на двух фреймворках и одной модели, Qwen3-14B. Нагрузочный сценарий использует четыре H100, 64 tenants и 50% запросов с revisions. Работа не показывает, сохранятся ли проценты экономии для других моделей, графов, долей revisions и инфраструктурных конфигураций.

Заявленная корректность относится к выполнению внутри процесса. Авторы прямо отделяют её от распределённого консенсуса и восстановления после сбоев. Физическое переиспользование KV cache, включая размещение между GPU, также находится вне границ системы. Без fine-grained provenance Revise консервативен: во всех 48 соответствующих случаях восстановление оказалось эквивалентно полному перезапуску.

Сравнение охватывает полный restart, суффиксный recovery и ожидание конца текущего хода в live-экспериментах. Прямых экспериментальных сравнений с другими системами rollback, transactional effects или revisable execution из раздела related work авторы не приводят. Затраты на внедрение адаптеров, staging внешних эффектов и сбор полных зависимостей отдельно не оценены.

Что это значит

Для команды, которая строит линейного агента с короткими вызовами и редкими правками во время выполнения, работа не меняет архитектурный план. При слабой конкуренции авторы измерили почти нулевое изменение SLO goodput, а сокращение model-wall time не превратилось в сопоставимое улучшение end-to-end задержки.

Для долгих DAG с параллельными ветвями вывод практичнее: полный restart не обязан быть единственной безопасной политикой. Но экономия появляется не из эвристического переиспользования ответов, а из инфраструктуры корректности — версионированного состояния, динамических data/control dependencies, отмены запросов, staged effects и повторной проверки перед commit.

Если такая provenance уже собирается, Revise задаёт полезную модель runtime: revision становится изменением версии состояния, а recovery — вычислением затронутого подграфа. Если зависимости неполны или внешние эффекты нельзя отложить, работа скорее подтверждает необходимость сохранить консервативный restart. Планировать выборочное восстановление как отдельный слой имеет смысл для систем, где revisions пересекаются с дорогой параллельной работой и GPU регулярно работает под нагрузкой.

Источники

Пауза в чтении

Похоже на вашу задачу?

Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.

Rit.work

Студия разработки

Собираем мобильные приложения и помогаем командам получать от AI реальную пользу. Основатель и команда, работаем удалённо — с клиентами в России и за рубежом.

Ко всем материалам
Понравилось? Обсудим вашу задачу