Orjinal Başlık: Neden Açık Pençe Oturumlarım Bir Günde 21.5M Jeton Yaktı (Ve Gerçekte Nasıl Düzeltildi)
Orjinal Yazar: MOSHIII
Çeviri: Peggy, BlockBeats

Editör Notu: Ajan Uygulamasının hızla yaygınlaştığı bugünlerde, birçok ekip görünüşte sıradışı bir fenomen keşfetti: Sistem her şey normal işlerken, jeton maliyeti bilinçsizce sürekli artıyor. Bu makale, gerçek bir OpenClaw iş yükünün ayrıştırılması yoluyla, maliyet patlamasının genellikle kullanıcı girdisinden veya model çıktısından değil, göz ardı edilen önbellek geri oynatmasından (cached prefix replay) kaynaklandığını ortaya koyuyor. Model, her çağrı turunda devasa bir tarihsel bağlamı tekrar tekrar okurken, büyük miktarda jeton tüketimi oluşturuyor.

Makale, belirli oturum verilerini kullanarak, araç çıktısı, tarayıcı anlık görüntüsü, JSON günlükleri gibi büyük ara ürünlerin nasıl sürekli olarak tarihsel bağlama yazıldığını ve ajan döngüsünde tekrar tekrar okunduğunu göstermektedir.

Bu örnekleme üzerinden, yazar, net bir optimizasyon yaklaşımı önerdi: bağlam yapısı tasarımından araç çıktısı yönetimine ve sıkıştırma mekanizması yapılandırmasına kadar. Ajan sistemi oluşturan geliştiriciler için, bu sadece bir teknik sorun giderme kaydı değil, aynı zamanda ciddi bir tasarruf stratejisi anlamına gelmektedir.

Aşağıda orijinal metin bulunmaktadır:

Bir gerçek OpenClaw iş yükünü analiz ettim ve Agent kullanıcılarının çoğunun tanıyacağını düşündüğüm bir model keşfettim:

Jet kullanımı çok "canlı" görünüyor

Cevaplama görünüşte çok normal

Ancak jeton tüketimi aniden patlayıcı bir şekilde artıyor

Aşağıda bu analizin yapısal ayrıştırması, temel nedeni ve pratik olarak uygulanabilir tamir yolu bulunmaktadır.

Özet

En büyük maliyet itici faktör, kullanıcı mesajlarının çok uzun olması değil. Aksine, devasa miktarda önbellek öneki tekrar tekrar oynatıldığıdur.

Oturum verilerine göre:

Toplam jetonlar: 21,543,714

Önbellek Okuması: 17,105,970 (%79.40)

Giriş: 4.345.264 (%20,17)

Çıkış: 92.480 (%0,43)

Yani, çoğu çağrının maliyeti aslında yeni kullanıcı niyetini işlemekte değil, devasa tarihsel bağlamı tekrar tekrar okumakta.

“Hadi bir dakika, bu nasıl olabilir?” Anı

Ben başlangıçta yüksek token kullanımının uzun kullanıcı sorusundan, büyük çıktı üretiminden veya pahalı araç çağrılarından geldiğini düşünmüştüm.

Ancak gerçekten baskın olan desen şudur:

Giriş: Birkaç yüz ila birkaç bin token

Önbellek Okuma: Her çağrıda 170.000 ila 180.000 token

Yani, model her döngüde aynı devasa sabit önekin tekrar tekrar okunmasını yapmaktadır.

Veri Kapsamı

Verilerin iki düzeyini analiz ettim:

1. Çalışma Zamanı Günlükleri (runtime logs)
2. Oturum Metinleri (session transcripts)

Açıklamam gereken bir nokta var:

Çalışma günlükleri davranış sinyallerini gözlemlemek için kullanılmaktadır (yeniden başlatma, hata, yapılandırma sorunu gibi)

Kesin token istatistiği oturum JSONL'deki kullanım alanından gelmektedir.

Kullanılan betikler:

scripts/session_token_breakdown.py

scripts/session_duplicate_waste_analysis.py

Oluşturulan analiz dosyaları:

tmp/session_token_stats_v2.txt

tmp/session_token_stats_v2.json

tmp/session_duplicate_waste.txt

tmp/session_duplicate_waste.json

tmp/session_duplicate_waste.png

Token Gerçekten Nerede Harcanıyor?

1）Oturum Odaklılık

Bir oturumun diğerlerinden çok daha fazla harcama yaptığı görülüyor:

570587c3-dc42-47e4-9dd4-985c2a50af86: 19,204,645 token

Ardından belirgin bir şekilde düşüş görülüyor:

ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1,505,038

ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649,584

2）Davranış Odaklılık

Token'lar çoğunlukla şu kaynaklardan geliyor:

toolUse: 16,372,294

stop: 5,171,420

Problemin, normal sohbetten ziyade araç çağrısı zinciri döngüsünde olduğu görülüyor.

3）Zaman Odaklılık

Token zirvesi rastgele değil, birkaç saat diliminde yoğunlaşmış durumda:

2026-03-08 16:00: 4,105,105

2026-03-08 09:00: 4,036,070

2026-03-08 07:00: 2,793,648

Büyük Önbellek Öneki Gerçekte Ne İçeriyor?

Burada konuşmanın içeriği değil, genellikle büyük ara ürünler bulunuyor:

Büyük toolResult veri bloğu

Uzun düşünce / mantık izleri

Büyük JSON anlık görüntüsü

Dosya listesi

Tarayıcı tarafından alınan veriler

Ara Ajan'ın konuşma kayıtları

En büyük oturumda, karakter sayısı yaklaşık olarak şu şekildedir:

toolResult:text: 366,469 karakter

assistant:thinking: 331,494 karakter

assistant:toolCall: 53,039 karakter

Bu içerikler bir kez tarih bağlamında saklandığında, her bir çağrı sonrasında muhtemelen önbellek öneki aracılığıyla yeniden okunabilir.

Özel Örnek (oturum dosyasından)

Aşağıdaki konumda tekrar tekrar görünen büyük hacimli bağlam blokları vardır:

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70

Büyük Gateway JSON günlüğü (yaklaşık 37,000 karakter)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134

Tarayıcı Anlık Görüntüsü + Güvenlik Kılıfı (yaklaşık 29,000 karakter)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219

Büyük dosya listesi çıktısı (yaklaşık 41,000 karakter)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311

oturum/status durum anlık görüntüsü + büyük ekran yapısı (yaklaşık 30,000 karakter)

「Tekrarlanan İçerik Boşa Harcanması」 vs 「Önbellek Yeniden Oynatma Yükü」

Ayrıca, tek çağrı içinde iç tekrar oranını ölçtüm:

Tekrar oranı yaklaşık: %1.72

Evet var ancak ana sorun değil.

Gerçek sorun şudur: Önbellek önekinin mutlak büyüklüğü çok fazladır

Yapı, büyük tarih bağlamı, her tur çağrı yeniden okuma, yalnızca az miktarda yeni girdinin üst üste gelmesidir

Bu nedenle, optimizasyon odak noktası tekrar değil, bağlam yapılandırmasıdır.

Neden Araştırmacı Döngüsü bu sorunu özellikle kolayca yaşar?

Üç mekanizma birbirini etkiler:

1. Büyük miktarda araç çıktısı geçmiş bağlama yazılır

2. Araç döngüsü büyük miktarda kısa süreli çağrı üretir

3. Önek değişikliği çok küçük → önbellek her zaman yeniden okunur

Eğer bağlam sıkıştırması istikrarlı bir şekilde tetiklenmezse, sorun hızla büyür.

En Önemli Düzeltme Stratejileri (Etki Sırasına Göre)

P0—Büyük Araç Çıktılarını Uzun Süreli Bağlama Yerleştirme

Süper büyük araç çıktıları için:

· Özet + Referans Yolu / Kimlik tut

· Orijinal yük dosyasını dosya sanatı olarak yaz

· Tam metni sohbet geçmişinde saklama

Bu kategorileri öncelikle kısıtlayın:

· Büyük JSON

· Uzun dizin listeler

· Tarayıcı tam görüntüsü

· Alt Araştırmacı Tam Metin Kaydı

P1—Sıkıştırma Mekanizmasının Gerçekten İşe Yaradığından Emin Olun

Bu veride, yapılandırma uyumsuzluğu sorunları defalarca karşılaşıldı: sıkıştırma anahtarı geçersiz

Bu, optimizasyon mekanizmasını sessizce kapatır.

Doğru işlem: Yalnızca sürüm uyumlu yapılandırmayı kullanın

Ardından doğrulayın:

openclaw doctor --fix

Ve sıkıştırmanın kabul edildiğini onaylamak için başlangıç günlüklerini kontrol edin.

P1—Akıl Yürütme Metni Kalıcılığını Azaltın

Uzun akıl yürütme metnin tekrar tekrar oynatılmasını önleyin

Üretim ortamında: Tam ayrıntı yerine kısa özetleri saklayın

P2—Prompt Önbelleğini Geliştirme

Hedef, cacheRead'i maksimize etmek değildir. Hedef, sıkı, istikrarlı ve yüksek değerli öneklerde önbelleği kullanmaktır.

Öneri:

· Sabit kuralları sistem prompt'ına yerleştirin

· Sabit olmayan verileri sabit önek içine koymayın

· Her döngüde büyük miktarda hata ayıklama verisi enjekte etmekten kaçının

Uygulanabilir Stop-Loss Stratejisi (Yarın İşlemem Gerekiyorsa)

1. En yüksek cacheRead yüzdesine sahip oturumu bulun
2. Kaçan oturumlara /kompakt işlemi uygulayın
3. Araç çıktısına kırpma + artefakt ekleme yapın
4. Her değişiklikten sonra jeton istatistiğini tekrar çalıştırın

Dört KPI'yi dikkatlice takip edin:

cacheRead / toplamJet

araçKullanımı avgToplam/çağrı

>=100k jeton olan çağrıların sayısı

Maksimum oturum yüzdesi

Başarılı Sinyaller

Optimizasyon etkili olduğunda şunları görmelisiniz:

100k+ jeton çağrısında belirgin azalma

cacheRead yüzdesinde düşüş

araçKullanımı çağrı ağırlığında düşüş

Tek bir oturumun hakimiyet düzeyinde azalma

Eğer bu metriklerde bir değişiklik yoksa, bağlam stratejinizin hala çok geniş olduğunu gösterir.

Reprodüksiyon Deneyi Komutu

python3 scripts/session_token_breakdown.py 'oturumlar' \
--silinmeleri-dahil-et \
--ilk 20 \
--aykırı-eşik 120000 \
--json-çıkış tmp/oturum_token_istatistikleri_v2.json \
> tmp/oturum_token_istatistikleri_v2.txt

python3 scripts/session_duplicate_waste_analysis.py 'sessions' \
--include-deleted \
--top 20 \
--png-out tmp/session_duplicate_waste.png \
--json-out tmp/session_duplicate_waste.json \
> tmp/session_duplicate_waste.txt

Sonuç

Eğer Agent sisteminiz her şey normal görünürken maliyet sürekli artıyorsa, bir sorunu kontrol etmek iyi bir başlangıç olabilir: Ödediğiniz şey yeni çıkarım mı, yoksa büyük ölçekli eski bağlamın tekrarlanması mı?

Benim durumumda, asıl maliyetin çoğu aslında Bağlamın Tekrar Oynatılmasından kaynaklanıyordu.

Bunu fark ettiğinizde, çözüm oldukça açıktır: Uzun vadeli bağlama giren veriyi sıkıca kontrol edin.

[Orijinal Makale Bağlantısı]

BlockBeats Resmi Topluluğuna Katılın:

Telegram Abonelik Grubu: https://t.me/theblockbeats

Telegram Sohbet Grubu: https://t.me/BlockBeats_App

Twitter Resmi Hesabı: https://twitter.com/BlockBeatsAsia