# Bir Kodlama Ajanı Hatasını Model Sürümleri Arasında Nasıl Yeniden Üretirsiniz? > Kodlama ajanı hatasını yeniden üretmek için tüm çalışmayı sürümlenmiş bir test fixture'ı olarak kaydedin; aynı istemi, depo commit'ini, araç sözleşmesini, ortamı ve durdurma kurallarını sabit model kimlikleriyle birkaç kez çalıştırın. Yalnızca asistan metnini değil, yapılandırılmış olayları ve son depo durumunu karşılaştırın. # Bir Kodlama Ajanı Hatasını Model Sürümleri Arasında Nasıl Yeniden Üretirsiniz? Yararlı yeniden üretim kopyalanmış transkript değil, yürütülebilir deneydir. Hatanın görüldüğü depo durumundan başlayın, ajanın görebildiği her girdiyi sabitleyin ve hata için makinece denetlenebilir koşul tanımlayın. Ardından fixture'ı sabit model sürümlerinde birkaç kez oynatın. Ajan çalışması model davranışını araçlar, dosyalar, ağ sonuçları, orkestrasyon ve zamanlamayla birleştirir. Bunlardan biri değişirse farklı sonuç modelin sorunu çözdüğünü veya oluşturduğunu kanıtlamaz. ## Hatayı bir koşul olarak tanımlayın Başarısızlığı başarıdan ayıran en küçük gözlenebilir durumu yazın. Kırmızı kalan test, beklenmedik dosya değişikliği, yasak komut, eksik migration veya derlenip davranışı değiştiren yama iyi örneklerdir. "Yanıt daha kötü görünüyor" gibi koşullardan kaçının. Kabul paketi şunları isteyebilir: * özgün gerileme testi geçer; * mevcut tüm testler geçer; * allowlist dışındaki dosyalar değişmez; * ajan belirli çağrı sayısında durur; * son diff'te üretilmiş sır veya lockfile sapması yoktur. ## Tam çalışma zarfını kaydedin İstem yalnızca bir girdidir. Fixture yanında şunları saklayın: | Katman | Neyi sabitlemeli | Sonucu neden değiştirir | |---|---|---| | Depo | Commit, submodules, kaydedilmemiş yama, izlenmeyen fixture dosyaları | Ajan kesin kaynak durumundan düşünür | | Talimatlar | Sistem istemi, depo kuralları, kullanıcı görevi | Küçük ifade farkları planı değiştirir | | Model | Sağlayıcı, değişmez model kimliği, parametreler | Takma ad ve varsayılanlar değişebilir | | Araçlar | Adlar, JSON şemaları, izinler, timeout'lar | Araç imkanları planı şekillendirir | | Ortam | Container imajı, OS, mimari, bağımlılık kilitleri | Komut ve testler farklı davranabilir | | Dış veri | Mock HTTP yanıtları, saatler, rastgele girdiler | Canlı hizmetler sapma ekler | | Orkestratör | Döngü limiti, retry ilkesi, bağlam sıkıştırması | Aynı model farklı geçmiş alabilir | Sırları çıkarın, ancak kimlik bilgisinin mevcut olup olmadığını ve kapsamını koruyun. ## Yalnızca metin değil, yapılandırılmış olay kaydedin Her model isteğini, yanıtını, araç çağrısını, sonucunu, retry'ı ve durma kararını sıralı olay olarak saklayın. Büyük araç çıktısı için içerik hash'i ekleyip özgün nesneyi ayrı tutun. ```json { "run_id": "agent-regression-042", "fixture": "sha256:...", "model": "provider/model-version", "event": "tool_result", "tool": "run_tests", "exit_code": 1, "stdout_sha256": "..." } ``` Yapılandırılmış olaylar yeni modelin farklı araç seçip seçmediğini, aynı hatayı farklı yorumlayıp yorumlamadığını veya farklı kanıt aldığını gösterir. ## Sürümleri sabitleyin ve canlı değişkenliği kaldırın Varsa tarihli veya değişmez model kimlikleri kullanın. Tarihsel hatayı `latest` takma adıyla karşılaştırmayın; başka yapıya işaret ediyor olabilir. Temiz container veya sanal makinede çalışın. Canlı aramaları ve değişken paket dizinlerini kaydedilmiş yanıtlarla veya snapshot'la değiştirin. Tarihe duyarlı mantıkta saati sabitleyin. Ağ gerekiyorsa her yanıtı kaydedip testi kısmen kontrollü olarak etiketleyin. Rastgele tohum yardımcıdır, fakat dağıtık inference'ı, araç zamanlamasını veya sağlayıcı değişikliklerini sabitlemez. ## Tek çift değil, matris çalıştırın Sürüm başına bir geçiş gerilemeyi örnekleme değişkenliğinden ayıramaz. Fixture'ı sabit tutan küçük matris kullanın: | Model sürümü | Tekrar | Geçiş oranı | Medyan çağrı | Hata imzası | |---|---:|---:|---:|---| | Sabit temel kimlik | 5 | 4/5 | 9 | Uç durum testi atlandı | | Sabit aday kimlik | 5 | 1/5 | 13 | Üretilen dosya düzenlendi | | Eski istemli aday | 5 | 1/5 | 12 | Aynı imza | Beş tekrar ilk bakış için uygundur. Aralıklı veya yüksek etkili hatalarda örneği artırın. Deney parametreler hakkında değilse sıcaklığı ve örnekleme kontrollerini eşit tutun. ## Kararları ve depo durumunu karşılaştırın Dört katmanı ayrı karşılaştırın: * normalize edilmiş model ve araç olayları; * komutlar ve çıkış kodları; * son dosya ağacı ve yama; * kabul testi sonuçları ve kaynak kullanımı. Aynı doğal dil gerekmez. Farklı yollar eşdeğer doğru yamalara ulaşabilir; benzer metin ise maddi olarak farklı komutu gizleyebilir. ## Yeniden üretimden sonra fixture'ı küçültün Hata tekrarlanınca ilgisiz dosyaları, araçları, istem paragraflarını ve dış çağrıları birer birer çıkarın. Küçük fixture daha hızlı çalışır ve nedensel sınırı gösterir. Denetim için tam olay tekrarını, sürekli değerlendirme için küçültülmüş gerileme testini saklayın. Küçük vakayı model yükseltme kapısına ekleyin. ## Taşınabilir model adaptörü kullanın Atlas Cloud gibi ağ geçidi birden çok modeli tek OpenAI uyumlu istemci arkasına koyabilir, ancak uyumluluk davranışsal eşitlik sağlamaz. Model kimliklerini, sağlayıcı seçeneklerini ve araç biçimi farklarını adaptörde tutun. Ortak test düzeneği fixture, olay, retry ve koşulları yönetmelidir. Bu yapı aynı yeniden üretimin değerlendirme mantığı yazılmadan sağlayıcılar arasında çalışmasını sağlar. ## Sonuç Kodlama ajanı hatasını yeniden üretmek için çalışma zarfını sabitleyin, sabit modelleri birkaç kez oynatın ve yürütülebilir sonuçları değerlendirin. Kesin olayı üretemiyorsanız canlı kalan girdileri işaretleyin ve sonucu model gerilemesinin kanıtı değil, karşılaştırma çalışması sayın. ## FAQ ### Bir kodlama ajanı hatasını yeniden üretmek için neler kaydedilmelidir? Depo commit'ini ve kaydedilmemiş yamayı, istem ve sistem talimatlarını, model kimliğini, parametreleri, araç şemalarını ve sonuçlarını, ortam imajını, bağımlılık kilitlerini, kimlik bilgisi ve ağ ilkelerini ve kesin başarı koşulunu kaydedin. ### Hatayı latest model takma adıyla yeniden çalıştırmalı mıyım? Hayır. Değişmez veya tarihli model kimlikleri kullanın. latest takma adı test sırasında değişebilir ve sonucu belirli bir sürüme bağlamayı imkansızlaştırır. ### Sabit rastgele tohum neden yeterli değildir? Tohum; sağlayıcı altyapısını, araç zamanlamasını, retrieval sonuçlarını veya model revizyonlarını sabitlemez. Determinizm garantisi değil, kontrollerden yalnızca biridir. ### Kodlama ajanı için en iyi başarılı veya başarısız sinyali nedir? Testler, lint sonuçları, beklenen dosya farkları, yasaklı dosya kontrolleri ve komut çıkış kodları gibi yürütülebilir koşulları kullanın. Metin benzerliği kodlama görevlerinde genellikle yetersizdir. ### Her model sürümü için kaç tekrar çalıştırmalıyım? Deterministik gerilemeyi örnekleme değişkenliğinden ayıracak kadar tekrar yapın. Beş çalışma iyi bir başlangıçtır; yüksek etkili hatalar yirmi veya daha fazlasını gerektirebilir. ### Aynı test düzeneği farklı sağlayıcıların modellerini karşılaştırabilir mi? Evet. İsteği, araç sözleşmesini, olay günlüğünü ve çıktı koşullarını normalize edin; sağlayıcıya özgü seçenekleri adaptörlerde tutun.