Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Управляющую обвязку ИИ-агента научили переписывать целиком и одновременно менять правила, по которым ищут следующую версию. Prithwish Jana и соавторы представили MILO; работа не рецензирована, а числа получили сами авторы: на Terminal-Bench 2.1 система набрала 86,1% против 83,8% у лидера официальной таблицы и потратила на 26% меньше токенов, чем исходная обвязка. Для агентных продуктов это способ улучшать длинные сценарии без обучения новой модели и без ручного перебора архитектур.
Обвязка влияет не только на подсказку модели
Управляющая обвязка (harness) определяет, как модель работает с окружением. Она передаёт модели контекст, подключает инструменты и память, выполняет команды, запускает вспомогательных агентов, проверяет результат и решает, когда остановиться.
На короткой задаче слабое решение иногда исправляет удачная подсказка. В длинном сценарии ошибки накапливаются: агент преждевременно объявляет работу законченной, тратит срок на второстепенные действия, плохо проверяет собственный результат или раздувает контекст. Поэтому настройка отдельных формулировок не охватывает значительную часть пространства решений.
Автоматический поиск обвязки уже строят как эволюционный процесс: система выбирает существующий вариант, меняет его, запускает на заданиях и сохраняет удачные изменения. Прежние подходы часто редактируют только подсказки, навыки или память. Те, что умеют переписывать всю обвязку, обычно заранее фиксируют правила выбора кандидатов и застревают, когда однотипные изменения перестают помогать.
Есть и практическая причина автоматизировать этот цикл. Обвязка зависит от конкретной модели: после замены модели меняются работа с инструментами, чувствительность к инструкциям и характер ошибок. Ручную настройку приходится повторять, даже если задачи продукта остались прежними.
Как MILO выходит из тупика поиска
MILO ведёт несколько независимых ветвей, которые авторы называют островами. Каждый остров начинается со своей исходной обвязки и развивает отдельное дерево вариантов. Ветви обмениваются удачными идеями, но не вытесняют друг друга общим рейтингом, поэтому необычный исходный вариант может сохраниться достаточно долго, чтобы дать лучший результат.
Система хранит не только принятые версии, но и отклонённые. Для каждого изменения остаются исходная обвязка, новая версия, результаты запусков и следы ошибок. Неудачная попытка становится отрицательным примером: следующий агент-редактор видит, какие решения уже проверяли и почему они не сработали.
На каждом острове свой агент-редактор. Он получает историю общего поиска, слабые места выбранного предка и может переписать всю обвязку, включая порядок действий и проверки. Кандидат сохраняют, если он улучшает границу сразу по нескольким критериям: качеству решения, расходу токенов и задержке. Так поиск не должен повышать долю решённых задач любой ценой.
Внешний контур следит уже не за обвязками, а за ходом самого поиска. Когда ветвь перестаёт улучшаться, оркестратор может перенести в неё часть другой родословной, выделить новое направление, назначить другого агента-редактора или пересобрать последовательность заданий. Получается связка из двух процессов: внутренний меняет продуктовую логику агента, внешний — способ, которым эту логику ищут.
Метод проверяли на Terminal-Bench 2.1, PaperBench и DeepSWE с Opus 4.8 и gpt-oss-120b. Обвязки искали на одной части заданий, а выбирали по другой; каждый вариант запускали повторно и сравнивали с ручными обвязками и другими автоматическими методами. Эти условия близки к задачам разработки и исследовательской работы, но не доказывают такой же выигрыш в произвольном бизнес-процессе.
Командам нужен измеримый сценарий, а не новый стек
С Opus 4.8 MILO улучшил результат исходной обвязки на 12,0% в Terminal-Bench 2.1, на 28,3% в PaperBench и на 10,3% в DeepSWE. Предыдущие методы поиска на тех же испытаниях давали меньший прирост.
Особенно показателен ход поиска с gpt-oss-120b. Все ветви остановились, но после вмешательства оркестратора снова начали улучшаться. Самый слабый исходный вариант с результатом 39,2% в итоге породил лучшую обвязку с 59,9% — обычный отбор по текущему рейтингу, вероятно, удалил бы эту ветвь слишком рано.
Работа меняет планы команд, у которых уже есть агент, исполняемая обвязка и набор проверяемых длинных заданий. Вместо ручной настройки подсказок можно разрешить системе менять управление инструментами, проверки, остановку и распределение работы между агентами. Модель при этом остаётся неизменной.
Но MILO не устраняет стоимость оценки. Каждый кандидат нужно действительно запускать, а длинные задания могут выполняться часами. Метод имеет смысл, когда команда умеет автоматически проверить результат, отделить набор для поиска от контрольного набора и окупить вычисления многократным использованием найденной обвязки.
Для редких или плохо формализованных процессов ручная разработка останется проще. Для повторяемых сценариев с тестами или строгим проверяющим механизмом MILO предлагает другой цикл работы: после смены модели не переносить старую обвязку вслепую, а заново искать подходящую архитектуру и позволять поиску менять собственную стратегию.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
