Mehrere KI-Codierungsagenten mit OpenClaw ausführen: Einrichtung benutzerdefinierter Anbieter & Herausforderungen des agentenübergreifenden Gedächtnisses

Ein Entwickler auf r/openclaw teilt seine Erfahrungen mit der Ausführung mehrerer Coding-Agenten über OpenClaw unter Verwendung eines Drittanbieter-API-Providers, um die Ratenbegrenzungen und Kosten von Anthropic zu umgehen. Er konfigurierte einen benutzerdefinierten Provider in openclaw.json mit DeepInfra, setzte den API-Token in .zshrc und startete das Gateway neu.

Probleme und Lösungen

1. Fehlgeschlagene API-Schlüsselauflösung: openclaw doctor zeigte „apiKey resolution failed“, da die Umgebungsvariable nicht im Gültigkeitsbereich des Daemons lag. Behoben durch Hinzufügen von export in /etc/environment (systemweit) und Neustart des gesamten Systems, nicht nur des Gateways.

2. Timeout bei DeepSeek V4 Pro: Die ersten Anfragen liefen mit über 120 Sekunden TTFT im maximalen Denkmodus in einen Timeout. OpenClaws Standardwert LLM_REQUEST_TIMEOUT=60 brach Anfragen ab, bevor das Modell die Überlegungen abgeschlossen hatte. Erhöht auf LLM_REQUEST_TIMEOUT=180 in .env.

3. Context Caching funktionierte nicht: Der Provider unterstützt Caching, aber OpenClaw benötigt die Werte cacheRead und cacheWrite im Kostenblock der Providerkonfiguration. Nachdem diese hinzugefügt wurden, erschienen Cache-Treffer ab der zweiten Anfrage mit identischem MEMORY.md-Inhalt in den Logs.

Aktuelle Konfiguration

• Backend-Agent: DeepSeek V4 Pro
• Frontend-Agent: Qwen3.5 122B A10B
• Migrations-Agent: V4 Flash

Problem der speicherübergreifenden Isolation zwischen Agenten

Jeder Agent hat seine eigene memory.md-Datei im Arbeitsbereich, kann aber bei Bedarf nicht auf die Speicher der anderen zugreifen. Beispielsweise schreibt der Backend-Agent eine Schemaänderung in seinen Speicher; der Migrations-Agent startet später und hat keine Kenntnis davon. Symlinking der Speicherdateien führt zu Dateisperrkonflikten, da OpenClaws Speicherverwalter Dateisperren verwendet, die bei gleichzeitigem Zugriff mehrerer Agenten auf dieselbe Datei kollidieren. OpenClaws flaches Dateisystem unterstützt keine integrierten abteilungsübergreifenden Speicherabfragen.

Der Autor fragt nach Lösungen, die nicht den Wechsel zu einer Vektordatenbank (z.B. ChromaDB) erfordern, und erwägt, eine benutzerdefinierte Fähigkeit zu schreiben, die die Speicherdateien anderer Agenten liest und relevanten Kontext bereitstellt.