# Como chamadas paralelas afetam a confiabilidade de agentes de programação? > Chamadas paralelas reduzem a latência de leituras independentes, mas diminuem a confiabilidade quando compartilham estado, dependem da ordem ou escrevem. Use grafo de dependências, bloqueios, chaves de idempotência e combinação determinística em vez de paralelizar tudo. Chamadas paralelas são uma proposta de agendamento, não permissão para iniciar tudo de uma vez. Duas buscas geralmente podem se sobrepor; uma edição e um formatador talvez não; instalação e testes não devem partir juntos do mesmo estado anterior. A confiabilidade aumenta quando a concorrência segue um modelo de recursos e dependências, e cai quando o executor considera que uma lista de chamadas prova independência. ## Classifique chamadas por efeito Marque cada ferramenta com um comportamento que o agendador possa impor. | Classe | Exemplo | Política padrão | |---|---|---| | Leitura pura | Ler dois arquivos | Paralelo permitido | | Leitura externa | Consultar duas APIs | Paralelo com limites | | Escrita local | Editar um arquivo | Serializar por recurso | | Escrita global | Instalar dependências | Serializar globalmente | | Ação irreversível | Publicar ou enviar | Exigir porta explícita | Não confie apenas em nomes. `inspect` pode criar caches e um teste pode gravar snapshots ou bancos. Documente os efeitos colaterais. ## Construa um grafo antes de executar Represente chamadas como nós e a ordem exigida como arestas. Uma chamada começa apenas quando suas predecessoras terminam e os recursos estão livres. ```text read_config ----+ +--> build --> test read_source ----+ search_docs ---------> summarize ``` As duas leituras podem coincidir. O build espera ambas, e o teste espera o build. A busca de documentação pode ocorrer em paralelo se não afetar as entradas. Quando o modelo não informar dependências, infira-as de forma conservadora pelos metadados e argumentos. Escritas ambíguas devem ser seriais. ## Bloqueie recursos, não o agente inteiro Um bloqueio global é confiável, mas lento; bloqueios por recurso mantêm concorrência segura. Normalize caminhos antes de comparar. Editar `src/a.ts` conflita com formatar `src`, e gerar um lockfile conflita com outra operação de pacotes. Inclua bancos, sessões de navegador, terminais e registros remotos. | Recurso | Escopo do bloqueio | |---|---| | Arquivo-fonte | Caminho canônico | | Formatador | Subárvore do diretório | | Gerenciador de pacotes | Workspace e lockfile | | Sessão do navegador | Aba ou fluxo autenticado | | Implantação | Ambiente e serviço | ## Preserve a identidade no stream Várias chamadas podem emitir fragmentos intercalados. Armazene por ID e execute apenas após o evento final de cada chamada. Não use a posição como identidade permanente. Devolva resultados com os mesmos IDs opacos e ordene-os de forma determinística, por exemplo pela ordem original, mesmo se terminarem em outra sequência. A Atlas Cloud transmite `tools`, `tool_choice` e `parallel_tool_calls` para modelos com ferramentas no OpenAI Chat Completions. Confira o modelo e protocolo no [guia 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), em vez de presumir compatibilidade. ## Defina uma política de falha parcial Um lote pode ter uma chamada concluída, outra inválida e outra ativa. Escolha a política conforme o efeito: * Mantenha leituras independentes corretas e relate a falha. * Cancele dependentes pendentes se um requisito falhar. * Não repita uma escrita concluída sem chave de idempotência. * Compense somente se a ferramenta oferecer suporte explícito. * Devolva ao modelo um resultado estruturado do lote. A nova tentativa deve mirar o nó com falha, não repetir todo o lote. ## Limite concorrência e aplique backpressure Até chamadas independentes podem saturar sistema de arquivos, API, runner ou limite. Defina limites por ferramenta e recurso, coloque o excesso em fila e permita cancelamento. Meça a chamada mais lenta, tempo em fila, tentativas, duplicações evitadas e sucesso final. Reduzir tempo só importa se a saída continuar correta e não surgirem turnos extras. ## Teste agendamentos, não só resultados Uma corrida pode desaparecer em uma única ordem. Force sequências diferentes com atrasos. | Teste | Ordem forçada | Resultado esperado | |---|---|---| | Duas leituras | A-B e B-A | Mesma evidência combinada | | Leitura e escrita | A escrita espera | Leitura vê versão definida | | Duas escritas no mesmo arquivo | Qualquer ordem proposta | Um plano serializado | | Falha e chamada lenta | Falha primeiro | Dependente cancelada | | Desconexão após escrever | Resposta perdida | Escrita não duplicada | Use um executor falso para que a CI reproduza agendamentos sem depender de sorte. ## Decida quando serial é melhor Migrações, instalações, edições compartilhadas, publicações e operações sem rollback claro devem ser seriais. Paralelismo funciona para exploração, documentação independente, lint isolado e partes de teste separadas. Um modelo do [catálogo LLM da 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) pode propor várias chamadas, mas o executor decide quais podem coincidir. ## Conclusão Chamadas paralelas aceleram trabalho independente e de leitura, mas reduzem confiabilidade quando efeitos, recursos ou ordem são ignorados. Classifique ferramentas, crie dependências, bloqueie recursos, preserve IDs, repita nós idempotentes e teste várias sequências. O executor deve impor segurança mesmo quando o modelo propõe concorrência. ## FAQ ### Quais chamadas podem rodar em paralelo com segurança? Leituras independentes em recursos diferentes são as mais seguras. Confirme que não alteram caches, arquivos temporários ou sessões compartilhadas. ### Edições de arquivos devem rodar em paralelo? Somente com áreas de propriedade separadas e combinação determinística. A execução serial é mais segura para o mesmo arquivo, artefatos, lockfiles ou estado de build. ### O que acontece se uma chamada paralela falhar? O orquestrador precisa de uma política: cancelar irmãs, manter leituras corretas, compensar escritas concluídas ou repetir apenas chamadas idempotentes. ### Como devolver resultados ao modelo? Preserve cada ID e combine os resultados em ordem determinística, com estados explícitos de sucesso, erro e cancelamento. ### Chamadas paralelas podem baratear o agente? Podem reduzir o tempo, mas aumentar tokens, trabalho duplicado ou tentativas. Meça custo e correção separadamente da latência. ### Todo modelo aceita chamadas paralelas? Não. Verifique modelo e protocolo; algumas rotas aceitam ferramentas, mas não várias chamadas no mesmo turno.