00:00:00لطالما كانت الهندسة عملية تعاونية للغاية بسبب حجم العمل وتعدد الأدوار المشاركة فيها.
00:00:05لقد تغير هذا بسبب الذكاء الاصطناعي، لكنه في الوقت نفسه يفتح آفاقاً جديدة للتعاون.
00:00:09تتمتع النماذج المختلفة بنقاط قوة متباينة، سواء في أدوارها أو في تكلفتها.
00:00:13لنأخذ مثالاً واحداً.
00:00:14من الحقائق المعروفة أن أحدث نماذج Gemini رائعة حقاً في التصميم.
00:00:18إنها أكثر إبداعاً بكثير من أي نموذج لـ Claude، خاصة إذا أعطيتها تعليمات أقل.
00:00:23لكن بشكل عام، يعد Opus 4.6 نموذجاً متميزاً،
00:00:26خاصة مع أداة Claude code المحيطة به، وهي أداة أكثر استقراراً بكثير من Gemini CLI.
00:00:31لكن لا توجد طريقة فعالة لاستخدام هذه النماذج معاً في سير عمل مشترك.
00:00:35وحتى لو حاولت استخدامها، فستضطر للقيام بالكثير من العمل اليدوي،
00:00:38ولا سبيل لجعل هذه الوكلاء يؤدون العمل بشكل مستقل.
00:00:41مؤخراً، عثرنا على أداة تحل مشكلة التواصل هذه من خلال السماح لعدة
00:00:46وكلاء بنماذج مختلفة بالدردشة مع بعضهم البعض وإخراجنا من المنتصف.
00:00:50إن Agent Chatter هي واجهة دردشة للتنسيق الفوري بين وكلاء الذكاء الاصطناعي.
00:00:55وهي تدعم أشهر ثلاثة وكلاء مثل Claude code و Gemini CLI و Codex،
00:01:00بالإضافة إلى النماذج مفتوحة المصدر مثل Kimi و Qwen وغيرها.
00:01:03يمكنك أيضاً استخدامها لتقليل التكاليف عبر ترك الوكلاء المكلفين مثل Claude يقومون بالتخطيط
00:01:07وترك مهمة التنفيذ لنماذج مثل Kimi أو GLM.
00:01:10تعتمد الأداة على دردشة مشتركة بقنوات متعددة وتسمح للوكلاء بالتحدث مع بعضهم
00:01:14وتنفيذ الميزات بتنسيق متبادل.
00:01:16كان انطباعنا الأول عن الأداة أن واجهة المستخدم الافتراضية لم تكن متقنة تماماً.
00:01:20ولكن بما أن هذا مشروع مفتوح المصدر، فقد قمنا بعمل نسخة (fork) من المستودع الأصلي وأضفنا
00:01:24طبقة بصرية فوقه، تبدو لنا أفضل بكثير وأسهل في التصفح
00:01:28مع بعض التعديلات التي تناسب احتياجاتنا.
00:01:31لقد رفعنا هذا الإصدار إلى مستودعنا مع الحفاظ على الوظائف الأصلية كما هي.
00:01:35لكن كل الفضل في البنية الأساسية لهذه المنصة يعود للمبتكر الأصلي.
00:01:40الآن، يحتوي هذا المشروع فعلياً على مجموعة من البرامج النصية (scripts)
00:01:43التي تحتاج لتشغيلها مرة واحدة لتهيئة الوكلاء لهذه الأداة.
00:01:46هذه البرامج هي نقاط الدخول لتشغيل النظام،
00:01:49وبدونها لا يمكنك تشغيل أي وكيل.
00:01:51للوصول إلى هذه البرامج، ستحتاج إلى استنساخ المستودع بالكامل.
00:01:54يحتوي المستودع بشكل أساسي على برامج لتهيئة كل وكيل على حدة.
00:01:58لكن قبل استخدامها، إذا كنت تستخدم Mac OS أو Linux، يجب أن يكون لديك TMUX مثبتاً.
00:02:02TMUX هو ببساطة مجمع لجلسات الطرفية (terminal multiplexer).
00:02:05يسمح لك بإنشاء جلسات طرفية متعددة والتحكم فيها جميعاً من نقطة واحدة.
00:02:09هذا ما تستخدمه دردشة الوكلاء في الخلفية،
00:02:11لإرسال المهام إلى كل وكيل يعمل في الطرفية.
00:02:14بالنسبة لمستخدمي Windows، يمكنكم تشغيل البرامج مباشرة وستعمل معكم.
00:02:18لقد أدرجوا كافة الأوامر اللازمة لتشغيل برامج كل وكيل.
00:02:21على سبيل المثال، إذا كنت ستستخدم Claude code و Gemini CLI معاً،
00:02:26فانسخ أوامر كل منهما والصقها في الطرفية داخل المجلد الذي استنسخت فيه المستودع.
00:02:31يمكنك اختيار الأوامر الخاصة بأي وكلاء ترغب في تشغيلهم.
00:02:34بمجرد لصق الأمر، ستبدأ جلسة الوكيل داخل جلسة TMUX.
00:02:38يمكنك استخدام العدد الذي تريده من الوكلاء في إعداداتك.
00:02:40مثلاً، يمكنك إعداد أربعة وكلاء: ثلاث جلسات لـ Claude وجلسة واحدة لـ Gemini.
00:02:44ولكن مهما كان عدد الوكلاء، يجب تشغيل كل واحد منهم في طرفية مخصصة.
00:02:49فإذا كنت تشغل أربع جلسات، فستحتاج لأربع طرفيات تعمل جنباً إلى جنب،
00:02:53وستتمكن من التحكم فيها جميعاً من جلسة دردشة واحدة في الأداة.
00:02:56الآن، بمجرد تثبيت كل شيء، عندما تتوجه إلى localhost،
00:03:00يجب أن تظهر لك جميع الوكلاء الذين بدأت تشغيلهم في لوحة الدردشة.
00:03:03لتحقيق أقصى استفادة من هذه الأداة،
00:03:06هناك خطوات معينة يجب اتباعها لمساعدتك على العمل بكفاءة أكبر.
00:03:09يُنصح بتهيئة إطار العمل الذي تستخدمه لبناء تطبيقك قبل استخدام الأداة،
00:03:14لأن هذه النقطة تسبب تضارباً بين الوكلاء حتى لو تم تعيين أدوار مختلفة لهم.
00:03:20لذا تأكد من تهيئة تطبيق Next.js أو أي إطار عمل تستخدمه قبل البدء.
00:03:25أولاً، بما أن كل وكيل يعمل كجلسة منفصلة لـ Claude أو Gemini،
00:03:29سيتعين عليك الموافقة يدوياً على الأذونات لكل واحد منهم بشكل فردي.
00:03:33رغم أنهم يوفرون برامج نصية للتشغيل في وضع "تخطي الأذونات"،
00:03:36إلا أنه لا يُنصح بذلك، فمع وجود عدة وكلاء، يزداد خطر قيام أحدهم بحذف عمل الآخر.
00:03:42لذا ستحتاج لإعداد ملف settings.json لكل من Claude code و Gemini CLI بالأذونات المناسبة.
00:03:48بهذه الطريقة، إذا لزم تعديل ملف أو تشغيل أمر بناء (build)، فلن ينتظر موافقتك اليدوية،
00:03:53وفي الوقت نفسه ستحافظ على التحكم في الأوامر الخطيرة.
00:03:56أمر آخر مهم هو التأكد من تكوين أدوات MCP في الملف أيضاً،
00:04:01وإلا سيتعين عليك الموافقة عليها هي الأخرى.
00:04:03يجب عليك أيضاً إنشاء ملف باسم agents.md.
00:04:05وهو يعمل حالياً كقالب يحتوي على هيكل محسن لاستخدام الوكلاء،
00:04:09والذي يتم ملؤه لاحقاً بواسطتهم.
00:04:11يتضمن الملف قواعد الأدوار، والسلوك، وجميع المبادئ التي يجب على الوكلاء اتباعها.
00:04:15ستحتاج أيضاً لملفات تخطيط مثل مستند متطلبات المنتج (PRD)، وقوالب مواصفات الواجهة والخلفية،
00:04:20والتي كنا نستخدم قوالب لها ليتم ملؤها لاحقاً بواسطة وكيل التخطيط.
00:04:24الغرض من هذه القوالب هو توفير هيكل يمنع الوكلاء من إضافة محتوى غير ضروري.
00:04:30كل هذه القوالب متاحة على AI Labs Pro حيث يمكنك تحميلها واستخدامها.
00:04:35إذا وجدت قيمة فيما نقدمه وترغب في دعم القناة،
00:04:38فإن AI Labs Pro هو أفضل وسيلة للقيام بذلك.
00:04:40الرابط سيكون موجوداً في الوصف.
00:04:42ميزة أخرى تتيحها هذه الأداة هي تسمية كل وكيل وتعيين دور محدد له.
00:04:47هذا يسهل التعرف على الوكيل وجعله يعمل وفقاً لدور مصمم خصيصاً له.
00:04:52على سبيل المثال، إذا كنت تستخدم Gemini لتصميم واجهة المستخدم،
00:04:55يمكنك إعادة تسميته وتعيين دور مخصص له كخبير في تجربة وواجهة المستخدم (UI UX).
00:04:59أنت تعين الأسماء والأدوار لكل وكيل ليعملوا وفقاً للشخصية المحددة لهم.
00:05:04وأخيراً، تحتاج لوضع قواعد معينة لضمان اتباع الوكلاء للمهام بشكل صحيح.
00:05:09كما ذكرنا سابقاً، يجب استخدام ملف agents.md.
00:05:12لكن Claude يستخدم Claude.md و Gemini يستخدم Gemini.md،
00:05:16ولا يستخدم أي منهما ملف تعليمات الآخر كمرجع أساسي.
00:05:19لذا للتنسيق بينهما، نستخدم agents.md ونضيف قاعدة تجعلهما يشيران إليه كملف توجيه رئيسي.
00:05:25يمكنك إعداد قواعد متعددة لتناسب احتياجاتك وإضافة ما تشاء منها.
00:05:29لكن عند إنشاء قاعدة، فإنها توضع أولاً في "المسودات"،
00:05:31ويجب عليك نقلها يدوياً إلى "النشطة" ليتعرف عليها الوكلاء.
00:05:35يتم تحديث القواعد بعد كل 10 محفزات دردشة، ويمكنك تعديل ذلك حسب رغبتك.
00:05:39نقطة أخرى تجب ملاحظتها هي "حارس التكرار" (loop guard)، والمحدد افتراضياً بـ 4.
00:05:43حارس التكرار هو أقصى عدد من التنقلات بين الوكلاء
00:05:46قبل أن يتوقف الوكلاء عن مهامهم وينتظروا مدخلاً منك.
00:05:49تمت إضافته لمنع الوكلاء من العلوق في حلقة مفرغة من الأسئلة المتبادلة لفترة طويلة.
00:05:53بمجرد الوصول إلى حد حارس التكرار، يتوقف الوكلاء عن التواصل
00:05:56وعليك إرسال أمر "متابعة" للاستئناف.
00:05:59يُفضل زيادة هذا الحد إذا أردت تنسيقاً أفضل وأطول بين الوكلاء.
00:06:03لكن قبل أن نخطط للتنفيذ، لنستمع إلى كلمة من راعينا، Airtop.
00:06:06إذا كنت تقضي ساعات كل أسبوع في استخراج البيانات يدوياً
00:06:10أو التنقل بين عشرات التبويبات في المتصفح، فهناك طريقة أفضل بكثير للتعامل مع ذلك.
00:06:13Airtop هي منصة سحابية تتيح لوكلاء الذكاء الاصطناعي التفاعل مع الويب تماماً كالبشر،
00:06:19باستخدام قوالب مخصصة أو جاهزة تحل أكثر المهام اليدوية إزعاجاً.
00:06:23فكر فيها كمتصفح سحابي يتولى كل العمل الشاق بدلاً منك.
00:06:27على سبيل المثال، أنا أستخدم قالباً للبحث في أسعار المنافسين.
00:06:30أعطي الوكيل التعليمات بلغة إنجليزية بسيطة، دون الحاجة لأي كود،
00:06:33وهو يتصفح الموقع، ويتعامل مع تسجيل الدخول، ويستخرج بالضبط ما أحتاجه بتنسيق منظم.
00:06:39أكثر ما يعجبني هو قدرته على تجاوز إجراءات مكافحة الروبوتات المزعجة
00:06:43واختبارات CAPTCHA التي عادة ما تعطل الأتمتة التقليدية،
00:06:46مما يجعله موثوقاً للغاية للأعمال ذات الحجم الكبير.
00:06:48قم ببناء أتمتة موثوقة في دقائق وسجل في Airtop مجاناً الآن.
00:06:53اضغط على الرابط في التعليق المثبت وابدأ البناء اليوم.
00:06:56الآن وبعد اكتمال كافة الخطوات، حان الوقت للانتقال نحو التنفيذ.
00:07:00بما أننا نؤكد دائماً على أهمية التخطيط قبل التنفيذ،
00:07:03يجب أن تبدأ بالتخطيط هنا أيضاً.
00:07:05على غرار قنوات Slack، يمكنك إنشاء قنوات مختلفة هنا أيضاً.
00:07:09ستحتاج لإنشاء قنوات منفصلة لكل من الواجهة الأمامية والخلفية.
00:07:12بمجرد تقديم فكرة التطبيق، ترسل الأداة طلباً إلى جلسة Tmux
00:07:16وتحثها على التحقق من الرسالة لأنه تمت الإشارة إليها.
00:07:18يقوم وكيل التخطيط بإنشاء خطة كاملة، ويخطرك، ويطلب منك الموافقة أو إضافة تعديلات.
00:07:23ويقوم بتوثيق الخطة في ملف الـ PRD مباشرة فوق القالب الذي أضفته في البداية.
00:07:28يمكنك إجراء التغييرات كما تراه مناسباً، وسيقوم بتحديث الملف بناءً عليها.
00:07:32تستخدم هذه الأداة MCP للسماح لـ Claude بإرسال الردود وقراءة الدردشات من الواجهة،
00:07:37مما يجعل التواصل ثنائي الاتجاه ممكناً.
00:07:39بمجرد تأكيد الخطة، تطلب منه المتابعة.
00:07:41وبعد الموافقة على الـ PRD، يقوم الوكيل بتنبيه Gemini تلقائياً
00:07:44ويطلب منه البدء في تنفيذ مستندات مواصفات واجهة المستخدم.
00:07:47ثم يبدأ مصمم الواجهة ووكيل التخطيط في التنسيق مع بعضهما البعض
00:07:51حول تفاصيل التنفيذ، حيث يقترح المخطط التفاصيل
00:07:54ويقوم مصمم الواجهة بدمجها في الخطة، وتستمر المراجعة ذهاباً وإياباً.
00:07:59ملاحظة هامة: رغم أننا ضبطنا حارس التكرار على 8،
00:08:02إلا أنه لم يسجل ذلك لسبب ما.
00:08:04لذا وصلنا للحد الأقصى بعد 4 تكرارات فقط وطُلب منا متابعة المحادثة.
00:08:08الآن يتم إبلاغ "البنّاء" (builder) بأن الخطط جاهزة للتنفيذ من قبل مصمم الواجهة،
00:08:13ويقر البنّاء باستلام الخطط وينتظر الموافقة للبدء.
00:08:18وكيل التصميم ينبهك أيضاً برغبته في المتابعة في تنفيذ الواجهة،
00:08:22وهو ما يجب تأجيله حتى تراجع الخطط بنفسك.
00:08:25في قناة الخلفية (backend)، يمكنك طلب مراجعة ملف backend.md من البنّاء والمخطط،
00:08:30والذي يتم إنشاؤه بواسطة المخطط أثناء تنفيذ الـ PRD.
00:08:33تستخدمهم للتنسيق فيما بينهم للتحقق من المستندات،
00:08:37لكن قد يكتشف كل منهم ثغرات في التنفيذ.
00:08:40لذا ينسقون جميعاً ويشركون مصمم الواجهة للتعامل مع مواصفاتها،
00:08:44ويعملون معاً لإصلاح المشكلات.
00:08:47يمكنك بعدها طلب مراجعة أخيرة من المخطط بمجرد تنفيذهم لكل شيء.
00:08:50في حالتنا، وجدوا بعض المشكلات الإضافية خلال المراجعة النهائية.
00:08:54وبعد معالجتها، أكد جميع الوكلاء
00:08:56أن المشكلات حُلت وأن التطبيق جاهز للبناء.
00:08:59لكن لا تبدأ بالبناء بعد. هناك خطوة إضافية يجب اتخاذها.
00:09:02تريد منهم مراجعة الخطط مع بعضهم البعض.
00:09:04تحتوي هذه الأداة على أوضاع متعددة للتجربة، ويجب عليك اختبار "وضع المخطط".
00:09:08يمكنك تجربة أوضاع مراجعة التصميم، ونقد الكود، وغيرها.
00:09:12تعمل هذه الأوضاع في 3 مراحل مع قيام نماذج مختلفة بأدوار متباينة.
00:09:16تحدد وكيل التخطيط كـ "مقدّم"، يعرض ما قام به سابقاً،
00:09:20ووكيل المراجعة كـ "متحدٍّ"، يقوم بانتقاد وتحدي ما يقوله المقدم.
00:09:24وكيل التخطيط يكون هو "المؤلف" الذي يجمع النتائج من الطرفين.
00:09:28تبدأ الجلسة بعرض المقدم، وبعدها يقوم المتحدي بالتحليل النقدي
00:09:32للنتائج واختبار تحمل المستندات، مكتشفاً الكثير من الثغرات.
00:09:36ولأن الوكلاء يستجوبون بعضهم البعض،
00:09:38فإنهم قادرون على تحديد وإصلاح العديد من المشكلات التي قد تمر دون ملاحظة.
00:09:42وبعد ذلك تحصل على الخطة النهائية، مما يمثل نهاية الجلسة المكونة من 3 مراحل.
00:09:46أيضاً، إذا كنتم تستمتعون بمحتوانا، فكروا في الضغط على زر الدعم (hype)،
00:09:50لأن ذلك يساعدنا على تقديم المزيد من المحتوى والوصول لجمهور أكبر.
00:09:54بمجرد انتهاء المراجعة، تطلب من المخطط أن يعمل كمنسق وينسق مع
00:09:58بقية الوكلاء لتنفيذ المشروع، باستخدام النماذج المناسبة لمهامهم.
00:10:03يقر المخطط بذلك ويجعل المصمم والبنّاء يعملان بالتوازي.
00:10:06ويرسل رسائل لكل من قناتي الخلفية والواجهة الأمامية، معطياً الضوء الأخضر
00:10:10للبنّاء للبدء، ومحرراً مهندس الواجهة الأمامية ليتمكن من تنفيذ التصميم.
00:10:15العمل بهذا الأسلوب ممتع جداً لأنك ببساطة تسلم
00:10:18المهمة لوكيل التخطيط ولا تحتاج إلا لمطالبته بالتحديثات.
00:10:22رؤية الوكلاء يعملون معاً أمر مذهل لأنهم ينبهون بعضهم عند وقوع أخطاء.
00:10:26مثلاً، في حالتنا، حاول مصمم الواجهة بالخطأ حل خطأ
00:10:30يقع ضمن مسؤولية البنّاء.
00:10:32أشار كل من المخطط والبنّاء إلى أنه لم يكن من المفترض قيامه بالإصلاح،
00:10:37لأنه كتب فوق الملف الذي كان البنّاء يعمل عليه.
00:10:39سير العمل هذا سيكون أكثر سلاسة إذا جعلت الوكلاء يعملون في مسارات عمل مخصصة،
00:10:44مع وجود وكيل واحد يدمج ويراجع كل شيء ككل،
00:10:47لأن ذلك سيقضي على مشكلة قيام الوكلاء بالكتابة فوق عمل بعضهم البعض.
00:10:50لذا، هذا أمر يجب وضعه في الاعتبار للإعدادات الأكثر تعقيداً.
00:10:53يقوم المخطط بعدها بتشغيل وكيل المراجعة، الذي يحدد المشكلات بالتفصيل،
00:10:57ويقدم تقريراً شاملاً، ويوزع المهام على الوكلاء.
00:11:01بما أننا وضعنا قاعدة مسبقاً تقضي بأنه إذا احتاج أي وكيل شيئاً من الآخر،
00:11:04فعليه أن يطلبه ببساطة، فقد طلب مصمم الواجهة الوصول لمتغير معين من البنّاء،
00:11:09وقام البنّاء بمنحه ذلك.
00:11:10بمجرد انتهاء المراجعة من جانبهم، يطلب منك المخطط إجراء المراجعة النهائية للواجهة.
00:11:15عندما تتوجه إلى خادم التطوير،
00:11:17ستجد أن الواجهة تطابق النسخة التفاعلية (gamified) التي أردتها.
00:11:20تتميز الصفحة الرئيسية بتباين عالٍ، مما يمنحها طابع الألعاب،
00:11:23وتستخدم كلمات حماسية وإشارات تجعل تجربتها مشوقة.
00:11:26بعد اختبار الكتابة، تتلقى تقريراً عن الأداء.
00:11:29تُعرض النتائج على لوحة التحكم، موضحةً أفضل سرعة تم تحقيقها،
00:11:33جنباً إلى جنب مع المستويات الحالية والتقدم، مما يجعل تجربة التصميم غامرة.
00:11:37بهذا نصل لنهاية هذا الفيديو. إذا كنتم ترغبون في دعم القناة
00:11:40ومساعدتنا في الاستمرار بتقديم مثل هذه الفيديوهات، يمكنكم فعل ذلك عبر زر "شكراً" أدناه.
00:11:45كما هو الحال دائماً، شكراً للمشاهدة وأراكم في الفيديو القادم.