Самая странная вещь в обучении ИИ-агентов с подкреплением происходила незаметно. Инженер брал агента, который уже работает в продакшене, вынимал из него логику, переписывал её внутри тренировочного фреймворка, а потом удивлялся, что обученная версия ведёт себя не так, как боевая. Microsoft Research Asia предлагает просто перестать это делать. Их Agent Lightning v1.0 ставит между агентом и моделью обычный прокси, и дальше учится на том, что через этот прокси проходит.

Результат на удивление конкретный: Qwen3.5-9B поднялась с 41,8% до 56,4% на SWE-bench Verified, то есть на 14,6 процентного пункта, и для этого хватило примерно шести тысяч обучающих примеров. Весь фреймворк при этом занимает около 3500 строк кода.

Что такое Agent Lightning v1.0

Это открытый фреймворк для agentic RL, в котором обучение идёт на том же harness, что и эксплуатация. Harness здесь означает внешнюю обвязку агента: управление контекстом, протокол вызова инструментов, цикл выполнения, работу с окружением. Agent Lightning не воспроизводит эту обвязку у себя, а подключается к ней сбоку.

Формально подход назвали Harnessed Agentic RL. В классической схеме среда и цикл взаимодействия принадлежат тренировочному фреймворку. Здесь и то и другое остаётся за harness, а система обучения видит только последовательность пар «запрос к модели, ответ модели».

Почему старый agentic RL перестал масштабироваться

Ранние системы вроде verl, AReaL и slime строились вокруг допущения, что весь rollout укладывается в одну непрерывную траекторию токенов. Модель выдаёт действие, среда возвращает наблюдение, наблюдение дописывается в контекст, модель выдаёт следующее действие. Пока агент был простым ReAct-циклом, этого хватало.

Современные coding-агенты в это допущение не помещаются. mini-SWE-agent, OpenHands, OpenCode, Claude Code и Codex приносят с собой собственное управление контекстом, свои протоколы инструментов, свою логику исполнения и свои зависимости. Пересобрать такого агента внутри RL-фреймворка стоит дорого, а главное, пересобранная версия уже не гарантирует того же поведения, что и развёрнутая.

Отсюда и разрыв, который легко не заметить: метрики растут на тренировочной копии агента, а в продакшене остаётся другая система. Agent Lightning закрывает этот разрыв тем, что тренирует именно ту систему, которую потом выкатят.

Три компонента вместо монолита

Внутри v1.0 всего три части, и это осознанное решение, а не следствие экономии времени. API Gateway работает как OpenAI-совместимый прокси: он хранит rollout, модели и события, связывает каждый вызов модели от harness с конкретным rollout и записывает промпты, ответы и логвероятности, без которых обучение невозможно. Rollout Controller запускает и ведёт выполнение агента, локальными процессами или стандартными заданиями Kubernetes. Customized Trainer построен на verl, создаёт rollout, дожидается их завершения, собирает сэмплы и приводит их к тренировочному виду через sample adapter.

Практическое следствие простое: если у вас уже есть работающий harness, обычно достаточно перенаправить endpoint, который раньше смотрел на API модели, в сторону прокси Agent Lightning. Код агента при этом не меняется.

Четыре проблемы, которые создаёт живой harness

Как только цикл взаимодействия уходит из тренировочного фреймворка, обучение начинает видеть мир иначе. Один rollout может распасться на переменное число обучающих сэмплов, и это порождает четыре конкретные инженерные задачи.

Первая связана с ретокенизацией и склейкой сэмплов. Harness держит контекст как текст, а RL нужно знать конкретные token IDs, которые были сэмплированы во время rollout. Повторный проход через chat template и токенизатор может сдвинуть границы токенов, поэтому соседние вызовы не всегда удаётся слить в один сэмпл.

Вторая касается расчёта преимуществ. Из-за ретокенизации, субагентов и суммаризации контекста один rollout распадается на несколько сэмплов. Если считать базовые значения и advantage на уровне сэмпла, rollout, породивший больше сэмплов, будет учтён несколько раз, и исходные статистические соотношения на уровне rollout исказятся.

Третья проблема вытекает из второй. Если усреднять loss по числу сэмплов, больший вес получат те rollout, которые просто породили больше сэмплов, а это чаще всего продукт поведения harness, а не качества политики. Нормализацию приходится строить так, чтобы она не наследовала эту случайность.

Четвёртая задача относится к планированию тренировочного бэкенда. Число сэмплов и их длина становятся известны только после того, как harness закончил работу, а конфигурация GPU и режимы параллелизма заданы заранее и не меняются на ходу. Бэкенду приходится отображать переменную нагрузку на фиксированные ресурсы.

Авторы отдельно подчёркивают, что сравнение на уровне rollout и нормализация на уровне rollout дают более высокую награду на валидации и держат энтропию политики стабильнее, чем пооперационная обработка на уровне сэмплов. На практике это означает, что часть работы уходит от модели к инженерии данных.

Collocated Async RL: вдвое быстрее на меньшем числе GPU

Время выполнения rollout у агентов различается в разы, и это ломает обе крайности. Синхронное обучение ждёт самого медленного агента в батче и держит GPU простаивающими. Полностью асинхронное поднимает утилизацию, но требует отдельных пулов GPU для роллаутов и для обновления весов, то есть денег на инфраструктуру.

Решение в Agent Lightning называется Collocated Async RL. Rollout и обновление модели делят один и тот же набор GPU. Когда роллаутов набралось достаточно, Gateway перестаёт принимать новые запросы, дожидается завершения тех, что уже в работе, обучение проходит обновление, и rollout возобновляется. Для внешнего harness это выглядит как обычная задержка. Заявленный выигрыш: примерно двукратное ускорение end-to-end по сравнению с синхронной схемой при меньшем числе GPU, чем у обычной асинхронной.

Kubernetes вместо платных песочниц

Чтобы собрать достаточно rollout, нужно одновременно гонять много агентов, а каждый агент потребляет CPU, память и диск. Большинство соседних реализаций Harnessed Agentic RL размещают агентов в коммерческих песочницах вроде Modal Sandbox или E2B, и стоимость растёт линейно вместе с масштабом экспериментов.

Agent Lightning запускает агентов как стандартные задания Kubernetes, используя уже имеющиеся кластеры, облачный Kubernetes или локальную машину. Для исследовательской группы это часто разница между «эксперимент можно повторить» и «эксперимент съел бюджет». Плюс требование воспроизводимости выполняется естественным образом: пайплайн открыт целиком.

Результат: шесть тысяч сэмплов и плюс 14,6 пункта

Эксперимент собрали на SWE-smith, mini-SWE-agent и Qwen3.5-9B, пройдя весь путь от очистки данных и построения окружений до защиты от reward hacking и собственно RL-обучения. Тренировочный набор содержит около шести тысяч сэмплов, и крупных вычислительных ресурсов он не требует.

Одно только RL-обучение подняло Qwen3.5-9B с 41,8% до 56,4% Pass@1 на SWE-bench Verified. Формулировка «одно только» здесь важна: прирост получен не за счёт смены базовой модели и не за счёт дополнительной дистилляции, а за счёт обучения на реальной обвязке с корректно посчитанными преимуществами.

Отдельная ценность в том, что эти 14,6 пункта получены на агенте, который не переписывали. Тот harness, который участвовал в обучении, и есть тот harness, который разворачивают.

Три дороги, из которых выбрали четвёртую

Сравнение с соседями здесь полезнее любых обещаний. Первая дорога, по которой шли ранние системы, состоит в том, чтобы реализовать среду и цикл взаимодействия внутри тренировочного фреймворка. Это даёт полный контроль над траекторией, но цена высока: переписанный агент и обучение на копии. Вторая дорога, вынести агентов в коммерческую песочницу: быстро на старте, дорого при масштабировании, и воспроизводимость чужая. Третья, самая распространённая на практике, вообще не обучать агента, а подкручивать промпт и набор инструментов, потому что обучение кажется слишком дорогим.

Agent Lightning выбирает вариант, который раньше выглядел неудобным: оставить цикл там, где он уже отлажен, и научиться наблюдать его снаружи. Плата за это: четыре инженерные задачи из предыдущего раздела и необходимость иметь прокси на пути к модели. Выигрыш: обучение на той системе, которая потом работает, и отсутствие отдельной инфраструктуры для песочниц.

Что это меняет для практики

Первое следствие касается стоимости входа. Раньше, чтобы применить RL к своему агенту, команде требовалось портировать логику агента в чужой фреймворк, а это недели работы и постоянный риск расхождения. Теперь порог сводится к смене endpoint и подготовке данных.

Второе следствие касается честности измерений. Значительная часть публикаций об улучшении агентов сравнивает модели в обвязке авторов, а не в той, что стоит у читателя. Когда тренируется реальный harness, вопрос «а как это поведёт себя у нас» становится проверяемым, а не риторическим.

Третье следствие лежит в области, которую легко упустить: harness становится объектом оптимизации. Если метрику можно улучшить, меняя поведение обвязки, часть прироста будет приходить не от модели, а от того, как она вызывает инструменты и сколько контекста себе оставляет. Для тех, кто собирает агентов, это аргумент в пользу версионирования harness и фиксации его версии в экспериментах.

Есть и границы. Подход требует, чтобы harness можно было направить на произвольный OpenAI-совместимый endpoint, а часть коммерческих обвязок этого не позволяет. Воспроизводимость на уровне «поставил и заработало» тоже ограничена: нужны рабочие окружения и защита от reward hacking, а это самая скучная и самая дорогая часть пайплайна. Плюс 3500 строк кода это про контроль и понимание, а не про отсутствие работы.

Часто задаваемые вопросы

Нужно ли переписывать агента, чтобы начать обучение?

Нет, в этом и смысл подхода. Harness остаётся тем же кодом, который работает в продакшене. Достаточно указать в нём новый endpoint, ведущий на прокси Agent Lightning, и дальше фреймворк сам записывает промпты, ответы и логвероятности в привязке к rollout.

Почему нельзя просто считать advantage по каждому сэмплу?

Потому что один rollout распадается на переменное число сэмплов. Rollout, который породил больше вызовов модели, получит больший вес, и статистика на уровне rollout исказится. Из-за этого же усреднение loss по числу сэмплов перестаёт отражать качество политики и начинает отражать поведение harness.

Насколько это дорого по железу?

Дешевле, чем кажется. Авторы подчёркивают, что набор из шести тысяч сэмплов не требует крупных вычислений, а Collocated Async RL позволяет делить один пул GPU между rollout и обновлением весов, давая примерно двукратное ускорение и при этом занимая меньше GPU, чем обычная асинхронная схема с раздельными пулами.

Итог

Agent Lightning v1.0 решает не модельную, а инженерную проблему: убирает необходимость пересобирать агента ради обучения. Harnessed Agentic RL, прокси перед моделью, три компонента на 3500 строк, Kubernetes вместо платных песочниц и аккуратная работа с преимуществами и нормализацией дают измеримый результат: 41,8% превращаются в 56,4% на SWE-bench Verified при шести тысячах примеров.

Если вы держите своего агента в продакшене и думаете про дообучение, самый полезный шаг сегодня не в выборе модели, а в проверке, можно ли перенаправить её вызовы на собственный прокси. Всё остальное в этом пайплайне уже открыто.