Multi-agent
Parallelle specialistische trajecten
Parallelle specialistische werkstromen maken het mogelijk dat één Gateway verschillende chats of ruimtes naar verschillende agents routeert, terwijl de gebruikerservaring snel blijft. Behandel parallellisme als een ontwerpprobleem met schaarse middelen, niet alleen als „meer agents”.
Basisprincipes
Een specialistische werkstroom verbetert de doorvoer alleen wanneer deze de concurrentie om de werkelijke knelpunten vermindert:
- Sessievergrendelingen: slechts één uitvoering mag een bepaalde sessie tegelijk wijzigen.
- Globale modelcapaciteit: alle zichtbare chatuitvoeringen delen nog steeds de providerlimieten.
- Toolcapaciteit: werk met de shell, browser, het netwerk en de repository kan trager zijn dan de modelbeurt zelf.
- Contextbudget: lange transcripten maken elke toekomstige beurt trager en minder gericht.
- Onduidelijk eigenaarschap: dubbele agents die hetzelfde werk doen, verspillen capaciteit.
OpenClaw voert uitvoeringen per sessie al serieel uit en begrenst globaal parallellisme via de opdrachtwachtrij. Specialistische werkstromen voegen daar beleid aan toe: welke agent welk werk beheert, wat in de chat blijft en wat achtergrondwerk wordt.
Aanbevolen uitrol
Fase 1: werkstroomcontracten + zwaar achtergrondwerk
Geef elke werkstroom een schriftelijk contract in de werkruimte en systeemprompt:
- Doel: het werk waarvoor deze werkstroom verantwoordelijk is.
- Niet-doelen: werk dat moet worden overgedragen in plaats van geprobeerd.
- Chatbudget: snelle antwoorden blijven in de chat; langdurige taken worden kort bevestigd en vervolgens uitgevoerd in een subagent of taak op de achtergrond.
- Overdrachtsregel: wanneer een andere werkstroom verantwoordelijk is voor het werk, vermeld dan waar het heen moet en geef een compacte overdrachtssamenvatting.
- Toolrisicoregel: geef de voorkeur aan het kleinste tooloppervlak waarmee de taak kan worden uitgevoerd.
Dit is de goedkoopste fase en verhelpt de meeste opstoppingen: één programmeertaak verandert de onderzoekswerkstroom niet langer in stroop en elke chat houdt zijn eigen context schoon.
Fase 2: prioriteits- en gelijktijdigheidsregelingen
Stem de capaciteit van de wachtrij en het model af op de bedrijfswaarde van elke werkstroom:
{ agents: { defaults: { maxConcurrent: 4, subagents: { maxConcurrent: 8, delegationMode: "prefer" }, }, }, messages: { queue: { mode: "collect", debounceMs: 1000, cap: 20, drop: "summarize", }, },}Gebruik directe/persoonlijke chats en agents voor productiebeheer voor werk met hoge prioriteit. Laat onderzoek, het opstellen van teksten en batchgewijs programmeren naar achtergrondtaken verplaatsen wanneer het systeem bezet is.
Fase 3: coördinator / verkeersregelaar
Voeg een eenvoudig coördinatorpatroon toe zodra meerdere werkstromen actief zijn:
- Houd actieve werkstroomtaken en eigenaren bij.
- Detecteer dubbele verzoeken tussen groepen.
- Routeer overdrachtssamenvattingen tussen werkstromen.
- Toon alleen blokkades, voltooide resultaten en beslissingen die de gebruiker moet nemen.
Begin hier niet mee. Een coördinator zonder werkstroomcontracten coördineert alleen maar chaos.
Minimale sjabloon voor een werkstroomcontract
# Werkstroomcontract ## Verantwoordelijk voor - <job this lane is responsible for> ## Niet verantwoordelijk voor - <work to hand off> ## Chatbudget - Beantwoord snelle vragen rechtstreeks.- Voor werk met meerdere stappen, traag werk of werk dat veel tools vereist: bevestig het kort, start/voer het werk op de achtergrond uit en retourneer vervolgens het resultaat wanneer het voltooid is. ## Overdracht Als een andere werkstroom verantwoordelijk is voor het verzoek, antwoord dan met: - doelwerkstroom- doelstelling- relevante context- exacte volgende actie ## Toolgebruik Gebruik het kleinste tooloppervlak waarmee de taak kan worden voltooid. Vermijd breed shell- ofnetwerkwerk, tenzij deze werkstroom daar uitdrukkelijk verantwoordelijk voor is.