كلاود يرفع مستوى قدرات وكلائه الذكيّة

AAI LABS
컴퓨터/소프트웨어경영/리더십AI/미래기술

Transcript

00:00:00هل كان الإصدار Opus 4.6 هو التحديث الوحيد من Anthropic؟
00:00:03أنت تعلم بالفعل عن الوكلاء الفرعيين (sub-agents)، حيث يعمل كل وكيل ككيان مستقل
00:00:07بنافذة سياق خاصة به.
00:00:09لكن هؤلاء الوكلاء فشلوا عندما تطلبت المهمة تنسيقاً بينهم.
00:00:13في تلك الحالات، كان على المنسق التدخل، حيث يأخذ الردود من وكيل ويفوضها
00:00:17إلى وكيل آخر، أو يضطر الوكلاء للاعتماد على الملاحظات في مجلد المشروع.
00:00:21بسبب فجوة التواصل هذه، كانت المهام البسيطة تصبح معقدة للغاية.
00:00:25ولمعالجة ذلك، أطلقت Anthropic تحديثاً جديداً للوكلاء الفرعيين وأطلقت عليهم اسم “فرق الوكلاء” (Agent-Teams).
00:00:30لقد تم إطلاقهم جنباً إلى جنب مع الإصدار Opus 4.6.
00:00:33على الرغم من أن هذه الميزة لا تزال تجريبية، إلا أننا طبقناها في سير عمل متعدد،
00:00:37وكان التحسن الأكبر هو تقليل الوقت الذي تستغرقه هذه المهام بشكل كبير.
00:00:41لكنها تجريبية لسبب ما ولا تزال بها بعض الثغرات، وقد وجدنا حلولاً بسيطة
00:00:44لهذه المشكلات أيضاً.
00:00:47فكرة فرق الوكلاء هي وجود عدة جلسات من ClodCode تعمل معاً.
00:00:51يعمل كل عضو في الفريق على مهام معزولة، مع وجود إدارة مركزية يتحكم بها
00:00:55وكيل واحد.
00:00:56الآن، قد تعتقد أن هذا يشبه إلى حد كبير الوكلاء الفرعيين لـ Clod الموجودين بالفعل لأن
00:01:00كلاهما يعمل بالتوازي ويقسم المهام، لكنهما ليسا متماثلين.
00:01:03وذلك لأن فرق الوكلاء حلت المشكلة الوحيدة التي كان يعاني منها إطار عمل الوكلاء الفرعيين.
00:01:08فالوكلاء الفرعيون لا يستطيعون التواصل مع بعضهم البعض ويضطرون للاعتماد على الوكيل المنسق
00:01:12ليعمل كوسيط تواصل بينهم.
00:01:15أما أعضاء الفريق، من ناحية أخرى، فهم قادرون على التواصل مع بعضهم البعض.
00:01:18الفكرة الجوهرية وراء فرق الوكلاء هي وجود عدة جلسات ClodCode تعمل معاً.
00:01:22إحدى الجلسات تعمل كقائد للفريق، تنسق العمل وتوزع المهام وتجمع النتائج،
00:01:27بينما يعمل أعضاء الفريق بشكل مستقل في نوافذ السياق الخاصة بهم.
00:01:31الوكلاء الفرعيون لديهم نافذة سياق خاصة بهم، ويقومون بإبلاغ النتيجة إلى المستدعي.
00:01:34لكن بالنسبة للفرق، فالأمر يعمل بشكل مختلف.
00:01:36كل عضو في فريق الوكلاء هو عبارة عن جلسة برمجية مستقلة تماماً.
00:01:40لا يتم تقييدهم أو تنسيقهم بواسطة منسق يكتفي بتقسيم المهام.
00:01:43بدلاً من ذلك، يتم فتح وإغلاق هذه الجلسات بواسطة قائد الفريق الرئيسي.
00:01:47وهم قادرون على العمل عبر المهام التي تتطلب نقاشاً وتعاوناً بين الوكلاء
00:01:52بسبب قدرتهم على التواصل.
00:01:54لذا، يتكون فريق الوكلاء أساساً من قائد فريق وأعضاء فريق.
00:01:57قائد الفريق هو الوكيل الرئيسي الذي ينشئ الفريق وينسق عملهم.
00:02:01وأعضاء الفريق هم العمال الذين ينفذون المهام بالفعل.
00:02:03يتلقى كل عضو في الفريق قائمة مهام، وهي قائمة مشتركة من البنود.
00:02:07يحدد كل عضو ما يحتاج إلى القيام به من هذه القائمة وينفذه.
00:02:10وللتواصل، لديهم أيضاً صندوق بريد مشترك يسمح لهم بإرسال الرسائل لبعضهم البعض.
00:02:15والآن السؤال هو كيف يعمل هذا بالفعل إذا كان كل عضو في الفريق مستقلاً.
00:02:19كيف يعرفون ما يفعله الأعضاء الآخرون؟
00:02:21يعمل هذا لأن جميع المعلومات المتعلقة بالفريق والأعضاء والمهام التي يعمل عليها
00:02:26كل عضو يتم تخزينها محلياً في مجلد “.claud” ويتم تعريفها باسم المهمة.
00:02:30هذه الميزة لا تزال تجريبية ومعطلة افتراضياً، لذا ستكون هناك بعض الأخطاء
00:02:34في التعامل مع أعضاء الفريق خلال هذه المرحلة.
00:02:36ولتجربتها، كان علينا تفعيلها يدوياً.
00:02:38لقد قمنا بذلك من خلال ضبط علامة (flag) واجهة أوامر claud code لفرق الوكلاء التجريبية على 1.
00:02:43مع تفعيل هذه العلامة، أصبحت فرق الوكلاء متاحة للاستخدام في الجلسات اللاحقة.
00:02:47وباستخدام هذه العلامة، تمكنا من الوصول إلى ميزة الفرق في claud code.
00:02:51بما أن هذه ميزة تجريبية، فقد احتجنا لاستخدام صياغة محددة تخبر
00:02:55claud بأننا نريد استخدام فريق الوكلاء لمهمة معينة.
00:02:58بدأ فريقنا باستخدام هذه الميزة للقيام بمراجعة الكود بشكل متوازٍ، مما يسمح بتحديد
00:03:02مشاكل الكود وإصلاحها في نفس الوقت.
00:03:04للقيام بذلك، طلبنا من claud استخدام أحد أعضاء الفريق للعثور على المشاكل في الكود
00:03:08وآخر لإصلاح المشاكل التي حددها العضو الأول.
00:03:11كان علينا أن نكون دقيقين في الأوامر لجعلها تسير في الاتجاه الصحيح.
00:03:15الآن، لو كان الوكلاء الفرعيون هم من يتعاملون مع هذا، لقاموا بكتابة تقرير في ملف
00:03:19مادي لإعلام الوكلاء الآخرين بما يجب إصلاحه.
00:03:21لكننا هنا أردنا تسريع عملية المراجعة من خلال السماح بحدوث ذلك دون عبء
00:03:26الكتابة في ملف محلي.
00:03:27عندما أعطينا الأمر لـ claud code، ظهر أعضاء الفريق، كل منهم تحت إشراف
00:03:31قائد الفريق.
00:03:32قام الوكيل القائد بإعطاء الأمر للوكلاء المنفردين، لإعلامهم بالمهمة التي يجب القيام بها.
00:03:36بدأ وكيل مراجعة الكود الأول بالعمل، وبعد تحليل المهمة، شارك الرسائل
00:03:40مع مصلح الكود خطأً تلو الآخر.
00:03:42كان هذا الوكيل يعطي الأولوية للقضايا الأمنية الحرجة، وبمجرد أن استلم مصلح الكود
00:03:47الرسائل من مراجع الكود، بدأ في تنفيذ الإصلاحات بينما استمر مراجع الكود
00:03:51في البحث عن المزيد من المشاكل.
00:03:53وبالمثل، استمروا في التحدث مع بعضهم البعض والإبلاغ عن التغييرات التي تم تنفيذها.
00:03:57بمجرد الانتهاء من المشاكل الحرجة، انتقل الوكيلان نحو إصلاح المشاكل
00:04:01ذات الأولوية المتوسطة.
00:04:02كانت مراجعة الكود وإصلاحه تتم في وقت واحد، مما وفر الكثير من الوقت.
00:04:06الشيء الجيد في هذا هو أنه يمكنك أيضاً تعيين أو تعديل أي مهمة لعضو في الفريق.
00:04:10مع تفعيل هذا، يمكنك توجيه مسار عمل ذلك العضو المحدد في الفريق.
00:04:14بمجرد انتهاء الوكلاء من العمل، تمت إعادة التحكم إلى الوكيل الرئيسي، وهو
00:04:18المسؤول عن التأكد من تنفيذ التغييرات المطلوبة بشكل صحيح وإيقاف
00:04:22هؤلاء الوكلاء بسلاسة، لضمان أن خروجهم لا يسبب أخطاء لاحقاً.
00:04:26ربما لاحظتم أننا نبني الكثير من الأشياء في هذه الفيديوهات.
00:04:28كل الأوامر، والبرمجيات، والقوالب، الأشياء التي تضطر عادةً
00:04:32لإيقاف الفيديو مؤقتاً ونسخها من الشاشة، كلها موجودة في مجتمعنا، لهذا الفيديو
00:04:36ولكل فيديو سبقه أيضاً.
00:04:37الروابط في الوصف.
00:04:38العثور على المشاكل وإصلاحها على نطاق واسع أمر رائع، ولكن غالباً ما تكون هناك حالات تواجه فيها مشاكل
00:04:43ولا يمكنك ببساطة معرفة سببها.
00:04:45في تلك الحالات، يمكننا استخدام فريق وكلاء لاختبار وجهات نظر متعددة لنفس التطبيق
00:04:49والعمل تدريجياً نحو حل الخطأ.
00:04:51بهذه الطريقة، يمكن لأعضاء الفريق إيصال نتائجهم لبعضهم البعض والمضي قدماً معاً.
00:04:55طلبنا من Claude العثور على خطأ في الكود وحددنا استخدام عدة أعضاء في الفريق،
00:04:59ليقاربوا المشكلة من وجهات نظر مختلفة.
00:05:02عندها أنشأ أربعة وكلاء فرعيين، ركز كل منهم على منظور مختلف لنفس التطبيق.
00:05:06تلقوا أوامر مماثلة من قائد الفريق وحققوا في الأخطاء بناءً على
00:05:09جانبهم المحدد من التطبيق، بينما انتظر القائد الرئيسي انتهاءهم ثم
00:05:14قام بتحليل النتائج التي توصلوا إليها.
00:05:16بدون الفرق، كان سيكون لدينا مسار واحد، وهو ما كان سيستغرق وقتاً أطول بكثير.
00:05:19لكن مع هؤلاء الوكلاء، كانت العملية أسرع بكثير.
00:05:22اكتمل التحقيق بسرعة، وتم إجراء كل أبحاث الوكلاء في حوالي
00:05:27دقيقتين إلى ثلاث دقائق، وهو تحسن كبير مقارنة بالفحص المتسلسل الذي كان
00:05:31سيستغرق بسهولة من 5 إلى 10 دقائق.
00:05:33شيء واحد يجب الانتباه إليه هو أن هذا النهج يستهلك الكثير من الرموز (tokens)، لأن كل وكيل
00:05:37لديه نافذة سياق خاصة به، لذا علينا الحذر بشأن ذلك.
00:05:40بمجرد أن قدم الوكلاء نتائجهم وتم إيقافهم، قام قائد الفريق أيضاً بالتحقق
00:05:45من النتائج بنفسه.
00:05:46اتفق الوكلاء الأربعة على نفس الخطأ، وأشاروا بشكل صحيح إلى المشكلة المتعلقة
00:05:50بإغلاق قديم (stale closure) في الـ use effect.
00:05:52هذا الجزء تحديداً تم تحديده من قبل جميع الوكلاء الأربعة.
00:05:54أيضاً، إذا كنتم تستمتعون بمحتوانا، فكروا في الضغط على زر الإعجاب، لأنه يساعدنا
00:05:59على إنشاء المزيد من المحتوى كهذا والوصول إلى المزيد من الأشخاص.
00:06:02لقد غيّر إطار عمل الوكلاء هذا طريقة عملنا في المهام طويلة المدى، لأنه بفضل قدراتهم،
00:06:07لا يضطر الوكلاء للاعتماد على توثيق تقدمهم فقط.
00:06:10مع فرق الوكلاء، يمكننا التعامل مع جوانب مختلفة من التطبيق بالتوازي،
00:06:14وكذلك تخصيص عضو للتعامل مع البحث.
00:06:16عندما أعطينا Claude الأمر، قام بإنشاء 6 وكلاء.
00:06:19اثنان يعملان على البحث ووضع الأسس، بينما البقية لبناء
00:06:23الصفحات.
00:06:24تم إيقاف وكلاء البناء بواسطة الوكيل الذي يضع الأساس، لأنه كان مسؤولاً
00:06:28عن تثبيت الحزم المطلوبة وتجهيز البيئة بجميع التبعيات.
00:06:32تلقى كل وكيل أمراً محدداً يحدد وظيفته.
00:06:35ظل الوكلاء الموقوفون ينتظرون إشارة فك الحظر من قائد الفريق.
00:06:38بمجرد اكتمال البحث والأساسات، تم فك حظر الوكلاء المتبقين وبدأوا
00:06:43في تنفيذ أجزائهم الخاصة من التطبيق جنباً إلى جنب.
00:06:46استمروا في التواصل مع بعضهم البعض لضمان الاتساق بين كل مكون.
00:06:49استمر قائد الفريق في التنسيق مع الوكلاء، وبمجرد انتهاء أي وكيل، أرسل
00:06:53قائد الفريق رسالة إيقاف لهذا الوكيل، للتعامل مع خروجه بسلاسة.
00:06:57استهلكت هذه العملية بالكامل حوالي 170 ألف رمز من نافذة السياق، ولكن في النهاية،
00:07:02حصلنا على التطبيق مبنياً تماماً كما أردنا، كل ذلك من أمر واحد فقط.
00:07:05كما ذكرنا في الفيديو، عندما كان فريقنا يختبر هذا، توصلنا إلى عدة
00:07:09طرق لجعل فرق الوكلاء تعمل بشكل أفضل بالنسبة لنا، ومرة أخرى، تتوفر أفضل الممارسات هذه
00:07:13في AI Labs Pro، لتمكينكم من تجربتها بأنفسكم.
00:07:16التوصية الأولى قابلة للتطبيق بشكل عام على جميع الوكلاء، وليست محدودة فقط
00:07:20بميزة فرق الوكلاء.
00:07:21تحتاج إلى تحديد نطاق عمل الوكيل بدقة.
00:07:25يمكنك فعل ذلك إما من خلال تحديده في الأمر، بتحديد الملفات التي يجب البحث فيها
00:07:29للقيام بالمهمة، أو بإنشاء مستندات في المشروع تحتوي على المهام
00:07:33الفردية كما فعلنا في سير عملنا، حيث أعددنا مستند مهام مناسباً لكل مهمة
00:07:38حتى يتمكن الوكيل من العمل بشكل مستقل وضمن النطاق الصحيح.
00:07:41شيء آخر يجب مراعاته هو أن كل وكيل من هؤلاء يجب أن يعمل على مهام مستقلة
00:07:45عن الآخرين، لأنه إذا قاموا بتعديل نفس الملف في وقت واحد،
00:07:49فسيؤدي ذلك إلى تعارض وقد يؤدي إلى الكتابة فوق المحتوى.
00:07:52علاوة على ذلك، كانت هناك أوقات وجدنا فيها أن الوكيل الرئيسي قد يفقد صبره
00:07:56إذا استغرق أي وكيل وقتاً طويلاً لإكمال المهمة ويبدأ في تنفيذ المهمة بنفسه
00:08:00بدلاً من ترك أعضاء الفريق يكملونها، لذا من المهم تذكير الوكيل الرئيسي
00:08:04بالانتظار حتى يكمل أعضاء الفريق مهامهم قبل المتابعة.
00:08:06تحتاج أيضاً إلى تحديد حجم المهام بشكل مناسب.
00:08:08فإذا قمت بتعيين مهام صغيرة جداً، فإن ذلك يخلق عبئاً في التنسيق.
00:08:11وإذا كانت المهام كبيرة جداً، فإنها تزيد من خطر ضياع الجهد، لذا يجب أن تكون المهام متوازنة
00:08:16ومستقلة بذاتها.
00:08:17أخيراً، عليك مراقبة عمل الوكلاء.
00:08:19إذا كان أي وكيل لا يؤدي كما هو متوقع، يمكنك إيقاف تنفيذه وإعطاؤه
00:08:23تعليمات جديدة حول ما يجب عليه فعله.
00:08:25اتباع هذه الممارسات يجعل استخدام هذه الميزة التجريبية أكثر فعالية بكثير.
00:08:29هذا يوصلنا إلى نهاية هذا الفيديو.
00:08:31إذا كنت ترغب في دعم القناة ومساعدتنا في الاستمرار في صنع فيديوهات كهذه، يمكنك فعل
00:08:35ذلك باستخدام زر الشكر أسفل الفيديو.
00:08:38كما هو الحال دائماً، شكراً للمشاهدة وسأراكم في الفيديو القادم.

Key Takeaway

تمثل ميزة "فرق الوكلاء" في تحديث Claude Opus 4.6 قفزة نوعية في الإنتاجية من خلال تمكين الوكلاء الذكيين من التواصل والتعاون المتوازي تحت قيادة مركزية لإنهاء المهام المعقدة بسرعة فائقة.

Highlights

التحول من نموذج "الوكلاء الفرعيين" التقليديين إلى إطار عمل "فرق الوكلاء" (Agent-Teams) الأكثر تطوراً.

الميزة الجوهرية لفرق الوكلاء هي قدرتهم على التواصل المباشر وتبادل الرسائل عبر صندوق بريد مشترك.

تقليل الوقت المستغرق في مهام مراجعة الكود وحل الأخطاء بنسبة تصل إلى 50% مقارنة بالفحص المتسلسل.

تفعيل الميزة يتطلب ضبط علامة تجريبية في واجهة أوامر Claude Code واستخدام صياغة برمجية محددة.

أهمية تحديد نطاق عمل كل وكيل بدقة وتجنب التداخل في تعديل الملفات لمنع التعارض التقني.

استهلاك الرموز (Tokens) يزداد مع استخدام عدة وكلاء، حيث يمتلك كل عضو نافذة سياق مستقلة.

Timeline

مقدمة وتطور الوكلاء في Anthropic

يبدأ الفيديو باستعراض التحديث الجديد من شركة Anthropic تزامناً مع إطلاق الإصدار Opus 4.6. يوضح المتحدث الفرق بين الوكلاء الفرعيين القدامى الذين عانوا من ضعف التنسيق وبين المفهوم الجديد المسمى "فرق الوكلاء". كانت المشكلة الأساسية سابقاً تكمن في فجوة التواصل التي تجعل المهام البسيطة معقدة وتطلب تدخلاً بشرياً أو وسيطاً. يهدف هذا التحديث التجريبي إلى سد هذه الفجوة وتقليل الوقت المستغرق في تنفيذ العمليات بشكل كبير. يتم التأكيد على أن الميزة لا تزال في مراحلها الأولى وتحتاج لبعض الحلول البسيطة لتجاوز ثغراتها.

آلية عمل فرق الوكلاء والفرق عن الوكلاء الفرعيين

يشرح هذا القسم الهيكلية التقنية لفرق الوكلاء التي تعتمد على وجود عدة جلسات Claude Code تعمل في آن واحد. يتميز هذا النظام بوجود "قائد فريق" يدير العمليات مركزياً بينما يعمل الأعضاء في مهام معزولة ولكنها متصلة. الفارق الجوهري هو قدرة أعضاء الفريق على التواصل المباشر فيما بينهم دون الحاجة لوسيط، وهو ما لم يكن متاحاً في الوكلاء الفرعيين. يمتلك الفريق أدوات مشتركة مثل قائمة المهام وصندوق بريد لتبادل الرسائل، مما يسهل توزيع الأدوار بوضوح. يتم تخزين كافة البيانات المتعلقة بالفريق محلياً في مجلد خاص يسمى .claud لضمان استمرارية العمل.

التفعيل العملي واستخدام الفرق في مراجعة الكود

يتناول هذا الجزء كيفية تفعيل الميزة يدوياً عن طريق ضبط علامة معينة (flag) في واجهة الأوامر لأنها معطلة افتراضياً. يستعرض المتحدث تجربة عملية لمراجعة الكود وإصلاحه بشكل متوازٍ باستخدام وكيلين تحت إشراف القائد. يقوم الوكيل الأول بتحديد الثغرات الأمنية ويرسلها فوراً للوكيل الثاني الذي يبدأ الإصلاح دون انتظار انتهاء عملية الفحص بالكامل. هذا التعاون اللحظي يلغي الحاجة لكتابة تقارير وسيطة ويوفر وقتاً ثميناً للمبرمجين. تنتهي العملية بإعادة التحكم للوكيل الرئيسي الذي يتحقق من جودة التعديلات ويغلق الجلسات بسلامة.

حل الأخطاء المعقدة وبناء التطبيقات المتوازي

ينتقل الفيديو لإظهار قوة الفرق في معالجة الأخطاء البرمجية الصعبة عبر فحصها من وجهات نظر متعددة في وقت واحد. تم استخدام أربعة وكلاء لتحليل تطبيق واحد، مما قلص زمن التحقيق من 10 دقائق إلى دقيقتين فقط. يذكر المتحدث مثالاً آخر لبناء تطبيق كامل من أمر واحد، حيث تم توزيع 6 وكلاء بين البحث وتأسيس البيئة وبناء الصفحات. رغم استهلاك حوالي 170 ألف رمز (token) في هذه العملية، إلا أن النتيجة كانت تطبيقاً متكاملاً ومبني بدقة. يشدد هذا القسم على أن التواصل بين الوكلاء يضمن اتساق المكونات البرمجية ويمنع التشتت.

أفضل الممارسات والنصائح لتحسين الأداء

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

Community Posts

View all posts