كيف تبني وكيلاً فائق الذكاء مثل DeepSeek: شرح الموجه ومنفذي المهام والمشغلات

لبناء وكيل فائق (super-agent) شبيه بما يصفه DeepSeek Harness، قسّم وكيلك إلى طبقتين: جلسة Router (موجّه) واحدة دائمة تتواصل مع البشر وتوزع المهام، والعديد من جلسات Worker (عامل) المعزولة التي ينفذ كل منها مهمة واحدة باستخدام مجموعة الأدوات الكاملة. زوّد كلتيهما بالمدخلات عبر مشغلات الأحداث Triggers (المحادثات، وGitHub، وأنظمة التكامل المستمر CI)، ووجّه المتابعات وفق مسارات المحادثة Thread، وأضف مراقباً مستقلاً Watchdog لمتابعة كل شيء.

يحوّل هذا الدليل المقال التصميمي لـ DeepSeek Harness، المعنون بـ "Exploring Super-agent Design" (استكشاف تصميم الوكيل الفائق)، إلى خطوات بناء عملية. تجدر الإشارة إلى تنبيه هام: يصف المقال بنية معمارية وليس ميزة مطروحة للاستخدام النهائي بعد؛ حيث توجد أجزاء منه في إضافة نموذجية أولية تُدعى dsh-superagent-prototype، والتي يؤكد مطوروها أنها "ليست منتجاً رسمياً من DeepSeek". كما أن جميع المخططات البرمجية الموضحة أدناه هي لأغراض توضيحية وليست من كود DeepSeek الفعلي.

ما هو الوكيل الفائق (Super-agent)؟

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

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

يتميز الوكيل الفائق بأربع سمات:

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

إذا كنت جديداً على منظومة DeepSeek Harness، فيمكنك البدء بالتعرف على ماهية DeepSeek Harness وكيف تُقارن مع Claude Code.

بنية الوكيل الفائق: الوحدات الخمس

يحدد المقال خمس وحدات معمارية، وفيما يلي استعراض لها مع خطوة البناء المخصصة لكل منها:

الخطوة 1: فصل الـ Router عن الـ Workers

يمثل Router (الموجّه) جلسة واحدة طويلة الأمد؛ حيث يتولى جميع التفاعلات مع البشر وعمليات توزيع المهام، ولا ينفذ المهام بنفسه على الإطلاق. ويمكن تشغيله دون الحاجة لأداة Bash، كما يكفيه استخدام نموذج أخف وزناً وأقل تكلفة. وعند ورود عدة مشغلات (Triggers) خلال دورة واحدة للـ Router، يتم تجميعها في دفعة واحدة للمطالبة التالية: مدخلات طويلة، ومخرجات قصيرة، مدمجة في مرحلة التعبئة المسبقة (prefill).

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

احرص على عدم الخلط بين هذا النمط وفريق الوكلاء (agent team)؛ فقائد الفريق يفكك مهمة واحدة مترابطة، بينما يقتصر دور الـ Router على توزيع المهام المستقلة فقط، مع إمكانية الجمع بين النمطين في طبقات متراكبة.

# Illustrative sketch, not DeepSeek's code
class Router:
    def on_events(self, batch):              # triggers arriving mid-turn are batched
        plan = self.llm_light.decide(batch)  # dispatch, reply, or ignore
        for task in plan.new_tasks:
            Worker.spawn(task, model="strongest", tools="all", report_to=self)
        for msg in plan.replies:
            self.channels.send(msg)          # only the Router speaks to humans

الخطوة 2: تحويل الأحداث إلى مشغلات (Triggers)

كل مدخل يتلقاه الوكيل الفائق يعد مشغلاً (Trigger): رسالة محادثة، أو حدث webhook من GitHub، أو حمولة بيانات من Slack Events API، أو استدعاء من نظام CI. ولا ينبغي لمعظم هذه الأحداث أن تصل إلى النموذج اللغوي إطلاقاً، ولهذا يقترح المقال تصفيتها عبر مسارين:

1. مسار سريع عبر الكود: التصفية بحسب المصدر، والمجموعة، والقوائم البيضاء للمستخدمين أو البوتات. ويُحدد لكل مصدر وضع عمل: "الاستجابة للطلبات الصريحة فقط"، أو "مرشح"، أو "تجاهل".
2. مسار بطيء عبر نموذج لغوي: تُرسل الأحداث المرشحة إلى نموذج يُطبق سياسات مكتوبة في صيغة مطالبات، مثل "الرد عندما يُبلغ شخص ما عن خطأ برمجي في هذه القناة".

يجب أن تؤكد نقطة نهاية الاستقبال لديك استلام الطلب سريعاً وتؤجل المعالجة لوقت لاحق؛ إذ تتطلب أفضل ممارسات الـ webhooks في GitHub الرد برمز 2XX خلال 10 ثوانٍ، وهو ما لا يمكن ضمانه عند استدعاء النماذج اللغوية. لذا، أرسل الرد 202 Accepted، وضع المشغل في قائمة انتظار، ودع الـ Router يتولى استلامه. يغطي دليلنا حول تصميم webhooks موثوقة استراتيجيات إعادة المحاولة والعمليات المتماثلة (idempotency) لهذه الطبقة.

الخطوة 3: توجيه المتابعات حسب مسار المحادثة (Thread)

يمثل Thread (مسار المحادثة) سلسلة متتابعة من الأحداث المرتبطة بطلب سحب (PR) واحد، أو موضوع دردشة، أو سلسلة رسائل بريد إلكتروني. يشترك الـ Worker المنشأ للحدث الأول في هذا المسار تلقائياً؛ ومن ثم تمر أحداث المتابعة اللاحقة مباشرة إلى ذلك الـ Worker دون الحاجة لاستدعاء الـ Router.

وتعد هذه العلاقة متعددة إلى متعددة؛ فإذا كان هناك عاملان يتعاملان مع طلب السحب نفسه، يتلقى كلاهما أحداثه، ويمكنهما حل التعارضات عبر طلب السحب نفسه دون مراسلة بعضهما بشكل مباشر.

إن تخطي هذه الخطوة سيكلفك الكثير: ففي تجربة المقال، أدى إلغاء التمرير المباشر إلى زيادة قرارات الـ Router بنحو 30% ورفع استهلاك الرموز (tokens) بنسبة تقارب 37%.

الخطوة 4: التعامل مع السياق كذاكرة مؤقتة وجعل الأدوات غير متزامنة

لا يستطيع الـ Router استيعاب كل شيء، لذلك يتعامل المقال مع السياق كذاكرة تخزين مؤقت (cache):

• تضمين داخلي (Inline) لما يُرجح الاحتياج إليه: المعرفات (IDs)، والملخصات القصيرة، والرسائل المجاورة.
• إفاضة وتفريغ (Spill) لما تبقى: اقتطاعه وترك مؤشر مرجعي يمكن للوكيل تتبعه.

تُشكّل المعرفات الثابتة للمشغلات (Triggers) والمسارات (Threads) والعمال (Workers) شبكة مرجعية يطلق عليها المؤلفون اسم "سلسلة الاستدعاء" (Chain of Recall)؛ حيث ينتقل الوكيل من المشغل إلى مساره، ثم إلى العامل الذي تولى معالجته، مما يمنحه قدرة الاستدعاء متعدد القفزات دون الحاجة إلى مطالبة ضخمة.

بعد ذلك، انتقل إلى وضع الازدواج الكامل (full-duplex)، واستبدل أداة run() المعطلة بـ start() وstop() غير المتزامنتين. تُرجع start() حالة "تم البدء" فوراً، وتصل النتيجة لاحقاً كحدث جديد، وهو ما يسمح للوكيل باستقبال تعليماتك التالية أثناء تشغيل السابقة. ويوضح المقال أن DeepSeek Harness يطبق هذا الأمر ولكنه لا يُفعّله افتراضياً.

أخيراً، اجعل الردود مدركة لطبيعة القناة؛ فالقاعدة التي اختبروها تحدد ردود المحادثات الفورية بحد أقصى 100 كلمة، بينما تتلقى منصات GitHub والبريد الإلكتروني والمستندات تقارير مفصلة ومنظمة بعناية.

كما يتيح ذلك أيضاً التنفيذ التخميني (speculative execution): ففي مجموعة المستخدمين لديهم، تطبق سياسة "إعادة الإنتاج والإصلاح بصمت" والتي لا تقدم سوى الإصلاحات البسيطة المؤكدة وتبقى صامتة في الحالات الأخرى.

الخطوة 5: الفصل بين الحوسبة والحالة وبيئات التشغيل

شغّل حلقة الوكيل (agent loop) في حاويات سحابية عديمة الحالة (stateless) واحتفظ بحالة الجلسة في قاعدة بيانات. أما بيئات العمل فتبقى كما هي في مواقعها: يُشغّل كل جهاز برنامج خلفية خفيفاً، وهو ما يطلق عليه المقال اسم BYOM (أحضر جهازك الخاص). وفي حال تعطلت حلقة التشغيل، فإنها تعيد الإقلاع في أي مكان وتستعيد حالتها، بينما تظل المستودعات البرمجية في أجهزتها دون تغيير.

ويشير المقال إلى مقال Anthropic بعنوان “Scaling Managed Agents: Decoupling the brain from the hands” باعتباره يتبنى الفكرة نفسها، مع توجيهه نحو بيئات العزل المُدارة (sandboxes) بدلاً من أجهزتك الخاصة.

الخطوة 6: إضافة مراقب (Watchdog)

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

ما أظهرته التجارب

أجرى الباحثون اختبارات شملت حوالي 300 رسالة محادثة وإشعار CI تضمنت قرابة 20 طلب عمل، مع محاكاة كتابة الأكواد بمؤقت زمني، وتشغيل كل إعداد 5 مرات، مشيرين إلى أن النتائج "ذات دلالة استرشادية فقط".

برزت نتيجتان رئيسيتان: فمع استخدام مطالبة محايدة، لم تقم الجلسة الفردية بتفويض المهام مطلقاً خلال جولات التشغيل الخمس، مما جعل قيمة p95 تقترب من ضعف قيمة الوكيل الفائق. بينما نجحت المطالبة المعتمدة على أولوية التفويض في تحسين الوسيط (median)، لكنها لم تعالج الحالات القصوى البطيئة (tail). ويكلف الوكيل الفائق رموزاً أكثر مقارنة بالجلسة المفردة، مما يعني أنك تقايض استهلاك الرموز مقابل تقليل زمن الاستجابة وتوفير انتباه المستخدم.

واختبرت تجربة ثانية تحميل الـ Router بمفرده؛ فمع ارتفاع المشغلات (Triggers) من 1 إلى 40 مشغلاً في الدقيقة، زاد حجم الدفعة من 1.0 إلى 2.8 وارتفع الوقت لكل طلب من 2.5 ثانية إلى 3.9 ثانية، بينما انخفض الوقت لكل قرار من 6.4 ثانية إلى 1.6 ثانية. وتعد آلية التجميع في دفعات (Batching) هي ما يمنع الـ Router الفردي من التحول إلى عنق زجاجة في وقت مبكر.

اختبار استقبال المشغلات باستخدام Apidog CLI

يبدأ كل مشغل دورة حياته كطلب HTTP يصل إلى نقطة نهاية الاستقبال لديك، لذا تعد تلك النقطة أول ما يستحق الاختبار. فإذا أسقطت تعليقاً على طلب سحب أو أسندت thread_id جديداً لكل حدث، فسيتعطل توجيه المسارات ويعود كل تعقيب ليمر عبر الـ Router مجدداً. يمكنك جعل وكيلك البرمجي يكتب هذا الاختبار ويشغله باستخدام Apidog CLI.

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

ثم وجّه لوكيلك مطالبة واحدة:

In Apidog project <id>, create POST /triggers/github for a GitHub
pull_request_review_comment webhook. Add a test case that sends two
comments on the same PR and asserts: status 202, a trigger_id in the
body, and the same thread_id both times. Run it against staging and
summarize any failures.

يقرأ الوكيل مخطط كل حمولة بيانات، ويتحقق من صحة JSON، وينشئ نقطة النهاية وحالة الاختبار، ثم يقوم بتشغيلها:

apidog cli-schema get endpoint-create
apidog cli-schema validate endpoint-create --file endpoint.json
apidog endpoint create --project <id> --file endpoint.json
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog run --test-case <caseId> --project <id> -e <stagingEnvId> -r cli,json

يمكنك دمج أمر apidog run نفسه مع خيار -r junit مباشرة في خط أنابيب النشر والتطوير؛ راجع Apidog CLI في CI/CD. وإذا كان وكيلك هو DeepSeek Harness نفسه، فاتبع دليل الإعداد هذا؛ أما بالنسبة لـ Claude Code، فاستخدم هذا الدليل. وتغطي خطة Apidog المجانية ما يصل إلى 4 مستخدمين.

مشكلات وتحديات غير محلولة

يسرد المقال التحديات التي لا تزال دون حل:

• توسيع نطاق الـ Router وتحديد بنية توزيع الـ Workers مع تزايد عبء العمل.
• الذاكرة طويلة الأمد بما يتجاوز سلسلة الاستدعاء (Chain of Recall).
• تجربة المستخدم دون جلسات: كيفية توجيه الوكيل دون الاعتماد على نافذة محادثة موحدة.
• حدود السياق وبروتوكولات التواصل بين الوكلاء، حيث يُعد بروتوكول A2A أحد الحلول المرشحة.
• الأمان: قد يؤدي أي حقن للمطالبات يصل إلى حلقة العمل السحابية إلى الوصول لجميع الأجهزة المتصلة، كما يمكن أن تتسرب بيانات الاعتماد الحساسة الموجودة في السياق. ويتطلع المؤلفون إلى تمكين الوكلاء من استخدام بيانات الاعتماد دون الاطلاع عليها مطلقاً.

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

هل الوكيل الفائق ميزة في DeepSeek Harness يمكنني تفعيلها؟ لا؛ يصف المقال بنية معمارية وليس ميزة جاهزة، وتوجد أجزاء منها في إضافة dsh-superagent-prototype النموذجية، والتي يوضح مؤلفوها أنها ليست منتجاً رسمياً من DeepSeek. كما أن أدوات الازدواج الكامل (full-duplex) منفذة برمجياً ولكنها معطلة افتراضياً.

لماذا يستخدم الـ Router نموذجاً أخف؟ يقتصر دور الـ Router على التوجيه والتواصل مع البشر، ولا ينفذ المهام بنفسه مطلقاً ولا يحتاج إلى أداة Bash؛ بينما يتولى الـ Workers التفكير المعقد باستخدام أقوى النماذج المتاحة.

ما الفرق بين الوكيل الفائق وفريق الوكلاء؟ يفكك قائد الفريق مهمة واحدة مترابطة إلى أجزاء، بينما يوزع الـ Router مهاماً مستقلة. ويمكن لأي Worker أن يدير فريق وكلاء خاصاً به داخل الوكيل الفائق.

ما هو التمرير المباشر للمسار (Thread pass-through)؟ تذهب أحداث المتابعة في طلب سحب أو موضوع دردشة أو سلسلة بريد إلكتروني مباشرة إلى الـ Worker المسؤول عن ذلك المسار، متجاوزة الـ Router...