Herkes "Loop nedir?" diye soruyor. Ama kimsenin sormadığı soru şu: Loop'u ne çalıştırıyor?
AI söylemi, loop'ları ajan sistemlerinin temel bir yapı taşı olarak kabul etti. Matt Van Horn (@mvanhorn), ajan loop'larının soyunu ReAct'ten araç kullanımına, orkestrasyon loop'larından loop'ları denetleyen loop'lara kadar takip etti. Addy Osmani (@addyosmani), loop'ların içindeki yapı taşlarını inceledi: otomasyonlar, iş ağaçları, yetenekler, bağlayıcılar, alt ajanlar. Van Horn, dayanıklılık kavramına odaklandı ve bir yeniden başlatmadan sağ çıkamayan loop'ların gerçek loop olmadığını savundu. Osmani'nin ana teması ise orkestrasyon idi: ajanı sizin yerinize yönlendiren sistemi tasarlamak.
Ben onların görüşlerini biraz daha ileri götürmek istiyorum. Dayanıklılık sadece loop'un bir özelliği değil. Aynı zamanda onun altındaki tüm yürütme katmanıdır. Önemli olan gerçek şu ki, dayanıklı orkestrasyon, ajan loop mimarinizi oluşturmanın temelidir. Şimdi bu mimariyi inceleyelim.
Loop'ların kırıldığı yerler
/loop ve /goal desenleri, tek ajanlı, tek oturumlu işlerde iyi çalışır. Bir ajan, görev tamamlanana kadar loop yapar. Bu, pek çok durumu kapsar. Ancak bir sonraki aşama (Van Horn'un çerçevesinde 5. Aşama) işlerin dağıldığı yerdir:
- Diğer loop'ları denetleyen loop'lar
- Bir insan tarafından tetiklenmek yerine programlı olarak çalışan loop'lar
- Süreç yeniden başlatmalarından, dağıtımlardan ve çökmelerden sağ çıkan loop'lar
- Alt ajanlar oluşturan ve sonuçları bekleyen (bazen saatler süren) loop'lar
- Sonradan gözlemlenebilir olması gereken loop'lar
Bu bir yönlendirme sorunu değil. Bu bir altyapı sorunu.
Van Horn, @runes_leo'yu aktarıyor: "AI kodlamadaki en maliyetli şey artık kod yazmak değil, ajan loop'unu yönetmek." Bir terminaldeki while True döngüsü size bunların hiçbirini sağlamaz. Bir VM veya sandbox üzerindeki uzun süreli bir süreç de sağlamaz.
Bir sunucuda bir ajan loop'u çalıştırdığınızda ne olduğunu düşünün. Süreç ölecek veya yeniden başlayacaktır. Bir dağıtım, bir OOM, bir spot örnek geri alımı. Loop yeniden başlar. Peki ne yapıyordu? Hangi adımdadaydı? O Slack mesajını zaten göndermiş miydi? Alt ajanı zaten çağırmış mıydı?
Bilmiyorsunuz. Baştan başlar. Zaten sahip olduğu verileri yeniden getirir. Zaten verdiği kararlar için LLM'yi yeniden çağırır. Yinelenen bir bildirim gönderir. Yinelenen bir alt ajan oluşturur. Sabah uyandığınızda üç tane aynı Slack mesajı ve kafası karışmış bir ekiple karşılaşırsınız.
Çözüm "daha iyi hata yönetimi" değil — her adımın kontrol edildiği, her kararın kalıcı hale getirildiği ve kurtarmanın son başarılı adımdan devam etmek anlamına geldiği bir yürütme modelidir.
Üç katmanda ajan loop mimarisi
Üç katman. Her biri somut bir ilkel yapıya karşılık gelir.
Katman 1: Loop (Döngü)
Bir loop, bir cron artı bir karar vericidir. Bir programa (veya tetikleyiciye) göre çalışır, durumu değerlendirir ve bir sonraki adımda ne yapacağına karar verir.
Bu, Van Horn'un tanımının somut hale getirilmiş halidir: cron'un hiç sahip olmadığı şey, ortadaki karar mekanizmasıdır. Kararı siz değil, ajan verir. Cron kalp atışıdır. LLM karar vericidir. Adımlar ise ilerlemeyi kontrol eden dayanıklı yürütmedir.
1export const infraHealthCheck = inngest.createFunction(2 { id: "infra-health-check" },3 { cron: "*/30 * * * *" }, // Her 30 dakikada bir4 async ({ step }) => {5 const metrics = await step.run("fetch-service-metrics", async () => {6 return await fetchServiceMetrics(); // hata oranları, gecikme, bellek, CPU7 });89 const assessment = await step.run("assess-health", async () => {10 return await callLLM({11 prompt: `Bu servis metriklerine göre, genel sistem sağlığını12 "normal", "bozulmuş" veya "kritik" olarak sınıflandır.13 Gerekçeni açıkla.14 Metrikler: ${JSON.stringify(metrics)}`,15 });16 });1718 if (assessment.status === "degraded" || assessment.status === "critical") {19 await step.invoke("triage-incident", {20 function: incidentTriage,21 data: { metrics, assessment, services: assessment.affectedServices },22 });23 }24 }25);
Her Pazartesi saat 9'da loop tetiklenir. Verileri getirir, LLM'ye bir raporun gerekip gerekmediğini sorar ve cevap evet ise bir yeteneği çağırır. Süreç adımlar arasında yeniden başlarsa, tamamlanmış adımlar yeniden yürütülmez. İşte loop budur. LLM değil, LLM'nin etrafındaki loop.
Katman 2: Yetenek
Bu bağlamda, bir yetenek bir yönlendirme değildir. Dayanıklı bir iş akışıdır. Çok adımlı, yeniden denenebilir, birleştirilebilir, bağımsız olarak dağıtılabilir.
Van Horn: "Loop tesisattır. Değerli olan, çağırdığı yetenektir." Bu, birikerek artan kısımdır. Sistemin öğrendiği her yeni yetenek, her loop'u daha yetenekli hale getirir.
1export const incidentTriage = inngest.createFunction(2 { id: "incident-triage", retries: 3 },3 { event: "infra.incident.triage" },4 async ({ event, step }) => {5 const details = await step.run("fetch-detailed-metrics", async () => {6 return await fetchDetailedMetrics({ services: event.data.services });7 });89 const deploys = await step.run("fetch-deploy-history", async () => {10 return await fetchRecentDeploys({ since: hoursAgo(2) });11 });1213 const analysis = await step.run("correlate-incident", async () => {14 return await callLLM({15 prompt: `Bu servis metriklerini son dağıtımlarla ilişkilendir.16 Olası kök nedeni ve önem derecesini belirle.17 Metrikler: ${JSON.stringify(details)}18 Son dağıtımlar: ${JSON.stringify(deploys)}`,19 });20 });2122 await step.run("post-triage-summary", async () => {23 await slack.postMessage({24 channel: "#incidents",25 text: formatTriageSummary({26 analysis,27 affectedServices: event.data.services,28 recommendedActions: analysis.recommendations,29 }),30 });31 });3233 return analysis;34 }35);
Bu yetenek, getirir, sınıflandırır ve yönlendirir. İçinde yerleşik hata toleransı olan bir iş birimidir. Yetenek, ortasında bir LLM bulunan bir AI iş akışı veya deterministik kod olabilir.
Katman 3: Orkestratör
Orkestratör, her şeyi çalıştıran motordur: cron'ları zamanlar, adımları yürütür, yeniden denemeleri yönetir, eşzamanlılık sınırlarını uygular, çalışma geçmişini depolar ve çalışan iş akışlarını bozmadan yeni fonksiyonları/iş akışlarını sıcak dağıtır.
Bu, kimsenin konuşmadığı katmandır çünkü görünmez olması gerekir. Ancak temeldir.
Çoğu insan ajanları "LLM + araçlar" olarak düşünür. Ajan loop mimarisi bunu yeniden çerçeveler: ajanlar "loop'lar + yetenekler + orkestrasyon"dur. LLM'ler ve araçlar loop'ların içindedir. LLM'ler ve araçlar, mimari aynı kalırken değiştirilebilir veya ayarlanabilir. Orkestrasyon, mimariyi mümkün kılar.
İşler bozulduğunda ne olur
Mutlu yol kolaydır. Ancak bu, üretimde çalışan bir yazılımdır; gerçekten her şey hiç planlandığı gibi gider mi?
Olay triyaj yeteneğiniz tetiklenir ve metrikler API'si zaman aşımına uğrar. Okuma işlemi diske gitmek zorunda kalmıştır ve bellek içi önbellekte veri yoktur. Bu API'yi çağıran adım şimdi yeniden dener ve API'ye tekrar vurur. Veriler artık kısmen önbelleğe alınmıştır ve API tamamlanır. Yetenek, hiçbir şey olmamış gibi bir sonraki adımla devam eder.
Bazen bu kadar basit olmayabilir. Ya bir API anahtarının süresi dolarsa veya barındırma sağlayıcınız 30 dakika boyunca kapalı kalırsa? Tüm yeniden denemeleriniz tükenir. Şimdi ne olur? Başarısızlıkları da ele almanız gerekir.
1export const incidentTriage = inngest.createFunction(2 {3 id: "incident-triage",4 retries: 3,5 onFailure: async ({ error, event, step }) => {6 // Tüm yeniden denemeler tükendikten sonra fonksiyon başarısız oldu.7 // Hala orijinal olay verilerine sahibiz. Hiçbir şey kaybolmadı.8 await step.run("notify-failure", async () => {9 await slack.postMessage({10 channel: "#agent-ops",11 text: `⚠️ Olay triyajı başarısız oldu: ${error.message}. ` +12 `Bir sonraki sağlık kontrolü döngüsünde yeniden denenecek. ` +13 `Etkilenen servisler: ${event.data.services.join(", ")}`,14 });15 });16 },17 },18 { event: "infra.incident.triage" },19 async ({ event, step }) => {20 /* yukarıdaki yetenekle aynı mantık */21 }22);
\onFailure\ işleyicisi, tüm yeniden denemeler tükendikten sonra tetiklenir. Bir operasyon kanalına mesaj gönderir, böylece birileri durumdan haberdar olur. Olay korunur, hiçbir şey kaybolmaz. Bir sonraki planlanmış çalıştırma, başarısız olanın kaldığı yerden devam eder.
Dayanıklı orkestrasyon, geçici hatalar için adım düzeyinde yeniden denemeler ve kurtarılamaz hatalar için başarısızlık yönetimi kancaları sağlamalıdır. Bu olmadan, işler (olduğu gibi) bozulur ve saatler veya günler sonra haberdar olursunuz.
Geçici hatalar ayrıca pahalıdır. Yeteneğiniz veya ajanınız baştan yeniden denerse, LLM'leri birden çok kez çağırır ve gereksiz yere token yakarsınız. LLM çağrısı kontrol edilebilir. Şimdi bunu sisteminizdeki 10 veya 30 ajanla çarpın. Bu pahalıdır.
Adım düzeyinde kontrol noktası belirleme sadece bir doğruluk özelliği değildir. Aynı zamanda bir para tasarrufu sağlayıcısıdır.
Kendi yeteneklerini oluşturan ajan
İşte burası daha da ilginçleşiyor. Sistem statik değildir; kendini geliştirmek ve genişletmek için tasarlanmıştır.
Ajan sadece loop'ların içinde çalışmaz — yeni loop'lar oluşturur ve bunları orkestrasyon motoruna kaydeder. Dağıtılan her fonksiyon, bir loop veya ajandan tetiklenebilen veya bir programda çalışabilen, kendi yeniden deneme mantığına sahip, bağımsız olarak çalışan dayanıklı bir yetenektir. Yetenekler birikir.
Bu, orkestrasyonun farkında olan bir ajandır.
İşte nasıl çalıştığı. Bir AI ajanı, bir araç olarak orkestrasyon SDK'sına erişebilir. Yeni fonksiyonlar yazabilir, bunları motora kaydedebilir ve hemen çalışmaya başlarlar. Ajan süreci, devam eden çalıştırmaları yeniden başlatmadan veya bozmadan yeni fonksiyonları sıcak olarak yeniden yükler.
Somut bir örnek üzerinden gidelim:
1. Bir insan bir ihtiyacı ifade eder. Mühendis der ki: "Servislerimizde gece boyunca gecikme ani artışları oluyor ve sabaha kadar kimse fark etmiyor." Bu tetikleyicidir. Ajanın ortam verilerinden belirsiz bir model çıkarması gerekmez. Net talimatları vardır.
2. Ajan bir yetenek yazar. İki çok adımlı fonksiyon: her 30 dakikada bir çalışan, hata oranlarını, gecikmeyi ve kaynak kullanımını çeken ve LLM'nin sistem sağlığını normal, bozulmuş veya kritik olarak sınıflandırdığı bir sağlık kontrol loop'u. Ve ayrıntılı metrikleri ve son dağıtım geçmişini getiren, LLM ile kök nedenleri ilişkilendiren ve Slack'e önerilen eylemlerle birlikte bir triyaj özeti gönderen bir olay triyaj yeteneği. Hata yönetimi: metrikler API'si kapalıysa, geri çekil ve yeniden dene. LLM başarısız olursa, kural tabanlı önem sınıflandırmasına geri dön.
3. Ajan yeteneği dağıtır. Ajan, bir yan işlem tarafından alınan fonksiyon kodunu yazar. Yeni fonksiyonlar otomatik olarak kaydedilir. Hiçbir dağıtım hattı, hiçbir PR olmadan hemen canlı olurlar.
4. Yetenek otonom olarak çalışır. Her 30 dakikada bir, motor sağlık kontrolünü tetikler. Bir şeyler yanlışsa, triyaj yeteneğini çağırır. Döngüde insan yok. Tamamen dayanıklı.
5. Ajan sinyale göre yineleme yapar. Bu, insanların üstünkörü geçtiği kısımdır, bu yüzden "yineleme"nin ne anlama geldiğini açıklayayım. Ajan sihirli bir şekilde desenleri fark etmez. Ayrı bir inceleme loop'u vardır: haftalık olarak tetiklenen bir cron fonksiyonu, orkestratörden çalışma geçmişini okur ve performansı değerlendirir:
1export const reviewSkillPerformance = inngest.createFunction(2 { id: "review-skill-performance" },3 { cron: "0 10 * * 5" }, // Her Cuma saat 10'da4 async ({ step }) => {5 const runs = await step.run("fetch-run-history", async () => {6 return await getInngestRuns({7 functionId: "incident-triage",8 since: daysAgo(7),9 });10 });1112 const analysis = await step.run("analyze-performance", async () => {13 const successRate = runs.filter(r => r.status === "completed").length / runs.length;14 const avgDuration = average(runs.map(r => r.duration));15 const incidents = await fetchIncidentOutcomes(); // Olaylar gerçek kesintilerle ilişkili miydi?1617 return await callLLM({18 prompt: `Bu yeteneğin geçen haftaki performansını değerlendir.19 Başarı oranı: ${successRate}20 Ort. süre: ${avgDuration}ms21 Gerçek kesintilerle ilişkili olaylar: ${incidents.confirmed}/${incidents.total}22 Yanlış pozitifler: ${incidents.falsePositives}23 Ekip uyarılara aksiyon aldı: ${incidents.actedOn}/${incidents.total}2425 Eşik değerlerini veya sınıflandırmayı ayarlamalı mıyız? Hangi spesifik değişiklikler?`,26 });27 });2829 if (analysis.shouldModify) {30 await step.invoke("update-skill", {31 function: coreAgent,32 data: { prompt: `Olay triyaj yeteneklerini aşağıdaki önerilen değişikliklere göre güncelle: ${analysis.proposedChanges}` },33 });34 }35 }36);
"İnceleme" bir fonksiyondur. Çalışma geçmişini okur, olayların gerçek kesintilerle ilişkili olup olmadığını kontrol eder ve bu sinyali LLM'ye besler. Sağlık kontrolü bir servisi sürekli bozulmuş olarak işaretliyor ancak ekip bunu görmezden geliyorsa çünkü eşikler çok hassastır, inceleme loop'u bunu yakalar ve yetenek sınıflandırmayı ayarlamak için güncellenir. Sihir değil. Karar koltuğunda bir LLM olan bir cron işi.
Peki ya doğrulama? Kod yazan ajan, etrafındaki güvenlik önlemleri kadar iyidir. Kod tip kontrolünden geçirilebilir. Ajan, orkestrasyon motoruyla kendisi etkileşime girebildiği için fonksiyonu test etmek üzere çağırabilir. Kurşun geçirmez olmasa da, çekirdek ajana, çalıştığı sistem içinde yazdığı yetenekleri yerel olarak hata ayıklama yeteneği veriyorsunuz. İnceleme loop'u, ilk hata ayıklamada yakalanmayan sorunları yakalar.
Bunu bir adım daha ileri götürürsek, ajan, belirli bir başarısızlığı değerlendirmek için kendini tetiklemek üzere onFailure kancalarını kullanabilir. Bu, kendini sürekli geliştiren bir geri bildirim döngüsüdür.
Peki ya çatışmalar? Akış kontrolleri, özellikle eşzamanlılık kontrolleri veya singleton'lar basit durumu halleder (concurrency: { limit: 1, key: "[event.data.service" }]), yani servis başına aynı anda yalnızca bir olay triyajı çalışır. Ancak daha derin soru şudur: Ya iki sağlık kontrolü aynı anda aynı serviste sorun tespit ederse? Orkestratör onları sıraya koyar. İkinci triyaj, birincisi tamamlanana kadar bekler. Yinelenen uyarı yok, yarış koşulu yok. Bu teorik değil. Herhangi bir iş kuyruğunda kullanacağınız aynı eşzamanlılık ilkelidir.
Ajan sadece görevleri yürütmüyor. Kendisi için altyapı inşa ediyor. Her yetenek, onu oluşturan konuşmanın ötesinde kalıcı olur. Ajan sürecini öldürün ve yeniden başlatın. Yetenekler çalışmaya devam eder. Temel modeli değiştirin. Yetenekler çalışmaya devam eder. Ajan geçicidir — çıktısı dayanıklıdır.
Ajan loop mimarisi sistem genel bakışı
Geliştiricinin bakış açısı
Bu önemlidir çünkü geliştirici ajanın ne dağıttığını göremez, neyin bozulduğunu hata ayıklayamaz ve saat 3'te neyin çalıştığını denetleyemezse, tüm mimari büyük bir yükümlülük haline gelir.
Orkestrasyon motoru, her çalıştırmayı, her adımı, her girdiyi, her çıktıyı, her yeniden denemeyi depolar. Ajanın geçen Salı dağıttığı ve sabah 4'te başarısız olan bir yetenek mi? Hangi adımın başarısız olduğunu, girdinin ne olduğunu, hangi hatayı fırlattığını ve vazgeçmeden önce kaç kez yeniden denediğini tam olarak görebilirsiniz. Adım düzeyine kadar tam izlemeler, orkestrasyon motorunun kendisinin çıktısıdır.
Bu, sonradan eklenmiş bir kontrol paneli değildir. Dayanıklı yürütmenin doğasında vardır. Her step.run() bir kontrol noktasıdır. Her kontrol noktası gözlemlenebilirdir. Kodu yazan şey bir insan olmadığında, gözlemlenebilirlik olmazsa olmaz değil, güven katmanıdır.
Günlük olarak, geliştiricinin iş akışı şöyle görünür: sabah çalıştırma panosunu kontrol et. Geceleri hangi yeteneklerin çalıştığını, hangilerinin başarılı olduğunu, hangilerinin başarısız olduğunu gör. Ajan tarafından yazılan bir yetenek yanlış davranıyorsa, kodu doğrudan okuyabilir, düzenleyebilir, silebilir veya ajana düzeltmesini söyleyebilirsin. Ajan onu yazdı, ama sahibi sensin. Ajan ve yetenekleri hala bakman gereken bir bahçedir.
Dayanıklılık neden temeldir
Van Horn: "Bu şeyler bir yeniden başlatmadan sağ çıkmak zorunda."
İşte dayanıklılığın pratikte ne anlama geldiği:
Gereksinim
Ne anlama geliyor
Temel while loop neden başarısız olur
Bağımsız adım yeniden deneme
5 adımdan 3'ü başarısız olursa, 1. ve 2. adımları değil, sadece 3. adımı yeniden dene
Loop yeniden başlatması her şeyi sıfırdan yeniden çalıştırır
Alt ajan yaşam döngüsü
Bir alt görev oluştur, bekle (belki saatler), ebeveyn iptal edilirse iptal et
Yerleşik ebeveyn-çocuk yaşam döngüsü yönetimi yok
Garantili olay teslimi
Ajan kapalıyken bir olay tetiklenirse, yine de işlenmelidir
Süreç çalışmıyorsa olaylar kaybolur
Sonradan gözlemlenebilirlik
Sonradan ne olduğunu gör: her adım, her karar, her yeniden deneme
Günlükler tek seçeneğinizdir ve geçicidirler
Kesintisiz sıcak dağıtım
Devam eden çalıştırmaları öldürmeden yeni bir fonksiyon sürümü dağıt
Süreç yeniden başlatması her şeyi öldürür
Eşzamanlılık kontrolü
Bir yeteneğin aynı anda yalnızca N örneğini çalıştır
Yerleşik eşzamanlılık ilkelleri yok
"Sadece bir kapsayıcıda çalıştır" size çalışma süresi kazandırır. Size doğruluk kazandırmaz. Bir çökmeden sonra yeniden başlayan bir kapsayıcı süreci geri getirir, ancak devam eden her loop baştan başlar. Her adım yeniden yürütülür. Her LLM çağrısı yeniden yapılır. Loop çalışıyor gibi görünür, ancak körü körüne çalışır.
Mevcut araçlarla karşılaştırma
Bazı araçlar size bu tür bir sisteme "şık" bir anahtar teslim çözüm sunabilir veya daha düşük seviyeli araçları bir araya getirip kendi sisteminizi oluşturmayı seçebilirsiniz. Hiçbir seçim yanlış değildir, ancak doğru mimari katmanı, sizin ve ajanınızın zaman içinde gelişmesine izin vermelidir. Esnek, dinamik, dayanıklı.
Bir ajan için iyi uyum sağlayan ve bir ajanın kolayca yazabileceği dayanıklı yürütme ilkelleri ve ajanın orkestrasyonun farkında olmasını sağlamak için gözlemlenebilirlik ve API'ler.
Çalışan bir örnek
Bu desenleri Inngest'te dahili olarak test ediyoruz ve bunun bir konseptini "utah" proje deposunda görebilirsiniz: https://github.com/inngest/utah: Bu, Inngest'in dayanıklı orkestrasyonu üzerine inşa edilmiş ve aynı zamanda orkestrasyonun farkında olan bir ajan çerçevesidir.
Sistemde, ana ajanın kendi çalışma alanında Inngest fonksiyonları yazmasını ve düzenlemesini sağlayan, böylece kendini "yeteneklerle" (bu makale bağlamında) genişleten bir yan işlem bulunur. Yakında, başlangıç loop'ları örnek olarak tüm bir sistemi sağlamayı planlıyoruz, ancak oradaki fikirler bu makaledeki fikirleri biraz daha net bir şekilde gösterebilir.
Bileşik loop
Satya Nadella'nın son gönderisi, sektörün hissettiği bir şeyi adlandırdı: hendek model değil — loop'tur.
Onun çerçevesi: iki tür sermaye vardır. İnsan sermayesi, ekibinizin yıllar içinde oluşturduğu bilgi ve muhakeme. Ve onun token sermayesi dediği şey, bir şirketin temel modeller üzerine inşa ettiği AI iş akışları, karar desenleri ve öğrenilmiş yetenekler.
Tez: bunlar birlikte birleşir. Her gelişmiş iş akışı daha iyi sinyal üretir. Daha iyi sinyal, daha keskin AI davranışı üretir. Daha keskin davranış, insan dikkatini daha yüksek muhakeme gerektiren işler için serbest bırakır. Bir tepe tırmanma makinesi.
Ajan loop mimarisinin somut olarak sağladığı şey budur:
- Ajanın dağıttığı her dayanıklı yetenek, yürütülebilir altyapı olarak kodlanmış kurumsal bilgidir. Kalıcıdır. Bir insan izliyor olsun ya da olmasın çalışır.
- Yetenek performansını değerlendiren ve yineleyen bir cron tetiklemeli inceleme loop'u. İşte tepe tırmanma makinesi gerçek oldu. Bir slayttaki volan diyagramı değil. Bir cron tetikleyicili bir fonksiyon.
- Yetenekleriniz süreç yeniden başlatmasında ölürse, bileşik etki sıfırlanır. Dayanıklılık, yatırımın kalıcı olmasını sağlayan şeydir.
Nadella'nın kilit noktası: "Bir şirket, öğrenme sistemine yerleşik 'şirket emektarı' uzmanlığını kaybetmeden bir 'genelci' modeli değiştirebilmelidir." İşte bu yetenek kütüphanesi desenidir. Dayanıklı fonksiyonlar, hangi LLM'nin onları çağırdığı umursamaz.
Buna göre inşa edin
Konuşma, ajanların ne yaptığıyla ilgiliydi: loop'lar, araçlar, akıl yürütme, bağlam mühendisliği. Bir sonraki konuşma, ajanları neyin çalıştırdığıyla ilgili.
Üç katman: loop, yetenek, orkestratör. Loop iş birimidir. Yetenek değerli olandır. Orkestrasyon motoru, her ikisini de dayanıklı kılan şeydir. Yan işlem deseni modeldir: bir ajan kendi dayanıklı yeteneklerini yazar, dağıtır, nasıl performans gösterdiklerini inceler ve yineler. Bir düşünce deneyi değil. Çalışan bir model.
Biz Inngest'i bunun için orkestrasyon motoru olarak inşa ettik: step.run(), step.invoke(), cron tetikleyicileri, olay odaklı kontrol akışı, eşzamanlılık kontrolleri ve tam adım düzeyinde gözlemlenebilirlik. Ancak mimari desen, tek bir araçtan daha büyüktür. Üretimde ajan loop'ları oluşturuyorsanız, üç katmanı tanımlayın.
İlkeller bugün zaten var. Buna göre inşa edin.
