Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
LLM-агента удалось автоматически приспособить к конкретной рабочей системе, меняя не только инструкции, но и модель с кодом вокруг неё. Лучший вариант превзошёл исходный Gemini 3.5 Flash и стоил до 29 раз дешевле, хотя препринт не рецензирован и числа получили сами авторы. Для продуктовых команд это повод рассматривать архитектуру агента как единый объект настройки, но пока не как полностью автономный процесс.
Настройщик меняет один компонент за итерацию
AutoOnboarder из работы Tanay Arora и Cong Liu состоит из двух агентов. Executor выполняет целевую задачу, а Onboarder наблюдает за его работой и может менять три компонента: модель, шаблон промпта и обвязку (harness) — программу, которая передаёт модели контекст, открывает доступ к инструментам, разбирает ответы и решает, когда остановиться.
На каждой итерации Onboarder реализует одну отдельную идею только в одном компоненте. Затем он запускает Executor на учебных примерах, получает журнал действий, оценку и текстовый разбор ошибок, после чего сохраняет изменение или откатывает его. За двенадцать итераций нужно выбрать одну конфигурацию, которая укладывается в заданную стоимость обработки случая.
Учебные и проверочные данные находятся на разных виртуальных машинах. Onboarder видит записи из учебной части и журналы Executor, но не может читать проверочные примеры или запускать их оценку. Отправленные формы получают криптографическую подпись, а права на файлы ограничивают изменения моделью, промптом и обвязкой.
Систему проверяли на заполнении заявок для предварительного согласования геномного секвенирования. Агент читал синтетическую медицинскую карту, переносил сведения в форму и должен был остановиться, если находил неисправимую ошибку. Для настройки использовали 20 случаев, для проверки — 180; ошибки относились к 23 классам. Успех засчитывали только за безошибочную форму либо остановку с верно указанной причиной.
Главная проблема — не средний результат, а разброс
Повторный запуск настройки мог привести к существенно другому агенту при тех же исходных условиях. Разница между худшей и лучшей итоговой оценкой достигла 0,302, а стоимость обработки случая менялась от $0,032 до $0,069. Обычный повтор проверки уже выбранного агента давал гораздо меньший разброс, поэтому нестабильность возникала прежде всего во время поиска конфигурации.
Onboarder неравномерно использовал доступные способы настройки. Он часто менял модель, однако такие попытки чаще приводили к сбою или откату, чем к пригодной конфигурации: дешёвые модели не всегда соблюдали формат действий браузерной обвязки, поддерживали изображения или оставались доступными у провайдера. Код обвязки агент, напротив, редактировал редко.
Свободные текстовые инструкции тоже работали ненадёжно. Onboarder мог выбирать модель по знакомому названию вместо доступных сравнений, преждевременно завершать поиск или фактически отказываться от заполнения формы. Авторы связывают это с интерфейсом самого настройщика: контракт описывал правила словами, но программно не заставлял планировать поиск и использовать все доступные компоненты.
Проверка охватывает одну медицинскую задачу, один тип браузерной среды и небольшой набор запусков. В роли Onboarder выступал Claude Code с Opus 4.8, а варианты Executor выбирались из каталога OpenRouter на момент эксперимента. Поэтому работа показывает осуществимость подхода, но не доказывает, что он так же поведёт себя в другой предметной области или с обновлёнными закрытыми моделями.
Командам стоит расширить контур оптимизации, но оставить контроль
Работа меняет план экспериментов для команд, которые сейчас подбирают только промпт или только модель. Поведение агента зависит и от того, как обвязка сокращает историю, описывает действия, сохраняет промежуточные данные и передаёт наблюдения. Дешёвая модель с подходящим интерфейсом может оказаться выгоднее более дорогой модели в неизменной обвязке.
Сам цикл можно перенести в разработку без полной автономности: изолировать проверочный набор, менять по одному компоненту, сохранять журналы и откатывать неудачные версии. Стоимость следует считать частью целевой функции, а не проверять после выбора лучшего качества. Иначе настройщик легко найдёт вариант, который решает задачу, но не соответствует экономике продукта.
Полностью автономный поиск пока не стоит ставить в критический производственный контур. Сначала ему нужны каталог совместимых моделей, программно заданный порядок рассуждений и контролируемый доступ к справочным данным. В эксперименте отсутствие сети мешало получать точные медицинские коды, но открытый интернет позволил бы искать ответы на конкретные проверочные случаи вместо освоения общего правила.
Практический вывод для архитектуры уже применим: версионировать нужно связку из модели, промпта и обвязки, а проверять — всю связку целиком. AutoOnboarder показывает возможный способ автоматизировать такой поиск, но большой разброс между запусками оставляет за командой выбор кандидата, повторную проверку и решение о выпуске.
Источники
Иллюстрация: рисунок из статьи «AutoOnboarder: Autonomously Onboarding LLM Agents», Tanay Arora, Cong Liu, CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
