Configuration

Маршрутизація каналів

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

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

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

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

Префікси вихідних цілей

Явні вихідні цілі можуть містити префікс постачальника, наприклад telegram:123 або tg:123. Ядро розглядає цей префікс як підказку для вибору каналу, лише коли вибраним каналом є last або канал інакше не визначено, і лише коли завантажений плагін оголошує підтримку цього префікса. Якщо викликач уже явно вибрав канал, префікс постачальника має відповідати цьому каналу; міжканальні комбінації, як-от доставка через WhatsApp до telegram:123, завершуються помилкою ще до нормалізації цілі, специфічної для плагіна.

Префікси типу цілі та служби, як-от channel:<id>, user:<id>, room:<id>, thread:<id>, imessage:<handle> і sms:<number>, залишаються частиною граматики вибраного каналу. Самі по собі вони не вибирають постачальника.

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

Безпосередні повідомлення за замовчуванням зводяться до основного сеансу агента:

agent:<agentId>:<mainKey> (за замовчуванням: agent:main:main)

session.dmScope керує зведенням безпосередніх повідомлень: main (за замовчуванням) використовує один спільний основний сеанс, тоді як per-peer, per-channel-peer і per-account-channel-peer зберігають безпосередні повідомлення в окремих сеансах. Прив’язка маршруту може перевизначити область для відповідних співрозмовників через bindings[].session.dmScope.

Навіть коли історія розмов у безпосередніх повідомленнях спільна з основним сеансом, пісочниця та політика інструментів використовують похідний ключ середовища виконання безпосереднього чату для кожного облікового запису для зовнішніх безпосередніх повідомлень, щоб повідомлення, отримані з каналів, не оброблялися як локальні запуски основного сеансу.

Групи й канали залишаються ізольованими в межах кожного каналу:

Групи: 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 містить рівно один запис без символу підстановки.
Запис можна нормалізувати до конкретного ідентифікатора відправника для цього каналу.
Відправник вхідного безпосереднього повідомлення не відповідає цьому закріпленому власнику.

У разі такої невідповідності OpenClaw усе одно записує метадані вхідного сеансу, але не оновлює lastRoute основного сеансу.

Захищений запис вхідних повідомлень

Плагіни каналів можуть позначати запис вхідного сеансу як createIfMissing: false, коли захищений шлях не повинен створювати новий сеанс OpenClaw. У цьому режимі OpenClaw може оновлювати метадані та lastRoute наявного сеансу, але не створює запис сеансу лише для маршруту тільки через те, що було отримано повідомлення.

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

Маршрутизація вибирає одного агента для кожного вхідного повідомлення:

Точний збіг співрозмовника (bindings з peer.kind + peer.id).
Збіг батьківського співрозмовника (успадкування гілки).
Збіг співрозмовника за символом підстановки (peer.id: "*" для типу співрозмовника).
Збіг сервера й ролей (Discord) через guildId + roles.
Збіг сервера (Discord) через guildId.
Збіг команди (Slack) через teamId.
Збіг облікового запису (accountId у каналі).
Збіг каналу (будь-який обліковий запис у цьому каналі, accountId: "*").
Стандартний агент (agents.list[].default, інакше перший запис у списку, з резервним переходом до main).

Якщо прив’язка містить кілька полів зіставлення (peer, guildId, teamId, roles), для застосування цієї прив’язки мають збігатися всі вказані поля.

Зіставлений агент визначає, який робочий простір і сховище сеансів використовуються.

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

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

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

json5

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

Дивіться: Групи розсилки.

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

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" },  ],}

Зберігання сеансів

Рядки сеансів середовища виконання зберігаються в базі даних SQLite кожного агента в каталозі стану (за замовчуванням ~/.openclaw):

~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite

У старіших інсталяціях можуть бути застарілі файли транскриптів JSONL і сховище рядків sessions.json у ~/.openclaw/agents/<agentId>/sessions/. Запуск Gateway і openclaw doctor --fix автоматично імпортують активно використовувані застарілі рядки й історію до SQLite. Використовуйте openclaw doctor --session-sqlite inspect --session-sqlite-all-agents і послідовність перевірки Doctor, коли потрібні явні докази міграції. Для робочих процесів міграції та автономного обслуговування все ще можна вибрати шлях до застарілого сховища за допомогою шаблонів session.store і {agentId}.

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

Поведінка WebChat

WebChat під’єднується до вибраного агента й за замовчуванням використовує основний сеанс агента. Завдяки цьому у WebChat можна переглядати міжканальний контекст цього агента в одному місці.

Контекст відповіді

Вхідні відповіді містять:

ReplyToId, ReplyToBody і ReplyToSender, якщо доступні.
Цитований контекст додається до Body як блок [Replying to ...].

Ця поведінка однакова для всіх каналів.

Пов’язані матеріали

Was this useful?