1. Genel Bakış
ADK 2'nin başlığı üç düzenleme kalıbıdır. Bu codelab'de, Maraton Yarışı Günü Koçu adlı bir uygulama oluşturarak bu üç kavramın tamamı öğretilir. Her seviye tek bir soruyu yanıtlar, bir fikir ekler ve kendi başına çalışır.
Neler öğreneceksiniz?
- Grafik iş akışları (1. sütun): Giriş gelmeden önce akışı çizebildiğiniz zamanlar.
- İşbirlikçi aracılar (2. sütun): Ekibi bildiğiniz ancak isteğin alt grubu seçtiği ve her biri canlı olarak çalışan üç ortak çalışma modu (
chat/task/single_turn) - Dinamik iş akışları (3. sütun): İşin şeklinin girişe bağlı olduğu durumlar.
- Nasıl seçilir?: Tek soruluk bir karar ağacı ve desenlerin nasıl oluşturulduğu.
The through-line
bilinen yapı → bilinen takım / değişken alt kümesi → bilinmeyen şekil → doğru olanı seçin
Ne oluşturacaksınız?
Maraton Yarış Günü Koçu adlı bir uygulama, her seferinde bir koşulabilir seviye oluşturdu. Her seviye, terminalden çalıştırdığınız basit bir Python modülüdür. 5. seviyeye geldiğinizde aşağıdaki parçaların tümü sizin olur.
Resim, çalışan koddan alınır: Her düz çizgi Workflow.graph.edges'den okunur. Bu, ilk dersi oluşturuyor. Önceden çizilebilen kısımlar tam olarak 1. sütunu, çizilemeyen kısımlar ise 2. ve 3. sütunların var olma nedenini açıklıyor.
İhtiyacınız olanlar
- Google Hesabı (Colab için) — Yerel kurulum gerekmez.
- Yaklaşık 50 dakika (L4 seviyelerinin ikisi uzun olduğundan bu seviyeler için zaman ayırın).
- Gemini modeline ulaşmanın iki yolundan biri. Yolunuzu seçin: Bir kurulum adımını çalıştırır ve diğerini atlarsınız:
🎓 Atölye | 🏠 Take-home | |
Kim | Canlı bir atölye çalışmasına katılıyorsunuz ve eğitmen size kredi talep bağlantısı verdi. | Atölye katılımcıları da dahil olmak üzere diğer herkes |
Gerekenler | Hak talebi bağlantısı ve Cloud projesi oluşturabilen bir Google Hesabı | Ücretsiz AI Studio API anahtarı |
Şu cihazlarda çalışır: | Vertex AI, atölye kredinizle faturalandırılan bir projede | Google AI Studio |
Maliyet | Kredi kapsamındadır | Ücretsiz katman |
Kurulum adımı | Atölye kurulumu (sonraki adım) | Evde kurulum (sonraki adım) |
Önsözden sonraki her şey her iki durumda da aynıdır. Şerit yalnızca not defterinin hangi model uç noktasıyla iletişim kuracağına karar verir.
İki şekilde takip edebilirsiniz
Aşağıdaki her adım Colab not defterindeki bir hücreye ve GitHub deposundaki bir klasöre karşılık gelir. Şunlardan birini seçin:
- ▶ Colab (önerilir): Not defterini açın → hücreleri yukarıdan aşağıya doğru çalıştırın.
- 💻 Yerel:
git clonedepoyu./setup_venv.sh, ardından her seviyeyi modül olarak çalıştırın (python -m ...) veya./run.sh(adk web) ile hepsine göz atın.
2. Çalıştay kurulumu · Kredinizi talep etme ve Vertex AI'a geçme
Çalışma atölyesinde size Google Cloud kredisi verilir. Bu hesabı talep edip bu hesaba faturalandırılan bir proje oluşturacak ve not defterini AI Studio yerine Vertex AI'a yönlendireceksiniz. Bir hücre, hak talebinden sonraki her şeyi yapar.
1. Kredinizi alın (~1 dakika)
- Eğitmeninizin paylaştığı talep bağlantısını açın.
https://me.developers.google.com/benefits/claim/your-workshop-namegibi görünüyor. - Oturum açın ve krediyi kabul etmek için sayfayı takip edin.
- Hangi Google Hesabı'nı kullandığınızı not edin. Aşağıdaki her adım aynı hesapla çalıştırılmalıdır.
2. Not defterini açın ve ADK 2'yi yükleyin (~1 dakika)
Colab'de aç'ı tıklayın ve ilk kod hücresini çalıştırın. Bu codelab'in doğrulandığı tam ADK 2 sürümünü sabitler ve ✓ installed yazdırır.
3. "Workshop setup" hücresini çalıştırın (~3 dakika).
Bu, 🎓 A Rotası · Atölye başlıklı hücredir. Çalıştırın. Colab, yetkilendirmenizi ister. Krediyi talep ettiğiniz Google Hesabı'nı seçin ve erişime izin verin.
Bu kod dört işlem yapar: Kredinizle adk-2-tutorial-XXXX adlı bir proje oluşturur, bu projede Vertex AI API'yi etkinleştirir, sonraki her hücrenin okuduğu dört ortam değişkenini ayarlar ve Vertex'e bir test çağrısı yapar ve yanıtlayana kadar bekler. Böylece kurulum ya çalışmayı tamamlar ya da daha sonra bir seviyede başarısız olmak yerine neden başarısız olduğunu size bildirir.
Beklenen çıkış: Önemli olan son satırdır:
Signed in as: you@example.com
...
Successfully created GCP project 'adk-2-tutorial-4817'.
Successfully linked 'adk-2-tutorial-4817' to billing account '01ABCD-...'.
waiting for Vertex AI to come up on the new project... (10s)
waiting for Vertex AI to come up on the new project... (20s)
✅ Vertex AI on adk-2-tutorial-4817 · us-central1 · gemini-2.5-flash — answered a test call
4. "Kurulumu evde yapın" adımını atlayın.
AI Studio anahtar hücresini çalıştırmayın. Bu işlem, not defterini AI Studio'ya geri döndürür ve yaptığınız işlemleri geri alır. (Hücre bunu önler ve çalıştırmayı reddeder ancak daha düzenli hareket, hücreyi atlamaktır.) Buradan doğrudan Paylaşılan yapı taşları hücresine gidin.
5. "Paylaşılan yapı taşları" hücresini çalıştırın.
Bir kez çalıştırın. L2 ve sonraki her seviyenin yeniden kullandığı Pydantic şemalarını ve hazır maraton senaryolarını tanımlar. ✓ schemas + scenarios ready ifadesini görürsünüz.
Atölye çalışmasından sonra
Krediniz ve oluşturduğu proje sonsuza kadar sürmez. Çalıştay bittikten sonra bu seviyeleri ücretsiz olarak yeniden çalıştırmaya devam etmek için Take-home setup adımını çalıştırın. Bu adımda ücretsiz bir AI Studio anahtarı, Cloud projesi ve faturalandırma gerekmez. Değişen tek şey bu hücredir.
Daha erken temizlemek için: Cloud Console'u açın, adk-2-tutorial-XXXX öğesini seçin ve silin. Bu codelab'deki başka hiçbir şey faturalandırılabilir kaynak oluşturmaz.
3. Evde kurulum · AI Studio API anahtarı
Bu rotadaki her şey ücretsiz bir Google AI Studio API anahtarıyla çalışır. Google Cloud projesi, faturalandırma veya yerel yükleme gerekmez. Bu adımın tamamı yaklaşık 3 dakika sürer.
1. Not defterini açın.
Colab'da aç'ı tıklayın. Not defterine yönlendirilirsiniz. Not defterinde, markdown ile yazılmış bir giriş ve her seviye için çalıştırılabilir bir hücre bulunur. Hücreleri yukarıdan aşağıya doğru çalıştırırsınız. Her hücre, kendi çıktısını hemen altına yazdırır.
2. ADK 2'yi yükleyin (~1 dakika)
İlk kod hücresini çalıştırın. Bu codelab'in doğrulandığı tam sürümü sabitler:
%pip install -q "google-adk==2.3.0" python-dotenv pydantic nest_asyncio
İşlemin bitmesini bekleyin. ✓ installed simgesini görürsünüz. (İlk yükleme yaklaşık 30-60 saniye sürer. Yükleme daha sonra önbelleğe alınır.)
3. AI Studio'dan Gemini API anahtarınızı alın (~1 dakika)
- Yeni bir tarayıcı sekmesinde aistudio.google.com/app/apikey adresini açın.
- Google hesabınızla oturum açın.
- Create API key'i (API anahtarı oluştur) tıklayın (sağ üstte).
- Mevcut bir Google projesini seçin veya yeni bir proje oluşturmasına izin verin.
AIza...ile başlayan ve yaklaşık 40 karakterden oluşan anahtarı kopyalayın.
4 · Anahtarınızı Colab'e ekleyin (~1 dakika)
A seçeneği: Colab Secrets (önerilir; anahtar gizli kalır):
- Colab'in sol kenar çubuğunda 🔑 anahtar simgesini tıklayın.
- + Yeni gizli anahtar ekle'yi tıklayın.
- Ad'ı tam olarak
GOOGLE_API_KEYolarak ayarlayın. - Anahtarınızı Value (Değer) alanına yapıştırın.
- Not defteri erişimi'ni AÇIK konuma getirin.
B seçeneği: İstendiğinde yapıştırın (hızlı): Gizli istemi atlayın. Bir sonraki hücreyi çalıştırdığınızda gizli bir istem gösterilir 🔑 Enter your Google AI Studio API key:. Yapıştırıp Enter tuşuna basın.
5. Anahtar hücreyi çalıştırın.
Gizliyi okur (veya yapıştırma istemine geri döner), ardından ADK'yı AI Studio'ya (Vertex AI'ya değil) yönlendirir:
import os
# 🏠 TAKE-HOME ONLY — if you ran the Workshop setup cell, skip this one.
if os.environ.get("GOOGLE_GENAI_USE_VERTEXAI") == "True":
raise SystemExit("✋ You're set up on the workshop path (Vertex AI). Skip this cell.")
# Google AI Studio API key — add GOOGLE_API_KEY in the 🔑 Secrets panel (or paste when prompted).
try:
from google.colab import userdata
key = userdata.get("GOOGLE_API_KEY")
except Exception:
import getpass
key = getpass.getpass("Enter your Google AI Studio API key: ")
os.environ["GOOGLE_API_KEY"] = "".join(key.split()) # drop any stray whitespace/newlines
os.environ["GOOGLE_GENAI_USE_VERTEXAI"] = "False" # use AI Studio, not Vertex AI
print("✅ API key set — using Google AI Studio.")
Beklenen çıktı: ✅ API key set — using Google AI Studio.
6. "Paylaşılan yapı taşları" hücresini çalıştırın.
Paylaşılan yapı taşları hücresini bir kez çalıştırın. L2 ve sonraki her seviyenin yeniden kullandığı Pydantic şemalarını ve hazır maraton senaryolarını tanımlar. ✓ schemas + scenarios ready ifadesini görürsünüz.
Kurulum tamamlandı. 🎽 L0'a (herkesin ilk oluşturduğu sürüm) geçmeden önce kısa bir ara verelim.
4. Prologue · Why not one big prompt?
⚡ Çalıştırmadan önce izlenecek TEK şeyi belirleyin: Her bir sayı nereden geliyor? Egzersizin tamamı bu kadar. Diğer her şey süsleme.
Merdivenden önce, merdivenin yerine geçen şeyi çalıştırın: İsteminde her şeyi yapmayı vaat eden bir aracı (hava durumunu getir, rotayı analiz et, antrenman günlüğünü oku, koşullara göre yönlendir, planı oluştur).
Görecekleriniz: Sayıları uydurulmuş, kendine güvenen, net ve iyi biçimlendirilmiş bir strateji. Bir canlı çalıştırmada "Bugünün hava durumu metriklerini aldım" ifadesiyle açıldı ve 11 °C, 14, 5 km/saat rüzgar ve daha önce hiç görmediği bir eğitim günlüğünün analizini bildirdi. Burada hava durumu API'si, kurs verileri veya günlük yok. Opak bir model çağrısı, girişlerini uyduruyor ya da onları işe yaramaz hale getiriyor.
Bu hastalık, adlandırılması gereken dört belirtiye sahiptir:
- Güvenemezsiniz: Veriler akıcı bir şekilde uydurulur.
- Test edemezsiniz: 4. adımın yönlendirmesi metin içinde yer alır. Birim testi için
ifyoktur. - Adım değiştirilemez: Gerçek bir hava durumu API'sinin bağlanabileceği bir yer yoktur.
- Her seferinde her şey için ödeme yaparsınız: Beş adım, tek bir büyük çağrı, deterministik bir bölümü önbelleğe alma yok.
Bu duyguyu koruyun. Sonraki dokuz seviyede bu adımlar istemden birer birer çıkarılır: işlevler getirilir (L1-L2a), bir if ifadesi yönlendirilir (L2b), uzmanlar işi böler (L3a-L3b) ve kod şekli sınırlar (L4a-L4b).
💻 Yerel: python -m shared.prologue
5. L0 · İlk ADK 2 temsilciniz
⚡ Çok Kısa Özet: Ajan, model + talimat + çağırabileceği araçlardır; Runner ise bunu yürütür. Bu seviyeden sonraki her şey, daha iyi şekillerde düzenlenmiş daha fazla aracıdan ibarettir.
Soru: Bir modelin yanıt vermesini ve aritmetik önemli olduğunda gerçek kod kullanmasını sağlayabilir misiniz?
Tek fikir, üç bölüm:
Agent: Akıl yürüten şey (bir Gemini modeli + bir talimat).Runner: Bir oturumda aracı yürüten ve etkinlikleri yayınlayan öğe.- Araç: Modelin çağırmaya karar verdiği basit bir Python işlevi (
pace_splits). ADK, imzayı ve docstring'i okur ve modele bir bildirim iletir. Şema yazılmaz.
Bu, prologdan sonraki ilk düzeltmedir: Zihninde hızlıca aritmetik işlemler yapan bir LLM, yanlış cevap vermekten çekinmez. pace_splits, deterministik Python olduğundan yanıttaki sayılar hesaplanır, doğaçlama yapılmaz.
▶ Colab: L0 hücresini çalıştırın. · 📁 GitHub: L0_first_agent/ · 💻 Yerel: python -m L0_first_agent.agent
def pace_splits(target_finish: str) -> dict:
"""Convert a goal time like '3:30:00' into exact per-mile / per-km paces."""
... # deterministic Python — no LLM
pace_coach = Agent(
name="pace_coach", model=MODEL,
tools=[pace_splits], # the model may call it; ADK reads the signature
instruction="You are a friendly, concise marathon coach. ... If the runner "
"mentions a goal time, call pace_splits — never do arithmetic yourself.",
)
runner = Runner(node=pace_coach, session_service=InMemorySessionService(), auto_create_session=True)
async for event in runner.run_async(user_id="u1", session_id="s1", new_message=msg):
... # events carry the model's text
🔍 İşaretçiler: Agent(...) · tools=[pace_splits] · Runner(...). Çıkışta ise 🔧 satırı, modelin yanıtın ortasında kodunuzu çağırmaya karar verdiği yerdir.
Görecekleriniz:
🔧 model called tool → pace_splits({'target_finish': '3:30:00'})
🔧 tool returned → {'per_mile': '8:00', 'per_km': '4:58', ...}
🧠 Coach: To finish in 3:30:00, you need an average pace of 8:00 per mile...
🔧 satırları dersi oluşturur: Yanıtın ortasında model, işlevinizi çağırmayı seçti ve yanıtındaki tam 8:00/mile, jeton istatistiklerinden değil, kodunuzdan geldi.
❓ Şunu merak ediyor olabilirsiniz: Model her zaman aracı çağırır mı? Hayır, soru bazında karar verilir. İçinde sayı olmayan bir şey sorun. 🔧 çizgileri kaybolur (Playground'da tam olarak bunu denemeniz istenir).
👀 Okuma: pace_splits (basit bir işlev) ve tools=[pace_splits] satırı. · ▶ Çalıştırın. · ✏️ Değişiklik: Genel soruyu sorun (hedef süresi yok). 🔧 çizgilerinin kaybolduğunu fark edin: Bir aracın çağrılmaya değer olup olmadığına model karar verir. Ardından, instruction bölümünü yeniden yazıp tekrar çalıştırın. Talimat, programın geri kalan kısmıdır.
6. L1 · İlk iş akışınız
⚡ Çok Kısa Özet: Düz bir işlev ve bir LLM aracısı aynı türden düğümlerdir. Tahmin edilebilir çalışma → işlev (0 LLM, deterministik); akıl yürütme → aracı.
Soru: Yalnızca kod olan kısımlar için model çağrısı ücreti ödemeden, tek bir akışta düz kodu ve bir LLM'yi nasıl karıştırırsınız?
Tek fikir: Workflow içinde, basit bir Python işlevi ve bir LLM aracısı aynı edges listesindeki düğümlerdir.
START ──► fetch_conditions (function, 0 LLM) ──► advise (agent, 1 LLM)
▶ Colab: L1 hücresini çalıştırın. · 📁 GitHub: L1_graph_basics/ · 💻 Yerel: python -m L1_graph_basics.workflow
İşlev düğümü, oluşturduğu verileri (model çağrısı yok) yazdırır. Ardından, aracı, aldığı gerçek sıcaklık ve rüzgarı referans alan tavsiyeler verir:
def fetch_conditions(node_input): # function node — 0 LLM
return Event(output=Conditions(temp_f=78, wind_mph=12, conditions="sunny").model_dump())
advise = Agent(name="advise", model=MODEL, mode="single_turn",
input_schema=Conditions, instruction="...give pacing + gear advice...")
workflow = Workflow(edges=[(START, fetch_conditions, advise)])
🔍 İşaretler: Ortasında çıplak bir Python işlevi bulunan bir kenar demeti ((START, fetch_conditions, advise)) ve devri doğrulayan input_schema=.
L0'a kıyasla yenilikler: Workflow(edges=[...]), START (girişin girildiği yer), Event(output=...) döndüren bir işlev düğümü ve input_schema=Conditions. Böylece, işlevin çıkışı, temsilci görmeden önce (JSON metni olarak) bu şemaya göre doğrulanır. input_schema, sınırı doğrular ancak temsilciye bir Python nesnesi vermez.
❓ Şunu merak ediyor olabilirsiniz: İşlev-aracı sırası gerekli mi? Hayır. Herhangi bir sıra, herhangi bir karışım, herhangi bir sayı. advise yalnızca fetch_conditions verilerine ihtiyaç duyduğu için ikinci sırada çalışır. Önemli olan sıra değil, dersin kendisidir.
👀 Okuma: fetch_conditions, model çağrısı olmadan veri döndürüyor; advise'de input_schema=Conditions var. · ▶ Çalıştırın. · ✏️ Değiştirme: İşlevde temp_f=30 ayarlayın ve işlevi yeniden çalıştırın. Öneri değişir ve işlev yine 0 LLM çağrısı maliyetine sahip olur.
7. L2a · Parallel fan-out + JoinNode (Pillar 1a)
⚡ Özet: Paralel olarak dağıtın (ücretsiz), tüm yanıtları bekleyin, paketleyin ve bir aracıya tüm resmi verin.
Soru: Giriş gelmeden önce akışı çizebilirsiniz. İskeletle başlayın: Verileri paralel olarak toplayın, paketleyin ve tek bir temsilciye teslim edin.
Şekil:
START ──► fetch_weather ──┐
START ──► analyze_course ─┼─► JoinNode ─► strategy (1 agent)
START ──► pull_fitness ───┘ (bundles)
▶ Colab: L2a hücresini çalıştırın. · 📁 GitHub: L2a_parallel_join/ · 💻 Yerel: python -m L2a_parallel_join.workflow
🔍 İşaretler: Üç kenar START noktasında başlar. Bu nokta, yayılma noktasıdır. JoinNode ise buluşma noktasıdır.
- Üç getirme işlemi işlevdir. Bu işlemler paralel olarak çalışır ve 0 LLM çağrısı yapılır.
JoinNode, üçünün de tamamlanmasını bekler ve bunları işlev adına göre anahtarlanmış tek bir türü belirlenmiş yükte (BundledRunData) birleştirir.- Bir
strategyaracısı paketi okur veRaceStrategyyazar.
Gördükleriniz: Her getirme işlemi bir started / finished zaman damgası yazdırır. Üçü de 0,0 s'de başlar ve dağıtım 2,0 s'de sona erer. Bu süre, sürelerinin toplamı olan 4,5 s değil, en yavaş getirme süresidir. Bu örtüşme, paralelliktir. (Strateji aracısının LLM çağrısını da içerdiğinden sonunda yazdırılan toplam duvar süresi yaklaşık 8 saniyedir. Toplam süre yerine paralel talep için getirme zaman damgalarını okuyun.)
💡 Prologue geri çağırma: Mega istem, hava durumunu icat etti. Burada sıcaklık, bir getirme işlevinden (gerçek kod, gerçek dikiş) elde edilir. Hazır dikteyi gerçek bir hava durumu API'siyle değiştirin. Başka hiçbir şey değişmez.
❓ Şunu merak ediyor olabilirsiniz: Ne kadar
JoinNode
bilmem gerekiyor? Tek cümleyle açıklamak gerekirse: Her paralel dalın tamamlanmasını bekler, çıkışları yukarı akış işlevinin adıyla anahtarlanmış tek bir sözlüğe yerleştirir ve kendisi hiçbir hesaplama yapmaz. That dict is exactly why L2b's router can write node_input["fetch_weather"]["temp_f"].
👀 Okuma: Üç kenar START'den yayılır; JoinNode bunları tek bir aracı için paketler. · ▶ Çalıştırın ve toplamı değil, zaman damgalarını okuyun. · ✏️ Değişiklik: Bir getirme işleminin uykuya geçmesini sağlayın 3.0 — Önce yeni fan-out bitiş zamanını tahmin edin, ardından doğrulayın.
8. L2b · Belirleyici yönlendiriciyi ekleyin (Pillar 1b)
⚡ Özet: L2a'ya dokunulmamış + basit bir if, hangi bir aracının çalışacağına karar verir. Modele sormadan dallanma.
Soru: Plan, sıcak ve soğuk havalarda farklı olmalıdır. Modele karar vermesini istemeden nasıl dallanma yaparsınız?
Şekil (L2a + yönlendirici):
... JoinNode ─► route_by_weather ─► hot_strategy
(if-statement) ─► normal_strategy
─► cold_strategy
▶ Colab: L2b hücresini çalıştırın. run("NORMAL") / run("COLD") · 📁 GitHub: L2b_router/ · 💻 Yerel: python -m L2b_router.workflow COLD
def route_by_weather(node_input): # an if-statement, 0 LLM
temp = node_input["fetch_weather"]["temp_f"]
route = "HOT" if temp >= 70 else "COLD" if temp <= 40 else "NORMAL"
return Event(output=node_input, route=route)
(route_by_weather, {"HOT": hot_strategy, "NORMAL": normal_strategy, "COLD": cold_strategy})
🔍 İşaretçiler: Event(output=..., route=...) — yolu adlandıran bir işlev düğümü ve adları düğümlerle eşleyen dict-edge {"HOT": ..., "NORMAL": ..., "COLD": ...}.
Özet: Üç tür iş, üç ev:
- Öngörülebilir çalışma → işlevler (3 paralel getirme)
- Net bir kural → açık yönlendirme (
route_by_weather, model kararı değilififadesidir) - Akıl yürütme → model (tam olarak bir strateji aracısı çalışır)
Görecekleriniz: temp=78F -> route=HOT ve ardından yapılandırılmış bir RaceStrategy. Net maliyet: 1 LLM çağrısı.
⚠️ Dördüncü bir dal ekliyorsanız route-dict'e DEFAULT_ROUTE girişi de ekleyin. Sözlüğün eşleşmediği bir rota hata değildir. Dal yalnızca sona erer ve program 0 ile çıkış yapar ancak çıkış olmaz. Bu, hata ayıklama için kafa karıştırıcı bir çıkmazdır.
❓ Şunu merak ediyor olabilirsiniz: Yani L2b, L2a'ya yönlendirici eklenmiş hali mi? Evet. Getirme ve birleştirme işlemleri değiştirilmez ve 1 LLM çağrısı olarak kalır. Değişenler: "Her zaman aynı temsilci" yerine "Veriler tarafından seçilen üç temsilciden biri" kullanılıyor.
👀 Okuyun: route_by_weather — yönlendirici bir if ifadesidir, aracı değildir. · ▶ Koşu 'yu run("COLD") da seçebilirsiniz. · ✏️ Değiştirme: Dördüncü bir temsilciyle WINDY şubesi ekleyin ve bunu yapmadan önce yukarıdaki DEFAULT_ROUTE uyarısını okuyun.
9. L3a · İşbirlikçi temsilciler: Bir işaret, iki dünya - 2. sütun
⚡ Özet: Aynı takım, tek bayrak. chat Tüm görüşmeyi tek bir uzmana devreder ve geri dönmez; single_turn her uzmanı bir araca dönüştürür (paralel alt küme, otomatik geri dönüş, tek sentez).
Soru: Ekibi tanıyorsunuz ancak hangi üyelerin yanıt vereceğine istek karar veriyor. Bir LLM'nin alt kümeyi seçmesine ve bunları eşzamanlı olarak çalıştırmasına nasıl izin verirsiniz?
Şekil: Altı uzman (tıbbi, hava durumu, tempo, ekipman, beslenme, zihinsel) üzerinde koordinatör. Bu seviyede aynı ekip iki kez çalıştırılır. Aynı koordinatör istemi ve aynı altı uzman kullanılır. Tek fark, alt acentelerdeki bir işarettir. Kontrast, dersin konusudur.
▶ Colab: L3a hücresini çalıştırın. · 📁 GitHub: L3a_collaborative/ · 💻 Yerel: python -m L3a_collaborative.concierge --mode chat "What about fueling?"
🔍 İşaretler: Fabrikada mode="single_turn" ve çıkışta TRANSFER → (1. vuruş) ile tek bir zaman damgası paylaşan DISPATCH → satır patlaması (2. vuruş).
1. adım: Önce varsayılanı çalıştırın ve işin başarısız olduğunu görün
mode= yazılmamışsa → alt temsilciler varsayılan olarak chat olur. Görecekleriniz:
TRANSFER → nutrition_specialist (transfer_to_agent — the only tool chat subagents provide)
Final speaker: nutrition_specialist
Koordinatör yetki devretme araçlarına sahip değildir. Sohbet alt aracıları, bir uzmana sohbetin tamamını sırayla devreder.transfer_to_agent Uzman, kullanıcıyı doğrudan yanıtlar ve çalıştırma burada sona erer. Paralel gönderim yok. İade yok. Sentez yok. Kapsamlı soru sorulduğunda durum daha da kötüleşiyor: altı uzman, bir aktarım.
Bu bir hata değil, sohbet modunun işini yapmasıdır. İleti dizisi, açıkça başka birine aktarılana kadar sahibine aittir. Açık uçlu bir asistan için doğru, bir ardışık düzen adımı için yanlış.
2. etkileşim anı: Tek bayrak, iki dünya
Tek fark: Her uzman için mode="single_turn". Aynı soru, tekrar çalıştır:
[t= 7.8s] DISPATCH → medical_specialist ← same timestamp =
[t= 7.8s] DISPATCH → weather_specialist one turn, many calls
[t=14.5s] ↩ medical_specialist replied ← replies land inside
[t=14.5s] ↩ weather_specialist replied one short window
🧠 Concierge (synthesized): <one answer>
ADK artık uzman başına bir yetki verme aracı yerleştiriyor. Bu araç, alt temsilcinin adını taşıyor ve description= ile tanımlanıyor (bu metin, alt grubu seçerken koordinatörün okuduğu metindir; bu metni atlayıp yalnızca adlara göre yönlendirme yapabilirsiniz). Koordinatör, tek bir dönüşte birkaç çağrı yayınlar. ADK, bunları paralel olarak çalıştırır, her biri sonucunu otomatik olarak döndürür ve koordinatör sentezleme yapar.
Soru | Ateş eden uzmanlar |
"Yakıt ikmali nasıl olacak?" | yalnızca beslenme |
"18. kilometrede dizim ağrıyor" | yalnızca tıbbi |
"Bugün yarışmalı mıyım?" | tıbbi + hava durumu + tempolu |
"Endişelenmem gereken bir şey var mı?" | 6'sı da |
Her uzmana neden brifingin tamamı verilir? Her single_turn alt aracısı, kendi yalıtılmış oturum dalında çalışır. Görüşmeyi veya benzerlerini göremez. Hiçbir şey ortamla ilgili değildir: Koordinatör, SpecialistInput'ın tamamını (soru + strateji + koşucu verileri) her paralel çağrıya ayrı ayrı iletmelidir.
💡 ADK 2'nin bu işleme doğrudan destek verdiği yerler: Bir LLM, sub_agents + mode="single_turn" aracılığıyla bildirilen bir istek başına alt küme seçer VE bunu paralel olarak çalıştırır. 1.x'te her uzmanı AgentTool içine alarak aynı şekli oluşturabilirsiniz. Değişen şey, bunun artık bir tesisat değil, bir bildirim olmasıdır. (ParallelAgent her zaman tümü, transfer_to_agent ise seri anlamına gelir.)
⚠️ İki önemli uyarı: (1) Alt kümeyi model seçtiği için L2'nin sabit kodlanmış yönlendiricisinden daha az deterministtir. Tam alt küme, çalıştırmadan çalıştırmaya değişebilir. (2) Bazen bir uzman için Error validating input: ... satırı görürsünüz. Bu, neredeyse hiçbir zaman uzmanın çıktısı değildir. output_schema, Gemini'ın bunu sunucu tarafında zorunlu kılmasına neden olur. Bu, giriştir: Koordinatör, her paralel çağrı için iç içe yerleştirilmiş SpecialistInput öğesinin tamamını kelimesi kelimesine yeniden üretmek zorundadır ve bazen birini karıştırır. ADK, hatayı bu aracın sonucu olarak döndürür, koordinatör kurtarır ve sentez yine de gerçekleşir.
❓ Şunu merak ediyor olabilirsiniz: is
chat
Yalnızca 1.x tarzı temsilci atama mı? Yani tek seferde bir temsilci mi? Evet, bu özellik 1.x'teki varsayılan davranışın adlandırılmış halidir. single_turn ile arasındaki fark üç boyutludur: Koordinatörün elinde ne olduğu (bir transfer_to_agent ile uzman başına bir araç), kaç kişinin çalışabileceği (bir kişi, görüşmenin sahibi ile N kişi paralel olarak) ve kontrolün geri dönüp dönmediği (hiçbir zaman ile otomatik olarak, sonuçlarla birlikte). Kod hakkında: Fabrikanın if mode == dalı yalnızca bu karşıtlık için iki şekilde ekip oluşturulabilmesi amacıyla vardır. Gerçek bir uygulama bir modu sabit kodlar ve if kaybolur.
👀 Okuma: _specialist fabrika — mode parametresi tüm seviyedir. · ▶ İki ritmi de çalıştırın. · ✏️ Değişiklik: "18. kilometrede dizim ağrıyor" diye sorulduğunda önce alt kümeyi tahmin edin, ardından DISPATCH satırlarını kontrol edin.
# The factory's mode parameter is THE variable this level teaches:
def _specialist(name, domain, focus, mode):
kwargs = {}
if mode == "single_turn": # the structured contract only makes sense for a TOOL
kwargs = dict(mode="single_turn",
input_schema=SpecialistInput, output_schema=SpecialistResponse)
return Agent(name=name, model=MODEL,
description=f"Marathon {domain} specialist. Consult for: {focus}.",
instruction=..., **kwargs)
race_concierge = Agent(name="race_concierge", model=MODEL,
sub_agents=[...six specialists...], # NOTE: no `mode` on the coordinator
instruction="...DECIDE which specialists are relevant... call them IN PARALLEL... SYNTHESIZE...")
10. L3b · Görev modu: Bitiş çizgisi olan bir sohbet — 2. sütun
⚡ Çok Kısa Özet: Orta modda, alanlar toplanana kadar kullanıcıyla konuşun, ardından doğrulanmış bir nesneyle otomatik olarak geri dönün.
Soru: L3a boşluk bıraktı. chat tüm görüşmeyi yönetir; single_turn kullanıcıyla hiçbir zaman konuşmaz. Ancak gerçek kabul çalışması bu ikisinin arasında yer alır: "X sayısını toplayana kadar kullanıcıyla konuş, ardından doğrulanmış bir nesneyle geri gel." Bu hangi moddur?
Şekil:
race_desk (coordinator)
└─ gear_fitter (mode="task", output_schema=GearOrder)
▶ Colab: L3b hücresini çalıştırın. · 📁 GitHub: L3b_task_desk/ · 💻 Yerel: python -m L3b_task_desk.desk
🔍 İşaretçiler: mode="task" + output_schema= aynı temsilcide ve çıkışta ⏸ duraklatma ile finish_task görüşmesi.
Görecekleriniz:
━━ TURN 1 ━━ user: 'I need shoes for the marathon.'
race_desk → delegate: gear_fitter
gear_fitter: What is your shoe size?
⏸ The run ENDED — but nothing failed. This is a PAUSED task.
━━ TURN 2 ━━ user: 'Size 9, wide.' (same session → resumes the task)
gear_fitter → finish_task (payload validates as GearOrder)
race_desk: Your order ... in size 9 Wide has been confirmed.
L3a modunun yapamayacağı üç şey gerçekleşti:
- Çalıştırma işlemi, görev ortasında gerçekten durduruldu: Duraklatılan bir görev, takılma veya hata değil. Ajan, netleştirme sorusunu sordu ve görevi açık tutuyor. (
adk webiçinde yanıtı yazmanız yeterlidir. Harness, aynı oturumda ikinci bir mesaj olarak komut dosyası oluşturur.) - Bir sonraki mesajda AYNI görev aracısı devam ettirildi. Yeniden yönlendirme veya yeniden yetkilendirme yapılmadı. Oturum, bekleyen kişileri bilir.
finish_tasksona erdi:mode="task"nedeniyle ADK'nın yerleştirdiği bir araç. Ajan, işlemi tamamlamak için bunu çağırmalı ve yüküoutput_schema'ya göre doğrulanmalıdır. Yazılı bir bitiş çizgisiyle sonuçlanan bir görüşme. Ardından kontrol otomatik olarak koordinatöre geri döner ve sonuç eklenir.
Mod seçmeyle ilgili tek soruluk kural
💡 "Kullanıcının ne zamana kadar bu hizmetle konuşması gerekiyor?" sohbet = süresiz · görev = alanlar toplanana kadar · tek_dönüş = hiçbir zaman.
Mod | Sürece dahil olan insan | Paralel mi? | Üst öğeye döner |
| tam görüşme | hayır | manuel (aktarım yoluyla) |
| yalnızca açıklayıcı sorular | hayır | otomatik ( |
| yok | yes | otomatik (sonucuyla birlikte) |
mode yalnızca alt aracılara uygulanır, asla koordinatöre uygulanmaz. İş akışı düğümleri varsayılan olarak single_turn (bu nedenle L1-L2b bunu hiçbir zaman yazmadı), alt aracılar ise varsayılan olarak chat (bu nedenle L3a bunu yazmak zorunda kaldı) olarak ayarlanır.
⚠️ Bu sürümü oluşturmadan önce iki sürüm notu: (1) task
Statik grafik düğümü olarak Workflow(...), sürüme bağlıdır. 2.0.0b1-2.3.0 sürümlerinde (bu codelab'in sabitlendiği sürüm) Workflow(...), oluşturma sırasında hata verir. Bu düzeyin yaptığı işlemi (görev alt aracılarına sahip bir sohbet koordinatörü) tam olarak kullanın veya ctx.run_node aracılığıyla gönderin. 2.5.0 sürümünde kaldırıldı. (2) "Görev aracıları, yaprak aracılar olmalıdır" (kendi alt aracıları olmamalıdır) belgelenmiş bir ADK sınırlamasıdır ancak çalışma zamanı koruması değil sözleşmedir: Ne 2.3.0 ne de 2.5.0 sizi durdurur. Hata olmaması, izin olduğu anlamına gelmez.
💡 Daha ayrıntılı bilgi: Grafik iş akışına yerleştirilmiş (2.5.0+ şekli) ve görüşmeyi tekrar denemek için başa döndürebilen yönlendirmeye sahip bir taskaracı: yardımcı depo 22_agent_in_workflow · tam mod kılavuzu: docs/agent-modes.md.
❓ Şunu merak ediyor olabilirsiniz:
task
satın alabilir miyim? Üç şey: Otomatik dönüş (sohbet, konuşmayı devam ettirir) · Yazılan bitiş çizgisi (finish_task'nin yükü şemaya göre doğrulanmalıdır. Transkript değil, veriler geri alınır) · Duraklatma/devam ettirme (⏸, takılma değil, insan müdahalesi bekleyen bekletilmiş bir görevdir).
👀 Okunanlar: gear_fitter — mode="task" + output_schema, sözleşmenin tamamıdır. · ▶ Çalıştırın. · ✏️ Değiştir: run_desk("I need a hydration vest", "2 liters, medium") Açıklayıcı soru uyarlanır, bitiş çizgisi yazılı kalır.
11. L4a · Çalışma zamanı boyutlu paralel fan-out (3a sütunu)
⚡ Çok kısa: İskelet hâlâ üç statik adımdan oluşuyor. Dinamik, genişliğin çalışma zamanındaki verilere göre belirlendiği ortadaki adımın içinde gizleniyor.
⚠️ Önemli: Bu, merdivenin en zorlu adımıdır. Önceki seviye 44 satırdan oluşuyordu. Bu seviye ise yaklaşık 120 satırdan oluşuyor. Üç aracı ve iki iş akışı düğümü var ve bunların hiçbiri dolgu değil. Yaklaşık 15 dakika ayırın ve sonunda Okuma/Çalıştırma/Değiştirme satırına odaklanın: İlk okumada her satırı anlamanız gerekmez.
Soru: Çalışmanın şekli, girişe bağlıdır. Grafiği önceden çizemezsiniz. Çalışma zamanı genişliği ile başlayın: LLM'nin kaç tane alt soruya karar vermesine izin verin.
Şekil (bir düzey derinliğinde):
START ─► decompose ─► research_topic (parallel_worker) ─► synthesize
│ │ │
└──┴──┴─ (flat: no children yet)
Açık uçlu bir soru, N alt soruya ayrılır. N, çalışma zamanında LLM tarafından seçilir (3-7). Her biri paralel olarak araştırılır ve ardından tek bir özet halinde sentezlenir.
▶ Colab: L4a hücresini çalıştırın. · 📁 GitHub: L4a_flat_research/ · 💻 Yerel: python -m L4a_flat_research.deep_research
🔍 İşaretçiler —
dynamic=True
anahtarı. Dinamik, bir yapılandırma değil yazma yöntemidir. Yalnızca iki işaretçi vardır: @node(parallel_worker=True) (çalışma zamanı boyutunda bir liste alır, öğe başına bir çalışan çalıştırır) ve ctx.run_node(...) (kod planlama düğümlerini doğrudan çalıştırır). İkisinden birini görüyorsanız → Dinamik moddasınız.
Gördükleriniz: Ayrıştırıcı, örneğin 5 alt soru yazdırır, bunlar paralel olarak araştırılır ve ardından sentezlenmiş bir özet oluşturulur. Sayı her çalıştırmada farklıdır. Sabit grafik bunu yapamaz.
Çalışanla ilgili olarak anlaşılması gereken iki işaret vardır:
rerun_on_resume=True,ctx.run_nodeişlevini çağıran tüm düğümlerde zorunludur. ADK, bu işlev olmadanValueErroroluşturur. Devam ettirildiğinde, oluşturduğu alt öğeler statik grafikte olmadığından, gönderme düğümünü yeniden yürütmesi gerekir.retry_config=Bu, nasıl BAŞARISIZ OLUR? Paralel çalışan, her kardeş görevi iptal eder ve bir alt görev başarısız olduğunda anında yeniden başlatır. Bu nedenle, yeniden deneme yapılmadan, geçici bir 429 hatası, halihazırda ödenmiş olan her çağrı da dahil olmak üzere tüm çalıştırmayı iptal eder. Yeniden deneme, öğe başına olan iç düğüme ulaşır. Bu nedenle, her dal bağımsız olarak yeniden denenir.
❓ Şunu merak ediyor olabilirsiniz: ADK, bunun dinamik olduğunu nereden "biliyor"? Hiçbir yerde beyan edilmediği için gerekmez. Ayrıştırıcı, çalışma zamanında bir liste oluşturur. Paralel çalışan, gelen öğelere göre boyutunu ayarlar. Dinamizm, etkinleştirdiğiniz bir mod değil, yazdığınız veri akışının bir özelliğidir.
👀 Okuma: research_topic üzerindeki iki işaret: parallel_worker ve rerun_on_resume. · ▶ Çalıştırın. · ✏️ Değişiklik: Kendi açık uçlu sorunuzu ekleyin. Giriş genişliğe karar verdiği için N değişir.
12. L4b · Add recursive spawning (Pillar 3b)
⚡ Çok Kısa Özet: Özyineleme verilmez, yazılır. Çalışan, ctx.run_node (sıradan Python) aracılığıyla kendisini çağırır. Bu nedenle, durdurma da yazılmalıdır. Bu MAX_DEPTH.
Soru: Bir araştırma bulgusu bazen kendi başına incelenmeye değer dar bir alt konuyu ortaya çıkarır. Bir dalın daha fazla paralel iş oluşturmasına nasıl izin verirsiniz ve bunu nasıl sınırlarsınız?
Şekil (artık yinelemeli):
START ─► decompose ─► research_topic (parallel_worker, recursive) ─► synthesize
│ │ │
│ │ └─ research(q3) ─► maybe spawn children
│ └─── research(q2) ─► maybe spawn children
└────── research(q1) ─► maybe spawn children
▶ Colab: L4b hücresini çalıştırın. · 📁 GitHub: L4b_recursion/ · 💻 Yerel: python -m L4b_recursion.deep_research
@node(parallel_worker=True, rerun_on_resume=True)
async def research_topic(ctx, node_input):
finding = coerce(await ctx.run_node(research_agent, node_input=...), ResearchFinding)
if finding.needs_deeper and finding.deeper_questions and depth < MAX_DEPTH: # boundary in CODE
children = await ctx.run_node(research_topic, node_input=deeper) # recursive fan-out
yield Event(output={..., "children": children})
🔍 İşaretçiler: ctx.run_node(research_topic, ...) içindeki research_topic kendisi (özyineleme olan kendi kendine referans) ve bir satır üstündeki koruma depth < MAX_DEPTH.
Gördükleriniz: spawning N deeper yazan araştırma düğümleri (canlı olarak gerçekleşen yineleme) ve ardından bir çalışma zamanı ağacı şekli (ör. 5 top-level + 10 recursive children). Ağaç, her çalıştırmada farklıdır.
⚠️ Düğmeyi yükseltmeden önce: Tavan değeri hızla artar. MAX_DEPTH=3, en kötü durumda yaklaşık 30 çağrıdan yaklaşık 93 çağrıya çıkar. Ayrıca, bir çalıştırmanın en sonunda cancelling N leftover tasks günlük satırını görebilirsiniz. Bu, sonuç tamamlandıktan sonra ADK'nın paralel görev grubunu kapatmasıdır. Zararsızdır ve günlük kaydı yapılandırmanıza bağlı olarak bu mesajı hiç görmeyebilirsiniz.
❓ Şunu merak ediyor olabilirsiniz: Dinamik, varsayılan olarak yinelemeli değil mi? Hayır. L4a, sıfır yinelemeyle tamamen dinamiktir. Dynamic yalnızca sıradan Python kontrol akışını sunar. L4b, bununla özyineleme yazmayı tercih eder. Özyinelemeyi siz yazdığınız için sınırını da siz yazmalısınız. İşte bu noktada "Büyük dil modelinin çalışmaya şekil vermesine izin verin, sınırları kodda tutun" slogan olmaktan çıkar.
👀 Okuyun: Koruma: if finding.needs_deeper and depth < MAX_DEPTH. · ▶ Çalıştırın. · ✏️ Değiştirme: MAX_DEPTH = 1 ayarlanır ve yeniden çalıştırılır. Ağaç düzleşir (ve çalıştırma daha ucuz olur). Sınır, kodda SİZE aittir.
13. L5 · Hangi kalıbı kullanmalısınız?
⚡ Özet: Her şeyi bir eksen belirler: Bir sonraki adımı kim seçer? Çizdiğiniz grafik, LLM veya kodunuz.
Üçünü de oluşturmuş olmanız gerekir. Bu modeli kullanmak için sorununuzun şekliyle kalıbı eşleştirin.
Eksen: Bir sonraki çalıştırılacak öğeye kim karar veriyor?
Sütun | Bir sonraki yayını kim belirler? | Yerleşik |
1 · Grafik | Çizdiğiniz grafik | L2a / L2b |
2 · İşbirlikçi | LLM | L3a / L3b |
3. Dinamik | çalışma zamanında Python kodunuz | L4a / L4b |
0. adım: Grafiğe ihtiyacınız var mı?
ADK, önceden oluşturulmuş iş akışı aracıları (SequentialAgent, ParallelAgent, LoopAgent) ile birlikte gelir. Basit bir aracı zincirinde bunlar en ucuz doğru yanıttır ve birleştirilecek bir grafik yoktur. Açık yönlendirme (L2b'nin yönlendiricisi), birleştirme (L2a'nın JoinNode) veya aracı olmayan düğümler (basit bir işlev, sıfır LLM çağrısı) gerektiğinde bu sınıra ulaşabilirsiniz. Genellikle bu sonuncusu sınıra ulaşma nedenidir.
Would a prebuilt SequentialAgent / ParallelAgent / LoopAgent do?
│
├─ YES ──────────────────────────────► use it; stop here
│
└─ NO — I need routing, a join, or non-agent nodes
│
Can you draw the workflow before the input arrives?
│
├─ YES ───────────────────────────► Pillar 1 · Graph workflow (L2a/L2b)
│
└─ NO
├─ Known team, request picks the subset? ─► Pillar 2 · Collaborative (L3a/L3b)
└─ Does the shape depend on the input? ──► Pillar 3 · Dynamic (L4a/L4b)
Dürüst 1.x-vs-2 çerçeveleme
Bu, "2.0, 1.x'in yapamadığı şeyleri yapabilir" değildir. 1.x, bunların hepsini oluşturabilir. Bu değişiklikle birlikte 2.0, her şekle daha doğrudan bir yer veriyor. Böylece bilinen kontrol akışı istemden ayrılıp görebileceğiniz ve test edebileceğiniz bir yapıya dönüşüyor.
Kalıp | 1.x maliyeti | ADK 2 ana sayfası |
Grafik | Ortak derlemede 4 LLM çağrısı; yönlendirme istemde gizleniyor | işlev + aracı düğümleri eşler olarak → 1 çağrı, |
Ortak çalışma (Collaborative) |
| Bildirilmiş bir takım: |
Dinamik | özyineleme sizi çerçeve dışına çıkarır | Çerçeve içinde |
Uygulamanın tamamı ve grafiğin gösteremeyecekleri
Aşağıdaki tüm parçaları oluşturdunuz. Workflow, yapısını graph.edges adresinde gösterir. Bu nedenle bu resim, elle çizilmek yerine koddan oluşturulur. İntrospeksiyonun bulduğu şey ise bu laboratuvarın özetidir:
Sütun |
| Neden? |
1 · Grafik (L2b) | 10 kenar, rotalar ve her şey | giriş gelmeden önce çizdiyseniz |
2 · İşbirlikçi (L3a) | 0 kenar: Yalnızca | LLM, istek başına alt kümeyi seçer. |
3 · Dinamik (L4a/L4b) | 3 kenar: Her ikisinde de aynı | the recursion is written in Python, not wired in the graph |
Son satır, L4b'nin yanıtladığı sorunun kanıtıdır: L4a ve L4b, aynı grafiğe sahiptir ve yalnızca biri yinelemelidir.
Şu anda oluşturabileceğiniz öğeler
Az önce çalıştırdığınız her desen gerçek bir ürün şeklidir:
Alıştırma yaptınız | Doğada bu | Başlangıç |
Grafik + yönlendirici (L2a/L2b) | belge ardışık düzenleri, ETL-with-LLM-steps, inceleme/onay zincirleri, değerlendirme koşumları | bu depodaki L2b |
Koordinatör + | Uzman ekipler, triyaj masaları ve çok yönlü inceleme özelliklerine sahip bir destek yardımcı pilotu | marathon demo mode 2 |
| formları, rezervasyon akışları, oryantasyon, KYC (Müşterinizi Tanıyın) gibi "önce topla, sonra harekete geç" | |
Dinamik genişlik/derinlik (L4a/L4b) | araştırma aracıları, rapor oluşturucular, bilinmeyen boyutlu girişler üzerinde denetim taramaları | marathon demo modu 3 |
Oluşturma
Üç kalıp birbirini dışlamaz. Grafik düğümü, ortak çalışma koordinatörünü arayabilir. Uzman, dinamik iş akışı başlatabilir. Sorunun her bir bölümü için doğru kalıbı seçin. Böylece her aracı sistemini tek bir devasa isteme dönüştürmekten kaçınabilirsiniz.
💡 Kendi iş akışınızda deneyin: Bu görseli oluşturan komut dosyası scripts/graph_dump.py. Herhangi bir Workflow üzerine tuttuğunuzda gerçek kenarları yazdırır. Böylece, inşa ettiğiniz her şeyin ücretsiz bir yapısal diyagramını elde edersiniz.
14. Tebrikler
Maraton Yarışı Günü Koçu ve bu süreçte ADK 2'nin üç düzenleme kalıbını da oluşturdunuz.
Öğrendikleriniz
- Prologue: Kendi hava durumunu icat eden mega istem. Yapının neden var olduğunu açıklar.
- L0-L1:
Agent,Runner, modelin çağırmayı seçtiği gerçek bir araç ve ilkWorkflow(eşler olarak işlev düğümleri + aracı düğümleri). - L2a / L2b: Grafik iş akışları: paralel dağıtım +
JoinNode, ardından deterministik yönlendirme (tek bir LLM çağrısı). - L3a: İşbirlikçi aracılar: Aynı ekip önce
chat(bağlantısız) sonrasingle_turn(paralel alt küme + sentez) olarak çalışır. Bir işaret, iki dünya. - L3b —
taskmodu: duraklatılmış bir açıklama sorusu, senaryolu bir devam ettirme,finish_taskdoğrulanmış bir nesneyi döndürme. - L4a / L4b: Dinamik iş akışları: Çalışma zamanı genişliği (fan-out), ardından kodda sınırlarla çalışma zamanı derinliği (özyineleme).
- L5: Karar ağacı ve kalıpların nasıl oluşturulduğu.
Saklanmaya değer satırlar
İşlevler bağlamı hazırlar. Kenarlar iş akışını tanımlar. Yolu yönlendirici seçer. Model, yanıtı yazar.
Çalışmaya LLM'nin yön vermesine izin verin ancak sınırları kodda tutun.
Deseni sorununuzun şekliyle eşleştirin.
Sonraki adımlar
- Bu seviyelerin elde edildiği tam uygulamayı (Marathon Race Day Coach) çalıştırın. Bu uygulama, üç modun tamamını canlı olarak gösteren bir tarayıcı kullanıcı arayüzüyle birlikte FastAPI + SSE derlemesidir: github.com/cuppibla/adk-2-marathon-demo.
- Kapsamı genişletin: adk-workflows-compared: Her biri 1.x bağlantı noktasına ve ne zaman kullanılacağına dair rehberliğe sahip 23 resmi ADK 2 iş akışı örneği.
docs/three-pillars.mdile başlayın, ardından bu Codelab'in atladığı konuları (07_loop,17_request_input,22_agent_in_workflow) inceleyin. - Kendi sorununuzu sınıflandırın: Hangi kısımlar bilinen yapı (L2), bilinen ekip (L3a/L3b), bilinmeyen şekil (L4) kategorisine giriyor?
- Kodu inceleyin: github.com/cuppibla/adk2-tutorial.
- Atölyeye katıldınız mı? Krediniz ve oluşturduğu proje sonsuza kadar sürmez. Bu seviyeleri ücretsiz olarak yeniden çalıştırmaya devam etmek için bunun yerine Evde kurulum adımını uygulayın: ücretsiz AI Studio anahtarı, Cloud projesi ve faturalandırma gerekmez. Tek değişiklik, bu hücrenin değiştirilmesidir.