توجيه وكلاء البرمجة بين النماذج: متى يكون فعالاً؟

تأثير التوجيه متعدد النماذج على وكيل البرمجة

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

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

أربعة مصطلحات، مُعرّفة لمرة واحدة. الموجّه (router) يختار نموذجاً لكل طلب. البوابة (gateway) هي الوكيل (proxy) الذي يمر الطلب من خلاله، وقد يقوم بالتوجيه أو لا يقوم به. ذاكرة المطالبة المؤقتة (prompt cache) هي قيام المزود بتخزين البادئة المعالجة لمطالبتك، بحيث يتم محاسبتك على الطلب اللاحق الذي يكرر تلك البادئة بجزء بسيط من سعر الإدخال. ذاكرة KV المؤقتة (KV cache) هي نفس المفهوم داخل خادم تشغله بنفسك.

لماذا يتم توجيه حركة مرور الدردشة بشكل جيد بينما لا يحدث ذلك مع حركة مرور الوكيل

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

دورة الوكيل ليست طلباً واحداً. تعليمات واحدة مثل "أصلح الاختبار الفاشل" تتحول إلى ما بين عشرين إلى ستين استدعاء لواجهة برمجة التطبيقات (API). يعيد كل استدعاء إرسال المحادثة بأكملها: مطالبة النظام (system prompt)، وتعريف كل أداة، وكل ملف قرأه الوكيل، وكل مخرجات أمر رآها. السياق ينمو فقط. بحلول الاستدعاء الثلاثين، يمكن أن تصل البادئة المكررة إلى عشرات الآلاف من الرموز (tokens)، بينما المحتوى الجديد حقاً في كل استدعاء هو بضع مئات فقط.

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

ذاكرة التخزين المؤقت للمطالبات خاصة بكل نموذج، والوكيل يعيش بداخلها

تُسعّر شركة Anthropic قراءة ذاكرة التخزين المؤقت بـ 0.1 من سعر الإدخال الأساسي، وكتابة ذاكرة التخزين المؤقت لمدة خمس دقائق بـ 1.25 من ذلك السعر. هذه هي الأسعار المعلنة في القوائم، اعتباراً من أغسطس 2026.

[
  {
    "label": "Opus 5",
    "uncached_input_usd": "5.00",
    "cache_read_usd": "0.50"
  },
  {
    "label": "Sonnet 5",
    "uncached_input_usd": "2.00",
    "cache_read_usd": "0.20"
  },
  {
    "label": "Haiku 4.5",
    "uncached_input_usd": "1.00",
    "cache_read_usd": "0.10"
  }
]

اقرأ السلسلة الثانية مقابل الأولى، عبر الصفوف بدلاً من الأعمدة. تبلغ تكلفة قراءة ذاكرة التخزين المؤقت على Opus 5 0.50 دولاراً لكل مليون رمز (token). بينما يبلغ سعر الإدخال غير المخزن مؤقتاً على Haiku 4.5، وهو أرخص نموذج مدرج، 1.00 دولاراً. لذا، فإن إعادة قراءة بادئة جاهزة (warm prefix) على أغلى نموذج تكلف أقل لكل رمز إدخال مقارنة بقراءة نفس البادئة وهي باردة (cold) على أرخص نموذج.

تلك المقارنة الواحدة تكسر معظم خطط التوجيه. فالموجّه الذي ينقل العمل "لأسفل" إلى فئة أقل يقارن أسعار القائمة. لكن الوكيل في منتصف الجلسة لا يدفع سعر القائمة للنموذج الذي يستخدمه بالفعل. إنه يدفع سعر قراءة ذاكرة التخزين المؤقت، والذي يقع بالفعل تحت سعر الإدخال غير المخزن مؤقتاً للنموذج الرخيص.

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

التكلفة الحقيقية لتبديل النموذج أثناء الجلسة

لنفترض وجود جلسة ذات بادئة ثابتة (stable prefix) بحجم 40,000 رمز (token)، وهو حجم عادي بمجرد أن يقرأ الوكيل بضعة ملفات. أدناه تكلفة البادئة لدورة واحدة، محسوبة بناءً على الأسعار المعلنة أعلاه.

[
  {
    "label": "Opus 5, cache warm",
    "prefix_cost_usd": "0.020"
  },
  {
    "label": "Sonnet 5, turn after switch",
    "prefix_cost_usd": "0.100"
  },
  {
    "label": "Opus 5, cache re-warmed",
    "prefix_cost_usd": "0.250"
  }
]

البقاء على Opus 5 مع ذاكرة تخزين مؤقت نشطة يكلّف 0.020 دولاراً مقابل بادئة تلك الدورة. أما الدورة الأولى بعد توجيه الطلب إلى Sonnet 5 فتكلف 0.100 دولاراً، لأن Sonnet لا تملك إدخالاً لهذه البادئة وتضطر لكتابة واحد جديد. والعودة إلى Opus 5 تكلّف 0.250 دولاراً، لأن الإدخال الأصلي انتهت صلاحيته أثناء غياب الجلسة.

بذلك، تدفع رحلة الذهاب والعودة تكلفة عمليتي كتابة في ذاكرة التخزين المؤقت لتجنب عمليتي قراءة. في المقابل، وفّر هذا التبديل دورة واحدة من المخرجات بسعر Sonnet بدلاً من سعر Opus. يوضح قسم التفاصيل أدناه الرحلة كاملة: تظهر الوفورات بأجزاء من السنت، بينما تظهر تكلفة ذاكرة التخزين المؤقت بعشرات السنتات. هذه التكلفة الإضافية أكبر بأكثر من عشرة أضعاف، وهي تزداد مع طول البادئة بينما لا تزداد الوفورات.

Opus 5, warm read     40,000 x $0.50 / 1e6  = $0.020
Sonnet 5, cache write 40,000 x $2.50 / 1e6  = $0.100   (1.25 x $2 base)
Opus 5, cache write   40,000 x $6.25 / 1e6  = $0.250   (1.25 x $5 base)

800 x ($25 - $10) / 1e6 = $0.012

تنسيقات استدعاء الأدوات ليست متطابقة عبر المزودين

الوكيل (Agent) هو حلقة استدعاء أدوات، لذا فإن تنسيق استدعاء الأداة مهم بطريقة لا تظهر أبداً في المحادثات العادية. تُرجع واجهة برمجة تطبيقات Messages الخاصة بـ Anthropic كتلة محتوى tool_use وتتوقع كتلة tool_result في المقابل. أما واجهات برمجة التطبيقات المتوافقة مع OpenAI فتُرجع مصفوفة tool_calls حيث يكون function.arguments عبارة عن سلسلة نصية مشفرة بصيغة JSON بدلاً من كائن متداخل. تقوم البوابة (Gateway) بالترجمة بين التنسيقين، وتكون الترجمة نظيفة في الاستدعاءات العادية.

تظهر المشكلات عند الحواف. فاستدعاءات الأدوات المتوازية، حيث يُصدر النموذج عدة استدعاءات في استجابة واحدة، تُمثَّل بشكل مختلف ولا يتم دعمها بشكل متطابق في كل مكان. إن فرض المخطط الصارم (Strict schema enforcement) هو ميزة خاصة بكل مزود، لذا فإن النموذج الذي يضمن وسيطات صالحة للمخطط على نقطة نهاية واحدة يميل فقط نحو وسيطات صالحة على نقطة أخرى. يرى الوكيل الفرق كـ "نتيجة أداة" تحتوي على خطأ في التحليل (parse error)، ثم يحاول إصلاحه عبر استهلاك دورة إضافية. تُحاسَب دورات الإصلاح هذه بالسعر الكامل للبادئة (prefix price)، لذا يظهر عدم تطابق التنسيق في الفاتورة كما يظهر في سجل المحادثة.

تحتاج نقاط النهاية المستضافة ذاتياً إلى تهيئة هذا الأمر بشكل صريح. يتطلب خادم vLLM المتوافق مع OpenAI استخدام --enable-auto-tool-choice مع --tool-call-parser مطابق لعائلة النموذج (hermes، وmistral، وllama3_json وغيرها)، بالإضافة إلى قالب محادثة يتعامل مع رسائل دور الأداة. وثائق vLLM واضحة بشأن حدود هذا المسار: مع tool_choice="auto" وبدون قيود صارمة على المخطط، يستخرج vLLM استدعاءات الأدوات من النص الخام، لذا قد تكون الوسيطات أحياناً مشوهة أو تنتهك مخطط معاملات الدالة. اختيار المحلل (parser) الخاطئ لنموذجك هو خطأ في التهيئة يظهر على شكل وكيل لا يمكنه استدعاء الأدوات، وهو أمر يستحق المعرفة قبل توجيه حركة المرور (traffic) إليه. إن الفرق بين Ollama و vLLM لخدمة النماذج ذاتياً مهم هنا، لأن كلاً منهما يتيح استدعاء الأدوات بشروط مختلفة.

تغيير سلوك التراجع (Fallback) في منتصف المهمة دون ظهور خطأ

تعد ميزة التوجيه الاحتياطي (Fallback routing) هي الميزة الأكثر عرضة للتفعيل عن طريق الخطأ. يتم إعداد البوابة (Gateway) لإعادة المحاولة باستخدام نموذج آخر عندما يعيد النموذج الأول خطأ تجاوز حد المعدل (rate limit) أو خطأ من فئة 5xx، ثم يضع النموذج الفاشل في حالة تهدئة (cooldown) لعدة ثوانٍ. هذا السلوك مثالي تماماً عند التعامل مع حركة مرور الدردشة، ولكن داخل مهمة وكيل (agent task) طويلة، يعني هذا أن النصف الثاني من مهمتك قد نُفِّذ بواسطة نموذج لم تختره.

لا يوجد أي تقرير يشير إلى حدوث ذلك. المهمة لا تفشل، والوكيل لا يرسل تحذيراً، وتكون حالة الخروج (exit status) ناجحة. ما تحصل عليه هو مهمة كُتبت خطتها بواسطة نموذج، بينما نُفِّذت التعديلات بواسطة نموذج آخر، مما يؤدي إلى تغير في النبرة ومجموعة العادات في منتصف العمل. الإشارة الموثوقة الوحيدة هي حقل model في سجل طلبات البوابة أو في البيانات الوصفية للاستجابة؛ لذا إذا كنت تستخدم ميزات التراجع، فقم بتسجيل هذا الحقل لكل طلب واقرأه عندما تفاجئك النتيجة. إن تصحيح السلوك دون معرفة النموذج الذي أنتجه يستهلك وقتاً أكثر مما وفره التراجع نفسه.

يقع ضغط السياق (context compression) في الفخ نفسه. يقوم العديد من الوكلاء بتلخيص السجل الطويل عن طريق استدعاء نموذج صغير. إذا كان هذا الاستدعاء يحمل نموذجاً مختلفاً أو system prompt مختلفاً، فإنه يكتب إدخال ذاكرة تخزين مؤقت (cache entry) خاصاً به ولا يقوم بتحديث ذاكرة الجلسة الرئيسية، مما يجعل الدورة الكاملة التالية تتحمل تكلفة بادئة باردة (cold prefix). لقد وفّر الضغط الرموز (tokens) ولكنه فقد ذاكرة التخزين المؤقت.

التكاليف الإضافية للتوجيه حقيقية، لكن زمن الانتقال ليس هو مصدر الضرر

تضيف الموجهات (Routers) عملاً إضافياً لكل طلب، ومن المهم أن نكون دقيقين بشأن حجم هذا العمل. تشير DigitalOcean إلى أن نموذج Arch-Router الخاص بها يحلل غرض التوجيه في حوالي 51 مللي ثانية، بدقة توجيه تصل إلى 93.17% وفقاً لتقييمهم الخاص. هذه أرقامهم هم، ومستمدة من قياساتهم ومعاييرهم، وليست أرقامنا ولا نتيجة عالمية. إذا أخذنا هذه الأرقام كما هي، فإن الاستنتاج مطمئن: 51 مللي ثانية عبر أربعين استدعاء للوكيل (agent) تعادل حوالي ثانيتين إضافيتين لمهمة تستغرق عدة دقائق.

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

على خادم تديره بنفسك، تنطبق القاعدة نفسها مع مساحة أقل للمناورة. المكافئ المحلي للتخزين المؤقت للمطالبات (prompt cache) هو التخزين المؤقت للبادئات (prefix caching) في ذاكرة KV cache، والتي توجد في ذاكرة وحدة معالجة الرسومات (GPU). استضافة نموذجين على وحدة GPU واحدة يقسم تلك الذاكرة بينهما، مما يجعل كل نموذج يحتفظ بذاكرة KV cache أصغر ويقوم بطرد البادئات في وقت أقرب. لذا، يمكن أن يؤدي التوجيه بين نموذجين محليين إلى تقليل معدل نجاح التخزين المؤقت لكليهما في آن واحد. إذا كنت تحدد مواصفات العتاد لهذا الغرض، فإن الذاكرة والمعالج اللذان يحتاجهما وكيل البرمجة فعلياً على خادم VPS هو نقطة البداية الأكثر فائدة من الموجه.

قاعدة اتخاذ القرار

• وجّه الطلبات عبر مزودين مختلفين لضمان التوافر. عندما يكون البديل هو فشل الطلب، فإن أي تكلفة هي تكلفة مبررة. ثبّت خيار النسخ الاحتياطي (fallback) على نموذج يستخدم نفس تنسيق استدعاء الأدوات (tool call format) لضمان استمرار حلقة عمل الوكيل، وسجّل النموذج الذي خدم كل طلب.
• وجّه الطلبات عبر فئات مختلفة (tiers) عند حدود المهام فقط. اختيار نموذج Haiku لإعادة التسمية ونموذج Opus لإعادة الهيكلة هو قرار جيد إذا اتُخذ مرة واحدة قبل بدء الجلسة. لكنه قرار سيء إذا اتُخذ في الجولة الثلاثين من تلك الجلسة.
• ثبّت نموذجاً واحداً لكل جلسة في أي عمل يتضمن وكلاء (agentic). قيمة الجلسة تكمن في ذاكرتها المؤقتة (warm cache). تعامل مع تبديل النماذج كما تتعامل مع مسح تلك الذاكرة، لأن هذا هو ما يحدث فعلياً.
• وجّه الوكلاء الفرعيين بحرية. الوكيل الفرعي الذي يبدأ بسياق جديد وصغير لا يملك ذاكرة مؤقتة ليخسرها، لذا يمكنه العمل على أي نموذج يناسب مهمته. هذا هو المكان الوحيد داخل الوكيل الذي تكون فيه عملية التوجيه غير مكلفة تقريباً.

لبناء هذا النظام، تقوم البوابة (gateway) بالعمل المطلوب: استخدام أسماء مستعارة للنماذج وقوائم احتياطية صريحة. يبدو إعداد LiteLLM proxy بحدوده الدنيا كما يلي.

model_list:
  - model_name: agent-primary
    litellm_params:
      model: anthropic/claude-opus-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: agent-standby
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks: [{"agent-primary": ["agent-standby"]}]
  num_retries: 2
  cooldown_time: 30

وجّه الوكيل إلى agent-primary وسيبقى على نموذج واحد حتى يصبح ذلك النموذج غير متاح. كلا المدخلين يقعان لدى نفس المزود، لذا لا يتغير تنسيق استدعاء الأدوات عند تفعيل الخيار الاحتياطي. أنت تقبل هنا تغييراً في الفئة (tier) في تلك اللحظة، وهي مقايضة تستحق العناء فقط لأن البديل هو فشل الطلب. هذا هو توجيه التوافر (availability routing) دون إقحام توجيه التكلفة، وهو المزيج الذي تريده معظم وكلاء البرمجة. البناء الكامل، بما في ذلك المفاتيح والميزانيات، مشروح في تشغيل بوابة LiteLLM ذاتية الاستضافة على خادم VPS الخاص بك، وقد تعمدت هذه التدوينة عدم تكراره.

عندما يتفوق نموذج واحد مُختار بعناية على أي موجّه (Router)

التوجيه هو حل لتباين صعوبة الطلبات. يمتلك وكيل البرمجة تبايناً أقل مما يبدو، لأن الجزء المكلف من كل استدعاء هو البادئة (prefix) نفسها، بغض النظر عما يطلبه الاستدعاء. بمجرد أن تصبح البادئة هي الجزء المهيمن، يتقلص الفرق بين فئتك الرخيصة وفئتك الغالية ليقترب من الفرق في أسعار المخرجات، والمخرجات تشكل جزءاً صغيراً من رموز (tokens) الوكيل.

لذا، الخيار الافتراضي الصادق هو نموذج واحد، يتم اختياره مرة واحدة، مع تفعيل التخزين المؤقت (caching) واستخدام TTL (زمن البقاء) طويل بما يكفي لتغطية الفجوات عندما تتوقف لقراءة فرق (diff). توفر Anthropic ميزة الكتابة في الذاكرة المؤقتة لمدة ساعة واحدة بتكلفة تعادل 2 ضعف مدخلات الأساس، وهو ما يغطي تكلفته بعد قراءتين، وغالباً ما يكون هذا خياراً أفضل من أي موجّه. اختر الفئة بعناية باستخدام مقارنة مباشرة بين Opus وSonnet وHaiku، وإذا كانت الفاتورة لا تزال تمثل مشكلة، قلل التكلفة باستخدام الميزانيات والسياقات الأصغر كما هو موضح في التحكم في تكاليف وكيل الذكاء الاصطناعي على خادم VPS بدلاً من التبديل أثناء الجلسة.

استخدم التوجيه عندما تكون الطلبات مستقلة وقصيرة، أو عندما تبدأ الوكلاء الفرعيون بسياقات جديدة. ثبّت النموذج عندما تكون لديك جلسة واحدة طويلة تؤدي مهمة واحدة. معظم أعمال وكيل البرمجة تندرج تحت النوع الثاني، ولهذا السبب فإن الموجّه الذي يوفر المال في منتج الدردشة الخاص بك سيكلفك المال هنا بصمت. إذا لم تستقر على الوكيل نفسه بعد، فإن مقارنة Claude Code مقابل Cursor وCodex وCopilot تغطي كيفية تعامل كل منها مع اختيار النموذج، وبعضها يتخذ هذا القرار نيابة عنك.

FAQ

هل يؤدي تبديل النماذج في منتصف الجلسة فعلياً إلى فقدان ذاكرة التخزين المؤقت للمطالبة (prompt cache)؟

نعم. تعتمد ذاكرة التخزين المؤقت للمطالبة على قيمة تجزئة (hash) لبادئة المطالبة وتُخزّن لكل نموذج على حدة، لذا فإن أي طلب يُرسل إلى نموذج مختلف سيُقارن بمخزن لم يسبق له رؤية تلك البادئة. لن يجد النظام شيئاً وسيدفع تكلفة الإدخال الكاملة غير المخزنة، ثم سيدفع تكلفة كتابة في الذاكرة إذا كانت خاصية التخزين المؤقت مفعّلة. كما أن العودة إلى النموذج الأصلي لا تستعيد الإدخال السابق، لأن فترة الصلاحية الافتراضية البالغة خمس دقائق تكون قد انتهت عادةً بحلول ذلك الوقت. تحقق من الحقلين cache_read_input_tokens وcache_creation_input_tokens في كائن استخدام الاستجابة: الجولة التي تقرأ صفراً من الرموز المخزنة (cached tokens) في جلسة طويلة هي العرض الدال على ذلك.

هل توجيه الطلبات إلى نموذج أرخص يقلل التكلفة دائماً للوكيل (agent)؟

فقط عندما لا توجد ذاكرة تخزين مؤقت دافئة (warm cache) لتفقدها. تكلفة قراءة الذاكرة في Anthropic تعادل 0.1 من تكلفة الإدخال الأساسي، مما يجعل تكلفة القراءة من نموذج Opus 5 أقل من تكلفة الإدخال غير المخزن في Haiku 4.5. بمجرد أن تحتوي الجلسة على بادئة مخزنة كبيرة، يصبح النموذج الحالي هو الخيار الأرخص من حيث الإدخال. يكون التوجيه مجدياً عندما يكون السياق جديداً وصغيراً: في بداية المهمة، أو في وكيل فرعي يحمل فقط السياق الذي يحتاجه.

لماذا تصرف الوكيل الخاص بي بشكل مختلف في منتصف المهمة؟

تحقق مما إذا كان قد تم تفعيل آلية التبديل الاحتياطي (gateway fallback). إن حدوث تجاوز لمعدل الطلبات (rate limit) أو خطأ 5xx في النموذج الأساسي يجعل البوابة (gateway) تعيد المحاولة عبر النموذج الاحتياطي وتضع النموذج الأساسي في حالة تبريد (cooldown) لبضع ثوانٍ، لذا يتم تنفيذ بقية المهمة في مكان آخر. لا ينتج عن هذا أي خطأ أو تحذير، وتظل المهمة تُبلغ عن نجاحها. الحقل model في سجل طلبات البوابة أو بيانات الاستجابة الوصفية هو السجل الموثوق الوحيد، لذا قم بتسجيله لكل طلب إذا كنت تستخدم آليات التبديل الاحتياطي.

هل تعمل استدعاءات الأدوات (tool calls) بنفس الطريقة عبر جميع المزودين؟

ليس تماماً. تستخدم واجهة برمجة تطبيقات الرسائل في Anthropic كتل محتوى tool_use وtool_result، بينما تستخدم واجهات برمجة التطبيقات المتوافقة مع OpenAI مصفوفة tool_calls يكون فيها function.arguments عبارة عن سلسلة نصية مشفرة بصيغة JSON. تترجم البوابة الحالات الشائعة بشكل جيد، لكن استدعاءات الأدوات المتوازية وفرض المخطط الصارم (strict schema enforcement) تختلف باختلاف المزود. في خادم vLLM المستضاف ذاتياً، يجب عليك ضبط --enable-auto-tool-choice و--tool-call-parser بما يتوافق مع عائلة نموذجك، وتشير وثائق vLLM إلى أنه بدون قيود صارمة على المخطط، يستخرج الخادم استدعاءات الأدوات من النص الخام، لذا قد تكون الوسائط غير صحيحة التنسيق في بعض الأحيان.

ما هي المدة التي يجب أن أضبط عليها زمن بقاء الذاكرة المؤقتة (cache TTL) لجلسة برمجة؟

استخدم فترة الصلاحية الافتراضية البالغة خمس دقائق للعمل المستمر، وخيار الساعة الواحدة عندما يقرأ الإنسان الفروقات (diffs) بين الجولات. تسعّر Anthropic تكلفة الكتابة لمدة خمس دقائق بـ 1.25 ضعف الإدخال الأساسي، وتكلفة الكتابة لمدة ساعة بضعفين، مقابل تكلفة قراءة تعادل 0.1. يتم استرداد تكلفة الكتابة لمدة خمس دقائق بقراءة واحدة، وتكلفة الكتابة لمدة ساعة بقراءتين، لذا في أي جلسة تتوقع العودة إليها ومتابعة العمل، عادة ما تكون تكلفة فترة الصلاحية الأطول أقل من تكلفة دفع ثمن بادئة باردة (cold prefix).