198 lines
5.8 KiB
Markdown
198 lines
5.8 KiB
Markdown
Poniżej masz **jasne, techniczne, ale praktyczne wyjaśnienie jak działa `sessions_spawn` w OpenClaw** — **bez lania wody**, krok po kroku, z mentalnym modelem „co się naprawdę dzieje pod maską”.
|
||
|
||
***
|
||
|
||
# Jak działa `sessions_spawn` w OpenClaw
|
||
|
||
## TL;DR
|
||
|
||
`sessions_spawn` to **mechanizm delegowania pracy do tymczasowego sub‑agenta**, który:
|
||
|
||
* działa **równolegle** do głównego agenta,
|
||
* ma **własną sesję i kontekst**,
|
||
* **nie blokuje** głównej rozmowy,
|
||
* po zakończeniu **odsyła wynik** do agenta nadrzędnego,
|
||
* jest **automatycznie sprzątany** (chyba że ustawisz inaczej).
|
||
|
||
To dokładnie model: **manager → deleguje task → dostaje raport**. [\[learnopenclaw.com\]](https://learnopenclaw.com/advanced/sub-agents), [\[deepwiki.com\]](https://deepwiki.com/openclaw/openclaw/3.4.3-subagents-and-acp)
|
||
|
||
***
|
||
|
||
## 1️⃣ Co to jest sub‑agent technicznie
|
||
|
||
Gdy wywołujesz `sessions_spawn`, OpenClaw:
|
||
|
||
1. Tworzy **nową sesję** o kluczu:
|
||
agent:<agentId>:subagent:<uuid>
|
||
|
||
2. Ta sesja:
|
||
* ma **oddzielne okno kontekstu** (własne tokeny),
|
||
* **dziedziczy SOUL / AGENTS / USER** agenta nadrzędnego,
|
||
* **nie dostaje narzędzi sesyjnych** (np. nie może listować innych sesji),
|
||
* **nie ładuje MEMORY.md** (bezpieczna izolacja).
|
||
|
||
3. Sub‑agent wykonuje **jedno zadanie** i kończy run. [\[deepwiki.com\]](https://deepwiki.com/openclaw/openclaw/3.4.3-subagents-and-acp)
|
||
|
||
***
|
||
|
||
## 2️⃣ Co dokładnie robi `sessions_spawn` (flow runtime)
|
||
|
||
### Krok po kroku (runtime):
|
||
|
||
1. **Agent nadrzędny** decyduje:
|
||
> „To zadanie jest długie / wolne / równoległe — deleguję”.
|
||
|
||
2. Agent wywołuje tool:
|
||
```text
|
||
sessions_spawn
|
||
```
|
||
|
||
3. OpenClaw:
|
||
* natychmiast zwraca `runId` (non‑blocking),
|
||
* **główny agent działa dalej**.
|
||
|
||
4. **Sub‑agent**:
|
||
* dostaje instrukcję (`task`),
|
||
* pracuje w tle,
|
||
* używa modeli / narzędzi zgodnie z polityką.
|
||
|
||
5. Po zakończeniu:
|
||
* OpenClaw wysyła **announce message** do sesji rodzica:
|
||
* wynik,
|
||
* status (success / failed / timeout),
|
||
* krótkie statystyki.
|
||
|
||
6. Sesja sub‑agenta:
|
||
* domyślnie **zostaje zarchiwizowana** lub usunięta. [\[deepwiki.com\]](https://deepwiki.com/openclaw/openclaw/3.4.3-subagents-and-acp), [\[docs.openclaw.kr\]](https://docs.openclaw.kr/tools/subagents)
|
||
|
||
***
|
||
|
||
## 3️⃣ Najważniejsze parametry `sessions_spawn`
|
||
|
||
Najczęściej używane (i sensowne w produkcji):
|
||
|
||
### 🔹 `task` (wymagane)
|
||
|
||
Co sub‑agent ma zrobić.
|
||
|
||
* **Im bardziej precyzyjne, tym lepiej**
|
||
* Traktuj jak „ticket w JIRA”
|
||
|
||
[\[learnopenclaw.com\]](https://learnopenclaw.com/advanced/sub-agents)
|
||
|
||
***
|
||
|
||
### 🔹 `label` (opcjonalne, ALE BARDZO POLECANE)
|
||
|
||
Czytelna nazwa zadania, np.:
|
||
|
||
* `css-fix-header`
|
||
* `research-competitors`
|
||
* `db-review-migrations`
|
||
|
||
Pomaga w logach, debugowaniu i `/subagents list`. [\[deepwiki.com\]](https://deepwiki.com/openclaw/openclaw/3.4.3-subagents-and-acp)
|
||
|
||
***
|
||
|
||
### 🔹 `model` / `thinking`
|
||
|
||
Możesz nadpisać model tylko dla tego zadania:
|
||
|
||
* np. research → tańszy model
|
||
* architektura → droższy, większe „thinking”
|
||
|
||
[\[deepwiki.com\]](https://deepwiki.com/openclaw/openclaw/3.4.3-subagents-and-acp)
|
||
|
||
***
|
||
|
||
### 🔹 `runTimeoutSeconds`
|
||
|
||
Twardy limit czasu.
|
||
|
||
* Po przekroczeniu → sub‑agent jest ubijany
|
||
* Bardzo ważne w automatyzacjach
|
||
|
||
[\[deepwiki.com\]](https://deepwiki.com/openclaw/openclaw/3.4.3-subagents-and-acp)
|
||
|
||
***
|
||
|
||
### 🔹 `cleanup`
|
||
|
||
* `keep` (domyślnie) – sesja zostaje w historii
|
||
* `delete` – sprzątana po zakończeniu
|
||
|
||
[\[deepwiki.com\]](https://deepwiki.com/openclaw/openclaw/3.4.3-subagents-and-acp)
|
||
|
||
***
|
||
|
||
## 4️⃣ Czego sub‑agent **NIE MOŻE**
|
||
|
||
To kluczowe (i często źle rozumiane):
|
||
|
||
❌ Nie ma własnego workspace
|
||
❌ Nie zapisuje do `MEMORY.md`
|
||
❌ Nie ma trwałej tożsamości
|
||
❌ Nie zarządza innymi sesjami
|
||
❌ Nie powinien podejmować decyzji strategicznych
|
||
|
||
Sub‑agent:
|
||
|
||
> **robi robotę i wraca z wynikiem**. [\[deepwiki.com\]](https://deepwiki.com/openclaw/openclaw/3.4.3-subagents-and-acp)
|
||
|
||
***
|
||
|
||
## 5️⃣ Kiedy OpenClaw SAM wybiera `sessions_spawn`
|
||
|
||
Dobrze napisany agent (np. Twój COO‑orchestrator) używa `sessions_spawn`, gdy:
|
||
|
||
* task jest **długi** (research, analiza),
|
||
* task jest **równoległy** (N podobnych rzeczy),
|
||
* task używa **wolnych narzędzi** (web, pliki),
|
||
* wynik da się jasno opisać (lista, raport, JSON).
|
||
|
||
Dokładnie ten pattern jest opisany w oficjalnych materiałach o sub‑agentach. [\[learnopenclaw.com\]](https://learnopenclaw.com/advanced/sub-agents)
|
||
|
||
***
|
||
|
||
## 6️⃣ Przykład mentalny (bez kodu)
|
||
|
||
> Użytkownik:
|
||
> „Zbadaj 5 konkurentów i porównaj ich feature’y”
|
||
|
||
**Bez `sessions_spawn`:**
|
||
|
||
* agent robi wszystko sekwencyjnie,
|
||
* długo,
|
||
* blokuje rozmowę.
|
||
|
||
**Z `sessions_spawn`:**
|
||
|
||
* agent tworzy 5 sub‑agentów:
|
||
* `research-competitor-1`
|
||
* `research-competitor-2`
|
||
* …
|
||
* każdy robi swoje,
|
||
* agent nadrzędny zbiera wyniki i składa raport.
|
||
|
||
To **główna przewaga OpenClaw nad „zwykłym chatbotem”**. [\[learnopenclaw.com\]](https://learnopenclaw.com/advanced/sub-agents), [\[deepwiki.com\]](https://deepwiki.com/openclaw/openclaw/3.4.3-subagents-and-acp)
|
||
|
||
***
|
||
|
||
## 7️⃣ Złota reguła projektowa (z naszej rozmowy)
|
||
|
||
> **Agent = rola + pamięć + odpowiedzialność**
|
||
> **Sub‑agent = task + wynik + znikam**
|
||
|
||
Jeśli:
|
||
|
||
* potrzebujesz pamięci → **Agent**
|
||
* potrzebujesz wyniku → **sessions\_spawn**
|
||
|
||
***
|
||
|
||
Jeśli chcesz, w kolejnym kroku mogę:
|
||
|
||
* rozpisać **konkretny playbook: CTO / CMO / CRO → jakie taski spawnują**
|
||
* albo dać Ci **gotowy snippet do AGENTS.md**, który uczy agenta *kiedy* ma używać `sessions_spawn`
|
||
* albo przeanalizować **Twoje use‑case’y (DB / infra / automatyzacja)** i powiedzieć *gdzie spawn ma sens, a gdzie nie*.
|