Как выбирать архитектуру ИИ-агента: сначала сильный baseline, затем оркестрация

Спор об архитектуре ИИ-агентов часто начинается слишком поздно — с выбора между одним агентом, командой агентов, деревом поиска и сложным оркестратором. Полезнее начать с другого вопроса: какую часть результата даёт сама модель в подходящей рабочей среде, а какую действительно добавляет внешний процесс? Без такого baseline команда рискует строить дорогую систему для функций, которые сильная модель уже выполняет самостоятельно.

Новое исследование Apple и EPFL делает этот вопрос измеримым для автономной ML-разработки. Его практический смысл шире конкретного рейтинга: архитектуру стоит усложнять после проверки прироста при одинаковых модели, времени и ресурсах. Это не приговор multi-agent системам. Это требование предъявить каждому дополнительному слою собственную пользу.

Что именно показал эксперимент

Авторы сравнили минимальный coding-agent harness Malena с поисковыми и многоагентными вариантами, удерживая одинаковыми backbone, вычислительные ресурсы и временной бюджет. Агент мог читать и менять файлы, запускать код и исправлять ошибки. В контролируемых абляциях доступ к такой среде дал основной прирост, а последующие поисковые и координационные механизмы не показали статистически значимого преимущества над сильным baseline. На 30 задачах MLE-bench и 40 задачах NatureBench Malena, по сообщению авторов, не уступила проверенным внешним harness при frontier-backbone; на меньшей Gemma 4 оценка уже была менее однозначной. Работа ограничена набором ML-задач, частью однорабочими вмешательствами, широкими доверительными интервалами в отдельных сравнениях и возможной разницей в настройке систем. Авторы также отмечают известные дефекты подготовки некоторых MLE-bench задач и отдельно исправляют их. Поэтому результат поддерживает узкий вывод: при сопоставимых условиях сильный coding-agent — обязательный baseline, а не универсальное доказательство бесполезности кооперации.

Baseline должен воспроизводить реальную работу

Минимальный baseline — не одиночный текстовый ответ. Репозиторий OpenCode, на котором строилась экспериментальная среда, описывает полнофункционального build-агента, read-only plan-режим и отдельного общего subagent. Это возможности OpenCode как платформы; наличие subagent в её документации не означает его использование в минимальном варианте Malena. Это важное различие: сильная одиночная сессия уже может иметь инструменты, длительный контекст и внутреннее разделение режимов. Сравнивать её с простым чат-ботом и приписывать весь выигрыш оркестрации было бы неверно.

MLE-bench помогает понять границы такого baseline. Создатели набора собрали 75 соревнований Kaggle, где требуется готовить данные, обучать модели и проводить эксперименты, а результат сопоставляется с человеческими таблицами лидеров. Агент может запускать варианты и оценивать их на собственной локальной валидации. Скрытые тестовые оценки benchmark ему не сообщаются; встроенный сервер проверяет лишь допустимость формата результата. Если основной цикл именно таков, единая сессия сохраняет контекст решений и избегает передачи неполной информации между исполнителями.

Редакционный вывод: первый прототип архитектуры должен включать сильнейшую допустимую модель, реальные инструменты и тот же лимит времени, который получит более сложная система. Только разница с этим вариантом показывает вклад harness.

Почему результаты о поиске могут расходиться

Работа AI Research Agents предлагает другой контекст. Её авторы формализуют ML-агента как поисковую политику над кандидатами и сообщают, что совместный выбор операторов и стратегии поиска — Greedy, MCTS или Evolutionary — существенно влиял на MLE-bench Lite. Лучшая комбинация в их эксперименте подняла долю медалей с 39,6% до 47,7%.

Это не прямое опровержение новой работы: различаются модели, реализации, подмножества задач и условия сравнения. Вместе результаты задают полезный тест. Если модель с инструментами сама устойчиво исследует варианты, жёсткая внешняя стратегия может дублировать её работу. Если она рано застревает, повторяет один подход или плохо сохраняет кандидатов, явная поисковая политика получает понятную функцию.

Поэтому искать нужно не «лучшую архитектуру вообще», а конкретный дефект baseline. Дерево вариантов оправдано измеримым недостатком разнообразия. Отдельный критик — пропущенными ошибками. Параллельные агенты — экономией календарного времени при достаточных вычислительных ресурсах. Память — потерей существенных решений, а не длиной проекта как таковой.

Открыть крупнее

Бюджет важнее числа агентов

Параллельность не создаёт вычисления бесплатно. Несколько агентов могут быстрее проверить независимые гипотезы, но начинают конкурировать за ускорители, контекст, лимиты запросов и внимание человека. Если затем одна система должна выбрать итог по шумной внутренней метрике, больше кандидатов может увеличить разрыв между лучшим найденным и правильно выбранным решением.

Отсюда простой порядок расчёта. Сначала фиксируют общий бюджет: время, вычислители, обращения к модели и стоимость проверки. Затем определяют, какие операции действительно независимы. Наконец, сравнивают качество итогового выбора, а не лучший случай, обнаруженный задним числом. Архитектура, которая породила сильный вариант, но не смогла выбрать его без знания скрытого теста, не решила производственную задачу.

Workflow и независимость решают разные проблемы

Единый агент особенно уместен, когда работа итеративна, инструменты безопасны, обратная связь частая, а промежуточные решения тесно связаны. Оркестратор полезнее, когда процесс содержит обязательные этапы: получение данных, выполнение, проверку, утверждение и сохранение доказательств. Здесь его ценность состоит не в попытке сделать модель умнее, а в гарантированном порядке действий.

Независимый агент нужен ещё по одной причине. Проверяющий, который получил тот же контекст, исходную гипотезу и промежуточные объяснения, легко воспроизводит исходную ошибку. Раздельные роли оправданы там, где цена ошибки требует второго метода, слепой оценки или отдельного допуска. Это относится к безопасности, финансовым операциям, публикации и любым необратимым действиям. Такой контур нельзя оценивать только по среднему баллу benchmark: он уменьшает риск конкретного класса отказов.

NatureBench показывает, почему область задачи меняет вывод. Авторы этого benchmark собрали 90 задач из статей семейства Nature и стандартизировали окружение через NatureGym. По их данным, сильнейшая конфигурация превзошла опубликованный уровень лишь на 17,8% задач; основные неудачи связывались с неверным выбором метода и недостаточным вычислительным бюджетом. NatureBench тоже предоставляет автоматическую обратную связь во время работы. Подготовленные данные и вычислимая оценка охватывают лишь часть научного процесса: результат на таком наборе нельзя переносить на самостоятельный выбор научного вопроса или проведение реального эксперимента.

Открыть крупнее

Четыре вопроса перед усложнением

Редакционный анализ сводит выбор к четырём проверкам. Во-первых, достигает ли сильный одиночный агент приемлемого результата с настоящими инструментами? Во-вторых, какой наблюдаемый отказ должен исправить новый компонент? В-третьих, сохраняется ли преимущество при общем, а не поглощённом несколькими агентами бюджете? В-четвёртых, нужны ли обязательный workflow, разграничение доступа или независимая проверка независимо от прироста среднего качества?

Если baseline слаб из-за модели или бедной среды, оркестрация маскирует первопричину. Если задача естественно распадается, проверка независима, а параллельные ветви обеспечены ресурсами, multi-agent архитектура может быть рациональной. Если система совершает чувствительные действия, контроль и разделение полномочий становятся требованиями продукта.

Минимальный harness полезен как точка отсчёта, а не как идеология. Сильный backbone определяет доступный уровень работы; бюджет ограничивает число попыток; структура задачи определяет workflow; безопасность и цена ошибки — степень независимости. Архитектуру следует расширять там, где каждый новый слой устраняет измеренный риск или ограничение.