Protocole Pilot : Une pile réseau P2P pour les agents IA construite avec Claude

Un développeur frustré par les méthodes actuelles de communication multi-agents a créé Pilot Protocol, une pile réseau virtuelle purement en espace utilisateur et pair-à-pair, conçue spécifiquement pour les agents autonomes. Le protocole résout le problème des agents traités comme des scripts plutôt que comme des citoyens du réseau en fournissant une communication directe et sécurisée sans bases de données centralisées, API REST ou files d'attente de messages dans le cloud.

Implémentation technique

Le protocole a été construit en Go sans aucune dépendance CGO. L'IA Claude a aidé à écrire la logique de multiplexage UDP et à déboguer des cas limites complexes dans la traversée NAT. Pilot contourne entièrement le noyau de l'hôte et n'utilise pas de périphériques TUN/TAP comme Tailscale ou WireGuard, le rendant adapté aux environnements non privilégiés où l'accès root n'est pas disponible.

Le démon multiplexe un protocole fiable personnalisé de type TCP sur des datagrammes UDP standard. Chaque agent obtient une adresse virtuelle permanente de 48 bits et peut se lier à des ports 16 bits standard (par exemple, Port 1001 pour l'échange de données, Port 1002 pour pub/sub). Une balise de type STUN gère la traversée NAT, atteignant un taux de réussite de connexion directe de 100 % sans serveurs relais en exploitant le mappage indépendant des points de terminaison utilisé par des fournisseurs cloud comme GCP.

Fonctionnalités de sécurité

Chaque tunnel utilise par défaut un échange de clés ECDH X25519 et un chiffrement authentifié AES-256-GCM. Une poignée de main de confiance au niveau de l'application sur le port virtuel 444 permet aux agents de demander explicitement, d'approuver automatiquement ou de rejeter des demandes de collaboration basées sur des identités cryptographiques avant d'échanger des données.

Performances et limitations

Le protocole a acheminé plus de 1,5 milliard de requêtes P2P à travers un essaim de plus de 12 000 agents actifs en production. Les limitations de performance actuelles incluent :

• 89 Mo/s de débit maximum en localhost
• 2,1 Mo/s sur des liaisons WAN transcontinentales

Les doubles frontières IPC (déplacer les données de l'Application → Socket Unix → Démon → Encapsulation UDP) créent une pénalité de changement de contexte. Le protocole implémente le contrôle de congestion TCP (AIMD, accusés de réception sélectifs, dimensionnement de fenêtre) sur UDP mais manque d'estimation de bande passante à tampon profond comme BBR, ce qui nuit au débit WAN. Le développeur prévoit de corriger le goulot d'étranglement IPC en utilisant des tampons en anneau en mémoire partagée (io_uring).

Défis de développement

Recréer des machines d'état TCP, gérer io.EOF, la propagation des paquets FIN et SetReadDeadline avec précision à travers un pont IPC était difficile mais nécessaire pour que le package net/http standard de Go fonctionne sans planter.

L'implémentation de référence est open-source et gratuite à essayer, avec un SDK Python disponible sur PyPI pour l'intégration dans des frameworks d'orchestration existants.