ملاحظة المؤلف: ننطلق من تصميم الوكيل الفائق لدى DeepSeek لتوضيح منطق توزيع النماذج بين الموجّه (router) والعامل (worker) في الأنظمة متعددة الوكلاء، وكيف تؤثر رموز قراءة ذاكرة التخزين المؤقت في تكلفة البنية.
عند بناء نظام برمجي متعدد الوكلاء، يخصص معظم الناس أقوى نموذج «للقائد»، ثم يتركون التنفيذ لنماذج أقل تكلفة. لكن تصميم الوكيل الفائق الذي نشره فريق DeepSeek Harness في نوفمبر 2026 يطرح فكرة معاكسة: نموذج منخفض التكلفة للموجّه، ونموذج قوي للعامل. يستخدم الموجّه المسؤول عن المحادثة وتوزيع المهام نموذجًا خفيفًا، بينما يستخدم العامل الذي يكتب الشفرة نموذجًا قويًا.
هذا المقال ليس مجرد إعادة سرد لخبر. سنحوّل هذه البنية إلى قرارات عملية لاختيار النماذج: ما القدرات التي يحتاجها الموجّه؟ وما القدرات التي يحتاجها العامل؟ وكيف نقدّر رموز قراءة ذاكرة التخزين المؤقت؟ ومتى نختار نموذجًا منخفض التكلفة؟ أما بيانات الاختبارات الواردة هنا، فتصفها DeepSeek نفسها بأنها نتائج «استرشادية» فقط، وسنوضح حدود الاستفادة منها.
الفائدة الأساسية: بعد قراءة المقال، ستتمكن من إعداد خطة لتوزيع النماذج حسب الأدوار في نظامك متعدد الوكلاء، وتقدير التكلفة التقريبية للخطة باستخدام حجم قراءات ذاكرة التخزين المؤقت.
أهم النقاط لتوزيع النماذج بين الوكلاء
يتكون تصميم DeepSeek من طبقتين. يعمل router في جلسة مستمرة، ويتولى التواصل مع المستخدم وتوزيع المهام وتتبع العلاقات بينها. أما worker فيتولى مهمة واحدة في كل مرة، وله سياق مستقل ونظيف، ولا يتحدث مع المستخدم مباشرةً، بل يرفع تقارير الحالة إلى router فقط. وبناءً على هذا التقسيم، يمكن استخدام الجدول التالي نقطةَ انطلاق لتوزيع النماذج.
| الدور | المسؤوليات الأساسية | هل يكتب الشفرة؟ | فئة النموذج الموصى بها | سبب الاختيار |
|---|---|---|---|---|
| router | الحوار وتوزيع المهام وتتبع العلاقات بينها | لا، ويمكن عدم منحه صلاحية الوصول إلى shell | خفيف ومنخفض التكلفة وسريع | عمله بسيط، لكن استدعاءاته متكررة، لذا فإن زمن الاستجابة وتكلفة الاستدعاء أهم |
| worker | استلام مهمة واحدة وإنجاز أعمال البرمجة | نعم | أقوى نموذج برمجة متاح حاليًا | جودة الشفرة تحدد جودة النتيجة النهائية مباشرةً |
| طبقة تصفية المحفزات | استبعاد الضوضاء من المحادثات الجماعية وإشعارات CI | لا | شفرة عادية في المرحلة الأولى، ونموذج صغير في الثانية | معظم الأحداث لا تحتاج إلى تمريرها إلى النموذج |
لماذا يُعكس توزيع النماذج بين الوكلاء المتعددين؟
ترى DeepSeek أن عنق الزجاجة في البرمجة بمساعدة الذكاء الاصطناعي انتقل من قدرات النموذج إلى انتباه الإنسان. فعادةً لا يستطيع الشخص متابعة أكثر من 3 إلى 5 جلسات نشطة للوكلاء في الوقت نفسه. وإذا زاد العدد، يصعب عليه معرفة أي جلسة تنتظر الموافقة، وأيها متعثرة، وأي وكيلين يعدّلان طلب السحب (PR) نفسه دون أن ينتبه.
لذلك لا تكمن قيمة router في «الذكاء»، بل في «توزيع المهام وتتبعها باستقرار». فهو لا يقسّم المهام، بل يكتفي بتوزيعها ومتابعتها، بخلاف النمط الشائع الذي يقسّم فيه «الوكيل الرئيسي» المهمة إلى خطوات.
وبما أن router لا يحتاج إلى استدلال عميق ولا يكتب الشفرة، فإن تخصيص أغلى نموذج له يعدّ إهدارًا. أما worker فهو الذي ينتج الشفرة فعليًا، وجودتها تحدد نجاح التسليم أو فشله، لذا ينبغي تخصيص ميزانية النموذج القوي له. هذا هو المقصود بـ«عكس اختيار النماذج»: كلما كان الدور أقرب إلى المستخدم كان نموذجه أخف، وكلما اقترب من الشفرة كان نموذجه أقوى.
ما القدرات التي يحتاجها كل من router وworker؟
يساعد تفصيل مسؤوليات كل دور إلى قدرات محددة على اختيار النموذج المناسب. ويمكن استخدام القائمة التالية مباشرةً لتقييم النماذج المرشحة.
| القدرة | متطلبات router | متطلبات worker | نصيحة للاختيار |
|---|---|---|---|
| اتباع التعليمات والتصنيف | عالية، لتحديد الجهة المناسبة للمهمة باستقرار | متوسطة | اختبر دقة توزيع المهام أولًا عند اختيار router |
| السياق الطويل والرجوع إلى التفاصيل | متوسطة، مع التوسع التدريجي انطلاقًا من ملخصات المعرّفات | عالية، إذ يحتاج إلى قراءة كميات كبيرة من الشفرة | راعِ نافذة السياق وقدرة worker على البحث في الشفرة |
| جودة توليد الشفرة | غير مطلوبة | الأولوية القصوى | لا تقتصد في ميزانية worker |
| زمن الاستجابة | أولوية عالية، لأنه يتخذ قرارات متكررة | متوسطة، يمكن أن تستغرق المهمة الواحدة وقتًا أطول | اختر نموذجًا سريعًا من فئة Flash لدور router |
| الحساسية لسعر الوحدة | عالية جدًا، بسبب كثرة عمليات قراءة ذاكرة التخزين المؤقت | متوسطة | يؤثر سعر وحدة router في التكلفة الإجمالية |
| استدعاء الأدوات | محدود، ويمكن الاستغناء عن صلاحية shell | متكرر، إذ يحتاج إلى التنفيذ والاختبار | استخدم حدود الصلاحيات لضبط كل دور |
هناك متطلب آخر يسهل إغفاله في router: يجب أن يمنعه التصميم من «القيام بالعمل بنفسه». فقد حرصت DeepSeek على عدم منحه صلاحية shell، لإلغاء إمكانية تنفيذه العمل مباشرةً. لذلك، عند اختيار نموذج لدور router، لا داعي للبحث عن نموذج «يجيد كل شيء»؛ بل تقبّل أنه «يوزّع المهام فقط».
تكلفة رموز قراءة ذاكرة التخزين المؤقت في توزيع النماذج بين الوكلاء
لا يكفي أن يكون الموجّه (router) منخفض التكلفة؛ فالنصيب الأكبر من تكلفة هذه البنية يأتي من رموز قراءة ذاكرة التخزين المؤقت. يعمل الموجّه في جلسة طويلة ويقرأ سياقًا مخزنًا مؤقتًا مرارًا، بينما تعمل عدة وكلاء منفّذين (workers) بالتوازي، ويقرأ كل منهم قدرًا كبيرًا من السياق. وتوضح بيانات اختبار DeepSeek حجم المشكلة:
| مقياس الاختبار | القيمة | التوضيح |
|---|---|---|
| عدد الرسائل في كل جولة | نحو 300 رسالة | منها نحو 20 طلب عمل فعليًا |
| متوسط وقت إنجاز الوكيل الفائق | 12.4 دقيقة | بلغ الوقت في الطرف الأبطأ 15.7 دقيقة |
| وقت الجلسة الواحدة الأساسي في الطرف الأبطأ | 29.5 دقيقة | استُخدم للمقارنة |
| حمل قرارات الموجّه | ارتفع من نحو قرار واحد إلى نحو 40 قرارًا في الدقيقة | انخفض وقت القرار الواحد من 6.4 ثانية إلى 1.6 ثانية |
| رموز قراءة ذاكرة التخزين المؤقت | 23.2 مليون | مع تفعيل تحسين pass-through |
| رموز قراءة ذاكرة التخزين المؤقت دون التحسين | 31.8 مليون | عندما لا يشترك الوكلاء المنفّذون في سلسلة الرسائل مباشرةً |
| تكلفة ذاكرة التخزين المؤقت | نحو 7 دولارات | وفق تسعير فئة Flash خارج أوقات الذروة لدى DeepSeek |
كيفية تقدير تكلفة توزيع النماذج بين الوكلاء بناءً على حجم قراءات ذاكرة التخزين المؤقت
يمكن تقسيم تكلفة التشغيل إلى ثلاثة أجزاء: عدد رموز Token المقروءة من ذاكرة التخزين المؤقت مضروبًا في سعر قراءتها، بالإضافة إلى رموز الإدخال غير الموجودة في الذاكرة المؤقتة مضروبةً في سعر الإدخال، ثم رموز الإخراج مضروبةً في سعر الإخراج. في بنية router-worker، يستحوذ الجزء الأول غالبًا على الحصة الأكبر من التكلفة، لذا فإن سعر قراءة الذاكرة المؤقتة هو أهم بند ينبغي مراقبته عند اختيار النموذج.
وباستخدام الأرقام الواردة في التقرير للحساب العكسي: تقابل تكلفة تبلغ نحو 7 دولارات قراءة 23.2 مليون رمز Token من الذاكرة المؤقتة، أي ما يعادل تقريبًا 0.3 دولار لكل مليون رمز. هذه قيمة تقريبية مستنتجة من أرقام التقرير، وليست سعرًا رسميًا؛ أما السعر الفعلي فيجب الرجوع فيه إلى قائمة الأسعار الحالية لمزوّد النموذج. وبمعرفة هذا المستوى التقريبي، يمكنك إدخال سعر قراءة الذاكرة المؤقتة لكل نموذج مرشح، لترى سريعًا كم ستتضاعف تكلفة العمل نفسه عند استخدام نموذج أعلى سعرًا.
يستحق تحسين pass-through الانتباه أيضًا. فبعد اشتراك worker في سلسلة المحادثة، تصل الأحداث الجديدة إليه مباشرةً دون أن يمررها router. وقد انخفض حجم قراءات الذاكرة المؤقتة من 31.8 مليون إلى 23.2 مليون، أي بنحو 27%. بعبارة أخرى، يمكن للتحسين على مستوى البنية أن يخفض الفاتورة مباشرةً، تمامًا مثل الانتقال إلى نموذج أقل تكلفة.
ثلاثة حدود يجب الانتباه إليها في بيانات المصدر
- مرحلة البرمجة محاكاة: استُخدمت في الاختبار أداة تستهلك الوقت فقط بدلًا من «كتابة الشفرة». لذا يقيس الاختبار سلوك الجدولة، لا جودة الشفرة، ولا يمكن الاستناد إليه لتحديد النموذج الأفضل للعمال.
- البيانات استرشادية فقط: أوضحت DeepSeek أن هذه الأرقام استرشادية وليست نتائج اختبار معياري صارم.
- المقارنة السعرية مع فئة Sonnet غير متسقة: يذكر ملخص التقرير تقديرًا بنحو 4.64 دولارات وفق أسعار فئة Sonnet، بينما يقول المتن إن الاستخدام نفسه سيكون «أعلى تكلفة بوضوح» في الفئة الأعلى سعرًا. تتعارض العبارتان، لذا لا يُنصح بالاستشهاد بهذه المقارنة المحددة قبل مراجعة المقال الأصلي لـ DeepSeek والتحقق منها.
دليل سريع لتوزيع النماذج في نظام متعدد الوكلاء
لتطبيق المنطق السابق في نظامك، يمكنك اتباع الخطوات التالية. لن نعرض شيفرة هنا؛ بل سنوضح جميع عناصر الإعداد ضمن النص، لتسهيل مقارنتها بإطار العمل الذي تستخدمه.
- حدّد الأدوار أولًا، ثم اختر النماذج: اكتب قائمة بجميع الأدوار التي تستدعي النماذج في نظامك، وميّز على الأقل بين الموجّه (router)، والعامل (worker)، ومرشّح المحفزات. وحدّد لكل دور ما إذا كان يكتب شيفرة أو يحتاج إلى أدوات.
- اجعل أسماء النماذج قابلة للتهيئة: أضف في الإعدادات معاملًا مستقلًا لكل دور، مثل
router_modelوworker_modelوfilter_model، بدلًا من تثبيت أسماء النماذج داخل شيفرة التطبيق. - اضمن التفويض من خلال بنية النظام: أزل أدوات التنفيذ، مثل shell، من الموجّه. أظهرت تجارب DeepSeek أن وكيل الجلسة الواحدة لم يفوّض أي مهمة في خمس محاولات باستخدام موجه محايد، واستغرقت أبطأ محاولة نحو نصف ساعة. وحتى عندما طلب الموجه التفويض صراحةً، قرر الوكيل في محاولة واحدة من أصل خمس أن المهمة صغيرة بما يكفي لينفذها بنفسه.
- رشّح الأحداث أولًا: استخدم شيفرة عادية لاستبعاد الأحداث غير المهمة بحسب مصدر الحدث وقائمة السماح، ثم أرسل الأحداث المتبقية إلى النموذج ليقيّمها وفق قواعد الفريق.
- سجّل حجم القراءة من ذاكرة التخزين المؤقت: سجّل في كل تشغيل ثلاث فئات من الرموز (Tokens): القراءة من ذاكرة التخزين المؤقت، والمدخلات غير المخزّنة مؤقتًا، والمخرجات. ثم استخدم المعادلة السابقة لحساب تكلفة التشغيل الواحد.
- قارن بين النماذج: أبقِ مجموعة المهام كما هي، وغيّر
router_modelفقط. راقب التغيّر في دقة توزيع المهام وزمن الاستجابة والتكلفة، ثم قرر ما إذا كان الانتقال إلى نموذج أقل فئة مناسبًا.
في الخطوتين 2 و6، تؤثر طريقة الربط مباشرةً في كفاءة التجربة. فإذا كان نموذجا الموجّه والعامل من مزودين مختلفين، فإن إدارة مفاتيح وإعدادات SDK منفصلة لكل منهما تعني تعديل مواضع كثيرة عند التبديل. باستخدام منصة واجهة موحّدة مثل APIYI apiyi.com، يمكنك استخدام مفتاح API واحد وصيغة طلبات واحدة متوافقة مع OpenAI، وتخصيص نماذج من مزودين مختلفين للموجّه والعامل بتغيير معامل model فقط، ما يخفض تكلفة تجارب المقارنة.
🚀 نصيحة للبدء السريع: عند اختبار نموذج أولي، جرّب ضبط معاملات نماذج الموجّه والعامل باستخدام المفتاح نفسه على APIYI apiyi.com، ثم شغّل مجموعة المهام نفسها وسجّل استهلاك الرموز. ارجع إلى قائمة النماذج الحالية على المنصة لمعرفة النماذج المتاحة، مثل نماذج DeepSeek من فئة Flash.
متى تختار نموذجًا منخفض التكلفة لأدوار الوكلاء المتعددين؟
النماذج منخفضة التكلفة ليست مناسبة لكل مهمة. يساعدك الجدول التالي على تحديد ما إذا كان بإمكانك استخدام نموذج أقل تكلفة لكل دور.
| طبيعة المهمة | التوصية | السبب | طريقة الوصول |
|---|---|---|---|
| يقتصر الدور على توزيع المهام ومتابعتها وفحص السياق المخزّن مؤقتًا | اختر نموذجًا سريعًا منخفض التكلفة | المهمة بسيطة، وتكلفة الاستدعاء وزمن الاستجابة هما العاملان الأكثر تأثيرًا في التجربة | APIYI apiyi.com أو API الرسمي لمزوّد النموذج |
| يتولى الدور توليد الشفرة البرمجية وتعديلها | اختر نموذجًا قويًا | جودة الشفرة تحدد جودة النتيجة النهائية | APIYI apiyi.com أو API الرسمي لمزوّد النموذج |
| يصل حجم قراءة البيانات المخزّنة مؤقتًا إلى عشرات الملايين، مع تكرار التشغيل يوميًا | أعطِ الأولوية لخفض تكلفة قراءة البيانات المخزّنة مؤقتًا | تزداد تكلفة ذاكرة التخزين المؤقت خطيًا مع عدد مرات التشغيل | احسب التكلفة وفق قائمة أسعار المزوّد |
| مهمة فردية خفيفة وغير متكررة | اكتفِ بالدفع حسب الاستخدام | حجم الاستخدام صغير ولا يبرر تكلفة زيادة تعقيد البنية | أي قناة تتيح الدفع حسب الاستخدام |
| مهام آلية متكررة وكثيفة الاستخدام للرموز | قيّم الاشتراكات الشهرية أو الخطط ذات الحدود المرتفعة | لا تعود التكلفة الإضافية لكل تشغيل ظاهرة في الفاتورة | بحسب شروط الاشتراك المحددة |
ولتوضيح الخيار في الصف الأخير، أشارت تقارير نُشرت في الفترة نفسها إلى أن سعر Claude Code Pass يبلغ 9.99 دولارًا شهريًا، وأنه يوفر حدودًا لمعدل الاستخدام تزيد بنحو 2 إلى 5 أضعاف للنماذج المفتوحة مثل Kimi K3.1 Pro وGLM 5.3 وDeepSeek V4.1 Flash، مع ثلاثة مستويات للحدود: كل 5 ساعات، وأسبوعيًا، وشهريًا. ورأت التقارير أيضًا أن النموذج السريع والرخيص أنسب تقنيًا للمهام التي تقتصر على اتخاذ قرارات التوجيه أو فحص السياق المخزّن مؤقتًا، وليس مجرد خيار أقل تكلفة. لكن هذه الخطط تقيدك بالنماذج المشمولة فيها؛ فإذا كان الـ worker يعتمد على نموذج خارج الباقة، فستحتاج إلى قناة وصول منفصلة.
مخاطر توزيع النماذج بين الوكلاء وحدوده
يعالج توزيع النماذج مسألتي التكلفة وتقسيم العمل، لكنه لا يحل التحديات القائمة في هذه البنية نفسها. وقد أقرت DeepSeek بوجود مشكلتين لم تُحلّا بعد: الأولى هي الذاكرة طويلة الأمد، إذ يظل الاحتفاظ بالسجل ذي الصلة بعد تشغيل النظام لأشهر صعبًا دون استنفاد نافذة السياق. والثانية هي حقن الموجهات؛ فكل وكيل يقرأ أحداثًا خارجية، مثل المحادثات الجماعية وتعليقات طلبات السحب (PR)، قد يتعرض للتلاعب. ونظرًا إلى اتصال وكيل التوجيه (router) والوكلاء العاملين (workers) عبر حلقة سحابية مشتركة، فقد ينشر مصدر أحداث مخترق التعليمات نظريًا إلى كل جهاز يتصل به النظام.
لهذا أثر مباشر على توزيع النماذج. فاستخدام نموذج منخفض التكلفة لوكيل التوجيه لا يعني التساهل في حمايته، لأنه أول من يتعامل مع الأحداث الخارجية. عند نشر النظام داخليًا في DeepSeek، شُغّلت الإجراءات الاستباقية أولًا في وضع يسجل «ما كان النظام سيفعله»، بدلًا من تنفيذها فورًا. ومن الأمثلة على ذلك استراتيجية «إعادة إنتاج الخلل وإصلاحه بصمت»: عندما يبلغ أحدهم عن خلل، يحاول الوكيل إعادة إنتاجه في الخلفية، ولا يقدّم طلب سحب إلا بعد تأكيد الخلل وإصلاحه، بينما تكون المحادثة ما زالت جارية. وإذا لم يستطع إعادة إنتاجه، فلا يرسل شيئًا. عند إطلاق نظام جديد، يكون من الأسلم مراقبة السجلات أولًا، ثم توسيع صلاحياته تدريجيًا.
إضافة إلى ذلك، تشير صفحة الشفرة الأولية لـ DSH Super Agent على GitHub بوضوح إلى أنها شفرة بحثية وليست منتجًا رسميًا. لا بأس بالاستفادة من أفكار تصميمها، لكن لا يُنصح بنشرها مباشرة في بيئة الإنتاج.
الأسئلة الشائعة FAQ
س1: ما المقصود بـ«قلب اختيار النماذج» في الأنظمة متعددة الوكلاء؟
يعني استخدام نموذج خفيف ومنخفض التكلفة للموجّه (router)، وأقوى نموذج متاح للعامل (worker). يتولى الموجّه المحادثة وتوزيع المهام ومتابعتها فقط، ولا يكتب الشفرة؛ أما العامل فيتولى البرمجة الفعلية. لذلك ينبغي تخصيص ميزانية النموذج الأقوى للعامل، لا لـ«القائد العام».
س2: ما الفرق بين بنية الموجّه والعامل ونمط «الوكيل الرئيسي الذي يقسّم المهام»؟
في نمط الوكيل الرئيسي، يقسّم الوكيل المهمة إلى خطوات، ما يتطلب قدرات استدلال أعلى. أما موجّه DeepSeek فلا يقسّم المهام إطلاقًا، بل يوزّعها ويتابعها فقط، لذا يمكنه استخدام نموذج أخف. لكن في المقابل، يجب أن يكون العامل قادرًا على إنجاز المهمة كاملةً بصورة مستقلة.
س3: متى أُعلن عن هذا التصميم؟ وهل يمكن استخدام DSH Super Agent مباشرةً؟
نُشرت التقارير ذات الصلة في 3 نوفمبر 2026. وDSH Super Agent نموذج أولي بحثي نُشر على GitHub مع المقال الذي يشرح التصميم. وقد أوضح الفريق رسميًا أنه ليس منتجًا مدعومًا، وأنه مناسب فقط لفهم البنية.
س4: هل يمكن تعليم وكيل واحد تفويض المهام باستخدام الموجهات وحدها؟
أظهرت اختبارات DeepSeek أن هذه الطريقة غير موثوقة: لم يحدث أي تفويض في خمس مرات تشغيل باستخدام موجه محايد، وحتى مع موجه يؤكد على التفويض، لم يُفوَّض العمل في إحدى مرات التشغيل. يتطلب التفويض الموثوق فصلًا بنيويًا، مثل فصل الجلسات وإزالة أدوات التنفيذ، بدلًا من كتابة موجهات أطول.
س5: كيف يمكن إعداد نماذج من مزودين مختلفين للموجّه والعامل بسهولة داخل النظام نفسه؟
المفتاح هو جعل اسم النموذج خيار إعداد مستقلًا لكل دور، مع توحيد طريقة الوصول:
1. سجّل في APIYI عبر apiyi.com واحصل على مفتاح API
2. اضبط معامل `model` لكل من الموجّه والعامل في إعدادات النظام
3. حافظ على صيغة الطلب كما هي، وغيّر اسم النموذج فقط لإجراء تجارب المقارنة
بهذه الطريقة، لا تحتاج إلى صيانة إعدادات SDK منفصلة لكل مزود. وتُحدد النماذج المتاحة وفق القائمة الحالية على المنصة.
س6: هل يمكن استخدام بيانات التكلفة الواردة في النص الأصلي مباشرةً لإعداد الميزانية؟
لا يُنصح بتطبيقها مباشرةً. فقد جرت محاكاة مرحلة البرمجة، والبيانات مجرد نتائج استرشادية، كما أن عرض مقارنة الأسعار مع فئة Sonnet غير متسق في مواضع مختلفة. الأفضل هو قياس حجم القراءة من ذاكرة التخزين المؤقت باستخدام مجموعة مهامك، ثم ضربه في سعر الوحدة الحالي. يمكنك تثبيت المهام على APIYI عبر apiyi.com، وتشغيلها مرة مع كل نموذج للحصول على بيانات تناسب حالتك.
س7: ما القيود المعروفة لهذه البنية؟
هناك ثلاث مشكلات رئيسية: تدهور الذاكرة بعد التشغيل لفترة طويلة، وخطر حقن الموجهات عند قراءة أحداث خارجية، وارتفاع حجم الرموز (Token) المقروءة من ذاكرة التخزين المؤقت، ما يرفع التكلفة بشكل ملحوظ عند استخدام نموذج مرتفع السعر. بالإضافة إلى ذلك، لا تتوفر حاليًا بيانات عن أداء نماذج محددة عند استخدامها في router، لذا يلزم اختبارها بنفسك.
أهم النقاط لتوزيع النماذج بين الوكلاء
- عكس اختيار النماذج: يستخدم router نموذجًا خفيفًا ومنخفض التكلفة، بينما يستخدم worker نموذجًا قويًا لكتابة الشفرة.
- عنق الزجاجة هو الانتباه: يستطيع الشخص عادةً متابعة 3 إلى 5 جلسات فقط، ويتولى router تنسيق التواصل بينها.
- التفويض يعتمد على البنية: إزالة أدوات التنفيذ من router أكثر موثوقية بكثير من تعديل الموجه.
- التخزين المؤقت هو الجزء الأكبر من التكلفة: بلغت قراءات التخزين المؤقت في جولة اختبار 23.2 مليون Token، لذا يُعد سعر الوحدة العامل الأهم.
- تحسين البنية يوفر المال أيضًا: أدى التمرير المباشر (pass-through) إلى خفض قراءات التخزين المؤقت بنحو 27%.
- تعامل مع البيانات بحذر: كانت كتابة الشفرة محاكاة، والنتائج استرشادية فقط، أما مقارنة الأسعار فتحتاج إلى التحقق.
- استخدم واجهة موحدة للتجربة: في APIYI على apiyi.com، يكفي تغيير المعامل
modelللمقارنة بين خطط التوزيع المختلفة.
الخلاصة
تعتمد فكرة توزيع النماذج بين الوكلاء المتعددين على استخدام نموذج منخفض التكلفة للموجّه (router) ونموذج قوي للعامل (worker). وأبرز نقاطها:
- التوزيع حسب المسؤوليات: استخدم نموذجًا سريعًا منخفض التكلفة للأدوار التي تكتفي بالتوجيه والمتابعة ولا تكتب الشفرة، ونموذجًا قويًا لأدوار البرمجة.
- حساب تكلفة ذاكرة التخزين المؤقت: تمثل رموز Token المقروءة من ذاكرة التخزين المؤقت التكلفة الرئيسية في هذه البنية، لذا قارن أسعار قراءتها أولًا عند اختيار النموذج.
- الحسم بالتجربة: بيانات المقال الأصلي مفيدة لتحديد الاتجاه، لكن القرار النهائي يحتاج إلى قياس التكلفة والأداء على مجموعة مهامك أنت.
ابدأ ببناء نموذج أولي من نوع router-worker باستخدام مجموعة صغيرة من المهام، واجعل اسم النموذج إعدادًا قابلًا للتغيير لكل دور. بعد ذلك، استبدل نموذج الموجّه تدريجيًا وراقب أثر التغيير في دقة التوجيه والتكلفة. ونوصي باستخدام APIYI عبر apiyi.com للوصول إلى نماذج من عدة مزودين بمفتاح واحد، وإجراء هذه المقارنة لتستند قراراتك إلى بياناتك الخاصة.
📚 المراجع
- DeepSeek’s Super Agent Harness: Fixing the Attention Bottleneck in AI Coding: شرح تصميم الوكيل الفائق من DeepSeek
- الرابط:
mindstudio.ai/blog/deepseek-super-agent-harness-design -
الوصف: يتناول بنية router-worker، وتجارب التفويض، وبيانات رموز Token في ذاكرة التخزين المؤقت، والمسائل التي لم تُحل بعد
-
Claude Code Pass Pricing: What’s in the $9.99/Month Plan: شرح خطة الاشتراك الشهري ذات الحدود المرتفعة
- الرابط:
mindstudio.ai/blog/claude-code-pass-pricing - الوصف: يناقش المفاضلة بين الدفع حسب الاستخدام والاشتراك الشهري في مهام الوكلاء المتعددين وسير العمل كثيف الاستخدام لرموز Token
الكاتب: الفريق التقني في APIYI
للتواصل التقني: يسعدنا تواصلكم معنا عبر الصفحة الرئيسية لـ APIYI على apiyi.com لمناقشة حلول توزيع النماذج بين الوكلاء المتعددين. ولمزيد من معلومات التكامل، يمكنكم زيارة مركز التوثيق على docs.apiyi.com
