Вопрос

Второй агент в OpenClaw: как развести ботов по каналам

Добавите второго агента через openclaw agents add, привяжете его к своему каналу в блоке bindings и разнесёте настройки skills и плагинов.

· 3 мин чтения

Коротко

  • У каждого агента свой workspace, свой agentDir и своя SQLite с сессиями.
  • Отдельный аккаунт в канале привязывается к агенту через блок bindings.
  • Workspace у каждого свой, skills и хранилища плагинов по умолчанию общие: их надо разнести отдельно.

Сверено с документацией OpenClaw 2026.10.4, 17 октября 2026.

Один Gateway умеет держать несколько изолированных агентов. Каждому нужны своя рабочая папка и свой agentDir, иначе пересекутся авторизация и сессии. Канал сначала принимает сообщение по своим правилам, и только потом bindings выбирает агента. Ниже минимальный путь: создать агента, привязать к нему аккаунт и не сломать общие настройки.

Что такое агент и что такое bindings

Агент — это полная персона: рабочая папка с AGENTS.md, SOUL.md и заметками, профили авторизации, реестр моделей и хранилище сессий. Сессии и транскрипты лежат в <agentDir>/openclaw-agent.sqlite, по умолчанию это ~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite.

Binding привязывает аккаунт канала к конкретному агенту. Это не контроль доступа и не настройка самого канала: канал уже принял сообщение, и binding только выбирает, кто на него ответит.

Минимальный путь: добавить агента и привязать канал

  1. Создайте агента командой openclaw agents add support. Ключ --bind <channel[:accountId]> можно повторять, чтобы сразу повесить аккаунты.
  2. Проверьте, что оба агента описаны в agents.entries и стоит agents.ownership: "explicit" (OpenClaw ставит его сам при создании второго агента). Без привязок у такой конфигурации нет агента по умолчанию.
  3. Добавьте блок bindings в ~/.openclaw/openclaw.json: первым узкое правило для конкретного аккаунта, ниже широкий резерв accountId: "*" на остальные аккаунты.
  4. Проверьте результат: openclaw agents list --bindings и openclaw channels status --probe.
  5. Если gateway.reload.mode стоит в off, перезапустите Gateway, чтобы bindings применились.
{
  agents: {
    ownership: "explicit",
    entries: {
      main: {
        workspace: "~/.openclaw/workspace",
      },
      support: {
        workspace: "~/.openclaw/workspace-support",
      },
    },
  },
  bindings: [
    {
      agentId: "support",
      comment: "Route the support bot account to the support agent",
      match: {
        channel: "discord",
        accountId: "support",
      },
    },
    {
      agentId: "main",
      match: {
        channel: "discord",
        accountId: "*",
      },
    },
  ],
}

Что остаётся общим, а что надо разнести

Workspace у каждого агента свой. Skills подгружаются из папок каждого агента плюс общие корни вроде ~/.openclaw/skills и фильтруются по списку разрешённых: agents.defaults.skills задаёт базовый набор, agents.entries.*.skills заменяет его целиком для конкретного агента, а не сливает с базовым.

Хранилища плагинов так не разделяются автоматически: добавление второго агента само по себе не раскладывает по нему глобальные хранилища плагинов. Если двум персонам нельзя делиться собранной вики-памятью, настройте отдельные хранилища Memory Wiki по агентам. Рабочая папка — это каталог по умолчанию, а не песочница: абсолютные пути всё равно ведут в другие места хоста, пока не включена изоляция.

Полезные команды

openclaw agents add support
openclaw agents list --bindings
openclaw agents list --tree
openclaw channels status --probe

Частые ошибки

  • Опускают accountId, имея в виду «все аккаунты». Если accountId не указан, правило сработает только для аккаунта по умолчанию; для всего канала пишите accountId: "*".
  • Binding указывает на агента, которого нет в agents.entries. OpenClaw не подменит его на другого агента, а вернёт AGENT_SELECTION_REQUIRED.
  • Считают bindings контролем доступа. Они выбирают агента уже после того, как канал принял сообщение; сопряжение, dmPolicy и списки разрешённых настраиваются отдельно.
  • Копируют OAuth-учётки второму агенту вручную. Refresh-токены по умолчанию не переносятся: для независимого аккаунта войдите из-под этого агента, либо используйте copyToAgents, либо копируйте только статические api_key и token.