Saltar al contenido principal
Los carriles especializados paralelos permiten que un Gateway enrute diferentes chats o salas a distintos agentes mientras mantiene rápida la experiencia de usuario. Trata el paralelismo como un problema de diseño de recursos escasos, no solo como “más agentes”.

​
Primeros principios

Un carril especializado solo mejora el rendimiento cuando reduce la contención por los cuellos de botella reales:
  • Bloqueos de sesión: solo una ejecución debería modificar una sesión determinada a la vez.
  • Capacidad global del modelo: todas las ejecuciones de chat visibles siguen compartiendo los límites del proveedor.
  • Capacidad de herramientas: el trabajo con shell, navegador, red y repositorio puede ser más lento que el propio turno del modelo.
  • Presupuesto de contexto: las transcripciones largas hacen que cada turno futuro sea más lento y menos enfocado.
  • Ambigüedad de propiedad: agentes duplicados haciendo el mismo trabajo desperdician capacidad.
OpenClaw ya serializa las ejecuciones por sesión y limita el paralelismo global mediante la cola de comandos. Los carriles especializados añaden una política encima: qué agente es propietario de qué trabajo, qué permanece en el chat y qué se convierte en trabajo en segundo plano.

​
Despliegue recomendado

​
Fase 1: contratos de carril + trabajo pesado en segundo plano

Dale a cada carril un contrato escrito en su espacio de trabajo y prompt del sistema:
  • Propósito: el trabajo del que este carril es propietario.
  • No objetivos: trabajo que debería transferir en lugar de intentar.
  • Presupuesto de chat: las respuestas rápidas permanecen en el chat; las tareas largas se reconocen brevemente, y luego se ejecutan en un subagente o tarea en segundo plano.
  • Regla de transferencia: cuando otro carril sea propietario del trabajo, indica adónde debería ir y proporciona un resumen compacto de transferencia.
  • Regla de riesgo de herramientas: prefiere la superficie de herramientas más pequeña que pueda hacer el trabajo.
Esta es la fase más económica y soluciona la mayoría de los atascos: un trabajo de programación ya no convierte el carril de investigación en melaza, y cada chat mantiene limpio su propio contexto.

​
Fase 2: controles de prioridad y concurrencia

Ajusta la cola y la capacidad del modelo en torno al valor de negocio de cada carril: 
{
  agents: {
    defaults: {
      maxConcurrent: 4,
      subagents: { maxConcurrent: 8, delegationMode: "prefer" },
    },
  },
  messages: {
    queue: {
      mode: "collect",
      debounceMs: 1000,
      cap: 20,
      drop: "summarize",
    },
  },
}
Usa chats directos/personales y agentes de operaciones de producción para el trabajo de alta prioridad. Deja que la investigación, la redacción y la programación por lotes pasen a tareas en segundo plano cuando el sistema esté ocupado.

​
Fase 3: coordinador / controlador de tráfico

Añade un pequeño patrón de coordinador cuando haya varios carriles activos:
  • Haz seguimiento de las tareas y propietarios activos de los carriles.
  • Detecta solicitudes duplicadas entre grupos.
  • Enruta resúmenes de transferencia entre carriles.
  • Muestra solo bloqueadores, resultados completados y decisiones que deba tomar la persona.
No empieces aquí. Un coordinador sin contratos de carril solo coordina el caos.

​
Plantilla mínima de contrato de carril

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

​
Relacionado