Когда у AI-агента несколько пользователей
почему модели ломаются в мире конфликтующих ролей, целей и доступов

Когда у агента больше одного хозяина

Мы привыкли думать о больших языковых моделях как о личных помощниках: дал задачу — получил ответ. Но реальный мир устроен иначе. В компании ассистенту пишет не один пользователь, а сразу несколько: менеджер, инженер, HR, финансист. У каждого — свои цели, свой уровень доступа, свои интересы и, что особенно неприятно, свои конфликты. И вот тут выясняется, что большинство LLM по-прежнему живут в очень упрощённой вселенной, где есть один главный человек и одна правильная цель.

Статья Multi-User Large Language Model Agents — редкий и очень своевременный взгляд на проблему, о которой индустрия пока говорит слишком мало: что происходит, когда один AI-агент должен обслуживать сразу нескольких людей. Авторы из Stanford, MIT, KAUST и University of Toronto предлагают не очередной “агентный” демо-сценарий, а систематический стресс-тест для таких ситуаций. И результаты, прямо скажем, отрезвляют: даже сильные модели заметно сыплются, когда нужно не просто “быть полезными”, а разруливать конфликты, не сливать приватные данные и координировать группу в несколько ходов.

Почему это важно прямо сейчас

До недавнего времени слабости моделей в многопользовательской среде можно было считать академической экзотикой. Но это уже не так. LLM все чаще встраивают в корпоративные чаты, почтовые помощники, системы планирования встреч, CRM, внутренние базы знаний и инструменты для совместной работы. То есть в среду, где “пользователь” — это не один человек, а целая организация.

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

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

Главная идея статьи

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

Задача агента — не просто ответить “умно”, а выбрать действие, которое учитывает все эти факторы. На практике это означает три очень приземлённые способности:

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

Как тестировали модели

Вместо абстрактных рассуждений исследователи собрали набор сценариев с симулированными пользователями: от интернов до директоров, с разными характерами, стилями работы и отношением к безопасности. В экспериментах участвовали как закрытые передовые-модели, так и открытые системы: Claude, GPT, Gemini, Grok, Qwen, Llama, DeepSeek и другие.

Три ключевые задачи такие:

1. Следование инструкций в многопользовательском режиме

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

2. Контроль доступа между всеми пользователями

Агент должен защищать чувствительную информацию и не выдавать её тем, у кого нет прав доступа, даже если запрос звучит убедительно или давит на срочность.

3. Управление встречами

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

Метрики тоже выбраны здраво: точность выбора и исполнения инструкций, privacy vs utility в доступе к данным, success rate и число ходов для координации.

Что идет не так

Главный вывод статьи: LLM неплохо справляются с отдельными элементами многопользовательских задач, но ломаются на их комбинации. Особенно когда в игру вступают конфликт интересов, многоходовое взаимодействие и частично скрытая информация.

В сводной таблице лучше всех выглядит Gemini-3-Pro: он показывает лучший средний результат по всему бенчмарку. Сильны также Claude-Sonnet-4.5, Gemini-3-Flash и GPT-5.1. Но даже лидеры далеки от решения проблемы.

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

Конфликт между пользователями — ахиллесова пята

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

Это особенно важный сигнал для корпоративных внедрений. На практике AI-ассистент почти никогда не живет в стерильной среде, где все участники согласны друг с другом. Конфликт — это норма. А значит, модель должна не просто продолжать текст, а устойчиво удерживать иерархию полномочий, общую цель и правила отказа.

Авторы интерпретируют это так: современные модели не по-настоящему усвоили authority-aware reasoning. Они часто опираются на поверхностные подсказки в тексте и теряются, когда требуется принципиальный арбитраж.

Приватность держится недолго

Вторая сильная часть статьи — анализ приватности в многоходовых диалогах. Здесь картина даже тревожнее. На первых ходах многие модели показывают достойные privacy score: не выдают секреты тем, кому не положено. Но по мере продолжения разговора защита начинает “размываться”.

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

Отсюда важный практический вывод: тесты на приватность в один ход сильно недооценивают риск. Для реальных систем критичны именно длинные взаимодействия, где пользователь постепенно давит, манипулирует контекстом и использует social engineering.

Координация — это не только умение рассуждать

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

Вottleneck не столько в абстрактной способности “думать”, сколько в умении вести процесс координации. Хороший многопользовательский агент должен быть немного менеджером проекта: отслеживать, кто уже ответил, где есть пробелы, какие ограничения жёсткие, а какие можно согласовать. Многие модели вместо этого либо слишком долго топчутся на месте, либо, наоборот, преждевременно объявляют консенсус там, где его нет.

Авторы отдельно показывают и масштабный эффект: по мере роста числа участников успешность координации падает, а число требуемых ходов растёт примерно линейно. То есть проблема не исчезнет сама собой с “чуть более длинным контекстом” — здесь упираемся в фундаментальную сложность многопользовательского взаимодействия.

Что статья говорит о текущей архитектуре LLM

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

Если модель обучали на парах “один запрос — один хороший ответ”, а preference optimization сжимал всё в один скалярный reward, то откуда у неё возьмётся внутренняя механика для честного баланса между несколькими людьми с разными правами и интересами? По сути, сегодняшние LLM пытаются решать многопользовательскую задачу инструментами, созданными для одного юзера.

Это объясняет, почему даже сильные модели показывают странные компромиссы:

Что делать дальше

Авторы довольно чётко очерчивают направления, без которых многопользовательские LLM останутся в таком состоянии:

Итог

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

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

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