Graf Mühendisliği: Tek Bir İstemden 1.000 AI Ajanını Paralel Olarak Nasıl Çalıştırırsınız

2026 yılında çoklu ajan sistemleri kuran herkes hâlâ düz çizgiler yazıyor. Birinci adım, sonra ikinci adım, sonra üçüncü adım - her biri bir öncekini bekliyor. İşte bunun neden yavaş olduğu ve nasıl düzeltileceği.

Kimsenin kontrol etmediği sorun

Çok adımlı bir ajan kurdun. Çalışıyor. Ama aynı zamanda yavaş.

Modelin darboğaz olduğunu varsayıyorsun. Öyle değil.

Darboğaz, çizdiğin şekil. Bir zincir - 1. adım 2. adımı bekler, 2. adım 3. adımı bekler - adımların yarısının birbiriyle hiçbir ilgisi olmasa bile sıralı yürütmeyi zorlar.

"Bu belgeyi özetle, sonra hava durumunu kontrol et" bir iş akışı kılığına girmiş iki bağımsız iş. Hava durumu görevi özete ihtiyaç duymaz. Hiç duymadı. Ama bunu bir zincir olarak yazdıysan, yine de bekler.

Düzinelerce adıma yayılan bu boşa harcanan bekleme, çalışma sürenizin çoğunun kaybolduğu yerdir.

Bölüm 1 - Döngüler ve graflar

Bir döngü, bir kendini geliştirme birimidir:

1bir şey dene → sonucu kontrol et → ayarla → tekrar dene

Bu atomdur. Bir ajan, bir metrik, yakınsayana kadar döngü.

Döngülerin bilinen bir başarısızlık modu vardır: tam olarak ölçtüğünüz şeyi optimize ederler, başka hiçbir şeyi. Biletleri hızlı kapatmaya ayarlanmış bir destek botu biletleri hızlı kapatır - memnuniyet sessizce çakılırken. Döngü kendi metriğinin dışını göremez. Bu, ajan mimarinizde ortaya çıkan Goodhart Yasası'dır.

Bir graf bunu tasarım gereği düzeltir. Bir döngünün tek bir sayının peşinden koşması yerine, birbirini izleyen ve düzelten bir döngü ağı kurarsınız. A Düğümü'nün çıktısı B Düğümü'nü besler. C Düğümü bağımsız çalışır ve ikisini de kontrol eder. Tek bir metrik tüm sistemi yönlendirmez - yapı yönlendirir.

Ajan sistemleri için bu somut bir değişim anlamına gelir: her şeyi baştan sona yapan tek bir ajan yazmayı bırakın. Önce işin şeklini tasarlayın - neyin neden önce gerçekleşmesi gerektiği, neyin aynı anda çalışabileceği, neyin gerçekten beklemesi gerektiği.

Bölüm 2 - Düğümler, kenarlar ve onları ayıran test

Bir graf tam olarak iki bileşene sahiptir:

Düğüm - bir iş birimi. Bir ajan, bir iş, bir girdi, bir çıktı.

Kenar - gerçek bir bağımlılık. B Düğümü'nün girdisi, A Düğümü'nün çıktısını gerektirir.

Hemen hemen herkesin yaptığı hata: "ve sonra"yı varsayılan olarak bir kenar olarak ele almak.

1"Kod tabanını oku ve ardından değişiklik günlüğünü yaz"
2"Fiyatlandırma sayfasını getir ve ardından rakip özelliklerini özetle"

İş akışınızdaki her "ve sonra" için bir soru sorun:

Bir sonraki adım, bir önceki adımın çıktısını gerçekten okuyor mu?

Evet ise → gerçek kenar. Sıralı düzeni koruyun. Hayır ise → kenar yok. Bekleme boşa. Bunları paralel çalıştırın.

İki görev arasında hiçbir veri geçmiyorsa, bağımsızdırlar - ve sıralı olarak çalıştırdığınız her bağımsız çift, boşa harcadığınız çalışma süresidir.

İşte kodda uygulanan test:

1from dataclasses import dataclass
2
3@dataclass
4class TaskNode:
5    id: str
6    prompt: str
7    depends_on: list[str]  # Bu düğümün gerçekten ihtiyaç duyduğu düğümlerin ID'leri
8
9def has_real_edge(node_a: TaskNode, node_b: TaskNode) -> bool:
10    """
11    Temel graf mühendisliği testi:
12    node_b'nin prompt'u gerçekten node_a'nın çıktısını gerektiriyor mu?
13    """
14    return node_a.id in node_b.depends_on
15
16# Örnek: çoğu "zincir" 2-3 gerçek bağımlılık grubuna dönüşür
17nodes = [
18    TaskNode("audit_routes", "Tüm API rota dosyalarını listele", []),
19    TaskNode("check_auth", "Kimlik doğrulama middleware kapsamını kontrol et", []),
20    TaskNode("fetch_weather", "Bugünün hava durumunu al", []),
21    TaskNode("summarize", "Rota + kimlik doğrulama bulgularını özetle",
22              depends_on=["audit_routes", "check_auth"]),
23]
24
25# audit_routes, check_auth, fetch_weather arasında HİÇBİR kenar yok
26# Paralel çalışırlar. Yalnızca "summarize"nin gerçek kenarları vardır -- bekler.

Mevcut "A yap, sonra B, sonra C" ajanınız teknik olarak zaten bir graf. Ama mümkün olan en kötüsü - C takılırsa, downstream'de hiçbir şeyin çalışmadığı tek bir zincir.

Bölüm 3 - İlk grafunuzu oluşturmak

Gereksinimler:

• Claude Code (Dynamic Workflows desteği olan güncel sürüm).
• Max, Team veya Enterprise planı - iş akışları varsayılan olarak açık. Pro'da elle etkinleştirin.

Gerçek bir depo açın. Oyuncak bir örnek değil - getirisi yalnızca gerçek ölçekte ortaya çıkar.

İlk grafunuzu başlatan prompt:

1Bu kod tabanındaki her rota dosyasını denetlemek için bir iş akışı oluşturun.
2
3Her rota dosyası için bağımsız olarak kontrol edin:
4- kimlik doğrulama middleware'i mevcut
5- tüm parametrelerde girdi doğrulama
6- hız sınırlama yapılandırılmış
7- hata yönetimi stack trace sızdırmıyor
8
9Bu kontrolleri tüm rota dosyalarında paralel olarak çalıştırın —
10birbirlerine bağımlı değiller.
11
12Tüm dosyalar kontrol edildikten sonra, ciddiyete göre gruplandırılmış tek bir birleştirilmiş rapor oluşturun: kritik, uyarı, bilgi.
13
14Birleştirme adımı, tüm kontrollerin tamamlanmasını beklemelidir.
15Ondan önceki her şey beklememelidir.

Prompt'un kendisine gömülü yapıya dikkat edin: paralel iş açıkça belirtilmiş, tek gerçek bağımlılık (birleştirmenin tüm kontrolleri beklemesi) açıkça adlandırılmış. Ajanın grafu çıkaracağını ummuyorsunuz - onu tanımlıyorsunuz.

Perde arkasında neler oluyor - orkestrasyonun basitleştirilmiş bir versiyonu:

1import asyncio
2from anthropic import Anthropic
3
4client = Anthropic()
5
6async def audit_route_file(filepath: str) -> dict:
7    """Bir düğüm. Diğer tüm rota dosyalarından bağımsız çalışır."""
8    response = await client.messages.create(
9        model="claude-sonnet-5",
10        max_tokens=1000,
11        messages=[{
12            "role": "user",
13            "content": f"""Bu rota dosyasını şunlar için denetle:
14            - kimlik doğrulama middleware'i, girdi doğrulama,
15              hız sınırlama, hata yönetimi
16
17            Dosya: {filepath}
18
19            JSON döndür: {{"file": "", "issues": [], "severity": ""}}"""
20        }]
21    )
22    return {"file": filepath, "result": response.content[0].text}
23
24async def consolidate(results: list[dict]) -> str:
25    """Tek gerçek kenar -- her denetim düğümünün bitmesini bekler."""
26    response = await client.messages.create(
27        model="claude-opus-4-8",
28        max_tokens=2000,
29        messages=[{
30            "role": "user",
31            "content": f"""Bu {len(results)} rota denetimini birleştir
32            ciddiyete göre gruplandırılmış tek bir raporda:
33
34            {results}"""
35        }]
36    )
37    return response.content[0].text
38
39async def run_graph(route_files: list[str]):
40    # Fan out -- tüm bağımsız düğümler eşzamanlı çalışır
41    audit_tasks = [audit_route_file(f) for f in route_files]
42    results = await asyncio.gather(*audit_tasks)
43
44    # Fan in -- gerçek bağımlılığı olan tek düğüm
45    report = await consolidate(results)
46    return report
47
48# 40 rota dosyası, bir prompt, bir paralel geçiş
49results = asyncio.run(run_graph([
50    f"routes/{f}.py" for f in ["auth", "users", "billing", "orders"]
51    # ...36 tane daha

Her biri ~8 saniye süren 40 sıralı API çağrısı 5 dakikadan fazladır. Aynı 40 çağrının paralel olarak dağıtılması: 15 saniyeden az, en yavaş tek dosyanızla sınırlı, hepsinin toplamıyla değil.

Bölüm 4 - Grafların gerçekten bozulduğu yerler

Graf mühendisliği öngörülebilir üç yerde başarısız olur. Bunlarla karşılaşmadan önce bilin.

Bağlam çökmesi. 1.000 düğümü fan out yapın ve tüm 1.000 çıktıyı tek bir birleştirme adımına beslemeye çalışın, sentez başlamadan herhangi bir bağlam penceresini aşarsınız. Düzeltme: fan-in'inizi katmanlayın. Düğümleri 20-50'lik gruplara ayırın, her grubu özetleyin, ardından özetleri birleştirin - ham çıktıları değil.

1async def layered_consolidate(results: list[dict], batch_size: int = 30):
2    """Katmanlar halinde fan-in -- asla ham çıktıyı ölçekte sentezlemeyin."""
3    batches = [results[i:i+batch_size]
4               for i in range(0, len(results), batch_size)]
5
6    batch_summaries = await asyncio.gather(*[
7        summarize_batch(batch) for batch in batches
8    ])
9
10    # Nihai birleştirme, 1.000 ham sonuç üzerinde değil, özetler üzerinde çalışır
11    return await consolidate(batch_summaries)

Yanlış bağımsızlık. İki düğümün bağımsız olduğunu varsayarsınız çünkü prompt'ları birbirine atıfta bulunmaz - ancak her ikisi de aynı dosyaya yazar veya aynı hız sınırlı API'yi kullanır. Bu gizli bir kenardır. Düzeltme: yalnızca paylaşılan veriler için değil, paylaşılan kaynaklar için denetim yapın. Yazma çakışması olan iki düğüm, sıfır veri bağımlılığı olsa bile bir kenara ihtiyaç duyar.

Sessiz düğüm hatası. Bir zincirde, tek bir hata her şeyi durdurur - can sıkıcı ama açık. Bir grafta, 200 arasından bir başarısız düğüm, tamamlanmış görünen bir rapora kaybolabilir. Düzeltme: her fan-in adımı, sentezlemeden önce düğüm sayısını beklenen sayıya karşı kontrol eder ve kısmi verilerle sessizce çalışmak yerine boşlukları açıkça işaretler.

1async def safe_consolidate(results: list[dict], expected_count: int):
2    if len(results) < expected_count:
3        missing = expected_count - len(results)
4        print(f"UYARI: {missing} düğüm sessizce başarısız oldu. "
5              f"Rapor eksik olacak.")
6    return await consolidate(results)

Bölüm 5 - Gerçek bir filoya ölçeklendirme

Desen 40 düğümde çalıştığında, yüzlerceye ölçeklendirme bir yeniden tasarım değil, bir yapılandırma değişikliğidir - grafu Bölüm 2'den itibaren doğru bir şekilde oluşturduysanız.

Tam üretim şekli:

1                    Orkestratör
2                         |
3        +--------+-------+-------+--------+
4        v        v       v       v        v
5     Düğüm 1   Düğüm 2  Düğüm 3  ...     Düğüm N
6   (paralel, hiçbiri arasında kenar yok)
7        |        |       |               |
8        +--------+-------+-------+-------+
9                         v
10                Toplu Özet  <- katmanlı fan-in
11                (30'lu gruplar)
12                         v
13               Son Rapor   <- tek gerçek kenar

Orkestratörün tek işi: görevi düğümlere ayırmak, gerçek kenarları tanımlamak ve dağıtmak. Kendisi hiçbir iş yapmaz - grafu çizer.

1async def orchestrate(task: str, resources: list[str]):
2    """
3    Orkestratör düğümü -- ayırır, yürütmez.
4    """
5    plan = await client.messages.create(
6        model="claude-opus-4-8",
7        max_tokens=2000,
8        messages=[{
9            "role": "user",
10            "content": f"""Görev: {task}
11            Mevcut kaynaklar: {resources}
12
13            Bir grafa ayır:
14            - Her bağımsız düğümü listele (paylaşılan kenar yok)
15            - Düğümler arasındaki gerçek bağımlılıkları listele
16            - Sayı 50'den fazlaysa düğümleri fan-in gruplarına ayır
17
18            Şunlarla JSON döndür: nodes, edges, batch_groups"""
19        }]
20    )
21
22    graph = parse_plan(plan.content[0].text)
23
24    # Bağımsız düğümleri paralel yürüt
25    node_results = await asyncio.gather(*[
26        execute_node(n) for n in graph["nodes"] if not n["depends_on"]
27    ])
28
29    # Ardından bağımlı düğümleri yürüt, yalnızca gerçek kenarlara saygı göster
30    final = await execute_dependent_chain(graph["edges"], node_results)
31
32    return final

Graf mühendisliğinin temsil ettiği asıl değişim budur: her adımı yazan kişi olmaktan çıkıp bağımlılık yapısını tasarlayan kişi haline gelirsiniz. Ajanlar düğümleri doldurur. Kenarlar sizin sorumluluğunuzdadır.

Çizgiler yerine graflarla düşündüğünüzde ne değişir

40 adımlı doğrusal bir ajan, 40 sıralı başarısızlık noktasına ve en yavaş tek adımının 40 katı gecikmeye sahiptir.

Aynı 40 iş birimine sahip bir graf, gerçek bağımlılıklarınız kadar paralel başarısızlık noktasına sahiptir - çoğu iş akışında genellikle 3 ila 5 - ve gecikme, toplam adım sayınızla değil, en yavaş katmanınızla sınırlıdır.

Bu marjinal bir hızlanma değil. Aynı temel işi çalıştıran 5 dakika süren bir iş akışı ile 15 saniye süren bir iş akışı arasındaki farktır.

Model hiçbir zaman darboğaz olmadı. Çizdiğiniz çizgiydi.

Bu, Temmuz 2026 itibarıyla çoklu ajan orkestrasyon modellerinin teknik bir dökümüdür. Kod örnekleri açıklayıcıdır - ölçekte dağıtmadan önce hata yönetimini, hız sınırlamayı ve yeniden deneme mantığını üretim ortamınıza uyarlayın.

Okuduğunuz için teşekkürler.