Çoğu çoklu ajan (multi-agent) iş akışı işin zor kısmında takılmaz. Ajan kodu yazar, testleri çalıştırır, pull request'i açar. Asıl aksaklık dikiş yerlerinde yaşanır: İşin bir ajandan çıkıp başka bir yere ulaşması gereken o anda. Bir backend Ajanı bir endpoint'i tamamlar ama frontend Ajanının bunun hazır olduğundan asla haberi olmaz. Bir refactoring işlemi bir worktree'ye aktarılır ve testler yeşil yandığı hâlde öylece bekler; çünkü hiçbir insana gidip bakması söylenmemiştir. Görev bozulmamıştır; kopan şey görev devridir (handoff).
Yapay zekâ ajan devri (handoff); bir iş parçasının sahip olduğu tüm bağlamla birlikte bir çalışandan diğerine, yani ajandan ajana veya ajandan insana aktarılmasıdır. Tek bir terminalde tek bir kodlama ajanı çalıştırdığınızda devir teslimler görünmezdir, çünkü ortada devredilecek bir süreç yoktur. Ancak iki ajan ya da bir ajan ile bir denetçi çalıştırdığınız anda, tamamlanan her adımın bir sonraki çalışanın bulabileceği bir noktaya ulaşması gerekir. Bütün mesele işte bu varış noktasını doğru kurmaktır.
Bu makale, kodlama ajanlarınızın üzerinde konumlanarak bağlamı, ilerlemeyi, engelleri, sonuçları ve insan denetimini talepten yayına kadar görünür kılan iş akışı katmanı Sharkly üzerinden pratikte gerçekten işe yarayan görev devri modellerini ele alıyor. Kodlama ajanlarına zaten sahipsiniz; bu yazının çözdüğü sorun ise ajanların arasındaki boşluklarda neler yaşandığıdır.
Özetle
Görev devri, bir işin ve bağlamının bir çalışandan diğerine aktarıldığı yerdir. Ajandan ajana devirlerde tamamlanan bir alt görev sıradaki ajana iletilir; ajandan insana devirlerde ise otonom çalışma bir inceleme aşamasında durdurulur. Her iki süreci de durumlarla (status) açık hâle getirin: Ajanlar bir Görevi Ready for review durumuna taşır, İnsanlar ise Done durumuna getirir. Görev devri, terminaldeki bir mesaj yerine paylaşılan bir Görev üzerindeki durum değişikliği olduğunda hiçbir şey sessizce gözden kaçmaz.
Ajan devri tam olarak nedir?
Bir görev devrinin üç bileşeni vardır ve bunlardan herhangi birinin atlanması işlerin kaybolmasına yol açar: Çıktı (diff, PR, veritabanı migrasyonu), bağlam (ne istendi, ne değişti, hâlâ nelerin belirsiz olduğu) ve alıcı (bir sonraki adımın sahibi olan belirli ajan veya kişi).
Terminal tabanlı iş akışları yalnızca çıktıyı taşır, diğer iki bileşeni ise kaybeder. Commit mevcuttur ancak bunun ardındaki mantık yalnızca tek bir ajanın gördüğü terminal geçmişinde kalır; "sıradakinin kim olduğu" ise tamamen tesadüfen kontrol eden kişiye bağlıdır. İşte bu yüzden ajan orkestrasyonu, onları çalıştırmaktan çok ürettikleri çıktıları doğru yönlendirmekle ilgilidir.
Sorunsuz bir devir teslim bu üç unsuru bir arada taşır: yapılan değişiklik, neyin yapılıp neyin yapılmadığına dair özet ve sıranın alıcıda olduğunu belirten net bir sinyal. Sharkly terminolojisiyle ifade edersek; yürütme, engeller, sonuçlar ve takip eden tartışmalar doğrudan Görev zaman çizelgesine işlenir; böylece sıradaki çalışan üç farklı parçayı birleştirmeye çalışmak yerine tek bir kaydı inceler.
İki temel görev devri modeli
Bu iki model birbirine benzer görünse de varsayılan yaklaşımları tamamen zıttır. Ajandan ajana devir otomatik olarak akmalıdır: Sıradaki Ajan hazır olan alt görevi üstlenir ve devam eder. Ajandan insana devir ise varsayılan olarak durmalıdır: Ajan kendi payına düşen kısmı bitirir ve bekler, çünkü kararı bir insanın vermesi gerekir.
| Ajandan ajana | Ajandan insana | |
|---|---|---|
| Tetikleyici | Bir alt görev hazır olarak işaretlendiğinde | İş bir inceleme aşamasına ulaştığında |
| Varsayılan | Otomatik olarak devam et | Dur ve bekle |
| Taşınanlar | Çıktı + bağlam + kabul kriterleri | Diff + değişiklik özeti + bilinen sınırlar |
| Eksik olursa risk | Mükerrer veya çelişkili çalışma | İncelenmemiş kodun doğrudan merge edilmesi |
İşte doğru kararı vermenizi sağlayacak karşılaştırma: Sıradaki adım net bir şekilde tanımlanmış ve kabul kriterleri önceden yazılmışsa ajandan ajana devri otomatikleştirin: "test paketini çalıştır", "migrasyonu oluştur", "OpenAPI belirtimini güncelle". Sıradaki adım ajanın üstlenemeyeceği bir muhakeme gerektirdiğinde ise mutlaka ajandan insana devri zorunlu kılın: main dalına merge etmek, genel bir sözleşmeyi (public contract) değiştirmek, kimlik doğrulama veya faturalandırmaya dokunmak ya da bir sonucu tamamlanmış olarak onaylamak gibi.
Yapılan hata, her devir teslim sürecine aynı şekilde yaklaşmaktır. Her şeyi otomatik akışa bırakırsanız denetlenmemiş kodları merge edersiniz; her adıma onay kapısı koyarsanız da fazladan adımlarla yavaş bir manuel süreç kurmuş olursunuz. Bu durum, ajanların her önemsiz detayda değil, maliyetli hatalar gerçekleşmeden önce durması için onay kapılarının nereye konumlandırılacağını bilmekle doğrudan bağlantılıdır.
Durumlar devir teslimi bir temenni değil, bir denetim kapısı yapar
Çalışma modeli temelde dört eyleme ve bunların kime ait olduğuna dayanır: kim atar, kim çalıştırır, kim inceler, kim onaylar. Ajanlar araştırır, yürütür, test eder ve raporlar. İnsanlar yön belirler, yetki verir ve sonucu onaylar. Otomasyon, ekibin muhakemesinin gerektiği noktada durur.
Durumlar (status), bu sözleşmenin sadece bir niyet olarak kalmayıp mekanik bir işleyişe dönüşmesini sağlar. Her Görev aynı aşamalardan geçer:
- Todo: Atandı, henüz başlanmadı. Bir insan veya lider bir Ajan görevi buraya eklemiştir.
- In progress: Bir Ajan görevi üstlendi ve izole bir worktree içinde çalışıyor.
- Ready for review: Ajanın sınır çizgisi. Tip kontrolünü (typecheck), testleri ve derlemeyi çalıştırdı; değişiklik özetini ve bilinen sınırları ekledi ve durdu.
- Done: İnsanın sınır çizgisi. Birisi sonucu onayladı; merge ve yayınlama kararını verdi.
Tüm süreci anlaşılır kılan kural şudur: Ajanlar bir Görevi Ready for review durumuna taşır; İnsanlar ise Done durumuna getirir. Bir Ajan kendi işini asla Done olarak işaretlemez ve bir insan da testleri yeşil olan bir Görevin güvenli olup olmadığını tahmin etmek zorunda kalmaz. Durumun kendisi, görev devridir. On ajan çalışırken on ayrı terminali taramazsınız; panoya bakar ve neyin sizi beklediğini, neyin başka bir ajanı beklediğini ve neyin hâlâ yürütüldüğünü açıkça görürsünüz. Bu görünürlük, ajanların neleri tamamladığını takip etmek ile daha sonra commit geçmişinin her şeyi anlatacağını ummak arasındaki farktır.
Uygulamalı bir örnek: Talep kaydından merge edilmiş PR'a
Gerçek hayattan bir Görevi ele alalım, SH-312: "Genel API'ye rate limiting ekle." Şimdi koda değil, görev devirlerine odaklanın.
Bir insan ihtiyacı doğal dille açıklar ve görevi atar. Lider bir Ajan kod tabanını ve geçmiş görevleri araştırır, kapsamı ve kabul kriterlerini yazar (API anahtarı başına sınır, Retry-After başlığıyla 429 döndürme, en yoğun üç endpoint'i kapsama) ve SH-312'yi yürütülebilir üç alt göreve böler. İşte ilk ajandan ajana devir: girdi olarak hedef, çıktı olarak hazır alt görevler.
Alt görevler otomatik olarak ilerler. Bir backend Ajanı hız sınırlayıcı mantığını üstlenir; bir test Ajanı ise test kapsamını ele alır. Her biri izole bir worktree içinde çalıştığından aynı dosyalarda çakışma yaşamazlar ve her sonuç özel bir oturum yerine doğrudan SH-312'ye aktarılır. Backend Ajanı işini bitirdiğinde bir insana bildirim göndermez; kendi alt görevini hazır olarak işaretler ve test Ajanı bir taslak yerine gerçek uygulamayı devralır.
Ardından devir teslim türü yön değiştirir. Hız sınırlayıcı yazılmış, tip kontrolü hatasız tamamlanmış, testler geçmiş ve derleme başarıyla sonuçlanmışken, iş artık ajandan insana denetim kapısına ulaşır. Ajan, SH-312'yi Ready for review durumuna taşır ve diff'i, değişiklik özetini ve bilinen bir kısıtlamayı ekler: "Redis tabanlı sayaç tek bir bölge varsayar; çoklu bölge desteği için ayrı bir takip görevi gerekir." Bir insan tüm bunları tek bir yerden okur, 429 davranışını kontrol eder ve görevi Done durumuna getirerek merge işlemini tetikler. Talep kaydından merge edilmiş PR'a kadar, her bağlantı noktasında kimin ne yaptığının kaydı tutulur. Bu, uçtan uca gereksinimden koda izlenebilir hâle getirilmiş akışın ta kendisidir.
Görev devirleri nerede aksar ve nasıl sağlam tutulur?
Görev devirleri öngörülebilir üç şekilde aksar ve her birinin "hatırlamaya çalışmak" yerine yapısal bir çözümü vardır.
Bağlam kaybolur. Ajan belirli bir tercihi neden yaptığını bilir; denetleyen kişi ise bilmez. Çözüm: Görev devrinin, sonradan akla gelen bir detay olarak değil, Ready for review durumuna geçişin doğrudan bir parçası olarak değişiklik özetini ve bilinen sınırları taşımasıdır. Sahiplik belirsizleşir. İki ajan aynı işe yönelir ya da hiçbiri ilgilenmez. Çözüm: Her Görev ve alt görevde bir Atanan (Assignee) bulunmasıdır; böylece "sıra sende" durumu belirsiz bir his değil, somut bir veri alanı hâline gelir. İnceleme asla gerçekleşmez. Kimseye durdurulması söylenmediği için otonom çalışma doğrudan merge edilir. Çözüm: Ajanın tek başına aşamayacağı bir durum sınırıdır.
Tüm bunları worktree'ler, bir adlandırma standardı ve kişisel disiplinle manuel olarak da kurabilirsiniz. Ancak ajan, görev ve repo sayısı arttıkça bu yöntem yetersiz kalır ve ilk kaybedilen şey disiplin olur. Hâlihazırda birden fazla ajan çalıştırıyorsanız Sharkly, bu ajanların görevlerini ve sonuçlarını yönetebileceğiniz tek bir merkez sunar: Paylaşılan Görevler, Görev başına Atananlar, izole worktree'ler ve Ajanların Ready for review durumuna ulaştığı, İnsanların ise Done kararı verdiği bir durum akışı. Mevcut kodlama ajanlarınızı kullanmaya devam edin; yalnızca aralarındaki görev devirlerini görünür kılan katmanı ekleyin. Ajanlarınız arasındaki bağlantı noktaları işin kendisinden daha maliyetli hâle gelmeye başladığında Sharkly'yi indirin.
Sıkça Sorulan Sorular
Yapay zekâ ajan devri (handoff) nedir? Bir görevin, sahip olduğu bağlam ve sıranın artık başkasına geçtiğini belirten sinyalle birlikte bir çalışandan diğerine aktarılmasıdır. İki biçimi vardır: Ajandan ajana (tamamlanan bir alt görev sıradaki ajana geçer) ve ajandan insana (otonom çalışma bir inceleme aşamasında durur).
Ajandan ajana devir ile ajandan insana devir arasındaki fark nedir? Ajandan ajana devirler, bir sonraki adımın kabul kriterleri önceden belirlenmişse otomatik olarak devam etmelidir. Ajandan insana devirler ise durup beklemelidir; çünkü bir insanın muhakeme yürütmesi gerekir: merge etmek, genel bir sözleşmeyi değiştirmek veya bir sonucu onaylamak gibi.
Ajanlar kendi işlerini tamamlandı (done) olarak işaretlemeli mi? Hayır. Bırakın Ajanlar testleri çalıştırıp özeti ekledikten sonra Görevi Ready for review durumuna taşısın; Done durumuna geçirme ve merge etme kararını ise bir insana bırakın. Bu iki sınırı birbirinden ayırmak, incelenmemiş kodların yayınlanmasını engeller. Ayrıntılar için döngüde insanın yer aldığı (human-in-the-loop) kodlama ajanları konusuna göz atabilirsiniz.
Durumlar işlerin gözden kaçmasını nasıl önler? Görev devri bir terminal mesajı yerine paylaşılan bir Görev üzerindeki durum değişikliği olduğunda, sıradaki çalışan kendisini neyin beklediğini açıkça görür. Hiçbir şey, birinin doğru anda doğru terminal geçmişini izlemesine bağlı kalmaz. Bir ajan Gelen Kutusu (Inbox), ilginizi gerektiren maddeleri doğrudan öne çıkarır.
Bunun için bir araca ihtiyacım var mı, yoksa manuel olarak yapabilir miyim? Bunu worktree'ler ve paylaşılan bir pano ile yürütebilirsiniz. Ancak birden fazla depoda birden fazla ajanı koordine ettiğinizde ve manuel takip bir darboğaza dönüştüğünde özel bir katman gerçek değerini gösterir. Karar vermek için asistan ile ekip arkadaşı zihinsel modelini karşılaştırabilirsiniz.
