English简体中文繁體中文日本語EspañolPortuguês (BR)한국어DeutschFrançaisالعربيةItalianoTiếng ViệtNederlandsTürkçeУкраїнськаBahasa IndonesiaPolskiفارسیไทย

Configuration

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

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

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

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

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

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

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

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

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

Прямі повідомлення типово згортаються в основну сесію агента:

  • agent:<agentId>:<mainKey> (типово: agent:main:main)

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

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

  • Групи: 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

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

Коли session.dmScope має значення main, прямі повідомлення можуть спільно використовувати одну основну сесію. Щоб запобігти перезапису lastRoute сесії прямими повідомленнями не від власника, OpenClaw виводить закріпленого власника з allowFrom, коли всі ці умови істинні:

  • allowFrom має рівно один запис без символу-замінника.
  • Запис можна нормалізувати до конкретного ідентифікатора відправника для цього каналу.
  • Відправник вхідного DM не відповідає цьому закріпленому власнику.

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

Захищений запис вхідних даних

Канальні Plugin-и можуть позначати запис вхідної сесії як createIfMissing: false, коли захищений шлях не повинен створювати нову сесію OpenClaw. У цьому режимі 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), усі надані поля мають збігатися, щоб ця прив’язка застосувалася.

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

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

Групи трансляції дають змогу запускати кілька агентів для одного й того самого однорангового вузла коли 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 ...].

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

Пов’язане