Modül 4 · Domain 3 — Memory & state (%10-15) · ⏱ 16 dakika

Domain 3 özeti — Bellek, durum, drift ve süreklilik

Domain 3 — Memory, state, drift, and continuity

Bu derste neler öğreneceksin

  • Short-term / long-term / external memory seçim kriterlerini öğrenmek
  • Durable artifact pattern'ini GitHub karşılıklarıyla eşleştirmek
  • Drift'i tespit etme operasyonel sinyallerini bilmek
  • Stale ve conflicting context'i önleme stratejilerini kavramak

Ağırlık: %10-15 · Mock’ta ~6 soru. Kavramsal olarak orta, ama community raporu (jingchang0623) “memory management underemphasized but critical” diyor — atlatma.

1. Memory stratejileri — üç tür

TürNe içinSüreGitHub karşılığı
Short-termMevcut görev/oturum context’iOturum sonu kaybolurChat history, agent in-memory state
Long-termKullanıcı/repo tercihleriKalıcıCopilot memory, agent persistent state
ExternalGörev için okunan dış kaynakKaynak hayatta olduğu süreceRepo dosyaları, issue/PR, doküman, DB

Seçim kriterleri

  • Görev tek seferlik / oturum-içi → short-term
  • Tercih, stil, takım kuralı oturumlar arası → long-term
  • Büyük doküman, dış sistem verisi → external (RAG benzeri)

Memory expiration, pruning, reset

Sınav bullet’ı: “Define memory expiration, pruning, and reset rules”. Sebep — drift ve scope koruma:

  • Expiration — eski karar zamanaşımına uğrar
  • Pruning — görev-alakasız bilgi silinir
  • Reset — yeni görev başında temiz sayfa

Memory’yi scope’lamamak = drift’in birinci nedeni.

2. Durable artifact — state’i kalıcı tutmak

Agent’ın yarıda kaldığı yerden devam edebilmesi için, kararlar ve ilerleme standart geliştirme araçlarında erişilebilir kaydedilmeli.

GitHub durable artifact karşılıkları:

Veri türüGitHub artifact
Karar / gerekçePR description, issue yorumu, ADR dosyası
İlerleme adımlarıCommit history, PR commit listesi
Ara çıktı (plan, rapor)Actions artifacts (upload-artifact)
Custom stateRepo dosyası (agent-state.json) — kontrollü

Resume: agent yarıda kaldı → yeni invocation eski PR’a bakar, kararları okur, kaldığı yerden devam eder. Bellek dump’ı YOK — kaynak GitHub.

3. Drift tespiti — operasyonel sinyaller

Drift = agent uzun yürütmede önceki kararlarından / başarı kriterinden sapar. Tespiti zor; sinyaller:

Doğru sinyaller:

  • Önceki kararlarla çelişen çıktı
  • Aynı görev tekrar edildiğinde belirgin farklı sonuç
  • Başarı kriterini görmezden gelen output
  • Plan’da yokken yeni step icat etme

Drift sinyali DEĞİL:

  • CPU kullanımı artışı (performance metric’i)
  • Yanıt süresi (latency, throughput metric’leri)
  • Token kullanımı

Drift tespit edilince rollback + context refresh + plan revalidation zinciri devreye girer.

4. Süreklilik — multi-tool / multi-env

3 bullet:

  • Share agent state — birden çok tool/agent aynı state’i okuyabilmeli
  • Prevent conflicting context — iki tool farklı versiyon tutmasın
  • Prevent stale context — bayat bilgi karar kaynağı olmasın

Pattern: System of record

Tek doğruluk kaynağı kuralı — GitHub’da genelde bu:

  • Karar = ADR dosyası veya PR description
  • Durum = repo dosyası veya Actions artifact
  • Geçmiş = commit + audit log

Tool’lar bu tek kaynaktan okur; kendi state’lerini tutmaz veya tutarsa periyodik sync yapar.

Mini quiz — Domain 3 (3 soru)

Bir agent çoklu PR review oturumlarında 'ekip kod stili kararlarını' tutarlı uygulamalı. Bu bilgi hangi memory türündedir?

Bir agent uzun süreli görevi yarıda bıraktı. Devam için sınavın önerdiği yaklaşım nedir?

Uzun çalışan bir agent'ta context drift'i tespit etmenin operasyonel sinyali HANGİSİ değildir?

Sırada ne var?

Domain 4 — Eval & tuning. Otomatik tarama araçlarını eval sinyaline çevirmeyi, root cause üçlü sınıflandırmasını ve hedefli tuning kararlarını işleyeceğiz.