Обычный coding agent делает одно и то же: запускает эксперимент, смотрит результат, забывает выводы и повторяет ошибки. Исследователи из Renmin University of China и Microsoft Research построили фреймворк, который вместо хаотичного перебора собирает дерево гипотез. В тестах Arbor показал в 2,5 раза больше verifiable performance gains, чем Claude Code и Codex, при том же бюджете вычислений.

Проблема современных AI-агентов для разработки не в том, что они не могут писать код. Они могут, и очень хорошо. Проблема в том, что они не умеют учиться на своих ошибках в долгой перспективе. Представьте: вы дали агенту задачу оптимизировать RAG-пайплайн для внутреннего AI-ассистента. Он меняет чанкинг, промпт, метод поиска - всё в одном заходе. Что сработало? Неизвестно. Потому что правки переплетены, а память агента - просто лог чата, который быстро переполняется.

Arbor решает эту проблему архитектурно. Вместо плоского потока попыток он строит дерево. Каждая гипотеза - отдельная ветка. Каждый эксперимент - изолированный git worktree. Координатор (долгоживущий AI-агент) никогда не трогает код сам - он ставит задачи исполнителям и собирает результаты. А исполнители (короткоживущие агенты) работают каждый в своей песочнице.

«Автоматизация может заставить AI работать очень долго - но цикл - это не прогресс. Если цель размыта или метрику легко хакнуть, долгая автоматизация просто производит «улучшения» быстрее, которые никому не нужны»

- Цзяцзе Цзинь, соавтор исследования Arbor

Как работает Hypothesis Tree Refinement

Ключевая инновация Arbor - механизм HTR (Hypothesis Tree Refinement). Это не просто база знаний - это структура, где каждый узел связывает четыре элемента: гипотезу, исполняемый артефакт, фактические доказательства и дистиллированное инсайт. Широкие идеи остаются у корня, конкретные уточнения - на листьях. Когда эксперимент проваливается, дерево записывает причину как отрицательное ограничение, чтобы система не повторяла ту же ошибку бесконечно.

Допустим, вы оптимизируете RAG-пайплайн. Чанкинг - одна ветка, метод поиска - другая, промпт - третья. Каждая ветка реализуется и оценивается в своём изолированном git worktree. Результат - чистая атрибуция: «декомпозиция ограничений на стороне поиска дала +X; BFS-поиск навредил».

Цифры Arbor в тестах

  • 2,5x - средний относительный прирост verifiable performance против Claude Code и Codex
  • BrowseComp: точность выросла с 45,33% до 67,67% (Codex и Claude Code застряли на 50% и 53,33%)
  • Terminal-Bench 2.0: Arbor набрал 77,36 на тестовых данных против 71 у Claude Code (Claude Code показал 75 на dev, но упал на тесте - переобучился)

Ещё один важный механизм - «merge gate». Даже если исполнитель сообщает фантастический результат на разработке, координатор запускает изолированный worktree, чтобы проверить кандидата на отложенной тестовой выборке. Артефакт попадает в основной код только если он реально улучшает тестовые метрики. Это предотвращает reward hacking - проблему, от которой страдают многие AI-системы оптимизации.

Arbor не требует замены существующей инфраструктуры. Он садится поверх Git-воркфлоу. Его выход - обычная git-ветка, которую можно просмотреть в code review и CI. Только проверенные улучшения попадают в основную ветку; репозиторий остаётся нетронутым, пока разработчик вручную не решит продвинуть изменения.

Где Arbor пригодится, а где - нет

По словам Цзиня, Arbor лучше всего работает на задачах с чёткой метрикой, долгим горизонтом планирования и настоящим пространством поиска. Идеальные сценарии: оптимизация пайплайнов, качество синтеза данных, настройка рецептов обучения моделей.

Не стоит использовать Arbor для задач реального времени, очевидных исправлений в одну строку или когда метрика оценки ненадёжна. «Если метрике нельзя доверять, Arbor просто оптимизирует к ненадёжному результату быстрее», - говорит Цзинь.

Главный практический недостаток - стоимость токенов. Долгоживущий координатор, который постоянно управляет деревом и рассылает исполнителей, - это доминирующий расход. Несколько изолированных worktree одновременно требуют настоящих вычислительных и дисковых ресурсов.

Следующая версия Arbor, по словам исследователей, будет использовать не скалярную метрику, а вектор - accuracy, latency, cost. Переход от одной шкалы к многокритериальному поиску Парето - естественное расширение фреймворка.

Что это значит для бизнеса

Arbor - это не просто очередной инструмент для разработчиков. Это пример того, как AI-агенты перестают быть «чёрными ящиками», которые выдают непредсказуемый результат, и становятся системами с прозрачной логикой принятия решений.

Для компаний во Владивостоке и на Дальнем Востоке, которые задумываются об автоматизации с помощью ИИ, Arbor показывает важный принцип: AI-агент эффективен ровно настолько, насколько хорошо он запоминает свои ошибки. Без структурированной памяти - той самой, которую Arbor строит в виде дерева гипотез - агент обречён повторять одно и то же. Это знание напрямую переносится на выбор AI-инструментов для бизнеса.

Если ваша команда использует coding agents для поддержки кодовой базы или оптимизации пайплайнов, стоит присмотреться к подходам Arbor: изолированные эксперименты, чёткая атрибуция, merge gate от переобучения. Эти принципы работают не только в research - они уже завтра появятся в коммерческих инструментах для разработки.

Open source ии - это именно то, что делает Arbor особенно интересным. Фреймворк построен на открытых принципах и доступен для интеграции. Для бизнеса это означает, что технологию можно тестировать и адаптировать без вендор-лока.