---
read_when:
    - Зміна маршрутизації каналів або поведінки вхідних повідомлень
summary: Правила маршрутизації для кожного каналу (WhatsApp, Telegram, Discord, Slack) і спільний контекст
title: Маршрутизація каналів
x-i18n:
    generated_at: "2026-04-05T17:57:18Z"
    model: gpt-5.4
    provider: openai
    source_hash: 63916c4dd0af5fc9bbd12581a9eb15fea14a380c5ade09323ca0c237db61e537
    source_path: channels/channel-routing.md
    workflow: 15
---

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

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 після проходження згадки/активаційного шлюзу).

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

```json5
{
  broadcast: {
    strategy: "parallel",
    "120363403215116621@g.us": ["alfred", "baerbel"],
    "+15555550123": ["support", "logger"],
  },
}
```

Див.: [Broadcast Groups](/channels/broadcast-groups).

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

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

Приклад:

```json5
{
  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 ...]`.

Це узгоджено в усіх каналах.
