AI ajanları geliştirmeyi bırakın, daha akıllı LLM iş akışları kullanın

• LLM tabanlı sistemler geliştiren ekiplerin çoğu herkes gibi önce ajan (Agent) yapmaya çalışıyor, ancak bunların büyük bölümü karmaşıklık, kontrol edememe ve hata ayıklama zorluğu nedeniyle kolayca çöküyor
• Bellek, RAG, araç kullanımı ve iş akışı kontrolünün hepsinin gerektiği gerçek ajan deseni pratikte nadir; sorunların çoğu basit iş akışlarıyla (zincirleme, paralelleştirme, yönlendirme vb.) daha etkili biçimde çözülebiliyor
• Önce gerçek dünyada faydalı 5 LLM iş akışı desenini uygulamanız öneriliyor; ajanlar ise yalnızca gerçekten gerektiğinde dikkatle kullanılmalı
  • Prompt chaining, paralelleştirme, yönlendirme, orchestrator-worker, evaluator-optimizer
• Ajanın gerekli olduğu durumlarda bile asıl kritik olan şey insan katılımı, net kontrol ve gözlemlenebilirlik (Observability)

---

AI ajanları, gerçekten gerekli mi?

• Netflix, Meta, ABD Hava Kuvvetleri gibi farklı mühendis ve ekiplere LLM sistemi kurma konusunda danışmanlık ve eğitim veren Hugo Bowne-Anderson’ın içgörüleri
  • Kendisi Building LLM Applications for Data Scientists and Software Engineers adlı bir eğitim programı yürütüyor

Yanlış başlangıç: Neden herkes ajanlara takıntılı?

• Birçok ekip LLM projesine başlarken ajanlar, bellek, yönlendirme, araç kullanımı, karakter özellikleri gibi karmaşık yapıları önce devreye alıyor
• Gerçekte kurulduğunda ise ajanlar arası iş birliği, araç seçimi, uzun süreli bellek gibi birçok alanda sürekli anormal davranışlar ve hatalar sıkça ortaya çıkıyor
• Örnek olarak CrewAI tabanlı bir araştırma ajanı projesinde her rolün (araştırmacı, özetleyici, koordinatör) beklendiği kadar iş birliği yapamayıp tamamen çöktüğü deneyimlenmiş

Ajan nedir?

• LLM sistemlerinin 4 özelliği: bellek, bilgi erişimi (RAG), araç kullanımı ve iş akışı kontrolü
• Sonuncusu olan iş akışı kontrolü (LLM’in bir sonraki adımı veya araç kullanımını doğrudan belirlemesi) ajanik özellik olarak adlandırılıyor
• Gerçekte çoğu işte basit iş akışları (zincirleme, yönlendirme vb.) daha yüksek kararlılık gösteriyor

Ajanlar yerine kullanmanız gereken, pratikte faydalı LLM iş akışı desenleri

1. Prompt Chaining

• Açıklama: Birden fazla görevi bir dizi adıma (zincire) bölüp, her adımın LLM tarafından sırasıyla işlenmesini sağlamak
• Örnek: LinkedIn profilinden isim, unvan ve şirket bilgisi çıkarma → o şirket hakkında ek bilgiler (misyon, işe alım vb.) ekleme → profil + şirket bilgisine dayanarak kişiselleştirilmiş e-posta yazma
• Avantaj: Her adım net biçimde ayrıldığı için hata olduğunda nedenini kolayca izlemek ve düzeltmek mümkün; hata ayıklama ve bakım açısından avantajlı
• Kılavuz:
  • Sıralı biçimde birbirine bağlanan görevler için uygun
  • Tek bir adım başarısız olsa bile tüm zincir çökebilir
  • İşleri küçük parçalara bölmek daha öngörülebilir sonuçlar ve daha kolay hata ayıklama sağlar

2. Paralelleştirme

• Açıklama: Birden çok bağımsız görevi aynı anda çalıştırarak tüm süreci hızlandırmak
• Örnek: Birden fazla kişinin profilinden eğitim, deneyim, beceri gibi farklı alanları paralel çıkararak toplam işlem süresini kısaltmak
• Avantaj: Bağımsız veri çıkarma/işleme işlerinde büyük ölçekli veride verimli; dağıtık işleme ortamlarıyla iyi uyum sağlar
• Kılavuz:
  • Her görev birbirinden bağımsızsa ve eşzamanlı çalıştırma toplam hızı ciddi biçimde artırıyorsa uygundur
  • Paralel yürütme sırasında race condition, timeout gibi istisnai durumlara dikkat etmek gerekir
  • Büyük veri işleme ve birden fazla kaynağı aynı anda analiz etme için uygundur

3. Yönlendirme (Routing)

• Açıklama: Girdi verisini LLM’in sınıflandırıp her biri için uygun iş akışına otomatik olarak yönlendirmesi
• Örnek: Bir müşteri destek aracında girilen içeriği ürün sorusu, ödeme sorunu veya iade talebi olarak sınıflandırıp ilgili iş akışına göndermek; tür belirsizse varsayılan işleyiciye aktarmak
• Avantaj: Girdi türüne göre uzmanlaşmış işleme mantığını uygulayarak farklı vakaları temiz biçimde ayırır
• Kılavuz:
  • Farklı girdi türleri/durumları için ayrı işlem gerektiğinde kullanılır
  • Sınır vakalarda veya istisnai durumlarda yönlendirme başarısız olabilir ya da bazı vakalar atlanabilir
  • Sınıflandırılamayan/istisnai durumlar için mutlaka bir catch-all handler tasarlanmalı

4. Orchestrator-Worker

• Açıklama: Orchestrator rolündeki LLM’in işi parçalara ayırıp değerlendirmesi ve worker’lara (yürütücü LLM’lere) detay görevleri devretmesi; genel akışı ve sırayı doğrudan kontrol etmesi
• Örnek: Hedef profili tech/non-tech olarak sınıflandırma → tech ise uzman worker’a e-posta üretimini devretme, non-tech ise başka bir worker’a devretme
• Avantaj: Karar verme (sınıflandırma/değerlendirme) ile yürütmenin (tekil işleme) ayrılması; dinamik akış kontrolü ve genişleme açısından avantaj sağlar
• Kılavuz:
  • Her görev için uzmanlaşmış işleme gerektiğinde, karmaşık dallanmalar ve aşamalı koordinasyon için uygundur
  • Orchestrator görevleri yanlış parçalara ayırır veya yanlış devrederse tüm akış hata verir
  • Mantığı açık ve basit tutmak, devretme/sıra/bitiş koşullarını net tasarlamak gerekir

5. Evaluator-Optimizer

• Açıklama: LLM’in çıktıyı değerlendirdiği (puan/geri bildirim) ve eşik altında kalırsa tekrar tekrar düzelttiği/geliştirdiği yapı
• Örnek: E-posta taslağı oluşturma → değerlendiricinin kalite puanı/geri bildirimi → belirli bir eşiği karşılıyorsa veya azami yineleme sayısı aşılmışsa durdurma, değilse yeniden düzeltme
• Avantaj: Nihai çıktının kalitesini hedef seviyeye gelene kadar yinelemeli biçimde artırabilir; nicel kriterler için uygundur
• Kılavuz:
  • Hızdan çok kalitenin önemli olduğu ve yinelemeli optimizasyon gereken iş akışları için uygundur
  • Bitiş koşulu yoksa sonsuz döngüye girilebilir
  • Net kalite kriterleri ve yineleme sınırı mutlaka tanımlanmalı

Ajanların gerçekten gerekli olduğu durumlar

• İnsanın gerçek zamanlı müdahalesinin (Human-in-the-loop) garanti edildiği ortamlarda ajanlar gerçek değerini gösterir
  • Örnek1: Veri bilimi asistanı - SQL sorguları, görselleştirme, veri analizi önerileri gibi işlerde LLM yaratıcı denemeler yapar, insan da sonucu değerlendirip düzeltir
  • Örnek2: Yaratıcı partner - metin fikri, başlık önerisi, metin yapısı önerisi gibi işlerde insanın yön düzeltmesi ve kalite denetimi kritik olur
  • Örnek3: Kod refactoring yardımcısı - tasarım deseni önerileri, edge case tespiti, kod optimizasyonu gibi işlerde geliştirici onaylar ve tamamlar
• Özellik: Ajanın “her şeyi kendi kendine” yapması değil, insanın gerçek zamanlı olarak hatayı ve yönü düzelttiği ortamda en etkili olması

Ajanların uygun olmadığı durumlar

• Kurumsal ve mission-critical sistemler (finans, sağlık, hukuk vb.):
  • Otomasyonun güvenilirliği ve deterministik davranış önemli olduğu için, LLM ajanının karar verdiği yapı risklidir
  • Orchestrator, yönlendirme gibi net kontrol desenleri kullanılmalı
• Kararlılık ve öngörülebilirliğin kritik olduğu tüm durumlar
  • Tipik sorunlar: ajanın bağlam/bellek olmadan araç seçimini tekrar tekrar yanlış yapması veya iş bölümü/koordinasyonun başarısız olup tüm akışın çökmesi
• Pratikte sık görülen ajan sistem başarısızlığı nedenleri
  • Açık bir bellek sistemi tasarlanmadığı için bağlam kaybı
  • Araç seçimi kısıtlarının yetersizliği (gereksiz/yanlış araç kullanımı)
  • Yalnızca serbest devretme yapısına dayanıldığı için iş birliği ve koordinasyonun bozulması

Pratik sistem tasarımında çıkarılacak dersler

• Ajan kullanılsa bile “olgun bir yazılım sistemi” seviyesinde tasarım, gözlemlenebilirlik ve kontrol mekanizmaları mutlaka gerekir
• Karmaşık ajan framework’leri yerine gözlemlenebilirlik (Observability), net değerlendirme döngüleri ve doğrudan kontrol edilebilir yapılarla tasarlamak daha hızlı ve daha güvenlidir

Sonuç (TL;DR)

• Ajanlar çoğu zaman olduğundan fazla değerlendirilip aşırı kullanılıyor
• Pratikteki görevlerin çoğu için basit iş akışı desenleri daha uygun
• Ajanlar, “insanın doğrudan dahil olduğu” ortamlarda gerçek değerini gösteriyor
• Kararlı sistemlerde ise tersine bir risk unsuru olabiliyor
• Tasarımı gözlemlenebilirlik, açık kontrol ve yinelemeli değerlendirme yapısı üzerine kurun

• Karmaşık ajan framework’leri yerine, gözlemlenebilirlik, net değerlendirme döngüleri ve doğrudan kontrol edilebilir yapılarla tasarım yapmak, gerçekte daha hızlı ve daha güvenli LLM tabanlı hizmet geliştirmenin anahtarıdır

[samdo103]

Bir ay önce, hem CURSOR kullanarak AI coding’in ne olduğunu öğrenmek hem de geliştirme framework’ü geliştirmeye başlamak için işe koyuldum.

Yaklaşık 3 hafta boyunca, başarıyla ilerlerken AI Agent tarafından doğrulanmış kaynak kodun tekrar tekrar bozulduğunu gördüm; AI Agent’ı kontrol etmek için her türlü yöntemi denedim ama başarısız oldum.

Sonra, geliştirme framework’ünü geliştirmeden önce önceliğin AI Agent’ı kontrol eden kaynak kodu geliştirmek olduğunu fark ettim.

Sonuç olarak, ilk AI’nin ne olduğunu anlamak için başlamamın üzerinden tam 1 ay geçtikten sonra, AI Agent’ı tamamen kontrol edebilen (daha doğrusu harici LLM ya da AI Agent’a ihtiyaç duymayan), yapay zeka tarafından %100 geliştirilebilen ve %100 işletilebilen bir yazılımı tamamlamayı başardım.

Şu anda 14. gündeyim; ek iyileştirmeler için bu META AI’yi yeniden eğitip operasyon kuralları oluşturarak bunlara uymasını sağlama sürecini yürütüyorum. Aynı zamanda, daha önce insanlar tarafından eksik şekilde yapılmış 3 MES sistemini eşzamanlı olarak migrate edip iyileştiriyor ve standardize ediyorum; çalışma artık son aşamaya girmiş durumda.

Ve şimdi bir başka evrime daha hazırlanıyorum.

[spilist2]

Ama prompt chaining'de tek tek prompt'ları çalıştıran LLM'e, yürütücü worker'a, orkestratör worker'a, değerlendirici LLM'e vb. ayrı ayrı ajan demek de makul değil mi?

[spilist2]

Ah, demek ki "nihai iş akışı kontrolü (LLM’nin bir sonraki adımı veya araç kullanıp kullanmayacağını doğrudan belirlemesi, ajansal özellik olarak adlandırılır)" diye bir şey varmış. Anladım. Otonom agent’ı hedefleyerek yazılmış bir yazıymış. Ben agent’lar konusunda hâlâ çok bilgili olmadığım için...

[GN⁺]

Hacker News yorumları

• Ajan geliştirmek gerçekten eğlenceliydi, ama “kontekst mühendisliği” tarafında ciddi sorunlar olduğu açık. Kontekst penceresini ne kadar büyütseniz de ajanın göreceği öğeleri kürate etmeniz gerekiyor ve gerçekten önemli bilgileri seçen etkili filtreler eksik gibi geliyor. Bu yüzden oraya buraya *.md dosyaları serpiştirerek yardımcı olmak gerekiyor, ayrıca rol ataması da önemli. Bu *.md sistemi bir tür ilkel hafıza sistemi ve çok daha sağlam hale getirilebilir. Kullanıcı etkileşimlerine dayanarak gerçek zamanlı programlar veya modeller (doğal dil tabanlı) üretmenin de mümkün olduğunu düşünüyorum. Claude Code kullanırken ajanı bir test suite ile “yönlendirmenin” gerçekten güçlü bir pekiştirmeli öğrenme mekanizması olduğunu fark ettim; bu döngü çoğunlukla başarılı şekilde devam ediyor, bu yüzden ileride ajanları daha akıllı işbirlikçilere dönüştürecek yeni fikirler çıkmasını umuyorum
  • Asıl işten çok araçlarla boğuşmaya daha fazla zaman harcıyormuşsunuz gibi hissettiriyor
  • Bu tür sistemlerde .md dosyalarını yapılandırmak için önerilen bir yöntem olup olmadığını merak ediyorum. İnsanların kolay okuması için çok fazla işaretleme eklendiğinde bunun llm tarafından işlenmesi açısından sorun yaratmasından endişe ediyorum. İnsanların okuyacağı şekilde aynı .md dosyalarını hazırlamanın llm kullanımını engelleyip engellemediğini bilmek isterim
  • Benim deneyimime göre kontekst yönetimi neredeyse her sorunun merkezinde. Örneğin paralel/özyinelemeli işler için doğru konteksti oluşturmak, bazı adımları (ör. önceki yanıtı düzenleme) hariç tutup yalnızca düzeltilmiş sonucu göstermek, ben yorum eklediğimde ajanın bu yorumla kendi çıktısını ilişkilendirmesini sağlamak gibi pratikte pek çok durum var
  • Ajanı test suite ile güçlendirme kısmı ilginç geldi; bunu tam olarak nasıl yaptığınızı biraz daha ayrıntılı anlatabilir misiniz diye merak ediyorum
• AI ajanlarının insanların LinkedIn’de anlattığı kadar kitlesel şekilde kullanılacağından hâlâ emin değilim, ama ihtimali açık bırakıyorum. Ben şu anda Claude Code, Cursor gibi araçlarla AI’yi sıkı biçimde kontrol ederek kullanıyorum. Sebebi modelin yetersiz olması değil; sadece sık sık kendi “zevkimi” ve yönümü bizzat vermek istemem. AI’ye daha fazla özerklik vermek bana o kadar çekici gelmiyor, çünkü araya girdiğimde kimlik ve aidiyet hissediyorum. İleride çalışma biçimim değişir ya da yeni bir UX çıkarsa fikrim değişebilir, ama şu an için AI’nin fazla ajanvari olmasını istemiyorum
  • Zamanla modelin nasıl davrandığını iyice öğrenip ona daha fazla/daha iyi kontekst ve talimat verirseniz, kullanıcının zevk ve yönelim beklentilerini belli ölçüde karşılayabileceğini düşünüp düşünmediğinizi merak ediyorum. Benim deneyimimde iyi yapılmış prompt engineering tek başına bile birçok iş akışında AI’nin istenen şekilde davranmasını sağlayabiliyor; bu yüzden sık müdahale gerekmeyebiliyor
  • Buna tam olarak katılıyorum. Başka yerlerde de benzer yorumlar yazdım; eski “bedava öğle yemeği yoktur” sözünün hâlâ geçerli olduğunu düşünüyorum. Eğer LLM’ler insanı tamamen devreden çıkararak sorun çözebiliyorsa, o zaman herkes birkaç satır prompt ile aynı derecede rafine sistemler kurabilir demektir ve o noktada sistemler arasındaki farklılaşma ve değer kaybolur. Eğer prompt’lar yeni bir soyutlama seviyesi ise, örneğin Claude’a “bana bir not uygulaması yap” dendiğinde milyonlarca insanın aynı düşük maliyetli prompt’u gireceğini varsayarsak, bu durumda prompter’ın kattığı anlam tam olarak nedir diye sormak gerekir
  • Bence zamanla bu ayrı ayrı “zevk” unsurları da giderek prompt olarak sistematikleştirilebilir. Örneğin tek bir prompt ile kod değiştirirken gereksiz değişkenlik oluşturmamayı, mümkünse immutable yazmayı teşvik ediyorum. Başka bir prompt ile de faydasız log yazımından kaçınma gibi, benim özel olarak tanımladığım kuralları koyuyorum. Kod değişikliklerini incelerken bu prompt’ların hepsini ayrı ayrı çalıştırıp yapılandırılmış MCP çıktıları olarak bir araya getiriyorum. Bu parçaları kod ajanına uygulayarak otomatik inceleme döngüleri kuruyorum. Eğer elle kontekst eklemem gereken bir durum ortaya çıkarsa yeni bir prompt oluşturuyor ya da mevcut birini genişletiyorum
• İlginç olan, daha 1-2 yıllık deneyimi varmış gibi görünen bir alanda “otoritelerin” ortaya çıkması. Sanki “2 yıllık dilde 10 yıl deneyimli aday aranıyor” memesinin ters çevrilmiş hali gibi
  • Ben GPT-3 çıktığından beri “ai agent” denilen şeyler geliştiriyorum; benden başka birçok insan da aynı deneyimi yaşadı. Üzerinden zaten 5 yıl geçti; eğer 5 yılda da uzmanlar ortaya çıkmıyorsa artık ortada uzman diye bir şey yoktur diye düşünürüm. Tabii bugünlerde “ajan” kelimesi iyice bir buzzword’e dönüştüğü için anlamı da aşınıyor
  • Ama “onlarca ekiple çalıştım...” gibi deneyim anlatılarını okuyunca biraz dramatik geliyor
• Temel özet şu: Önceden tanımlı bir çözüm varsa ajan kullanmaya gerek yok (ör. yazıda geçen “pattern”ler). Programcılar genelde programla çözülebilecek sorunlar için daha basit ve daha güvenilir çözümler önerir. Gelecekte AI gerçekten çok akıllı olup her türlü sorunu brute force ile çözebilir, ama şu an için sadece karmaşıklığı artırıyor. İnsanların ajanlara bu kadar ilgi duymasının nedenlerinden biri, çoğunun LLM’lerle ilk olarak chat assistant biçiminde tanışmış olması olabilir. Bu tür chat assistant senaryolarında çoğu zaman hazır bir çözüm yoktur ve etkileşimler karmaşıktır; bu yüzden ajanlar burada gerçekten işe yarar. Örneğin: “En yakın cuma akşamını bul ve Bob’a buluşup buluşamayacağını soran bir mesaj gönder” — bunun tüm olasılıklarını önceden programlamak zor. Asistanla etkileşim biçimleri neredeyse sonsuz olduğu için ajan yaklaşımı daha uygundur
  • Kontrol etme hızı, işi kendiniz yapmaktan daha hızlı olduğunda çok iyi çalışıyor. Ama ben doğrulamadan AI’ye güvenmekte zorlanıyorum
• Neden bu kadar çok örnek sonunda “spam’i daha hızlı ve daha iyi gönderme yöntemi”ne çıkıyor diye merak ediyorum
  • Aslında örnek tam olarak bu değil miydi? LinkedIn’i crawl edip insan bulmak ve “kişiselleştirilmiş” e-postalarla spam göndermek gibi
  • Buna tekerleğin sonuçta yağ olmadan dönmemesine benzetilebilir
• Bu, 2023 sonu ile 2024 başı arasında doğruydu ama artık mid 2025 civarında SOTA LLM’ler kullanıldığında birçok görev için geçerli olmadığını düşünüyorum. Eskiden çoğu şey LLM’i bir fonksiyon gibi çağırma şeklindeydi, ama bu biraz da yanlış araç seçiminden kaynaklanıyordu. Günümüzde üst düzey LLM’ler (Gemini 2.5 Pro, Claude 4 vb.) gerçekten çok zeki; instruction following ve araç seçimi konusunda oldukça iyiler. Checklist araçları, delegate komutu, görev bölme gibi şeyler hâlâ gerekli. Ama talimatları oluşturup komutları belirleme yaklaşımı — özellikle UI ortamında araç komutları kolayca tanımlanabiliyorsa — iş akışlarından daha esnek ve bir seviye daha yüksek soyutlama sunuyor. Görsel iş akışları da sonuçta kırılgan ve ayarlaması zor bir tür programlama. 6-12 ay önce bunlar mümkün değildi; ama LLM yeterince iyi değilse bu hâlâ geçerli değil. Büyük resimde, instruction following ve araç entegrasyonu iyi olan model sayısı az olduğu için bu modellere ajan uygulamak avantajlı. Önümüzdeki 1-2 yıl içinde tarayıcı/bilgisayar kullanan ajanlar büyük bir trend haline gelecek. Bunlar iyi bir hafıza sistemi ile “demonstration/observation mode”u birleştirerek kullanıcının UI kullanımını öğrenip (kaydedip) insanın sözlü/yazılı talimatlarından optimize edilmiş prosedürler de öğrenecek
  • Son dönemde en güçlü ajan modellerinin (Claude Opus 4 vb.) gelmesiyle tablo tamamen değişti. Hâlâ iyi kontekst gerekiyor, ama araçları gerçekten çok doğru seçiyorlar
  • Orijinal gönderideki tekniklerin çoğu, sorunu bir 'data flow graph olarak modelleyip sonra onu takip etmek**ten ibaret. Modellemenin ötesine geçip “nasıl olsa halleder” diye yaklaşmak artık mühendislik değil, inanç olur
• Son 3 haftadır ajanları kararlı şekilde çalıştırmaya uğraştım ama sonunda çok daha basit bir desene geri döndüm. Mevcut ajanlar bana evrimin çok erken aşamasındaki “altı parmaklı bir el” gibi geliyor
• “Koordinatör görev tanımı yeterince net değilse vazgeçiyor” gibi bir şeyi görüp “o zaman koordinatörü de at ve imperatif mantığa dön” sonucuna varıldığında, aslında mesele prompt veya araç açıklamalarını daha somut yazmakla, ayrıca ara özetler ya da LLM kontekst sıkıştırma gibi adımlar eklemekle çözülebilir olabilir. Yazıda gerçekten kullanılabilir uzun araç açıklamaları/prompt örnekleri bile yoksa karar vermek zor. Sezgisel olarak göreve uygun orkestrasyon kullanmak doğru cevap, ama gerçekte çok daha fazla görevde ajanik orkestrasyonun etkili şekilde işe yarayabileceğine inanıyorum
• Ben de %100 katılıyorum. Ajanlar gerçekten çok eğlenceli ve deney yapmak için harika, ama gerçek verimlilik artışı istiyorsanız önemli olan belirli iş akışlarını ve süreçleri iyi orkestre etmek ve AI’nin gerçekten benzersiz olduğu kısımlara odaklanmak. Bu arada ai.intellectronica.net üzerindeki AI iş akışları yazılarını da tavsiye ederim
• Son zamanlarda sık gördüğüm şey, mevcut workflow orchestration tool’lara LLM eklenerek sistemlerin çok daha kolay kurulması. Karmaşıklığın büyük kısmı a) modelin kendisi (önde gelen laboratuvarlar kullanımı kolay modeller sunuyor), b) iş akışının production ortamına alınması (iş akışı araçları bunu kolaylaştırıyor) tarafında. Bu iş akışları mevcut işlere dayandığı için ortaya çıkan değeri görmek ve ölçmek kolay oluyor. Bu örüntü o kadar sıklaştı ki Airflow (çok popüler bir iş akışı aracı) için özel bir SDK paketleyip yayımladım.
  https://github.com/astronomer/airflow-ai-sdk

[sto1111]

Ben de şu anda UseDesktop

https://youtu.be/aBkbsvMxP_A?si=uaugxKQEu4ZEz7jq

usedesktop.com

adlı bir Computer-use Agent geliştiriyorum ve büyük ölçüde katılıyorum.

Bu yazı pratik ipuçlarından ziyade genel bir overview ele alıyor; ben de LLM tabanlı agentic/agent geliştirirken birkaç ipucu daha eklemek isterim: Sonuçta LLM transformer tabanlıdır (yani probabilistic based akıl yürütme; mevcut token/state’e dayanarak bir sonraki token’ı bağlamı/semantiği gerçekten anlayıp üretmekten ziyade olasılıksal olarak output verir). Bu yüzden sys prompt ne kadar iyi yazılırsa yazılsın, çoğu zaman istenen yanıtı vermediği durumlar olur (örneğin JSON output istenir ama bazen } karakterini unutabilir). Bu nedenle regex tabanlı birden fazla fallback fn eklemek her zaman şarttır.

Ayrıca structured output veren bir sys prompt yazıyorsanız genelde non-reasoning model kullanırsınız; context uzadıkça hallucination daha sık ortaya çıktığı için, tek bir uzun sys prompt yerine birkaç sys prompt hazırlayıp chaining yapmak daha iyidir.

Bir servis geliştirirken çeşitli hatalar oluşabileceğinden, servis mimarisini modüler ve fault tolerant şekilde tasarlamak kritik önemdedir (örneğin supervisor agent’ı async, diğer agent’ları sync yapmak). Özellikle unexpected output’un sık görüldüğü agentic ve agent sistemlerinde bu daha da önemlidir. Bu yüzden en baştan kod yazarken mümkün olduğunca SRP’ye uymak ve declarative bir yaklaşım benimsemek iyi olur; yani fonksiyonel bir yaklaşımın daha iyi olduğunu söylemek isterim (= side effect yoktur ve flow sezgiseldir).

Ayrıca LLM’i API üzerinden mi kullanacağınız yoksa modeli doğrudan kendiniz mi serve edeceğiniz duruma göre değişir; ancak SLM ya da LLM’i doğrudan serve edecekseniz backend’i host ettiğiniz sunucuda model serving yapmayın. IO bound task’lerle CPU bound task’leri (yani GPU gerektiren, mat mult gibi işlemler isteyen task’ler) ayrı sunuculara koymak fault tolerance açısından daha iyidir (örneğin CPU bound task’leri Runpod’da host etmek).

Bunun dışında daha birçok geliştirme ipucu var ama çok uzamasın diye burada bırakayım.

Birilerine faydalı olmasını umuyorum.

[jypark]

Değerli deneyimlerinizi ve görüşlerinizi paylaştığınız için gerçekten çok teşekkür ederim. Sahada olan birinin görüşleri bize gerçekten çok yardımcı oluyor.