Пользовательские агенты и команда агентов: Делегируйте, не теряя контроля

Последняя проверка и обновление: 25 августа 2026 года

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

Один Команда агентов это система выполнения одной сложной цели. MiniMax сообщает, что она координирует разложение задачи, выполнение специалистами, отслеживание прогресса, проверку и финальный синтез. Его инженерная статья описывает Лидер → Работник → Проверяющий цикл: Лидер организует работу, Работники создают ограниченные результаты, а Проверяющий решает, соответствует ли доказательство критериям принятия.

A 19 марта 2026 г., пост X от Jace J обобщил обращение как отдельные роли для написания, проверки и тестирования. Это полезная модель мышления для сообщества, но публикация носит рекламный характер и не доказывает, что большее количество агентов улучшает каждую задачу. Упражнение ниже проверяет идею с ограниченными ролями и внешними доказательствами.

Это не синонимы:

Инструмент	Многоразовый объект	Лучшее для	Основной риск
Память	Стабильное предпочтение или урок	Повторное использование контекста	Устаревший или слишком общий контекст
Навык	Повторяемая процедура	Последовательное выполнение одной задачи	Пересекающиеся триггеры или жесткие инструкции
Пользовательский агент	Постоянный владелец с ролью, рабочей средой, инструкциями и возможностями	Регулярная ответственность специалиста	Неопределенное или перекрывающееся владение
Команда агентов	Скоординированный запуск с разложением на части и проверкой	Сложная параллельная доставка	Затраты, дрейф передачи, дублирование работы и бесконтрольные повторные попытки

К концу этого урока вы разработаете один Practice Verifier План агента и команды из двух работников с независимым финальным этапом.

Когда один агент является лучшим вариантом дизайна

Оставайтесь в одиночку, когда задача:

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

Используйте команду агентов, когда работа имеет независимые единицы и одну точку интеграции — например:

• исследовать несколько потоков доказательств параллельно, а затем синтезировать;
• внедрять изменение, пока другой работник готовит независимый тест или проверку совместимости;
• писать длинный документ через стадии содержания, формата и оценки;
• объединяйте код, документацию и визуальное QA с отдельными проверками на соответствие.

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

Пошаговый сценарий: сначала Агент, потом команда

Сначала разработайте одного индивидуального Агента

Наша повторяющаяся роль — это в основном проверяющий для одноразового рабочего пространства практики.

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

Отображаемое имя: Проверяющий Практики

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

Инструкции:
- Отчеты о собственной проверке для рабочего пространства minimax-code-practice.
- Проверяйте перед тем, как предлагать какие-либо действия.
- Различайте проверенные, только сообщенные и не запущенные.
- Не редактируйте, не коммитьте, не отправляйте, не развертывайте, не публикуйте, не отправляйте, не удаляйте и не устанавливайте.
- Отклоняйте изменения файлов вне области.
- Завершайте с отметкой Pass, Fail или Blocked и предоставляйте доказательства для этого вердикта.

Рабочее пространство по умолчанию:
[выберите только временную папку minimax-code-practice]

Каналы связи:
Нет для этого упражнения.

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

Если вы явно попросите MiniMax Code создать Агента на диске, проверенный create-agent способность добавляет дополнительные меры предосторожности: требует предварительного одобрения, использует имя ответственности в kebab-case, проверяет запуск Агента и предотвращает перекрытие ответственности. Создание Агента отличается от создания способности; Агент может выполнять способности, но роль отвечает за результат.

Быстрый тест на работоспособность пользовательского Агента

Задача верификации только для чтения.

Требование
README.md должен содержать заголовок "MiniMax Code Practice" и строку состояния.

Область
Только текущая рабочая область практики и README.md.

Проверки
Проверьте текущий файл и видимые измененные пути. Не выполняйте команды и не редактируйте.

Вердикт
Верните Pass, Fail или Blocked. Произведите цитирование наблюдаемого заголовка и строки состояния и укажите
существует ли какой-либо измененный путь вне области.

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

Спроектируйте команду агентов, которая может реально работать параллельно.

Сценарий: подготовьте записку о готовности к выпуску для небольшого изменения на демонстрационном сайте. Работа имеет два независимых потока доказательств:

1. Аудит изменений: сравните запрашиваемый результат с изменёнными путями и различиями.
2. Аудит верификации: исследуйте доступные доказательства тестирования/сборки/предварительного просмотра и различайте, что было выполнено, а что нет.

Лидер может одновременно распределить этих двух работников только для чтения, а затем попросить Practice Verifier проверить интегрированную записку. Ни один работник не редактирует файлы. Это делает первое командное упражнение безопасным и делает невозможными конфликты слияния.

Контракт команды

Роль	Owns	Возвраты	Не должен делать
Лидер	Цель, распределение задач, статус, правила остановки, интеграция	Примечание о готовности к релизу	Скрывать разногласия или расширять область
Работник аудита изменений	Требование, изменённые пути, различия	Таблица изменений в рамках области	Редактировать, тестировать или делать вывод о готовности в реальном времени
Работник по сбору доказательств	Существующий вывод команд и предварительные доказательства	Таблица проверенных / только отчётных / не запущенных	Запускать неподтверждённые команды или рассматривать утверждения как доказательства
Практический верификатор	Ворота приёмки на интегрированном примечании	Пройти, не пройти или заблокировано с указанием причин	Одобрять собственные неподдержанные выводы или переписывать исходные доказательства

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

Копируемая подсказка команды агентов

Используйте команду агентов для аудита готовности к выпуску в режиме только для чтения текущей временной рабочей области
практики.

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

Вводы
- Требование в этом сообщении
- Текущие измененные пути и различия
- Существующий вывод тестов/сборки в задаче
- Существующее наблюдение в Markdown или предварительном просмотре в браузере

План и роли
Используйте одного лидера. Запускайте не более двух работников одновременно:
1. Работник аудита изменений: требование против путей/различий.
2. Работник доказательств: фактические проверки против заявлений.
После синтеза используйте Проверяющего Практику в качестве независимого финального этапа.

Ограничения и утверждения
Только для чтения. Не редактируйте, не устанавливайте, не запускайте новую команду, не открывайте соседнее рабочее пространство,
не выполняйте commit, push, deploy, publish, send, delete, или не меняйте учетную запись. Не создавайте
больше Агентов. Доказательства текущего рабочего пространства превосходят старые заявления из диалога.

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

Бюджеты и правила остановки
- Максимальное количество одновременных работников: 2.
- Максимальное количество циклов исправлений после проверки: 1.
- Остановитесь и спросите меня, если рабочее пространство неверное, необходимые доказательства недоступны,
  разрешения не действуют, вмешиваются лимиты использования, или Рабочим нужен один и тот же изменяемый файл.

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

Контролируйте выполнение

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

Следите за пятью вещами:

1. План: Действительно ли задачи Рабочих независимы?
2. Статус: Рабочий производит, проверяет, завершил или застрял?
3. Артефакты: Каждый переданный элемент указывает файл, таблицу или краткий результат?
4. Разногласия: Сохранил ли Руководитель конфликт или тихо его сгладил?
5. Условие остановки: Достигла ли команда предела ревизии, разрешения, использования или времени?

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

Почему проверяющий и рецензент не являются магическими щитами

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

• тесты и команды для исполняемого поведения;
• стабильные первоисточники для исследовательских утверждений;
• сгенерированные файлы для макета;
• явные проверки пути и разрешений для локальных изменений;
• человеческая подпись для действий с высоким риском или необратимых действий.

Инженерная статья MiniMax также называет три типа затрат на сотрудничество:

• затраты на передачу: подготовка полезного контекста для следующего Агента;
• затраты на обмен: многократное подвергание каждого Агента ненужному контексту;
• затраты на агрегацию: объединение нескольких результатов в один согласованный продукт.

Большее количество агентов не является настройкой качества. Ценность создают структура и проверка.

Граница безопасности

• Рабочее пространство по умолчанию предоставляет контекст; не рассматривайте его как гарантированную границу изоляции.
• Не связывайте канал сообщений, не создавайте аккаунт, не предоставляйте OAuth-доступ и не делитесь личными данными только для выполнения этого упражнения.
• Держите публикацию, отправку, покупку, передачу, удаление, изменение производства, использование учетных данных и изменения учетной записи/разрешений под точным текущим подтверждением.
• Дайте Работникам отдельные артефакты только для чтения или непересекаящиеся пути. Не позволяйте нескольким Работникам одновременно редактировать один и тот же файл.
• Установите ограничения на параллельность, повторные попытки и использование перед запуском. Ошибка ограничения использования является сигналом остановки, а не разрешением на создание замещающих Работников.
• Сохраняйте одного ответственного Лидера и одного человека в качестве окончательного владельца. «Проверка пройдена» не передает ответственность.

Публичные отчеты: сигналы, а не распространенность

Официальный репозиторий MiniMax Code содержит отдельные отчеты о команде Агентов, задерживающейся во время глубокого исследования, параллельных повторных попытках после ограничения использования, и повреждении хранилища разрешений во время параллельной работы. Эти отчеты не устанавливают частоту и не доказывают, что текущие сборки v3.0.67 воспроизводят поведение. Они полезны как тесты сценариев для ваших правил эксплуатации: ограничивать разветвление, останавливаться на границах использования, изолировать записи, сохранять статус и вмешиваться, вместо того чтобы запускать больше повторных попыток.

Устранение неполадок

Симптом	Вероятная причина	Восстановление
Два Рабочих выполняют одно и то же задание	Задачи не являются независимыми или роли перекрываются	Объедините роли или перепишите границы ввода/вывода каждого Рабочего
Команда работает медленнее, чем один Агент	Стоимость передачи и агрегирования превышает выгоду от параллельной работы	Остановите команду и вернитесь к одному Агенту с контрольным списком
Рабочий застревает без артефакта	Цель или необходимый ввод неоднозначны, или инструмент/разрешение заблокировано	Спросите у Руководителя точный блокировщик; предоставьте доказательства один раз или остановите Рабочего
Циклы проверки повторяются	Критерии приёмки расплывчаты или один и тот же дефект исправляется без новых доказательств	Ограничьте пересмотры, определите неудачную проверку и эскалируйте к ответственному человеку
Ограничение использования вызывает запуск дополнительных Рабочих	Политика повторных попыток рассматривает сбой ёмкости как неудачу задачи	Остановите разветвление; ждите разрешения или уменьшите объём после указаний пользователя
Параллельная работа вызывает ошибки разрешений	Рабочие используют общую изменяемую среду выполнения, хранилище разрешений или путь	Остановите команду, сохраните логи, проверьте состояние и продолжите с изолированными/только для чтения ролями
Для нерелевантной работы выбран индивидуальный Агент	Его описание или сфера деятельности перекрывается с другим Агентом	Перепишите описание вокруг одной ответственности и явных исключений

FAQ

Является ли пользовательский Агент тем же, что подагент или Работник?

Нет. Пользовательский Агент — это долговечная настроенная роль. Работник — это роль внутри конкретного выполнения команды и может выбираться динамически.

Должен ли каждый пользовательский Агент присоединяться к каждой Команде Агентов?

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

Могу ли я начать с программной команды из пяти Агентов?

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

Нужны ли Проверяющему разные инструменты?

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

Что мне делать, когда команда работает, а у меня есть новая информация?

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

Официальные источники

• Пользовательские агенты
• Команда агентов
• Технический блог по инженерии агента MiniMax
• Разрешения и безопасность
• Задачи и история

Что вы можете делать сейчас

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