# Comment les appels d’outils parallèles affectent-ils la fiabilité d’un agent de code ? > Les appels parallèles réduisent la latence des lectures indépendantes, mais diminuent la fiabilité lorsqu’ils partagent un état, dépendent de l’ordre ou écrivent. Utilisez un graphe de dépendances, des verrous, des clés d’idempotence et une fusion déterministe plutôt que de tout paralléliser. Les appels parallèles sont une proposition de planification, pas une autorisation de tout lancer à la fois. Deux recherches peuvent généralement se chevaucher ; une modification et un formateur, peut-être pas ; une installation et des tests ne doivent pas partir du même état initial. La fiabilité augmente lorsque la concurrence suit un modèle de ressources et de dépendances. Elle baisse lorsque l’exécuteur considère qu’une liste d’appels prouve leur indépendance. ## Classez les appels par effet Étiquetez chaque outil avec un comportement que le planificateur peut imposer. | Classe | Exemple | Politique par défaut | |---|---|---| | Lecture pure | Lire deux fichiers | Parallèle autorisé | | Lecture externe | Interroger deux API | Parallèle avec limites | | Écriture locale | Modifier un fichier | Sérialiser par ressource | | Écriture globale | Installer des dépendances | Sérialiser globalement | | Action irréversible | Publier ou envoyer | Exiger une porte explicite | Ne vous fiez pas aux noms. `inspect` peut créer des caches et un test peut écrire des snapshots ou bases. Documentez les effets secondaires. ## Construisez un graphe avant l’exécution Représentez les appels par des nœuds et l’ordre requis par des arêtes. Un appel ne démarre que lorsque ses prédécesseurs réussissent et que ses ressources sont libres. ```text read_config ----+ +--> build --> test read_source ----+ search_docs ---------> summarize ``` Les deux lectures peuvent coïncider. Le build attend les deux, et le test attend le build. La recherche documentaire peut se chevaucher si elle n’affecte pas les entrées. Si le modèle ne fournit pas les dépendances, déduisez-les prudemment des métadonnées et arguments. Les écritures ambiguës doivent rester séquentielles. ## Verrouillez les ressources, pas tout l’agent Un verrou global est fiable mais lent ; des verrous par ressource conservent une concurrence sûre. Normalisez les chemins avant comparaison. Modifier `src/a.ts` entre en conflit avec le formatage de `src`, et produire un lockfile avec une autre opération de paquets. Incluez bases de données, sessions navigateur, terminaux et enregistrements distants. | Ressource | Portée du verrou | |---|---| | Fichier source | Chemin canonique | | Formateur | Sous-arbre du dossier | | Gestionnaire de paquets | Workspace et lockfile | | Session navigateur | Onglet ou flux authentifié | | Déploiement | Environnement et service | ## Préservez l’identité dans le flux Plusieurs appels peuvent produire des fragments entrelacés. Mettez-les en tampon par ID et exécutez uniquement après l’événement final de chacun. N’utilisez pas la position comme identité permanente. Renvoyez les résultats avec les mêmes IDs opaques et ordonnez-les de façon déterministe, par exemple selon l’ordre original, même s’ils se terminent autrement. Atlas Cloud transmet `tools`, `tool_choice` et `parallel_tool_calls` pour les modèles dotés d’outils sur OpenAI Chat Completions. Vérifiez modèle et protocole dans le [guide LLM](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=how-parallel-tool-calls-change-coding-agent-reliability) au lieu de supposer la compatibilité. ## Définissez une politique d’échec partiel Un lot peut contenir un appel terminé, un autre invalide et un troisième actif. Choisissez la politique selon l’effet : * Conservez les lectures indépendantes réussies et signalez l’échec. * Annulez les dépendants en attente si un prérequis échoue. * Ne réessayez pas une écriture terminée sans clé d’idempotence. * Ne compensez que si l’outil le permet explicitement. * Renvoyez au modèle un résultat de lot structuré. La nouvelle tentative doit viser le nœud en échec, pas rejouer tout le lot. ## Limitez la concurrence et appliquez la backpressure Même des appels indépendants peuvent saturer système de fichiers, API, runner ou limite. Définissez des plafonds par outil et ressource, mettez l’excédent en file et autorisez l’annulation. Mesurez l’appel le plus lent, le temps en file, les tentatives, doublons évités et le succès final. Gagner du temps ne compte que si la sortie reste correcte sans tours supplémentaires. ## Testez les ordonnancements, pas seulement les sorties Une course peut disparaître dans un seul ordre. Forcez des séquences différentes avec des délais. | Test | Ordre forcé | Résultat attendu | |---|---|---| | Deux lectures | A-B et B-A | Même preuve fusionnée | | Lecture et écriture | L’écriture attend | Lecture d’une version définie | | Deux écritures même fichier | Tout ordre proposé | Un plan sérialisé | | Échec et appel lent | Échec d’abord | Dépendant annulé | | Déconnexion après écriture | Réponse perdue | Écriture non dupliquée | Utilisez un faux exécuteur pour que la CI reproduise les ordres sans hasard. ## Décidez quand le séquentiel est préférable Les migrations, installations, modifications partagées, publications et opérations sans rollback clair doivent être séquentielles. Le parallèle convient à l’exploration, la documentation indépendante, le lint isolé et les groupes de tests distincts. Un modèle du [catalogue LLM Atlas Cloud](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=how-parallel-tool-calls-change-coding-agent-reliability) peut proposer plusieurs appels, mais l’exécuteur décide lesquels peuvent coïncider. ## Conclusion Les appels parallèles accélèrent le travail indépendant et centré sur la lecture, mais réduisent la fiabilité si effets, ressources ou ordre sont ignorés. Classez les outils, créez les dépendances, verrouillez les ressources, conservez les IDs, réessayez les nœuds idempotents et testez plusieurs ordres. L’exécuteur doit imposer la sécurité même lorsque le modèle propose la concurrence. ## FAQ ### Quels appels peuvent être exécutés en parallèle sans risque ? Les lectures indépendantes sur des ressources différentes sont les plus sûres. Vérifiez qu’elles ne modifient ni caches, ni fichiers temporaires, ni sessions partagées. ### Les modifications de fichiers peuvent-elles être parallèles ? Seulement si les zones de propriété sont séparées et la fusion déterministe. L’exécution séquentielle est plus sûre pour le même fichier, les artefacts, lockfiles ou l’état de build. ### Que faire si un appel parallèle échoue ? L’orchestrateur doit avoir une politique : annuler les appels associés, conserver les lectures réussies, compenser les écritures ou ne réessayer que les appels idempotents. ### Comment renvoyer les résultats au modèle ? Conservez chaque ID et fusionnez les résultats dans un ordre déterministe, avec des états explicites de réussite, erreur et annulation. ### Les appels parallèles peuvent-ils réduire le coût ? Ils peuvent réduire le temps, mais augmenter les tokens, le travail dupliqué ou les tentatives. Mesurez coût et correction séparément de la latence. ### Tous les modèles prennent-ils en charge les appels parallèles ? Non. Vérifiez modèle et protocole ; certaines routes acceptent les outils, mais pas plusieurs appels dans le même tour.