Configuración de proveedores personalizados y desafíos de memoria entre agentes con OpenClaw para ejecutar múltiples agentes de codificación de IA

Un desarrollador en r/openclaw comparte su experiencia ejecutando múltiples agentes de codificación a través de OpenClaw usando un proveedor de API de terceros para evitar los límites de tasa y costos de Anthropic. Configuraron un proveedor personalizado en openclaw.json con DeepInfra, establecieron el token de API en .zshrc y reiniciaron la puerta de enlace.

Problemas y Soluciones

1. Fallo de resolución de clave API: openclaw doctor mostró "falló la resolución de apiKey" porque la variable de entorno no estaba en el ámbito del daemon. Se solucionó agregando export a /etc/environment (en todo el sistema) y reiniciando todo el sistema, no solo la puerta de enlace.

2. Timeout de DeepSeek V4 Pro: Las primeras solicitudes agotaron el tiempo de espera con más de 120 segundos de TTFT en modo de razonamiento máximo. El valor predeterminado LLM_REQUEST_TIMEOUT=60 de OpenClaw terminaba las solicitudes antes de que el modelo terminara de pensar. Se aumentó a LLM_REQUEST_TIMEOUT=180 en .env.

3. Caché de contexto no funcionaba: El proveedor soporta almacenamiento en caché, pero OpenClaw requiere los valores cacheRead y cacheWrite en el bloque de costos de la configuración del proveedor. Después de agregarlos, los aciertos de caché aparecieron en los registros a partir de la segunda solicitud con contenido MEMORY.md idéntico.

Configuración Actual

• Agente backend: DeepSeek V4 Pro
• Agente frontend: Qwen3.5 122B A10B
• Agente de migración: V4 Flash

Problema de Aislamiento de Memoria entre Agentes

Cada agente tiene su propio archivo memory.md en el espacio de trabajo, pero no pueden hacer referencia a las memorias de otros cuando es necesario. Por ejemplo, el agente backend escribe un cambio de esquema en su memoria; el agente de migración comienza más tarde y no tiene conocimiento de esa decisión. Vincular simbólicamente los archivos de memoria causa conflictos de bloqueo de archivos porque el administrador de memoria de OpenClaw usa bloqueos de archivos que chocan cuando varios agentes acceden al mismo archivo simultáneamente. El sistema de archivos plano de OpenClaw carece de consultas de memoria entre agentes integradas.

El autor pide soluciones que no impliquen migrar a una base de datos vectorial (p. ej., ChromaDB) y considera escribir una habilidad personalizada que lea los archivos de memoria de otros agentes y muestre el contexto relevante.