تفكيك «تصميم الوكيل الخارق» من DeepSeek Harness: 12 ممارسة قابلة للتطبيق لمعالجة 3 مشكلات تصميمية تتعلق بالاتصال مزدوج الاتجاه بالكامل والذاكرة وبيانات الاعتماد

ملاحظة الكاتب: يستعرض هذا المقال ثلاث مسائل تصميمية في «تصميم الوكيل الفائق» من DeepSeek Harness: الاتصال ثنائي الاتجاه الكامل، والذاكرة، وبيانات الاعتماد. ويوضح ما يمكن الاستفادة منه الآن وما لا يزال «مسألة مفتوحة»، مع تقديم عقود الواجهات وقائمة للتنفيذ.

غالبًا ما يواجه الوكيل طويل التشغيل ثلاث مشكلات في الوقت نفسه. فخلال الدقائق الست التي يستغرقها تشغيل الاختبارات، لا يسع سؤال المستخدم الجديد إلا الانتظار في الطابور؛ وسياق الأمس تُزيحه أحداث اليوم من نافذة السياق؛ وأثناء تصحيح الأخطاء، قد يفتح الوكيل ملف .env فتتسرّب المفاتيح إلى سجل المحادثة. في 2026-11-01، نشر فريق DeepSeek Harness مقالًا مطولًا بعنوان “Exploring Super-agent Design”، لخّص فيه هذه المشكلات الثلاث تحت عناوين الاتصال ثنائي الاتجاه الكامل (full-duplex)، والذاكرة (Chain of Recall)، و«استخدام بيانات الاعتماد دون رؤيتها».

هذا المقال ليس تحليلًا لإطلاق منتج. فالمقال الأصلي يصف بنية معمارية، لا ميزة يمكن تفعيلها مباشرة: الاتصال ثنائي الاتجاه الكامل مُنفَّذ بالفعل في DeepSeek Harness، لكنه معطّل افتراضيًا، وبعض مكوّناته موجود في الإضافة التجريبية dsh-superagent-prototype، التي يوضح مؤلفها صراحة أنها «ليست منتجًا رسميًا من DeepSeek». أما الذاكرة طويلة المدى وبيانات الاعتماد، فقد أدرجهما المقال الأصلي ضمن المسائل المفتوحة.

الفائدة الأساسية: بعد قراءة هذا المقال، ستعرف أيّ حلول هذه المسائل الثلاث يمكنك اعتمادها مباشرة، وما العقود التي يجب أن تستوفيها واجهات API وراء كل حل، وما الخطوة الأولى التي يمكنك اتخاذها في مشروع الوكيل الخاص بك.

أبرز مبادئ تصميم الوكيل الفائق DeepSeek Harness

لنبدأ بجدول يوضح موقع كل مشكلة من المشكلات الثلاث في المقال الأصلي، وما يمكن الاستفادة منه الآن.

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

البنية العامة للوكيل الفائق DeepSeek Harness

يتكوّن الوكيل الفائق في المقال الأصلي من مكوّن توجيه (Router) وعمال (Workers). يعمل Router باستمرار بوصفه نقطة دخول لجدولة المهام، ويراقب في الوقت نفسه الأحداث الواردة من مصادر مثل الدردشة وGitHub وCI. أما Worker فهو جلسة وكيل معزولة، يتولى كل منها مهمة واحدة فقط. يُسمّى كل حدث يدخل النظام Trigger، وتُجمع الأحداث المترابطة الخاصة بطلب دمج (PR) واحد، أو موضوع واحد في المراسلة الفورية (IM)، أو سلسلة بريد إلكتروني واحدة، ضمن Thread واحد.

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

كيف تستفيد من تصميم الاتصال ثنائي الاتجاه المتزامن في DeepSeek Harness

يعالج الاتصال ثنائي الاتجاه المتزامن مشكلة «أداة بطيئة تُجمّد الوكيل بالكامل». في النهج التقليدي، ينتظر الوكيل نتيجة استدعاء الأداة قبل المتابعة. قد لا يسبب استعلام يستغرق 200 مللي ثانية مشكلة، لكن تشغيل اختبار يستغرق 6 دقائق يخلق ثلاث مشكلات: تتراكم فترات تأخير الطلبات اللاحقة؛ ولا يسمع الوكيل المستخدم إذا قال أثناء التشغيل «تجاوز اختبارات e2e»؛ وقد تقطع البوابة اتصالًا ظل معلقًا طويلًا، فيظهر خطأ انتهاء المهلة رغم نجاح العمل.

يصف النص الأصلي الحالة المثالية بأنها «productive»، أي أن الوكيل يستطيع تلقي التعليمة التالية قبل اكتمال السابقة. ولتحقيق ذلك، يُقسّم استدعاء run() الذي يحجب التنفيذ إلى مجموعة من العقود الصغيرة: تُرجع start() معرّفًا للمهمة فورًا، وتُبلغ status() عن التقدم، وتبدأ stop() الإلغاء، ثم تعود النتيجة لاحقًا إلى المحادثة في صورة حدث. الفرق هو في الجهة التي تنتظر: مع run() ينتظر النموذج، ومع start() تنتظر بيئة التشغيل.

عقد الأدوات غير المتزامنة للاتصال ثنائي الاتجاه في DeepSeek Harness

عند تعريف الأدوات، تُقدَّم كل وظيفة طويلة التنفيذ عبر ثلاث أدوات بدلًا من واحدة. في مثال الاختبارات، تُرجع start_test_run القيمة job_id والحالة queued فقط، من دون أي بيانات للنتيجة؛ وتُرجع get_job_status إحدى الحالات queued أو running أو done أو failed مع وصف موجز للتقدم؛ أما stop_job فتبدأ الإلغاء وتُرجع الحالة الفعلية التي وصلت إليها المهمة.

هناك قاعدتان تساعدان على إبقاء سلوك النموذج على المسار الصحيح. الأولى: يجب أن ينص وصف الأداة على «عدم انتظار النتيجة»، وإلا فقد يستعلم النموذج عن get_job_status باستمرار. الثانية: يجب ألا تُرجع start بيانات أبدًا، حتى لا يضطر النموذج إلى تخمين بنية الاستجابة في كل مرة. يمكن تصميم واجهة API للمهام التي تعمل خلف الأدوات وفق الجدول التالي. ويعرّف RFC 9110 حالة 202 Accepted بأنها تعني أن الطلب قُبل للمعالجة، لكن المعالجة لم تكتمل بعد.

الاستدعاء	الاستجابة	الأداة المقابلة
`POST /jobs` (مع ترويسة الطلب `Idempotency-Key`)	202، مع إرجاع `job_id` والحالة `queued`، وتشير `Location` إلى `/jobs/{id}`	start
`GET /jobs/{id}`	200، مع إرجاع queued / running / done / failed	status، ومراقب المهام
`GET /jobs/{id}/result`	200 مع النتيجة عند الاكتمال، و409 إذا لم تكتمل المهمة	أداة جلب النتائج
`DELETE /jobs/{id}`	202 تعني قبول طلب الإلغاء، وتُرجع الاستدعاءات اللاحقة 404 أو 409	stop
عنوان URL اختياري لمعاودة الاتصال	إرسال POST إلى الجهة المستدعية عند اكتمال المهمة	مراقب المهام

إعادة نتائج المهام إلى المحادثة والمعالجة الدفعية في وضع الاتصال ثنائي الاتجاه الكامل لدى DeepSeek Harness

الاستقصاء مجرد حل احتياطي. والتصميم الأفضل هو أن تراقب بيئة التشغيل المهام، ثم ترسل إلى المحادثة حدث اكتمال مختصرًا عند انتهاء كل مهمة، يتضمن job_id والحالة وملخصًا من سطر واحد، مثل «نجح 412، وفشل 3». أما السجل الكامل فيُتاح عبر أداة جلب النتائج، حتى لا يدخل سجل من أربعين ألف سطر إلى السياق مباشرة.

يصف المقال الأصلي أيضًا المعالجة الدفعية في Router: تُضاف أحداث Trigger التي تصل أثناء جولة توليد إلى قائمة انتظار، ثم تُدمج في استدعاء النموذج التالي. تكون مدخلات هذه الاستدعاءات طويلة ومخرجاتها قصيرة، وتقع معظم تكلفتها في مرحلة المعالجة المسبقة للمدخلات (prefill). في تجربة المقال الأصلي، عندما ارتفع تكرار Trigger من حدث واحد في الدقيقة إلى 40، زاد متوسط حجم الدفعة من 1.0 إلى 2.8، وانخفض زمن اتخاذ القرار الواحد من 6.4 s إلى 1.6 s. هذه بيانات اختبار خاصة بالمقال الأصلي وليست معيارًا عامًا، لكن يمكن تطبيق الفكرة مباشرة: توضع الأحداث ورسائل المستخدم في قائمة انتظار أثناء توليد النموذج، ثم تُرسل معًا حسب ترتيب وصولها بعد انتهاء الجولة.

تفاصيل هندسية حول الترتيب والإلغاء وضمان عدم تكرار التنفيذ

هذه التفاصيل يسهل إغفالها في مرحلة النموذج الأولي، لكنها قد تتسبب في مشكلات عند الإطلاق:

الترتيب: لا تنتهي المهام دائمًا بالترتيب نفسه. عندما تعتمد B على A، يجب التعبير عن هذه العلاقة صراحةً: إما انتظار حدث اكتمال A قبل بدء B، أو جعل API يدعم depends_on.
الإلغاء: stop مجرد طلب، ولا يضمن نجاح الإلغاء. يجب إرجاع الحالة النهائية الفعلية؛ فإذا كانت المهمة قد اكتملت قبل إلغائها، ينبغي إرجاع done ليخبر النموذج المستخدم بما حدث.
مفتاح ضمان عدم تكرار التنفيذ: قد يعيد النموذج المحاولة، وقد يؤدي فقدان الاستجابة إلى إرسال start مرة ثانية. يجب إرفاق idempotency_key بكل طلب start، بحيث يعيد المفتاح المكرر المهمة الموجودة؛ وإلا فقد تُنفّذ عبارة مثل «نفّذ الترحيل» مرتين.
النتائج الجزئية والمهلة: أتح المخرجات المبكرة عبر واجهة نتائج تدعم المؤشر؛ وحدد موعدًا نهائيًا لكل مهمة، ثم أرسل حدث job_timed_out عند تجاوز المهلة.

إذا كانت أداتك تستخدم MCP، فيمكنك الاطلاع على الامتداد الاختياري Tasks في إصدار 2026-07-28 من مواصفة MCP. يستطيع الخادم الاستجابة لاستدعاء الأداة بنتيجة تتضمن taskId، ويمكن للعميل الاستقصاء عبر tasks/get، أو الاستماع إلى notifications/tasks، وطلب الإلغاء باستخدام tasks/cancel. يتطلب هذا الامتداد تفعيلًا صريحًا من العميل والخادم، كما يختلف مستوى دعمه بين البيئات المضيفة، لذا تحقّق من ذلك قبل استخدامه.

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

كيف نستفيد من تصميم الذاكرة في DeepSeek Harness: Chain of Recall

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

تقوم فكرة المقال الأصلي على التعامل مع السياق كذاكرة تخزين مؤقت، باستخدام عمليتين فقط. تضع Inline المحتوى الذي يُرجّح أن يحتاج إليه الوكيل الآن، بما في ذلك المعرّفات والملخصات القصيرة والرسائل المجاورة. أما Spill فتعالج بقية المحتوى: تختصره وتترك مؤشرًا لاسترجاعه عند الحاجة. لا يُحذف المحتوى المُرحّل؛ بل يبقى منه مؤشر فقط في الموجه. فمثلًا، عند فشل عملية CI، لا يبقى في السياق سوى سطر ملخص يقول: «فشلت عملية CI الخاصة بـ PR #412، وفشلت 3 اختبارات من أصل 118 في مجلد payments»، بينما يُحتفظ بمسار استرجاع السجل الكامل البالغ حجمه 41 KB فقط. وإذا كان الملخص كافيًا، فلن يضطر الوكيل إلى دفع تكلفة معالجة تلك الـ 41 KB.

المعرّفات الثابتة ورسم الإحالات في تصميم ذاكرة DeepSeek Harness

تعتمد سلسلة الاسترجاع (Chain of Recall) على بقاء المعرّفات ثابتة دائمًا. يضم النص الأصلي ثلاثة أنواع من الكائنات تحمل معرّفات:

الكائن	المعنى	مثال على المعرّف	علاقة الربط
Trigger	حدث يدخل النظام، مثل رسالة محادثة أو Webhook أو استدعاء راجع من CI	`trg_8f21`	ينتمي إلى Thread
Thread	سلسلة من الأحداث المرتبطة بطلب السحب نفسه أو موضوع مراسلة فورية أو سلسلة بريد إلكتروني	`thr_pr_412`	يتولاها Worker واحد أو أكثر
Worker	جلسة Agent معزولة تتولى مهمة واحدة	`wkr_77a0`	يشير تقريرها إلى أحداث Trigger التي عالجتها

تشكّل هذه الروابط رسمًا للإحالات يمثّل ذاكرة Agent. وعند الاسترجاع، يتتبع الروابط خطوة بخطوة، دون تحميل السجل كاملًا أو البحث عن نصوص متشابهة. على سبيل المثال، يسأل أحدهم يوم الجمعة Router: «لماذا أُضيفت إعادة المحاولة إلى عميل الدفع؟» وكان النقاش المعني قد جرى يوم الثلاثاء وخرج من السياق منذ مدة. في الخطوة الأولى، يستخدم Router سطر فهرسة لا يزال موجودًا في السياق لاسترجاع thr_pr_412. وفي الثانية، يقرأ من سجل Thread معرّف Worker الذي يتولاها، ثم يسترجع تقريره النهائي. وفي الثالثة، يجد في التقرير إحالة إلى Trigger الخاص بفشل CI، فيسترجع سجله ويرى خطأ انتهاء المهلة. ثلاثة استعلامات صغيرة ودقيقة، وإجابة لا تعتمد على التخمين.

أربعة عقود يجب أن تلتزم بها واجهة API لذاكرة DeepSeek Harness

كل خطوة في سلسلة الاسترجاع هي استدعاء لواجهة API. وإذا أعاد أي استدعاء سجلًا مختلفًا أو لم يُرجع سجلًا، تنقطع السلسلة، وقد يتعطل الوكيل أو يلجأ إلى التخمين للإجابة. لذلك يجب أن تلتزم واجهة API الأساسية بأربعة عقود:

المعرّف لا يتغير أبدًا: يجب أن يشير المعرّف الذي يُعاد اليوم إلى الكائن نفسه الشهر المقبل، وألا يُعاد استخدامه بعد الحذف أو ترقيمه من جديد بعد الترحيل.
الاسترجاع بالمعرّف دقيق ومنخفض التكلفة: لا يُرجع GET /threads/{id} سوى هذا السجل تحديدًا، دون إجراء بحث أو إرجاع «أقرب تطابق».
المعرّف المجهول يفشل بوضوح: يُرجع الاستدعاء رمز 404 ونص خطأ واضحًا. أما إرجاع 200 مع كائن فارغ، فسيجعل الوكيل يعتقد أن هذه الذاكرة موجودة.
الترقيم بالمؤشر بلا فجوات: تُقسّم سلاسل Thread الطويلة إلى صفحات بالترتيب، ويظهر كل حدث مرة واحدة فقط، ويظل المؤشر صالحًا عند كتابة أحداث جديدة.

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

ومن المهم النظر بموضوعية إلى حدّين. أولًا، لا تحل سلسلة الاسترجاع (Chain of Recall) محل البحث المتجهي: فالبحث المتجهي يجيب عن سؤال «ما الذي يشبه هذا؟»، بينما تجيب سلسلة الاسترجاع عن سؤال «ما الذي يرتبط بهذا؟». وفي المشاريع العملية، يُستخدم الاثنان غالبًا معًا: يبدأ البحث بفهرس متجهي للعثور على معرّف Thread أولي، ثم يتتبع الروابط وصولًا إلى الوقائع الدقيقة.

ثانيًا، تشير نسبة «37%» في النص الأصلي إلى تمرير Thread: فعند إزالة هذه الميزة، ارتفع عدد رموز القراءة من ذاكرة التخزين المؤقت في كل تشغيل من 23.2M إلى 31.8M. وهذه هي تكلفة غياب ميزة معينة، وليست الوفر الذي تحققه سلسلة الاسترجاع نفسها، لذا ينبغي عدم الخلط بين الأمرين عند الاستشهاد بها.

كيف نستفيد من تصميم بيانات الاعتماد في DeepSeek Harness: استخدام بيانات الاعتماد دون رؤيتها

تطرح المقالة الأصلية هذه المسألة باعتبارها سؤالًا مفتوحًا: إذا دخلت بيانات الاعتماد إلى سياق الوكيل، فقد تتسرب. لذلك ينبغي أن يتمكن الوكيل من استخدامها دون أن يراها. وهناك أربعة مسارات شائعة للتسرب: قراءة ملف .env لاستكشاف الأخطاء؛ أو كتابة ترويسات طلب بنص واضح في أمر تصحيح، أو تنفيذ echo «للتأكد من ضبط المتغير»؛ أو إدراج القيم الحقيقية في وصف طلب سحب (PR) أو تعليق على Issue أو بيانات اختبار ثابتة؛ أو الانخداع بحقن موجهات في صفحة ويب أو استجابة واجهة، فيطبع متغيرات البيئة. وتصنّف OWASP حقن الموجهات بوصفه الخطر الأول على تطبيقات نماذج اللغة الكبيرة، وتدرج كشف بيانات الاعتماد ضمن تسرب المعلومات الحساسة.

تتبع جميع وسائل الحماية قاعدة واحدة: ضع الأسماء فقط في السياق، وأبقِ القيم خارج النموذج. يمكن أن يظهر في السياق اسم متغير مثل STRIPE_KEY، أو مرجع إلى مدير مفاتيح، أو عنصر نائب مثل {{token}}، أو قيمة محجوبة جزئيًا؛ لكن يجب ألا تظهر المفاتيح الحقيقية أو القيم بعد استخراجها أو أسطر السجلات غير المنقّحة. وبمجرد ظهور القيمة الحقيقية في المحادثة، يجب تدوير المفتاح في اليوم نفسه، لأن سجلات المحادثة تُحفظ وتُخزّن مؤقتًا وتُصدّر، ولا يمكن استرداد الرمز بعد إرساله.

أربعة أنماط عملية لإدارة بيانات الاعتماد في DeepSeek Harness

النمط	طريقة العمل	هل يمتلك الوكيل القيمة؟	القيد الأساسي
متغيرات البيئة + إخفاء القيم الحساسة	كتابة `$NAME` في الأمر، وتترك عملية توسعته لـ shell؛ مع منع قراءة `.env` وإخفاء القيم قبل إعادة المخرجات	يمتلكها shell	يحمي من الأخطاء غير المقصودة، لكنه لا يمنع طباعتها عمدًا بعد هجوم حقن
مرجع إلى مدير الأسرار	وضع مرجع مثل `op://vault/item/field` فقط في الإعدادات، ثم تحلّه أداة CLI وتوفر القيمة للعملية الفرعية وقت التشغيل	تمتلكها العملية الفرعية	القيود نفسها التي تنطبق على متغيرات البيئة
وكيل حقن بيانات الاعتماد	يرسل الوكيل طلبًا بلا مفتاح إلى وكيل محلي، فيضيف الأخير ترويسة المصادقة ويمرر الطلب وفق قائمة سماح	لا يمتلك المفتاح أبدًا	يتطلب نشر الوكيل وصيانته بصورة مستقلة
رمز قصير العمر ومحدود الصلاحيات	إصدار رمز لكل جلسة تنتهي صلاحيته بعد بضع دقائق ولا ينفذ سوى مهمة واحدة	يمتلكه، لكن قيمته محدودة	إجراء احتياطي فقط؛ فقد يُساء استخدامه خلال مدة صلاحيته

من بين هذه الأنماط الأربعة، لا يمنع امتلاك الوكيل للمفتاح فعليًا إلا وكيل حقن بيانات الاعتماد. وتكتسب قائمة السماح أهمية لا تقل عن الحقن نفسه: مثلًا، السماح بـ GET /v1/charges ورفض DELETE /v1/customers. حتى لو تعرّض الوكيل لهجوم حقن، فلن يتمكن إلا من تنفيذ الاستدعاءات التي وافقت عليها، ولن يستطيع تسريب المفتاح. ويجب تشغيل وكيل الحقن بمستخدم مستقل أو داخل حاوية مستقلة، لمنع الوكيل من قراءة إعداداته. وهذا يتوافق مع نهج النشر في المصدر الأصلي: تبقى بيانات الاعتماد محليًا مع البيئة.

إذا كان وكيلك يستدعي النموذج عبر APIYI، فيمكن تطبيق الفكرة نفسها على مفتاح النموذج: دع وكيل الحقن يضيف المفتاح عند تمرير الطلب إلى APIYI، بحيث لا يعرف الوكيل سوى أنه يستخدم وكيلًا محليًا. وهكذا، حتى لو سُجّل تصدير للمحادثة، فلن يحتوي على مفتاح APIYI قابل للاستخدام. للاطلاع على عنوان الاتصال وطريقة المصادقة، راجع وثائق APIYI على docs.apiyi.com.

الطبقة الأخيرة هي إخفاء القيم الحساسة. يجب إخفاء القيم ذات البادئات المعروفة في مخرجات الأدوات وسجلات CI والجلسات المحفوظة، بما في ذلك sk_live_ وghp_ وgithub_pat_ وAKIA وxoxb-، إضافة إلى قيم جميع ترويسات الطلب Authorization وX-API-Key، والقيم الفعلية التي حُقنت خلال الجلسة. فسطر واحد لم تُخفَ بياناته الحساسة قد يُبطل كل وسائل الحماية السابقة.

دليل البدء السريع لتصميم DeepSeek Harness: قائمة التنفيذ واختيار النماذج

لا يلزم معالجة مسائل التصميم الثلاث دفعة واحدة. بحسب العائد مقابل الجهد، يُنصح بالترتيب التالي:

ابدأ بحماية بيانات الاعتماد: امنع الوكيل من قراءة .env، وانص صراحةً في CLAUDE.md أو AGENTS.md على «عدم طباعة أي متغير ينتهي بـ _KEY أو _TOKEN أو _SECRET»، وأضف مرشحًا لإخفاء البيانات الحساسة في المخرجات. يمكن إنجاز هذه الخطوة في نصف يوم، وتظهر فائدتها فورًا.
حوّل الأدوات البطيئة إلى أدوات غير متزامنة: ابدأ بأدوات الاختبار والبناء والنشر التي تستغرق عادةً أكثر من بضع ثوانٍ، وقسّم عملها إلى start / status / stop، مع إضافة مفاتيح لضمان عدم تكرار الأثر ومهل نهائية.
أنشئ معرّفات ثابتة: خصّص معرّفات غير قابلة للتغيير للأحداث وسلاسل الجلسات والمهام الفرعية، واحتفظ في السياق بالمعرّف وملخص من سطر واحد فقط. أما المحتوى الطويل فخزّنه خارجيًا مع الإبقاء على مؤشر إليه.
أخيرًا، أضف وكيل حقن بيانات الاعتماد والرموز قصيرة العمر: انشر وكيلًا لواجهات API التابعة لجهات خارجية واضبط قائمة سماح، ثم أصدر رمزًا مستقلًا لكل جلسة وكيل.

في اختيار النموذج، يتعامل Router مع مدخلات طويلة ومخرجات قصيرة، ويتخذ قرارات جماعية متكررة؛ لذا يناسبه نموذج منخفض التكلفة وسريع، مع سعر منخفض لقراءة ذاكرة التخزين المؤقت. أما Worker فيتولى كتابة الشفرة والاستدلال المعقد، لذا يناسبه نموذج أكثر قدرة. الأسعار في الجدول أدناه مأخوذة من صفحة أسعار APIYI على docs.apiyi.com/models. تُعتمد آلية الفوترة وأحدث الأسعار بحسب البيانات المباشرة على الصفحة، ولا تقدم هذه المقالة أي التزام آخر بالأسعار.

النموذج (اسم النموذج لدى APIYI)	سعر الإدخال	سعر الإخراج	سعر ذاكرة التخزين المؤقت	الدور المقترح	المنصة المتاحة
deepseek-v4.1-flash	$0.3	$1.2	$0.006	قرارات Router الجماعية وتلخيص الأحداث	APIYI apiyi.com
claude-sonnet-5-5	$2	$10	$0.1	Worker للبرمجة اليومية	APIYI apiyi.com
kimi-k3.1-pro	$2	$10	$0.2	Worker للسياقات الطويلة ومهام المستندات	APIYI apiyi.com
claude-opus-5-5	$4	$20	$0.2	Worker لإعادة الهيكلة المعقدة والقرارات المهمة	APIYI apiyi.com

من المهم الإشارة إلى أن تجربتَي المعالجة الدفعية وتمرير Thread في المقال الأصلي تؤكدان حجم الرموز المقروءة من ذاكرة التخزين المؤقت. وتقع معظم تكاليف Router على مرحلتَي المعالجة المسبقة للمدخلات (prefill) والقراءة من ذاكرة التخزين المؤقت؛ لذلك غالبًا ما يستحق سعر التخزين المؤقت اهتمامًا أكبر من سعر الإخراج عند اختيار النموذج.

🚀 ابدأ بسرعة: تتيح APIYI استدعاء النماذج في الجدول أعلاه عبر API، وتدعم تنسيقَي واجهات OpenAI وAnthropic. يمكن لـ Router الاتصال بنموذج deepseek-v4.1-flash باستخدام تنسيق OpenAI، بينما يتصل Worker بنموذج claude-sonnet-5-5 باستخدام تنسيق Anthropic، مع إدارة الطرفين من حساب واحد. للاطلاع على تعليمات الربط، راجع وثائق APIYI على docs.apiyi.com، وللأسعار راجع docs.apiyi.com/models.

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

س1: ما هو «تصميم الوكيل الفائق» من DeepSeek Harness؟

هو مقال مطوّل بعنوان “Exploring Super-agent Design”، نشره فريق DeepSeek Harness في 2026-11-01، ويناقش كيفية تصميم وكيل فائق يعمل باستمرار ويراقب عدة مصادر للأحداث في الوقت نفسه. يصف المقال بنية مقترحة، وليس ميزة أُطلقت رسميًا. وقد وُضع بعض محتواه في الإضافة التجريبية `dsh-superagent-prototype`، التي أوضح الكاتب أنها ليست منتجًا رسميًا من DeepSeek.

س2: ما الفرق بين الاتصال ثنائي الاتجاه الكامل واستدعاء الأدوات بالتوازي؟

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

س3: هل يمكن تفعيل Chain of Recall مباشرة؟ وهل يمكنها أن تحل محل RAG؟

لا، في الحالتين. Chain of Recall هي نمط تصميم ورد في المقال الأصلي، وليست ميزة يمكن تفعيلها بمفتاح؛ بل تحتاج إلى تنفيذ معرّفات ثابتة وواجهة لاسترجاع المعلومات باستخدامها. وهي تحل مشكلة مختلفة عن RAG: تبحث RAG عن المحتوى المتشابه، بينما تسترجع Chain of Recall المعلومات عبر روابط دقيقة. في المشاريع العملية، يُستخدم البحث بالمتجهات عادةً للعثور على نقطة البداية، ثم تُتبع روابط المعرّفات للوصول إلى الحقائق المحددة. وقد أدرج المقال الأصلي الذاكرة طويلة المدى ضمن المسائل المفتوحة، ولم يقل إن Chain of Recall قد حلّتها.

س4: ما التطبيقات الأنسب لقضايا التصميم الثلاث هذه؟

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

س5: كيف يمكن ربط Router وWorker بنموذجين مختلفين بسرعة؟

من الطرق الأسهل استخدام منصة موحّدة متوافقة مع صيغتي واجهات OpenAI وAnthropic. بعد التسجيل في APIYI عبر apiyi.com، احصل على مفتاح API، ثم أدخل اسم النموذج المناسب لكل من Router وWorker للتبديل بينهما. يُرجى الرجوع إلى وثائق APIYI على docs.apiyi.com لمعرفة عنوان الاتصال المعتمد. قبل الإطلاق، يُنصح باختبار جودة قرارات deepseek-v4.1-flash وclaude-sonnet-5-5 باستخدام مجموعة الأحداث الحقيقية نفسها، ثم تحديد توزيع الأدوار بينهما.

س6: أين يمكن التحقق من النماذج أو الأسعار المذكورة في المقال الأصلي؟

تعتمد أسعار النماذج المذكورة في هذا المقال على البيانات المحدّثة في صفحة أسعار APIYI على docs.apiyi.com/models، أما الأرقام الواردة في المقال الأصلي ومواد الجهات الخارجية فهي للمقارنة فقط. إذا لم يظهر نموذج في صفحة الأسعار، فهذا يعني أن APIYI لم توفره بعد. وسنعمل على توفيره في أقرب وقت، على أن تكون صفحة الأسعار هي المرجع عندئذٍ.

السؤال 7: ما القيود المعروفة لهذه الممارسات؟

يتطلب التشغيل مزدوج الاتجاه بالكامل دعمًا حقيقيًا من واجهة API للمهام؛ أما تغليف التنفيذ المحظور لإظهاره كأنه غير متزامن فلا يزيد الأمور إلا تعقيدًا. ولا تستطيع سلسلة الاسترجاع (Chain of Recall) العثور على محتوى لم تُنشأ له روابط، كما يسهل انتهاك عقد المعرّفات (ID) أثناء الترحيل وإعادة هيكلة الشفرة. وفي ما يتعلق ببيانات الاعتماد، لا تمنع متغيرات البيئة ولا مراجع الأسرار الوكيل من طباعة القيم عمدًا بعد تعرضه لهجوم حقن. وحده وكيل الحقن يضمن ألا يحتفظ الوكيل الذكي بالقيم أصلًا، بينما لا تصلح الرموز قصيرة الأجل إلا كحل احتياطي. ويصنّف المقال الأصلي نفسه الذاكرة وبيانات الاعتماد ضمن المسائل المفتوحة.

أبرز النقاط في تصميم الوكيل الذكي الفائق DeepSeek Harness

طبيعة المقال الأصلي: مقال عن تصميم البنية؛ التشغيل مزدوج الاتجاه بالكامل معطّل افتراضيًا، والإضافة النموذجية ليست منتجًا رسميًا.
التشغيل مزدوج الاتجاه بالكامل: استبدال run المحظور بالعمليات start / status / stop، وإعادة إدراج النتائج كأحداث تُدمج على دفعات.
عقد واجهة API للمهام: قبول الطلب برمز 202، وإزالة التكرار باستخدام مفتاح منع التكرار، وإرجاع الحالة الفعلية عند الإلغاء، وتحديد موعد نهائي لكل مهمة.
تصميم الذاكرة: لا يوضع في السياق سوى المعرّفات الثابتة والملخصات القصيرة، مع ترك مؤشرات إلى المحتوى المتبقي واسترجاعه عبر روابط المعرّفات على عدة خطوات.
عقد واجهة API للذاكرة: ثبات المعرّفات، والاسترجاع الدقيق، وإرجاع 404 للمعرّفات غير المعروفة، وتقسيم النتائج إلى صفحات باستخدام المؤشرات دون فجوات.
مبدأ بيانات الاعتماد: تدخل الأسماء إلى السياق وتبقى القيم خارجه، مع تفضيل وكيل الحقن واستخدام الرموز قصيرة الأجل كحل احتياطي وإخفاء البيانات الحساسة في السجلات بالكامل.
توزيع الأدوار بين النماذج: يختار Router نموذجًا منخفض التكلفة وتكلفة التخزين المؤقت، بينما يختار Worker نموذجًا أكثر قدرة. ويمكن مقارنة النماذج واختبارها بحساب واحد على APIYI.

الخلاصة

يمكن الاستفادة مباشرة من أفكار أكثر مما توحي به صفة «النموذج الأولي» في مقال DeepSeek Harness بعنوان «تصميم الوكيل الفائق»:

الاتصال ثنائي الاتجاه المتزامن: عقود الأدوات غير المتزامنة وإعادة إدخال الأحداث ممارسات هندسية ناضجة. ويمكن كتابة اختبارات لواجهة API الخاصة بالمهام قبل دمجها مع الوكيل.
الذاكرة: استخدام معرّفات ثابتة مع أسلوب inline/spill هو أقل الطرق تكلفةً لتوفير ذاكرة دقيقة للوكيل المعتمد على الأحداث، لكنه لا يحل محل البحث المتجهي.
بيانات الاعتماد: يمكن تطبيق قاعدة «الأسماء في السياق، والقيم خارجه» اليوم. ووكيل الحقن هو الحل الوحيد الذي يضمن ألا يحتفظ الوكيل بمفاتيح API إطلاقًا.

يُنصح بالبدء بتأمين بيانات الاعتماد وتحويل الأدوات البطيئة إلى أدوات غير متزامنة، ثم الانتقال إلى المعرّفات الثابتة ووكيل الحقن في المرحلة الثانية. وعند الحاجة إلى استخدام نماذج مختلفة للموجّه (Router) والعامل (Worker)، يمكن إجراء اختبارات عملية عبر APIYI على apiyi.com باستخدام واجهة موحّدة متوافقة مع صيغتي OpenAI وAnthropic. يُرجى الرجوع إلى docs.apiyi.com/models لمعرفة الأسعار.

📚 المراجع

What Is Chain of Recall؟ How Stable IDs Give AI Agents Memory: شرح تصميم ذاكرة Chain of Recall
الرابط: apidog.com/blog/chain-of-recall-ai-agent-memory
التفاصيل: يتضمن أمثلة على المعرّفات الثابتة، وinline/spill، والاسترجاع متعدد الخطوات، إلى جانب أربعة عقود لواجهة API.
Async Tool Calls for AI Agents: Why start（） Beats a Blocking run（）: شرح تصميم الأدوات غير المتزامنة للاتصال ثنائي الاتجاه المتزامن
الرابط: apidog.com/blog/async-tool-calls-ai-agents
التفاصيل: يتضمن عقد start/status/stop، وبيانات تجارب المعالجة الدفعية، وشرحًا لامتداد MCP Tasks.
How to Let AI Agents Use API Keys Without Seeing Them: ممارسات تأمين بيانات اعتماد الوكلاء
الرابط: apidog.com/blog/ai-agents-use-api-keys-without-seeing-them
التفاصيل: يتضمن أربعة أنماط لبيانات الاعتماد، ومسارات التسريب، وقائمة لإخفاء البيانات الحساسة.
وثائق APIYI وصفحة الأسعار: إرشادات دمج النماذج وبيانات تسعيرها المذكورة في هذا المقال
الرابط: docs.apiyi.com وdocs.apiyi.com/models
التفاصيل: يُرجى الرجوع إليهما للتحقق من أسماء النماذج وصيغ الواجهات والأسعار الحالية.

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