OpenClaw Multi-agent: wielu asystentów, jeden serwer

OPUBLIKOWANO: 11 lutego 2026

Jeśli masz jednego asystenta AI „do wszystkiego”, szybko odkrywasz dwa problemy: brak specjalizacji i bałagan w kontekście. Ten sam agent raz ma planować sprint, raz pisać posty, raz grzebać w serwerze – a Ty oczekujesz, że zawsze będzie równie dobry i równie bezpieczny.

Multi-agent w OpenClaw rozwiązuje to prosto: zamiast jednego „mózgu” masz kilka izolowanych agentów, gdzie każdy ma własny workspace, własne sesje i własną konfigurację. W praktyce budujesz wirtualny zespół ról, a nie jednego bota.

Co ważne: multi-agent w OpenClaw nie jest gadżetem. To mechanizm, który pozwala trzymać porządek w firmie: jeden agent do operacji, drugi do komunikacji, trzeci do pisania, czwarty do kodu – i każdy dostaje odpowiednie narzędzia, model oraz granice.

1. Czym jest agent w OpenClaw (konkretnie)
2. Po co Ci wielu agentów: jakość, koszty i porządek
3. Routing wiadomości: jak OpenClaw wybiera właściwego agenta
4. Komunikacja między agentami (kiedy ma sens)
5. Przykład konfiguracji: „Home” i „Work” na jednym Gateway
6. Dobre praktyki: nazewnictwo, uprawnienia, bezpieczeństwo

Czym jest agent w OpenClaw (konkretnie)

W OpenClaw agent to nie „profil czatu”. To osobny, izolowany „mózg”, który ma własny workspace (pliki, SOUL.md, USER.md), własny katalog stanu (auth i konfiguracje) oraz własne sesje rozmów.

Ta izolacja ma znaczenie, bo w firmie najdroższe są pomyłki kontekstu. Jeśli agent „od marketingu” miesza decyzje techniczne z komunikacją do klienta, szybko robi się to ryzykowne. Multi-agent to sposób, żeby konteksty nie przeciekały.

Ważny detal: uwierzytelnienia (np. konta kanałów) są per agent. Nie zakładaj, że „wszystko jest współdzielone”. Jeśli chcesz, żeby agent work miał dostęp do tych samych profili auth co agent home, robisz to świadomie.

Po co Ci wielu agentów: jakość, koszty i porządek

Pierwszy zysk to specjalizacja. Jeden agent może być operacyjny: zwięzły, nastawiony na listy kontrolne i bezpieczeństwo. Drugi może być pisarski: dbać o styl, strukturę i redakcję. W efekcie dostajesz lepsze wyniki bez wymuszania jednego kompromisowego stylu.

Drugi zysk to kontrola kosztów i wydajności. Możesz przypisać różne modele do różnych agentów: szybki do codziennego czatu, mocny do trudnych analiz, a kodowy do pracy w repo. To nie fanaberia – to normalna optymalizacja, gdy AI zaczyna pracować codziennie.

Trzeci zysk to bezpieczeństwo i granice. Agent, który ma dostęp do terminala i infrastruktury, nie powinien jednocześnie odpowiadać w publicznych kanałach. Multi-agent ułatwia zasadę minimalnych uprawnień: każdy agent dostaje tylko to, czego potrzebuje.

Routing wiadomości: jak OpenClaw wybiera właściwego agenta

Multi-agent bez routingu byłby tylko chaosem. Dlatego OpenClaw używa bindings: deterministycznych reguł, które mapują wiadomości przychodzące na konkretne agentId.

Najważniejsza zasada jest prosta: najbardziej szczegółowe dopasowanie wygrywa. Jeśli masz regułę na konkretny DM albo konkretną grupę – ona ma pierwszeństwo. Dopiero potem wchodzą reguły ogólne (np. „cały kanał Telegram → agent work”).

To podejście jest dobre, bo jest przewidywalne. W firmie chcesz wiedzieć, gdzie trafi wiadomość, zanim ją wyślesz. Routing ma być narzędziem porządku, a nie magią.

Komunikacja między agentami (kiedy ma sens)

W pewnym momencie agent PM będzie chciał poprosić agenta Coder o sprawdzenie PR-a, albo agenta Ops o sprawdzenie logów. To naturalne: nawet w realnym zespole role ze sobą rozmawiają.

W OpenClaw komunikacja agent-to-agent jest celowo „zamknięta” na start. Musisz ją jawnie włączyć i allowlistować, żeby uniknąć przypadkowego wycieku kontekstu między agentami.

Dobra praktyka: agent-to-agent traktuj jak wewnętrzne API. Krótkie, konkretne zlecenia, jasny cel – a nie „porozmawiajcie sobie”. Wtedy to działa.

Przykład konfiguracji: „Home” i „Work” na jednym Gateway

Poniżej jest sensowny minimalny przykład: dwa izolowane agentId, osobne workspace i routing po kanale albo po koncie.

Najprościej dodać agenta przez CLI:

openclaw agents add work
openclaw agents add home

openclaw agents list --bindings

A potem skonfigurować agents.list oraz bindings w ~/.openclaw/openclaw.json (format JSON5):

{
  agents: {
    list: [
      { id: "home", default: true, workspace: "~/.openclaw/workspace-home" },
      { id: "work", workspace: "~/.openclaw/workspace-work" },
    ],
  },

  bindings: [
    // Przykład: cały Telegram trafia do agenta work
    { agentId: "work", match: { channel: "telegram" } },

    // Przykład: wybrany DM w WhatsApp trafia do home
    { agentId: "home", match: { channel: "whatsapp", peer: { kind: "dm", id: "+48123123123" } } },
  ],

  tools: {
    agentToAgent: {
      enabled: false,
      allow: ["home", "work"],
    },
  },
}

Ten przykład jest nudny – i właśnie dlatego dobry. Multi-agent ma być przewidywalny, a nie efektowny.

Dobre praktyki: nazewnictwo, uprawnienia, bezpieczeństwo

Zacznij od nazewnictwa agentów po roli: work, ops, writer, dev. To ułatwia routing i rozmowy w zespole. Czytelność jest ważniejsza niż kreatywne nazwy.

Następnie dopasuj uprawnienia. Agent od treści zwykle nie potrzebuje terminala, a agent od infrastruktury nie powinien odpowiadać w publicznych kanałach. Multi-agent ułatwia zasadę minimalnych uprawnień, ale to Ty ją projektujesz.

Na koniec: nie automatyzuj wysokich stawek od razu. Jeśli agent może coś wykonać nieodwracalnie, dodaj etap zatwierdzenia. Human-in-the-loop jest w praktyce najszybszą drogą do stabilnej automatyzacji.

Potrzebujesz architektury multi-agent w firmie?