OpenClaw агенты позволяют разделить задачи между несколькими ролями с собственными рабочими пространствами и правилами доступа к инструментам. Например, одна роль ищет сведения в разрешённых материалах, другая готовит черновик ответа, а человек решает вопрос отправки. Польза возникает, когда маршрут входящего запроса, границы файлов и порядок подтверждения заданы явно.
Разные роли
По документации OpenClaw, несколько агентов могут работать в одном Gateway, причём у каждого есть собственное рабочее пространство, каталог состояния и история сеансов. Привязки направляют входящие сообщения к выбранному агенту.
Начните с границы между задачами, а затем подбирайте роли. Для внутреннего запроса о правилах компании полезна роль исследователя: она ищет источники и указывает, где нашла ответ. Редактор получает проверенные фрагменты и готовит черновик. Ответственный сотрудник сверяет факты и принимает решение о публикации или отправке. Эту последовательность предлагаем как схему будущей проверки.
Разделение имеет смысл там, где у ролей разные данные или действия. Если оба помощника читают одни файлы, видят одинаковые сеансы и обладают общим правом отправки, названия ролей мало что меняют. Для каждой роли запишите вход, ожидаемый результат и запретные действия понятными глаголами. Исследователь возвращает цитату с источником. Редактор возвращает черновик с отмеченными вопросами. Внешний ответ готовится только после решения владельца процесса.
- Назначьте владельца каждого входящего потока, чтобы сообщение попадало в предсказуемую роль.
- Определите артефакт работы: найденные источники, черновик или список спорных утверждений.
- Отдельно перечислите операции с файлами, командами и внешними каналами для каждой роли.
Общую логику приёмки агентной работы раскрывает статья о тестировании ИИ-агентов. Здесь акцент на конфигурации нескольких ролей OpenClaw и проверке того, что запрос дошёл до правильного адресата.
Границы пространства
Укажите каждой роли своё рабочее пространство и каталог состояния. В рабочем пространстве лежат инструкции роли и её материалы; отдельный каталог хранит состояние агента и сеансы, согласно документации OpenClaw. В инструкции исследователя опишите допустимые источники и формат ссылок. В инструкции редактора задайте правило: готовить черновик по переданным выдержкам и отмечать пробелы в фактах. Секреты и клиентские документы держите вне материалов, доступных лишним ролям.
Отдельная папка удобна для организации, но техническую изоляцию задают дополнительные ограничения. Документация OpenClaw описывает песочницу, доступ к рабочему пространству и списки разрешённых инструментов. Проверьте реальные права на файловой системе и видимость сеансов. В настройках сеансов OpenClaw видимость по умолчанию охватывает всех агентов, а обмен между агентами включён. Для разделения явно сузьте tools.sessions.visibility и ограничьте tools.agentToAgent по утверждённому маршруту; затем проверьте доступ тестом. Несколько ролей в одном Gateway подходят для доверенной команды с общим администрированием. Для групп с разными уровнями доверия используйте отдельные Gateway: документация описывает это как более строгую границу.
| Роль | Материалы | Инструменты | Проверка |
|---|---|---|---|
| Исследователь | Утверждённые источники и заметки | Чтение разрешено | Открыть приведённые ссылки |
| Редактор | Выдержки и черновики | Запись в рабочий черновик | Сверить текст с источниками |
| Ответственный | Черновик и правила публикации | Подтверждение через сервер процесса | Зафиксировать решение человека |
Для роли с чтением задайте ограниченный доступ к файловой системе и запретите инструменты записи, командной строки и отправки сообщений, если задача их исключает. Затем проверьте права тестовым запросом. Подход к секретам и серверным границам подробнее разобран в материале о безопасности ИИ-агентов. Инструкция роли поясняет поведение модели; доступ к данным и подтверждение действий обеспечивает технический контур.
Маршрут запроса
В OpenClaw привязка, или binding, выбирает агента по признакам входящего сообщения: каналу, учётной записи или конкретному разговору. По официальному описанию привязок, этот механизм работает после обычных правил допуска канала. Допуск к каналу проверяют его отдельные правила. Для пилота можно выбрать уже разрешённый тестовый источник сообщений и назначить ему исследователя; остальные потоки оставьте под контролем прежнего маршрута.
- Запишите, откуда приходит тестовый запрос, кто вправе его отправить и какую роль должен увидеть отправитель.
- Создайте отдельные идентификаторы ролей и рабочие пространства в проектной схеме конфигурации.
- Опишите узкую привязку к тестовому разговору и проверьте приоритет относительно общего правила канала.
- Отправьте разрешённое тестовое сообщение без личных данных и сверьте выбранного агента с ожидаемым маршрутом.
- Повторите проверку на соседнем разговоре и убедитесь, что общий поток сохранил своего владельца.
При нескольких привязках узкое правило должно соответствовать конкретному разговору, а широкое правило охватывает остаток потока. Документация объясняет порядок сопоставления по специфичности и порядок правил внутри одного уровня. После изменения конфигурации проверьте список агентов и привязок доступными средствами OpenClaw. Результат зафиксируйте как пару «источник сообщения — выбранная роль», чтобы затем отделять ошибку маршрута от ошибки ответа модели.
Передача задачи между ролями требует отдельного решения. Если исследователь передаёт выдержку редактору, опишите допустимые поля и адресата передачи. Историю чужих разговоров редактору лучше закрыть. Возможность направить запрос другому агенту и право читать его сеансы имеют разные настройки; обе границы проверьте на тестовом контуре.
Инструменты ролей
После маршрута составьте матрицу инструментов. Исследователю нужен доступ к утверждённым материалам и возможность возвращать ссылки. Редактору нужен черновик, но право внешней отправки остаётся у ответственного сотрудника. В OpenClaw для отдельного агента можно задать песочницу и списки allow и deny для инструментов, согласно документации по правам. Рабочую конфигурацию сверяйте с актуальной версией документации перед запуском.
Сравните список доступных инструментов с реальной задачей. Для чтения материалов нет причины открывать командную строку, запись файлов или управление внешними каналами. Если редактору нужен только локальный черновик, разрешите запись в выделенную рабочую область и оставьте публикацию на отдельном серверном шаге. Право владельца процесса подтверждать отправку проверяет сервер приложения; промпт описывает условие, а полномочия проверяет сервер.
- Проверьте доступ к своим файлам и отсутствие доступа к материалам соседней роли.
- Проверьте запрет операции записи там, где роль отвечает только за чтение.
- Проверьте видимость чужих сеансов и возможность передачи сообщений между ролями.
- Проверьте отклонение внешнего действия без подтверждения на сервере.
Такая матрица превращает абстрактные ограничения в наблюдаемые проверки. Сохраните для каждого теста вход, ожидаемое действие и фактический результат. Если роль получила лишний инструмент, исправьте конфигурацию и повторите тот же сценарий. Если инструмент запрещён, а ответ модели обещает его выполнить, пользователь увидит расхождение между словами и возможностями. Это тоже повод переписать инструкцию роли.
Хотите сверить права агентов в вашем рабочем процессе?
Пилот и приёмка
Предложите пилот на обезличенном запросе к внутренним правилам. Исследователь должен выбрать источник и вернуть цитату; редактор получает только проверенную выдержку и готовит черновик. Ответственный сотрудник сверяет цитату с актуальным документом и фиксирует решение об ответе. Для оценки пилота запишите маршрут сообщения, доступные инструменты, видимые файлы и результат проверки содержания.
Отдельно испытайте пограничные ситуации: запрос попал в другой разговор, исследователь попросил чужой файл, редактор попытался увидеть историю соседней роли, а черновик содержит недоказанное утверждение. Для каждого случая заранее определите ожидаемую остановку и владельца решения. Если требуется дополнительный инструмент, расширяйте доступ после проверки его назначения. Так рост числа ролей сохраняет ясную границу ответственности. Добавьте в протокол проверки снимок применённой конфигурации и список разрешённых инструментов. При изменении роли повторите именно те сценарии, которые раньше подтверждали её границы. Так команда заметит расширение доступа до работы с настоящими запросами.
Нарисуйте маршрут одного тестового сообщения и подпишите рядом владельца роли, доступные файлы и допустимые инструменты. Затем сравните схему с фактической привязкой и результатом проверки доступа. Ошибка маршрутизации здесь важнее красоты черновика: она сразу показывает, что сообщение попало к роли с другим контекстом.
Стоимость настройки зависит от числа ролей, объёма изолируемых материалов, каналов, набора инструментов и требований к подтверждению. Тарифы используемых сервисов сверяйте на их страницах; состав работ обсуждайте по вашей схеме доступа. Если нужен управляемый процесс с приёмкой человеком, опишите задачу через страницу об ИИ-агентах для бизнеса: подготовим оценку работ. Общие критерии выбора системы изложены в статье о платформах для ИИ-агентов.