Fonksiyon Açıklamaları 01: Orkestrasyon Motoru

İlk görevden doğrulanmış yamaya

Agent Argo, bir görevi mümkün olduğunca uzun süre yürüten tek bir modelden oluşmaz. Yazılım çalışmasını anlaşılabilir adımlara dönüştüren bir sistemdir: planlama, bölme, işleme, denetleme, düzeltme ve ancak ondan sonra devralmaya sunma.

Bu yazıyla birlikte “Fonksiyon Açıklamaları” dizisi başlıyor. Agent Argo'nun merkezi mekanizmalarını anlaşılır kılıyor – bir pazarlama vaadi olarak değil, gerçek kullanımı boyunca. Açılışı Orkestrasyon Motoru yapıyor: bir gereksinimi denetimli bir çalışma sürecine dönüştüren akış.

1. Başlamadan önce: Kalite, Maliyet ve Özerkliği Belirleme

Argo bir görevi işlemeye başlamadan önce iki karar önemlidir. Bunlar bilinçli olarak birbirinden ayrılmıştır:

1. Argo maliyet ile sonuç kalitesi arasında nasıl dengelenmeli?
2. Argo projede ne kadar bağımsız hareket edebilir?

Bu, tipik bir hedef çatışmasını önler: Kapsamlı bir çalıştırma otomatik olarak daha fazla yazma izni almak zorunda değildir. Ve özerk bir çalıştırma otomatik olarak pahalı modelleri seçmek zorunda değildir.

Maliyet ve Kalite için Üç Aşama

Model yönlendiricisi üç anlaşılır mod bilir. Bunlar, fiyat ve model seviyesinin seçime ne kadar etki ettiğini değiştirir; gereken beceri her zaman merkezi kalır.

Aşama	Yönlendirici Modu	Uygun olduğu yer
Tutumlu	economy	Rutin görevler, çıkarım, net sınırlı değişiklikler. Maliyetler ağır basar.
Dengeli	balanced	Çoğu çalıştırma için standart: Beceri uyumu, maliyet ve kalite seviyesi dengede kalır.
İddialı	expert	Mimari, araştırma, karmaşık analizler ve iddialı incelemeler. Model seviyesi belirgin şekilde daha ağır basar, maliyet daha az.

Hızlı ve ucuz, Dengeli ve Kapsamlı işletme profilleri bu yönlendirici modunu ek kararlarla birleştirir: örneğin, ortak düşünmenin yalnızca izlenip izlenmeyeceği veya etkin olarak yürütülüp yürütülmeyeceği, doğrulamanın bağlayıcı olup olmadığı ve Argo'nun bir başarısız denemede daha güçlü şekilde yükseltme yapıp yapamayacağı.

Özerkliğin Üç Aşaması

Özerklik, Argo'nun nein doğru olduğunu değil, ne zaman bunun için bir insana ihtiyaç duyduğunu düzenler.

Aşama	Davranış
Güvenli	Argo analiz eder ve planlar. Değişiklikler inceleme için kalır; yazan veya riskli eylemlerden önce sorulur.
Dengeli	Normal değişiklikler izole bir çalışma durumu içinde oluşabilir. Silme, komutlar, indirmeler, ağ erişimi veya korumalı yollarda Argo yine sorar.
Tam özerk	Çalıştırma olağan sorular olmadan ilerler. Katı güvenlik, politika ve bütçe sınırları geçerliliğini korur.

Kodda bu kurallar readonly, confirm_write, auto_write ve bypass olarak daha kesin uygulanır. Üç aşama bunları kullanılabilir kılar; ancak proje politikası her zaman son merciidir. Örneğin bulut sağlayıcıları dışlayabilir, yalnızca yerel modelleri izin verebilir, ağ erişimlerini engelleyebilir, komutları sınırlayabilir, gizli bilgileri koruyabilir veya bir maliyet sınırı koyabilir.

2. CEO Katmanı Görevi Bir Plan Haline Getirir

Kullanıcı öncelikle hedefi normal dilde tanımlar. Argo'nun CEO katmanı bunun için sınırlı bir proje genel bakışı, mevcut model kataloğu ve ilgili proje bilgilerini alır. Açık sorularda önce sorabilir veya bir plan oluşturabilir.

Bir plan yalnızca bir yapılacaklar listesi içermez. Her görev bir rol, açıklama, bağımlılıklar ve gereken yetenekler alır – örneğin coding, planning, qa_review veya context_comprehension. Zor görevler için daha yüksek zorluk da not edilebilir. CEO katmanı katı şekilde bir model söylemez: İşi tanımlar, yönlendirici daha sonra görev başına uygun modeli kararlaştırır.

Plan böylece girişim üzerine insan tarafından okunabilir anlaşma olarak kalır, yürütme ise uyarlanabilir olabilir.

3. Plandan Bir Görev Grafiği Oluşur

Plan onayından sonra Argo görevleri bir görev grafiğine dönüştürür. Bir düğüm, bağımlılıkları başarıyla tamamlanmadan çalışamaz. Bağımsız görevler paralel çalışabilir.

Zamanlayıcı hazır düğümleri anlaşılır bir fayda sezgisine göre sıralar: beklenen kalite eksi maliyet, zaman ve risk cezası. Bir düğüm kritik yolda ise, eşitlikte öncelik alır çünkü çalıştırmanın toplam süresini belirler.

Yüksek belirsizlik veya yüksek risk durumunda Argo işlemeden önce ortak bir düşünme modu seçebilir: birden fazla perspektif yaklaşım geliştirir, birbirini eleştirir ve çalışan için gerekçelendirilmiş bir çalışma yaklaşımı sunar. Bunun yalnızca kaydedilip kaydedilmediği veya gerçekten yürütülüp yürütülmediği, çalıştırma öncesi seçilen işletme profili tarafından kararlaştırılır.

4. Her Görevden Önce: Uygun Bağlam, Uygun Yetenekler, Uygun Model

Bir çalışan başlamadan önce Argo, role ve göreve göre uyarlanmış bir bağlam kurar. Buna ilgili dosyalar, bağımlılık sonuçları ve – etkinse – kompakt bir bellek paketi ile uygun beceri kılavuzları dahildir. Argo tüm proje bilgisini körü körüne isteme aktarmaz. Bellek ve beceriler ilgi, kaynak, güncellik, maliyet ve güvenlik durumuna göre seçilir.

Ardından model yönlendiricisi bir model seçer. Önce ulaşılamayan, yeterli bağlam penceresi olmayan, kotası tükenen veya aktif politikayı ihlal eden adaylar elenir. Kalan modeller için Argo dört faktörü değerlendirir:

• Yetenek Uyumu: Bir model gereken beceriler için ne kadar iyi değerlendirilir? Birden fazla beceri varsa ortalama alınır.
• Maliyet: İstek ne kadar pahalı – veya aktif maliyet yönlendirmesinde muhtemel başarılı sonuç?
• Model Seviyesi: Zor, güvenlik kritik, mimari ve inceleme görevleri amiral gemisi seviyesini tercih edebilir.
• Deneyim Değerleri: Yeterli gerçek sonuçtan sonra bir model/beceri kombinasyonunun en son başarı ve tekrar oranı dahil edilir.

Maliyet hesabı için Argo Başarı Beklenen Maliyeti (Expected Cost of Success) kullanabilir: doğrudan fiyat, beklenen tekrarlar, doğrulama yükü, olası yeniden işleme ve küçük bir gecikme cezası. Böylece ucuz tek bir çağrı, sık başarısız oluyorsa veya yeniden işleme tetikliyorsa otomatik olarak en ucuz çözüm değildir.

Açık bir model önerisi yalnızca mevcutsa, politikayla izinliyse ve bağlam için yeterince büyükse kabul edilir. CEO katmanının planlama, delegasyon ve bağlam anlama işlemleri ise özel olarak bu üç yetenek için seçilmiş güçlü bir model kullanır.

5. Çalışan Görevi Küçük, Doğrulanabilir Adımlarda İşler

Bir çalışan tek bir yanıtla çalışmaz. Sınırlı bir ReAct döngüsünden geçer:

1. Model yapılandırılmış eylemler önerir – örneğin dosya okuma, arama, test çalıştırma veya değişiklik yazma.
2. Yürütücü izin, yol, komut riski ve aktif politikayı kontrol eder.
3. Argo yalnızca izinli eylemleri yürütür.
4. Sonuçlar, diff'ler ve hata mesajları gözlem olarak modele geri akar.
5. Buna dayanarak çalışan bir sonraki adımını düzeltir veya görevi tamamlar.

Böylece bir aracı örneğin önce ilgili kodu okuyabilir, sonra değişiklik yapabilir, test çalıştırıp bir test sonucunu sonraki karara dahil edebilir. Tüm akış çalıştırma günlüğünde görünür kalır.

Çıktının kendisi de denetlenir. Bir model geçersiz eylem JSON'u verirse, Argo sınırlı bir onarım döngüsü talep edebilir. Katı modda kalıcı hatalı çıktı, belirsiz metni eylem olarak yorumlamak yerine kontrollü şekilde reddedilir.

6. Hatalarda: Kör Tekrar Yerine Hedefli Düzeltme

Her başarısız görev tüm çalıştırmanın başarısız olduğu anlamına gelmez. Orkestrasyon Motoru hata nedenlerini ayırır ve kontrollü tepki verir:

• Geçici bir hata sabit sınırlar içinde yeniden denenebilir.
• Katı bir doğrulama bulgusu somut itirazını sonraki denemeye görev olarak verir.
• Etkin basamaklandırmada sonraki deneme öncekinin bulgularını alır, sıfırdan başlamaz.
• Başarısız denemeden sonra Argo daha güçlü bir modeli tercih edebilir.
• Bütçe tükendiyse pahalı kör deneme başlatılmaz: Düğüm belgeli kısmi sonuçla biter veya görünür şekilde yükseltilir.

Düğüm stratejası sonunda bir görevin atlanıp atlanamayacağına, kontrollü şekilde başarısız olup olmayacağına veya kullanıcı kararı gerektirip gerektirmediğine karar verir. Bağımlı görevler yalnızca onaylı kısmi sonuçlar alır. Böylece yerel bir hata, planın geri kalanına sessizce yayılan sessiz bir hataya dönüşmez.

7. Uygulamadan Sonra: İnceleme, Doğrulama ve Olası Başka Bir Döngü

Planlanan görevler işlendikten sonra Argo entegre durumu birden fazla açıdan inceler:

• QA-Aracısı dosya okuyabilir ve test komutları çalıştırabilir.
• Mimari-Aracı yapıyı okuyarak denetler ve bilinçli olarak yazma izni olmadan kalır.
• Deterministik doğrulayıcılar test, tip kontrolü veya linting'i nesnel oracle olarak çalıştırabilir.
• Model tabanlı ve deterministik bulgular bir genel yargıda birleştirilir.

QA, mimari veya bağlayıcı bir doğrulayıcı sorun bulursa, Argo bulguları ilgili görevlere atar. Yalnızca bu görevler somut geri bildirimle yeniden işlenir. Ardından tekrar inceleme ve doğrulama gelir. Uzlaşı modu olmadan bu döngü sınırlıdır; açıkça seçilen bir uzlaşı modunda kullanıcı durduraya veya denetçiler onaylayana kadar sürer.

Gözlem modundaki bir doğrulayıcı bulguları belgeler ama engellemez. Bağlayıcı modda katı bir bulgu sonucun başarılı sayılmasını engelleyebilir. Böylece katılık işletme profiline göre seçilebilir, anlaşılabilirlik bırakılmaz.

8. Durum Denetlendikten Sonra: Dokümantasyon ve CEO Özeti

Tamamlanmış bir çalışma ve denetim döngüsünden sonra bir dokümantasyon aracısı değişiklikleri kaydedebilir. Ardından CEO katmanı kullanıcı için özeti oluşturur: Ne yapıldı? Ne açık kaldı? Hangi denetimler çalıştı? Hangi dosyalar veya kararlar etkilendi?

Sonuç bir sohbet metninden fazlasıdır. Çalıştırma, plan, model seçimi, maliyet, eylemler, doğrulama yargıları, kullanıcı kesintileri ve sonraki yama kararları için ortak bir kimlik taşır. Böylece Argo'nun bir sonuca nasıl ulaştığı izlenebilir.

9. Sonunda Gerçek Workspace'e Karar Veren İnsandır

Varsayılan olarak Argo izole bir worktree'de çalışır. Değişiklikler orada yama olarak durur, sessizce gerçek projede değil. Özerklik seviyesine göre üç şeyden biri olur:

• Yama kabul, kısmi alma, düzenleme veya reddetmeye hazır kalır.
• Başarılı bir yama otomatik alınır.
• Ara sıra değişen dosyalarla çakışmada Argo görünür şekilde durur; yabancı değişikliklerin üzerine yazmaz.

Başarısız bir çalıştırma otomatik uygulanmaz. Çok özerk bir yapılandırma bile politikayı kaldırmaz: gizli koruma, komut kuralları, sağlayıcı sınırları, bütçe limitleri ve gerekli insan kapıları geçerlidir.

Orkestrasyon Motoru Neler Yapar

Orkestrasyon Motoru yalnızca sıradaki modelin ne yanıt vereceğine karar vermez. Kullanıcı niyetini, ayarları, planlamayı, paralelleştirmeyi, model seçimini, araç kullanımını, hata düzeltmeyi, kalite güvencesini ve güvenli devralmayı birbirine bağlı bir akışta birleştirir.

Ölçüt “mümkün olduğunca çok aracı” değildir. Ek iş yalnızca gerekçelendirildiği yerde oluşur: zor bir mimari karar için daha güçlü model, belirsizlikte ikinci düşünme yaklaşımı, doğrulayıcı itirazından sonra hedefli retry veya riskli etki öncesi insan onayı.

Yön böylece belirlenmiştir.