1. Anasayfa
  2. Teknoloji Trendleri

Çoklu Yapay Zeka Ajanlarında (Multi-Agent) Sonsuz Döngü ve Hafıza Krizini Çözme Rehberi

Çoklu Yapay Zeka Ajanlarında (Multi-Agent) Sonsuz Döngü ve Hafıza Krizini Çözme Rehberi
Çoklu Yapay Zeka Ajanlarında (Multi-Agent) Sonsuz Döngü ve Hafıza Krizini Çözme Rehberi
0

Çoklu Yapay Zeka Ajanlarında (Multi-Agent) Sonsuz Döngü ve Hafıza Krizini Çözme Rehberi

Yapay zeka asistanlarını tekil bir sohbet penceresinden çıkarıp, belirli görevleri otonom şekilde yürüten ajan sistemlerine (AI Agents) dönüştürmek, SaaS projelerinin yeni standart haline geldi. Ancak CrewAI, LangGraph veya AutoGen gibi framework’leri kullanarak birden fazla ajanın bir arada çalıştığı (Multi-Agent) sistemler inşa etmeye başladığınızda, süreç basit bir prompt zinciri olmaktan çıkar ve karmaşık bir dağıtık sistem mimarisine dönüşür.

Geliştiricilerin üretim (production) ortamında karşılaştığı ve projelerin kilitlenmesine neden olan en büyük iki kriz; ajanların birbirlerine hatalı veri aktararak sonsuz döngüye (infinite loop) girmesi ve ortak bellek (shared memory) yönetiminin senkronize edilememesidir. Bu rehber, teorik yaklaşımlardan uzak, çoklu ajan mimarilerinde durum yönetimini (state management) kontrol altına almanın ve sistem kilitlenmelerini yazılımsal olarak engellemenin teknik metodolojisini ele almaktadır.

🔄 Çoklu Ajanlarda Sonsuz Döngü (Infinite Loop) Neden Oluşur?

Bir multi-agent sisteminde, bir ajanın çıktısı (output) diğer ajanın girdisi (input) haline gelir. Örneğin; bir “Kod Yazan Ajan” ve bir “Kodu Test Eden Ajan” kurguladığınızı düşünelim. Kod yazan ajan hatalı bir mantık kurduğunda, test ajanı bu hatayı tespit edip geri gönderir. Eğer iki ajan arasındaki geri bildirim döngüsüne (feedback loop) katı bir sınır konulmazsa, ajanlar kendi aralarında binlerce token tüketerek aynı hatayı birbirlerine raporlamaya devam ederler. Bu durum hem API bütçesini dakikalar içinde tüketir hem de sistemi kilitler.

Bu krizi engellemenin kesin yolu, ajanlar arasındaki durum geçişlerini deterministik bir graf (Directed Acyclic Graph – DAG) yapısına bağlamak ve her state geçişine bir “Maksimum Döngü Sayacı” (Max Iteration Counter) entegre etmektir.

Aşağıdaki Python ve LangGraph tabanlı kod bloğu, iki ajan arasındaki döngüyü kontrol altında tutan ve hafızadaki durumu güvenli bir şekilde güncelleyen mimariyi göstermektedir:

from typing import TypedDict, Annotated, List
from langgraph.graph import StateGraph, END

# 1. Sistem Durumunun (State) Tanımlanması
class AgentState(TypedDict):
    task: str
    code: str
    feedback: str
    iteration_count: int  # Sonsuz döngüyü engelleyecek kritik sayaç

# 2. Döngü Kontrol Fonksiyonu (Router)
def route_after_testing(state: AgentState):
    # Eğer maksimum deneme sayısına ulaşıldıysa döngüyü zorla kır
    if state["iteration_count"] >= 3:
        return "human_intervention"
    
    # Test başarılıysa süreci bitir, başarısızsa kod ajanı tekrar çalışsın
    if "FAIL" in state["feedback"]:
        return "coder_agent"
    return END

# 3. Graf Mimarisi Kurulumu
workflow = StateGraph(AgentState)

# Düğümler (Nodes) ve Kenarlar (Edges) sisteme tanımlanır
workflow.add_node("coder_agent", lambda state: {"iteration_count": state["iteration_count"] + 1})
workflow.add_node("test_agent", lambda state: state)

workflow.set_entry_point("coder_agent")
workflow.add_edge("coder_agent", "test_agent")

# Dinamik yönlendirme köprüsü
workflow.add_conditional_edges(
    "test_agent",
    route_after_testing,
    {
        "coder_agent": "coder_agent",
        "human_intervention": END,
        END: END
    }
)

🧠 Hafıza Yönetimi (Short-Term vs. Long-Term Memory)

Çoklu ajan sistemlerinde verinin kaybolması veya ajanların eski kararları unutması, durum yönetiminin tek bir merkezi veritabanına bağlanmamasından kaynaklanır. Ajanların hafızası yazılımsal olarak ikiye ayrılmalıdır:

  • Kısa Süreli Bellek (Thread-Level State): Sadece o an yürütülen spesifik görev boyunca (Örn: tek bir kullanıcının tek bir transaction işlemi) ajanların paylaştığı geçici verilerdir. Bellekte tutulur, işlem bitince silinir.
  • Uzun Süreli Bellek (Persistence Layer): Ajanların geçmiş görevlerde elde ettiği başarıları, kullandıkları araçların (tools) çalışma performanslarını ve insan müdahalelerinden aldıkları geri bildirimleri sakladığı katmandır. PostgreSQL veya Redis üzerinde vektör tabanlı veri şemalarıyla tutulmalıdır.

Ajanların ortak bellek krizini çözmek için her ajana doğrudan global değişken erişimi vermek yerine, durum verisini sadece bir “Durum Yöneticisi” (State Manager) kontrolünde mutasyona uğratmak gerekir. Bir ajan, merkezi durum nesnesini doğrudan değiştirememeli, yalnızca yeni bir durum kopyası üreterek sisteme sunmalıdır (Immutability ilkesi).

🛠️ Üretim Ortamında Durum Yönetimi İçin Teknik Kurallar

Birden fazla ajanın kararlı çalışmasını sağlamak için sistem mimarinize eklemeniz gereken optimizasyon adımları şunlardır:

1. İnsan Kontrol Noktaları (Human-in-the-Loop)

Sistem kritik bir eşiğe geldiğinde veya yukarıdaki kod örneğinde olduğu gibi maksimum döngü sınırına yaklaştığında, karar yetkisi ajanlardan alınıp bir webhook tetiklenerek insan onayına (Human Intervention) sunulmalıdır. Geliştirici onay vermeden veya hatayı manuel düzeltmeden ajanlar sonraki adıma geçmemelidir.

2. Durumun Veritabanında Saklanması (Check-pointing)

Her ajan adımı bittiğinde, mevcut AgentState nesnesi benzersiz bir thread_id ile veri tabanına (Örn: Supabase/PostgreSQL) kaydedilmelidir. Bu sayede, sunucu çöktüğünde veya API bağlantısı koptuğunda, ajan sistemi göreve sıfırdan başlamak yerine kaldığı son adımdan otonom olarak devam edebilir.

📊 Gerçek Deneyimlerden Çıkarılan Sonuçlar

Production aşamasına geçmiş karmaşık çoklu ajan sistemleri üzerinde yapılan mimari testler şu somut bulguları ortaya koymuştur:

  • Ajanlara verilen sistem promptlarında “Lütfen en doğru sonucu bulana kadar denemeye devam et” gibi ucu açık talimatlar verildiğinde, RAG sistemlerinin hata payı artmakta ve maliyetler katlanmaktadır. İstisnasız her ajana katı bir sınır çizilmelidir.
  • Ajanların birbirleriyle olan mesajlaşma geçmişi (message history) temizlenmeden sürekli büyüdüğünde, LLM’lerin bağlam penceresi (context window) şişmekte ve modeller anlamsal olarak saçmalamaya başlamaktadır. Her 5 ajan adımında bir, mesaj geçmişini özetleyen (summarization) bağımsız bir arka plan servisi çalıştırmak sistem kararlılığını korumanın tek yoludur.

🗒️ Özet Eyleme Geçme Planı

Çoklu ajan mimarilerinde başarı, ajanların ne kadar akıllı promptlara sahip olduğuyla değil, durum yönetiminin ne kadar katı yazılım kurallarıyla kontrol edildiğiyle ölçülür. Bir multi-agent sistemi kurarken; durum nesnesini değiştirilemez (immutable) kılın, adımları bir veritabanı kontrol noktasına bağlayın ve ajanlar arasına deterministik döngü sayıcıları ekleyerek API bütçenizi güvence altına alın.

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir