Мультиагентная система: маршруты и права важнее числа персонажей

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

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

Начните с карты входов

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

Затем назначьте владельца процесса. Продажи, поддержка и техника могут работать с одним клиентом, но должны иметь разные критерии завершения. Нельзя использовать тему сообщения как единственный маршрутизатор: слово «оплата» встречается и в вопросе покупателя, и в бухгалтерской задаче, и в инциденте.

Запишите приоритет правил

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

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

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

Разделите роль и полномочия

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

Составьте матрицу «агент × инструмент × операция». Разделяйте чтение, подготовку черновика и выполнение. Поддержке может быть разрешено читать заказ и создать заявку; продажам — читать каталог и создать черновик предложения; технику — читать статус и запустить безопасную диагностику. Изменение денег, прав доступа или внешняя публикация требуют отдельного решения и часто одобрения человеком.

Привяжите учётные данные к контексту

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

Минимизируйте область токена и срок жизни. Секрет хранится в vault и не должен попадать в промпт. Проверяйте не только успешный вызов, но и отрицательные сценарии: агент продаж не видит технический аккаунт, пользователь одной группы не наследует доступ другой, а отсутствие привязки не приводит к выбору «первого доступного» секрета.

Добавьте гейты и эскалацию

Маршрут к агенту не завершает принятие решения. Перед побочным эффектом могут быть нужны лимит, стабильный ключ и approve/reject. Человеку показывают сумму, получателя, причину и последствия, а не абстрактное «разрешить действие».

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

Наблюдайте объяснение маршрута

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

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

Тестовая сетка

Проверьте минимум такие случаи:

• собеседник с явной привязкой;
• новая группа без правила;
• конфликт peer и group;
• явное упоминание другого агента;
• пользователь без доступа;
• правило mute;
• отсутствующая учётная запись;
• инструмент только для чтения;
• опасное действие с одобрением;
• отказ внешней интеграции;
• повтор после рестарта;
• передача человеку и возврат управления.

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

План внедрения

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

Не выдавайте всем агентам общий широкий ключ «на первое время». Временные полномочия имеют свойство становиться постоянными. Лучше начать с чтения и черновиков, а выполнение открывать по доказанному сценарию.

Учтите модель угроз маршрутизации

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

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

Источники и ограничения

Официальные материалы: «Агенты и персоны», «Роутинг», «RBAC и scoped API-ключи» и «Гейты одобрения». Доступность RBAC, обязательных одобрений, расширенного аудита, каналов и интеграций зависит от тарифа и конфигурации. Подключённый канал не означает, что любой отправитель автоматически разрешён.

Начните с вопроса «какой негативный тест должен остановить агента». Ответ обычно точнее показывает архитектуру команды, чем список желаемых ролей.