Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
WorkRover исправляет учебные среды для длинных офисных задач по результатам запусков агента, не пересобирая весь пакет без разбора. В работе команды Fudan University и нескольких партнёров, которая не рецензирована, а числа получили сами авторы, обученная модель превзошла исходную Qwen3.5-35B-A3B на JobBench на 26,27 процентного пункта. Подход меняет саму подготовку данных: среда становится версионируемой системой, где контекст, задание и проверка результата развиваются вместе.
Среда состоит из связанных контекста, задания и проверки
Обычный набор для обучения агента легко рассинхронизировать. В рабочей папке может не оказаться нужного файла, инструкция может требовать недоступное действие, а проверка — отвергать корректный результат или принимать ошибочный.
WorkRover собирает такой набор как связанный пакет. Рабочий контекст включает файлы, приложения и доступные инструменты. Задание задаёт цель, материалы, результат и ограничения. Верификатор проверяет итог по файлам, состоянию приложений и изменениям рабочего пространства.
Связи между компонентами хранит управляющий контур Harness. Он знает, какие файлы использует задание, какие действия поддерживают приложения и на какие свидетельства опирается верификатор. Поэтому изменение исходной таблицы можно протянуть до зависимого задания и его проверки, а не исправлять каждый элемент вручную.
Перед допуском в обучение отдельный агент выполняет задание из чистого начального состояния. Этот запуск подтверждает, что задача выполнима, и создаёт эталонное состояние. Верификатор затем проверяют не только на эталоне, но и на заведомо неправильных результатах и допустимых альтернативных решениях. Он должен оценивать требуемый итог, а не совпадение с единственным заранее записанным путём.
Совместный ремонт сохраняет смысл задания
Когда запуск выявляет дефект, WorkRover сначала отделяет ошибку среды от ошибки самого агента. Если агент выбрал неверное действие, пакет не меняют. Если проблема находится в контексте, задании, Harness или верификаторе, для затронутых компонентов готовят фиксированные варианты исправлений.
Механизм FCR проверяет изменения по отдельности и совместно. Для каждого сочетания он достраивает обязательные зависимые обновления, повторяет запуск при одинаковых условиях и прогоняет проверки на связанных задачах. При четырёх затронутых компонентах получается не более 16 сочетаний, после чего система выбирает наименьший набор изменений, который устраняет дефект и не меняет требования.
На естественно возникших дефектах доля безопасных исправлений выросла с 60,7% при полной перегенерации до 70,3% с FCR. Доля случаев, где ремонт непреднамеренно менял смысл задания, снизилась с 14,3% до 1,3%. Работа с комбинациями требует больше вычислений, чем безусловное применение всех предложенных правок, но заметно реже ломает связанные задачи.
Для обучения модели авторы добавили VTCA — распределение награды по отдельным шагам. Детерминированные проверки сравнивают сохранённые состояния рабочего пространства до и после действия. Положительный вклад получает шаг, который создал проверяемый результат, а часть награды может перейти более ранним действиям, если записанные зависимости показывают, что их выводы действительно использовались позже.
Так чтение таблицы получает награду, если извлечённые данные затем вошли в корректный расчёт. Простое открытие файла не считается полезным действием. Ошибка или откат остаются на том шаге, где они произошли, а промежуточные вызовы модели-оценщика не требуются.
Планы меняются у команд, которые сами строят обучение агентов
WorkRover проверяли на Qwen3.5-35B-A3B и внешних наборах задач для профессиональных результатов, работы с документами и действий между приложениями. Сравнения охватывают исходную модель, обучение по итоговой награде за весь запуск и вариант с наградой за отдельные шаги. Это результат для одной основы модели и созданной авторами учебной инфраструктуры, а не готовая оценка любого офисного агента.
Для команды, которая только подключает готовую модель через API, работа не требует менять архитектуру продукта. WorkRover относится к подготовке сред и дополнительному обучению, а не к выполнению запросов в рабочем приложении.
Если команда сама генерирует задания, запускает обучение с подкреплением или обслуживает наборы проверяемых процессов, план стоит пересмотреть. Контекст, формулировку задания и верификатор лучше хранить как версии единого пакета с явными зависимостями. После каждого ремонта нужно повторно проверять затронутые задачи и подтверждать исправление новым запуском.
Главный практический вывод касается не выбора Qwen3.5, а устройства конвейера данных. Увеличивать число синтетических заданий недостаточно: ошибочная проверка превращает корректное действие в отрицательный пример, а несогласованный контекст делает задачу невыполнимой. WorkRover показывает схему, в которой обратная связь от запусков улучшает одновременно учебную среду и саму модель.
Источники
Иллюстрация: рисунок из статьи «WorkRover: Scaling Long-Horizon Cowork Agent Training Via Recursive Environment Evolution», Hang He, Linting Wang, Guanming Liu и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
