Kanaly i routing

OpenClaw kieruje odpowiedzi z powrotem na kanal, z ktorego przyszla wiadomosc. Model nie wybiera kanalu; routing jest deterministyczny i kontrolowany przez konfiguracje hosta.

Kluczowe pojecia

• Kanal: whatsapp, telegram, discord, slack, signal, imessage, webchat.
• AccountId: instancja konta na kanal (gdy obslugiwana).
• Opcjonalne domyslne konto kanalu: channels.<channel>.defaultAccount wybiera, ktore konto jest uzywane gdy sciezka wychodzaca nie podaje accountId.
  • W konfiguracjach wielokontowych ustaw jawne domyslne (defaultAccount lub accounts.default) gdy skonfigurowane sa dwa lub wiecej kont. Bez tego routowanie zastepczym moze wybrac pierwszy znormalizowany ID konta.
• AgentId: izolowana przestrzen robocza + magazyn sesji (“mozg”).
• SessionKey: klucz bucketu uzywany do przechowywania kontekstu i kontroli wspolbieznosci.

Ksztalty kluczy sesji (przyklady)

Wiadomosci bezposrednie zwijaja sie do glownej sesji agenta:

• agent:<agentId>:<mainKey> (domyslnie: agent:main:main)

Grupy i kanaly pozostaja izolowane na kanal:

• Grupy: agent:<agentId>:<channel>:group:<id>
• Kanaly/pokoje: agent:<agentId>:<channel>:channel:<id>

Watki:

• Watki Slack/Discord dolaczaja :thread:<threadId> do klucza bazowego.
• Tematy forum Telegram osadzaja :topic:<topicId> w kluczu grupy.

Przyklady:

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

Przypinanie glownej trasy DM

Gdy session.dmScope jest main, wiadomosci bezposrednie moga wspoldzielic jedna glowna sesje. Aby zapobiec nadpisywaniu lastRoute sesji przez DM od nie-wlascicieli, OpenClaw wnioskuje przypiętego wlasciciela z allowFrom gdy wszystkie ponizsze warunki sa spelnioane:

• allowFrom ma dokladnie jeden wpis nie-wildcard.
• Wpis moze byc znormalizowany do konkretnego ID nadawcy dla tego kanalu.
• Nadawca przychodzacego DM nie pasuje do tego przypietego wlasciciela.

W takim przypadku OpenClaw nadal rejestruje metadane sesji przychodzacej, ale pomija aktualizacje lastRoute glownej sesji.

Reguly routingu (jak agent jest wybierany)

Routing wybiera jednego agenta dla kazdej przychodzacej wiadomosci:

1. Dokladne dopasowanie peera (bindings z peer.kind + peer.id).
2. Dopasowanie peera nadrzednego (dziedziczenie watkow).
3. Dopasowanie guild + role (Discord) przez guildId + roles.
4. Dopasowanie guild (Discord) przez guildId.
5. Dopasowanie team (Slack) przez teamId.
6. Dopasowanie konta (accountId na kanale).
7. Dopasowanie kanalu (dowolne konto na tym kanale, accountId: "*").
8. Domyslny agent (agents.list[].default, w przeciwnym razie pierwszy wpis na liscie, zastepczym main).

Gdy binding zawiera wiele pol dopasowania (peer, guildId, teamId, roles), wszystkie podane pola musza pasowac aby ten binding zostal zastosowany.

Dopasowany agent okresla, ktora przestrzen robocza i magazyn sesji sa uzywane.

Grupy broadcastowe (uruchom wielu agentow)

Grupy broadcastowe pozwalaja uruchomic wielu agentow dla tego samego peera gdy OpenClaw normalnie by odpowiedzial (na przyklad: w grupach WhatsApp, po gatingu wzmianek/aktywacji).

Konfiguracja:

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

Zobacz: Grupy broadcastowe.

Przeglad konfiguracji

• agents.list: nazwane definicje agentow (przestrzen robocza, model itp.).
• bindings: mapuj przychodzace kanaly/konta/peery na agentow.

Przyklad:

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

Przechowywanie sesji

Magazyny sesji znajduja sie w katalogu stanu (domyslnie ~/.openclaw):

• ~/.openclaw/agents/<agentId>/sessions/sessions.json
• Transkrypcje JSONL znajduja sie obok magazynu

Mozesz nadpisac sciezke magazynu przez session.store i szablonowanie {agentId}.

Odkrywanie sesji Gateway i ACP skanuje rowniez dyskowe magazyny agentow pod domyslnym korzeniem agents/ i pod szablonowanymi korzeniami session.store. Odkryte magazyny musza pozostac wewnatrz rozwiazanego korzenia agenta i uzywac zwyklego pliku sessions.json. Dowiazania symboliczne i sciezki poza korzeniem sa ignorowane.

Zachowanie WebChat

WebChat dolacza do wybranego agenta i domyslnie uzywa glownej sesji agenta. Dzieki temu WebChat pozwala zobaczyc kontekst miedzykanalowy tego agenta w jednym miejscu.

Kontekst odpowiedzi

Przychodzace odpowiedzi zawieraja:

• ReplyToId, ReplyToBody i ReplyToSender gdy dostepne.
• Cytowany kontekst jest dolaczany do Body jako blok [Replying to ...].

Jest to spojne miedzy kanalami.