# Paralel Araç Çağrıları Kodlama Ajanı Güvenilirliğini Nasıl Değiştirir? > Paralel araç çağrıları bağımsız okumaların gecikmesini azaltır ancak çağrılar durum paylaştığında, sıraya bağlı olduğunda veya yazma yaptığında güvenilirliği düşürür. Açık bağımlılık grafiği, kaynak kilitleri, idempotency key ve deterministik sonuç birleştirme kullanın. Paralel araç çağrıları bir zamanlama önerisidir, her şeyi aynı anda başlatma izni değildir. İki repository araması genellikle çakışabilir. Bir dosya düzenlemesi ile formatter çakışamayabilir. Bağımlılık kurulumu ve test çalışması aynı kurulum öncesi durumdan kesinlikle başlamamalıdır. Eşzamanlılık bir kaynak ve bağımlılık modelini izlediğinde güvenilirlik artar. Yürütücü, çağrı dizisini bağımsızlık kanıtı saydığında azalır. ## Çağrıları etkisine göre sınıflandırın Registry’deki her aracı scheduler’ın uygulayabileceği davranışla etiketleyin. | Etki sınıfı | Örnek | Varsayılan politika | |---|---|---| | Saf okuma | İki kaynak dosyasını oku | Paralel izinli | | Dış okuma | İki API’ye sorgu yap | Limitlerle paralel | | Yerel yazma | Dosya düzenle | Kaynak başına seri | | Global yazma | Bağımlılık yükle | Global seri | | Geri alınamaz eylem | Publish veya send | Açık kapı gerektir | Yalnızca araç adına güvenmeyin. `inspect` adlı komut cache oluşturabilir; test snapshot veya veritabanı yazabilir. Yan etkileri registry’de belgeleyin. ## Yürütmeden önce bağımlılık grafiği kurun Çağrıları düğüm, zorunlu sıralamayı kenar olarak gösterin. Bir çağrı yalnız öncülleri başarılı ve kaynakları boş olduğunda başlayabilir. ```text read_config ----+ +--> build --> test read_source ----+ search_docs ---------> summarize ``` İlk iki okuma birlikte çalışabilir. Build ikisini, test build’i bekler. Doküman araması build girdilerini etkilemiyorsa repository dalıyla çakışabilir. Model bağımlılık vermiyorsa araç metadatası ve argümanlardan temkinli çıkarım yapın. Belirsiz yazmaları seri çalıştırın. ## Tüm ajanı değil, kaynakları kilitleyin Tek global kilit güvenilir ama yavaştır. Kaynak düzeyi kilitler güvenli eşzamanlılığı korur. Karşılaştırmadan önce yolları normalize edin. `src/a.ts` düzenlemek `src` dizinini biçimlendirmekle, lockfile üretmek başka paket işlemiyle çakışır. Veritabanı, tarayıcı oturumu, terminal ve uzak kayıtları kaynak modeline dahil edin. | Kaynak | Kilit kapsamı | |---|---| | Kaynak dosya | Kanonik yol | | Dizin formatterı | Dizin alt ağacı | | Paket yöneticisi | Workspace ve lockfile | | Tarayıcı oturumu | Sekme veya doğrulanmış akış | | Deployment | Ortam ve servis | ## Akış boyunca çağrı kimliğini koruyun Birden fazla çağrı iç içe argüman parçaları gönderebilir. Call ID’ye göre bufferlayın ve her çağrı tamamlanma olayını aldıktan sonra çalıştırın. Output konumunu kalıcı kimlik olarak kullanmayın. Sonuçları aynı opaque call ID ile döndürün. Tamamlanma sırası farklı olsa da sunumu ilk çağrı sırası gibi deterministik bir düzende sıralayın. Atlas Cloud, OpenAI Chat Completions üzerinde araç yeteneği bildiren modeller için `tools`, `tool_choice` ve `parallel_tool_calls` alanlarını iletir. Her rotanın paralel çağrı desteklediğini varsaymak yerine [LLM protokol rehberinde](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) modeli ve protokolü kontrol edin. ## Kısmi hata politikasını tanımlayın Paralel batch yalnız başarı veya hatadan oluşmaz. Bir çağrı tamamlanabilir, biri doğrulamada başarısız olabilir, diğeri çalışıyor olabilir. Etkiye göre politika seçin: * Başarılı bağımsız okumaları tutup başarısız okumayı bildirin. * Önkoşul başarısız olursa bekleyen bağımlıları iptal edin. * Tamamlanmış yazmayı idempotency key olmadan yeniden denemeyin. * Telafiyi yalnızca araç açıkça destekliyorsa kullanın. * Modele yapılandırılmış batch sonucu döndürün. Retry tüm batch’i körlemesine tekrarlamak yerine başarısız düğümü hedeflemelidir. ## Eşzamanlılığı sınırlayın ve backpressure uygulayın Bağımsız çağrılar bile dosya sistemini, API’yi, test runner’ı veya rate limit’i aşırı yükleyebilir. Araç ve kaynak başına limit koyun, fazla işi kuyruğa alın ve iptal sunun. En yavaş çağrıyı, kuyruk süresini, retry sayısını, duplicate suppression’ı ve son görev başarısını ölçün. Daha kısa süre yalnız çıktı doğru kaldığında değerlidir. ## Yalnız çıktıları değil, zamanlamaları test edin Race bug tek bir tamamlanma sırasında kaybolabilir. Aynı fixture’ı farklı sıraları zorlayan gecikmelerle çalıştırın. | Test | Zorlanan sıra | Beklenen sonuç | |---|---|---| | İki okuma | A sonra B, B sonra A | Aynı birleşmiş kanıt | | Okuma ve yazma | Yazma bekler | Okuma tanımlı sürümü görür | | Aynı dosyaya iki yazma | Herhangi öneri sırası | Tek seri plan | | Hata ve yavaş çağrı | Önce hata | Bağımlı çağrı iptal edilir | | Yazmadan sonra kopma | Yanıt kaybolur | Yazma tekrarlanmaz | CI’ın zamanlama şansına bağlı olmadan sıraları yeniden üretmesi için sahte yürütücü kullanın. ## Seri yürütmenin ne zaman daha iyi olduğuna karar verin Migration, paket kurulumu, paylaşılan dosya düzenlemesi, yayın adımı ve rollback’i belirsiz işlemler seri yürütülmelidir. Repository keşfi, bağımsız doküman okumaları, izole lint kontrolleri ve ayrık test shard’ları paralellikten yararlanır. [Atlas Cloud LLM kataloğundaki](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=how-parallel-tool-calls-change-coding-agent-reliability) bir model birkaç çağrı önerebilir; ancak hangilerinin eşzamanlı çalışabileceğine yürütücü karar verir. ## Sonuç Paralel çağrılar iş bağımsız ve okuma ağırlıklı olduğunda kodlama ajanını hızlandırır. Yan etkiler, gizli kaynaklar veya sıra görmezden gelindiğinde güvenilirliği düşürür. Araçları sınıflandırın, bağımlılık grafiği kurun, paylaşılan kaynakları kilitleyin, call ID’leri koruyun, yalnız idempotent düğümleri yeniden deneyin ve birden fazla zamanlamayı test edin. Model eşzamanlılık önerse de güvenliği yürütücü uygulasın. ## FAQ ### Hangi kodlama ajanı araç çağrıları paralel çalıştırılabilir? Farklı kaynaklardaki bağımsız salt okunur çağrılar en güvenlisidir. Cache, geçici dosya veya paylaşılan oturumları değiştirmediklerini doğrulayın. ### Dosya düzenlemeleri paralel çalıştırılmalı mı? Yalnızca sahiplik alanları ayrık ve birleştirme deterministikse. Aynı dosya, üretilen artefakt, lockfile veya paylaşılan build durumu için seri yürütme daha güvenlidir. ### Bir paralel çağrı başarısız olursa ne olur? Orkestratörün tanımlı bir politikası olmalıdır: bağımlıları iptal etmek, başarılı okumaları tutmak, yazmayı telafi etmek veya yalnız idempotent çağrıyı yeniden denemek. ### Sonuçlar modele nasıl döndürülmeli? Her call ID korunmalı ve sonuçlar açık success, error ve cancelled durumlarıyla deterministik sırada birleştirilmelidir. ### Paralel çağrılar ajanı daha ucuz yapabilir mi? Geçen süreyi azaltabilir fakat tokenı artırabilir, işi çoğaltabilir veya retry oluşturabilir. Tamamlanan görev maliyetini ve doğruluğu gecikmeden ayrı ölçün. ### Her model paralel araç çağrısını destekler mi? Hayır. Seçili model ve protokolü doğrulayın. Bazı rotalar araçları desteklerken aynı turda birden fazla çağrıyı desteklemeyebilir.