Представь: твоя команда только что развернула AI-агента, который должен рыться во внутренних документах компании и отвечать на вопросы сотрудников. В разработке он работает как часы. Но в продакшене — начинает галлюцинировать, пропускать ключевые ограничения, тупить. И простым патчем тут не отделаться. Начинается мучительный метод тыка: меняешь нарезку документов, алгоритмы поиска, системные промпты — всё сразу. А потом сидишь и гадаешь: что именно из этого барахла сработало? Потому что изменения переплетаются, и понять, какой рычаг подействовал, становится почти невозможно.
Чтобы выйти из этого замкнутого круга, исследователи из Университета Жэньминь (Китай) и Microsoft Research представили Arbor — фреймворк, который превращает AI-исследования и оптимизацию из последовательности слепых экспериментов в накопительный процесс обучения. Arbor организует гипотезы, тесты и выводы в дерево, которое помогает системе учиться на прошлых ошибках и со временем делать умные, проверенные улучшения.
На практике Arbor показал более чем 2,5-кратный прирост верифицированной производительности по сравнению со стандартными AI-кодинг-агентами — при тех же затратах ресурсов. Для корпоративного AI это прямой путь к автоматизации непрерывного улучшения сложных инженерных систем реального мира.
Понимание узкого места автономной оптимизации
По мере того как языковые модели и AI-системы становятся всё мощнее, от них ожидают выполнения всё более сложных операций — вроде автономной оптимизации (AO) софтверных систем: обвязок агентов, тренировочных алгоритмов и так далее.
AO захватывает фундаментальный цикл автономного исследования: AI-агент стартует с некоего изменяемого артефакта (скажем, кодовой базы для машинного обучения или пайплайна данных) и конкретной цели. Задача агента — итеративно улучшать этот артефакт через экспериментальную обратную связь, без пошагового контроля человека.
Главная проблема AO часто понимается неправильно. Многие инженерные команды обнаруживают, что простой выдел больше времени или вычислительных мощностей кодинговому агенту для оптимизации кодовой базы не даёт лучших результатов. «Автоматизация может заставить AI работать очень долго — но цикл ≠ прогресс», — говорит Джяцзе Джин, соавтор статьи. — «Если цель размыта, или метрику легко накрутить, долгая автоматизация просто быстрее генерирует "улучшения", которые на самом деле никому не нужны».
Джин объясняет, что сложные задачи требуют множества попыток, а стандартные архитектуры агентов лишены критической структуры данных для поддержания состояния. «Как сделать так, чтобы опыт и выводы из каждой попытки накапливались, а не терялись в буфере обратной прокрутки?» — спрашивает он. Без такой структуры агенты просто повторяют одни и те же ошибки.
Текущие агентные системы могут часами гонять эксперименты с хорошо заданными целями: править код, вызывать инструменты, прогонять тесты. Но каждый заход рассматривается в изоляции — не хватает структурных механизмов, которые позволили бы накапливать знания и действовать на их основе.
Им не хватает способности одновременно вести и сравнивать несколько конкурирующих направлений исследований. Без этого невозможно интерпретировать и успехи, и провалы для формирования будущих поисков — а это ключевой механизм, делающий человеческие исследования накопительными.
Обычные кодинг-агенты полагаются на стенограммы диалогов как на свою память. Поскольку задачи AO охватывают сотни шагов и легко вылезают за лимиты контекстного окна, агенты с трудом сохраняют и переиспользуют фактические свидетельства на длинной истории. В итоге они теряют общую структуру исследовательского процесса, застревают на ранних неудачах или гоняются за шумными колебаниями метрик. Системе нужна структурированная, долговечная память, которая записывает: какие направления опробованы, какие фактические доказательства получены и как каждый результат меняет пространство будущих гипотез.
Существующие фреймворки также склонны к «накрутке наград» (reward hacking) и переобучению на метрики разработки. Они создают иллюзию прогресса без реальных улучшений, переносимых на продакшен.
Наконец, агенты общего назначения обычно цепляют вызовы инструментов на одно общее рабочее дерево. Это архитектурное ограничение мешает тестировать параллельные гипотезы в изолированных средах, не портя основную кодовую базу и не затуманивая, какая именно гипотеза вызвала конкретный результат.
Фреймворк Arbor
Arbor решает проблемы AO с помощью фреймворка, автоматизирующего длинный цикл исследования, экспериментирования и абстрагирования — то, что характеризует человеческую науку. Arbor разделяет стратегическое направление исследований и низкоуровневые задачи кодинга через два ключевых компонента:
Координатор — долгоживущий AI-агент, работающий как главный исследователь. Он никогда напрямую не правит целевую кодовую базу. Вместо этого он владеет общим состоянием оптимизационного исследования, наблюдает накопившиеся свидетельства, выдвигает новые гипотезы и направления, решает, что делать с результатами экспериментов.
Исполнители — короткоживущие, узкоспециализированные AI-агенты. Когда координатор хочет проверить идею, он порождает исполнителя и помещает его в изолированную среду — по сути, свежий git worktree. Каждому исполнителю даётся одна гипотеза. Он реализует идею, запускает оценку, отлаживает ошибки и докладывает координатору результаты и созданные артефакты.
Эти два компонента сотрудничают через механизм, названный исследователями «Уточнение дерева гипотез» (Hypothesis Tree Refinement, HTR). HTR представляет весь исследовательский процесс как постоянное ветвящееся дерево, где каждый узел связывает четыре элемента: гипотезу, исполняемый артефакт, фактические доказательства и сжатый вывод. Это позволяет координатору исследовать несколько конкурирующих направлений одновременно, не теряя контекста.
Координатор строит дерево, располагая широкие идеи ближе к корню, а конкретные уточнения — как листья на ветвях. Это даёт Arbor возможность безопасно проверять несколько конкурирующих гипотез одновременно. Если эксперимент исполнителя провалился, дерево записывает причину как отрицательное ограничение — и система не повторяет ту же ошибку бесконечно.
Чтобы понять, почему изоляция в Arbor так важна, рассмотрим типичный корпоративный сценарий: оптимизация пайплайна Retrieval-Augmented Generation (RAG) для внутреннего AI-ассистента. «Когда вы просите одного агента вроде Claude Code или Codex "улучшить точность", он обычно меняет кучу вещей за один проход — нарезку, промпт, метод поиска», — говорит Джин. Это запутывает изменения, не позволяя понять, что именно сработало. К тому же он напрямую мутирует репозиторий без изоляции.
Arbor решает это, трактуя каждый рычаг как отдельную гипотезу. Нарезка — одна ветвь, поиск — другая, промпт — третья. Каждая реализуется и оценивается в собственном изолированном git worktree. «Так вы получаете чистую атрибуцию: "декомпозиция ограничений на стороне поиска дала +X; поиск в ширину на самом деле навредил"», — объясняет Джин.
Когда исполнитель возвращает отчёт, координатор записывает свидетельства в дерево и «обратно распространяет» выводы к родительским узлам. Локальное наблюдение становится обобщённым ограничением, которое формирует будущую генерацию идей координатора.
Чтобы предотвратить накрутку наград и переобучение на данных разработки, HTR использует строгий «шлюз слияния». Даже если исполнитель сообщает о фантастических результатах на отладочных данных, координатор запускает изолированный worktree для проверки кандидата на отложенном тестовом оценщике. Артефакт сливается с текущим лучшим стволом только если он реально улучшает тестовую метрику — гарантируя, что прогресс настоящий.
В целом Arbor попадает под концепцию «loop engineering» (инженерия циклов), популяризированную индустриальными фигурами вроде Питера Штейнбергера (создателя OpenClaw) и Бориса Черни (лида Claude Code). Идея — выйти за рамки одиночных промптов и проектировать итеративные циклы (наблюдай, рассуждай, действуй, проверяй), которые управляют автономными агентами. Однако, как отмечает Джин, «Цикл может заполниться грязными, неотслеживаемыми попытками — и в итоге вы не имеете ничего, чем можно похвастаться, и не можете восстановить, что изменилось».
Arbor в действии
Исследователи оценили Arbor на наборе задач автономной оптимизации, построенном из реальных исследовательских сценариев, и на бенчмарке машинного обучения MLE-Bench Lite. Набор задач AO охватывал разные области AI-разработки: тренировку моделей, инженерию обвязок (harness engineering) и синтез данных.
Для координатора и исполнителей использовались разные бэкбоновые модели: Claude Opus 4.6, GPT-5.5 и Gemini-3-Flash. Arbor сравнивали с сильнейшими кодинговыми агентами — Codex и Claude Code — при одинаковых ресурсах. Для задач MLE-Bench Lite также провели сравнение с топовыми агентными исследовательскими системами: AI-Scientist, ML-Master и AIDE.
Arbor стабильно превосходил базовая. Он добился лучшего результата на отложенных тестах по всем задачам, показав более чем 2,5-кратный средний прирост относительно Codex и Claude Code. На задаче BrowseComp (оптимизация поискового агента) Arbor повысил точность системы на отложенных данных с исходных 45.33% до 67.67%. Codex и Claude Code застряли на 50% и 53.33% соответственно. На MLE-Bench Lite с бэкбоном GPT-5.5 Arbor показал сильнейший результат среди всех протестированных систем.
Arbor доказал устойчивость к переобучению. Например, во время экспериментов с Terminal-Bench 2.0 Claude Code достиг высокой точности на разработке — 75, но на отложенных данных упал до 71. Arbor имел меньший балл на разработке — 72.22, но добился наивысшего на отложенных данных — 77.36, гарантируя переносимость результатов на реальные приложения.
Arbor также показал обобщение в эксперименте с переносом между задачами. После того как Arbor оптимизировал поисковую обвязку для BrowseComp, исследователи взяли оптимизированную кодовую базу и протестировали её на двух несвязанных задачах поисковых агентов — HLE и DeepSearchQA. Оптимизированная база Arbor значительно улучшила производительность и на этих невиданных задачах.
Развёртывание Arbor: точки роста и скрытые затраты
Для руководителей разработки, желающих встроить Arbor в свой существующий стек, фреймворк спроектирован как надстройка над Git-воркфлоу, а не замена. «Его выход — обычная git-ветка, которую ваша существующая система код-ревью, CI и человек могут проверить напрямую», — говорит Джин. Только подтверждённые улучшения сливаются в ствол текущего прогона; основной репозиторий остаётся нетронутым, пока разработчик вручную не решит продвинуть код.
Однако развёртывание Arbor сопряжено с определёнными компромиссами. Джин указывает на главный подвох — стоимость токенов: поддержание долгоживущего координатора, который непрерывно управляет деревом и диспетчеризует исполнителей, является доминирующей статьёй расходов. Запуск нескольких изолированных worktree одновременно также требует реальных вычислительных и дисковых ресурсов для обработки настоящих экспериментов.
Так где же зона комфорта Arbor? По словам Джина, он отлично справляется с задачами, где есть чёткая надёжная метрика, терпимость к долгому горизонту времени и реальное пространство поиска с несколькими правдоподобными направлениями. Например: оптимизация пайплайнов, качество синтеза данных, настройка рецептов тренировки моделей.
И наоборот — командам стоит явно избегать использования Arbor для задач, требующих низкой задержки в реальном времени, очевидных односрочных правок или когда метрика оценки изначально бракована. Качество всего прогона жёстко ограничено качеством оценщика. «Если метрика ненадёжна, Arbor просто быстрее оптимизирует в сторону ненадёжного результата», — замечает Джин.
Джин видит следующую эволюцию за пределами единственной скалярной метрики. «Естественное развитие — чтобы каждый узел нёс вектор — точность, задержку, стоимость — вместо одного числа, — говорит он. — Переход от одного скаляра к многокритериальному поиску Парето — очень естественное расширение фреймворка».