Meta’nın Muse Wonder lansman yazısı, Active Focus adını verdiği bir davranışı tarif ediyor: Model, zorlu bir hedefe doğru çalışmayı sürdürüyor, alternatif yaklaşımlar deniyor, engelleri aşıyor ve Meta’nın ifadesiyle, gerektiğinde açıklama talep edip önemli eylemlerden önce onay alıyor (check-in yapıyor). Meta ayrıca kritik sonuçlar doğurabilecek eylemlerden önce insan onayı alınmasını öneriyor; nitekim coding-agents kılavuzu da Muse Code’u ilk andan itibaren onay mekanizmaları ve bir korumalı alan (sandbox) devrede olacak şekilde sunuyor.
Bu oldukça doğru bir tasarım. Ancak aynı zamanda paralel ajanlar çalıştıran her ekibin zaten yakından bildiği bir soruyu da gündeme getiriyor: Model durup soru sorduğunda, orada yanıt verecek kim var, ne kadar sürede ve hangi bağlamla yanıt verebilecek? Kimsenin izlemediği bir terminale düşen bir onay talebi, duraklayıp kalmış bir çalıştırma demektir. Paylaşılan bir Inbox'a, ait olduğu Task'e bağlı olarak düşen bir onay talebi ise bir inceleme adımıdır. Bu yazı, işte bu ikinci yaklaşımı nasıl kuracağınızı anlatıyor.
Active Focus neler ortaya koyuyor?
Meta modeli üç temel davranış için eğitti ve bunları FocusBench adını verdiği dahili bir kıyaslama testiyle ölçüyor. Bu testte Muse Wonder Full %54,2 ile başı çekerken, API üzerinden erişilebilen Wonder %44,9 ile GPT-6 Astra ve Claude Opus 5.5'in gerisinde kalıyor. Skorları bir kenara bırakırsak, bir pano (board) için asıl önemli olan sergilenen davranışlardır:
- Sebat (Persistence). Model, karşılaştığı başarısızlıklara rağmen devam eder. Uzun soluklu kodlama kıyaslama testi SWE-Marathon'da Wonder, Opus 5.5'in 46,3 puanına karşılık 53,1 puan alıyor. Daha uzun çalıştırmalar, daha fazla deneme ve incelenecek daha çok ayrıntı.
- Netleştirme (Clarification). Model, Task belirsiz olduğunda tahmin yürütmek yerine soru sorar. Bir panoda bu, Task üzerine düşen bir yorumdur; bir terminalde ise bir tuşa basılmasını bekleyen bir komut istemidir.
- Onay Talepleri (Check-ins). Model, kritik olduğunu değerlendirdiği bir eylemden önce duraklayıp onay ister. Meta’nın kendi tavsiyesi de önemli sonuçlar doğurabilecek her eylem için bunun insan onayına bağlanması yönündedir.
Bu davranışların her biri inceleme kuyruğunun yapısını değiştirir. Sebat, Task başına düşen iş yükünü artırır. Netleştirme, araya giren kesintileri çoğaltır. Onay talepleri ise biri karar verene kadar çalıştırmayı askıya alan kararlar ekler.
Onay talebinin nereye ulaştığı neden önemli?
Muse Code'da, abonenin terminalinde bir onay istemi belirir ve çalıştırma beklemeye başlar. Başsız (headless) çalıştırmalarda (muse exec) etkileşimli bir istem bulunmadığından Meta'nın dokümantasyonu, ya gözetimsiz tamamlanabilecek bir politika seçilmesini ya da bekletilen eylemlerin çözümsüz kalmasının göze alınmasını tavsiye eder. Ortadaki dürüst denge şudur: Ya klavyenin başında biri oturacak ya model onay mekanizmaları devre dışı bırakılarak çalıştırılacak ya da eylem sonsuza dek bekleyecek.
Bir Sharkly panosunda ise çalıştırma, bir Computer üzerindeki Agent'a atanmış bir Task'tir. Agent durup bir şey sorduğunda, soru Task'e bir yorum olarak eklenir ve Inbox'a yönlendirilir. Task tüm bağlamı barındırır: ne sorulduğu, Agent'ın şimdiye kadar neler yaptığı, araç çağrılarının ve Runtime olaylarının çalıştırma günlüğü. Görevi devralan kişi yanıtı doğrudan Task üzerinden verir ve böylece çalıştırma kaldığı yerden devam edecek zemini bulur. Onay talebi nihayetinde yine bir insan kararıdır; ancak artık kaydı tutulan, bir kuyruğa giren ve birden fazla kişinin müdahale edebileceği bir insan kararıdır.
Bir güvenlik önlemi (safeguard) ile tıkanıklık (stall) arasındaki fark işte budur. Modelin sergilediği davranış tamamen aynıdır. Ancak etrafındaki sistem, bir onay talebinin bir dakikaya mı yoksa bir güne mi mal olacağını belirler.
Onay taleplerini verimli kılacak Agent talimatları yazmak
Bir onay talebinin değeri, sorulan sorunun kalitesi kadardır. İyi bir sorunun kriterlerini doğrudan Agent'ın talimatlarına yazın:
Stop and ask before anything destructive, anything that sends data outside the
attached repositories, any payment or external account action, and any change
to CI, deploy or access configuration.
When you ask, state in one comment: what you are about to do, why the Task needs
it, what you considered instead, and what happens if the answer is no.
Do not ask about reversible edits inside the repository. Make them, test them,
and report.
If you have waited for an answer and the Task has a deadline, say so in a second
comment rather than proceeding.
İlk kural sınırı çizer. Meta’nın modeli neyin önemli olduğuna kendisi karar verir; talimat ise ekibin neleri önemli gördüğünü modele bildirir. İkinci kural, süreci baştan sona izlememiş birinin bile bu yoruma otuz saniye içinde yanıt verebilmesini sağlar. Üçüncü kural ise modelin her şey hakkında soru sormasının önüne geçer; zira dikkatli bir ajanı çekilmez hale getiren hata tam olarak budur. Opus 5.5 için guardrails yazısı da aynı sınırı prompt enjeksiyonu penceresinden ele alıyor: Model ne vadederse etsin, asıl kontrol mekanizması inceleme aşamasıdır.
Kuyruk kapasitesini planlamak
Sebat, Task başına daha az değil, daha fazla inceleme anlamına gelir. Planınızı buna göre yapın.
| Kulvar | Tipik çalıştırma | Kuyruğa ulaşanlar |
|---|---|---|
| Uzun bir Task üzerinde Muse Wonder | Çok sayıda adım, geri alınan birkaç yaklaşım | Daha uzun bir diff, daha uzun bir log, sıfır ila üç onay talebi |
| Aynı Task üzerinde Opus 5.5 | Daha az adım, daha kararlı ilerleyiş | Daha kısa bir diff veya yarıda bırakılmış bir Task |
| Gece gözetimsiz çalışan herhangi bir model | Politikanın izin verdiği ölçüde | Ya bekletilen eylemler ya da kimsenin onaylamadığı işlemler |
Üç pratik yöntem kuyruğun akıcı kalmasını sağlar. Onay taleplerini herkese açmak yerine kulvar başına belirlenmiş bir incelemeciye iletin; böylece bir soru bir grubun inisiyatifine kalıp beklemez. Agent'ın Task başına zaman aşımını (timeout) ayarlayın; böylece bir onay talebinde takılan çalıştırma, saatlerce çalışır durumda görünmek yerine görünür biçimde zaman aşımına uğrasın. Ayrıca Wonder çalıştırmalarında sadece diff'e değil, log kayıtlarına da bakın: Başarısız olmuş üç yaklaşımdan geçen rota, sebatkar bir modelin sürece kattığı kısımdır ve sinsi hatalar tam da burada gizlenir. Coding agents while you’re away yazısı gece çalıştırmaları senaryosunu ele alırken, human review is the bottleneck yazısı ise daha gelişmiş bir modelle bu sürecin neden ucuzlamadığını irdeliyor.
Panoda iyi bir onay talebi nasıl görünür?
Yukarıdaki talimatların ortaya çıkardığı ve bir incelemecinin telefonundan dahi kolayca aksiyon alabileceği Task yorumunun örneği şöyledir:
Check-in before action.
About to: drop the legacy `orders_v1` table in the migration.
Why: the Task says remove v1 read paths; the table is the last reference.
Considered: keeping the table and removing only the code. Rejected because
the nightly job still writes to it and would fail silently.
If no: I will leave the table, remove the code paths, and note the job in
the report for a follow-up Task.
Dört satır, tek bir karar ve her iki ihtimal de önceden planlanmış. İncelemeci Task üzerine "evet" veya "hayır, kalsın" yazar, çalıştırma kaldığı yerden devam eder ve log kimin karar verdiğini kayıt altına alır. Bunu, önceki kırk adımı görmemiş birine Allow? [y/N] uyarısı veren bir terminal istemiyle karşılaştırın.
Kulvar bir hafta çalıştıktan sonra uygulanabilecek iki ince ayar bulunur: Bir incelemeci onay taleplerinin çoğunu tek başına karşılıyorsa, o kulvarın Agent'ına adı belirlenmiş ikinci bir incelemeci atayın; böylece öğleden sonraki bir toplantı tüm uzun süreli çalıştırmaları kilitlemez. Eğer Agent sürekli olarak aynı türdeki eylemler hakkında onay istiyorsa, o eylem türü kuyruğu meşgul etmek yerine talimatlar içinde peşinen verilmiş bir "evet" ya da "hayır" kuralı olarak tanımlanmalıdır.
Bilgisayar kullanımı (Computer-use) senaryosu
Meta, Wonder'ın yetenekleri arasında bilgisayar kullanımını (computer use) da sayıyor: tarayıcıları, masaüstü ortamlarını ve mobil uygulamaları yönetmek. Onay taleplerinin en kritik olduğu ve terminal isteminin en yetersiz kaldığı alan tam da burasıdır; çünkü yapılacak işlem, incelemecinin o an göremediği bir ekrandaki tıklamadır. Astra computer-use yazısındaki kuralların aynısı burada da geçerlidir: Agent ekibin belirlediği bir Computer üzerinde çalışır, onay talebi ekranı ve eylemi açıkça belirtir ve işlemi onaylayan kişi "evet" demeden önce Task'in günlüğünü inceleyebilir. Submit düğmesine basmak için izin isteyen bir model, ancak biri Submit'in arka planda ne yapacağını görebiliyorsa güvenlidir.
Bu yaklaşım ne değildir?
Active Focus bir model davranışıdır ve model davranışları kesin bir garanti teşkil etmez. Meta’nın kendi model kartı bile modellerin alışılmadık çok adımlı görevlerde yanılabileceğini belirtiyor ve kapsamlı güvenlik raporu henüz beklemede. Onay talebi mekanizması, iyi kurulmuş bir inceleme sistemini daha da güçlendiren bir özelliktir; onun yerini tutmaz. "Önemli eylemlerden önce onay ister" ifadesini gözetimsiz çalıştırma yetkisi olarak okuyan bir ekip yanılgıya düşmüştür. Her onay talebine bir Task, bir incelemeci ve bir zaman aşımı tanımlayan bir ekip ise bu özelliğin asıl tasarlanma amacını hayata geçirmiştir.
Bunların hiçbiri Sharkly faturasına ek bir yük getirmez. Model kullanımı, Computer üzerinde yapılandırılan Meta anahtarı üzerinden yürütülür. Model 12 Ekim'de güncellendi. Bağlam, ilerleme, engeller, sonuçlar ve insan incelemesi talepten canlıya alma aşamasına kadar görünür kalmaya devam etti. Bu yapıyı worktree'ler ile manuel olarak kurgulayabilir ya da iş akışını yönetmek için Sharkly'den yararlanabilirsiniz.
