Автоматизация ≠ прогресс
Большая идея последних двух лет — AI-агенты пишут код, улучшают системы, оптимизируют пайплайны. Есть только одна проблема: дать агенту больше времени и токенов не значит получить лучший результат. Без структуры агент зацикливается, повторяет одни и те же ошибки и создаёт иллюзию работы. Именно это исследователи Microsoft Research и Реньминьского университета называют «loop — не то же самое, что progress».
Arbor: дерево гипотез вместо чата
Фреймворк Arbor решает проблему архитектурно. Вместо монолитного агента в бесконечном цикле — два компонента:
- Координатор — долгоживущий агент, который не трогает код напрямую. Он управляет деревом гипотез, генерирует идеи, решает что делать с результатами экспериментов. Думайте о нём как о руководителе исследовательской группы.
- Исполнители — короткоживущие агенты, каждый из которых получает одну конкретную гипотезу и работает в изолированном git-worktree. Один тестит chunking, другой retrieval, третий системный промпт — и результаты не смешиваются.
Когда исполнитель завершает эксперимент, координатор записывает результат в дерево и «распространяет» вывод вверх — так локальное наблюдение становится общим знанием, формирующим будущие исследования.
Результаты, которые говорят сами за себя
В сравнительных тестах с одинаковым ресурсным бюджетом:
- BrowseComp (оптимизация поискового агента): точность с 45,33% до 67,67% у Arbor, тогда как Claude Code и Codex застряли на 53,33% и 50%
- MLE-Bench Lite: Arbor с GPT-5.5 показал лучший результат среди всех протестированных систем
- Terminal-Bench 2.0: Claude Code показал 75 на dev-данных, но упал до 71 на тестовых. Arbor — 72,22 на dev и 77,36 на тестовых, то есть его результаты реально переносятся в продакшен
Ключевой механизм — «merge gate»: даже если эксперимент выглядит блестящим на обучающих данных, Arbor проверяет результат на отложенной выборке перед тем, как принять изменение. Это защищает от overfitting.
Где Arbor shines — а где нет
Архитектура не бесплатна. Координатор потребляет значительные токены, а параллельные worktree требуют вычислительных ресурсов. По словам соавтора Цзяцзе Цзиня, лучшие сценарии — задачи с чёткой метрикой, долгосрочным горизонтом и несколькими правдоподобными направлениями: оптимизация RAG-pipeline, синтез данных, тюнинг обучения моделей.
А вот для real-time задач, очевидных фиксов на одну строку или при ненадёжных метриках — Arbor не подходит, его потолок качества ограничен качеством evaluators.
Личное мнение
Arbor — это редкий пример того, когда исследование не про «сделаем модель на 2% умнее», а про как заставить существующие инструменты работать правильно. Это именно то направление, которое сейчас определяет разницу между «AI в production» и «AI в демо».
Для разработчиков из России это особенно актуально. Доступ к современным моделям через STIVA — это фундамент. Но следующий уровень — инженерная культура работы с ИИ: структурированные эксперименты, отслеживание гипотез, верификация результатов. Без этого даже самый мощный агент останется игрушкой.
Вывод
Arbor показывает, что будущее ИИ-инженерии — не в более умных одиночных агентах, а в архитектуре, которая превращает хаос проб и ошибок в систематическое исследование. И это доступно уже сегодня — достаточно правильного подхода и правильных инструментов.
