Construire un pipeline de livraison sécurisé pour les agents
La plupart des démos d'agents passent à côté d'une question vitale. Comment permettre à un système autonome d'envoyer des éléments en votre nom sans risque de double envoi ou d'expédition de travaux non approuvés ?
Un double envoi n'est pas une erreur rare. C'est le comportement par défaut d'une file d'attente simple lorsqu'un worker plante en pleine tâche. Un worker envoie un message, puis plante avant d'avoir enregistré le succès. Le système pense que la tâche a échoué et demande à un nouveau worker de réessayer. Le client reçoit deux e-mails et vous recevez un ticket de support.
Vous ne pouvez pas prévenir chaque plantage. Vous devez concevoir votre système pour qu'il gère un plantage survenant dans l'intervalle entre l'action et l'enregistrement.
Utilisez ce pipeline en six étapes pour tout résultat d'agent ayant des conséquences réelles :
• Produire : L'agent génère l'artefact complet. Il n'envoie rien pour l'instant. • Persister : Écrivez d'abord l'intention et l'artefact dans un stockage durable. • Évaluer : Attachez un score de confiance au résultat. • Réviser : Dirigez les éléments à faible indice de confiance vers un humain. • Approuver : Utilisez une barrière de type "fail-closed" (échec par défaut). Le système bloque tous les envois à moins qu'un humain ne donne une autorisation explicite. • Envoyer et attester : Envoyez l'élément sous un bail (lease), puis écrivez un reçu de preuve.
Chaque étape doit être une transition durable distincte. L'état réside dans votre base de données, pas dans la mémoire d'un worker.
Pour éviter les doublons, utilisez le verrouillage au niveau de la ligne (row-level leasing). Dans Postgres, utilisez SELECT ... FOR UPDATE SKIP LOCKED. Cela garantit qu'un seul worker possède une tâche à la fois.
La règle la plus importante est la gestion des baux (leases) expirés. Si un worker plante pendant l'envoi d'un message externe, ne le réessayez pas automatiquement. À la place, laissez la tâche en suspens pour une révision humaine. Une tâche bloquée visible vaut mieux qu'un double envoi invisible.
Vous devez également suivre les principes du "fail-closed" :
- L'envoi est désactivé par défaut. Un seul indicateur (flag) doit activer tout le trafic sortant.
- L'identité est vérifiée. Le système doit vérifier l'adresse de l'expéditeur et la sécurité du transport au moment de l'envoi.
- Tout laisse un reçu. Un envoi non enregistré est un échec.
Ne construisez pas cela pour des tâches à faible enjeu comme des journaux internes. Utilisez-le lorsqu'une erreur coûte de l'argent, crée un problème juridique ou nécessite un ticket de support.
Optional learning community: https://t.me/GyaanSetuAi