Yazar: Yanhua
Antonio Gullí, Google'nün mühendislik direktörüdür. 453 sayfalık bir kitap yazarak AI Agent geliştirme sürecini 21 tasarım kalıbına ayırmıştır.
Ancak bu bir kitap incelemesi değil. Bu kitabı okuma motivasyonum çok spesifik: Harness Engineering yazdım, Clawdbot'un deneyimlerini paylaştım, “AI ajanları sihir değil” adlı, Token yakmaktan gerçekten kullanışlı hale gelene kadar olan yedi dönüm noktasını anlattım; her yazımın ardından tam olarak cevaplanamayan bir soru kaldı: Bunların arkasında tekrar kullanılabilir bir alt yapı var mı?
Bu kitap bana cevap verdi ve beklentimden daha derin oldu.
Yazdığınız muhtemelen tamamen bir Agent değil
Kitabın en sert kararı prolojede saklı.
Çoğu insanın kullandığı “Yapay Zeka”, Level 0: Araçsız, hafızası olmayan, eylemde bulunamayan açık LLM. 2025 Oscar En İyi Film'i hangisi diye sorarsanız, tahmin eder. Kitapta bunu çok açıkça belirtiyor: Level 0 şeyleri Agent değildir.
Yukarı doğru gitmek gerçek Agent:
Düzey 1: Araç Kullanıcıları
Ajan artık araçları kullanmaya başladı: arama, API, veritabanı. Ancak sadece “arayüz çağırma yeteneğine” sahip olmak değil, aynı zamanda ne zaman çağırması gerektiğini, hangi arayüzü çağırması gerektiğini ve sonuçları nasıl kullanacağını kendi başına karar verebilmesi gerekiyor. Kitapta çok spesifik bir örnek veriliyor: Kullanıcı “son zamanlarda hangi yeni diziler var?” diye soruyor; ajan, bu bilginin eğitim verilerinde olmadığını kendi başına fark ediyor ve sonuçları sentezlemek için aktif olarak arama aracını çağırıyor. Anahtar adım “kendi başına fark etmek”. İnsanlar “biraz araştır” demiyor, ajan kendi kendine arama yapması gerektiğini anlıyor. Bu karar verme yeteneği, Level 1’in eşikidir.
Düzey 2: Stratejik Düşünür
İki şey daha eklendi: planlama ve Bağlam Mühendisliği. Kitap, Bağlam Mühendisliğini şu şekilde tanımlıyor: bilgi yığını oluşturmak yerine, bağlamı dikkatle seçmek, kırmak ve paketlemek. Örnek çok etkileyici: Kullanıcı, iki konum arasında bir kafe arıyor. Ajan önce harita aracını çağırarak bir dizi veri alır, ardından kendi kararını verir: "Sonraki adım yalnızca cadde adları gerekiyor" ve harita çıktısını kısa bir liste haline getirir, ardından yerel arama aracına verir. Her adımda bilgi gürültüsü azaltılır.
Kitapta bir cümle var, birkaç kez okudum: “AI'nın en yüksek doğruluk oranına ulaşması için ona kısa, odaklı ve etkili bir bağlam verilmelidir.” Context Engineering, tam olarak bu işi yapar.
Bu seviyeye ulaştığında, Agent kendini yansıtabiliyor. İşini bitirdikten sonra kendisi kontrol ediyor, sorunları kendisi düzeltiyor. Daha sonra detaylı anlatacağım.
Düzey 3: Çok Ajan İşbirliği
Kitabın tutumu net: Tüm-powerful bir super agent yaratmaya odaklanmayın. Gerçekçi yaklaşım, proje yöneticisi agent + araştırmacı agent + tasarımcı agent + içerik yazıcı agent gibi bir ekip kurmaktır. Kitap, yeni bir ürünün piyasaya sürülmesi örneğini verir: Bir “proje yöneticisi agent” genel koordinasyonu yapar, “pazar araştırması agent”ına, “ürün tasarımı agent”ına, “pazarlama agent”ına görevler dağıtır. Anahtar iletişimdir: Agent’lar arasında veri nasıl aktarılır, durumlar nasıl senkronize edilir, çatışmalar nasıl çözülür? Bu bölüm, en basit tek agent’tan en esnek özelleştirilmiş karma yapıya kadar altı farklı iletişim topolojisi gösterir ve her birinin hangi senaryolarda uygun olduğu açıklanır.
Bu dört seviyeyi gördükten sonra neden birçok kişinin “Agent’ım iyi çalışmıyor” dediğini anladım. Model sorunsuz, sorun sizin onu bir sohbet robotu gibi kullandığınızda, belki Level 1’e bile ulaşamıyor.
Başlık: Kitaptaki En Az Değerlendirilen Kavram
Harness Engineering adlı bir makale yazmıştım, burada yarış pistinin tasarımı, motorun beygir gücünden daha önemliydi. Bu kitabı okuduktan sonra, Context Engineering'in, prompt düzeyindeki Harness Engineering'in bir yansıması olduğunu fark ettim.
Geleneksel Prompt Mühendisliği yalnızca “nasıl soracağınız” ile ilgilenir. Kitaptaki Bağlam Mühendisliği, “sorudan önce, Ajanın önündeki ne olduğunu” yönetir. Bu dört katman bilgiyi içerir:
Birinci katman, sistem talimatı. Agent'in kim olduğunu, hangi tonu ve hangi sınırları tanımlar. Çoğu kişi sadece bu katmanı yazar.
İkinci katman, dış veriler. RAG tarafından alınan belgeler, araç çağrısının dönüş değerleri, gerçek zamanlı API verileri. Bu, çoğu kişinin takıldığı yer: veri vermek gerektiğini biliyor, ancak modeli boğmadan nasıl verileceğini bilmiyor.
Üçüncü katman, örtük veriler. Kullanıcı kimliği, etkileşim geçmişi, ortam durumu. Açıkça söylemediniz ancak Agent'in bilmesi gereken şeyler. Örneğin, Agent'e "Yarının toplantısını John'a onaylamak için bir e-posta gönderir misin?" diyorsanız, Agent'in yarının toplantısının ne olduğunu ve John ile olan ilişkinizi biliyor olması gerekir.
Dördüncü katman, geri bildirim döngüsü. Agent her çıktı verdiğinde, kalitesini otomatik olarak değerlendirir ve bir sonraki bağlam stratejisini ayarlar. Kitap bunu “otomatikleştirilmiş bağlam optimizasyonu” olarak adlandırıyor; Google’ın Vertex AI Prompt Optimizer’ı bu fikrin mühendisliksel bir uygulamasıdır.
Burayı okurken daha önce yazdığım “AI Akıllı Ajanlar Sihir Değildir” adlı makaleyi hatırladım; orada bir deneyim olarak “Akıllı ajanınıza kurallar gerekiyor, ve çok sayıda kural” demiştim. Şimdi geri dönüp bakınca, bu kurallar temelde Context Engineering’in el ile yapılan bir versiyonuydu; kitap bunu sistematikleştirmiş.
Reflection: İki Agent gerçekten bir taneden daha iyi
Bu kitapta benim için en pratik değere sahip Desen.
Reflection'in temeli basittir: Agent işini bitirdikten sonra kendi çalışmalarını gözden geçirir, sorunları kendisi düzeltir. Ancak uygulama şekli önemlidir. Kitap açıkça belirtiyor: Producer ve Critic, farklı sistem promptları ile iki farklı Agent olmalıdır. Aynı persona, kendi çalışmalarını gözden geçirdiğinde mutlaka gözden kaçırmalar yapar. Aynı LLM'ye kod yazdırıp ardından yazdığı kodu kendisinin incelemesini isterseniz, büyük olasılıkla "çok iyi" diyecektir.
Kitap, tam bir kod örneği sunuyor.
Producer'un talimatı: “Bir Python geliştiricisisiniz, sınır koşullarını ve istisnaları işleyen bir faktöriyel hesaplayan fonksiyon yazın.”
Critic'in promptu: “Siz, kodu satır satır inceleyen, hataları, tarzı, atlanan sınır durumlarını ve iyileştirilebilecek noktaları kontrol eden ısrarcı bir üst düzey mühendissiniz. Eğer mükemmelse
CODE_IS_PERFECTçıktısı verin, aksi halde tüm sorunları listeleyin.”Ardından bir for döngüsü: Üretici kod yazır → Eleştirmen inceleyir → Üretici yorumlara göre düzenler → Eleştirmen tekrar inceleyir → Eleştirmen
CODE_IS_PERFECTder veya maksimum yineleme sayısı ulaşana kadar devam eder.
Bu kadar basit. Ancak kitap, her yansıma döngüsünün yeni bir LLM çağrısı olduğunu ve yineleme sayısı arttıkça maliyetin arttığını, diyalog geçmişi büyüdükçe bağlam penceresinin önceki sürümler ve eleştirilerle dolup da gerçek olarak kullanılabilir akıl yürütme alanının daraldığını hatırlatıyor. Bu nedenle Reflection için en iyi uygulama: makul bir maksimum yineleme sayısı belirlemektir (kitapta 3 kullanılıyor), Eleştirmen memnun olduğunda durun ve mükemmelliği aramayın.
Kod yazmanın ötesindeki kullanım alanları çok daha geniş. Makale yazmak, plan yapmak, belgeleri özetlemek, mantık sorularını çözmek—Producer-Critic modeli bunların hepsine uygulanabilir. Kitapta yedi farklı kullanım senaryosu listelenmiştir; temel mantık her zaman aynıdır: önce üret, sonra incele, ardından düzelt.
Çoklu Ajan daha karmaşık olmak zorunda değil
Multi-Agent Collaboration bölümünde en çok sevdiğim altı iletişim topoloji şeması. Birçok kişi hemen karmaşık şeylere girişir, ancak çoğu senaryoda üç tanesi yeterlidir:
Tek Agent (bağımsız yürütme): Görev, birbirinden bağımsız alt sorunlara ayrılabilir; her Agent kendi görevini kendi başına çözer. Basit ve kolay bakımlı.
Noktadan noktaya (Peer-to-Peer): Ajanlar arasında merkezi bir kontrol düğümü olmadan doğrudan iletişim kurulur. Merkeziyetsizdir ve hata toleransı yüksektir; bir ajanın çökmesi genel sistemi etkilemez. Ancak koordinasyon maliyeti yüksektir ve kaosa yol açabilir.
Yönetici (Merkezi Koordinasyon): Bir Yönetici Agent, bir grup Çalışan Agent'i yönetir. Görevleri atar, sonuçları toplar, çatışmaları çözer. Katmanlı yapı, yönetimi kolaylaştırır. Ancak Yönetici, tek bir hata noktası ve performans darboğazıdır.
Diğer üçü (Supervisor-as-Tool, hiyerarşik, özelleştirilmiş karışık), ilk üçünün varyasyonları ve kombinasyonlarıdır. Kitapta çok net bir şekilde belirtiliyor: ihtiyacınız olan topoloji, görevinizin karmaşıklığına bağlıdır. Görev ne kadar küçük parçalara ayrılırsa, iletişim maliyeti o kadar artar; belirli bir noktadan sonra Supervisor modeli, hiyerarşik modele göre daha verimli olur.
Benim deneyimim, birçok kişinin Multi-Agent kurarken %80 zamanını iletişim protokolüne harcadığı ve daha temel bir soruyu sormayı unuttuğu: Bu görev gerçekten birden fazla Agent gerektiriyor mu? Kitapta açıkça belirtildiği gibi, Level 2 tek bir Agent + Reflection genellikle yeterlidir. Level 3, tek bir Agent'in gerçekten başa çıkamadığı senaryolar için hazırlanmıştır.
Memory üç katmanlı model, daha önce belirsiz bir şekilde hissetmiştim ama adlandırmamıştım
Memory bu bölümde en çok benimle özdeşleştiğim kısım, çünkü Obsidian + Claude üzerine yazdığım iki makale sırasında sürekli bir soru üzerinde düşünüyordum: Agent'in hafızası nasıl katmanlandırılmalı?
Kitapta cevap verilmişti:
Oturum (oturum katmanı): Geçerli diyalogun bağlam penceresi, bu en kısa hafıza olup, diyalog sona erdiğinde kaybolur. Uzun bağlam modelleri sadece bu pencereyi genişletir, ancak temelde hâlâ geçicidir ve her çıkarım sırasında tüm pencere işlenir, bu da hem pahalı hem de yavaştır.
State (Durum Katmanı): Geçerli görevin geçici verileri. Örneğin, “Şu anda hangi görev yapılıyor”, “Hangi adıma kadar tamamlandı”, “Hangi ara veriler üretildi”. Session’dan uzun, ancak görev bittiğinde temizlenir. Kitap, Google ADK’nın State mekanizmasını tam bir örnek ile göstermektedir.
Memory (kalıcı katman): Oturumlar ve görevler arasında uzun vadeli hafıza. Kullanıcı tercihleri, kazanılan deneyimler, önemli geçmiş kararlar veritabanında veya vektör kütüphanesinde saklanır, semantik arama ile erişilir. Kitap, Memory'nin sadece saklanmasından ziyade "ne saklanmalı, ne zaman saklanmalı, nasıl aranmalı" gibi tam bir stratejinin tasarlanmasının çok önemli olduğunu vurguluyor. Çok fazla saklamak gürültü artırır, çok az saklamak yetersiz kalır.
Daha önce Clawdbot hakkında yazdığım makalede "durum dosyası" ve "çalışma alanı belgesi" ifadelerini kullanmıştım; bu aslında State katmanını ve Memory katmanını elle oluşturmak demekti, kitap bu işi çerçevelendirdi.
Beş varsayım, beşincisi en saçma
Kitabın sonunda, Agent'in geleceğiyle ilgili beş varsayım sunuldu; ilk dördü hâlâ mantıklı tahminler kapsamında: genel amaçlı Agent'in kod yazmaktan projeleri yönetmeye geçmesi, derin kişiselleştirilmiş şekilde ihtiyaçlarınızı aktif olarak keşfetmesi, gövdeli akıllılığın ekranlardan çıkıp fiziksel dünyaya geçmesi, Agent'in bağımsız ekonomik bir varlık haline gelmesi.
Beşincisi beni şok etti: Değişken Çok-Ajan.
Hedefi yalnızca belirtin, örneğin: "Kaliteli kahve satan bir e-ticaret işi kurmak." Sistem otomatik olarak "Pazar Araştırması Agenti" ve "Marka Agenti" oluşturur. Bir veri döngüsü tamamlandıktan sonra, sistem kendi kendine "Marka Agenti"nin gerekli olmadığını anlar ve bunu üç yeni Agent'e ayırır: "Logo Tasarımı Agenti", "Web Sitesi Oluşturma Agenti", "Tedarik Zinciri Agenti". Eğer Web Sitesi Oluşturma Agenti bir darboğaz haline gelirse, sistem otomatik olarak üç paralel Agent oluşturur ve bunlar farklı sayfalar üzerinde aynı anda çalışır. Tüm süreç boyunca, sistem her Agent'in prompt'larını sürekli otomatik olarak optimize eder ve ekip yapısını yeniden düzenler.
Kitap bunu "hedef odaklı, kendi kendini dönüştüren çok ajan sistemi" olarak adlandırıyor. Yazdığınız planı gerçekleştirmiyor, kendi planını oluşturuyor, kendi planını ayarlıyor ve kendi yürütme ekibini yeniden yapılandırıyor.
Bu, Karpathy'nin AutoResearch'ini hatırlatıyor: Bir program.md yazın, hedefleri, metrikleri ve sınırları tanımlayın, ardından "başlatın". İnsan döngünün dışında kalır. Ancak bu kitap daha da ileri gidiyor: Agent ekibinin nasıl kurulacağını ve nasıl yeniden yapılandırılacağını bile sisteme bırakıyor. İnsanlar sadece "ne istediğini" bildiriyor.
Hemen yapabileceğiniz üç şey
Bu kitabı okuduktan sonra hemen uygulayabileceğim üç eylem var:
Birinci olarak, mevcut Agent'inize bir Critic ekleyin. Claude Code, CrewAI veya kendi kurduğunuz herhangi bir çerçeveyi kullanıyor olmanıza bakılmaksızın, mevcut iş akışınızın sonuna bir adım ekleyin: Başka bir Agent (farklı bir sistem promptu kullanarak) önceki adımın çıktısını incelesin. Kod üretimi için kod incelemesi, makale yazımı için gerçeklik doğrulama, planlama için uygunluk değerlendirmesi. Bir kez daha LLM çağrısı yapın, ancak kalite genellikle iki katına çıkar. Kitaptaki Producer-Critic modeli tak-çalıştır özelliğine sahiptir.
İkinci olarak, yalnızca Prompt Mühendisliği değil, Context Mühendisliği'ne başlayın. Agent'e yazdığınız talimat dosyasına geri dönün. Eğer tümü "Ne yapmalısın" kurallarından oluşuyorsa ve "Şu anda hangi ortamla karşı karşıyasınız" bağlamı eksikse, ekleyin. Agent'e şu anda hangi projede olduğunu, daha önce hangi kararları aldığını ve kullanıcı tercihlerinin ne olduğunu söyleyin. Kitaptaki Context Mühendisliği bölümü ve
AGENTS.mddosyanız aynı şeyin iki ifadesidir.Üçüncü olarak, hemen Multi-Agent'e geçmeyin. Tek Agent'inizi Level 2'ye getirin: Araçlar, Reflection ve Memory ile. Kitapta tekrar tekrar vurgulandığı gibi, Level 2 tek Agent, Producer-Critic ve Context Engineering ile çoğu gerçek dünya senaryosunu kapsar. Level 3, gerçekten çoklu alanlara, çok aşamalı ve paralel görev paylaşımı gerektiren görevler için hazırlanmıştır. Çoğunluğun sorunu Agent sayısının yetersizliği değil, bir Agent'in bile iyi ayarlanmamış olmasıdır.
Bu kitap 453 sayfa olup Springer tarafından 2025 yılında yayınlanmıştır. Kod örnekleri LangChain/LangGraph, Google ADK, CrewAI ve OpenAI API'yi kapsamaktadır. Önsöz, Google Cloud AI Başkan Yardımcısı tarafından yazılmıştır ve Goldman Sachs CIO'sunun bir önerisi de bulunmaktadır, beklenmedik şekilde harikadır.
Ancak bunu önermemin nedeni “kapsamlı” olması değil; okuduktan sonra bir şeyin farkına varacaksınız: Geçen altı aydır Agent üzerinde yaşadığınız tüm zorluklar, zaten bir model halinde düzenlenmişti. Reflection’ı yeniden icat etmenize gerek yok, Memory’nin nasıl katmanlandırılacağını tahmin etmenize gerek yok, Multi-Agent için hangi iletişim topolojisinin kullanılacağını denemenize gerek yok.
Haritayı senin için çizen var, geriye kalan yürüyüş.
AI Agent ile geliştirme yapıyor musunuz? Şu anki Agent'iniz kaçıncı seviyede?