Каналы и маршрутизация

OpenClaw направляет ответы обратно в тот канал, откуда пришло сообщение. Модель не выбирает канал; маршрутизация детерминирована и управляется конфигурацией хоста.

Ключевые понятия

• Channel: whatsapp, telegram, discord, slack, signal, imessage, webchat.
• AccountId: экземпляр аккаунта внутри канала (если поддерживается).
• Аккаунт по умолчанию: channels.<channel>.defaultAccount определяет, какой аккаунт используется, когда исходящий путь не задаёт accountId.
  • В мульти-аккаунтных конфигурациях задайте явный дефолт (defaultAccount или accounts.default), когда настроены два и более аккаунтов. Без этого fallback-маршрутизация может выбрать первый нормализованный ID аккаунта.
• AgentId: изолированное рабочее пространство + хранилище сессий («мозг»).
• SessionKey: ключ-бакет для хранения контекста и управления параллелизмом.

Формы ключей сессий (примеры)

Прямые сообщения схлопываются в основную сессию агента:

• agent:<agentId>:<mainKey> (по умолчанию: agent:main:main)

Группы и каналы изолированы по каналу:

• Группы: agent:<agentId>:<channel>:group:<id>
• Каналы/комнаты: agent:<agentId>:<channel>:channel:<id>

Потоки (threads):

• Slack/Discord threads добавляют :thread:<threadId> к базовому ключу.
• Telegram forum topics встраивают :topic:<topicId> в ключ группы.

Примеры:

• agent:main:telegram:group:-1001234567890:topic:42
• agent:main:discord:channel:123456:thread:987654

Закрепление маршрута основного DM

Когда session.dmScope равен main, прямые сообщения могут использовать одну общую основную сессию. Чтобы lastRoute сессии не перезаписывался DM от не-владельцев, OpenClaw определяет закреплённого владельца из allowFrom, когда выполняются все условия:

• allowFrom содержит ровно одну запись, отличную от wildcard.
• Запись может быть нормализована в конкретный ID отправителя для данного канала.
• ID входящего DM-отправителя не совпадает с закреплённым владельцем.

В таком случае OpenClaw по-прежнему записывает метаданные входящей сессии, но пропускает обновление lastRoute основной сессии.

Правила маршрутизации (как выбирается агент)

Маршрутизация выбирает одного агента для каждого входящего сообщения:

1. Точное совпадение пира (bindings с peer.kind + peer.id).
2. Совпадение родительского пира (наследование потока).
3. Совпадение гильдии + ролей (Discord) через guildId + roles.
4. Совпадение гильдии (Discord) через guildId.
5. Совпадение команды (Slack) через teamId.
6. Совпадение аккаунта (accountId канала).
7. Совпадение канала (любой аккаунт этого канала, accountId: "*").
8. Агент по умолчанию (agents.list[].default, иначе первая запись списка, fallback к main).

Когда привязка содержит несколько полей совпадения (peer, guildId, teamId, roles), все указанные поля должны совпасть, чтобы привязка сработала.

Совпавший агент определяет, какое рабочее пространство и хранилище сессий будут использоваться.

Группы рассылки (запуск нескольких агентов)

Группы рассылки позволяют запустить несколько агентов для одного пира когда OpenClaw обычно ответил бы (например: в группах WhatsApp, после гейтинга по упоминанию/активации).

Конфигурация:

{
  broadcast: {
    strategy: "parallel",
    "[email protected]": ["alfred", "baerbel"],
    "+15555550123": ["support", "logger"],
  },
}

См.: Группы рассылки.

Обзор конфигурации

• agents.list: именованные определения агентов (рабочее пространство, модель и т.д.).
• bindings: привязка входящих каналов/аккаунтов/пиров к агентам.

Пример:

{
  agents: {
    list: [{ id: "support", name: "Support", workspace: "~/.openclaw/workspace-support" }],
  },
  bindings: [
    { match: { channel: "slack", teamId: "T123" }, agentId: "support" },
    { match: { channel: "telegram", peer: { kind: "group", id: "-100123" } }, agentId: "support" },
  ],
}

Хранилище сессий

Хранилища сессий располагаются в директории состояния (по умолчанию ~/.openclaw):

• ~/.openclaw/agents/<agentId>/sessions/sessions.json
• JSONL-транскрипты хранятся рядом с хранилищем

Путь хранилища можно переопределить через session.store и шаблонизацию {agentId}.

Обнаружение сессий Gateway и ACP также сканирует дисковые хранилища агентов в корне agents/ по умолчанию и в корнях шаблонизированного session.store. Обнаруженные хранилища должны оставаться внутри разрешённого корня агента и использовать файл sessions.json. Символические ссылки и пути за пределами корня игнорируются.

Поведение WebChat

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

Контекст ответа

Входящие ответы включают:

• ReplyToId, ReplyToBody и ReplyToSender, когда доступны.
• Цитированный контекст добавляется к Body как блок [Replying to ...].

Это поведение единообразно для всех каналов.