Graph Engineering Nedir? LangGraph ile Çoklu Aracıyı Yöneten Uygulamalı Bir Rehber

Bir aracıya tek bir iş verin, fena yapmaz. Üç iş verin ve ikinci devretme civarında olanları izleyin: birinci adımda bulduğu şeyleri unutur, kendi taslağını cömertçe puanlar ve çıktı henüz bitmemişken başarı ilan eder.

Bu kalıp hakkındaki tartışma Temmuz 2026 ortasında alevlendi; “graph engineering” X’te (eski Twitter) gündeme gelince zaman akışı anında ikiye bölündü: bir yanda aracı döngüsünün ölümünü ilan edenler, öte yanda terimi içerik çiftliği dolgusu olarak niteleyenler.

Benim görüşüm, graph engineering etiketinin isteğe bağlı, alttaki ölçek büyütmenin ise isteğe bağlı olmadığı yönünde; koda geçmeden önce bunu gerekçelendirmeye çalışacağım.

Bu ay inşa edeceklerinizin çoğu hâlâ tek bir döngü olmalı; tek işlik bir görev için 6 kutulu bir diyagram çizmek bir haftayı çöpe atmanın en hızlı yoludur.

Kısaca Graph Engineering

Bir aracı grafiğinin 3 parçası vardır:

• Düğümler işi yapar.
• Kenarlar sırada neyin çalışacağını belirler.
• Aralarında, o ana kadar üretilen her şeyi taşıyan, ortak bir nesne dolaşır.

Yazarın görseli. Daha sonra kuracağımız boru hattında gösterilen 3 parça: 3 isimli düğüm, bir geçiş kenarı ve bir yeniden deneme kenarı; konu, notlar, taslak ve hükmü toplayan tek bir durum nesnesi.

Üçünün hepsini en baştan ilan etmek, tek bir aracının kendi yolunu doğaçlamasına bırakmamak, graph engineering teriminin tarif ettiği şeydir.

Bu eğitim, başarısız taslakları revizyona gönderen koşullu bir kenar dahil olmak üzere, Python ve LangGraph ile çalışan bir araştırmacı, yazar ve değerlendirici boru hattı kurar.

Python, pip ve büyük dil modelleri (LLM’ler) veya yapay zekâ aracılarıyla bir miktar aşinalık gerekir. Aracılar sizin için yeniyse, Yapay Zekâ Aracılarına Giriş kursumuz bu yazının varsaydığı kavramları, LangGraph aracıları eğitimi ise uygulamalı kısmı kapsar.

Graph Engineering Nedir?

Graph engineering, bir aracı sisteminin kontrol akışını modelin takdirine bırakmak yerine kodda açıkça tanımlama pratiğidir.

Hangi uzmanlaşmış işçilerin var olduğunu, aralarındaki hangi geçişlerin izinli olduğunu ve bu geçişler boyunca hangi bilginin taşındığını beyan edersiniz.

Aracı yine serbestçe akıl yürütür, ama bunu tüm iş boyunca değil, tek bir düğüm içinde yapar.

Son cümle tüm ayrımı anlatır.

Bir döngüde, bir hedef ve bir kalite çıtası belirlersiniz ve aracı bunları aşmak için kendi yolunu seçer. Bir grafikte ise yolu ve kontrol noktalarını sabitlersiniz; böylece modelin özerkliği bir diff’te okuyabileceğiniz bir yapıyla sınırlandırılır.

Etiket Temmuz 2026’da X’te yükseldi ama orada başlamadı. CodiumAI’nin (şimdi Qodo) kurucusu Itamar Friedman, Şubat 2024’te “prompt engineering’den flow (/graph) engineering’e” bir kaymadan söz etmişti ve ekiplerinin AlphaCodium makalesi bunu sayılarla ortaya koydu.

GPT-4’ün CodeContests doğrulama setindeki pass@5 doğruluğu, iyi tasarlanmış tek bir prompt ile %19’dan çok aşamalı bir akışla %44’e çıktı. Her iki koşulda da problem başına 5 deneme var, tek atış değil.

Temmuz 2026’da olan şey büyütmeydi.

18 Temmuz’da Peter Steinberger, Mike Masson’ın merdiveni (prompt, bağlam, koşum, döngü, grafik) paylaşmasından bir hafta sonra X’te şunu sordu: “Hâlâ döngüleri mi konuşuyoruz yoksa artık grafiğe mi geçtik?” Soru 3,1 milyon görüntülenme aldı ve yaydığı ifade zaten kullanılıyordu.

Tepki hızlı geldi. LangGraph’ın arkasındaki ekipten bir LangChain kurucu ortağı olan Harrison Chase, bunun aslında sadece langgraph olup olmadığını sordu.

Dale Everett ise diğer taraftan bastırdı; bir döngünün her zaman tek düğümlü bir grafik olduğunu, dolayısıyla Temmuz heyecanının eski bir zeminin yeniden keşfi olduğunu savundu. LangChain’in kendi geriye dönük incelemesi, LangGraph ile 3 Yıl Graph Engineering, benzer bir çizgi izleyerek aracı grafikleri 3 yıldır inşa ettiği bir desen olarak çerçeveler.

Ben bu terimi faydalı bir kısaltma olarak dosyalıyorum.

Eskiden çerçeve dokümantasyonunda gömülü duran tasarım sorularına ortak bir ad verdi ve bir ad, bir çekme isteğinde mimari tartışırken işe yarar.

Graph engineering olmayanlar

Graph engineering yürütme yapısını tanımlar; böylece kelime dağarcığını ödünç alan iki şeyden ayrılır.

Bilgi grafikleri ve GraphRAG veriyi tanımlar.

Belgeleri varlık ve ilişkiler hâline getirirler ki bir getirme sistemi olgular arasındaki bağlantıları dolaşabilsin; araçlar, depolama ve değerlendirme ölçütleri bütünüyle farklıdır.

Bu taraf için, bir RAG uygulamasını bilgi grafiğiyle gerçekleştirme eğitimimiz doğru başlangıç noktasıdır; graf kuramına giriş yazımız ise her ikisinin altında yatan matematiği kapsar.

İkincisi, yeni bir yetenek değildir.

LangGraph, Google’ın Agent Development Kit’i (ADK) ve Microsoft AutoGen, etiket viral olmadan önce çoklu aracı orkestrasyonunu yayınladı; dolayısıyla bir StateGraph yazdıysanız bunu zaten yapıyordunuz.

Pek çok okuyucu, “benim LangGraph boru hattım” adı altında bir yıldır graph engineering yaptığını fark edecektir.

Yapay zekâ mühendisliği merdiveni

Yapay zekâ mühendisliğinin her katmanı, modelden bir adım daha dışarıdaki bir şeyi kontrol altına alır.

Bu tabloyu okumanın faydalı yolu sağ sütundur; atlanan bir basamak üzerine inşa etmeye kalktığınızda gerçekte neyin bozulduğunu söyler.

Bir basamağı atlamak, grafik projelerinin en yaygın başarısızlık yoludur ve bu başarısızlık nadiren barizdir.

Üç güvenilmez düğümü birbirine bağlamak, güvenilir bir sistemin ortalaması etmez.

Daha fazla yerde arızalanan, arıza başına daha pahalıya mal olan ve kötü çıktının artık ona sebep olan düğümden 2 devretme uzakta olması nedeniyle tanısı daha uzun süren bir sistem üretirler.

Bir Aracı Grafiğinin 3 Yapı Taşı

İster 3 düğümlü ister 30, her aracı grafiği düğümlere, kenarlara ve paylaşılan duruma ayrışır.

Bu 3 parçayı bir kod tabanında adlandırabildiğinizde, çoğu orkestrasyon çerçevesi belgeleri olmadan da okunur hâle gelir.

Düğümler: işçiler

Bir düğüm, adı ve tek bir sorumluluğu olan bir iş birimidir.

Özel bir isteme ve kendi araçlarına sahip bir LLM çağrısı olabilir; ya da bir veritabanını sorgulayan, bir şemayı doğrulayan ya da bir dosya yazan sıradan bir Python işlevi olabilir.

Model çağrılarını, anlamsal yargı gerektiren adımlar için saklayın.

Bir kuralın bilinen bir yanıtı varsa onu Python’a koyun; mikro saniyelerde çalışır, hiçbir maliyeti yoktur ve iki kez aynı sonucu döndürür.

Bir şeyi bölüp bölmemem gerektiğine dair kullandığım test şudur: düğümü bağlaç kullanmadan tek cümlede tanımlamayı deneyin.

“Kaynakları çeker ve yeterli olup olmadığımıza karar verir” diyen bir düğüm bu testi çoktan geçememiştir; çünkü getirme yarısını, yargı yarısını bozmadan değiştiremezsiniz.

Kenarlar: yönlendirme

Bir kenar, mevcut düğüm bittikten sonra neyin çalışacağını belirler.

Dört şekil, inşa edeceklerinizin neredeyse tamamını kapsar:

• Düz. A düğümünü bitir, B düğümünü başlat.
• Koşullu. Bir yönlendirme işlevi mevcut durumu okur ve bir sonraki düğümün adını döndürür. Bir değerlendiricinin hükmünün bir dala dönüştüğü yer burasıdır: onayla ve bitir, reddet ve taslağı yazara geri gönder.
• Dağıt (fan-out). Bir düğüm aynı anda çalışan birkaç düğümü başlatır. Beş kaynağı ardışık kuyruğa almak yerine eşzamanlı sorgulamanın yolu budur.
• Topla (fan-in). Paralel dallar, sonuçlarını birleştiren tek bir düğümde yeniden birleşir.

Kenarlar aynı zamanda durdurma mantığınızın da yeri olmalıdır. Yeniden deneme sınırları, kalite kapıları ve yükseltme kuralları birer yönlendirme kararıdır ve bunları kenar işlevlerinde tutmak, kontrol akışını düğüm gövdelerinde avlamak yerine tek bir yerde denetleyebilmenizi sağlar.

Paylaşılan durum: sistemin belleği

Paylaşılan durum, çalıştırma ilerledikçe her düğümün okuduğu ve yazdığı tek nesnedir.

Olmadan, bitişik işler yapan ve birbirine hiçbir şey aktarmayan birkaç aracıya sahip olursunuz; dolayısıyla yazar, araştırmacının bulduklarını göremez ve değerlendirici de ikisini birden göremez.

LangGraph’ta durum genellikle bir TypedDict’tir.

Bizimkisi konuyu, araştırmacının notlarını, mevcut taslağı, değerlendiricinin hükmü ve geri bildirimini ve bir revizyon sayacını biriktirir. Her düğüm yalnızca değiştirdiği alanları döndürür ve çerçeve bu döndürmeleri çalışan nesneye birleştirir.

Yazma sahipliği, grafiklerin önce bozulduğu yerdir.

Hangi alanı hangi düğümün yazabileceğine koda başlamadan karar verin; çünkü 3 farklı düğümün üzerine yazabildiği bir durum nesnesi, kendinize çoktan planlamış olduğunuz bir hata ayıklama oturumudur.

Döngü Mühendisliği vs Graph Engineering: Hangisi Ne Zaman?

Döngü mühendisliği, tek bir aracının bitirene kadar tekrarladığı çevrimi tasarlar; graph engineering ise bu çevrimlerden birkaçının koordinasyonunu tasarlar.

Bu yazıdaki en sonuç doğurucu karar budur; bu yüzden eğitimden önce gelir.

Varsayılan cevap döngüdür.

Sıkı bir doğrulayıcıya sahip, kapsamı iyi belirlenmiş tek bir aracı; aynı işi yapan herhangi bir grafikten daha hızlı inşa edilir, daha ucuza çalışır ve hata ayıklaması çok daha kolaydır.

Bu yalnızca benim tercihim değil.

UC Berkeley ekibi (ilk yazar Mert Cemri), çoklu aracı kurulumların tek aracıya göre kazançlarının sıklıkla sınırlı olduğu gözleminden yola çıkıp 7 çoklu aracı çerçevesinden 1.600+ yürütme izini açıklamak için etiketliyor (arXiv:2503.13657, v3).

Bu izlerin 150’sinin yakından okunmasıyla inşa edilen sınıflandırmaları 14 ayrı arıza türü tanımlar.

Bu 14 tür, sistem tasarımı sorunları, aracılar arası uyumsuzluk ve görev doğrulaması olmak üzere 3 kategoriye ayrılır.

Üçüncüsünü değerlendirici düğüme gelene kadar aklınızda tutun.

Karar tablosu: döngü mü grafik mi

Bunları bir kontrol listesi değil, tetikleyiciler olarak değerlendirin.

Sağ sütunda net bir “evet” yeterlidir; 5 muğlak işaret yeterli değildir.

En sık karşılaştığım aşırı mühendislik örneği, aslında aracılarla bile ilgili değildir. Birinin 800 otel adresini temizleyip jeokodlaması gerekir ve iş, yükleyici, normalleştirici, jeokodlayıcı, doğrulayıcı ve yazıcı düğümlerinden oluşan 5 düğümlü bir grafik olarak gelir; arada paylaşılan durum dolaşır.

Bu adımların her biri deterministiktir; yani gerçekte inşa ettikleri şey, bir çerçeve kılığına girmiş 40 satırlık bir Python betiğidir; artık satır başına para tutar ve pandas’ın asla etmeyeceği şekillerde arızalanır.

Doğru boyuttaki sürüm, şimdi kuracağımızdır.

Kısa bir araştırılmış bilgilendirme notu üretmek, tek bir döngünün zorlandığı işe ayrılır: ham malzeme toplamak, onu düz yazıya çevirmek ve sonra o yazıyı dışarıdan yargılamak.

Üçüncü adım grafiğin var olma nedenidir; çünkü bir aracının kendi taslağını değerlendirmesi değerlendirme değildir.

Grafiğin hakkını verdiğine dair sinyaller

Üç şey bir düğümü haklı çıkarır.

Eklediğiniz her düğüm için bunlardan birini gösteremiyorsanız, düğümü silin ve işini bir komşuya katlayın.

Gerçek uzmanlaşma önce gelir.

Araştırmacımız ucuz, hızlı bir model ve üretimde arama araçları ister. Yazar bunların hiçbirini istemez ve daha güçlü bir modelden fayda görür; dolayısıyla ayrım, bir diyagramı süslemek yerine iş yapmaktadır.

İkincisi, gerçekten fark edeceğiniz paralellik.

Fan-out, dallar bağımsız olduğunda ve duvar saati kazanımı birileri için önemli olduğunda işe yarar; ikisi de doğru değilse size fazladan karmaşıklık maliyeti çıkarır.

Üçüncüsü ve en çok savunacağım, bağımsız doğrulama.

Bir aracı kendi ödevini nazikçe notlar; bu yüzden taslağa salt-okunur erişimi olan ayrı bir değerlendirici düğümü, genellikle herhangi bir grafikteki en değerli düğümdür.

Bu desenleri farklı kütüphanelerin nasıl ifade ettiğine çerçeve seviyesinde bakmak için, CrewAI vs LangGraph vs AutoGen karşılaştırmamız ödünleşimleri ortaya koyar.

LangGraph ile Çoklu Aracılı Bir Grafik Oluşturma

Bir araştırmacı, bir yazar ve bir değerlendiriciyle, kısa bir araştırılmış bilgilendirme notu üreten ve başarısız taslakları revizyona gönderen bir LangGraph çoklu aracı boru hattı kuruyoruz.

LangGraph, durumlu aracıları orkestre eden düşük seviyeli bir çerçevedir ve StateGraph’ı önceki bölümdeki düğümler, kenarlar ve durum ile neredeyse bire bir eşleşir.

Aşağıdakilerin tamamı Eylül 2026’da langgraph 1.2.11 ve langchain-anthropic 1.7.1 ile sınandı.

Kütüphane sizin için yeniyse, LangGraph eğitimimiz temelleri kapsar. Bu bölüm hızlı ilerler ve LangChain vs LangGraph vs LangSmith vs LangFlow rehberimiz, bu ailenin hangi parçasının ne yaptığını ayırır.

Yazarın görseli. Şimdi kuracağımız boru hattı. Düz çizgiler 3 düz kenarı; kesikli ve noktalı çizgiler tek bir koşullu kenarın 2 dalını gösterir.

Kurulum ve paylaşılan durumun tanımı

Paketleri kurun; anahtarınız kaynağa girmesin diye python-dotenv ekleyin:

pip install langgraph langchain-anthropic python-dotenv

Betiğinizin yanına bir .env dosyası oluşturun:

ANTHROPIC_API_KEY=sk-ant-your-key-here

Şimdi içe aktarmalar ve durum şeması. TypedDict’i önce yazmak, 2 dakikaya değer; çünkü her düğümün üzerinde anlaştığı sözleşmedir:

from typing import Literal, TypedDict
 
from dotenv import load_dotenv
from langchain_anthropic import ChatAnthropic
from langgraph.graph import END, START, StateGraph
 
load_dotenv()
 
MAX_REVISIONS = 3
 
# A cheap model for gathering, a stronger one for writing and reviewing.
fast_llm = ChatAnthropic(model="claude-haiku-4-5-20251001", max_tokens=2000)
main_llm = ChatAnthropic(model="claude-sonnet-5", max_tokens=2000)
 
 
class BriefState(TypedDict):
    topic: str
    notes: str
    draft: str
    verdict: str
    feedback: str
    revisions: int

İki model, tek değil. Bu, karar tablosundaki “adım başına farklı model” tetikleyicisinin gerçek koddaki karşılığıdır; zira araştırma, pahalı modele ihtiyaç duymayan yüksek hacimli ve düşük yargı işidir.

MAX_REVISIONS burada sessiz ama önemli bir iş yapıyor.

Bir sınır olmadan, sıkı bir değerlendirici ve inatçı bir yazar bir taslağı faturanız ilginçleşene kadar ileri geri yollar.

Araştırmacı, yazar ve değerlendirici düğümlerini kurma

Her düğüm aynı sözleşmeyi izler. Mevcut durumu alır, tek işini yapar ve yalnızca değiştirdiği alanları içeren bir sözlük döndürür.

Araştırmacı ham malzemeyi toplar ve notes içine yazar:

def researcher(state: BriefState) -> dict:
    """Gather raw material and write it into shared state as notes."""
    prompt = (
        f"Topic: {state['topic']}\n\n"
        "List 6 to 8 concrete facts, numbers, or named examples a writer "
        "could use. Bullet points only. No introduction, no conclusion."
    )
    response = fast_llm.invoke(prompt)
    return {"notes": response.text}

Bu düğümün üretim sürümü, modelin kendi bilgisine güvenmek yerine bir arama aracını çağırırdı.

Grafik yapısı görünür kalsın diye tek bir .invoke() çağrısı olarak bıraktım; o yüzden ürettiği notları doğrulanmamış kabul edin.

Yazar bu notları okur ve bir taslak üretir. Ayrıca değerlendirici geri bildirimi olup olmadığını kontrol eder; bu da yeniden deneme kenarına işleyeceği bir şey verir:

def writer(state: BriefState) -> dict:
    """Turn notes into a draft, applying reviewer feedback on a retry."""
    feedback = state.get("feedback", "")
    revision_note = (
        f"\n\nThe reviewer rejected your last draft. Fix this: {feedback}"
        if feedback
        else ""
    )
    prompt = (
        f"Write a 200-word brief on: {state['topic']}\n\n"
        f"Use only these notes:\n{state['notes']}{revision_note}"
    )
    response = main_llm.invoke(prompt)
    return {
        "draft": response.text,
        "revisions": state.get("revisions", 0) + 1,
    }

Değerlendirici taslağı puanlar.

Yazarın muhakemesini hiç görmemiştir ve metnin hiçbirini üretmemiştir; bu yüzden sonuç hakkında açık sözlü olabilir.

Bu, Berkeley sınıflandırmasının üçüncü arıza kategorisidir; kendi düğümünü hak eder.

Görev doğrulaması, çıktıyı bağımsız hiçbir şey denetlemediğinde bozulur; çözüm, kendi ödevini notlandıramayan bir işçidir:

def reviewer(state: BriefState) -> dict:
    """Score the draft. This node never writes, so it can be honest."""
    prompt = (
        "You are a skeptical editor. Reject the draft if it makes a claim "
        "the notes do not support, or if it runs past 250 words.\n\n"
        f"NOTES:\n{state['notes']}\n\nDRAFT:\n{state['draft']}\n\n"
        "Reply with APPROVE or REVISE on the first line. "
        "If REVISE, add one line explaining the single biggest problem."
    )
    response = main_llm.invoke(prompt)
    text = response.text.strip()
    verdict = "approve" if text.upper().startswith("APPROVE") else "revise"
    return {"verdict": verdict, "feedback": text}

Üç düğümde de .content yerine .text kullanımına dikkat edin.

Her ikisi de basit bir yanıtta dize döndürür; ancak .text, yanıt birden fazla içerik bloğu olarak geldiğinde de doğru olanı yapar ve ileride kafa karıştırıcı bir AttributeError: 'list' object has no attribute 'strip' hatasından kurtarır.

Hükmü ilk satırdan ayrıştırmak okunaklıdır ve kırılgandır.

Başsız çalışacak bir şey için, o dize denetimini LangChain’in yapılandırılmış çıktısıyla değiştirin; böylece hüküm, modelin saygı göstereceğini umduğunuz bir önek yerine tipli bir alan olarak döner.

Kenarları bağlama ve koşullu yeniden denemeyi ekleme

Yönlendirme işlevi koşullu kenardır. Değerlendirici çalıştıktan sonraki durumu okur ve sırada ne olacağını döndürür:

def route_after_review(state: BriefState) -> Literal["writer", "__end__"]:
    """The conditional edge: ship it, or send it back to the writer."""
    if state["verdict"] == "approve":
        return END
    # revisions counts every draft, including the first, so ">" allows
    # 1 original draft plus MAX_REVISIONS rewrites.
    if state["revisions"] > MAX_REVISIONS:
        return END
    return "writer"

Bu işlevi sessiz tutun. İçine bir print() koymak, akış döngüsü hâlâ önceki parçayı yazdırırken stdout’a düşer; böylece sınır bildirimi bir adım erken görünür ve iz sırası karışık görünür.

Revizyon sınırı bir düğümün içinde değil, burada yaşar; çünkü durdurma bir kontrol akışı kararıdır ve kontrol akışı kenarlara aittir.

Şimdi grafiği birleştirin. Düğümler, sonra kenarlar, sonra derleme:

builder = StateGraph(BriefState)
 
builder.add_node("researcher", researcher)
builder.add_node("writer", writer)
builder.add_node("reviewer", reviewer)
 
builder.add_edge(START, "researcher")
builder.add_edge("researcher", "writer")
builder.add_edge("writer", "reviewer")
builder.add_conditional_edges(
    "reviewer",
    route_after_review,
    {"writer": "writer", END: END},
)
 
graph = builder.compile()

.add_conditional_edges()’in üçüncü argümanı yol haritasıdır.

Yönlendirme işlevinin döndürebileceği her hedefi listeler ve LangGraph, herhangi bir düğüm çalışmadan dalı çizebilmek için bunu kullanır.

Grafiği çalıştırma ve her adımı inceleme

Derlenmiş grafiği bir başlangıç durumu ile çağırın. Yalnızca topic ve revisions değerlere ihtiyaç duyar; çünkü diğer alanlar yürütme akışı ilerledikçe doldurulur:

result = graph.invoke(
    {"topic": "Why Postgres beat MongoDB for most startups", "revisions": 0}
)
 
if result["verdict"] != "approve":
    print(f"Hit the {MAX_REVISIONS}-revision cap. Shipped as is.")
 
print(f"Revisions: {result['revisions']}")
print(f"Verdict: {result['verdict']}")
print(result["draft"])

Bu, size yalnızca nihai durumu verir; bir çalışma yoldan çıkınca pek yardımcı olmaz.

Her düğümün ne yazdığını rapor etmesini izlemek için .invoke() yerine .stream() ve stream_mode="updates" kullanın. Her çağrı, kendi model çağrılarına sahip ayrı bir çalıştırmadır; bu nedenle her ikisini birden çalıştırmak yerine birini kullanın:

for step in graph.stream(
    {"topic": "Why Postgres beat MongoDB for most startups", "revisions": 0},
    stream_mode="updates",
):
    for node, update in step.items():
        print(f"[{node}] wrote: {list(update.keys())}")

Değerlendiricinin ilk taslağı reddettiği bir çalıştırmada şu çıktıyı yazdırır:

[researcher] wrote: ['notes']
[writer] wrote: ['draft', 'revisions']
[reviewer] wrote: ['verdict', 'feedback']
[writer] wrote: ['draft', 'revisions']
[reviewer] wrote: ['verdict', 'feedback']

Nihai durumun gizlediği iki şey burada görünür.

Araştırmacı bir kez çalıştı ve notları her iki yazma geçişi boyunca kalıcılığını korudu; dolayısıyla bir yeniden deneme yeniden araştırma yapmaz. Her düğüm yalnızca kendi alanlarına dokundu; böylece önceki yazma sahipliği kuralını doğrulanabilir bir şeye çevirdi.

Buradayken çağrıları sayın.

Bu reddedilmiş yol, aynı görevin tek döngülü sürümüne kıyasla yaklaşık 1’e karşı 5 model çağrısına mal olur ve fazladan 4 çağrının size bir şey kazandırıp kazandırmadığını bilmenin tek yolu hükümleri kaydetmek ve okumaktır.

Derlenen grafiği görselleştirme

İnşa ettiğiniz şeyin şeklini görmek için ek araca ihtiyacınız yok:

print(graph.get_graph().draw_ascii())      # needs: pip install grandalf
print(graph.get_graph().draw_mermaid())    # paste into any Mermaid renderer

Mermaid çıktısı, koşullu dalı reviewer’dan hem __end__’e hem de writer’a geri giden kesikli çizgiler olarak çizer.

Bu, yeniden deneme kenarınızın varlığını model çağrılarına herhangi bir harcama yapmadan önce teyit eder. ASCII görünüm yalnızca başlangıçtan sona düz yolu çizer; döngüyü görmek istediğinizde Mermaid çıktısını kullanın.

Yazarın ekran görüntüsü. Terminalde .draw_ascii() çıktısı; __start__, researcher, writer, reviewer ve __end__ dikey olarak istiflenmiş ve bağlı.

Her düğümde durum incelemesiyle adım adım hata ayıklama için LangGraph Studio yerel bir sunucuya bağlanır. Bunun kendi paketi ve bir yapılandırma dosyası gerekir; pip install "langgraph-cli[inmem]" kurun, derlenmiş graph nesnesini işaret eden bir langgraph.json ekleyin, sonra langgraph dev çalıştırın ve yazdırdığı Studio URL’sini açın.

LangGraph Studio rehberimiz arayüzü anlatır (2024 tarihli; bu yüzden kurulum adımlarını yukarıdaki komutlarla karşılaştırın) ve LangGraph aracıları eğitimimiz, araştırmacımız gibi bir düğüme gerçek araçlar eklemeyi kapsar.

Bir kapsam notu.

Bu boru hattı sıralıdır; dolayısıyla araştırmacının aynı anda birkaç kaynağı sorguladığı ve bir birleştirme düğümünün sonuçları topladığı fan-out desenini hiç göstermiyor.

Bu, doğal sonraki genişlemedir ve maliyetlerin en hızlı katlandığı yerdir.

Graph Engineering için En İyi Uygulamalar

Aracısal yapay zekâda graph engineering’in arıza türleri yeterince sık tekrar eder ki adları konabilir. Bir şeyi yayınlamadan önce kontrol ettiğim üç tanesi şunlar.

1. Grafikten önce döngüye hâkim olun

Her düğüm, istemi, araçları ve bitmiş tanımıyla başlı başına bir döngüdür.

Üç sallantılı düğümü birbirine bağlamak, yüzey alanı üç katına çıkmış ve hata ayıklama öyküsü çok daha kötü bir sallantılı sistem verir.

Önce tek bir düğümü tek başına çalışır hâle getirin.

Doğrudan çağırdığınızda muğlak notlar döndüren bir araştırmacı, bir grafiğin içinde de muğlak notlar döndürür ve aşağı akıştaki yazar bunların üzerine güvenle inşa eder.

2. Düğümleri küçük ve tek amaçlı tutun

Bir düğüme, aslında bir kenara ait olan mantığı koyma dürtüsüne direnin.

Durdurma koşulları, dal kararları ve yeniden deneme sınırları yönlendirmedir; yönlendirme de hepsini bir arada okuyabildiğiniz kenar işlevinde olmalıdır.

Önceki bağlaçsız testini uygulayın.

Kaynakları arayan ve yeterli olup olmadıklarına karar veren bir düğüm, işlev imzasını paylaşan 2 düğümdür.

3. Maliyetlerinizi izleyin

Fan-out ve yeniden deneme döngüleri, bir diyagramın tamamen gizlediği şekillerde jeton kullanımını katlar.

Bir birleştirme düğümüne beslenen 5 yönlü bir fan-out, 3 yeniden deneme sınırıyla birlikte 5 çağrı değildir; yeniden denemenin yerine bağlı olarak birleştirmeyi saymadan önce 15 ya da daha fazlası olabilir.

Sınırı açıkça belirleyin; bizim MAX_REVISIONS’ta yaptığımız gibi. Sonra düğüm başına jeton sayılarını kaydedin ve bir hafta sonra okuyun; çünkü ucuz olduğunu varsaydığınız düğüm genellikle en sık çalışan olur.

Bir çerçeve seçimi

AutoGen hâlâ grafik orkestrasyonu için öneriliyor ve deneysel GraphFlow çalışması gerçek bir öncüydü; ancak depo Eylül 2026 itibarıyla bakım modunda, yeni özellik yok.

Microsoft yeni kullanıcıları, yayınlanmış bir geçiş rehberi ile kendi grafik tabanlı iş akışlarına sahip olan Microsoft Agent Framework’e yönlendiriyor.

Bugünden başlayarak LangGraph, Google’ın ADK’si veya Microsoft Agent Framework daha güvenli tercihlerdir; Google ADK ile Yapay Zekâ Aracıları Oluşturma kursumuz ADK’yi derinlemesine kapsar.

Son Düşünceler

Graph engineering, döngü mühendisliğinin üzerindeki koordinasyon katmanıdır.

Düğümler işi yapar, kenarlar sırada neyin çalışacağını belirler ve tek bir paylaşılan nesne aralarında bilgiyi taşır.

Temmuz 2026 zaman akışının gürültüsünü soyup atın; modelin tamamı budur.

Boru hattımızı bilerek küçük tuttuk: 3 düğüm, 4 kenar bildirimi (bunlardan 1’i koşullu, bu yüzden 2 dal çizer) ve yeniden denemenin kontrolden çıkmaması için bir revizyon sınırı.

Bu kadarı, taslağı onu yazmamış bir şey tarafından gözden geçirtecek kadar yapı sağladı ve tek bir döngünün sunamadığı özellik tam olarak buydu.

İş; farklı uzmanlar gerektiren fazlara bölündüğünde, ve ondan bir düğüm önce değil, grafiğe uzanın. Şüpheciler, mekaniklerin onlarca yıllık olduğu ve terim etrafındaki yazıların çoğunun gürültü olduğu konusunda haklıydı.

Ayrıca salı öğleden sonrasında önemli olan kısımda da haklılardı.

Döngü biçimli bir probleme eklenmiş zayıf bir doğrulayıcı, etrafına daha fazla kutu çizdiğiniz için iyileşmez.

Bu desenleri ileri taşımak için, LangGraph ile Çoklu Aracı Sistemleri kursumuz bu eğitimin durduğu yönetici ve ağ tasarımlarını kapsar.

Kelimenin veri tarafı için, LangChain ve Neo4j ile Graph RAG iyi bir sonraki adımdır. Orkestrasyon tarafında kalmak için, MongoDB ve LangGraph ile Metinden Sorguya Aracılar canlı bir veritabanına karşı bir LangGraph boru hattı kurar ve LLM Aracıları Açıklaması tümünün altındaki mimariyi doldurur.

Tam betik GitHub depomda; grafik oluşturma yardımcısı ve her çalışmanın maliyetine dair kısa bir notla birlikte.