Как мультиагентные системы учатся на собственном опыте

Разбор лекции Всеволода Воропаева от 25 сентября 2026 года из библиотеки стримов Guide DAO.

Мультиагентную систему обычно проектируют заранее: выбирают модели, распределяют роли, пишут инструкции. Но если агенты умеют анализировать ошибки, писать код и ставить эксперименты, часть работы по улучшению системы можно отдать им самим. Всеволод Воропаев работал в AI-лабораториях, в том числе в исследовательской лаборатории, которую поддержала OpenAI, а сейчас строит мультиагентные системы для технических и научных компаний. В лекции он разбирает, как команда агентов накапливает опыт и перестраивает свою работу и почему центральным вопросом здесь становится качество обратной связи.

Допустим, команда агентов за месяц выполнила 500 задач, а в крупной компании их бывают десятки тысяч. Где-то нашлись удачные решения, где-то пришлось менять подход, и хочется, чтобы следующий месяц система начала с этим опытом. На таком ожидании держится идея самоулучшения, или self-improvement. Крупные компании и лаборатории хотят первыми добиться его в большом масштабе, а обычной компании нужна приземлённая версия: агенты запоминают нужное, не повторяют ошибок и находят понятный путь к правильному ответу.

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

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

Возьмём систему, которая готовит исследование. Один агент собирает материалы, второй делает выводы, третий проверяет результат. Проверяющий регулярно замечает нехватку важных данных слишком поздно, когда большая часть работы готова и приходится возвращаться назад. Разработчик подключил бы проверку раньше, пока выбираются источники и формулируется вопрос. Но этот разбор можно поручить самим агентам. Они изучат историю запусков, предложат изменение и проверят, помогло ли оно на следующих задачах.

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

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

Можно пойти иначе и дать агентам долго работать над одной проблемой, чтобы знания о ней копились. В проекте Coral несколько программирующих агентов исследуют разные варианты решения и обмениваются результатами через общую память. Туда попадают попытки, заметки и приёмы для повторного использования с оценкой того, что сработало. Один агент может продолжить направление, начатое другим, или взять его наблюдение в свой эксперимент. Авторы Coral проверяли подход на математических, алгоритмических и оптимизационных задачах и смотрели, насколько накопленный опыт помогает команде на задачах, которых она раньше не видела.

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

При этом запись «этот подход не помог» оставляет слишком много вопросов. В память нужно класть, что проверяли, в каких условиях и какой получили результат, иначе агенты наследуют чужие выводы и не могут оценить, применимы ли они к новой задаче. Всеволод сравнивает такую память с библиотекой эвристик. Участники меняются, диалоги заканчиваются, а опыт команды живёт дольше любого запуска.

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

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

Иначе можно посмотреть и на специализацию. Обычно её прописывают инструкцией вроде «ты исследователь» или «ты верификатор», но различия могут возникать и из опыта. Один участник чаще решает определённый класс задач и копит приёмы для него, другой исследует соседнее направление.

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

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

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

Поэтому накопленный опыт всё равно приходится сверять с реальной работой, ради которой систему создавали.

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

В системе, которая улучшает сама себя, ошибка оценки повторяется и накапливается. От неё зависит, какие решения сохранятся и какие инструкции изменятся, а значит, и то, какими станут следующие версии. Надёжность проверок определяет, куда будет развиваться вся система.

Напрашивается решение поставить в цикл человека. Но июньские работы Microsoft Research показывают, что само по себе это проблему не решает. Человек тоже меняется, работая с AI. Если он всё чаще полагается на готовые ответы, его способность самостоятельно оценивать результат в некоторых условиях может снижаться. Тогда и качество человеческого фидбека становится переменной, за которой приходится следить.

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

Каждый эксперимент требует ресурсов. Иногда удачное изменение находится быстро, иногда система перебирает сотни, тысячи или десятки тысяч вариантов без заметного результата. Поэтому стоит учитывать, сколько будущих задач воспользуется улучшением. Дорогой поиск окупается, если результат применят много раз.

По словам Всеволода, это больное место циклов автоматического исследования вроде autoresearch Андрея Карпаты, где агент ставит эксперимент за экспериментом и оставляет изменения, улучшившие метрику. Там радуются любому улучшению и не задумываются, насколько оно мелкое и как скажется на итоговом результате. Такие циклы могут поднять результат на 10–20%, но он считает их слишком общим и далеко не самым умным подходом. Переносите их в свой проект с поправкой на свой круг задач и считайте, сколько вычислений съело улучшение, найденное за 10 тысяч итераций.

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

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

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

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

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

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