Etkili AI Ajanları İnşa Etmek
(anthropic.com)- LLM tabanlı ajanları başarıyla hayata geçiren ekipler, karmaşık framework’ler yerine basit ve birleştirilebilir desenler kullanma eğiliminde
- İş akışları ile ajanlar arasındaki yapısal farkları anlamak gerekiyor; en iyi çözüm için her zaman yalnızca gerekli olan en düşük karmaşıklığın eklenmesi öneriliyor
- Çeşitli ajan desenleri (prompt chaining, routing, paralelleştirme, orchestrator-workers, değerlendirme-optimizasyon döngüsü vb.) gerçek üretim ortamlarında kullanılıyor ve her desenin kendine uygun kullanım senaryoları ile artı ve eksileri bulunuyor
- Ajan uygulamalarında sadelik, şeffaflık, arayüz tasarımı temel ilkeler; araç tasarımı ve prompt engineering’e özen göstermek gerekiyor
- Müşteri desteği veya yazılım geliştirme ortamlarında ajanların gerçek değer sunduğu örnekler giderek artıyor
Genel Bakış
Anthropic, son bir yılda farklı sektörlerdeki ekiplerle birlikte büyük dil modeli (LLM) tabanlı ajanlar inşa ediyor. Gerçekte başarılı ajan benimseme örnekleri, karmaşık framework’ler veya özel kütüphanelerden çok basit ve birleştirilebilir desenlere dayanma eğilimi gösteriyor. Bu yazı, müşteri iş birlikleri ve kurum içi geliştirme deneyimlerinden elde edilen içgörüleri ve etkili ajanlar inşa etmek için pratik önerileri paylaşıyor.
Ajan Nedir?
Ajanlar farklı şekillerde tanımlanabiliyor.
- Bazıları bunları, dış araçları kullanarak karmaşık görevleri bağımsız biçimde tamamlayan tam otonom sistemler olarak tanımlıyor
- Bazıları ise bunları sınırlı iş akışlarını veya önceden belirlenmiş süreçleri izleyen kuralcı uygulamalar olarak görüyor
Anthropic her iki yaklaşımı da agentic sistemler olarak sınıflandırıyor, ancak iş akışları ile ajanlar arasında önemli bir mimari ayrım yapıyor.
- İş akışları: LLM’lerin ve araçların önceden tanımlanmış kod yolları üzerinden orkestre edildiği yapı
- Ajanlar: LLM’nin araç kullanımını ve süreci kendi başına dinamik olarak belirlediği, görevin nasıl tamamlanacağı üzerinde kontrol sahibi olduğu yapı
Bu yazı, sistemlerin bu iki biçimini ayrıntılı olarak açıklıyor; pratik uygulama örnekleri ise Ek 1’de ele alınıyor.
Ajanlar Ne Zaman Kullanılmalı, Ne Zaman Kullanılmamalı?
Uygulama geliştirirken ilke olarak mümkün olan en düşük karmaşıklıkla başlamak ve ancak gerektiğinde kademeli olarak karmaşıklık eklemek tercih edilmeli.
- Agentic sistemler, bir miktar gecikme/maliyet pahasına görev performansını artırabilir
- Karmaşıklık gerçekten gerekmiyorsa, çoğu durumda tek bir LLM çağrısı; örnek ekleme ve arama entegrasyonu gibi yöntemlerle yeterli çözüm elde edilebilir
- İş akışları öngörülebilirlik ve tutarlılığın önemli olduğu yerler için, ajanlar ise esneklik ve ölçek gereken durumlar için daha uygundur
Framework’ler Ne Zaman ve Nasıl Kullanılmalı?
Agentic sistemleri uygulamayı kolaylaştıran çeşitli framework’ler bulunuyor.
- LangGraph (LangChain)
- Amazon Bedrock AI Agent framework
- Rivet, Vellum vb.
Bu framework’ler, LLM çağrıları, araç tanımı/ayrıştırması ve çağrı zinciri kurulumu gibi düşük seviyeli işleri basitleştiriyor. Ancak aşırı soyutlama, gerçek prompt-yanıt akışını opak hale getirebilir ve gereksiz karmaşıklık riskini artırabilir.
- Geliştiricilerin mümkün olduğunca doğrudan LLM API kullanımıyla başlaması öneriliyor
- Framework kullanılsa bile iç işleyişin tam olarak anlaşılması gerekiyor
Örnek uygulamalar anthropic-cookbook içinde görülebilir.
Yapı Taşları, İş Akışları ve Ajan Desenleri
Anthropic, gerçek operasyon ortamlarında sık kullanılan agentic sistem desenlerini tanıtıyor.
Yapı taşı: Geliştirilmiş LLM
Agentic sistemlerin çekirdeğinde, arama, araçlar ve bellek gibi yeteneklerle güçlendirilmiş bir LLM bulunuyor.
- Model, kendi başına arama sorgusu üretebilir, uygun aracı seçebilir ve bilgi depolayabilir
- Temel uygulama açısından önemli nokta, bu yetenekleri kullanım senaryosuna göre özelleştirmek ve LLM’ye açık ve belgelenmiş arayüzler sunmaktır
Yakın zamanda duyurulan Model Context Protocol sayesinde çeşitli üçüncü taraf araçlarla kolayca entegrasyon kurulabiliyor.
İş akışı türleri
Prompt chaining
- Görev bir dizi adıma bölünür; her LLM çağrısı önceki çıktıyı devralarak işler
- Her adıma programatik doğrulama kapıları eklenerek süreç yönetilebilir
- Kullanım örnekleri: Pazarlama metni oluşturup ardından çevirme, belge taslağı hazırlama → doğrulama → içerik yazımı
Routing
- Girdi sınıflandırılarak uygun sonraki görevlere yönlendirilir
- Her kategori için özelleştirilmiş prompt’lar ve araçlar kullanılabilir
- Kullanım örnekleri: Müşteri taleplerini yönlendirme (iade, teknik destek vb.), zorluk seviyesine göre model seçimi
Paralelleştirme
- Görev daha küçük birimlere ayrılır, paralel işlenir ve sonuçlar birleştirilir
- Sectioning: Her bölüm bağımsız olarak işlenir
- Voting: Aynı görev, farklı bakış açıları veya prompt’larla tekrar çalıştırılır; çoğunluk oyu gibi yöntemler kullanılır
- Kullanım örnekleri: Kullanıcı sorularını filtreleme ve yanıtı ayırma, otomatik değerlendirme, kod inceleme
Orchestrator-workers
- Merkezi bir LLM, görevi dinamik olarak parçalara ayırır ve dağıtır; birden çok worker LLM bunları işler, ardından sonuçlar birleştirilir
- Önceden tanımlı olmayan, girdiye göre değişen alt görevler için uygundur
- Kullanım örnekleri: Birden fazla dosyada değişiklik gerektiren kodlama işleri, karmaşık bilgi keşfi
Değerlendirme-optimizasyon döngüsü
- Yanıt üreten LLM ile değerlendiren LLM tekrar eden bir döngü içinde kullanılır
- Açık değerlendirme ölçütlerinin ve geri bildirim temelli iyileştirmenin değerli olduğu durumlara uygundur
- Kullanım örnekleri: Edebi çeviride ince nüansların değerlendirilmesi, çok turlu bilgi keşfi
Ajanlar
-
LLM’lerin ilerlemesiyle birlikte, gerçek hizmetlerde karmaşık girdileri ele alabilen, akıl yürütme ve planlama yapabilen, araç kullanabilen, hatalardan toparlanabilen ajanlar ortaya çıktı
-
Kullanıcı komutu/konuşmasıyla başlar → görevi netleştirir → otonom biçimde yürütür → ara kontrol noktalarında geri bildirim alabilir → tamamlanma veya durdurma koşulunda sonlanır
-
Gerçek uygulamalarda LLM, ortam geri bildirimini (araç sonuçları, kod yürütme çıktıları) referans alarak yinelemeli çalışır; burada araç seti ve dokümantasyon kritik önemdedir
-
Kullanım örnekleri: SWE-bench görevlerini çözmeye yönelik kodlama ajanı, Claude tabanlı bilgisayar kullanım otomasyonu
-
Kapsam: Belirli yol veya adımların öngörülemediği açık uçlu problemler, karar güvenilirliğinin gerektiği durumlar
-
Artan otonominin getirdiği maliyet ve bileşik hata olasılığı dikkate alınmalı; sandbox testleri ve guardrail’ler zorunludur
Desenleri birleştirme ve özelleştirme
- Tanıtılan yapı taşları katı kurallar değil; farklı durumlara göre birleştirilebilir
- Önemli olan, performansı ölçerek ve yinelemeli iyileştirme yaparak en uygun yapıyı seçmek ve karmaşıklığı kademeli biçimde artırmaktır
Özet ve Önerilen İlkeler
LLM sistemlerinde başarı, karmaşıklık ya da yeni teknolojilerden değil, amaca uygun doğru yaklaşımı bulmaktan gelir.
-
Basit prompt’larla başlayın, performansı değerlendirin, yinelemeli optimizasyon yapın ve karmaşıklığı aşamalı olarak genişletin
-
Ajan tasarımındaki 3 temel ilke
- Sadeliği koruyun
- Şeffaflığa (tasarım aşamasını netleştirmeye) öncelik verin
- Araç/arayüz dokümantasyonu ve testine önem verin
-
Framework’lerle hızlı başlangıç yapılabilir; ancak pratikte soyutlama katmanlarını en aza indirmek ve doğrudan uygulama yetkinliği, güvenilirlik ve bakım kolaylığını belirler
Ek 1: Pratikte Ajan Uygulama Örnekleri
Müşteri desteği
Müşteri desteği alanı, chatbot arayüzü ile araç entegrasyonunun birleşmesi sayesinde ajan kullanımına doğal biçimde uygundur.
- Konuşma tabanlı arayüz ile dış veri ve iş süreçlerini kullanma ihtiyacı aynı anda bulunur
- Araçlar aracılığıyla müşteri bilgileri, sipariş geçmişi ve bilgi tabanı entegre edilebilir
- İade / destek kaydı işlemleri gibi görevler otomatikleştirilebilir
- Çözüm kriterleri açık biçimde tanımlanabilir
Başarıyla uygulanan örneklerde, kullanım miktarına (başarılı çözüm ölçütüne) dayalı ücretlendirme modeliyle ajan etkinliği doğrulanmıştır.
Kodlama ajanları
Yazılım geliştirme ortamlarında da, sorunların otomatik çözümü gibi alanlarda ajanların kullanım değeri önemli ölçüde artıyor.
- Kod, otomatik testlerle doğrulanabilir
- Test sonuçları kullanılarak yinelemeli iyileştirme yapılabilir
- Problem tanımı nettir ve çıktı kalitesi de nesnel olarak ölçülebilir
Anthropic’in kendi uygulama örneği: SWE-bench Verified benchmark’ında, gerçek GitHub issue’ları yalnızca pull request açıklamaları üzerinden çözüldü. Otomatik testlere ek olarak, sistemin genel gereksinimlere uygunluğunu doğrulamak için insan incelemesi hâlâ önemini koruyor.
Ek 2: Araçlar için Prompt Engineering Yöntemleri
Tüm agentic sistemlerde araçlar temel unsurdur.
- Claude gibi LLM’ler, API içinde doğru yapı ve tanımlara uygun biçimde dış servislerle etkileşim kurabilir
- Yanıtlarda tool use block yer alabilir
- Araç tanımı ve spesifikasyonları da prompt engineering kadar ayrıntılı biçimde tasarlanmalıdır
Araç formatı tasarımı için ipuçları
-
Modelin yazım “tuzaklarına” düşmemesi için yeterli token bırakın
-
İnternette sık karşılaşılan doğal formatların kullanılması önerilir
-
Gereksiz biçimlendirme yükünü (ör. kod satırı sayma, string escape etme vb.) en aza indirin
-
İnsan-bilgisayar arayüzü (HCI) tasarımına ne kadar yatırım yapılıyorsa, ajan-bilgisayar arayüzüne (ACI) de o kadar özen gösterilmeli
-
Model açısından aracın anlaşılması ve kullanılması açık olmalı; kullanım örnekleri, sınır koşulları ve giriş formatı gibi unsurlar da yer almalı
-
Parametre adları ve açıklamalar da sezgisel terimlerle, sanki dokümantasyon yazıyormuş gibi tasarlanmalı
-
Gerçek kullanım biçimleri farklı girişlerle test edilmeli ve yinelemeli olarak iyileştirilmeli
-
Hata olasılığını azaltacak şekilde (Poka-yoke) argüman tasarımı yapılmalı
Gerçek SWE-bench ajanı geliştirilirken, genel prompt’tan çok araç tasarımını optimize etmeye daha fazla zaman harcandı. Örnek: Kök klasör dışına çıkıldıktan sonra dosya yolu hatalarını azaltmak için yalnızca mutlak yollar kabul edilecek şekilde değişiklik yapıldı ve sistem kusursuz çalıştı.
1 yorum
Hacker News yorumu
Bu yazının özellikle "AI agents" için tanımı netleştirerek başlaması etkileyici bulunmuş. Buradaki tanım, "LLM'nin süreçleri ve araç kullanımını dinamik biçimde kendi başına yönettiği, görevi nasıl gerçekleştireceğini kendisinin kontrol ettiği sistem" olarak özetleniyor. ‘agent’ ile ‘workflow’ ayrımı yapılması ve çeşitli pratik workflow kalıplarının tanıtılması da beğenilmiş. Yazı ilk yayımlandığında buna dair bizzat hazırlanmış bir özet de var: building-effective-agents notu. Ayrıca yakın zamanda Anthropic'in multi-agent araştırma sistemi kurulum yazısı da ilgi çekici bulunmuş ve bununla ilgili ek notlar da mevcut: multi-agent research system notu
Bu yazıdaki workflow tanımının tam isabetli olmadığı düşünülüyor. Günümüzde workflow motorları çoğu zaman önceden belirlenmiş kod yollarını izlemiyor ve pratikte agent'larla neredeyse aynı şekilde çalışıyor. Yazarın workflow'yu yeniden tanımlaması ayrım yapmak için anlaşılır bulunsa da, gerçekte agent denilen şeyin de yalnızca LLM yanıtlarına göre dinamik olarak çağrılan döngü biçimindeki bir workflow olduğu görüşü dile getiriliyor. Modern workflow motorlarının da oldukça dinamik olduğu savunuluyor
Building Effective Agents yazısının ortak yazarlarından biri, AIE'de bu yazı üzerine bir konuşma yapmış ve çok iyi geri dönüş almış: YouTube videosu
multi-agent araştırmasıyla ilgili yazının gerçekten çok iyi olduğu düşünülüyor, ancak Building Effective AI Agents yazısındaki "framework kullanmadan sistemi sıfırdan kurmanın eğitsel açıdan iyi olduğu" görüşüne katılınmıyor. İyi bir framework kullanmanın ilk avantajı olarak, farklı ve üreticiye bağlı olmayan çeşitli LLM'leri kolayca denemeye imkan vermesi gösteriliyor
Anthropic'in hangi AI agent framework'ünü kullandığı merak ediliyor. Kendi framework'lerini hiç yayımlamamış gibi göründükleri söyleniyor
Ek notlar için teşekkür ediliyor ve bu konunun son dönemde kendileri için de çok önemli bir mesele haline geldiği belirtiliyor
Yapay zeka alanında altı ayın çok uzun bir süre gibi hissedildiği söyleniyor. Birkaç ay önce bu yazının tekrar tekrar okunduğu, ancak artık agent geliştirme tarafının açık biçimde bir darboğaza girmiş gibi göründüğü ifade ediliyor. En yeni Gemini'nin bile hatta geriye gitmiş gibi hissettirdiği düşünülüyor
Birden fazla agent'ı aynı anda çalıştırmanın maliyetli olduğu ve bunun RoI'yi düşürdüğü belirtiliyor. Örneğin hisse senedi odaklı bir DeepSearch agent'ı 6 agent kullanıyor ve sorgu başına yaklaşık 2 dolar maliyet oluşturuyor. Multi-agent orkestrasyonunun kontrol edilmesi zor oluyor; modeller güçlendikçe multi-agent ihtiyacı azalıyor. Tersine, modeller zayıf olduğunda uzmanlaşmış dar kapsamlı yapay zekanın ticari değeri artıyor; bunun gerçek deneyimlerle görüldüğü aktarılıyor
Agent'ların geriye gittiği hissinin neden kaynaklandığı soruluyor. Neden kendi kopyalarını oluşturup 7/24 paralel şekilde çalışarak doğrulama yapıp kendilerini geliştiremedikleri merak ediliyor
Prompt injection sorununu çözmenin çok zor olduğu ve bunun ciddi bir darboğaz oluşturduğu görüşü paylaşılıyor
Agent'ların task queueing, race condition ve diğer eşzamanlılık sorunlarını nasıl ele aldığı merak ediliyor. Multi-agent workflow kurulumuna dair yazılarda sık sık orchestrator agent'ın her şeyi yönettiği anlatılsa da, pratikte daha karmaşık tasarımlar ve daha akıllı glue code gerekip gerekmediği hep sorgulanıyor. Yoksa tüm bunların gerçekten “otomatik sihir” gibi çalışıp çalışmadığına dair kuşku dile getiriliyor
Agent'lar için standart yaklaşımın, araçların sıralı biçimde çalıştırılması olduğu; bu nedenle eşzamanlılık sorunları için fazla endişelenmeye gerek olmadığı anlatılıyor. Artık birçok model paralel tool calling desteklediğinden, model “bu üç aracı çalıştır” dediğinde harness bunları paralel ya da sıralı biçimde çalıştırıp sonuçları sonraki adıma aktarabiliyor. Anthropic ise multi-agent düzenlerini daha yoğun kullanıyor; burada üst seviye bir agent, alt agent'lara işleri paralel biçimde devrediyor. Bu yaklaşımın Claude Code'da kullanıldığı ve ilgili tersine mühendislik notlarında (claude-trace) ve Claude Research'ün nasıl çalıştığını anlatan yazıda (multi-agent-research-system) daha ayrıntılı açıklandığı belirtiliyor. LLM'lerin tool use kalıplarını keşfetme sürecinin hâlâ çok erken aşamada olduğu, modellerin araç kullanımında gerçekten iyi hale gelmesinin de son 6 ay içinde yaşandığı ve bu nedenle ileride büyük gelişme potansiyeli bulunduğu vurgulanıyor
Bu nedenle her şeyi JSON ile ele almak yerine, LLM'nin doğrudan code üreterek tool call'ları yönetmesini tercih etmeye başladığını söyleyenler var. Huggingface'in smolagents kütüphanesi, LLM'nin python fonksiyon çağrısı kodu üretmesi yaklaşımını kullanıyor. Paralel tool calling istenirse bunun prompt içinde açıkça belirtilebildiği ve senkronizasyonun da LLM tarafından yönetilmesi gerektiği söyleniyor. Elbette LLM tarafından üretilen kodun çalıştırılması ayrı bir sorun ama buna yönelik çeşitli çözümler olduğu ekleniyor
Codex web arayüzüyle ilgili bir kullanım deneyimi paylaşılıyor. Tek seferde bitirilemeyecek kadar uzun bir refactoring planı olduğu, bu nedenle “ask” özelliği kullanılarak işin birden fazla göreve bölündüğü ve paralel yapılabilecek görevlerin gruplanmaya çalışıldığı anlatılıyor. LLM'nin işi, gerçek ekiplerin görev paylaşımına benzer biçimde böldüğü, ancak görevler arası iletişim varsayımı olmadığı için bağlam kaybının çok büyük olduğu söyleniyor. Kendi başına yapmaktan daha uzun sürse de denendiği; fakat sonunda birden çok oturum açıp her göreve amaç, yöntem, doğrulama ve dokümantasyon gibi ayrıntılı prompt'lar verilerek sıralı çalışmanın tercih edildiği aktarılıyor. Özetle orchestrator agent'ların çok basit işler için kullanılabildiği ama uygulama alanlarının düşünüldüğünden daha sınırlı olduğu yönünde pratik bir gözlem paylaşılıyor
Hiçbir şeyin sihirli şekilde otomatik çalışmadığı savunuluyor. Geleneksel sistemlerde önem verilen operasyonel özelliklerin AI agent'lar için de mutlaka geliştirilmesi gerektiği söyleniyor. Sadece AI agent demolarına bakıp “spagetti kodlu bir ekibin yazdığı kodu birkaç temiz AI prompt'u ile değiştirebiliriz” diye düşünmenin yanıltıcı olabileceği uyarısı yapılıyor. Bunun bazı dar örneklerde işe yarayabileceği, ancak sonuçta sistemdeki tüm kodların bir varlık sebebi bulunduğu; iş o kodların tamamını LLM'ye çevirmeye kadar gidiyorsa yön duygusunun kaybolduğu ifade ediliyor
Kodlama agent'ları tarafında ortaya çıkan kalıplardan birinin, işleri container içinde izole etmek ve çıkan işi git ile gözden geçirip merge etmek olduğu belirtiliyor. Örnek olarak container ve MCP kullanımını gösteren container-use veriliyor ve bunun paralel kod çalışmaları için yararlı olduğu söyleniyor. Bunun dışındaki işlerde ise n8n, Zapier ve CrewAI gibi workflow builder'ların hâlâ sık kullanıldığı belirtiliyor
Bu yazının, “en basit şeyle” başlayıp yalnızca gerçek karmaşıklık gerektiğinde ekleme yapma mesajını hatırlattığı söyleniyor. Net tanımlanmış LLM çağrıları ve biraz basit glue logic ile daha güvenilir, daha kolay debug edilen ve daha düşük maliyetli sistemler kurulabileceği ifade ediliyor. Buna karşılık gösterişli görünen agent sistemlerinin çoğu zaman daha fazla probleme yol açtığı belirtiliyor
Yapay zekanın insanlara gerçekten faydalı olan bir şeye dönüşmesi yönünde bir umut dile getiriliyor
Anthropic'in bu tür teknik bilgiler sunmasının güzel olduğu, ancak uzman olmayanlar için daha kolay bir rehber sürüm de sunması gerektiği düşünülüyor. Örneğin pazarlama departmanında agent kullanmak isteyenlerin, en azından temel düzeyde gereksinim tanımlayabilecekleri bir kılavuza ihtiyaç duyacağı söyleniyor. Yazının son kısmı ve eklerinde buna değinilse de, hâlâ daha çok “nasıl inşa edilir” sorusunun uygulama boyutunda kaldığı eleştirisi yapılıyor
(Aralık 2024 - şimdi dönüp bakınca çok eskiymiş gibi hissedilen bir zaman)
Bu yazının zamana çok iyi dayandığı söyleniyor. Kişisel olarak hâlâ sürekli başvuru kaynağı olarak kullanıldığı ve zaman geçmesine rağmen eskimiş hissettirmediği belirtiliyor. Anthropic'in “gerçek anlamda faydalı AI araçları geliştiren bir ortak” olarak yeni bir izlenim bıraktığı değerlendiriliyor
Agent'lara dair aşırı hype'ın artık büyük ölçüde sönmüş olduğu görüşü paylaşılıyor
Bu yazının o dönemde de tartışılmış olduğu bilgisi paylaşılıyor: orijinal HN tartışması
Yazının abartıya ya da modaya kapılmadan gerçekçi yaklaşımını koruması beğeniliyor. Pek çok kişinin modaya uyarak agent sistemleri inşa ettiği, ama gerçekten bu iş için bir agent gerekip gerekmediğini düşünmeden ilerlediği yönünde eleştirel bir bakış sunuluyor