Vai al contenuto principale

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

Le lane specialistiche parallele consentono a un Gateway di instradare chat o stanze diverse verso agenti diversi, mantenendo rapida l’esperienza utente. Il trucco è trattare il parallelismo come un problema di progettazione con risorse scarse, non solo come “più agenti”.

​
Principi fondamentali

Una lane specialistica migliora il throughput solo quando riduce la contesa per i veri colli di bottiglia:
  • Blocchi di sessione: una sola esecuzione dovrebbe modificare una determinata sessione alla volta.
  • Capacità globale del modello: tutte le esecuzioni di chat visibili condividono comunque i limiti del provider.
  • Capacità degli strumenti: shell, browser, rete e lavoro sul repository possono essere più lenti del turno del modello stesso.
  • Budget di contesto: transcript lunghi rendono ogni turno futuro più lento e meno focalizzato.
  • Ambiguità di proprietà: agenti duplicati che svolgono lo stesso lavoro sprecano capacità.
OpenClaw serializza già le esecuzioni per sessione e limita il parallelismo globale tramite la coda dei comandi. Le lane specialistiche aggiungono policy sopra: quale agente possiede quale lavoro, cosa resta in chat e cosa diventa lavoro in background.

​
Rollout consigliato

​
Fase 1: contratti di lane + lavoro pesante in background

Assegna a ogni lane un contratto scritto nel suo workspace e nel prompt di sistema:
  • Scopo: il lavoro di cui questa lane è proprietaria.
  • Non obiettivi: lavoro che dovrebbe passare ad altri invece di tentare.
  • Budget di chat: le risposte rapide restano in chat; le attività lunghe dovrebbero confermare brevemente, quindi eseguirsi in un sub-agente o task in background.
  • Regola di handoff: quando un’altra lane possiede il lavoro, indicare dove dovrebbe andare e fornire un riepilogo compatto per l’handoff.
  • Regola sul rischio degli strumenti: preferire la superficie di strumenti più piccola in grado di svolgere il lavoro.
Questa è la fase più economica e risolve la maggior parte degli intasamenti: un lavoro di coding non trasforma più la lane di ricerca in melassa, e ogni chat mantiene pulito il proprio contesto.

​
Fase 2: controlli di priorità e concorrenza

Configura coda e capacità del modello in base al valore aziendale di ogni lane: 
{
  agents: {
    defaults: {
      maxConcurrent: 4,
      subagents: { maxConcurrent: 8 },
    },
  },
  messages: {
    queue: {
      mode: "collect",
      debounceMs: 1000,
      cap: 20,
      drop: "summarize",
    },
  },
}
Usa chat dirette/personali e agenti per operazioni di produzione per il lavoro ad alta priorità. Lascia che ricerca, stesura e coding batch passino a task in background quando il sistema è occupato.

​
Fase 3: coordinatore / controller del traffico

Aggiungi un piccolo pattern di coordinamento quando più lane sono attive:
  • Tieni traccia dei task e dei proprietari delle lane attive.
  • Rileva richieste duplicate tra gruppi.
  • Instrada i riepiloghi di handoff tra lane.
  • Mostra solo blocker, risultati completati e decisioni che la persona deve prendere.
Non iniziare da qui. Un coordinatore senza contratti di lane coordina solo il caos.

​
Template minimo di contratto di lane

# Lane contract

## Owns

- <job this lane is responsible for>

## Does not own

- <work to hand off>

## Chat budget

- Answer quick questions directly.
- For multi-step, slow, or tool-heavy work: acknowledge briefly, spawn/background
  the work, then return the result when complete.

## Handoff

If another lane owns the request, reply with:

- target lane
- objective
- relevant context
- exact next action

## Tool posture

Use the smallest tool surface that can complete the task. Avoid broad shell or
network work unless this lane explicitly owns it.

​
Correlati