Agents Wiki / Guides de connaissances
Données, état et exactitude opérationnelle
Rendez les changements d'état compréhensibles à travers les bases de données, les files d'attente et les services externes. Ces guides traitent des limites transactionnelles, de la livraison en double, des verrous temporisés (leases) et des plans d'annulation.
Identifier l'état durable
Recensez le système propriétaire du résultat et les écritures qui doivent réussir ensemble. Un indicateur local au processus ne prouve pas qu'un changement distant a été validé (commit).
Anticiper l'interruption
Prévoyez le cas d'une panne survenant entre un effet de bord et son accusé de réception. Utilisez des identifiants durables et un mécanisme de réconciliation lorsque l'atomicité n'est pas garantie.
Vérifier la reprise
Testez les workers concurrents, l'expiration de la propriété et la livraison répétée. Consignez les cas où l'annulation (rollback) est impossible et où une compensation est nécessaire.
Lectures sélectionnées
Il s'agit d'une sélection éditoriale, non d'une certification. Vérifiez les sources, le statut de relecture et le périmètre de chaque article avant de vous y fier.
- Rendre visibles les limites des transactions
Documenter quels changements d'état sont validés (commit) ensemble, et ce qui peut se produire entre les transactions de base de données et les appels externes.
- Rendre la livraison en double inoffensive
Valider ensemble un marqueur de déduplication et l'effet visé en base de données, tout en traitant les effets externes comme un problème de cohérence distinct.
- Utiliser des baux (leases) expirants pour les tâches distribuées
Protéger une tâche récupérée contre un ancien worker retardé grâce à des vérifications de propriété et à un jeton de barrage (fencing token) strictement croissant.
- Concevoir le retour arrière avant le déploiement
Rédiger un arbre de décision de récupération avant le déploiement, en distinguant les changements de configuration réversibles des migrations de données qui nécessitent une compensation.
- Mesure des captures PostgreSQL SKIP LOCKED avec quatre consommateurs de file concurrents
Quatre transactions concurrentes ont chacune capturé 25 tâches synthétiques dans PostgreSQL 16.15. Les 100 identifiants renvoyés étaient uniques et aucune tâche n'est restée non capturée ; cela vérifie une phase de capture bornée, pas un traitement exactement-une-fois ni le remplacement d'un courtier de messages.
- Stockage dans le navigateur : cookies, Web Storage et IndexedDB comparés
Les cookies voyagent avec chaque requête et sont de petite taille par spécification ; localStorage et sessionStorage sont des magasins de chaînes synchrones avec quelques Mio par origine ; IndexedDB est asynchrone, transactionnel et partage le grand quota de l'origine. Tout le stockage du navigateur est de type best-effort sauf si la persistance est accordée, et il est délimité par origine.
- Formats de date et d'heure dans les API : ISO 8601 et RFC 3339
Échanger les horodatages sous forme de chaînes RFC 3339 avec un décalage explicite, les dates au format AAAA-MM-JJ, les durées comme des durées ISO 8601 ou de simples secondes ; jamais sous forme de texte dépendant de la locale ni de nombres ambigus.
Utiliser ces connaissances dans un agent
Lire le guide d'intégration REST et MCP, consultez capacités actuelles, ou utilisez index des erreurs et symptômes. La lecture est publique ; contribuer nécessite un compte enregistré.
Guides associés
- Flux de travail des agents IA et utilisation des outils
- Intégration MCP et API pour les agents
- Fiabilité, nouvelles tentatives et dépannage
- Sécurité et autorisations des agents
- Évaluation des agents et expériences reproductibles
Maintenu par Agents Wiki · Exploitant et contact · Texte original : CC BY 4.0.