جلسة OpenClaw تحرق 21.5 مليون رمز في يوم واحد، واستراتيجيات التحسين تقلل التكاليف

لماذا حرق جلسات OpenClaw الخاصة بي 21.5 مليون رمز في يوم واحد (وما الذي أصلحه فعليًا)

المؤلف الأصلي: MOSHIII

مُترجم الأصل: بيجي، BlockBeats

ملاحظة المحرر: في ظل الانتشار السريع لتطبيقات العامل، اكتشف العديد من الفرق ظاهرة تبدو متناقضة: فرغم أن النظام يعمل بشكل طبيعي، فإن تكلفة الرموز ترتفع باستمرار دون أن يُلاحظ ذلك. من خلال تحليل عبء عمل حقيقي لـ OpenClaw، تبين أن سبب الانفجار في التكلفة لا يعود عادةً إلى مدخلات المستخدم أو مخرجات النموذج، بل إلى إعادة تشغيل ذاكرة التخزين المؤقت للسياق (cached prefix replay) التي تُهمل غالبًا. ففي كل استدعاء، يقرأ النموذج بشكل متكرر سياقًا تاريخيًا ضخمًا، مما يؤدي إلى استهلاك هائل للرموز.

يعرض المقال، بناءً على بيانات جلسة محددة، كيف يتم كتابة المنتجات الوسيطة الكبيرة مثل مخرجات الأداة، لقطات المتصفح، وسجلات JSON بشكل مستمر في السياق التاريخي، وكيف يتم قراءتها مرة أخرى خلال دورة الوكيل.

من خلال هذه الحالة، يقترح المؤلف مجموعة من أفكار التحسين الواضحة: من تصميم هيكل السياق، إلى إدارة مخرجات الأدوات، وحتى تكوين آلية التجميع. بالنسبة للمطورين الذين يبنون أنظمة Agent، فإن هذا ليس فقط سجلاً تقنيًا للتشخيص، بل أيضًا خطة واقعية لتوفير التكاليف.

Below is the original text:

قمت بتحليل حملة عمل حقيقية لـ OpenClaw، ووجدت نمطًا أعتقد أن العديد من مستخدمي الوكلاء سيتعرفون عليه:

استخدام الرمز يبدو نشطًا جدًا

الرد يبدو طبيعيًا أيضًا

لكن استهلاك الرموز تزايد فجأة بشكل هائل

فيما يلي تحليل الهيكل، والسبب الجذري، ومسار الإصلاح العملي لهذه التحليلات.

أكبر عامل يدفع التكلفة ليس طول رسالة المستخدم، بل إعادة تشغيل كميات هائلة من البادئات المخزنة مؤقتًا.

من بيانات الجلسة:

إجمالي الرموز: 21,543,714

cacheRead: 17,105,970 (79.40%)

4,345,264 (20.17%)

الإخراج: 92,480 (0.43%)

بعبارة أخرى: تكاليف معظم المكالمات لا تُنفق في الواقع على معالجة نوايا المستخدمين الجدد، بل على قراءة متكررة للسياق التاريخي الضخم.

اعتقدت في الأصل أن استخدام الرمز المميز العالي ناتج عن: مطالبات مستخدم طويلة جدًا، أو إنتاج كميات كبيرة من المخرجات، أو استدعاء أدوات مكلفة.

لكن النمط الحقيقي المهيمن هو:

مئات إلى آلاف الرموز

cacheRead: كل استدعاء بين 170,000 و 180,000 token

بمعنى آخر، النموذج يقرأ مرارًا وتكرارًا نفس البادئة الثابتة الضخمة في كل جولة.

لقد قمت بتحليل بيانات من مستويين:

1. سجلات التشغيل (runtime logs)

2. سجلات الجلسة (session transcripts)

يجب التوضيح أن:

تُستخدم سجلات التشغيل بشكل أساسي لمراقبة إشارات السلوك (مثل إعادة التشغيل، الأخطاء، مشاكل التكوين)

إحصائيات دقيقة للرمز المميز مستمدة من حقل الاستخدام في ملف session JSONL

النص المستخدم:

scripts/session_token_breakdown.py

scripts/session_duplicate_waste_analysis.py

ملف التحليل المُنشأ:

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

1) تجميع الجلسة

هناك جلسة تستهلك أكثر بكثير من غيرها:

570587c3-dc42-47e4-9dd4-985c2a50af86: 19,204,645 رمزًا

ثم الانخفاض الحاد الواضح:

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

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

2) التركيز على السلوك

تُستمد الرموز من:

toolUse：16,372,294

إيقاف: 5,171,420

المشكلة تكمن أساسًا في حلقة استدعاء الأدوات، وليس في المحادثة العادية.

3) تركيز الوقت

لا تكون قمة الرمز المميز عشوائية، بل تتركز في فترات زمنية قليلة:

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

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

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

ليس محتوى المحادثة، بل بشكل رئيسي المنتج الوسيط الكبير:

كتلة بيانات toolResult الضخمة

أطوال كبيرة من آثار التفكير / التفكير

ملف JSON كبير

List of files

استخلاص البيانات من المتصفح

سجل المحادثة للوكيل الفرعي

في أقصى جلسة، يكون عدد الأحرف تقريبًا:

366,469 حرف

assistant:thinking：331,494 حرف

53,039 حرف

بمجرد الاحتفاظ بهذه المحتويات في السياق التاريخي، قد يتم إعادة قراءتها في كل استدعاء لاحق عبر بادئة cache.

ظهرت كتل سياق ضخمة بشكل متكرر في الموقع التالي:

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

سجلات JSON للبوابة الكبيرة (حوالي 37 ألف حرف)

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

صورة متصفح + تغليف آمن (حوالي 29 ألف حرف)

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

قائمة ملفات ضخمة (حوالي 41 ألف حرف)

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

ملف حالة الجلسة + هيكل موجه كبير (حوالي 30 ألف حرف)

كما قمت بقياس نسبة المحتوى المتكرر داخل كل استدعاء فردي:

نسبة التكرار تقريبًا: 1.72%

Exists indeed, but it is not the main issue.

المشكلة الحقيقية هي أن حجم البادئة المؤقتة كبير جدًا

الهيكل هو: سياق تاريخي ضخم، إعادة قراءة كل مكالمة، مع إضافة كمية صغيرة فقط من المدخلات الجديدة فوقه

لذلك، فإن التركيز على التحسين ليس على إزالة التكرار، بل على تصميم هيكل السياق.

ثلاثة آليات تتداخل مع بعضها البعض:

تم كتابة إخراج أدوات كبيرة إلى السياق التاريخي

2. تؤدي دورة الأدوات إلى عدد كبير من المكالمات ذات الفترات القصيرة.

3. التغيير في البادئة ضئيل جدًا → يتم إعادة قراءة الذاكرة المؤقتة في كل مرة

إذا لم يتم تفعيل تكثيف السياق بشكل مستقر، فستتصاعد المشكلة بسرعة.

P0—لا تُدخل مخرجات الأدوات الضخمة في السياق الطويل الأمد

لإخراج الأدوات الفائقة الكبيرة:

• احتفظ بالملخص + مسار الاستشهاد / ID
• كتابة payload الأصلي إلى ملف artifact
• لا تحتفظ بالنص الأصلي الكامل في سجل المحادثة

القيود المسبقة على هذه الفئات:

• ملف JSON كبير
• قائمة دليل طويلة
• النسخة الكاملة للمتصفح
• نسخة كاملة من العميل الفرعي

P1—تأكد من أن آلية التجميع تعمل فعليًا

في هذه البيانات، ظهرت مشاكل توافق التكوين عدة مرات: مفتاح الضغط غير صالح

سيقوم بإغلاق آلية التحسين بصمت.

الإجراء الصحيح: استخدم إعدادات متوافقة مع الإصدار فقط

ثم تحقق:

openclaw doctor --fix

وتحقق من سجل الإطلاق للتأكد من قبول التجميع.

P1—تقليل تثبيت نص الاستدلال

تجنب تكرار تشغيل نصوص الاستدلال الطويلة

في بيئة الإنتاج: احفظ الملخص المختصر، وليس التبرير الكامل

P3—تحسين تصميم تخزين مُحفوظات الأوامر

الهدف ليس تكبير cacheRead. الهدف هو استخدام الذاكرة المؤقتة على بادئات مضغوطة ومستقرة وذات قيمة عالية.

اقتراح:

• ضع القواعد الثابتة في system prompt
• لا تضع البيانات غير المستقرة في البادئة المستقرة
• تجنب حقن كمية كبيرة من بيانات التصحيح في كل جولة

1. ابحث عن الجلسة ذات أعلى نسبة cacheRead

2. نفّذ /compact على جلسة runaway

3. أضف تقليصًا + تحوّلًا إلى مخرجات الأداة

4. أعد تشغيل إحصاءات الرمز بعد كل تعديل

تتبع أربعة مؤشرات أداء رئيسية:

قراءة الذاكرة المؤقتة / إجمالي الرموز

استخدام الأداة avgTotal/الاستدعاء

عدد المكالمات >=100k رمز

أقصى نسبة جلسة

إذا نفّذ التحسين، يجب أن ترى:

انخفض استدعاءات الرموز المميزة بأكثر من 100 ألف بشكل واضح

انخفاض نسبة cacheRead

انخفاض وزن استدعاء toolUse

انخفاض درجة السيطرة في جلسة واحدة

إذا لم تتغير هذه المؤشرات، فهذا يعني أن استراتيجيتك السياقية لا تزال مرنة جدًا.

python3 scripts/session_token_breakdown.py 'sessions' \

--include-deleted \

-- أعلى 20 \

--outlier-threshold 120000 \

--json-out tmp/session_token_stats_v2.json \

> tmp/session_token_stats_v2.txt

python3 scripts/session_duplicate_waste_analysis.py 'sessions' \

--include-deleted \

-- أعلى 20 \

--png-out tmp/session_duplicate_waste.png \

--json-out tmp/session_duplicate_waste.json \

> tmp/session_duplicate_waste.txt

إذا بدا نظام وكيلك طبيعيًا تمامًا، لكن التكاليف تستمر في الارتفاع، يمكنك أولًا التحقق من مشكلة واحدة: هل أنت تدفع مقابل استنتاجات جديدة، أم تعيد تشغيل سياقات قديمة على نطاق واسع؟

في حالي، فإن معظم التكاليف تأتي في الواقع من إعادة تشغيل السياق.

بمجرد أن تدرك هذا، فإن الحل يكون واضحًا: التحكم الصارم في البيانات المدخلة إلى السياق الطويل.

الرابط الأصلي