في الأول من نوفمبر، نشر فريق DeepSeek Harness على منصة X مقالًا مطولًا بعنوان «استكشاف تصميم الوكيل الفائق»، يناقش فيه بنية الوكلاء الفائقين (Super-agent). وبعد نحو 15 ساعة من نشره، حصد المقال قرابة 1.3 مليون مشاهدة و9.4 آلاف إعجاب. يتناول المقال مفهومًا معماريًا، ولا يعرض ميزات منتج.
الخلاصة في جملة واحدة: يتولى النظام إدارة الجلسات، بينما يتعامل المستخدم مع نقطة دخول واحدة. يستقبل Router الطلبات ويوزع المهام من الواجهة الأمامية، وتنفذ جلسات Worker المهام بالتوازي في الخلفية، فيما يقتصر دور الإنسان على القرارات العليا والاعتماد النهائي.
لماذا يحتاج وكيل DeepSeek فائق الذكاء إلى تجاوز حدود الجلسة الواحدة؟
لا تزال معظم الوكلاء الأذكياء اليوم تعمل ضمن جلسة واحدة. وعندما يشغّل المستخدم عدة مهام في الوقت نفسه، عليه التنقل يدويًا بين الجلسات وتذكّر سياق كل منها. وتشير تجربة فريق DeepSeek Harness إلى أن الشخص يستطيع عادةً التعامل مع 3 إلى 5 جلسات نشطة في آن واحد. وهذا الرقم مستمد من تجربة الفريق، وليس إحصائية عامة، لكنه يكشف عن عنق زجاجة: المهمة الواحدة تحدّها قدرات النموذج، أما تعدد المهام فيحدّه انتباه الإنسان.
إضافة أدوات سطر الأوامر والموصلات الخارجية إلى وكيل محلي تتيح له استقبال رسائل من الخارج، لكنها لا تزيل ثلاثة قيود:
- الانتظار المتزامن: في حلقة ReAct التقليدية، التي تتناوب بين التفكير واستدعاء الأدوات، ينتظر الوكيل انتهاء العمليات الطويلة، ولا يستطيع خلالها الاستجابة لرسائل جديدة.
- تداخل السياقات: تختلط التفاصيل الوسيطة للمهام المختلفة في نافذة واحدة، ما يؤدي إلى تداخلها.
- الارتباط بالجهاز: بمجرد دخول الجهاز المحلي في وضع السكون أو انقطاع اتصاله، يتوقف الوكيل عن العمل.
لذلك تقترح المقالة فصل الوكيل عن أي جلسة منفردة يديرها المستخدم يدويًا، ليصبح كيانًا مستمرًا. ويجب أن يجمع بين الخصائص الأربع التالية، وهو ما لا تستطيع حلقة ReAct واحدة تحقيقه، بل يتطلب بنية نظام محيطة بها.
| خاصية الوكيل فائق الذكاء | ببساطة | الوحدة الأساسية المسؤولة |
|---|---|---|
| الاستمرارية | يتواصل عبر المراسلة الفورية وGitHub، ويبدو دائمًا أنه الوكيل نفسه | بنية من طبقتين، وتفاعل متعدد القنوات |
| الكفاءة | يستقبل تعليمات جديدة قبل انتهاء الأمر السابق، وينفّذ مهام متعددة بالتوازي | بنية من طبقتين، وتفاعل ثنائي الاتجاه ومتزامن |
| المبادرة | يراقب أحداث البيئة، ولا يتصرف إلا عندما يستدعي الحدث ذلك | التشغيل المدفوع بالأحداث |
| الديمومة | يبقى متصلًا دائمًا، ويتعافى تلقائيًا عند حدوث خلل | فصل موارد الحوسبة عن الحالة، وWatchdog |
تفكيك الوحدات الخمس للوكيل فائق الذكاء من DeepSeek
لنبدأ بالجدول العام. يستحق عمود «هل يمكن استخدامه الآن؟» اهتمامًا خاصًا، لأن المقال يتناول توجهًا تصميميًا، وليس بالضرورة وظائف جاهزة للاستخدام.
| الوحدة | المشكلة التي تحلها | الآلية الأساسية | هل يمكن استخدامها الآن؟ |
|---|---|---|---|
| البنية ذات الطبقتين | صعوبة الجمع بين استمرارية العمل وتنفيذ المهام بالتوازي | يتولى Router التفاعل وتوزيع المهام فقط، بينما ينفذها Worker في بيئة معزولة | يتضمن النموذج الأولي سير عمل مشابهًا، لكن التصميم الكامل يتطلب بناءه بنفسك |
| العمل الموجّه بالأحداث | لا يستجيب الوكيل إلا للأوامر، مع كثرة الأحداث غير المهمة | ترشيح سريع بالكود، ثم تقييم أدق بالنموذج، مع توجيه اشتراكات Thread مباشرةً | يمكن للنموذج الأولي مراقبة GitHub، مع خيار استخدام Feishu |
| اتصال ثنائي الاتجاه ومتعدد القنوات | المهام الطويلة تعطل المحادثة، والسجلات تزعج المستخدم | استدعاء الأدوات بشكل غير متزامن، وتحديد قواعد الرد حسب القناة | يدعم DeepSeek Harness المهام غير المتزامنة بالفعل، لكنها غير مفعّلة افتراضيًا |
| فصل موارد الحوسبة والحالة والبيئة | يتوقف العمل عند انقطاع اتصال الجهاز، مع صعوبة الوصول إلى بيئات أخرى | تشغيل دورة العمل في السحابة، وحفظ الحالة في قاعدة بيانات، وترك نقاط النهاية في مواقعها | لم يذكر المصدر الأصلي أنها متاحة للعموم؛ يتطلب الأمر بناءها بنفسك |
| Watchdog | تستمر العملية في العمل، لكن المهمة تتعطل أو تنحرف عن مسارها | جلسة مستقلة خارج النظام الرئيسي تفحصه دوريًا | لم يذكر المصدر الأصلي أنها متاحة للعموم؛ يتطلب الأمر بناءها بنفسك |
الوحدة الأولى: بنية Router/Worker ثنائية الطبقة في وكيل DeepSeek فائق الذكاء
للتوضيح: يشبه Router موظف الاستقبال في المطعم: يستقبل الطلبات ويوزعها فقط. أما Worker فيشبه فريق المطبخ، حيث يتولى كل طاهٍ إعداد طبق واحد.
إذا دخلت جميع الأحداث في جلسة واحدة، يظل السياق مترابطًا، لكن معدل المعالجة ينخفض. وإذا فُتحت جلسة جديدة لكل حدث، يرتفع مستوى التوازي، لكن السياق العام يضيع، وقد تنشأ فوضى عندما ترد جلسات متعددة على المستخدم كلٌّ على حدة. تفصل البنية ثنائية الطبقة بين المهمتين: يتولى Router، المتاح باستمرار، التفاعل مع المستخدم والتنسيق العام، ويمكنه حتى العمل من دون أداة Bash تمامًا. أما كل Worker فيعمل ضمن سياق معزول، ويتولى مهمة واحدة فقط، ولا يتحدث مباشرة إلى المستخدم، بل يرفع حالته إلى Router. والفكرة الأساسية في النص الأصلي هي أن الجلسات يجب أن تكون تفاصيل داخلية في تنفيذ النظام، لا عبئًا على المستخدم.
قد يبدو Router عرضة لأن يصبح عنق زجاجة، لكن المحفزات Trigger (الأحداث في البيئة) التي تصل خلال جولة استدلال واحدة تُضاف إلى قائمة انتظار، ثم تُدمج لمعالجتها في الجولة التالية. وعادةً ما تكون طلباته طويلة المدخلات وقصيرة المخرجات، وتُعالج الأحداث المدمجة بالتوازي خلال مرحلة Prefill، التي يعالج فيها النموذج المدخلات. لذلك لا يزداد زمن معالجة الطلب الواحد بالسرعة نفسها التي يزداد بها حجم الدفعة. ووفقًا لتجربة الفريق، غالبًا ما تكون مهام Router أبسط مما يُتصور، ويكفيها عادةً نموذج خفيف. عند التطبيق، يمكن البدء بتوصيل deepseek-v4.1-flash عبر APIYI · apiyi.com لتجربة Router ومراقبة دقته في توزيع المهام.
يؤثر Worker مباشرة في نتائج المهام وجودة الشفرة، لذلك يرى النص الأصلي أنه من الأفضل عادةً استخدام أقوى نموذج متاح. ويمكن مقارنة deepseek-v4-pro وclaude-opus-5-5 على المجموعة نفسها من المهام عبر APIYI · apiyi.com، ثم اختيار النموذج الافتراضي بناءً على النتائج.
الوحدة الثانية: آلية Trigger القائمة على الأحداث في وكيل DeepSeek فائق الذكاء
تشبيه: يتحقق حارس البوابة أولًا من الأسماء في القائمة، ويطلب من المدير الحكم على الحالات غير الواضحة؛ أما طلبات العملاء الحاليين فتوَّجه مباشرة إلى المسؤول الأصلي عنها.
لكي يعمل الوكيل بمبادرة منه، يجب أن يتحول مصدر مدخلاته الأساسي من الموجهات البشرية إلى أحداث البيئة المحيطة، مثل رسائل المحادثات الجماعية ونتائج التكامل المستمر (CI) وتعليقات مراجعة الشفرة. لكن تدفق الأحداث الفعلي مليء بالضوضاء، وإرسال كل حدث إلى نموذج لغة كبير لاتخاذ القرار سيستهلك قدرًا لا يُحتمل من الوقت والموارد الحاسوبية. لذلك يقترح المقال مستويين للترشيح:
- المسار السريع (Fast Path): تجري الشفرة فحوصًا محددة وفق قوائم السماح للمصادر أو المجموعات أو المستخدمين أو الروبوتات. ويمكن ضبط كل مصدر على «الاستجابة للطلبات الصريحة فقط» أو «اعتبار الأحداث مرشحة» أو «التجاهل».
- المسار البطيء (Slow Path): لا تُرسل إلى نموذج اللغة الكبير إلا الأحداث المرشحة التي اجتازت الترشيح السريع، ليقرر ما إذا كان سيتصرف بناءً على السياق والسياسة المكتوبة في الموجه.
ينقسم التوجيه أيضًا إلى مسار سريع وآخر بطيء. تشكّل الأحداث المتتابعة المرتبطة بطلب سحب (PR) واحد أو موضوع مراسلة فورية (IM) أو سلسلة بريد إلكتروني واحدة سلسلة أحداث (Thread). وبمجرد اشتراك عامل (Worker) فيها، تمرّر إليه الشفرة الأحداث اللاحقة مباشرة، دون الحاجة إلى قرار جديد من الموجّه (Router). وعندما يشترك عدة عمال في السلسلة نفسها، يتلقون الإشعارات ذاتها، ما يتيح لهم اكتشاف التعارضات وحلها بأنفسهم.
أما السياق فيُدار على غرار ذاكرة التخزين المؤقت: تُدرج المعلومات التي ستُستخدم قريبًا مباشرة في نافذة السياق (Inline)، بينما تبقى المعلومات الكاملة قليلة الاستخدام خارجها، مع الاحتفاظ بمرجع أو ملخص لها فقط (Spill). ويذكر المقال أيضًا العمل الاستباقي، مثل التحقق من التقويم أو إعادة إنتاج مشكلة (issue) في الخلفية. ولا تُقدَّم إلا النتائج المفيدة، فيما يُتخلّص من البقية، باستخدام موارد حاسوبية إضافية لتقليل انتظار المستخدم وحاجته إلى التدخل.
الوحدة الثالثة: التفاعل متعدد القنوات وثنائي الاتجاه الكامل في وكيل DeepSeek الفائق
للتوضيح: عند غلي الماء، لا تحتاج إلى الوقوف بجانب الغلاية؛ ستنبهك عندما يغلي، ويمكنك مواصلة الحديث مع الآخرين في هذه الأثناء.
يستبدل ReAct غير المتزامن الاستدعاءات التي تستغرق وقتًا باستخدام start() وstop(). تعود start() فورًا، بينما تعمل الأداة في الخلفية، وعند الانتهاء تُرسل النتيجة إلى المحادثة بوصفها حدثًا جديدًا. ويمكن للنموذج أيضًا استخدام stop() لإنهاء أمر استغرق وقتًا طويلًا. بهذه الطريقة، يمكن معالجة مدخلات المستخدم الجديدة بعد انتهاء خطوة الاستدلال الحالية. ويوضح المقال الأصلي أن DeepSeek Harness يطبق بالفعل آلية المهام غير المتزامنة، لكنها لم تُفعّل افتراضيًا بعد.
تعالج القنوات المتعددة مسألة «كيف نتواصل». ففي المراسلة الفورية، يجب أن تكون الرسائل خفيفة وقليلة الإزعاج، وألا تُرسل الإشعارات إلا عند الحاجة إلى قرار أو موافقة. ومن القواعد الصارمة التي اختبرها الفريق ألا تتجاوز كل إجابة 100 كلمة. أما GitHub والبريد الإلكتروني والمستندات فتحتاج إلى مخرجات منظمة وغنية بالمعلومات، مثل توضيح خلفية المشكلة والتغييرات ونتائج التحقق في طلب السحب (PR).
الوحدة الرابعة: فصل قدرات الحوسبة والحالة وبيئة التنفيذ في وكيل DeepSeek الفائق
للتوضيح: تُحفظ الملفات في أرشيف الشركة، فيستطيع الموظف مواصلة عمله حتى لو انتقل إلى مكتب آخر؛ وعندما يحتاج إلى أداة على جهاز معين، يرسل شخصًا لاستخدامها على ذلك الجهاز.
يفصل المقال هذه العناصر على خطوتين. أولًا، تعمل حلقة الوكيل داخل حاوية سحابية عديمة الحالة، بينما تُخزّن حالة المحادثة في قاعدة بيانات، فلا تؤثر إعادة تشغيل الحاوية أو استبدالها في استمرارية المهمة. ثانيًا، تبقى بيئة التنفيذ في مكانها، ويُثبّت على كل جهاز برنامج خفيف يعمل باستمرار في الخلفية (daemon)، لا يحفظ حالة المحادثة، بل يقتصر دوره على تنفيذ الأوامر وإرجاع النتائج.
يدعم هذا التصميم أيضًا مفهوم BYOM، أي توصيل جهازك الخاص بالوكيل السحابي. وبذلك لا تحتاج إلى مزامنة جميع التغييرات غير المودعة وبيانات الاعتماد المحلية مع السحابة. وعندما يعود الجهاز إلى الاتصال، يستطيع الوكيل السحابي مواصلة المهام التي تحتاج إلى التنفيذ عليه. وتتبنى مقالة Anthropic بعنوان “Decoupling the brain from the hands” فكرة فصل مشابهة، ويمكن الرجوع إليها للمقارنة.
الوحدة الخامسة: المراقبة الخارجية للوكيل الفائق من DeepSeek باستخدام Watchdog
للتقريب: مثل مشرف المناوبة الذي لا يشارك في العمل نفسه، بل يتفقد دوريًا من توقف عن العمل ومن انحرف عن المسار.
لا تظهر كثير من مشكلات الوكلاء في صورة انهيار؛ فقد تظل العملية نشطة بينما يكون النموذج عالقًا في حلقة لا تنتج شيئًا، وهو ما لا تكشفه فحوصات الحيوية التقليدية. يعمل Watchdog في جلسة مستقلة خارج النظام الرئيسي، وتحركه رسائل دورية. وهو يتعامل مع أعطال البنية التحتية، مثل أخطاء API وفشل استعادة الحالة، ويستخدم النموذج أيضًا لتقييم ما إذا كان كل عامل يحرز تقدمًا فعليًا. ويمكن للمسؤولين سؤاله بلغة طبيعية عن سبب الفشل، أو تكليفه بتعديل الموجهات وقواعد التشغيل أثناء عمل النظام.
ما الذي يمكن تجربته حاليًا في النموذج الأولي للوكيل الفائق من DeepSeek؟
المستودع المصاحب هو github.com/deepseek-ai/dsh-superagent-prototype، ويستخدم ترخيص MIT. وعند جمع البيانات في 2026-11-02، كان لديه 8,636 نجمة و863 نسخة متفرعة. وهو نموذج بحثي أولي، وليس منتجًا رسميًا من DeepSeek، ولا يطابق بالضرورة النسخة الداخلية للفريق أو التنفيذ الكامل الموصوف في المقال. كما أن بعض التصاميم المذكورة تمثل توجهات مستقبلية لم تُنفّذ في النموذج الأولي.
النموذج الأولي وكيل برمجي استباقي يعمل على مستودع GitHub واحد، ومُجمّع في حزمة لـ DeepSeek Harness. يراقب GitHub، ويمكن ربطه اختياريًا بـ Feishu؛ وعندما يُكلَّف بمهمة، ينشئ عنصر عمل وينجزه في جلسة ومجلد خاصين به، ثم يعود للرد في المحادثة الأصلية، مثل تقديم طلب سحب (PR). وتوجد أيضًا لوحة ويب تعرض العناصر التي تحتاج إلى تدخل بشري.
ماذا تكشف مجموعتا تجارب الوكيل فائق الذكاء من DeepSeek؟
البيانات التالية أوردها المقال الرسمي نفسه. استخدمت التجارب أعباء عمل اصطناعية وبيئة مبسطة، ويؤكد المؤلف أن النتائج استرشادية فقط. في المجموعة الأولى، شمل كل تشغيل نحو 300 رسالة، منها نحو 20 طلب عمل، وتكرر اختبار كل تصميم 5 مرات. وحُوكيت أعمال البرمجة بأدوات تستهلك الوقت فقط، لذا تقيس التجربة الجدولة والتنسيق، لا جودة تنفيذ المهام.
في الجدول، تشير p50 إلى الوقت الذي اكتمل خلاله نصف المهام، بينما تشير p95 إلى الوقت الذي اكتمل خلاله 95% منها. أما cache-read tokens فهي رموز القراءة من ذاكرة التخزين المؤقت، أي إعادة استخدام السياق المخزن مباشرة دون معالجته مجددًا، والعدد هنا هو إجمالي جميع الجلسات.
| التصميم | p50 (دقيقة) | p95 (دقيقة) | cache-read tokens / تشغيل |
|---|---|---|---|
| الوكيل الفائق (Super-agent) | 12.4 | 15.7 | 23.2M |
| من دون التمرير المباشر للاشتراكات (Pass-through) | 12.6 | 15.5 | 31.8M |
| جلسة واحدة + وكلاء فرعيون (موجه محايد) | 20.4 | 29.5 | 6.1M |
| جلسة واحدة + وكلاء فرعيون (موجه يعطي الأولوية للتفويض) | 13.8 | 29.0 | 10.8M |
مع الموجه المحايد، لم يستدعِ النموذج أي وكيل فرعي في التشغيلات الخمسة. أما مع موجه يعطي الأولوية للتفويض، فقد فوّض العمل في 4 تشغيلات من أصل 5، وفي المرة المتبقية رأى أن المهمة صغيرة ونفذها بنفسه. يوضح ذلك أن أداء الجلسة الواحدة، تحت عبء العمل هذا، يعتمد كثيرًا على الموجه وتقدير النموذج في اللحظة نفسها، بينما تجعل البنية ذات الطبقتين التفويض جزءًا ثابتًا من النظام. والثمن واضح أيضًا: يستهلك الوكيل الفائق رموز قراءة مخبأة أكثر بكثير مقابل وقت إنجاز أقصر وأكثر استقرارًا.
عند إزالة التمرير المباشر، لم يتغير وقت الإنجاز تقريبًا، لكن عدد قرارات الموجّه (Router) زاد بنحو 30%، ورموز القراءة من ذاكرة التخزين المؤقت بنحو 37%. لذا، في عبء العمل هذا، لم يسرّع التمرير المباشر الإنجاز، بل كان دوره الأساسي تقليل العبء على الموجّه.
اختبرت المجموعة الثانية قدرة طبقة الموجّه وحدها تحت الضغط: استخدم الموجّه نموذجًا حقيقيًا، بينما استخدم العامل (Worker) نموذجًا محاكيًا، مع زيادة معدل وصول المحفزات (Trigger) التي تتطلب قرارًا من الموجّه تدريجيًا.
| معدل الوصول (مرة/دقيقة) | متوسط حجم الدفعة | زمن الطلب الواحد | متوسط زمن الاستدلال لكل قرار |
|---|---|---|---|
| نحو 1 | 1.0 | 2.5 ثانية | 6.4 ثانية |
| نحو 40 | 2.8 | 3.9 ثانية | 1.6 ثانية |
قد يتضمن القرار الواحد عدة طلبات إلى نموذج لغة كبير، لذا قد يزيد الوقت المحسوب لكل قرار على زمن الطلب الواحد. وتدعم هذه البيانات استنتاجًا مفاده أن الدمج التلقائي يمكن أن يرفع معدل المعالجة الفعلي لـ Router عند تدفق الأحداث بكثافة. لكنها لا تثبت تحقق النتيجة نفسها في بيئة إنتاج حقيقية، ولا تكشف عن جودة المهام أو الأداء عبر مستودعات شيفرة مختلفة.
أربعة أسئلة مفتوحة حول وكيل DeepSeek الفائق
تقر المقالة بأن الأسئلة التالية لا تزال بلا إجابة، وينبغي أخذها في الحسبان عند تقييم خطة التطبيق:
- كيف تتوسع البنية؟ عند ازدياد حجم المهام وترابطها، لا يزال من غير الواضح ما إذا كان ينبغي تقسيم Router إلى أجزاء، وما درجة التفصيل المناسبة، ومتى ينبغي أن تتواصل مكونات Worker مباشرةً. كلما زاد التقسيم، زاد التوازي، لكن قلت الذاكرة والسياق المشتركان. وتظل الذاكرة طويلة الأمد أيضًا من أبرز عوائق التوسع.
- كيف يُستخدم النظام دون جلسات؟ لا تزال هناك حاجة إلى أساليب تفاعل جديدة لتحديد كيفية عرض المهام، وكيفية تدخل المستخدم في التفاصيل المهمة دون مقاطعة العمل الجاري في الخلفية.
- حدود السياق وA2A: يشير مصطلح A2A، أو التواصل بين الوكلاء، عمومًا إلى التواصل والتعاون بين وكلاء مختلفين. ومع توسع المنظومة، يصبح إعداد الوكيل الفائق (Super-agent) قرارًا بشأن السياق الذي يُشارك والسياق الذي يُعزل. ولا تزال كيفية التعاون الآمن عبر حدود الصلاحيات دون إجابة.
- الأمان والخصوصية: هذا هو الجانب الذي يجب تقييمه أولًا. تتلقى حلقة العمل السحابية أحداثًا خارجية باستمرار، بينما تحتفظ نقاط النهاية بشيفرة خاصة وبيانات اعتماد محلية. وإذا اختُرق الخادم أو نجح هجوم حقن الموجهات، أي تعليمات خبيثة مخبأة داخل المدخلات، في اختراق حلقة العمل، فقد يُستولى على جميع نقاط النهاية المتصلة. وترى المقالة أن الوكيل يحتاج إلى طريقة «تتيح له استخدام بيانات الاعتماد دون رؤيتها».
قائمة الحد الأدنى لتطبيق الوكيل فائق الذكاء من DeepSeek في فريق صغير
الترتيب التالي اقتراح منا يستند إلى أفكار المقال الأصلي، وليس خطة رسمية. ابدأ بتجربة داخل مستودع واحد ونطاق موثوق، وأجّل تقسيم Router إلى أجزاء في الوقت الحالي.
الخطوة الأولى: فصل Router عن Worker
- البرمجيات: أنشئ نقطة دخول Router تعمل باستمرار، دون إتاحة أداة Bash لها. خصّص Worker مستقلاً لكل مهمة، بسياق ومجلد عمل منفصلين، بحيث يرسل نتائجه إلى Router فقط.
- النموذج: استخدم نموذجاً خفيفاً لـ Router ونموذجاً أكثر قدرة لـ Worker، واضبط كلاً منهما بشكل مستقل لتسهيل استبداله.
- دور الفريق: تعامل مع Router فقط، وحدد نطاق المهام، واستجب لطلبات اتخاذ القرار، واعتمد النتائج النهائية.
الخطوة الثانية: إضافة فلترة Trigger
- البرمجيات: اضبط قائمة سماح للمصادر وسياسة بثلاثة مستويات، واربط طلبات السحب (PR) وموضوعات المراسلة الفورية (IM) بسلاسل محادثة (Thread). مرّر الأحداث اللاحقة التي تم الاشتراك فيها مباشرة إلى Worker.
- النموذج: أجرِ تقييماً دلالياً للأحداث المرشحة فقط، لتحديد ما إذا كان يلزم اتخاذ إجراء أو تشغيل Worker جديد.
- دور الفريق: وضّح شروط اتخاذ الإجراء في الموجه، وراجع دورياً عينات من حالات التشغيل الخاطئ والأحداث التي لم تُشغّل النظام رغم استيفائها الشروط، ثم عدّل قائمة السماح والسياسات.
الخطوة الثالثة: إضافة Watchdog
- البرمجيات: انشره خارج النظام الرئيسي، وشغّله برسائل مجدولة للتحقق من مشكلات البنية التحتية، مثل أخطاء API وفشل استعادة الحالة.
- النموذج: اقرأ سجلات تقدم Worker لتحديد ما إذا كان يحرز تقدماً فعلياً، أو عالقاً، أو انحرف عن الهدف.
- دور الفريق: حدد صلاحيات الإصلاح الممنوحة لـ Watchdog، ووافق على تعديلاته للموجه وقواعد التشغيل، وراجع أسباب الإخفاقات.
من اليوم الأول، تجنب وضع بيانات اعتماد بيئة الإنتاج مباشرة في سياق النموذج، واضبط الصلاحيات وفق مبدأ الحد الأدنى. يمكن تأجيل استدعاء الأدوات غير المتزامن وفصل موارد الحوسبة حتى تستقر الخطوات الثلاث الأولى، وتظهر فعلياً مشكلات في التعطل أو خروج الأجهزة عن الاتصال.
اختيار نماذج وكيل DeepSeek فائق الذكاء وتقدير التكلفة
يعرض الجدول التالي نماذج APIYI · apiyi.com كما ظهرت عند الاستعلام في 2026-11-02، بوحدة دولار لكل مليون token. يُرجى الرجوع إلى قائمة النماذج على المنصة لمعرفة النماذج والأسعار، وإلى لوحة التحكم لمعرفة الرسوم الفعلية.
| النموذج | الإدخال | الإخراج | قراءة ذاكرة التخزين المؤقت |
|---|---|---|---|
| deepseek-v4.1-flash | 0.3 | 1.2 | 0.006 |
| deepseek-v4-flash | 0.44 | 1.32 | 0.01408 |
| deepseek-v4-pro | 1.32 | 3.96 | 0.043996 |
| claude-opus-5-5 | 4 | 20 | 0.2 |
جميع الأرقام التالية تقديرات وليست نتائج قياس فعلي، وقد حُسبت وفق الأسعار المعلنة. نفترض أن كل استدعاء يستهلك 20 ألف token للإدخال وألفَي token للإخراج، دون احتساب التخزين المؤقت في الوقت الحالي:
- تبلغ تكلفة
deepseek-v4.1-flashنحو $0.0084، وdeepseek-v4-proنحو $0.0343، وclaude-opus-5-5نحو $0.12. - عند تشغيل الموجّه (Router) مرة واحدة باستخدام
deepseek-v4.1-flash، والعامل (Worker) مرة واحدة باستخدامdeepseek-v4-pro، تبلغ التكلفة الإجمالية نحو $0.0427. أما استخدامclaude-opus-5-5لكليهما فيكلف نحو $0.24، أي ما يقارب 5.6 أضعاف التكلفة الأولى. - عند تشغيل 20 مجموعة يوميًا بهذا الاستهلاك، تبلغ تكلفة الدمج بين النموذجين نحو $0.85، مقابل نحو $4.8 عند استخدام
claude-opus-5-5في جميع الحالات. عمليًا، غالبًا ما يحتاج العامل إلى أكثر من جولة استدعاء، لذا أعد الحساب باستخدام عدد الـtokens المسجل في سجلاتك.
تحتاج الأنظمة التي تعمل لفترات طويلة أيضًا إلى حساب تكلفة قراءة ذاكرة التخزين المؤقت بشكل منفصل. وفقًا لتقدير يستند إلى 23.2 مليون token قُرئت من الذاكرة المؤقتة في التجربة، تبلغ التكلفة نحو $0.14 إذا حُسبت جميعها بسعر deepseek-v4.1-flash، ونحو $1.02 بسعر deepseek-v4-pro، ونحو $4.64 بسعر claude-opus-5-5. هذه الأرقام مرجع تقريبي لحجم التكلفة فقط؛ إذ لم تكشف التجربة عن توزيع الـtokens بين الطبقات، كما أنها لا تشمل رسوم الإدخال والإخراج.
من الأفضل جعل نموذجي الموجّه والعامل قابلين للتعديل عبر الإعدادات. من خلال APIYI · apiyi.com، يمكنك التبديل بين هذه النماذج باستخدام مفتاح API واحد. قيمة base_url للواجهة المتوافقة مع OpenAI هي https://api.apiyi.com/v1، وعند التبديل يكفي غالبًا تغيير اسم النموذج، مما يسهل مقارنة الجودة والتكلفة باستخدام مجموعة المهام نفسها. لكن السعر ليس سوى نصف المعادلة؛ فاختيار النموذج الافتراضي للعامل يعتمد أيضًا على معدل نجاح المهام وحجم إعادة العمل.
يستند تقدير الرسم أعلاه إلى الأسعار الافتراضية في قائمة نماذج APIYI · apiyi.com. استخدم استهلاكك الفعلي من الـtokens عند إعداد ميزانيتك.
الأسئلة الشائعة حول الوكيل الفائق من DeepSeek
س1: هل هذا نموذج جديد؟
لا. المقال يناقش بنية نظام الوكلاء، ويركز على كيفية تنظيم النظام المحيط للجلسات والأحداث والحالة والمراقبة، ولم يُعلن فيه عن نموذج جديد.
س2: هل يمكن للمطورين استخدامه مباشرة؟
لا يمكن استخدام الوحدات الخمس كميزات جاهزة. يمكن حاليًا تجربة النموذج الأولي البحثي أو بناء نظام خاص وفق الأفكار الواردة في المقال. أما التطبيق الحالي الوحيد المذكور صراحةً في المقال الأصلي فهو آلية المهام غير المتزامنة في DeepSeek Harness، وهي غير مفعّلة افتراضيًا.
س3: هل dsh-superagent-prototype منتج رسمي؟
لا. يوضح ملف README أنه مخصص للرجوع إليه في الأبحاث فقط، وليس منتجًا رسميًا من DeepSeek، كما أنه لا يمثّل النسخة الداخلية أو التطبيق الكامل الموصوف في المقال.
س4: هل استخدام عدة وكلاء أكثر تكلفة؟
في هذه التجارب، كان عدد رموز القراءة من ذاكرة التخزين المؤقت أكبر بالفعل: بلغ 23.2 مليونًا للوكيل الفائق، مقابل 6.1 إلى 10.8 ملايين لحل الجلسة الواحدة، وذلك مقابل وقت إنجاز أقصر وأكثر استقرارًا. وتعتمد التكلفة الإجمالية الفعلية أيضًا على النماذج المستخدمة وحجم المهام. ويساعد استخدام نموذج خفيف في Router وتفعيل المرور المباشر لـ Thread على التحكم في التكاليف.
س5: كيف يمكن الوصول إلى هذه النماذج من داخل الصين؟
يمكنك التسجيل عبر APIYI · apiyi.com والحصول على مفتاح API، مع رصيد مجاني للاختبار للمستخدمين الجدد. بعد ذلك، غيّر قيمة base_url في العميل إلى العنوان المذكور أعلاه، وأدخل اسم النموذج من الجدول في معلمات النموذج. تدعم نماذج DeepSeek وClaude هذه نقطتي النهاية chat وmessages، ويُنصح بالتحقق منها بحجم طلبات صغير قبل الإطلاق.
الخلاصة
تكمن قيمة مقال DeepSeek عن الوكيل فائق الذكاء في تطبيق أفكار هندسة الأنظمة التقليدية على الوكلاء الذكيين. وهذه أبرز النقاط التي يمكنك استخلاصها:
- تحديد المشكلة: عند تنفيذ مهمة واحدة، تقل حاجة النموذج إلى التدخل البشري، أما في المهام المتعددة، فأصبح انتباه الإنسان هو عنق الزجاجة.
- خمس وحدات: البنية ثنائية الطبقة، والتشغيل القائم على الأحداث، والقنوات المتعددة ثنائية الاتجاه، وفصل الحوسبة عن الحالة وبيئة التشغيل، وآلية المراقبة (Watchdog). وتدعم هذه الوحدات أربع خصائص: الاستمرارية والكفاءة والمبادرة والديمومة.
- حدود الأدلة: التجربتان تستندان إلى أحمال عمل اصطناعية أبلغ عنها الكاتب بنفسه، لذا لا تصلح نتائجهما إلا للاستئناس عند التصميم.
- ترتيب التنفيذ: ابدأ بفصل الموجّه (Router) عن العامل (Worker)، ثم أضف تصفية المحفّزات (Trigger)، وأخيرًا آلية المراقبة (Watchdog)، مع إعطاء حدود الأمان الأولوية في كل مرحلة.
لا تحتاج إلى حسم اختيار النماذج من البداية. يمكنك إجراء مقارنة محدودة على مجموعة المهام نفسها عبر APIYI · apiyi.com، ثم تحديد التكوين المناسب بناءً على معدل النجاح والتكلفة.
تخلّص أولًا من دور «الموجّه البشري»، ثم فكّر في إضافة المزيد من الوكلاء.
الكاتب: الفريق التقني في APIYI
للتواصل التقني: يسعدنا تواصلك معنا عبر الصفحة الرئيسية لموقع APIYI، وللمزيد من المعلومات يمكنك زيارة مركز التوثيق على docs.apiyi.com
