مقارنة DeepSeek Super-agent مع Claude Code وCodex: 6 أبعاد لتحديد ما إذا كان الاختلاف في النموذج أم نظام الجدولة

ملاحظة الكاتب: بعد أن أتاحت DeepSeek النموذج البحثي الأولي لـ Super-agent كمصدر مفتوح، ما الفروق الحقيقية بينه وبين Claude Code وCodex؟ يحلل هذا المقال ستة أبعاد عبر ثلاث طبقات من القدرات: النموذج، وأدوات البرمجة، ونظام التنسيق، ويقدم توصيات تناسب أساليب العمل المختلفة.

في 31 أكتوبر 2026، نشر فريق DeepSeek Harness مقالًا تقنيًا بعنوان «استكشاف تصميم Super-agent: نحو أنظمة وكلاء أكثر استقلالية»، وأتاح النموذج الأولي المصاحب dsh-superagent-prototype كمصدر مفتوح على GitHub الرسمي بموجب ترخيص MIT. وسرعان ما أثارت بنية التنسيق ذات الطبقتين: موجّه دائم التشغيل وعمّال مستقلون نقاشًا واسعًا، وتناولت وسائل إعلام منها Bloomberg وصحيفة South China Morning Post الخبر في سياق المنافسة مع Claude Code وCodex.

هذا ليس مقالًا آخر ينحاز إلى طرف تحت شعار «من سيحل محل من». فالمستودع نفسه يوضح أن المشروع نموذج بحثي أولي، كما أن Claude Code وCodex لم يعودا منذ فترة مجرد أداتين تعملان في جلسة واحدة. عند مقارنة DeepSeek Super-agent مع Claude Code وCodex، فإن السؤال الأجدر بالطرح هو: هل تنبع الاختلافات من النموذج الأساسي، أم من نظام تنسيق الوكلاء؟

الفائدة الأساسية: بعد قراءة المقال، ستعرف الطبقة التي ينتمي إليها كل منها، وستفهم المعنى العملي لأولويات تصميم DeepSeek، وستتمكن من اختيار مجموعة الأدوات المناسبة لأسلوب عملك.

لمحة سريعة عن أبرز معلومات DeepSeek Super-agent

لنبدأ بتوضيح الحقائق: DeepSeek Super-agent ليس نموذجًا أساسيًا جديدًا، بل بنية نظام وكلاء مبنية حول نموذج لغة كبير. وما أُعلن عنه حاليًا مجرد نموذج بحثي أولي، وليس منتجًا تجاريًا رسميًا.

حتى 2 نوفمبر، أظهرت صفحة المشروع نحو 8900 نجمة و898 عملية Fork، ولا تزال هذه الأرقام تتغير. ومن المهم التأكيد أن عدد النجوم يعكس مستوى الاهتمام فقط، ولا يدل على عدد مرات التثبيت الفعلية أو معدل نجاح البرمجة.

ما المشكلة التي يسعى DeepSeek Super-agent إلى حلها؟

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

الرقم من 3 إلى 5 جلسات هو تقدير مستند إلى خبرة فريق DeepSeek، وليس إحصائية على مستوى القطاع. لكنه يوضح اتجاه البحث وراء Super-agent: الهدف ليس جعل النموذج أكثر ذكاءً، بل نقل جدولة الجلسات ومعالجة الأحداث وإدارة السياق من الإنسان إلى النظام. ولهذا حدد الفريق أربع خصائص مستهدفة: الاستمرارية (Continuous)، والإنتاجية العالية (Productive)، والمبادرة (Proactive)، والقدرة على الاستمرار (Persistent). وهذه أهداف تصميمية، ولا تعني أن النموذج الأولي حققها جميعًا بالفعل.

مقارنة DeepSeek Super-agent مع Claude Code وCodex: ثلاثة مستويات يجب التمييز بينها

قبل مناقشة «من الأقوى؟»، يجب الإقرار بأن الثلاثة لا تنتمي تمامًا إلى مستوى المنتجات نفسه. فـClaude Code وCodex منتجان للوكيل وأدوات مخصصة للبرمجة، بينما يركز Super-agent على بناء آلية تشغيل تحيط بالوكيل، وتظل متاحة باستمرار، وتستجيب للأحداث وتنسق المهام المتعددة. أما الاستدلال الفعلي وتنفيذ الأدوات فيعتمدان على النموذج الأساسي وDeepSeek Harness.

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

فيما يلي مقارنة للآليات المتاحة علنًا حاليًا عبر 6 جوانب. لاحظ أن الجدول يقارن «الآليات»، وليس ترتيب الأداء في ظروف متطابقة.

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

قدرات Claude Code متعددة الوكلاء ليست ضعيفة

وفقًا لوثائق Anthropic الرسمية، يمتلك الوكلاء الفرعيون (Subagents) في Claude Code نوافذ سياق مستقلة، ويمكن تخصيص تعليمات نظام لهم، وتقييد الأدوات المتاحة لهم، واختيار نماذج مختلفة لكل منهم. كما يمكنهم إجراء الأبحاث وتنفيذ بعض المهام بالتوازي في الخلفية. وتذهب ميزة فرق الوكلاء التجريبية (Agent Teams) خطوة أبعد: إذ تضم قائدًا وعدة أعضاء، يعمل كل منهم في جلسة Claude Code مستقلة، مع قائمة مهام مشتركة وإمكانية تبادل الرسائل مباشرةً. هذه الميزة معطّلة افتراضيًا، وتحذّر الوثائق الرسمية من أنها تزيد أعباء التنسيق واستهلاك الرموز (Tokens).

أما فيما يتعلق بالاستجابة للأحداث والتشغيل المستمر، فيمكن لـclaude-code-action الاستجابة لإشارات @claude في تعليقات المشكلات وطلبات السحب (PR)، وتحويل المشكلة إلى طلب سحب عند ضبط الإعدادات المناسبة. وتتيح Channels، المتوفرة كمعاينة بحثية، إدخال رسائل الدردشة وطلبات Webhook ونتائج التكامل المستمر (CI) إلى جلسة قيد التشغيل عبر MCP، لكنها تتطلب بقاء الجلسة نشطة. وهناك أيضًا أمر /loop داخل الجلسة، ومهام مجدولة على تطبيق سطح المكتب وفي السحابة؛ ويمكن لبعض المهام السحابية مواصلة العمل بعد إيقاف الجهاز المحلي. لذا فإن فكرة أن «Claude Code لا يستطيع سوى انتظار المدخلات» أصبحت قديمة.

تعدد المهام في Codex: فرّق بين المنتج وواجهة API

يمكن لـ Codex استخدام Git Worktree لإنشاء عدة مجلدات عمل مستقلة للمشروع نفسه، بحيث تعدّل جلسات مختلفة فروعًا مختلفة بالتوازي. ويحلّل Codex Cloud الشفرة وينفّذ التعديلات ويجري الاختبارات في مساحات عمل معزولة، مع استمرار المهام السحابية حتى بعد إغلاق الجهاز المحلي. كما تدعم منظومة ChatGPT/Codex المهام المجدولة في الخلفية، وتشغيل المهام بناءً على أحداث تطبيقات مثل GitHub، مع تصفية أنشطة طلبات السحب (PR)، للمستخدمين المؤهلين.

هناك نقطة يسهل الخلط فيها: قدرات تعدد الوكلاء (Multi-agent) التي توفرها OpenAI Agents API وResponses API، مثل إسناد الوكيل الرئيسي مهامًا إلى وكلاء فرعيين يمتلك كل منهم سياقًا مستقلًا، هي قدرات على مستوى API، ولا تعني بالضرورة أنها وظائف افتراضية في جميع واجهات منتجات Codex. وبالمثل، فإن استخدام GitHub Actions لاستدعاء Codex CLI وإنشاء طلب سحب للإصلاح بعد فشل CI، كما يشرح OpenAI Cookbook، هو أسلوب لبناء سير عمل، وليس وظيفة مدمجة جاهزة في Codex CLI.

جدولة المهام في DeepSeek Super-agent باستخدام Router وWorker

يمكن تلخيص سير العمل الأساسي في النموذج الأولي من DeepSeek بالشكل التالي: Source → Trigger → Eval → Ticket → Assignment → Executor → Result. تصل الأحداث من GitHub أو Feishu، وتمر أولًا عبر قواعد محددة لتصفية الصلاحيات، ثم يقرر النموذج ما إذا كانت تستدعي إنشاء مهمة. تُنشأ تذكرة مستقلة لكل مهمة مقبولة، وتُسند إلى Worker يمتلك مجلد عمل مستقلًا، ثم تُعاد النتيجة عبر القناة الأصلية، مثل طلب سحب على GitHub.

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

الفرق الحقيقي: أولويات تصميم نظام التنسيق في DeepSeek Super-agent

بما أن Claude Code وCodex يقدمان بالفعل قدرات تعدد الوكلاء والعمل في الخلفية والتعامل مع الأحداث، فما الذي يميز DeepSeek؟ الإجابة ليست في وجود هذه القدرات من عدمه، بل في «من يدير المهام» ونطاق إدارته لها.

عادةً ما يشارك الوكيل الرئيسي الذي يوزّع المهام الفرعية، أو قائد فريق الوكلاء (Team Lead)، بعمق في تخطيط مهمة معقدة واحدة وتنسيقها ودمج نتائجها. أما الموجّه (Router) في DeepSeek فيركز أكثر على التنسيق عالي المستوى عبر المهام: إذ يدير موجّه دائم عدة أعمال مستقلة نسبيًا في الوقت نفسه، بينما يتعامل المستخدم مع Super-agent واحد من الناحية المنطقية، ويتفاعل معه مباشرة عبر قنوات العمل مثل GitHub وFeishu، دون الحاجة إلى إدارة جلسة كل عامل (Worker) بنفسه.

وتقرّ DeepSeek بصراحة بأنه يمكن الوصول إلى بنية مشابهة من طبقتين عبر إعداد الوكيل الرئيسي في فريق الوكلاء للتعامل مع التفاعل العام وتوزيع المهام فقط، دون تنفيذها بنفسه. لذا فإن بنية Router + Worker ليست قدرة حصرية يتعذر على الآخرين تطبيقها؛ بل يكمن الفرق الحقيقي في مدى تنظيم الاستماع المستمر وتوجيه المهام عبر سياق عمل موحّد. ويتجلى ذلك في ثلاث نقاط:

• موجّه دائم: يعمل بوصفه جلسة رئيسية متصلة باستمرار، لا منسّقًا يُنشأ مؤقتًا لكل مهمة، ما يسمح باستمرار السياق العام عبر المهام.
• توجيه مباشر للأحداث المشترَك فيها: يستطيع العامل الذي اشترك في سلسلة (Thread) استقبال الأحداث اللاحقة مباشرةً، مثل التعليقات الجديدة على طلب الدمج (PR) نفسه، مما يقلل حاجة الموجّه إلى إعادة توزيعها.
• مبادرة متحفظة: تُقسّم المهام إلى Explicit (طلبات صريحة) وInferred (مهام محتملة مستنتجة). وتعمل المهام المستنتجة افتراضيًا في وضع observe، فتُسجَّل دون تنفيذ، كما يكون الدمج التلقائي لطلبات PR معطّلًا افتراضيًا.

كيف نقرأ بيانات تجارب DeepSeek Super-agent الرسمية؟

أجرت DeepSeek مجموعة من تجارب الجدولة الاصطناعية: تضمنت كل تجربة نحو 300 رسالة، منها نحو 20 طلب عمل، والباقي محادثات عادية وملاحظات لاحقة وطلبات إلغاء ورسائل CI. واستُبدلت أعمال البرمجة بأدوات محاكاة تستغرق وقتًا، ونُفّذ كل نهج 5 مرات.

هناك نتيجتان تستحقان الانتباه. الأولى أن تفوق Super-agent في P50 ضئيل مقارنة بنهج الجلسة الواحدة الذي يعطي الأولوية للتفويض، لكن زمن P95 أقصر بوضوح. وهذا يشير إلى أن الفائدة الأساسية للبنية ثنائية الطبقات هي الحد من التأخيرات الطويلة عند كثرة المهام. والثانية أن إزالة التمرير المباشر للاشتراكات لم تغيّر زمن الإنجاز تقريبًا، لكن عدد الرموز المقروءة من ذاكرة التخزين المؤقت ارتفع من نحو 23.2 مليون إلى نحو 31.8 مليون. وهذا يدل على أن دوره الأساسي هو تقليل المعالجة المتكررة في Router، لا زيادة السرعة.

لكن من المهم توضيح حدود هذه النتائج: هذه تجربة جدولة، وليست اختبارًا لجودة توليد الشفرة. كما أن مجموعة المقارنة استخدمت جلسة واحدة مع وكيل فرعي تحت موجهات محددة، وليست اختبارًا لمنتجي Claude Code أو Codex الكاملين في الظروف نفسها. لذلك لا تثبت البيانات تحسن كفاءة البرمجة الفعلية بنسبة 39% أو 47%، ولا تصلح لترتيب الأطراف الثلاثة حسب السرعة. وفي مجموعة أخرى من الاختبارات الرسمية لمعالجة الأحداث على دفعات في Router، ارتفع متوسط حجم الدفعة إلى 2.8 عند وصول نحو 40 حدثًا في الدقيقة، وانخفض زمن الاستدلال الموزع على كل قرار إلى 1.6 ثانية. وهذا أيضًا لا يدل إلا على قابلية الاستخدام تحت حمل الاختبار الحالي.

حدود التكلفة والأمان في DeepSeek Super-agent

تأتي السرعة الأعلى على حساب استهلاك المزيد من الرموز (Token). ففي الاختبارات التجريبية، كان حجم قراءة ذاكرة التخزين المؤقت في Super-agent نحو 3.8 أضعاف ما هو عليه في نهج محايد يعتمد على جلسة واحدة. لكن هذا لا يعني أن التكلفة الإجمالية تزيد بالقدر نفسه؛ فهي تعتمد أيضًا على أسعار النماذج، ومعدل الاستفادة من ذاكرة التخزين المؤقت، وحجم رموز الإدخال والإخراج، والنموذج المستخدم لكل من Router وWorker. ولم تعلن DeepSeek رسميًا بعد متوسط تكلفة معالجة كل طلب عمل فعلي.

للمقارنة، فيما يلي أسعار واجهة API الرسمية من DeepSeek بتاريخ 2026-11-02، بالدولار لكل مليون رمز. هذه أسعار استخدام النماذج، وليست باقات اشتراك Super-agent:

بالإضافة إلى ذلك، تبلغ تكلفة كل من Search وFetch مبلغ $0.75 لكل 1000 طلب ناجح، وقد بدأ احتسابها في 1 نوفمبر 2026 الساعة 00:00 بتوقيت بكين، ولا تُفرض إلا عند الاستخدام الفعلي. وعلى من يتولى النشر احتساب موارد الخادم وتكاليف التشغيل المستمر والصيانة البشرية أيضًا. أما Claude Code وCodex فيقدمان خططًا مختلفة تشمل الاشتراكات وواجهات API والتنفيذ السحابي، لذا لا يوجد حاليًا مقياس موحد لـ«تكلفة كل طلب سحب (PR) مؤهل» يمكن استخدامه للمقارنة بين الأدوات الثلاث.

💰 نصيحة لإدارة التكلفة: يتمثل العامل الأساسي في تكلفة بنية الوكلاء المتعددين في تحديد النموذج المستخدم لكل دور. إذا أردت تجربة استخدام نموذج خفيف لـRouter ونموذج أقوى لـWorker، فيمكنك عبر APIYI على apiyi.com الوصول إلى نماذج رائدة من عدة مزودين باستخدام مفتاح API واحد، مع الدفع حسب الاستخدام، مما يسهل متابعة استهلاك الرموز للتركيبات المختلفة في فاتورة واحدة.

ولا يمكن تجاهل الأمان أيضًا. تقر وثائق النشر الرسمية بأن الإعدادات المسبقة المخصصة لـRouter وWorker تعمل في وضع danger-full-access، وتُنفّذ افتراضيًا بصلاحيات مستخدم النظام الذي يشغّلها. وهذا يعني أنها قد تتمكن من قراءة ملفات المجلد الرئيسي، وتشغيل برامج محلية، والوصول إلى بيانات اعتماد محلية. لذلك توصي DeepSeek باستخدام مستخدم نظام مستقل وحساب روبوت GitHub مستقل. كما أن مراقبة التعليقات والرسائل الخارجية تنطوي على مخاطر حقن الموجهات (Prompt Injection). وظهر في المجتمع تقرير تدقيق من جهة خارجية يستهدف الـcommit 6337fc8، أشار إلى مشكلات محتملة، منها التحقق من صلاحية الطلبات في واجهة الإدارة. لكن عملية الهجوم الكاملة لم تُعَد محاكاتها بشكل مستقل، لذا ينبغي التعامل معها على أنها «مخاطر محتملة» لا حوادث مؤكدة.

تحليل تأثير DeepSeek Super-agent

التأثير على المطورين

• الحاجة إلى توسيع معايير التقييم: عند اختيار الأداة، لا يكفي النظر إلى نتائج النموذج الأساسي؛ بل يجب أيضًا تقييم مدى توافق استقبال الأحداث، وعزل المهام، والتشغيل في الخلفية، وآليات المراجعة البشرية مع سير عمل الفريق.
• النموذج الأولي قابل للاستخدام، لكنه ليس خاليًا من المتاعب: نجح مستخدم المجتمع xxxxkkkqq في تحويل Issue إلى PR داخل مستودع خاص، لكنه واجه مشكلات منها عدم وصول الإشعارات رغم نجاح فحوصات النشر، وفشل تأكيدات الاختبار بسبب ضبط لغة النظام على الصينية. واكتشف مستخدم آخر خلال ساعة على WSL2 عيبين يتعلقان بالتعرف على عمليات Node.js 24 وفقدان بعض تعليقات GitHub.
• قيمة واضحة للتطوير المخصص: بالنسبة إلى الفرق القادرة على صيانة TypeScript وتكامل GitHub وواجهات API للنماذج، يوفر المشروع تنفيذًا مرجعيًا متكاملًا للموجّه والأحداث وتذاكر المهام والعاملين وقواعد الصلاحيات.

التأثير على القطاع

• توسّع نطاق المنافسة: لم تعد المنافسة في البرمجة بالذكاء الاصطناعي مقتصرة على مقارنة النماذج؛ فأطر تشغيل الوكلاء، وتصميم سير العمل، وتجربة المطورين أصبحت عوامل لا تقل أهمية.
• نحو نهج أكثر انضباطًا للوكلاء الاستباقيين: ربطت DeepSeek «العمل الاستباقي» بسياسات التفويض ووضع المراقبة وآليات القبول البشري، استجابةً للمخاوف الواقعية من أن يهدر الوكيل انتباه الفريق.

بناءً على القدرات السابقة، يمكن الاختيار وفق نمط العمل كما يلي:

🎯 نصيحة للاختيار: لا تتعارض هذه الأدوات بالضرورة؛ فكثير من الفرق تستخدم Claude Code أو Codex للبرمجة اليومية، مع طبقة جدولة مخصصة لمعالجة الأحداث والتوجيه. وعند بناء هذه الطبقة، يمكن البدء بالحصول على رصيد تجريبي مجاني عبر APIYI على apiyi.com، ومقارنة أداء النماذج المختلفة في دورَي الموجّه والعامل.

تطبيق فكرة الموجّه في DeepSeek Super-agent باستخدام API

أفضل طريقة لفهم نظام الجدولة هي كتابة نسخة مبسطة منه. يستخدم المثال التالي واجهة متوافقة مع OpenAI لتوضيح فكرة «استخدام نموذج خفيف لاتخاذ قرار التوجيه». وهو مجرد مثال توضيحي، ولا يمثّل الشفرة الفعلية للنموذج الأولي من DeepSeek:

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # APIYI OpenAI 兼容接口
)

event = "PR #42 评论：CI 在 test_auth.py 失败，请帮忙看看"
resp = client.chat.completions.create(
    model="ROUTER_MODEL",  # 替换为控制台中可用的轻量模型名
    messages=[{"role": "user", "content": f"判断该事件是否需要建任务，只回答 YES/NO：{event}"}]
)
print(resp.choices[0].message.content)

import openai
from dataclasses import dataclass, field

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # 一个 Key 接入多家模型
)

ROUTER_MODEL = "ROUTER_MODEL"   # 轻量模型：负责路由判断
WORKER_MODEL = "WORKER_MODEL"   # 强模型：负责具体任务
AUTHORIZED_USERS = {"alice", "bob"}  # 确定性规则：授权名单

@dataclass
class Ticket:
    thread_id: str
    task: str
    history: list = field(default_factory=list)

tickets: dict[str, Ticket] = {}

def router_eval(event: dict) -> bool:
    """先规则过滤，再由模型判断是否建任务"""
    if event["user"] not in AUTHORIZED_USERS:
        return False  # 未授权：仅观察，不执行
    resp = client.chat.completions.create(
        model=ROUTER_MODEL,
        messages=[
            {"role": "system", "content": "你是任务路由器，只回答 YES 或 NO。"},
            {"role": "user", "content": f"该消息是否是需要执行的工作请求？\n{event['text']}"}
        ],
        max_tokens=5
    )
    return "YES" in resp.choices[0].message.content.upper()

def worker_run(ticket: Ticket, text: str) -> str:
    """Worker 使用独立上下文处理任务"""
    ticket.history.append({"role": "user", "content": text})
    resp = client.chat.completions.create(
        model=WORKER_MODEL,
        messages=[{"role": "system", "content": "你是代码修复助手，给出修复思路。"}] + ticket.history
    )
    answer = resp.choices[0].message.content
    ticket.history.append({"role": "assistant", "content": answer})
    return answer

def handle(event: dict) -> str:
    tid = event["thread_id"]
    # 订阅直通：已有 Ticket 的后续事件直接交给对应 Worker
    if tid in tickets:
        return worker_run(tickets[tid], event["text"])
    if router_eval(event):
        tickets[tid] = Ticket(thread_id=tid, task=event["text"])
        return worker_run(tickets[tid], event["text"])
    return "已记录，未建任务"

print(handle({"thread_id": "pr-42", "user": "alice", "text": "CI 在 test_auth.py 失败"}))
print(handle({"thread_id": "pr-42", "user": "alice", "text": "补充：只在 Python 3.12 下失败"}))

يوضح هذا المثال ثلاثة أمور: تُطبَّق القواعد الحتمية قبل أحكام النموذج، ويستخدم الموجّه (Router) والعامل (Worker) نموذجين مختلفين، وتدخل الأحداث اللاحقة للمحادثة (Thread) نفسها مباشرةً إلى سياق العامل الموجود. لكن النظام الفعلي يحتاج أيضًا إلى عزل أدلة العمل، وبيئة معزولة للصلاحيات، وحفظ الحالة، والمراجعة البشرية؛ وهي جوانب لا يزال النموذج الأولي قيد تطويرها.

🚀 للبدء سريعًا: لا يتطلب تشغيل الشفرة أعلاه سوى استبدال مفتاح API واسم النموذج. ننصح بالاطلاع على قائمة النماذج المتاحة حاليًا في لوحة تحكم APIYI على apiyi.com. يحصل المستخدمون الجدد على رصيد اختبار مجاني، مما يتيح التحقق من فكرة الجدولة بتكلفة منخفضة قبل اتخاذ قرار بشأن مواصلة التطوير.

الأسئلة الشائعة FAQ

مقارنة DeepSeek Super-agent مع Claude Code وCodex: أبرز النقاط

• اختلاف المستوى: Super-agent نموذج أولي لنظام تنسيق، بينما Claude Code وCodex منتجان لوكلاء البرمجة.
• تعدد الوكلاء ليس حكرًا على Super-agent: يوفّر Claude Code وCodex بالفعل وكلاء فرعيين وجلسات متوازية وإمكانات للعمل في الخلفية والتعامل مع الأحداث.
• الفرق الحقيقي في تنظيم النظام: يركز التصميم على Router دائم التشغيل، وتوجيه المهام المختلفة، والاشتراك المباشر، والسياق الموحّد.
• للنتائج التجريبية حدودها: تجربة التنسيق الاصطناعية تعكس أداء التنسيق فقط، ولا تمثل جودة البرمجة أو ترتيب الأطراف الثلاثة.
• السرعة مقابل استهلاك الرموز: تبلغ عمليات قراءة ذاكرة التخزين المؤقت نحو 3.8 أضعاف ما يستهلكه حل الجلسة الواحدة، ويجب حساب التكلفة وفق مجموعة النماذج المستخدمة.
• الأمان أولوية من البداية: يتطلب التشغيل بصلاحيات عالية ومخاطر الحقن عبر المدخلات الخارجية استخدام حساب مستقل ومراجعة بشرية للنتائج.
• التجربة العملية أكثر موثوقية: يمكن استخدام مفتاح واحد عبر APIYI على apiyi.com لتجربة توزيع أدوار Router وWorker بين نماذج متعددة.

الخلاصة

أهم نتائج مقارنة DeepSeek Super-agent مع Claude Code وCodex:

1. الفرق الأول هو المستوى: قدرات النموذج، وقدرات أداة البرمجة، وقدرات نظام التنسيق ثلاثة أمور مختلفة، ولا جدوى من خلطها في المقارنة.
2. قيمة DeepSeek تكمن في تصميم التنسيق: فهو ينظم الاستماع المستمر، وتوجيه المهام المختلفة، والسياق الموحّد، ويضبط التصرفات الاستباقية باستخدام الأذونات ووضع المراقبة observe.
3. الفجوة في النضج حقيقية: لدى النموذج الأولي حالات واقعية انتقلت من Issue إلى PR، لكن التثبيت والموثوقية والأمان لا تزال بحاجة إلى تحسين. لذلك يظل Claude Code وCodex خيارين أكثر أمانًا للبرمجة اليومية.

لم تعد المنافسة في البرمجة بالذكاء الاصطناعي مقتصرة على «أي نموذج أقوى؟»، بل امتدت إلى منظومة تشغيل الوكلاء (Agent Harness) وسير العمل وتجربة المطور. وبالنسبة إلى معظم الفرق، يتمثل المسار العملي في استخدام منتجات ناضجة للبرمجة اليومية، مع تجربة بناء طبقة تنسيق خاصة على نطاق صغير.

يُنصح باستخدام APIYI على apiyi.com للوصول الموحّد إلى نماذج رئيسية متعددة، والتحقق سريعًا من أداء النماذج المختلفة وتكلفتها عند إسناد دورَي Router وWorker إليها.

📚 المراجع

1. المستودع الرسمي للنموذج الأولي DeepSeek Super-agent: حالة المشروع والشيفرة المصدرية ونطاق الاستخدام
2. الرابط: github.com/deepseek-ai/dsh-superagent-prototype

3. التفاصيل: يتضمن ملف README ووثائق النشر وآلية الترخيص وفلسفة التصميم

4. الأسعار الرسمية لـ DeepSeek API: أسعار النماذج وتكاليف Search وFetch

5. الرابط: api-docs.deepseek.com/quick_start/pricing

6. التفاصيل: مرجع لحساب تكاليف نموذجي Router وWorker

7. وثائق Claude Code Subagents وAgent Teams: شرح إمكانات الوكلاء المتعددين

8. الرابط: code.claude.com/docs/en/sub-agents، code.claude.com/docs/en/agent-teams

9. التفاصيل: للتعرّف على السياق المستقل لكل وكيل فرعي وآليات التعاون بين أعضاء الفريق

10. وثائق Claude Code Channels والمهام المجدولة: دفع الأحداث والتشغيل المستمر

11. الرابط: code.claude.com/docs/en/channels، code.claude.com/docs/en/scheduled-tasks

12. التفاصيل: للتعرّف على شروط استخدام ميزات المعاينة البحثية وقيودها

13. وثائق Codex Cloud وWorktrees: المهام السحابية ومساحات العمل المتوازية

14. الرابط: help.openai.com/en/articles/20001545-using-codex-cloud، learn.chatgpt.com/docs/environments/git-worktrees

15. التفاصيل: مرجع رسمي للتمييز بين ميزات منتج Codex

16. دليل الوكلاء المتعددين في OpenAI Agents API: تنسيق الوكلاء المتعددين على مستوى API

17. الرابط: developers.openai.com/api/docs/guides/agents-api/multi-agent

18. التفاصيل: يُقرأ مع التمييز بينه وبين ميزات منتج Codex

19. نقاش تجارب مجتمع DeepSeek Harness: تقرير شامل من Issue إلى PR

20. الرابط: github.com/deepseek-ai/deepseek-harness/discussions/11706
21. التفاصيل: للتعرّف على أداء النموذج الأولي في التشغيل الفعلي والمشكلات الشائعة

الكاتب: الفريق التقني في APIYI
التواصل التقني: يمكنكم التواصل معنا عبر الصفحة الرئيسية لموقع APIYI، والاطلاع على المزيد من موارد تكامل النماذج المتعددة وتنسيق الوكلاء في مركز الوثائق docs.apiyi.com

مقالات ذات صلة

• Magpie مقابل CC Switch: ملف settings.json الخاص بي لا يستطيع أن يحب شخصين في الوقت نفسه: قارن بين magpie وCC Switch للتبديل بين أدوات البرمجة بالذكاء الاصطناعي من حيث اختلاف نهجي تعديل ملفات الإعدادات والبوابة المحلية، ووتيرة الإصدارات، والتوصيات حسب السيناريو، وكيف تختار خمس فئات من المستخدمين، ولماذا لا يمكنهما الكتابة في ملف settings.json نفسه في الوقت ذاته.
• دليل خطوة بخطوة: اربط جميع الوكلاء بمفتاح واحد عبر بوابة API موحّدة باستخدام Magpie مفتوح المصدر (مع Claude Code وCodex وPi وHermes أمثلةً): دليل عملي خطوة بخطوة: في نحو 30 دقيقة، اجعل جميع وكلاء البرمجة على جهازك (مثل Claude Code وCodex وPi وHermes) يستخدمون مفتاح API واحدًا وعنوان بوابة واحدًا، مع لقطات شاشة لواجهة magpie، وخطوات الربط، ومقارنة بالإعدادات الأصلية، وجدول لاستكشاف الأخطاء وإصلاحها.
• دليل البدء باستخدام T3 Code: 8 خطوات للتحكم في Claude Code وCodex وOpenCode عن بُعد عبر الهاتف: للمطورين الذين يستخدمون Claude Code وCodex وOpenCode على الحاسوب: اربط وكيل البرمجة بالهاتف في 8 خطوات، مع توضيح خيارات الاتصال عن بُعد وأنماط الأذونات ومزالق الحصص وكيفية الاتصال ببوابة APIYI.
• Gemini 4 Argon مقابل Claude Opus 5.5: تحليل جدول تقييم جوجل المكوّن من 19 بندًا، وأربعة أبعاد تكشف أيهما أقوى: استنادًا إلى جدول التقييم الرسمي من Google لـ Gemini 4 Argon، قارن بندًا بندًا أداء Gemini 4 Argon وClaude Opus 5.5 في 19 معيارًا تشمل العمل المعرفي والبرمجة الوكيلة والسياق الطويل والوسائط المتعددة، مع الاستعانة بتقييمات Artificial Analysis وVals المستقلة ومقارنة الأسعار والحد الأقصى للإخراج والتوافر، لتقديم توصيات لاختيار النموذج بحسب الاستخدام.
• فرحة عارمة للباحثين: ثبّت 177 مهارة بحثية بأمر واحد وانطلق فورًا: دليل خطوة بخطوة لدمج 177 مهارة لوكلاء البحث العلمي من K-Dense-AI: راجع القائمة، وثبّت ما تحتاج إليه فقط، واستكمل تبعيات Python، ثم شغّل المهارات وتحقق منها، مع جدول لاستكشاف الأخطاء وإصلاحها وتنبيهات بالمخاطر.