Представь: в компании не один умный чатик, а целая толпа ИИ-агентов. Один закупает, второй считает цены, третий общается с клиентами, четвёртый следит за логистикой. И все они должны дружить.
По факту получается офисный сериал. Каждый тянет одеяло на себя и тихо мешает соседу — потому что так в KPI. Два алгоритма ценообразования устраивают гонку «кто быстрее уронит цену», и бизнес в итоге выигрывает примерно ничего.
Команда Google разобралась, почему это происходит — и предложила неожиданно простой выход.
Почему жёсткие правила не спасают
Обычно разработчики решают проблему в лоб: прописывают схему координации. Если агент А сказал одно — запускаем агента Б. Если случилось то — переходим сюда. Выглядит надёжно.
Как инструкция к микроволновке: шаг влево — и суп взорвался.
Чем больше агентов и неожиданных ситуаций, тем быстрее такие схемы упираются в потолок. Один непредвиденный кейс — и начинается бесконечное «добавим ещё одно правило». В маленьких системах это работает. В большом зоопарке агентов — трещит по швам.
Что предложил Google
Вместо того чтобы прописывать как агентам дружить, исследователи предложили другое: тренировать агента в среде, где вокруг него постоянно разные и непредсказуемые партнёры.
Смысл простой. Агент привыкает, что мир не стационарный. Сегодня сосед ведёт себя так, завтра иначе. Поэтому агент начинает читать ситуацию по ходу дела — и выбирать стратегию, которая приводит к сотрудничеству, а не к вечной войне.
Проверяли это на классической задаче из теории игр — многократной версии «Дилеммы заключённого». Это когда двум игрокам выгоднее сотрудничать, но у каждого есть соблазн предать. Агент научился устойчиво выбирать сотрудничество — даже когда не знал ничего о сопернике и приходилось адаптироваться пробами и ошибками.
Что это меняет на практике
Сейчас при создании систем из нескольких ИИ-агентов разработчик обычно заранее рисует схему: кто кому передаёт задачу, какие переходы возможны, кто главный. Это похоже на очень умную таблицу «если-то».
Подход Google — наоборот. Меньше вручную прописанной координации, больше поведения, которое появляется из самого обучения. Ты не пишешь «агент А уступает агенту Б в таком-то случае». Ты создаёшь условия, где договариваться выгоднее, чем бодаться.
Роль разработчика при этом сдвигается. Не дирижёр, который управляет каждым музыкантом отдельно — а человек, который настраивает репетиции так, чтобы оркестр начал звучать сам.
Это звучит как мечта любого, кто хоть раз поддерживал систему из сотни простых правил и боялся тронуть одно — вдруг упадёт всё.
Вместо хрупкого замка из скриптов — стая, которая хотя бы иногда вспоминает, что она стая, а не коробка с пауками.