Zum Hauptinhalt springen
Parallele Spezialisten-Lanes ermöglichen es einem Gateway, verschiedene Chats oder Räume an verschiedene Agenten weiterzuleiten und dabei die Benutzererfahrung schnell zu halten. Der entscheidende Punkt ist, Parallelität als Designproblem für knappe Ressourcen zu behandeln, nicht nur als „mehr Agenten“.

​
Grundprinzipien

Eine Spezialisten-Lane verbessert den Durchsatz nur, wenn sie Konflikte um die eigentlichen Engpässe reduziert:
  • Session-Sperren: Es sollte immer nur ein Lauf eine bestimmte Session gleichzeitig ändern.
  • Globale Modellkapazität: Alle sichtbaren Chat-Läufe teilen sich weiterhin die Provider-Limits.
  • Tool-Kapazität: Shell-, Browser-, Netzwerk- und Repository-Arbeit kann langsamer sein als der Modellschritt selbst.
  • Kontextbudget: Lange Transkripte machen jede zukünftige Runde langsamer und weniger fokussiert.
  • Unklare Zuständigkeit: Doppelte Agenten, die dieselbe Aufgabe erledigen, verschwenden Kapazität.
OpenClaw serialisiert Läufe bereits pro Session und begrenzt die globale Parallelität über die Befehlswarteschlange. Spezialisten-Lanes ergänzen darüber eine Policy: welcher Agent welche Arbeit besitzt, was im Chat bleibt und was zu Hintergrundarbeit wird.

​
Empfohlener Rollout

​
Phase 1: Lane-Verträge + umfangreiche Hintergrundarbeit

Geben Sie jeder Lane einen schriftlichen Vertrag in ihrem Workspace und System-Prompt:
  • Zweck: die Arbeit, für die diese Lane zuständig ist.
  • Nicht-Ziele: Arbeit, die sie weitergeben sollte, statt sie selbst zu versuchen.
  • Chatbudget: Schnelle Antworten bleiben im Chat; lange Aufgaben sollten kurz bestätigt und dann in einem Hintergrund-Sub-Agent oder einer Aufgabe ausgeführt werden.
  • Übergaberegel: Wenn eine andere Lane für die Arbeit zuständig ist, sagen Sie, wohin sie gehen sollte, und geben Sie eine kompakte Übergabezusammenfassung.
  • Tool-Risikoregel: Bevorzugen Sie die kleinste Tool-Oberfläche, die die Aufgabe erledigen kann.
Dies ist die günstigste Phase und behebt die meisten Blockaden: Ein Coding-Job macht die Research-Lane nicht mehr zäh, und jeder Chat hält seinen eigenen Kontext sauber.

​
Phase 2: Prioritäts- und Nebenläufigkeitssteuerung

Stimmen Sie Warteschlange und Modellkapazität auf den geschäftlichen Wert jeder Lane ab: 
{
  agents: {
    defaults: {
      maxConcurrent: 4,
      subagents: { maxConcurrent: 8, delegationMode: "prefer" },
    },
  },
  messages: {
    queue: {
      mode: "collect",
      debounceMs: 1000,
      cap: 20,
      drop: "summarize",
    },
  },
}
Verwenden Sie direkte/persönliche Chats und Production-Ops-Agenten für Arbeit mit hoher Priorität. Lassen Sie Recherche, Entwürfe und Batch-Coding in Hintergrundaufgaben wechseln, wenn das System ausgelastet ist.

​
Phase 3: Koordinator / Traffic-Controller

Fügen Sie ein kleines Koordinatormuster hinzu, sobald mehrere Lanes aktiv sind:
  • Aktive Lane-Aufgaben und Zuständige nachverfolgen.
  • Doppelte Anfragen über Gruppen hinweg erkennen.
  • Übergabezusammenfassungen zwischen Lanes weiterleiten.
  • Nur Blocker, abgeschlossene Ergebnisse und Entscheidungen anzeigen, die der Mensch treffen muss.
Beginnen Sie nicht hier. Ein Koordinator ohne Lane-Verträge koordiniert nur Chaos.

​
Minimale Vorlage für Lane-Verträge

# 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.

​
Verwandte Themen