Agent Lightning v1.0: обучение ИИ-агента без пересборки его рабочей среды

Что объявлено: обучать агента вместе с его обвязкой

По объяснению исследователей, современный агент — это не только модель. Его поведение зависит от инструментов, управления контекстом, логики исполнения и среды. Эти элементы координирует обвязка. Перенос её логики в отдельный обучающий фреймворк требует работы и может изменить поведение системы.

Agent Lightning размещает между агентом и моделью LLM-прокси. Обвязка продолжает управлять взаимодействием со средой, а обучающая система наблюдает запросы и ответы. Как отмечает компания, для подключения существующей обвязки обычно достаточно перенаправить обращения к модели на этот прокси.

Кодовая база версии v1.0 насчитывает примерно 3500 строк. В архитектуре выделены шлюз API, контроллер запусков и специализированный тренер на базе verl. Шлюз сохраняет необходимые данные, контроллер управляет исполнением агентов, а тренер собирает материал для обучения.

Агенты могут выполняться как локальные процессы или стандартные задания Kubernetes. Поддерживаются собственные кластеры, облачный Kubernetes и локальная инфраструктура. Зависимость от платных коммерческих песочниц не требуется, но это не означает отсутствия затрат на вычисления и обслуживание.

Какие результаты приводит компания

Исследователи построили полный конвейер для агента программирования на SWE-smith, mini-SWE-agent и Qwen3.5-9B. Он включал очистку данных, подготовку окружения, защиту от обхода системы вознаграждения и обучение с подкреплением. Обучающий набор содержал около 6000 примеров.

По сообщению Microsoft Research Asia, обучение подняло Pass@1 модели Qwen3.5-9B на SWE-bench Verified с 41,8% до 56,4%. Абсолютная прибавка составила 14,6 процентного пункта. Эти значения описывают опубликованный эксперимент, а не ожидаемый эффект для любой корпоративной задачи.

Отдельно представлена схема Collocated Async RL: выполнение агентов и обновление модели используют общий набор GPU. При обновлении шлюз приостанавливает приём новых запросов и ждёт завершения текущих. После обновления работа продолжается без изменения внешней обвязки.

В экспериментах компания получила примерно двукратное сквозное ускорение относительно синхронного RL, используя меньше GPU, чем при обычном асинхронном подходе. В сообщении нет универсального расчёта экономии для бизнеса: переносить этот результат напрямую в финансовую модель проекта не следует.

Бизнес-сценарий: пилот внутри команды разработки

Редакционный сценарий — проверить подход на агенте, который уже помогает команде исправлять программный код. Смысл пилота не в создании новой обвязки ради обучения, а в оценке того, можно ли улучшить выполнение выбранных задач, сохранив существующий порядок работы агента.

Начать предлагаем с ограниченного класса исправлений, для которых команда может независимо проверить результат. До обучения стоит зафиксировать исходное качество, условия запуска и критерии приёмки. Иначе будет трудно отделить изменение модели от изменений инструментов, окружения или состава задач.

На время сравнения рекомендуем сохранить одинаковые правила доступа и исполнения. Обучение не должно становиться поводом расширять полномочия агента. Подключение через прокси следует рассматривать как техническую интеграцию, а не как подтверждение готовности системы к самостоятельной работе.

Для решения о продолжении пилота предлагаем сопоставлять качество исправлений с расходами на обучение, выполнение и проверку. Даже положительная динамика технической метрики сама по себе не отвечает на вопрос, оправдан ли подход для конкретной команды.

Ограничения и контроль: обвязка остаётся частью задачи

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

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

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

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

Практический чек-лист перед решением о внедрении

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

Главный предмет проверки — не компактность фреймворка сама по себе, а улучшение агента в значимом рабочем процессе. Опубликованные результаты дают основание изучить подход. Решение о применении предлагаем принимать только после собственного сравнения качества, управляемости и затрат.

Сцена по теме: Офис: команда разработки →