OpenClaw يوميًا يحرق 21.5 مليون توكن؟ ثلاث استراتيجيات تحسين لخفض التكاليف بشكل كبير

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

المؤلف: MOSHIII

الترجمة: Peggy، BlockBeats

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

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

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

وفيما يلي النص الأصلي:

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

استهلاك الرموز يبدو «نشطًا»

الردود تبدو طبيعية جدًا

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

وفيما يلي تفصيل التحليل، والأسباب الجذرية، والطريق العملي للإصلاح.

ملخص سريع

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

من بيانات الجلسة، نرى أن:

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

قراءة من الذاكرة المؤقتة (cacheRead): 17,105,970 (79.40%)

مدخلات (input): 4,345,264 (20.17%)

مخرجات (output): 92,480 (0.43%)

بمعنى آخر: غالبية التكاليف ليست في معالجة نية المستخدم الجديدة، بل في قراءة السياق التاريخي الضخم بشكل متكرر.

لحظة «كيف يمكن أن يكون ذلك؟»

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

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

مدخلات: من مئات إلى آلاف الرموز

قراءة من الذاكرة المؤقتة (cacheRead): من 170,000 إلى 180,000 رمز في كل استدعاء

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

نطاق البيانات

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

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

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

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

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

أما الإحصائيات الدقيقة للرموز فهي تأتي من حقل الاستخدام (usage) في ملفات 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

stop: 5,171,420

وهذا يدل على أن المشكلة تتعلق بشكل رئيسي بسلسلة استدعاءات الأدوات، وليس بالمحادثة العادية.

3) متركز زمنيًا

ذروة استهلاك الرموز ليست عشوائية، بل تتركز في فترات زمنية محددة:

8 مارس 2026، الساعة 16:00: 4,105,105

8 مارس 2026، الساعة 09:00: 4,036,070

8 مارس 2026، الساعة 07:00: 2,793,648

ما الذي يوجد في المقدمة الضخمة من ذاكرة السياق؟

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

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

مسارات التفكير / الاستنتاج الطويلة

لقطات JSON الكبيرة

قوائم الملفات

بيانات التقاط المتصفح

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

وفي أكبر جلسة، يكون حجم النص حوالي:

toolResult: النص: 366,469 حرفًا

assistant:thinking: 331,494 حرفًا

assistant:toolCall: 53,039 حرفًا

بمجرد أن يتم الاحتفاظ بهذه المحتويات في السياق التاريخي، فإن كل استدعاء لاحق قد يعيد قراءتها عبر المقدمة المخزنة (cache prefix).

مثال محدد (من ملف الجلسة)

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

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

سجل JSON كبير (حوالي 37,000 حرف)

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

لقطة المتصفح + التغليف الآمن (حوالي 29,000 حرف)

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

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

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

حالة الجلسة + هيكل prompt كبير (حوالي 30,000 حرف)

«إهدار المحتوى المكرر» مقابل «عبء إعادة التشغيل للذاكرة المؤقتة»

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

نسبة التكرار حوالي: 1.72%

وهذا موجود، لكنه ليس المشكلة الرئيسية.

المشكلة الحقيقية هي: الحجم المطلق للمقدمة المخزنة (cache prefix) كبير جدًا

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

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

لماذا تتكرر مشكلة الحلقة في Agent بشكل خاص؟

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

1. الكثير من مخرجات الأدوات تُكتب في السياق التاريخي

2. حلقات الأدوات تؤدي إلى العديد من الاستدعاءات قصيرة الفاصل الزمني

3. التغيرات في المقدمة صغيرة جدًا → كل مرة يعاد فيها القراءة من الذاكرة المؤقتة (cache)

إذا لم يتم تفعيل ضغط السياق (context compaction) بشكل مستقر، فإن المشكلة ستتفاقم بسرعة.

أهم استراتيجيات الإصلاح (حسب التأثير)

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

بالنسبة للمخرجات الضخمة للأدوات:

• احتفظ بملخص + مسار / معرف مرجعي

• اكتب الحمولة الأصلية في ملف artifact

• لا تحتفظ بالنص الكامل في سجل الدردشة

ركز على تقييد هذه الأنواع:

• JSON كبير

• قوائم الدلائل الطويلة

• لقطات المتصفح الكاملة

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

P1 — تأكد من أن آلية الضغط (compaction) فعالة حقًا

في البيانات الموجودة، تظهر مشاكل توافق التكوين عدة مرات: عدم فاعلية مفتاح الضغط (compression key)

وهذا يؤدي إلى إيقاف تفعيل التحسينات بشكل غير معلن.

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

ثم التحقق عبر:

openclaw doctor --fix

ومراجعة سجلات التشغيل للتأكد من قبول عملية الضغط.

P1 — قلل من تخزين نص الاستنتاج (reasoning)

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

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

P3 — حسّن تصميم التخزين المؤقت للمحفزات (prompt caching)

الهدف ليس تعظيم قراءة الرموز من الذاكرة المؤقتة. الهدف هو استخدام الكاش على المقدمة المضغوطة، المستقرة، ذات القيمة العالية.

اقتراحات:

• أدخل قواعد الاستقرار في prompt النظام (system prompt)

• لا تضع البيانات غير المستقرة في المقدمة المستقرة

• تجنب إدخال كمية كبيرة من بيانات التصحيح (debug) في كل دورة

خطة إيقاف الخسارة العملية (لو كنت سأتعامل غدًا)

1. حدد الجلسة التي تحتوي على أعلى نسبة من قراءة من الذاكرة المؤقتة (cacheRead)

2. نفذ أمر /compact على الجلسة المفرطة في التهور (runaway session)

3. أضف تقطيع (truncate) إلى مخرجات الأدوات واعتبرها كملفات artifact

4. بعد كل تعديل، أعد حساب الرموز

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

• نسبة cacheRead إلى إجمالي الرموز (totalTokens)

• متوسط إجمالي استخدام الأدوات لكل استدعاء

• عدد الاستدعاءات التي تتجاوز 100,000 رمز

• نسبة الجلسة الأكبر

إشارات النجاح

إذا كانت التحسينات فعالة، ستلاحظ:

• انخفاض واضح في الاستدعاءات التي تتجاوز 100,000 رمز

• انخفاض نسبة قراءة من الذاكرة المؤقتة (cacheRead)

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

• تقليل السيطرة على الجلسة الفردية

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

أوامر إعادة التجربة

python3 scripts/session_token_breakdown.py ‘sessions’
–include-deleted
–top 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
–top 20
–png-out tmp/session_duplicate_waste.png
–json-out tmp/session_duplicate_waste.json \

tmp/session_duplicate_waste.txt

الخاتمة

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

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

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