Agent gözlemlenebilirliğinde hesap verebilirlik boşluğu
Çoğu agent platformu denetimi sonradan ele alınacak bir mesele olarak görür. Trace'ler olay gerçekleştikten sonra yayınlanır, bir time-series deposuna gönderilir ve dashboard olarak görüntülenir. Bu, performans izleme için yeterlidir ve hesap verebilirlik için işe yaramaz. Bir dashboard örnekler, toplar ve downsample eder. Bu saatte kaç tool call başarısız oldu gibi soruları yanıtlar. Bu olaydan önce hangi kesin sıralı kararlar dizisi vardı ve her birini kim yetkilendirdi sorusunu yanıtlayamaz.
Yakın tarihli iki olay bu başarısızlık modunu gözler önüne seriyor. Avustralya Medicare olayı ve bildirilen Gemini bağlantılı ihlaller, her ikisi de kısmi telemetriden — dağınık uygulama logları, sağlayıcı tarafı kayıtlar ve elle birleştirilmesi gereken inference trace'leri — sonradan yeniden inşa edildi. Hiçbir durumda sistemin kendisi, agent'ın ne yapmayı amaçladığına ve ne yapmaya yetkili olduğuna dair eksiksiz, sıralı ve kurcalandığı kanıtlanabilir bir kayıt tutmuyordu. Yeniden inşa, adli arkeolojiydi ve vardığı sonuçlar ancak dolduramadığı boşluklar kadar güvenilirdi.
Daha derin sorun yapısaldır. Tanımladığı sürecin kendisi tarafından düzenlenebilen bir denetim kaydı kanıt değildir. Agent çalışma zamanı kendi logu üzerinde yazma yetkisini elinde tutuyorsa, o çalışma zamanındaki herhangi bir ihlal — prompt injection, dependency confusion, kötü niyetli bir tool — kendisini suçlayacak girdileri bastırabilir, yeniden sıralayabilir veya yeniden yazabilir. Bu şekilde kurulan gözlemlenebilirlik hatları, hesap verebilirlik açısından, öz bildirimdir. Hata ayıklama için faydalıdır ve bir anlaşmazlıkta değersizdir.
Agent çalıştırmaları için write-ahead semantiği
Write-ahead logging'in depolama motorlarında bu soruna yerleşik bir yanıtı vardır: niyet, etki uygulanmadan önce kalıcı olarak kaydedilir. Aynı disiplin agent'lar için de geçerlidir ve logu bir çıktıdan bir ön koşula dönüştürür.
Uyumlu bir agent çalıştırması, herhangi bir yan etki tetiklenmeden önce sırasıyla şunları ekler:
- Amaçlanan eylem — tool adı, kanonikleştirilmiş argümanlar, hedef kaynak.
- Yetkilendiren politika kararı — hangi kuralın eşleştiği, çalıştırmayı hangi principal'ın başlattığı, hangi kısıtların uygulandığı.
- Çözümlenen kimlik bilgisi — tool'un hangi kimlik olarak hareket edeceği ve o kimliğin kapsamı.

Tool call ancak ekleme onaylandıktan sonra yürütülür. Dolayısıyla log bir çalışma zamanı bağımlılığıdır: log yazıcısı kullanılamıyorsa eylem ilerlemez. Dürüst ödünleşim budur. Write-ahead denetimi benimseyen ekipler, bir log kesintisinin bir yetenek kesintisi haline geldiğini kabul eder. Alternatif — asla bloklamayan best-effort logging — tam da yukarıdaki yeniden inşaları üreten rejimdir.
Log aynı zamanda kurtarma noktası haline gelir. Çökme, kill veya timeout durumunda, kaydedilen trajectory'nin replay'i bir eylemin yeniden denenip denenmeyeceğine, geri alınıp alınmayacağına veya karantinaya alınıp alınmayacağına karar verir. Niyet yürütmeden önce kaydedildiği için, kurtarma süreci hiç başlamadı ile başladı ve sonucu bilinmiyor arasında ayrım yapabilir; bu, idempotency ve telafi mantığı için önemli olan ayrımdır. Bu olmadan, yeniden denemeler yan etkileri çoğaltır ve geri almalar onları kaçırır.
Son olarak, yazıcı agent sürecinden ayrılmalıdır. Yaygın bir desen, farklı bir kimlik altında çalışan, kimliği doğrulanmış bir kanal üzerinden eklemeleri kabul eden ve tek yazma kimlik bilgisini elinde tutan bir log servisidir. Agent süreci, kendi run tanımlayıcısıyla sınırlı, yalnızca ekleme yapabilen bir yetenek tutar; silemez, değiştiremez veya çalıştırmalar arasında okuyamaz. İhlal edilmiş bir agent o zaman harekete geçmeyi reddedebilir, ancak zaten beyan ettiğini silemez.
Kaydın içermesi gerekenler
Tek bir ekleme girdisi için minimal şema:
{
"seq": 41822,
"run_id": "run_7f3a...",
"parent_step": 41819,
"ts_monotonic": 918273645,
"kind": "tool.intent",
"tool": "http.fetch",
"args_hash": "sha256:9c1f...",
"policy_rule": "net.egress.allowlist.v4",
"credential": "svc-fetch-readonly@proj-9",
"context_refs": ["doc_31a", "doc_88b"]
}
Birkaç alan orantısız ağırlık taşır.
Argümanlar değil, argüman hash'i. Hash'leme, sırları logun dışında tutarken girdiyi yine de tam girdiye bağlar. Argümanların replay için kurtarılabilir olması gerektiğinde, bunları aynı hash il
saklayın.

Parent step. Agent çalıştırmaları çizgiler değil, ağaçlardır. Her eylemi talep eden parent step'i kaydetmek, bir subagent'ın davranışını onu doğuran delegasyona atfetmeyi mümkün kılan şeydir. Parentage olmadan, bir swarm'ın eylemleri ayrıştırılamayan bir akışa dönüşür.
Alınan bağlam için provenance. Bağlam penceresine giren her belge, snippet veya tool sonucu tanımlayıcı ve içerik hash'i ile referans verilmelidir. Bu, zehirlenmiş bir belgenin onu tüketen her çalıştırmaya ileriye doğru ve onu kabul eden ingestion yoluna geriye doğru izlenmesini sağlayan şeydir. Provenance olmadan retrieval, bir injection olayını sınırsız bir soruşturmaya dönüştürür.
Deterministik saatleme ve monotonik sıra numaraları. Worker başına duvar saati zaman damgaları, dağıtık bir orchestrator genelinde sıralanamaz; saat kayması ve eşzamanlı worker'lar nedensel olarak sıralı olan olayları yeniden sıralayacaktır. Orchestrator tarafından atanan tek bir monotonik sıra, insan okuması için ikincil alan olarak duvar saati zamanıyla birlikte, replay'den sağ çıkan bir toplam sıra verir.
Operasyonel sonuçlar
Write amplification ve retention bütçe kalemleri haline gelir. Her tool call artık en az bir kalıcı ekleme, çoğu zaman birkaç tane (niyet, politika kararı, kimlik bilgisi çözümlemesi, sonuç) maliyetindedir. Yüksek frekanslı agent'larda bu, depolama ve I/O bütçesinin anlamlı bir kısmıdır ve bir gözlemlenebilirlik ödeneğinin içinde değil, inference maliyetinin yanında durur. Retention politikası bir tasarım kararı haline gelir: tam trajectory'nin ne kadar süre saklanacağı, neyin hash'lere indirgeneceği, neyin soğuk depolamaya aktarılacağı. İndirgeme zinciri asla kırmamalıdır — bir hash ancak preimage'i onu güvenilir tutan bir politika altında kurtarılabilirse faydalıdır.
İlk günden şema sürümleme. Olay incelemesi, kod değiştikten aylar sonra gerçekleşir. Log şeması sürümlenmemişse, soruşturma altındaki döneme ait girdiler mevcut araçlar tarafından okunamayabilir ve soruşturma format geçişinde tıkanır. Girdi şemasını açıkça sürümleyin, şimdiye kadar yayınlanan her sürüm için okuyucuları koruyun ve şema değişikliklerini bir API ile aynı titizlikle breaking change olarak ele alın.
Olay müdahalesi arkeolojiden replay'e kayar. Trajectory eksiksiz ve sıralı olduğunda, ne oldu sorusu kaydedilen çalıştırmayı kaydedilen kararlara karşı replay ederek yanıtlanır. İlginç iş politika neden buna izin verdi ve neyin değişmesi gerektiği noktasına kayar. Bu gerçek bir iyileşmedir ve aynı zamanda çıtayı yükseltir: agent'larını kesin olarak replay edebilen bir organizasyon artık olayları eksik görünürlüğe atfedemez.
Görüş
Agent'lar için denetim izleri bir write-ahead log problemidir. Log, yürütmeden önce eklenmeli, agent'ın etkileyemeyeceği bir süreç tarafından yazılmalı, orchestrator tarafından sıralanmalı ve henüz var olmayan okuyucular için sürümlenmelidir. Dashboard'lar operasyonlar için faydalı olmaya devam eder; kanıt değildirler. Bu ayrımı içselleştiren ekipler, agent'larının ne yaptığını kanıtlayabilecek. İçselleştirmeyenler ise hayatta kalan telemetriden yeniden inşa etmeye devam edecek.
