# Come influiscono le chiamate parallele sull’affidabilità di un coding agent? > Le chiamate parallele riducono la latenza delle letture indipendenti, ma diminuiscono l’affidabilità quando condividono stato, dipendono dall’ordine o scrivono. Usa un grafo di dipendenze, lock, chiavi di idempotenza e unione deterministica invece di parallelizzare tutto. Le chiamate parallele sono una proposta di pianificazione, non il permesso di avviare tutto insieme. Due ricerche possono in genere sovrapporsi; una modifica e un formattatore forse no; installazione e test non devono partire dallo stesso stato precedente. L’affidabilità aumenta quando la concorrenza segue un modello di risorse e dipendenze. Diminuisce quando l’esecutore considera un elenco di chiamate come prova della loro indipendenza. ## Classifica le chiamate per effetto Etichetta ogni strumento con un comportamento che lo scheduler possa imporre. | Classe | Esempio | Politica predefinita | |---|---|---| | Lettura pura | Leggere due file | Parallelo consentito | | Lettura esterna | Interrogare due API | Parallelo con limiti | | Scrittura locale | Modificare un file | Serializzare per risorsa | | Scrittura globale | Installare dipendenze | Serializzare globalmente | | Azione irreversibile | Pubblicare o inviare | Richiedere una porta esplicita | Non fidarti solo dei nomi. `inspect` può creare cache e un test può scrivere snapshot o database. Documenta gli effetti collaterali. ## Costruisci un grafo prima dell’esecuzione Rappresenta le chiamate come nodi e l’ordine richiesto come archi. Una chiamata parte solo quando i predecessori riescono e le risorse sono libere. ```text read_config ----+ +--> build --> test read_source ----+ search_docs ---------> summarize ``` Le due letture possono coincidere. Il build attende entrambe e il test attende il build. La ricerca documentale può sovrapporsi se non influisce sugli input. Se il modello non fornisce dipendenze, deducile in modo prudente da metadati e argomenti. Le scritture ambigue devono essere seriali. ## Blocca le risorse, non l’intero agente Un lock globale è affidabile ma lento; lock per risorsa mantengono una concorrenza sicura. Normalizza i percorsi. Modificare `src/a.ts` confligge con formattare `src`, e generare un lockfile con un’altra operazione sui pacchetti. Includi database, sessioni browser, terminali e record remoti. | Risorsa | Ambito del lock | |---|---| | File sorgente | Percorso canonico | | Formattatore | Sottoalbero della directory | | Gestore pacchetti | Workspace e lockfile | | Sessione browser | Scheda o flusso autenticato | | Distribuzione | Ambiente e servizio | ## Conserva l’identità nel flusso Più chiamate possono produrre frammenti intercalati. Accumula per ID ed esegui solo dopo l’evento finale di ciascuna chiamata. Non usare la posizione come identità permanente. Restituisci i risultati con gli stessi ID opachi e ordinali in modo deterministico, per esempio secondo l’ordine originale, anche se terminano diversamente. Atlas Cloud inoltra `tools`, `tool_choice` e `parallel_tool_calls` per i modelli con strumenti in OpenAI Chat Completions. Controlla modello e protocollo nella [guida 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) invece di presumere compatibilità. ## Definisci una politica per i fallimenti parziali Un batch può contenere una chiamata completa, una non valida e una attiva. Scegli la politica in base all’effetto: * Conserva le letture indipendenti riuscite e segnala l’errore. * Annulla i dipendenti in attesa se un prerequisito fallisce. * Non riprovare una scrittura completata senza chiave di idempotenza. * Compensa solo se lo strumento lo supporta espressamente. * Restituisci al modello un risultato batch strutturato. Il nuovo tentativo deve riguardare il nodo fallito, non ripetere l’intero batch. ## Limita la concorrenza e applica backpressure Anche chiamate indipendenti possono saturare file system, API, runner o limite. Imposta limiti per strumento e risorsa, metti in coda l’eccesso e consenti l’annullamento. Misura la chiamata più lenta, il tempo in coda, i tentativi, i duplicati evitati e il successo finale. Ridurre il tempo conta solo se l’output resta corretto e non compaiono turni extra. ## Testa le pianificazioni, non solo gli output Una race condition può sparire in un solo ordine. Forza sequenze diverse con ritardi. | Test | Ordine forzato | Risultato atteso | |---|---|---| | Due letture | A-B e B-A | Stessa prova unita | | Lettura e scrittura | La scrittura attende | La lettura vede una versione definita | | Due scritture sullo stesso file | Qualsiasi ordine proposto | Un piano serializzato | | Errore e chiamata lenta | Errore prima | Dipendente annullato | | Disconnessione dopo scrittura | Risposta persa | Scrittura non duplicata | Usa un esecutore finto affinché la CI riproduca le pianificazioni senza fortuna. ## Decidi quando il seriale è migliore Migrazioni, installazioni, modifiche condivise, pubblicazioni e operazioni senza rollback chiaro devono essere seriali. Il parallelo funziona per esplorazione, documentazione indipendente, lint isolato e gruppi di test separati. Un modello del [catalogo 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) può proporre più chiamate, ma l’esecutore decide quali possono coincidere. ## Conclusione Le chiamate parallele accelerano il lavoro indipendente e basato su letture, ma riducono l’affidabilità se si ignorano effetti, risorse o ordine. Classifica gli strumenti, crea dipendenze, blocca le risorse, conserva gli ID, riprova nodi idempotenti e testa più sequenze. L’esecutore deve imporre la sicurezza anche quando il modello propone concorrenza. ## FAQ ### Quali chiamate possono essere eseguite in parallelo in sicurezza? Le letture indipendenti su risorse diverse sono le più sicure. Verifica che non modifichino cache, file temporanei o sessioni condivise. ### Le modifiche ai file possono essere parallele? Solo con aree di proprietà separate e unione deterministica. L’esecuzione seriale è più sicura per lo stesso file, artefatti, lockfile o stato di build condiviso. ### Cosa succede se una chiamata parallela fallisce? L’orchestratore deve avere una politica: annullare le chiamate correlate, conservare letture riuscite, compensare scritture completate o riprovare solo chiamate idempotenti. ### Come restituire i risultati al modello? Conserva ogni ID e unisci i risultati in ordine deterministico, con stati espliciti di successo, errore e annullamento. ### Le chiamate parallele possono ridurre i costi? Possono ridurre il tempo, ma aumentare token, lavoro duplicato o tentativi. Misura costo e correttezza separatamente dalla latenza. ### Tutti i modelli supportano chiamate parallele? No. Controlla modello e protocollo; alcune rotte supportano gli strumenti ma non più chiamate nello stesso turno.