Перейти до основного вмісту

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

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

​
Ключові терміни

  • Канал: telegram, whatsapp, discord, irc, googlechat, slack, signal, imessage, line, а також канали розширень. webchat — це внутрішній канал інтерфейсу WebChat і не є налаштовуваним вихідним каналом.
  • AccountId: екземпляр облікового запису для каналу (коли підтримується).
  • Необов’язковий типовий обліковий запис каналу: channels.<channel>.defaultAccount визначає, який обліковий запис використовується, коли вихідний шлях не задає accountId.
    • У конфігураціях із кількома обліковими записами задайте явний типовий обліковий запис (defaultAccount або accounts.default), коли налаштовано два або більше облікових записів. Без цього резервна маршрутизація може вибрати перший нормалізований ідентифікатор облікового запису.
  • AgentId: ізольований робочий простір + сховище сесій («мозок»).
  • SessionKey: ключ контейнера, який використовується для збереження контексту та керування паралельністю.

​
Форми ключів сесії (приклади)

Особисті повідомлення згортаються до основної сесії агента:
  • agent:<agentId>:<mainKey> (типово: agent:main:main)
Групи та канали залишаються ізольованими для кожного каналу:
  • Групи: agent:<agentId>:<channel>:group:<id>
  • Канали/кімнати: agent:<agentId>:<channel>:channel:<id>
Треди:
  • Треди Slack/Discord додають :thread:<threadId> до базового ключа.
  • Теми форуму Telegram вбудовують :topic:<topicId> у ключ групи.
Приклади:
  • agent:main:telegram:group:-1001234567890:topic:42
  • agent:main:discord:channel:123456:thread:987654

​
Закріплення основного маршруту особистих повідомлень

Коли session.dmScope має значення main, особисті повідомлення можуть використовувати спільну основну сесію. Щоб lastRoute сесії не перезаписувався особистими повідомленнями не від власника, OpenClaw визначає закріпленого власника з allowFrom, якщо виконуються всі ці умови:
  • allowFrom має рівно один запис без wildcard.
  • Цей запис можна нормалізувати до конкретного ідентифікатора відправника для цього каналу.
  • Відправник вхідного особистого повідомлення не збігається з цим закріпленим власником.
У разі такої невідповідності 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, інакше перший запис списку, резервно — main).
Коли прив’язка містить кілька полів збігу (peer, guildId, teamId, roles), усі вказані поля мають збігатися, щоб ця прив’язка застосувалася. Вибраний агент визначає, який робочий простір і сховище сесій використовуються.

​
Broadcast groups (запуск кількох агентів)

Broadcast groups дають змогу запускати кількох агентів для одного й того самого вузла коли OpenClaw зазвичай відповідає (наприклад, у групах WhatsApp після проходження згадки/активаційного шлюзу). Конфігурація: 
{
  broadcast: {
    strategy: "parallel",
    "120363403215116621@g.us": ["alfred", "baerbel"],
    "+15555550123": ["support", "logger"],
  },
}
Див.: Broadcast Groups.

​
Огляд конфігурації

  • 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 ...].
Це узгоджено в усіх каналах.