Bellek ve bilgi

Bellek ne işe yarar

Bellek olmadan her ajan konuşması sıfırdan başlar: aynı yerleşik kural yeniden anlatılır, aynı karar yeniden tartışılır, aynı çıkmaz sokak yeniden keşfedilir. Bellek, çalıştırmalar arasında varlığını sürdüren çalışma alanı kapsamlı depodur ve bir ajanın ürettiği bilginin daha sonra başka bir ajan tarafından bulunabilmesi için vardır.

Üç katmanı vardır ve bunlar farklı soruları yanıtlar:

1. Olgular — neyin doğru olduğu (yerleşik bir kural, bir sonuç, bir karar).
2. Politikalar — ajanların bu konuda ne yapması gerektiği (normatif bir kural).
3. Çalışma belleği — bir ajanın o anda neyin ortasında olduğu.

Bu ayrım önemlidir çünkü ajanın istemine farklı yollardan ulaşırlar. Olgular aranır. Politikalar itilir. Çalışma belleği gizlidir.

Olgular

Bir MemoryFact, bir çalışma alanına ve bir bilgi alanına kapsamlanmış bilgi birimidir.

Öznitelik	Nedir
domain	Bilgi alanı (“conventions”, “decisions”, “codebase”)
topic	Kısa bir konu etiketi
content	Bilgi metni
confidence	0.0–1.0, kökenden tohumlanır ve yeniden anılmayla yükselir
memoryType	Olgunun türü — zamansal bozunma eğrisini belirler
veracity	Nasıl öğrenildiği — güveni tohumlar ve her yeniden anılma artışının boyutunu belirler
sourceObservationIds	Hangi gözlemlerin ona yol açtığı
supersededBy	Varsa, onun yerine geçen daha yeni olgu
validUntil, recallCount, mentionCount	Geri çağırmada kullanılan son kullanma ve kullanım sinyalleri

Son iki satır insanların gözden kaçırdığı satırlardır ve hangi olgunun yüzeye çıkacağını belirleyen de onlardır. memoryType, tür başına Weibull bozunma parametreleri taşır; bu yüzden süreyle sınırlı bir taahhüt hızla solar, istikrarlı bir profil olgusu ise solmaz. veracity kökeni kaydeder — bir insan tarafından belirtilmiş (ağırlık 1.0), bir ajan tarafından çıkarılmış (0.7), bir araç tarafından üretilmiş (0.5), içe aktarılmış (0.6) — ve bu ağırlık olgunun başlangıç güvenini tohumlar.

Olgular çeliştiğinde asla yerinde düzenlenmez. Bir olgu yazmak, aynı bilgi alanındaki ve aynı konudaki olgulara karşı çakışma algılamasını çalıştırır ve kaybedenin yerine geçer, bir çakışma kaydı bırakır. Asıl mesele denetim izidir: daha önce neye inanıldığını ve yerine neyin geçtiğini her zaman görebilirsiniz.

Politikalar

Bir MemoryPolicy, olgulardan türetilen, bir çalışma alanına ve bilgi alanına kapsamlanmış, etkin bir bayrağı ve isteğe bağlı bir requiredRole alanı olan normatif bir kuraldır.

Çalışma alanındaki etkin her politika, filtrelenmeden her gönderime enjekte edilir — bilgi alanına, role, göreve veya alana göre filtreleme yapılmaz. Yirminci politikanızı yazmadan önce bunu bilmekte fayda var, çünkü politikalar görevle aynı bağlam penceresi için yarışır. Bir politikadaki requiredRole alanının uyarı niteliğinde olmasının nedeni de budur: kuralın kime yöneldiğini tanımlar, ancak kuralın diğer herkese ulaşmasını engellemez.

Bilgi alanları

Bir MemoryDomain, bir çalışma alanı içinde olguları ve politikaları gruplar. Bilgi alanları bilgiye kurumsal bir yapı kazandırır ve erişim yetkilerinin üzerine yazıldığı birimdir — ancak bir bilgi alanını gizlilik sınırı olarak ele almadan önce aşağıdaki uyarıya bakın.

Bir bilgi alanı ya çalışma alanı genelindedir (architecture) ya da tek bir depoya kapsamlanmıştır (repo:<slug>/architecture). İki kapsamdaki aynı ad iki bağımsız depodur: bir kod tabanı için doğru olan bir olgu, çalışma alanı genelindekinin üzerine yazmaz. search_memory ve gönderim önsözü, ajan o depoda çalışırken depo kapsamlı belleği öne alır; geri kalanı dışlamaz. Bu kapsamı yazmak veya güçlendirmek için propose_fact / propose_policy / search_memory üzerinde repo parametresini geçin.

Erişim denetimi okumalarda hata durumunda izin verir

MemoryAccessGrant, bir ajan rolünü ve bir bilgi alanını üç izin düzeyinden birine eşler:

İzin	Anlamı
none	Erişim yok
read	Olguları arayabilir ve getirebilir
write	propose_policy tarafından gerekli kılınır. Olgu yazmaları (propose_fact, supersede_fact) yetkiye bağlı değildir

Yetki kaydı yoksa okuma izni verilir, ret değil

Bir (role, domain) çifti için yetki satırı yoksa geçerli izin read olur. Okumalar tasarım gereği hata durumunda izin verir. Hata fırlatan tek yazma, write izni olmadan yapılan propose_policy işlemidir (InsufficientMemoryPermission). Hassas içeriği bir bilgi alanına koymak, görmemesi gereken her rol için açıkça bir none yetkisi yazmadığınız sürece onu kimin okuyabileceğini kısıtlamaz.

Ayrıca üründe bugün itibarıyla yetkiler için hiçbir arayüz yok. Bellek ekranında Olgular, Politikalar ve Bilgi grafiği sekmeleri vardır, başka bir şey yok; yetkilere yalnızca memory_access_grant.* RPC işlemleri üzerinden ulaşılır.

Bu asimetri — okumalarda yumuşak, politika yazmalarında katı — bilinçli bir tercihtir. Bellek, dolaşımda olduğunda en faydalıdır ve bir okuma reddi, sorun bildiren bir ajan yerine sessizce daha az bilen bir ajan üretir. Buna karşılık bir politika yazma reddi ses getirir ve düzeltilebilir; bu yüzden zorlama orada durur. Yeni oluşturulan bir bilgi alanı her rol için write iznini tohumlar; sonradan sıkılaştırmak RPC ile yapılan bir düzenlemedir, çünkü yetkiler için bir arayüz yok.

Çalışma belleği

Her ajanın bir AgentWorkingMemory alanı vardır: çalışma alanına ve ajana göre anahtarlanmış serbest metinli bir karalama defteri. Çalıştırmalar boyunca kalır, o ajana özeldir ve her gönderimde istemine enjekte edilir. “Kimlik doğrulamayı yeniden düzenlemenin yarısındaydım” bilgisinin yaşadığı yerdir — bir sonraki çalıştırmaya taşınmaya değer ama kalıcı bir olguya terfi ettirilmeye değmez durum.

Bir ajanın istemine gerçekte ne ulaşır

Gönderim sırasında bellek önsözü tam olarak üç şeyden oluşturulur:

• - [domain] rule satırları olarak çalışma alanındaki etkin her politika.
• Ajanın kendi çalışma belleği, birebir.
• Bu görev için anahtar sözcükle eşleşen kısa bir olgu listesi — en fazla beş olgu, yaklaşık 1.200 karakterlik bir bütçe içinde ve yalnızca görev açıklaması en az 20 karakter uzunluğundaysa. Daha kısa görevler hiç olgu almaz.

Kısa liste yalnızca FTS/anahtar sözcük tabanlıdır ve kasıtlı olarak sınırlandırılmıştır. Bir sorguyu gömmek yavaştır ve gönderim yolu, gecikmenin anında görünür olduğu tek yerdir; bu yüzden yavaş anlamsal yol oradan bilinçli olarak uzak tutulur. Önsöz, ajanın yük taşıyan öğeleri search_memory ile doğrulamasını söyleyerek kapanır; tam geri çağırma modelinin yaşadığı yer orasıdır.

Bu yolda hiçbir erişim yetkisine bakılmaz. Kısa listenin bulduğu şey, ajanın gördüğü şeydir.

Geri çağırma: tek sorgu, dört ses

Ajana sunulan search_memory aracının üç modu vardır ve bunlar gerçekten farklı aramalardır:

• keyword — yalnızca FTS5.
• semantic — BM25 ve vektör sonuçları karşılıklı sıra birleştirmesiyle kaynaştırılır.
• hybrid (varsayılan) — çok sesli geri çağırma: dört sıralı ses birleştirilir, ardından çeşitlendirilir.

Dört ses sözlüksel (FTS), anlamsal (vektör KNN), zamansal (yakın tarihli etkin olgular) ve grafiktir — en güçlü sözlüksel ve anlamsal tohumlardan başlayan iki adımlık bir gezinme. Epizodik kenarların var olmasının tek nedeni grafik sesidir: sözcüklerinizin hiçbiriyle eşleşmeden yanıtınıza bağlı olan olguyu yüzeye çıkarır. Sesler sınıflandırılmış bir sorgu niyetine göre ağırlıklandırılır (varsayılan olarak en fazla ağırlığı anlamsal taşır, sonra grafik ve sözlüksel, sonra yenilik), her adayın puanı Weibull bozunmasıyla ölçeklenir ve sonuç kümesi MMR ile çeşitlendirilir; böylece bir olgunun beş tekrarı dört farklı olgunun önünü kesmez.

Model kurulana kadar anlamsal geri çağırma sessizdir

Vektör sesi ancak cihaz üzerindeki gömme modeli indirildikten sonra katkıda bulunur. O zamana kadar karma geri çağırma üç sesle çalışır ve geriye dönük bir doldurma yoktur — model kurulmadan önce yazılan olgular hiçbir zaman vektör kazanmaz. SQLite vektör eklentisinin kendisi yüklenemezse vektör yolu daha da bozulur ve paketlenmiş gömmeler üzerinde Dart içi bir taramaya düşer; geri çağırma yine yanıt verir, yalnızca daha yavaş.

Masaüstü ve web bellek araması ayrı ve daha basit bir yoldur: memory_fact.search RPC işlemi yalnızca FTS5 kullanır, çünkü ince bir istemci sorgu gömmesi gönderemez ve karma yol ana makinede kalır. Dolayısıyla bellek tarayıcısında gördüğünüz sıralama, bir ajanın search_memory üzerinden aldığı sıralama değildir. Bu beklenen bir durumdur, hata değil; ancak arayüzdeki “aradım ve bulamadım” ifadesinin, ajanın da bulamayacağının kanıtı olmadığı anlamına gelir.

Bellek nerede durur ve onu kim yazar

Bellek tarayıcısı Ayarlar → Çalışma alanı → Bellek (/workspaces/<id>/settings/memory) yolundadır; Olgular, Politikalar ve Bilgi grafiği sekmelerine sahiptir.

Orada insanları şaşırtan bir asimetri vardır: belleği düzenleyebilir ve silebilirsiniz, ancak oluşturamazsınız. Ne Olgular sekmesinde ne de Politikalar sekmesinde ekleme imkânı vardır. Yazma işi ajan tarafındadır; propose_fact ve propose_policy ile yapılır (değiştirmek için supersede_fact / supersede_policy). remember, oturumla sınırlı bir sıcak katman öğesi yazar ve consolidate_memory bunu daha sonra bir olguya terfi ettirebilir; record_observation ve update_my_notes ise gönderimde enjekte edilen özel karalama defterini yazar. Tarayıcı bir inceleme ve düzeltme yüzeyidir, yazma yüzeyi değil — yani bellekte bir olgu istiyorsanız, onu oraya koymanın yolu bir ajana söylemektir.

İki bakım işlemi de zamanlanmış değil, ajan tarafından çağrılır: consolidate_memory birikmiş olguları birleştirir ve ayıklar, harmonize_memory ise ajanlar arasında ayrışan inançları uzlaştırır. list_memory_conflicts çakışma algılamasının şimdiye kadar kaydettiklerini gösterir. Bunları sizin için zamanlayıcıyla çalıştıran bir şey yoktur. Toplantı kararları, bir toplantı kalıcılaştırma adımı bunları kaydettiğinde decisions bilgi alanına toplanır; bu, tamamlanmış ajan çalıştırmaları üzerinde çalışan bir zamanlayıcı değildir.

İlgili kavramlar

• Ajan modeli: yetkilerin üzerine yazıldığı şey rollerdir
• Çalışma alanları ve yalıtım: bellek çalışma alanı kapsamlıdır ve o çalışma alanının kendi veritabanı dosyasında yaşar
• Çalışma alanı belleğini yönetme: bellekle pratikte çalışmak