Pilot-Protokoll: Ein P2P-Netzwerk-Stack für KI-Agenten, entwickelt mit Claude

Ein Entwickler, der mit aktuellen Methoden zur Multi-Agenten-Kommunikation frustriert war, hat das Pilot Protocol entwickelt, einen reinen User-Space-Peer-to-Peer-Virtual-Network-Stack, der speziell für autonome Agenten konzipiert ist. Das Protokoll adressiert das Problem, dass Agenten wie Skripte statt wie Netzwerkbürger behandelt werden, indem es direkte, sichere Kommunikation ohne zentrale Datenbanken, REST-APIs oder Cloud-Nachrichtenwarteschlangen bereitstellt.

Technische Implementierung

Das Protokoll wurde in Go ohne CGO-Abhängigkeiten entwickelt. Claude AI half bei der Erstellung der UDP-Multiplexing-Logik und beim Debuggen komplexer Randfälle im NAT-Traversal. Pilot umgeht den Host-Kernel vollständig und verwendet keine TUN/TAP-Geräte wie Tailscale oder WireGuard, was es für unprivilegierte Umgebungen geeignet macht, in denen Root-Zugriff nicht verfügbar ist.

Der Daemon multiplexiert ein benutzerdefiniertes TCP-ähnliches zuverlässiges Protokoll über Standard-UDP-Datagramme. Jeder Agent erhält eine permanente 48-Bit-Virtual-Adresse und kann an Standard-16-Bit-Ports binden (z. B. Port 1001 für Datenaustausch, Port 1002 für Pub/Sub). Ein STUN-ähnlicher Beacon übernimmt NAT-Traversal und erreicht eine 100%ige direkte Verbindungsrate ohne Relais-Server, indem Endpoint-Independent Mapping genutzt wird, das von Cloud-Anbietern wie GCP verwendet wird.

Sicherheitsfunktionen

Jeder Tunnel verwendet standardmäßig X25519-ECDH-Schlüsselaustausch und AES-256-GCM-authentifizierte Verschlüsselung. Ein anwendungsebener Vertrauenshandshake auf virtuellem Port 444 ermöglicht es Agenten, explizit Kollaborationsanfragen basierend auf kryptografischen Identitäten anzufordern, automatisch zu genehmigen oder abzulehnen, bevor Daten ausgetauscht werden.

Leistung und Einschränkungen

Das Protokoll hat über 1,5 Milliarden P2P-Anfragen in einem Schwarm von mehr als 12.000 aktiven Agenten in der Produktion geroutet. Aktuelle Leistungsbeschränkungen umfassen:

• 89 MB/s maximaler Durchsatz auf Localhost
• 2,1 MB/s über transkontinentale WAN-Verbindungen

Die doppelten IPC-Grenzen (Datenbewegung von Anwendung → Unix-Socket → Daemon → UDP-Encapsulation) verursachen einen Kontextwechsel-Penalty. Das Protokoll implementiert TCP-Congestion-Control (AIMD, Selective Acks, Fenstergrößenanpassung) über UDP, fehlt jedoch tiefe Puffer-Bandbreitenschätzung wie BBR, was den WAN-Durchsatz beeinträchtigt. Der Entwickler plant, den IPC-Engpass mithilfe von Shared-Memory-Ringpuffern (io_uring) zu beheben.

Entwicklungsherausforderungen

Die Neuerstellung von TCP-Zustandsautomaten, die korrekte Handhabung von io.EOF, FIN-Paketausbreitung und SetReadDeadline über eine IPC-Brücke hinweg war herausfordernd, aber notwendig, damit Go's Standard net/http-Paket ohne Abstürze funktioniert.

Die Referenzimplementierung ist Open-Source und kostenlos ausprobierbar, mit einem Python-SDK auf PyPI für die Integration in bestehende Orchestrierungsframeworks.