OmniRoute/docs/i18n/ar/docs/compression/COMPRESSION_GUIDE.md

🗜️ Prompt Compression Guide — OmniRoute (العربية)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

---

وفّر تلقائيًا من 15% إلى 95% من السياق المؤهل. للحصول على نظرة عامة سريعة، راجع قسم الضغط في README.

نظرة عامة

ينفّذ OmniRoute مسارًا معياريًا لضغط المطالبات يعمل استباقيًا قبل وصول الطلبات إلى موفّري الخدمة في المنبع. وهذا يعني أن توفير الرموز يتم بشفافية — من دون الحاجة إلى إجراء أي تغييرات على سير عملك.

طلب العميل
  → محدد استراتيجية الضغط
    → هل يوجد تجاوز عبر مجموعة؟ → استخدام إعداد المجموعة
    → هل تم بلوغ حد التشغيل التلقائي؟ → استخدام الوضع التلقائي
    → هل يوجد وضع افتراضي؟ → استخدام الإعداد العام
    → هل الضغط متوقف؟ → تخطي الضغط
  → وضع الضغط المحدد
    → متوقف: دون ضغط
    → خفيف: تنظيف آمن للمسافات البيضاء/التنسيق (~15%)
    → قياسي: إزالة الحشو بأسلوب الكلام المقتضب (~30%)
    → مكثف: تقادم السجل + التلخيص (~50%)
    → فائق: تقليم استدلالي + تقليص كتل التعليمات البرمجية (~75%)
    → RTK: تصفية واعية بالأوامر لمخرجات الطرفية/الأدوات (نطاق 60-90% في المنبع)
    → مكدّس: مسار مرتب متعدد المحركات، عادةً RTK ثم Caveman (نطاق 78-95% للمحتوى المؤهل)
  → الطلب المضغوط → الموفّر

---

أوضاع الضغط

متوقف

لا يُطبّق أي ضغط. تمر جميع الرسائل من دون تغيير.

الوضع الخفيف (توفير ~15%، وزمن استجابة <1ms)

الوضع الأكثر أمانًا — لا تغيير دلاليًا، بل تنظيف للتنسيق فقط:

التقنية	الوصف
collapseWhitespace	دمج الأسطر الفارغة المتتالية والمسافات اللاحقة
dedupSystemPrompt	إزالة رسائل النظام المكررة
compressToolResults	ضغط مخرجات الأدوات/الدوال المطوّلة
removeRedundantContent	حذف التعليمات المتكررة
replaceImageUrls	تقصير عناوين URI لبيانات الصور بترميز base64

الأنسب لـ: الاستخدام الدائم، وسير العمل الحساس للسلامة.

الوضع القياسي (توفير ~30%)

مستوحى من Caveman — يزيل الكلمات الحشوية والصياغات المطوّلة مع الحفاظ على المعنى:

• يزيل الكلمات الحشوية ("من فضلك"، "أعتقد"، "بشكل أساسي"، "في الواقع")
• يختصر العبارات المطوّلة ("من أجل" ← "لـ"، "نتيجةً لـ" ← "بسبب")
• يزيل عبارات التلطيف المهذبة ("هل تمانع..."، "إذا كان بإمكانك...")
• أكثر من 30 قاعدة regex مضبوطة لمطالبات البرمجة

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

الوضع المكثف (توفير ~50%)

إدارة ذكية للسجل في الجلسات الطويلة:

• تقادم الرسائل — تُضغط الرسائل الأقدم تدريجيًا
• تلخيص نتائج الأدوات — تُستبدل مخرجات الأدوات الطويلة بملخصات
• ضوابط السلامة الهيكلية — تضمن بقاء أزواج tool_use وtool_result متسقة
• مراعاة نافذة السياق — يلتزم بحدود الرموز الخاصة بكل نموذج

الأنسب لـ: جلسات تصحيح الأخطاء المطوّلة، وقواعد التعليمات البرمجية الكبيرة.

الوضع الفائق (توفير ~75%)

أقصى ضغط للسيناريوهات الحرجة من حيث الرموز:

• التقليم الاستدلالي — يزيل الرسائل التي تقل عن عتبة الصلة
• تقليص كتل التعليمات البرمجية — يضغط أمثلة التعليمات البرمجية المتكررة
• الاقتطاع بالبحث الثنائي — يعثر على نقطة القطع المثلى لنافذة السياق
• يتضمن جميع ميزات الوضع المكثف

الأنسب لـ: الحالات التي تبلغ فيها حدود السياق بصورة متكررة.

وضع RTK (نطاق 60-90% في المنبع)

تم تحسين وضع RTK لمخرجات الأدوات المطوّلة التي تظهر في جلسات وكلاء البرمجة:

• يكتشف فئات الأوامر/المخرجات مثل git status وgit diff وgit log وأدوات تشغيل الاختبارات، وعمليات بناء TypeScript/Vite/Webpack، وESLint/Biome/Prettier، وعمليات تدقيق/تثبيت npm، وسجلات Docker، ومخرجات البنية التحتية، ومخرجات الصدفة العامة
• يطبّق حزم مرشحات JSON من open-sse/services/compression/engines/rtk/filters/
• يستورد مرشحات مخطط RTK TOML بالإصدار v1 من ملفات filters.toml الخاصة بالمشروع أو العامة، مع التحقق بواسطة الاختبارات المضمّنة والتحكم القائم على الثقة لملفات المشروع
• يتضمن 49 مرشحًا مدمجًا مع عينات تحقق مضمّنة
• يزيل تسلسلات تحكم ANSI وأشرطة التقدم والأسطر المتكررة والضوضاء غير القابلة لاتخاذ إجراء
• يحافظ على حالات الفشل والأخطاء والتحذيرات والملفات المتغيرة والملخصات ونهاية المخرجات الطويلة
• يدعم مرشحات المشروع الخاضعة للتحكم القائم على الثقة، والمرشحات العامة، والاستعادة الاختيارية للمخرجات الخام المنقّحة

الأنسب لـ: جلسات الوكلاء التي تتضمن نصوصًا منقولة من الصدفة وعمليات البناء والاختبار وgit وgrep ومخرجات الملفات.

الوضع المكدّس (نطاق 78-95% للمحتوى المؤهل)

يشغّل الوضع المكدّس عدة محركات ضغط بترتيب حتمي. المسار الافتراضي هو:

RTK -> Caveman

يحافظ هذا الترتيب أولًا على إيجاز مخرجات الطرفية/الأدوات، ثم يطبّق التكثيف الدلالي لـ Caveman على ما تبقى من مطالبة اللغة الطبيعية. يمكن تكوين المسارات المكدّسة بشكل عام أو من خلال مجموعات الضغط المعيّنة لمجموعات التوجيه.

الأنسب لـ: السياق المختلط الذي يتضمن سجلات أدوات كبيرة إلى جانب تعليمات بشرية أو ملخصات المساعد.

---

حساب وفورات المصدر الأساسي

يوثّق OmniRoute وفورات الضغط من مصدرين: معايير أداء المشاريع الأصلية ودمج المحركات الخاص بـ OmniRoute.

المصدر	الرقم المستخدم هنا من README للمصدر الأساسي
Caveman	عدد رموز مخرجات أقل بنسبة ~75%، ومتوسط وفورات المخرجات في الاختبارات المعيارية 65%، ونطاق 22-87%، وأداة لضغط المدخلات بنسبة ~46%
RTK	وفورات بنسبة 60-90% في مخرجات الأوامر؛ جلسة نموذجية من ~118,000 -> ~23,900 رمزًا، أي توفير بنسبة 79.7% (~80%)

بالنسبة إلى حمولات الأدوات/السياق المتداخلة، تجمع توليفة OmniRoute الافتراضية المحركات:

RTK -> Caveman

الوفورات المجمّعة تراكمية بالضرب، وليست بالجمع:

المجمّع = 1 - (1 - وفورات RTK) * (1 - وفورات مدخلات Caveman)
المتوسط = 1 - (1 - 0.80) * (1 - 0.46) = 89.2%
النطاق  = 1 - (1 - 0.60..0.90) * (1 - 0.46) = 78.4-94.6%

ينطبق رقم 78-95% عندما يستطيع كلٌّ من RTK وCaveman تقليل حمولة المدخلات/السياق نفسها. يُعد وضع مخرجات استجابة Caveman منفصلًا: عند تمكينه، استخدم وفورات مخرجات Caveman نفسها (متوسط 65%، ورقم رئيسي ~75%، ونطاق 22-87%). تعتمد وفورات الفوترة الإجمالية على مزيج المطالبات/المخرجات لديك.

ما الذي تعنيه كلمة "مؤهل" فعليًا

النطاق الرئيسي 15-95% حقيقي، لكنه لا ينطبق إلا على المحتوى المكرر أو المسهب — مثل أسطر الأخطاء المتكررة، أو سجل بناء يكرر التحذير نفسه بإفراط، أو مخرجات ضخمة من grep/قراءة ملف. ولا يعني ذلك أن كل طلب يحقق هذا القدر من التوفير.

تم التحقق تجريبيًا (tests/unit/compression/stacked-compression-tool-result-savings.test.ts): أدى تشغيل stacked ‏(RTK + Caveman) على كتلة tool_result ببنية Anthropic تحتوي على 300 سطر خطأ متطابق إلى وفورات في الرموز بنسبة 95.93% / وفورات في الأحرف بنسبة 96.26% — ضمن النطاق المُعلن تمامًا. لكن تشغيل المسار نفسه على مخرجات أدوات عادية وغير مكررة (قائمة مطابقة نظيفة من grep، أو قراءة ملف قصيرة، أو نص محادثة اعتيادي) ينتج، على نحو صحيح، وفورات تقترب من الصفر، لأنه لا يوجد شيء متكرر لإزالته، ولأن validateCompression() ‏(validation.ts) يرفض إرسال إعادة صياغة قد تحذف أو تغيّر كتل التعليمات البرمجية أو عناوين URL أو العناوين أو الإصدارات أو معرّفات الثوابت المكتوبة بالكامل بأحرف كبيرة.

هذا سلوك متوقع وآمن، وليس خطأً برمجيًا: ستحقق جلسة برمجة تعتمد غالبًا على قراءة/البحث في ملفات نظيفة وفورات إجمالية متواضعة حتى مع تمكين الضغط بالكامل، بينما ستحقق جلسة تواجه حلقة فاشلة أو أداة lint كثيرة الرسائل النطاق الكامل 78-95% على ذلك التدفق. لا تستخدم انخفاض نسبة الوفورات الإجمالية لجلسة واحدة دليلًا على سوء إعداد الضغط — تحقّق أولًا مما إذا كانت مخرجات الأداة الأساسية مكررة فعلًا.

---

عرض مرئي لوفورات الرموز

دون ضغط:             47K رمزًا مُرسلًا إلى LLM
باستخدام Lite:       40K رمزًا مُرسلًا          (توفير 15% — آمن، ومفعّل دائمًا)
باستخدام Standard:   33K رمزًا مُرسلًا          (توفير 30% — قواعد أسلوب Caveman)
باستخدام Aggressive: 24K رمزًا مُرسلًا          (توفير 50% — التقادم + التلخيص)
باستخدام Ultra:      12K رمزًا مُرسلًا          (توفير 75% — التقليم الاستدلالي)
باستخدام RTK:        19K-5K رمزًا مُرسلًا       (توفير 60-90% في مخرجات الأوامر/الأدوات)
باستخدام Stacked:    10K-2.5K رمزًا مُرسلًا     (نطاق RTK+Caveman المؤهل البالغ 78-95%)

---

الإعداد

لوحة التحكم

انتقل إلى Dashboard → Context & Cache:

• Caveman — اختيار الوضع، وحزم اللغات، والمعاينة، والإعدادات الافتراضية العامة
• RTK — معاينة مرشح الأوامر، وإعدادات أمان RTK، ودليل المرشحات
• مجموعات الضغط — مسارات معالجة مسماة للمحركات تُعيّن إلى مجموعات التوجيه
• حد التشغيل التلقائي — تشغيل الضغط تلقائيًا عندما يتجاوز عدد الرموز الحد المحدد

التجاوز لكل مجموعة

في Dashboard → Context & Cache → Compression Combos، عيّن مجموعة ضغط إلى مجموعة توجيه:

المجموعة: "free-tier-fallback"
  مجموعة الضغط: "coding-agent-stack"
  مسار المعالجة: RTK -> Caveman
  الأهداف:
    1. if/kimi-k2.7-code
    2. if/qwen3.8-max-preview

يتيح لك ذلك استخدام الضغط المتسلسل مع مزودي الخدمات المجانية/البرمجية، مع الإبقاء على الوضع الخفيف للاشتراكات المدفوعة.

إن تعيين "التجاوز لكل مجموعة" هذا عنصر تحكم مختلف عن تجاوز وضع ضغط مجموعة التوجيه (Default/Off/Lite/Standard/Aggressive/Ultra) — فهذا التجاوز لا يختار مسار معالجة مسمى لمجموعة ضغط؛ بل يضبط فقط الحقل compressionMode الذي تستعلم عنه resolveCompressionPlan. ويمكن ضبطه إما على بطاقة المجموعة (Dashboard → Combos) أو، منذ #6760، لكل مجموعة توجيه في قائمة "Assign to routing" ضمن Dashboard → Context & Cache → Compression Combos، بجوار مربع اختيار تعيين مسار المعالجة الموثق أعلاه مباشرةً. وتُحفظ التغييرات من كلتا الواجهتين عبر نقطة النهاية نفسها PUT /api/combos/{id}.

التجاوز لكل طلب

أرسل ترويسة الطلب x-omniroute-compression لتجاوز خطة الضغط لطلب واحد. ولها أعلى أولوية — إذ تتفوق على تجاوز مجموعة التوجيه، والملف الشخصي النشط، والتشغيل التلقائي، والإعداد Default في اللوحة. تُتجاهل القيم غير المعروفة (ولا يُرفض الطلب مطلقًا)، ويظل مفتاح التفعيل العام يتحكم في كل شيء: عندما يكون الضغط معطلًا على المستوى العام، لا يمكن للترويسة تشغيله. القيم:

القيمة	التأثير
off	لا يوجد ضغط لهذا الطلب.
default	ملف Default المشتق من اللوحة (يتجاهل الملف الشخصي النشط).
engine:<id>	محرك واحد عند تمكينه، مثل engine:rtk.
<combo>	مجموعة مسماة، تُطابق أولًا حسب الاسم (من دون حساسية لحالة الأحرف)، ثم حسب المعرّف.

تُعاد خطة الضغط المطبقة في ترويسة الاستجابة X-OmniRoute-Compression: <mode>; source=<source>، حيث تكون <source> واحدة من request-header أو routing-override أو active-profile أو auto-trigger أو default أو off.

واجهة API

# الحصول على إعدادات الضغط
curl http://localhost:20128/api/settings/compression

# تحديث إعدادات الضغط
curl -X PUT http://localhost:20128/api/settings/compression \
  -H "Content-Type: application/json" \
  -d '{"defaultMode":"stacked","autoTriggerMode":"stacked","autoTriggerTokens":32000}'

# معاينة حمولة RTK/stacked محددة
curl -X POST http://localhost:20128/api/compression/preview \
  -H "Content-Type: application/json" \
  -d '{"mode":"rtk","messages":[{"role":"tool","content":"npm test output here"}]}'

# عرض حزم مرشحات RTK
curl http://localhost:20128/api/context/rtk/filters

# اختبار RTK مباشرةً باستخدام بيانات وصفية اختيارية للأمر
curl -X POST http://localhost:20128/api/context/rtk/test \
  -H "Content-Type: application/json" \
  -d '{"command":"npm test","text":"FAIL tests/example.test.ts\nError: boom"}'

---

ما الذي تتم حمايته

يحافظ محرك الضغط دائمًا على:

• ✅ كتل التعليمات البرمجية (المسيّجة والمضمّنة)
• ✅ عناوين URL ومسارات الملفات
• ✅ بُنى JSON والبيانات المنظّمة
• ✅ المعرّفات والرموز التقنية المحمية
• ✅ التعبيرات الرياضية
• ✅ تعريفات استدعاءات الأدوات/الدوال
• ✅ مطالبات النظام (في الوضع الخفيف)

تعمل استعادة المخرجات الأولية في RTK على تنقيح مفاتيح API الشائعة، ورموز الحامل، ورموز Slack، ومفاتيح وصول AWS، وكلمات المرور، والرموز، والأسرار قبل حفظ أي شيء.

---

إحصاءات الضغط

يتضمن كل طلب مضغوط إحصاءات في سجلات الخادم:

{
  "originalTokens": 47200,
  "compressedTokens": 40120,
  "savingsPercent": 15.0,
  "techniquesUsed": ["collapseWhitespace", "dedupSystemPrompt"],
  "mode": "lite",
  "engine": "caveman",
  "compressionComboId": "coding-agent-stack",
  "durationMs": 0.8,
  "rtkRawOutputPointers": []
}

---

خارطة طريق المراحل

المرحلة	الأوضاع	الحالة
المرحلة 1	معطّل، خفيف	✅ تم الإصدار
المرحلة 2	قياسي، مكثف، فائق	✅ تم الإصدار
المرحلة 3	RTK، مكدّس، توليفات الضغط	✅ تم الإصدار
المرحلة 4	أنماط المخرجات، الوضع الفائق بمستوى SLM، إطار التقييم	✅ تم الإصدار
المرحلة 4C	ميزانية سياق تكيفية ("قرص الضبط") — محرك الحوسبة + API (contextBudget على PUT /api/settings/compression) + عناصر التحكم في الوضع/السياسة ضمن لوحة المعلومات	✅ تم الإصدار

---

شكر وتقدير

قواعد الضغط في الوضع القياسي مستوحاة من Caveman الذي أنشأه JuliusBrussee (⭐ 51K+) — المشروع واسع الانتشار المعروف بعبارة "لماذا نستخدم رموزًا كثيرة عندما تؤدي رموز قليلة الغرض". يفيد Caveman بتحقيق عدد أقل من رموز المخرجات بنسبة ~75%، ومتوسط توفير في مخرجات الاختبارات المعيارية بنسبة 65%، ونطاق توفير في المخرجات يبلغ 22-87%، وأداة لضغط المدخلات بنسبة ~46%.

وضع RTK مستوحى من RTK - Rust Token Killer الذي أنشأته RTK AI — وهو مشروع عالي الأداء لضغط مخرجات الأوامر الخاصة بالطرفية والبناء والاختبار وgit وتصفية مخرجات الأدوات. يفيد RTK بتحقيق توفير بنسبة 60-90%، بينما تُظهر جلسة العينة في README توفيرًا قدره ~80%.

---

أنظمة الضغط المتقدمة

إلى جانب الأوضاع القياسية السبعة، يتضمن OmniRoute عدة أنظمة ضغط متقدمة تعمل تلقائيًا استنادًا إلى السياق.

الضغط المراعي لذاكرة التخزين المؤقت

يدعم بعض المزوّدين (مثل Anthropic مع التخزين المؤقت للمطالبات) التخزين المؤقت للمطالبات، ما يتيح لهم تخزين أجزاء من المطالبة مؤقتًا لتقليل التكاليف وزمن الاستجابة. عند تمكين التخزين المؤقت، قد يؤدي الضغط المكثف فعليًا إلى الإضرار بالأداء لأنه يغيّر الرموز المخزنة مؤقتًا، ما يؤدي إلى إبطال ذاكرة التخزين المؤقت.

تحل الوحدة cachingAware.ts هذه المشكلة من خلال اكتشاف سياق التخزين المؤقت وتعديل استراتيجية الضغط وفقًا لذلك.

كيفية العمل

1. اكتشاف سياق التخزين المؤقت — يفحص نص الطلب بحثًا عن علامات cache_control
2. تحديد مزوّدي التخزين المؤقت — يتحقق مما إذا كان المزوّد المستهدف يدعم التخزين المؤقت
3. تعديل الاستراتيجية — يخفض aggressive/ultra إلى standard لدى مزوّدي التخزين المؤقت
4. تخطي مطالبة النظام — عادةً ما تُخزَّن مطالبات النظام مؤقتًا، لذا لا تضغطها
5. استخدام تحويلات حتمية — استخدم فقط التحويلات التي تنتج مخرجات متسقة

مثال على التعليمات البرمجية

import {
  detectCachingContext,
  getCacheAwareStrategy,
} from "@omniroute/open-sse/services/compression/cachingAware";

const body = {
  model: "anthropic/claude-sonnet-4.5",
  messages: [{ role: "user", content: "Hello" }],
  cache_control: { type: "ephemeral" }, // ← علامة ذاكرة التخزين المؤقت
};

const ctx = detectCachingContext(body, { provider: "anthropic" });
// → { hasCacheControl: true, provider: "anthropic", isCachingProvider: true }

const strategy = getCacheAwareStrategy("aggressive", ctx);
// → { strategy: "standard", skipSystemPrompt: true, deterministicOnly: true }

متى يُستخدم

يكون الضغط المراعي لذاكرة التخزين المؤقت مفعّلًا دائمًا — ولا يحتاج إلى أي إعداد. ولا يُفعّل إلا عندما:

• يحتوي الطلب على علامات cache_control
• يدعم المزوّد المستهدف التخزين المؤقت للمطالبات (Anthropic وOpenAI وما إلى ذلك)

التقادم التدريجي

تتراكم في المحادثات الطويلة جولات عديدة من الرسائل، لكن الجولات الأقدم تصبح أقل صلة. تعمل الوحدة progressiveAging.ts على تقليل تفاصيل الرسائل وفقًا لبُعد الجولة:

• الجولات الحديثة (0-3): تُحفظ حرفيًا (بكامل التفاصيل)
• الجولات المتوسطة (4-8): ضغط خفيف (تنظيف المسافات البيضاء والتنسيق)
• الجولات القديمة (9+): ضغط Caveman (إزالة الحشو والتلخيص)
• الجولات القديمة جدًا (20+): تُلخّص بصورة مكثفة أو تُحذف

مثال على التعليمات البرمجية

import { applyAging } from "@omniroute/open-sse/services/compression/progressiveAging";

const messages = [
  { role: "system", content: "You are a helpful assistant" },
  { role: "user", content: "What is 2+2?" },
  { role: "assistant", content: "4" },
  // ... 50 جولة أخرى ...
];

const { messages: aged, saved } = applyAging(messages, {
  verbatim: 3, // أول 3 جولات: حرفيًا
  light: 8, // الجولات 4-8: ضغط خفيف
  moderate: 20, // الجولات 9-20: ضغط caveman
  // الجولات 21+: تلخيص مكثف
});

// saved = عدد الرموز التي تم توفيرها

متى يُستخدم

التقادم التدريجي مفعّل دائمًا في وضعي aggressive وultra. وهو فعّال بصورة خاصة في:

• جلسات البرمجة طويلة الأمد
• المحادثات الممتدة لعدة أيام
• مهام سير العمل الوكيلة التي تتضمن استدعاءات كثيرة للأدوات

وضع مخرجات رجل الكهف

تُدرج الوحدة outputMode.ts تعليمات في موجه النظام لجعل النموذج نفسه ينتج مخرجات مضغوطة ومقتضبة (بأسلوب «رجل الكهف»).

كيفية عمله

بدلًا من ضغط المدخلات، يضيف هذا الوضع موجه نظام مثل:

"أجب بأقل عدد من الكلمات. تجاوز المجاملات. استخدم جملًا قصيرة."

يعمل هذا بصورة جيدة خصوصًا في:

• توليد الشيفرة (مخرجات أكثر اقتضابًا = رموز أقل)
• الأسئلة والأجوبة السريعة (لا حاجة إلى شروحات مسهبة)
• المعالجة الدفعية (زيادة الإنتاجية إلى أقصى حد)

متى يُستخدم

وضع مخرجات رجل الكهف اختياري — اضبطه عبر إعدادات الدمج:

{
  "strategy": "auto",
  "config": {
    "auto": {
      "outputMode": "caveman"
    }
  }
}

أنماط المخرجات (الكتالوج)

وضع مخرجات رجل الكهف أعلاه هو مسار النمط الفردي القديم. عمّمته المرحلة 4 إلى كتالوج من أنماط المخرجات القابلة للتركيب: OUTPUT_STYLE_CATALOG في open-sse/services/compression/outputStyles/catalog.ts. كل نمط عبارة عن تعليمة في موجه النظام تجعل النموذج نفسه ينتج مخرجات أقل تكلفة؛ ويمكن تمكين الأنماط معًا، وتُدرج حسب ترتيبها في الكتالوج.

النمط	id	ما يفعله	لغات التعليمات
نثر مقتضب	terse-prose	يحذف الحشو وأدوات التعريف والتحوط؛ ويحافظ على دقة المحتوى التقني. النص نفسه المستخدم في وضع مخرجات رجل الكهف القديم (تتم الإشارة إليه، ولا يُعاد إدخاله).	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
شيفرة أقل	less-code	تسلسل YAGNI: أصغر تغيير عملي، من دون تجريدات غير مطلوبة.	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
ذيل الحصان (مطوّر أول كسول)	ponytail	«أفضل شيفرة هي الشيفرة التي لم تُكتب قط»: إعادة الاستخدام > إعادة الكتابة، السبب الجذري > العَرَض، أقصر فرق عملي.	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
لدي اضطراب فرط الحركة وتشتت الانتباه (الفعل أولًا)	i-have-adhd	الفعل أولًا (الأمر/المسار/المقتطف قبل النثر)، خطوات مرقمة ومحدودة، خطوة تالية عملية واحدة، بلا مقدمة/تلخيص/خاتمة. مقتبس من ayghri/i-have-adhd (MIT).	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
صينية ويابانية وكورية مقتضبة (文言)	terse-cjk	أسلوب صيني كلاسيكي بالغ الاقتضاب.	zh (مقيّد بالإعدادات المحلية: لا يُعرض إلا عندما تكون اللغة المحددة هي zh)

يتضمن كل نمط ثلاثة مستويات للشدة — lite وfull وultra — وينتهي كل مستوى ببند الحدود المشترك، الذي يُبقي كتل الشيفرة ومسارات الملفات والأوامر وسلاسل الأخطاء وعناوين URL والمعرّفات كما هي حرفيًا.

كيفية عمل الإدراج

تحل الدالة applyOutputStyles() (open-sse/services/compression/outputStyles/apply.ts) التحديد بالرجوع إلى الكتالوج (تُستبعد المعرّفات غير المعروفة والأنماط غير المتوافقة مع الإعدادات المحلية، من دون اعتبار ذلك خطأ)، وتدمج التعليمات المحددة وفق ترتيب الكتالوج، وتُلحق بند الحدود مرة واحدة، ثم تضع النتيجة في مقدمة موجه النظام بعد علامة واحدة لضمان التكرار الآمن ([OmniRoute Output Styles]) — ولا تؤثر إعادة التطبيق في شيء. عندما تتوفر ترجمة للغة الطلب المكتشفة، تُدرج التعليمة المترجمة بدلًا من الإنجليزية.

كيفية التمكين

في لوحة التحكم: السياق ← الإعدادات ← الضغط — صف واحد لكل نمط، مع مفتاح تشغيل/إيقاف ومحدد للمستوى. برمجيًا، تحتفظ إعدادات الضغط بالتحديد على النحو الآتي:

{
  "outputStyles": [
    { "id": "i-have-adhd", "level": "full" },
    { "id": "less-code", "level": "lite" }
  ]
}

التوافق مع الإصدارات السابقة: لا يزال إعداد الدمج القديم outputMode: "caveman" يعمل، ويُطابق terse-prose، بحيث يكون مطابقًا بايتًا ببايت للإدراج القديم في كل لغة قديمة.

اختيار اللغة: عند تفعيل languageConfig.enabled، يختار autoDetect لغة أحدث رسالة للمستخدم (باستخدام الكاشف نفسه الذي تستخدمه محركات الإدخال)؛ ويؤدي إيقاف autoDetect إلى تثبيت defaultLanguage. عند الإيقاف ← الإنجليزية.

تُثبّت مصفوفة النمط × اللغة بواسطة tests/unit/compression/output-styles-i18n-matrix.test.ts: لا يمكن إصدار نمط جديد من دون ترجمة إلى pt-BR على الأقل (أو استثناء صريح يجري تتبعه)، ولا يمكن لنمط موجود أن يفقد إعدادًا محليًا بصمت. لإضافة نمط، راجع EXTENDING_COMPRESSION.md.

ضغط نتائج الأدوات

توفر الوحدة toolResultCompressor.ts 5 استراتيجيات ضغط متخصصة لنتائج الأدوات (استدعاءات الدوال ومخرجات الوكلاء ونتائج البحث وما إلى ذلك):

1. ضغط نتائج البحث — يزيل النتائج المكررة ويحتفظ بأفضل N نتائج
2. ضغط قراءة الملفات — يقتطع الملفات الكبيرة ويحافظ على الترويسات/عمليات الاستيراد
3. ضغط تنفيذ الشيفرة — يحتفظ فقط بالمخرجات الأساسية من stdout/stderr
4. ضغط استعلامات قواعد البيانات — يحد عدد الصفوف ويزيل البيانات الوصفية المسهبة
5. ضغط استجابات API — يزيل الحقول الفارغة ويكثف المصفوفات

متى يُستخدم

يكون ضغط نتائج الأدوات مفعّلًا دائمًا عند وجود استدعاءات للأدوات. لا يلزم أي إعداد.

خط الأنابيب المتراكم

يشغّل الوضع المتراكم عدة محركات بالتتابع — عادةً RTK أولًا (توفير بنسبة 60-90% في مخرجات الأدوات)، ثم Caveman (توفير إضافي بنسبة 30% في النص المتبقي). يحقق ذلك توفيرًا إجماليًا بنسبة 78-95%.

كيفية عمله

المدخلات (1000 رمز)
  → RTK (مرشح مدرك للأوامر) → 200 رمز
    → Caveman (إزالة الحشو) → 140 رمزًا
  → المخرجات (140 رمزًا، توفير بنسبة 86%)

متى يُستخدم

استخدم الوضع المتراكم من أجل:

• مهام سير العمل كثيفة استخدام الأدوات (البرمجة الوكيلة، البحث)
• المعالجة الدفعية الحساسة للتكلفة
• عندما تحتاج إلى أقصى توفير في الرموز

اضبطه عبر الدمج:

{
  "strategy": "auto",
  "config": {
    "auto": {
      "modePack": "stacked"
    }
  }
}

---

تجاوزات الضغط لكل توليفة

يمكنك تجاوز وضع الضغط العام لكل توليفة لضبط السلوك بدقة لحالات الاستخدام المختلفة:

{
  "id": "coding-combo",
  "strategy": "priority",
  "config": {
    "auto": {
      "weights": { "taskFit": 0.5 },
      "modePack": "quality-first"
    }
  },
  "compressionOverride": {
    "mode": "aggressive",
    "stackedPipelines": ["rtk", "caveman"],
    "preserveToolDefinitions": true
  }
}

يفيد ذلك في:

• توليفات البرمجة: استخدم وضع aggressive للجلسات الطويلة
• توليفات الأسئلة والأجوبة السريعة: استخدم وضع lite للاستجابات السريعة
• التوليفات كثيفة استخدام الأدوات: استخدم وضع stacked لتحقيق أقصى قدر من التوفير
• توليفات بيئة الإنتاج: استخدم وضع cache-aware لموفّري التخزين المؤقت

---

راجع أيضًا

• إعدادات البيئة — متغيرات بيئة الضغط
• دليل البنية — التفاصيل الداخلية لمسار الضغط
• دليل المستخدم — بدء استخدام الضغط
• ضغط RTK — عوامل تصفية RTK، ونموذج الثقة، وبوابة التحقق، واسترداد المخرجات الأولية
• محركات الضغط — Caveman وRTK والوضع المكدّس وواجهات API وMCP ولوحة المعلومات
• تنسيق قواعد الضغط — تنسيق حزمة القواعد بصيغة JSON
• حزم لغات الضغط — قواعد Caveman الخاصة بكل لغة