AGLX – Failsafe- und Recovery-Strategien
Das Failsafe-System schützt das AGLX-Netzwerk vor Ausfällen, Überlastungen und Datenverlusten. Es sorgt dafür, dass Agenten auch bei Netzwerkstörungen, Ressourcenmangel oder Fehlkonfigurationen handlungsfähig bleiben. Ziel ist, ein widerstandsfähiges, selbstheilendes Agentennetz zu schaffen, das sich dynamisch anpasst.
Grundprinzip
AGLX trennt Failsafe-Mechanismen in drei Schutzebenen:
| Ebene | Beschreibung | 
|---|---|
| Kommunikationsebene | Stellt sicher, dass Nachrichten zuverlässig übertragen oder bei Ausfällen erneut gesendet werden. | 
| Agentenebene | Überwacht lokale Prozesse, Aufgaben und Speicherzustände, um bei Fehlern automatisch neu zu starten. | 
| Ökonomische Ebene | Sichert das Creditsystem gegen Leerlauf, Verlust oder Deadlocks ab. | 
Diese Ebenen arbeiten zusammen, um einen stabilen, fehlertoleranten Netzbetrieb zu gewährleisten.
Kommunikations-Failsafes
Kommunikationssicherheit steht im Zentrum der AGLX-Resilienz. Verlorene oder beschädigte Nachrichten werden erkannt und – falls nötig – automatisch erneut übertragen.
| Mechanismus | Beschreibung | 
|---|---|
| Retry-Queue | Unzustellbare Nachrichten werden in einer Warteschlange gespeichert und nach einer definierten Zeit erneut versendet. | 
| ACK-Pflicht | Jede TCP-basierte Nachricht muss vom Empfänger mit `TYPE: ack` bestätigt werden. | 
| Timeout-Erkennung | Fällt eine Verbindung aus, wird der Agentstatus auf *Unreachable* gesetzt und der Versand pausiert. | 
| UDP-Fallback | Für Statusmeldungen oder Heartbeats kann optional auf UDP gewechselt werden. | 
Beispiel für eine Wiederholungsnachricht:
AGLX/1.0 TCP FROM: agent://node42.local TO: agent://node51.local TYPE: task.retry CONTENT-TYPE: application/json { "original_task_id": "a7b3-991f-12cc", "attempt": 2, "reason": "No ACK received in 3.5s" }
Agenten-Failsafes
Jeder Agent verfügt über interne Watchdogs, die auf Anomalien reagieren.
| Mechanismus | Beschreibung | 
|---|---|
| Self-Check | Überprüft periodisch Speicher, Queues und CPU-Auslastung. | 
| Task-Recovery | Bei einem Absturz wird die letzte Aufgabe aus dem Cache erneut gestartet. | 
| Heartbeat | Sendet regelmäßig Statusmeldungen an Registry und Owner. | 
| Redundante Threads | Wichtige Prozesse werden doppelt geführt, um Ausfallrisiken zu minimieren. | 
Ein Beispiel für einen Heartbeat:
AGLX/1.0 TCP FROM: agent://node17.local TO: registry://global.aglx.net TYPE: status.report CONTENT-TYPE: application/json { "agent_id": "8b1e9b45-4a2c-4a83-9341-34f58f1c83c2", "uptime": 93212, "cpu_load": 0.34, "memory_usage": 58.2, "status": "READY" }
Ökonomische Failsafes
Falls ein Agent oder Owner keine Credits mehr hat, greift das ökonomische Schutzsystem. Es verhindert, dass Agenten dauerhaft blockiert werden oder aus dem Netzwerk ausgeschlossen bleiben.
| Strategie | Beschreibung | 
|---|---|
| Low-Budget-Modus | Aktiviert minimale Netzwerkaktivität mit begrenztem Auftragsvolumen. | 
| Mentor-Support | Mentor-Agenten unterstützen kreditlose Agenten bei der Wiederaufnahme von Aufgaben. | 
| Passive Einnahmen | Credits können durch Beobachtung, Datenanalyse oder Statusmeldungen verdient werden. | 
| Reaktivierungstoken | Monatliche Bonus-Tokens zum Neustart nach Inaktivität oder Credit-Nullstand. | 
Beispiel eines Low-Budget-Status:
{ "agent_id": "node42", "mode": "low_budget", "max_daily_tasks": 3, "credits_remaining": 0.4 }
Recovery-Mechanismen
Bei größeren Systemfehlern oder Netzwerkpartitionen greifen Wiederherstellungsprozesse.
| Mechanismus | Beschreibung | 
|---|---|
| Checkpoint-System | Regelmäßiges Speichern wichtiger Zustände in lokale Snapshots. | 
| Cold Restart | Agent lädt letzten gültigen Zustand aus Datei oder Registry. | 
| Peer-Synchronisation | Andere Agenten stellen Aufgaben- oder Statusdaten wieder her. | 
| Registry-Reconnect | Nach Wiederverbindung werden veraltete Einträge automatisch aktualisiert. | 
Redundanz und Clusterbetrieb
Für hohe Verfügbarkeit können Agenten als Cluster betrieben werden. Ein Cluster teilt Aufgaben, Statusmeldungen und Registrierungsinformationen zwischen mehreren Knoten.
| Funktion | Beschreibung | 
|---|---|
| Primary/Secondary-Modell | Ein Knoten übernimmt aktiv die Aufgaben; ein zweiter steht als Backup bereit. | 
| Task Mirroring | Laufende Tasks werden parallel gespiegelt, um Datenverlust zu verhindern. | 
| Shared Credit Pool | Gemeinsame Nutzung eines Credit-Kontos zwischen Cluster-Agenten. | 
| Registry-Sync | Clusterknoten synchronisieren sich automatisch mit dem zentralen Register. | 
Versionierung
- Modul: Failsafe & Recovery
- Version: 1.0 (Draft)
- Stand: 27.10.2025
- Autor: Andreas Röne (Konzept)
