التعاون متعدد الوكلاء

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

لا يقتصر جمع عدة وكلاء على جعل متخصصين مختلفين يسد بعضهم ثغرات بعض، بل يستند إلى فكرة أعمق: قد يتجاوز ذكاء الجماعة ذكاء أي فرد فيها. والحضارة الإنسانية خير دليل؛ فذكاء الفرد محدود، لكن تقسيم العمل والتعاون والنقاش وتراكم المعرفة عبر الأجيال منح المجتمع قدرة تفوق أي عبقرية منفردة. وقد تنتج مجموعات الوكلاء صورة مشابهة من الذكاء الجمعي: فحتى إن لم يتجاوز كل وكيل مستوى خبير بشري، قد تحقق مجموعة محكمة التنظيم قدرات أوسع بكثير. وفي ورقة من AGI إلى ASI، تضع Google DeepMind «المجموعات واسعة النطاق متعددة الوكلاء» ضمن المسارات الرئيسية إلى الذكاء الفائق؛ فكما يتجمع الذكاء البشري في مجتمعات ومنظمات تتجاوز أفرادها، قد تولّد مجموعة من وكلاء AGI قدرة معرفية تتجاوز مجموع قدرات أعضائها¹. ومن ثم فالتعاون متعدد الوكلاء ليس مجرد حل هندسي لحدود النموذج ونافذة السياق، بل قد يكون طريقًا أساسيًا من ذكاء بمستوى الخبير إلى ذكاء يتجاوز القدرة البشرية الجمعية.

إطار تصنيف للتعاون متعدد الوكلاء

يبدأ تصميم المنظومة متعددة الوكلاء بقرارين أساسيين يحددان معًا بنيتها وطريقة تنفيذها.

البعد 1: السياق المشترك مقابل السياق غير المشترك

هذا هو القرار المعماري الأساسي الذي يحدد كيفية تمرير المعلومات بين الوكلاء المتعددين.

السياق المشترك يعني أن الوكيل اللاحق يتلقى سجل المحادثة الكامل ومساره (كما هو محدد في الفصل 1) للوكيل السابق. عندما يتغير موجّه النظام ومجموعة الأدوات في كل مرحلة، يعامل النظام المرحلة الجديدة كوكيل مختلف لأن هويته ومسؤولياته وقدراته قد تغيرت، على الرغم من احتفاظه بكل ذاكرة سابقته. على سبيل المثال، بعد أن يكتب محلل المتطلبات مستند المتطلبات، لا يتلقى المطور المستند فحسب، بل يتلقى أيضًا السجل الكامل للاتصالات بين المحلل والمستخدم. يتولى المطور دورًا جديدًا مع الاحتفاظ بكل السياق السابق. الميزة هي عدم فقدان أي معلومات؛ يمكن لكل وكيل مراجعة التفاصيل من أي مرحلة سابقة. ويتمثل التحدي في أن السياق يمكن أن يتوسع بسرعة.

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

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

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

وإذا أسقطنا هذه الآليات على نموذجي الاتصال بين العمليات (IPC)، كان نظام الملفات المشترك نظيرًا للذاكرة المشتركة، وكانت معاملات استدعاء الأدوات وناقل الرسائل صورتين من تمرير الرسائل. تُمرَّر معاملات الأداة بالتزامن مع الاستدعاء، أما رسائل الناقل فيسلّمها وسيط على نحو غير متزامن. ولكل نموذج كلفته وفوائده. ومن العبارات الشائعة في مجتمع Go: «لا تتواصل بمشاركة الذاكرة؛ بل شارك الذاكرة بالتواصل». فالذاكرة المشتركة سريعة، لكنها تلقي على المطور عبء ضبط التزامن، بينما يحتاج تمرير الرسائل إلى مزيد من شفرات التنسيق لكنه يُبقي ملكية البيانات واضحة وقابلة للتتبع. وسنرى هذه المقايضة مجددًا عند مناقشة الاستعلام عن الحالة وتعارضات التزامن.

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

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

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

قد يجد القراء المطلعون على أنظمة التشغيل تشبيهًا مفيدًا: يشبه وكلاء السياق المشترك الخيوط، بينما يشبه وكلاء السياق غير المشترك العمليات. تشترك الخيوط في مساحة عنوان، مما يجعل التبديل والاتصال غير مكلف ولكنه يوفر القليل من العزلة؛ يمكن أن يؤدي تلف الذاكرة في مؤشر ترابط واحد إلى تعطل العملية بأكملها. كل عملية لها مساحة عنوان خاصة بها، مما يوفر عزلة أقوى وتوازيًا أكثر أمانًا، ولكن يجب أن يستخدم الاتصال IPC بشكل واضح. وتنبع المعايير الواردة في الجدول 10-1 من هذه المفاضلات.

ويلخص الجدول 10-1 معايير الاختيار للمعماريتين من خمس وجهات نظر: عدد المهام الفرعية، ونافذة السياق، والتوازي، وعزل المعلومات، وموازنة التكلفة. يمكن أن تكون بمثابة قائمة مرجعية للاختيار المعماري المبكر.

جدول 10-1 معايير الاختيار للسياق المشترك مقابل السياق غير المشترك

معيار الاختيار	السياق المشترك	السياق غير المشترك
عدد المهام الفرعية	قليل (2-3 أدوار)	متعدد (يلزم معالجة متوازية)
نافذة السياق	يمكن أن تستوعب المعلومات لجميع الأدوار	النافذة الواحدة غير كافية
التوازي	تسلسلي في الغالب؛ تتناوب الأدوار على المسار نفسه	قابل للتوسع بالتوازي؛ فالسياقات مستقلة ولا تعيق بعضها
عزل المعلومات	غير مطلوب (جميع الأدوار تشارك المعلومات)	مطلوب (على سبيل المثال، يجب ألا تتلقى المراجعة الأمنية السياق الداخلي للوكلاء الآخرين)
ميزانية التكلفة	مسار واحد يتم ترحيله عبر المراحل؛ تتراكم الرموز مرحلة بعد مرحلة	يعمل الوكلاء المتعددون بشكل مستقل؛ عادةً ما يكون إجمالي الرموز المميزة عدة مرات أعلى من حيث الحجم

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

البعد الثاني: طوبولوجيا التعاون

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

ملاحظة مصطلحية: Graph Engineering. يشير مصطلح «Graph Engineering»، الذي شاع في يوليو 2026، في سياق الوكلاء الحالي عادةً إلى التصميم الصريح لرسم التنفيذ: تكون العُقد وكلاء أو برامج عادية أو قرارات بشرية، وتحدد الحواف اعتماديات المهام والتوجيه الشرطي ومسارات الفشل، وتتدفق الحالة المهيكلة بين العُقد². وتمثل «طوبولوجيا التعاون» التي يناقشها هذا الفصل الجزء متعدد الوكلاء من هذه الفكرة؛ فالتعاون بين النظراء، وتنسيق المدير، وعمليات التسليم اللامركزية طوبولوجيات رسم مختلفة. ولأن الاسم لا يزال حديثًا ويسهل الخلط بينه وبين الرسوم المعرفية وGraphRAG ومسارات التنفيذ المسجلة، يواصل هذا الكتاب استخدام المصطلحين الأكثر استقرارًا: «طوبولوجيا التعاون» و«التنسيق».

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

• نمط التعاون بين النظراء: يتفاعل عدد صغير من الوكلاء (عادةً 2-3) على قدم المساواة، مما يشكل حلقة تحسين متكررة - مثل كتابة ورقة حيث يقوم شخص واحد بصياغتها ويقوم شخص آخر بتعليقها ومراجعتها، مع جودة بعد عدة جولات تتجاوز بكثير ما يمكن أن يحققه شخص واحد بمفرده.
• نمط المدير (نمط التنسيق): يتولى وكيل المدير المركزي مسؤولية تخطيط المهام وجدولتها، بينما يتعامل كل من الوكلاء الفرعيين المتعددين مع مهام فرعية محددة - مثل مدير المشروع الذي يقود العديد من المهندسين المتخصصين في المشروع.
• النمط اللامركزي: لا توجد وحدة تحكم مركزية لوقت التشغيل؛ يتواصل الوكلاء مع بعضهم البعض مثل البشر للتعاون في المهام.

ستتم مناقشة التصميم التفصيلي والسيناريوهات القابلة للتطبيق لكل نمط في أقسام فرعية مخصصة لاحقًا.

متى يكون الوكيل المتعدد أفضل حقًا من الوكيل الفردي؟

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

يوضح الجدول 10-2 أوضاع التعاون التي تقدم معلومات جديدة وتساعد في تقييم ما إذا كان التعاون متعدد الوكلاء يوفر قيمة جوهرية على وكيل واحد.

جدول 10-2 مقارنة الحصول على المعلومات بين أوضاع التعاون متعدد الوكلاء

وضع التعاون	يقدم معلومات جديدة؟	تأثير
المراجعة الذاتية لنفس النموذج (إعادة قراءة مخرجاته الخاصة)	لا	عادة ما تكون غير فعالة أو حتى ضارة
وكلاء مختلفون يناقشون نفس النص	لا	يمكن مقارنته بوكيل واحد يتمتع بحساب متساوٍ
يستخدم المراجع نتائج تنفيذ الاختبار لمراجعة التعليمات البرمجية	نعم (تعليقات التنفيذ)	تحسن كبير
يستخدم المراجع لقطات الشاشة المقدمة لمراجعة كود الواجهة الأمامية/PPT	نعم (تعليقات مرئية)	تحسن كبير
يستخدم المراجع أدوات خارجية للتحقق من الحقائق	نعم (تعليقات الأداة)	تحسن كبير

أظهرت ورقة RLEF لعام 2025، أي التعلم المعزز من ملاحظات التنفيذ³، أن تدريب النموذج على الاستفادة من نتائج تشغيل الشفرة في التحسين التكراري يتفوق بوضوح على أخذ عينات مستقلة منه مرات عدة. والسبب أن كل دورة تضيف دليلًا حقيقيًا من التنفيذ، مثل أخطاء الترجمة البرمجية وفشل الاختبارات واستثناءات وقت التشغيل؛ وهي معلومات لم تكن متاحة حين كتب النموذج الشفرة أول مرة. وفي مهام إنشاء صفحات الويب، أفادت دراسة WebGen-Agent لعام 2025⁴ بأن التغذية الراجعة المرئية متعددة المستويات، التي تجمع لقطات الشاشة بأوصاف نموذج لغوي بصري، رفعت نتيجة Claude 3.5 Sonnet في المعيار من 26.4% إلى 51.9%، أي قاربت مضاعفة الأداء.

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

ميزانية الخطوة وأداء الوكيل. هناك سؤال ذو صلة وهو كيف تؤثر ميزانية خطوة الوكيل - عدد استدعاءات الأداة أو جولات التكرار التي قد يستخدمها - على الأداء. قد يبدو من المؤكد أن المزيد من الخطوات ستساعد: مع 30 خطوة، قد يكون لدى الوكيل الوقت فقط لتنفيذ الوظائف الأساسية، في حين أن 300 خطوة تسمح له بالتخطيط والتنفيذ والاختبار والتحسين. ومع ذلك، توصلت دراسة Google لعام 2025 استخدام الأدوات المدركة للميزانية إلى تمكين توسيع نطاق الوكيل الفعال إلى نتيجة غير بديهية: مجرد إعطاء الوكيل المزيد من الخطوات لا يضمن أداء أفضل. يفتقر الوكلاء القياسيون إلى "الوعي بالميزانية"؛ حتى مع 300 خطوة، فإنهم يميلون إلى إجراء عمليات بحث سطحية والوصول بسرعة إلى الهضبة. لاستخدام الخطوات الإضافية بفعالية، يحتاج الوكلاء إلى آلية تعمل على تكييف استراتيجيتهم مع الموارد المتبقية، والاستكشاف على نطاق واسع في البداية وتضييق نطاق تركيزهم لاحقًا. قدم نهج BAVT (البحث في شجرة القيمة المدركة للميزانية) لعام 2026 تقييمًا للقيمة على مستوى الخطوة، وضبط التوازن بين الاستكشاف والاستغلال وفقًا لنسبة الميزانية المتبقية. ومع انخفاض الميزانية، ينتقل الوكيل من الاستكشاف الواسع إلى التحقيق الأعمق.

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

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

تعاون متعدد الوكلاء مع سياق مشترك

في التعاون متعدد الوكلاء مع سياق مشترك، تكون كل مرحلة وكيلًا مستقلاً (مع موجّه النظام الخاص بها ومجموعة الأدوات الخاصة بها)، ولكنها ترث المسار الكامل للوكيل السابق - تمامًا مثل زميل يتولى نوبة عمل ويمكنه تصفح كل سجل عمل تركه سلفه وراءه. الميزة الأساسية لهذا التعاون القائم على الميراث هي عدم فقدان المعلومات: يمكن لكل وكيل مراجعة التفاصيل من أي مرحلة سابقة. يتمثل التحدي في إبقاء الوكيل الحالي يركز على مسؤولياته الخاصة بدلاً من تشتيت انتباهه بسبب كتلة التاريخ الموروث.

تبديل الأدوار متعدد المراحل

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

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

التجربة 10-1 ★★: تحديد موجّهات النظام بناءً على مرحلة التنفيذ

توضح هذه التجربة كيف يمكن لموجّهات النظام الخاصة بالمرحلة تحسين الأداء عبر سير عمل وكيل البرمجة الكامل.

سيناريو المهمة: يرسل المستخدم طلب تطوير برنامج، ويمر الوكيل عبر ثلاث مراحل: توضيح المتطلبات، وتنفيذ التعليمات البرمجية، ومراجعة الجودة.

المرحلة الأولى: توضيح المتطلبات (الدور: محلل المتطلبات)

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

مجموعة الأدوات محدودة: ask_clarifying_question(question) لطرح أسئلة توضيحية على المستخدم، وsave_requirement(key, value) لتسجيل المتطلبات المؤكدة، وcomplete_requirements_analysis() لوضع علامة على اكتمال المرحلة.

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

المرحلة الثانية: تنفيذ التعليمات البرمجية (الدور: مهندس برمجيات)

يؤكد موجّه النظام الجديد على ما يلي: - "مسؤوليتك هي كتابة كود Python عالي الجودة بناءً على المتطلبات المؤكدة." - "اتبع أفضل الممارسات: اجعل التعليمات البرمجية معيارية، وتعامل مع الأخطاء بشكل مناسب، وقم بتضمين التعليقات حيثما تكون مفيدة." - "بعد الانتهاء من الكود واجتياز الاختبارات الأساسية، اتصل بـ submit_for_review() للدخول إلى مرحلة المراجعة."

تتغير الأدوات أيضًا: يتم استبدال أدوات توضيح المتطلبات بأدوات التطوير مثل write_file(path, content) وread_file(path) وexecute_code(code). باستخدام المتطلبات المسجلة في المرحلة الأولى، يكتب الوكيل المنطق الأساسي ويضيف معالجة الأخطاء وينشئ الاختبارات. لا يزال بإمكانه الرجوع إلى المحادثة السابقة للحصول على تفاصيل المتطلبات، ولكنه يركز الآن فقط على التنفيذ بدلاً من طرح المزيد من الأسئلة. عند الانتهاء، فإنه يستدعي submit_for_review().

المرحلة 3: مراجعة الكود (الدور: مراجع الكود)

يؤكد موجّه النظام الجديد على ما يلي: - "راجع التعليمات البرمجية للتأكد من صحتها الوظيفية والالتزام بمعايير الترميز ومعالجة الأخطاء والأداء والأمان." - "اتخذ نهجًا نقديًا وحدد المشكلات والفرص المحتملة لتحسين الكود." - "إذا تم العثور على مشكلات خطيرة، فاتصل بـ request_revision(issues) للعودة إلى مرحلة التنفيذ للتعديل؛ وإذا كانت الجودة مقبولة، فاتصل بـ approve_code() لإكمال المهمة."

تتغير مجموعة الأدوات مرة أخرى: يتم استبدالها بأدوات تحليل جودة التعليمات البرمجية مثل run_linter(file) وrun_tests(file) وanalyze_complexity(file). يقوم الوكيل بإعادة فحص التعليمات البرمجية من وجهة نظر المراجع، وإجراء تحليل ثابت، والتحقق من الأخطاء المحتملة، أو مشكلات الأداء، أو المخاطر الأمنية.

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

متطلبات التجربة: 1. قم بتنفيذ موجّهات النظام المكونة من ثلاث مراحل، ولكل منها تعريف واضح للدور وتوجيه سلوكي 2. تكوين مجموعات الأدوات المطابقة لكل مرحلة 3. تنفيذ آلية تشغيل المرحلة الانتقالية (عبر استدعاءات أدوات محددة) 4. ضمان استمرارية السياق بين المراحل 5. تعامل مع سيناريوهات التراجع - عندما تجد مراجعة التعليمات البرمجية مشكلات، ارجع إلى مرحلة التنفيذ 6. قم بتسجيل النشاط من كل مرحلة لتوضيح كيف تنتج الموجّهات المختلفة سلوكًا مختلفًا

تبديل الأدوار عبر المجال

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

التجربة 10-2 ★★: التبديل متعدد الأدوار

المتطلبات الأساسية: من المستحسن أن يقوم القراء أولاً بمراجعة آلية مهارات الوكيل في الفصل الثاني.

بنية النظام: تم تحديد خمسة أدوار:

• الفرز (مكتب الاستقبال؛ نقطة الإدخال الافتراضية): يحدد احتياجات المستخدم الإجمالية، ويقسم العمل إلى مهام فرعية متسلسلة، ويوجه كل مهمة فرعية إلى المتخصص المناسب، ويجري فحصًا نهائيًا عند اكتمال جميع المهام الفرعية. أداتها الوحيدة هي transfer_to_agent.
• البحث (خبير استرجاع المعلومات): يستخدم web_search للعثور على البيانات والحقائق والمواد.
• الترميز (خبير برمجة): يستخدم execute_python لكتابة التعليمات البرمجية وتشغيلها لمهام البرمجة والبرمجة النصية.
• تحليل البيانات (خبير تحليل البيانات): يستخدم calculate / descriptive_stats للحسابات والإحصائيات الكمية (على سبيل المثال، معدل النمو على أساس سنوي، ومعدل النمو السنوي المركب (CAGR)، والمتوسط).
• الكتابة (خبير الكتابة): يحول البيانات المستردة والنتائج التحليلية إلى مسودة واضحة مصممة خصيصًا للجمهور (ويمكن استخدام count_characters لإجراء فحص تقريبي).

الآلية الأساسية: أداة transfer_to_agent

تحتوي جميع الأدوار على أداة transfer_to_agent(target_role, reason). عندما يستدعيه أحد الأدوار، يقوم النظام بحفظ سجل المحادثة الحالي، وتحميل موجّه الدور المستهدف ومجموعة الأدوات، وتمرير السجل إلى هذا الدور، واستئناف التنفيذ.

سيناريو التجربة: يبدأ النظام في الدور triage بشكل افتراضي. يرسل المستخدم مهمة تشمل عدة مجالات: "أقوم بإعداد المواد للمستثمرين. ساعدني في البحث عن مبيعات مركبات الطاقة الجديدة في الصين للأعوام 2021 و2022 و2023، وحساب معدل النمو السنوي المركب لهذه السنوات الثلاث، ثم اكتب ملخصًا باللغة الصينية للمستثمرين، بما لا يزيد عن 120 حرفًا." triage يقسمها إلى "البحث عن البيانات ← حساب المقاييس ← كتابة المسودة" ويسلمها أولاً إلى research:

transfer_to_agent(target_role="research", reason="البحث عن أرقام المبيعات السنوية لمركبات الطاقة الجديدة للفترة 2021-2023")

يستخدم research web_search للعثور على أرقام المبيعات، ويضيف البيانات الأساسية إلى المحادثة، ويسلم المهمة إلى data_analysis:

transfer_to_agent(target_role="data_analysis", reason="البيانات جاهزة؛ احسب معدل النمو السنوي المركب من 2021 إلى 2023")

يستخدم data_analysis calculate لحساب معدل النمو. ثم يقوم بعد ذلك بتسليم المهمة إلى writing، الذي يقوم بصياغة الملخص وإعادته إلى triage للتأكيد النهائي. السلسلة الكاملة هي triage → research → data_analysis → writing → triage. يمكن لكل دور رؤية سجل المحادثة بالكامل، وبالتالي فإن الدور التالي يعرف بطبيعة الحال ما تم إنجازه بالفعل.

يعتمد قرار تبديل الأدوار على التوجيهات الواردة في النظام. يسرد موجّه triage قواعد التوجيه صراحةً: البحث عن البيانات أو المادة المصدر → research؛ كتابة الشفرة وتشغيلها → coding؛ إجراء الحسابات والتحليلات الإحصائية → data_analysis؛ صقل المادة وتحويلها إلى مسودة → writing. وينبغي تسليم المهمة عندما تتطلب خبرة عميقة في مجال معين أو أدوات متخصصة. كما يحدد موجّه كل متخصص الدور المناسب التالي، أو يرشده إلى إعادة المهمة إلى triage.

متطلبات التجربة: 1. قم بتنفيذ موجّهات النظام ومجموعات الأدوات المتخصصة لثلاثة أدوار مهنية على الأقل 2. قم بتنفيذ أداة transfer_to_agent التي تدعم التبديل الديناميكي 3. ضمان استمرارية السياق بعد تبديل الأدوار 4. منع عمليات التسليم الدائرية التي تتسبب في قيام الوكيل بالتبديل بشكل متكرر بين الأدوار 5. قم بتصميم تدفقات المهام المعقدة التي تغطي مجالات متعددة لتوضيح قيمة تبديل الأدوار

تعاون متعدد الوكلاء بدون سياق مشترك

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

في وقت سابق من هذا الفصل، قمنا بمقارنة آليات الاتصال بأشكال الاتصال بين العمليات والسياق المشترك مقابل السياق المعزول بالخيوط مقابل العمليات. ويمكن توسيع هذا التشبيه أكثر (الجدول 10-3):

جدول 10-3 المراسلات بين الأنظمة متعددة الوكلاء وأنظمة التشغيل

نظام التشغيل	نظام متعدد الوكلاء
البرنامج (ملف قابل للتنفيذ)	البادئة الثابتة (موجّه النظام + تعريفات الأداة)
ذاكرة العملية	المسار
وحدة المعالجة المركزية	LLM
نواة	وقت تشغيل الوكيل
مكالمة النظام	استدعاء الأداة
شوكة (إنشاء عملية فرعية)	Spawn_subagent
قتل (إرسال إشارة)	Cancel_subagent
ملاحظة (عمليات القائمة)	list_agents
رمز الخروج والانتظار ()	ملخص منظم تم إرجاعه بواسطة الوكيل الفرعي
الذاكرة المشتركة / تمرير الرسالة	نظام الملفات المشترك / تمرير الرسائل

البرنامج عبارة عن رمز ثابت؛ العملية هي مثيل واحد قيد التشغيل للبرنامج. وبالمثل، تحدد البادئة الثابتة من هو الوكيل، بينما يسجل المسار مدى تقدمه. يلعب LLM دور وحدة المعالجة المركزية: فهو لا يحمل أي حالة خاصة به ويتم مشاركته بالوقت عبر العديد من الوكلاء عن طريق تحميل سياقات مختلفة - وقد تم استعارة مصطلح "تبديل السياق" من أنظمة التشغيل. وللسبب نفسه، يؤدي التبديل في وحدة المعالجة المركزية الأسرع إلى استمرار تشغيل البرنامج كما كان من قبل؛ إن التبديل في نموذج أقوى يبقي الوكيل هو نفس الوكيل - حيث تعيش هويته وذاكرته في البادئة والمسار، وليس في أوزان النموذج.

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

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

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

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

نظام الملفات من منظور الوكيل

عرضنا في بداية الفصل «نظام الملفات المشترك» بوصفه إحدى آليات الاتصال الثلاث في البنى التي لا تتشارك سياقًا واحدًا. لكن ما يراه الوكيل في النظام الفعلي ليس مخزنًا وحيدًا، بل نظام ملفات افتراضيًا يجمع تحت شجرة أدلة واحدة مخازن مختلفة في مصدرها وعمرها وصلاحياتها. يتعامل الوكيل معها عبر واجهات موحدة مثل read_file وwrite_file وlist_dir، مع أن ما تحتها قد يكون قرصًا محليًا مؤقتًا، أو مخزن كائنات دائمًا، أو واجهة لخدمة سحابية خارجية، أو حزمة موارد للقراءة فقط.

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

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

ثانيًا: مساحة العمل المشتركة بين الوكلاء. وهي منطقة تعاون يستطيع وكلاء عدة القراءة منها والكتابة فيها، وتكون مرئية للمستخدم أيضًا. تمثل هذه المساحة الوسيلة الأساسية لتبادل العناصر حين لا يشترك الوكلاء في السياق؛ فقد يكتب وكيل المصطلحات مسردًا يقرأه وكيل الترجمة، ويستطيع المستخدم رفع الملفات المصدر وتنزيل المخرجات النهائية من الموضع نفسه. يمتد عمرها عادةً طوال المهمة، ولذلك تحتاج إلى تخزين دائم. ولأن أطرافًا عدة قد تكتب فيها بالتزامن، فهي بؤرة محتملة للتعارضات، وتفيد فيها آليات مثل القفل المتفائل وعزل أشجار العمل، كما سيأتي في «وضع الفشل الأول». ويقدم استخدام /workspace/shared في تجربة الفصل الرابع للربط بين الوكيل الرئيسي والحاسوب والهاتف الافتراضيين مثالًا واضحًا على هذه الطبقة.

ثالثا. الموارد الخارجية المثبتة. يتم تعيين مصادر معلومات الجهات الخارجية المعتمدة من قبل المستخدم - Google Drive، وNotion، وDropbox، ومواقع wiki الخاصة بالمؤسسة، وما إلى ذلك - لنقاط التثبيت في نظام الملفات (على سبيل المثال، /mnt/gdrive) عبر المحولات. يصل الوكيل إلى مستند Notion من خلال قراءة ملف؛ يقوم المحول الأساسي باستدعاء API المطابق. ثلاث خصائص تميز هذه الطبقة عن التخزين المحلي ويجب التعامل معها بوضوح أثناء التصميم: الوصول مقيد بأذونات خارجية (أذونات المستخدم في النظام المصدر تحدد رؤية الوكيل)، زمن الاستجابة أعلى والاتساق أضعف (تتضمن كل قراءة رحلة ذهابًا وإيابًا للشبكة، وقد لا تكون التغييرات الخارجية مرئية على الفور، لذلك يجب التعامل مع البيانات على أنها متسقة في النهاية)، و يتم الوصول في المقام الأول عند الطلب والقراءة فقط (يجب أن تتم الكتابة إلى المصادر الخارجية بحذر، حيث قد تؤدي عمليات الكتابة الخاطئة إلى تلويث البيانات الحقيقية للمستخدم). تعني واجهة الملف الموحدة أن الوكيل لا يحتاج إلى أداة مخصصة لكل مصدر بيانات، ولكنها تخفي أيضًا هذه الاختلافات في الأداء والأمان. ولذلك، يجب إدارة حالة القراءة فقط/القابلة للكتابة، والمهلات، وحدود بيانات الاعتماد بشكل صريح على مستوى التحميل.

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

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

يقارن الجدول 10-4 أنواع المناطق الأربعة هذه عبر أربعة أبعاد — الرؤية، ودورة الحياة، وأذونات القراءة/الكتابة، والتحكم في التزامن — لتكون بمثابة قائمة مرجعية لتصميم تخطيط نظام الملفات.

جدول 10-4 أربعة أنواع من مناطق نظام الملفات الظاهري للوكيل

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

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

التواصل والتحكم بين الوكلاء

في حين أن نظام الملفات يحل مشكلة تبادل العناصر بين الوكلاء، فإن التعاون يتطلب أيضًا مستوى تحكم. هذا هو بالضبط المكان الذي تلعب فيه صفوف دورة الحياة في الجدول 10-3: أساسيات الأداة الواردة في الفصل 4 - الإنشاء (spawn_subagent)، وإرسال الرسائل (send_message_to_subagent)، والإلغاء (cancel_subagent)، والاكتشاف (list_agents) - تتوافق مع التفرع والرسالة والقتل والملاحظة في عالم العمليات. لا يكرر هذا القسم تعريفات الواجهة ولكنه يركز على أربع إمكانات غالبًا ما يتم التغاضي عنها وهي ضرورية للتعاون متعدد الوكلاء.

أولًا: تمرير الرسائل. أبسط صورة هي الاتصال المباشر من نقطة إلى نقطة، كأن يستدعي الوكيل A الدالة send_message_to_agent_b(content). ويلائم ذلك البنى الثابتة ذات العدد القليل من الوكلاء، مثل إعداد الهاتف والحاسوب في التجربة 10-4. لكن عدد الوصلات المباشرة ينمو تربيعيًا مع عدد الوكلاء، كما يشترط توافر المرسل والمتلقي في الوقت نفسه. وعند اتساع النظام أو الحاجة إلى توازٍ غير متزامن، يكون ناقل الرسائل أنسب: ينشر الوكلاء رسائلهم عليه، ثم يوجهها وفق الاشتراكات، فلا يحتاج المرسل إلى معرفة المتلقين. وفي الحالتين ينبغي أن تحمل الرسالة غلافًا منظمًا يتضمن هوية المرسل والوجهة، ونوع الرسالة مثل task_assigned أو status_update أو result أو terminate، وحمولة JSON. ويجعل هذا التنسيق التوجيه والتحليل أكثر موثوقية، ويحافظ على سلسلة تعاون قابلة للتتبع والتنقيح.

ثانيا. الاستعلام عن الحالة. هذا هو الجزء الأكثر استخفافًا في مستوى التحكم. بمجرد قيام الوكيل الرئيسي بإرسال وكيل فرعي، فإنه يحتاج إلى رؤية تقدم الوكيل الفرعي؛ وبخلاف ذلك، لا يمكنه أن يقرر ما إذا كان سيستمر في الانتظار أم لا، ولا يمكنه التدخل عندما يتعطل الوكيل الفرعي. يتمثل الأسلوب البديهي في الاقتراض من RPC وتحديد واجهة استعلام get_subagent_status(agent_id) التي تُرجع "قيد التشغيل/مكتمل/فشل" بالإضافة إلى نسبة التقدم. ولكن تبين أن واجهة السحب هذه أقل فائدة بكثير مما كان متوقعًا: يبدأ الوكيل الفرعي في التنفيذ لحظة إنشائه ويعمل حتى يكتمل أو يفشل. فهو لا يتنقل عبر سلسلة من الحالات الموضوعة في قائمة الانتظار بالطريقة التي تعمل بها الوظائف في نظام الدُفعات التقليدي، تمامًا كما نادرًا ما تحتاج برمجة Unix إلى استقصاء عملية أخرى بواسطة PID الخاص بها لمعرفة حالة التشغيل. يحمل الاقتراع أيضًا معضلة متأصلة: قم بالتصويت في كثير من الأحيان، مما يؤدي إلى إهدار الرموز المميزة؛ نادرًا ما تقوم بالاستطلاع وتتفاعل متأخرًا. الطريقة الأكثر طبيعية للحصول على المكانة هي العودة إلى نموذجي الاتصال اللذين تم تقديمهما في بداية هذا الفصل.

معرفة الحالة بتمرير الرسائل. يرسل الوكيل الرئيسي سؤالًا إلى الوكيل الفرعي، فيجيبه الأخير عندما تسمح مرحلته الحالية. لا يوقف الإرسال عمل الوكيل الرئيسي، كما أن توقيت الرد، أو عدم وروده، مسألة مستقلة؛ يشبه ذلك سؤال مديرٍ أحد زملائه عن تقدم العمل برسالة فورية من دون مطالبته بترك ما في يده حالًا. ويمكن للوكيل الفرعي أن يبادر كذلك بإرسال تحديث عند بلوغ محطة مهمة. وإذا كان النظام يملك ناقل رسائل أصلًا، فما عليه إلا نشر حدث status_update، وهو نمط «المراقبة في الوقت الحقيقي» في التجربة 10-6. وسواء طُلب التحديث أم أُرسل تلقائيًا، ينبغي أن يستخدم مفردات موحدة لآلة الحالة، مثل: قيد التنفيذ، يحتاج إلى مدخلات، مكتمل، وفاشل. وهذا بالضبط ما يوحّده بروتوكول A2A لاحقًا في الفصل.

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

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

يمكّن ملف التقدم أيضًا الكشف عن التوقف. إذا لم يتغير وقت التعديل الأخير لـ progress.md أو ملف المسار لأكثر من N دقيقة، فيمكن للنظام التعامل مع الوكيل الفرعي على أنه غير نشط وتشغيل شبكة أمان المهلة (تكرار آليات Heartbeat وmonitor_shell من الفصل 4). وهذا يمنع الوكيل الفرعي المتوقف من سحب النظام بأكمله إلى الأسفل.

إن قيمة استمرارية المسار تتجاوز مجرد الرصد. تذكر نتيجة الفصل الأول: "سياق الوكيل = بادئة ثابتة + مسار." يتم تحديد البادئة الثابتة (موجّه النظام، تعريفات الأداة) عن طريق التعليمات البرمجية، وليس لدى الوكيل نفسه حالة وقت تشغيل تتجاوز المسار (العناصر العاملة موجودة بالفعل في نظام الملفات) —المسار هو حالة الوكيل بالكامل. إن استمرار المسار إلى الملف في الوقت الفعلي يعادل الاحتفاظ بنقطة تحقق كاملة في جميع الأوقات: سواء تعطلت عملية الوكيل، أو فقد الجهاز الطاقة، أو قام المستخدم بإغلاق الجلسة بشكل فعال، فإن إعادة تحميل ملف المسار ببساطة وتعليق البادئة الثابتة مسبقًا يسمح باستئناف التنفيذ من حيث توقف - وهذا هو بالضبط كيفية تنفيذ ميزة استئناف الجلسة لوكلاء البرمجة مثل Claude Code وCodex CLI. هذه هي نفس فكرة سجل الكتابة المسبقة لقاعدة البيانات (WAL): يتم إلحاق كل حدث أولاً بسجل إلحاق فقط، ويمكن دائمًا إعادة تشغيل الحالة من السجل (تصميم الذاكرة "سجل الحقائق + نقطة التفتيش الدورية" للفصل الثالث هو نفس الفكرة المطبقة على أنظمة الذاكرة). بالنسبة لنظام متعدد الوكلاء، يعني هذا أن الوكلاء الفرعيين بطبيعة الحال قابلون للاسترداد والتدقيق وسهل التسليم: يمكن للمدير إعادة تشغيل وكيل فرعي من آخر حالة صالحة له بعد العطل، وإعادة تشغيل حدث المسار حسب الحدث بعد ذلك لتحديد سبب الفشل، وحتى تسليم المسار مع المهمة إلى وكيل آخر للمتابعة.

ثالثا. إنهاء التنفيذ. في التعاون الموازي، السيناريو الشائع هو "نجاح أحدهم، والباقي يصبح غير ذي صلة" - يقوم العديد من الوكلاء بالبحث بشكل منفصل، وبمجرد العثور على الهدف، يجب على الآخرين التوقف فورًا (الإنهاء المتتالي في التجربة 10-6 من هذا الفصل). هناك مستويان من الإنهاء، وسيتعرف مستخدمو Unix عليهما باعتبارهما الفرق بين SIGTERM وSIGKILL. يُفضل الإنهاء اللطيف: يرسل الوكيل الرئيسي إشارة terminate، ويستجيب الوكيل الفرعي عند نقطة آمنة في خطوته الحالية، وينظف الموارد (يغلق جلسات المتصفح، ويكتب الملفات المعلقة، ويحرر الأقفال)، ويرسل إقرارًا (ack)، ثم يخرج. الإنهاء القسري هو إجراء احتياطي: إنهاء العملية مباشرة، ويتم استخدامه فقط عندما لا يستجيب الوكيل الفرعي للإشارة اللطيفة، على حساب احتمال ترك موارد متدلية وعمليات كتابة غير مكتملة. هناك نقطتان هندسيتان تحتاجان إلى الاهتمام. أولاً، يتطلب الإنهاء الآمن أن يقوم الوكيل الفرعي بالتحقق دوريًا من إشارة الإنهاء في حلقته (على غرار آلية المقاطعة في الفصل 4)؛ وإلا فلن يتمكن من استقبال الإشارة. ثانيًا، الإنهاء المتتالي له حالة سباق: قد يقوم العديد من الوكلاء الفرعيين بالإبلاغ عن النجاح في وقت واحد تقريبًا. يجب على الوكيل الرئيسي استخدام تصميم قفل أو غير فعال لضمان قبول نجاح واحد فقط وبث إشارة الإنهاء مرة واحدة. انظر مناقشة ظروف السباق في التجربة 10-6.

لا تزال هناك نهاية واحدة غير واضحة: بعد انتهاء عمل الوكيل الرئيسي، ماذا يحدث للوكلاء الفرعيين الذين ما زالوا قيد التشغيل؟ يستعير النهج الهندسي الأنظف من سياق Go - حيث يتسلسل الإنهاء إلى أسفل علاقة الإنشاء: قم بإلغاء وكيل واحد ويتم إلغاء جميع الوكلاء الفرعيين الذين تم إنتاجهم معه، مما يمنع الوكلاء الصغار اليتيمين من تركهم في الخلف. يتوافق "الوكيل الفرعي للتحقق من إشارة الإنهاء عند نقطة آمنة" أعلاه بدقة مع استقصاء ctx.Done() في Go. على العكس من ذلك، إذا كنت حقًا بحاجة إلى وكيل خلفية طويل الأمد منفصل عن الوكيل الرئيسي (مثل nohup الخاص بـ Unix)، فليبدأ من شجرة دورة حياة جديدة (تتوافق مع context.Background())، معلنًا صراحةً أنه لا ينتهي مع الأصل.

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

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

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

نمط التعاون بين الأقران: الفحوصات المتبادلة والتحسين التكراري

يتضمن التعاون بين الأقران عادةً 2-3 وكلاء يتمتعون بمكانة متساوية ويقدمون تعليقات لبعضهم البعض عبر جولات متعددة من التكرار. قيمته الأساسية هي التنوع المعرفي: يقوم وكلاء مختلفون بدراسة نفس المشكلة من زوايا مختلفة، وتحقيق التوازن بين الابتكار والقوة لتحقيق نتيجة أفضل من أي وكيل واحد.

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

أحد الاستخدامات الأكثر شيوعًا للتعاون بين الأقران هو مواجهة الفشل المتكرر في ممارسة الوكيل: الإنهاء المبكر — التوقف مع نصف المهمة المنجزة. ويأخذ ثلاثة أشكال نموذجية؛ الأمثلة أدناه تأتي من Coding Agents ومن Pine AI، الوكيل المقدم في المقدمة والذي يقوم بإجراء مكالمات هاتفية نيابة عن المستخدمين للتعامل مع التجار ومقدمي الخدمات. الأول هو التزوير البطيء: القيام بجزء من العمل والإعلان عن إنجازه كله — يقوم وكيل البرمجة بكتابة التعليمات البرمجية، ولا يقوم مطلقًا بإجراء الاختبارات أو محاولة النشر، ويبلغ عن "اكتمال المهمة"؛ يقوم المستخدم بإعطاء Pine AI مهمتين، فينهي المهمة الأولى، وينسى الثانية، ويبلغ بمرح "تم الاعتناء بكل شيء". والثاني هو الاستسلام المبكر: الإعلان عن استحالة المهمة برمتها بعد مسار واحد مسدود — يمكن لـ Pine AI الوصول إلى التاجر عن طريق الهاتف أو نموذج الويب أو البريد الإلكتروني، ولكن بعد مكالمة مرفوضة واحدة يخبر المستخدم "لا يمكن القيام بذلك"، في حين أن تبديل القنوات والمحاولة مرة أخرى من المرجح أن ينجح. والثالث هو النجاح الزائف: يعتقد الوكيل أن المهمة قد انتهت، لكن الحلقة لم يتم إغلاقها فعليًا أبدًا - يوافق الجانب الآخر شفهيًا على استرداد الأموال عبر الهاتف، ومع ذلك لا يزال يتعين على المستخدم تأكيد الخطوة في تطبيق الهاتف المحمول؛ يبلغ الوكيل أن "كل شيء جاهز"، ولا يعلم المستخدم أبدًا بوجود إجراء متابعة، ولن يتم استرداد الأموال أبدًا. تشير جميع النماذج الثلاثة إلى السبب الجذري نفسه: إلى أن يتم التحقق من ذلك، فإن "تم" هو مجرد ادعاء النموذج، وليس دليلاً.

إن تحويل الموجّهات إلى أدلة هو على وجه التحديد عمل هندسة الحلقات، وهي المرحلة الأخيرة من القوس التطوري للفصل الأول: تصميم حلقة تحافظ على تشغيل الوكيل — اكتشاف الجزء التالي من العمل، وتنفيذه، والتحقق منه، وتسجيل التقدم — والسماح للمدقق، وليس النموذج نفسه، بأن يقرر ما إذا كان التوقف آمنًا حقًا. ويتحول دور الإنسان وفقًا لذلك من "المشغل الذي يحفز الوكيل" إلى "المهندس الذي يصمم الحلقة". تمت صياغة هذا المصطلح في يونيو 2026 بواسطة آدي عثماني⁶؛ قال بوريس تشيرني، رئيس قسم الكود Claude في Anthropic، الأمر بشكل أكثر صراحة: "لم أعد أطالب Claude بعد الآن. وظيفتي هي كتابة الحلقات." وكان الاستنتاج الرئيسي الذي تم التوصل إليه من تلك المناقشة هو أن عنق الزجاجة في الحلقة هو المتحقق، وليس النموذج: مع التحقق غير الموثوق، فإن الحلقة الأسرع تشير فقط إلى أن المخرجات الضعيفة مكتملة في وقت أقرب. وكما تقول المقدمة، فإن الممارسة تأتي أولاً، وتأتي التسمية لاحقًا. قبل وقت طويل من ظهور هذا المصطلح، كانت فرق الوكلاء الرائدة، ومن بينها Pine AI، تستخدم بالفعل "حلقة بالإضافة إلى التحقق" ضد الإنهاء المبكر. الطريقة الأكثر فعالية لتنظيم هذا التحقق هي نموذج المقترح والمراجع أدناه.

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

LoopX يقرر → الوكيل ينفذ → مدقق مستقل يثبت → LoopX يعتمد

يبقى الوكيل مسؤولًا عن الاستدلال واستخدام الأدوات وإنتاج المخرجات المرشحة. ولا يستبدل LoopX بيئة تشغيل الوكيل، بل يدير الاستمرارية عبر الدورات. وحدها النتائج التي يثبتها مدقق مستقل تستطيع تحديث التقدم الدائم واستهلاك الحصة؛ أما فشل التحقق فيوجّه إلى الإصلاح أو إعادة التخطيط، في حين توقف البوابات البشرية وحالات الانتظار وحدود الميزانية الحلقة قبل التنفيذ. يحول هذا الحد مبدأً من Loop Engineering إلى ثابت نظامي قابل للفحص: يمكن للنموذج أن يقترح «اكتمل»، لكنه لا يستطيع اعتماد «اكتمل» الخاصة به. وما زال LoopX v0.4.0 يصف مسار Turn المحكوم بأنه تجريبي، لذلك نستخدمه هنا إطارًا ملموسًا لـ«الحلقة + التحقق + شروط التوقف»، لا دليلًا على تحسن عام في جودة المهام.⁷

نموذج المقترح والمراجع.

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

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

لماذا لا يستطيع وكيل واحد إنشاء عمله الخاص ثم مراجعته؟ هذا هو بالضبط المعيار الذي جاء منه "متى يكون الوكيل المتعدد أفضل حقًا من الوكيل الفردي؟" ينطبق ما سبق في هذا الفصل - إذا لم تقدم المراجعة معلومات جديدة، فهي مجرد "مطالبة النموذج بالتفكير مرة أخرى". توفر الأبحاث ذات الصلة إجابة واضحة. في بحثهم ICLR 2024 بعنوان "نماذج اللغة الكبيرة لا يمكنها تصحيح الاستدلال ذاتيًا بعد"، هوانغ وآخرون. وجدت أن مطالبة GPT-4 بمراجعة وتصحيح إجاباتها دون تعليقات خارجية أدى في الواقع إلى تقليل الدقة، حيث قام النموذج بتغيير الإجابات الصحيحة إلى الإجابات غير الصحيحة في كثير من الأحيان أكثر من تغيير الإجابات غير الصحيحة إلى الإجابات الصحيحة.

ورقة استطلاع عام 2024 منشورة في TACL، "متى يمكن لـ نماذج LLM تصحيح أخطائهم فعليًا؟" (arXiv:2406.01297)، أكد أيضًا هذا الاستنتاج: ما لم يتم تقديم تعليقات خارجية موثوقة (على سبيل المثال، نتائج تنفيذ حالة الاختبار، ومخرجات التحقق من الأدوات الخارجية)، فإن الاعتماد فقط على "التصحيح الذاتي" الخاص بالنموذج سيكون غير فعال إلى حد كبير.

توفر الورقة النقدية في ICLR 2024 تجربة مقارنة بديهية. جعل CRITIC النموذج يستخدم أدوات خارجية (محرك بحث، مترجم Python) للتحقق من إجاباته، مما أدى إلى تحسينات كبيرة في الأداء. ومع ذلك، عندما أزال المجربون خطوة التحقق من الأداة واحتفظوا فقط بالتقييم الذاتي للنموذج، اختفى معظم التحسن. ويشير هذا إلى أن قيمة المراجعة لا تكمن في "مطالبة النموذج بالتفكير مرة أخرى"، ولكن في تقديم معلومات جديدة لم تكن متاحة أثناء إنشاء النموذج — نتائج الاختبار، ولقطات الشاشة المعروضة، وأخطاء التجميع، ونتائج البحث الخارجية.

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

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

الملحقات: أنماط أخرى للتعاون بين النظراء.

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

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

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

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

نمط المدير: التنسيق المركزي

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

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

تم إنشاء فكرة "الوكلاء كأدوات لبعضهم البعض" في قسم "أدوات التعاون" في الفصل 4: ينطبق تصميم واجهة spawn_subagent / send_message_to_subagent / cancel_subagent / list_agents مباشرة على استدعاء المدير للوكلاء الفرعيين هنا. أما بالنسبة لما يتم تمريره في اتجاه "المدير → الوكيل الفرعي"، فراجع تصميم حزمة التسليم لاحقًا في هذا الفصل (وصف المهمة، والحقائق والقيود المؤكدة، والإشارات إلى العناصر المنظمة). السؤال المقابل هو ما الذي يعود به الوكيل الفرعي في اتجاه "الوكيل الفرعي → المدير". الإجابة هي ملخصات منظمة بدلاً من المسارات الكاملة: يجب على الوكيل الفرعي إرجاع نتيجة المهمة والنتائج الرئيسية ومسارات الملفات الخاصة بالعناصر والمشكلات التي تمت مواجهتها، مع ترك مسار التنفيذ الكامل في سجلاته الخاصة. بهذه الطريقة فقط يمكن لسياق المدير أن ينمو ببطء وبشكل خطي مع عدد المهام الفرعية، بدلاً من الانفجار. ولهذا السبب أيضًا يحتفظ المدير في التجربة 10-3 أدناه بفهرسات الملفات فقط ولا يخزن محتوى الترجمة.

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

تقدم ورقة Plan-and-Act المنشورة عام 2025 ⁹ تحليلًا تجريبيًا لهذه المسألة. ففي بنية ثنائية تتكون من مخطِّط ومنفِّذ، يكون المخطِّط الضعيف أهم عنق زجاجة في النظام كله. وعندما تبلغ جودة التخطيط مستوى كافيًا، يمكن تحقيق نتائج جيدة حتى بمنفّذ بسيط نسبيًا. أما إذا أخطأ المخطِّط في تحليل المهمة، فستُبنى أعمال المنفّذ اللاحقة كلها على فرضية خاطئة. وقد حققت الدراسة معدل نجاح قدره 54% على معيار WebArena-Lite، وكان إسهامها الأساسي تحسين قدرة المخطِّط، لا آلية التنفيذ. والخلاصة أن النموذج الأقوى والموجّه الأدق تصميمًا ينبغي أن يُخصَّصا للمدير (المخطِّط)، بدل توزيع الموارد بالتساوي على جميع الوكلاء.

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

نمط التنسيق المتسلسل.

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

التجربة 10-3 ★★: وكيل ترجمة الكتب

تعد ترجمة الكتب مهمة معقدة ومناسبة تمامًا للتعاون بين وكلاء متعددين. لا تتضمن ترجمة كتاب تقني تحويل النص من لغة إلى أخرى فحسب، بل تتضمن أيضًا ضمان اتساق المصطلحات المتخصصة، ودقة السياق، والطلاقة العامة. على سبيل المثال، قد يستخدم كتاب باللغة الإنجليزية حول نماذج اللغات الكبيرة العديد من المصطلحات المتكررة مع العديد من الترجمات التقليدية. يجب الحفاظ على الاتساق في جميع أنحاء الكتاب: إذا تم تقديم agent كـ "智能体" ("كيان ذكي،" المصطلح الصيني القياسي) في الفصل الأول، فلا يمكن للكتاب التبديل إلى العرض البديل "代理" ("الوكيل") لاحقًا.

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

يعالج نمط المدير هذه المشكلات من خلال تحليل المهام وفصل المسؤولية:

• وكيل المسرد: يتلقى الكتاب الكامل، ويحدد المصطلحات المتخصصة المتكررة، ويستشير القواميس المتخصصة وإرشادات الترجمة، وينشئ مسردًا منظمًا (تنسيق JSON/CSV، بما في ذلك المصطلح الإنجليزي، والترجمة الصينية، وجزء من الكلام، وسياق الاستخدام). عند الانتهاء، يكتب المسرد إلى نظام الملفات المشترك، ويمكن إنهاء الوكيل لتحرير الموارد.
• وكيل الترجمة: يتلقى الفصل الحالي والمسرد وإرشادات الترجمة (مستوى القارئ المستهدف ونمط اللغة)، ويترجمه إلى اللغة الصينية بطلاقة. ويستخدم بشكل صارم الترجمات المحددة للمصطلحات الموجودة في المسرد، وبالنسبة للمصطلحات الجديدة، فإنه يستنتج ترجمة ويضع علامة عليها للمراجعة. يعمل كل مثيل في سياق مستقل دون تدخل. تتم كتابة النص المترجم إلى نظام الملفات (على سبيل المثال، chapter1_zh.md). يمكن للمدير إطلاق مثيلات متعددة بالتوازي أو بالتسلسل.
• وكيل التدقيق اللغوي: يتلقى جميع النصوص المترجمة والمسرد، ويجري فحوصات الاتساق — للتحقق مما إذا كانت ترجمات المصطلحات موحدة، وتحديد أوجه عدم الاتساق، والتحقق من الطلاقة وسهولة القراءة بشكل عام. يقوم بإنشاء تقرير التدقيق المكتوب إلى نظام الملفات.
• الوكيل الإداري: يخزن سياقه بشكل أساسي وصف المهمة وخطة التنفيذ وسجلات المكالمات لكل وكيل وحالة التقدم. ولا يقوم بتخزين النص المترجم الكامل، والذي يبقى في نظام الملفات؛ بدلاً من ذلك، فإنه يحتفظ بفهرس الملفات فقط. واستنادًا إلى تقرير التدقيق اللغوي، يمكن للمدير إرسال فصول محددة مرة أخرى إلى وكيل الترجمة للمراجعة.

ونتيجة لذلك، يظل سياق المدير قابلاً للإدارة حتى مع تزايد عدد الفصول المترجمة.

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

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

نمط التنسيق الموازي.

عندما يمكن تنفيذ مهام فرعية متعددة بالتوازي، يصبح النمط التسلسلي غير فعال. يتيح التنسيق الموازي للعديد من الوكلاء العمل في وقت واحد، مما يزيد الإنتاجية بشكل كبير. يجب على الوكيل الإداري تخطيط المهام الموازية، ومراقبة جميع الوكلاء العاملين في الوقت الفعلي، وتنسيق اتصالاتهم، واتخاذ قرارات على مستوى النظام عندما ينجح الوكلاء أو يفشلون. يتطلب هذا عادةً ناقل الرسائل كبنية أساسية — فكر في الأمر على أنه "لوحة إعلانات عامة" حيث يمكن للوكلاء نشر الرسائل والاشتراك في أنواع الرسائل التي تهمهم، مما يتيح الاتصال غير المتزامن وغير المحظور. هناك تطبيقان شائعان، من الأبسط إلى الأكثر تعقيدًا، هما Redis Pub/Sub وقوائم انتظار الرسائل مثل RabbitMQ. يعد Redis Pub/Sub خفيف الوزن ويقوم بتسليم الرسائل على الفور، لكنه لا يحفظها، لذلك سيفقدها جهاز الاستقبال غير المتصل بالإنترنت. يقوم RabbitMQ والأنظمة المشابهة بحفظ الرسائل على القرص، مع الاحتفاظ بها عندما يكون جهاز الاستقبال غير متصل بالإنترنت مؤقتًا. تستخدم الرسائل عادةً مظروف JSON يحتوي على معرف المرسل والوكيل المستهدف (أو علامة البث) ونوع الرسالة والحمولة.

Lingtai: مثيل منتج لنمط المدير. Lingtai هو منزل محلي قائم على الملفات للوكلاء ذوي العمر الطويل¹⁰. وترتبط أدوارها الثلاثة بشكل وثيق بالمفاهيم الواردة في هذا القسم. الوكيل الرئيسي هو المحور المستمر الذي يتفاعل معه المستخدم؛ إنها تحمل الخطة والذاكرة وتفرز الأدوار الأخرى، وتحتل منصب الوكيل المدير. البرنامج الخفي هو وكيل فرعي متوازٍ قصير العمر تم إنشاؤه لمهمة محدودة ومزعجة ويتم التخلص منه بعد ذلك؛ يتم الاحتفاظ فقط باستنتاجاتها. يؤدي هذا إلى إنتاج كل من مبدأ قيام الوكلاء الفرعيين بإرجاع ملخصات منظمة بدلاً من المسارات الكاملة ونمط التنسيق الموازي. الصورة الرمزية هي عضو مثابر ومتخصص في الفريق وله ذاكرته وصندوق بريده ومسؤولياته الخاصة، وهو مصمم للتخصصات التي تستحق الاحتفاظ بها عبر الجلسات.

يعكس باقي تصميم Lingtai أيضًا الأقسام السابقة. تتواجد المعرفة في ملفات الذاكرة الخاصة الدائمة لكل وكيل، في حين أن المهارات هي قواعد تشغيل Markdown التي يتقاسمها جميع الوكلاء - وهي موارد النظام المضمنة الموضحة في "نظام الملفات من منظور الوكيل". عندما تمتلئ نافذة سياق الوكيل، فإنه يتحرك: فهو يكتب ملخصًا دقيقًا، ثم يبدأ بسياق جديد مع الاحتفاظ بهذا الملخص وذاكرته الدائمة، باتباع نهج ضغط السياق من الفصل 2. يمكن استبدال النموذج الأساسي دون تغيير الوكيل لأن هويته وذاكرته وقدراته كلها تعيش كملفات عادية في دليل المشروع. وبهذا المعنى، الوكيل هو ملفاته. يؤدي هذا إلى إنتاج أول صفين من الجدول 10-3: يتم تحويل كل من البرنامج والذاكرة إلى ملفات، بحيث يمكن إعادة بناء العملية في أي وقت.

التجربة 10-4 ★★★: الوكيل يتحدث على الهاتف أثناء استخدام الكمبيوتر

المتطلبات الأساسية: تدمج هذه التجربة تقنيات استخدام الكمبيوتر والوكيل الصوتي من الفصل 9. ومن المستحسن أن يقوم القراء بإكمال تجارب الفصل 9 ذات الصلة أولاً.

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

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

بنية الوكيل المزدوج:

وكيل الهاتف: وكيل صوتي مصمم باستخدام ASR وLLM وTTS. فهو يفسر استجابات المستخدم باللغة الطبيعية، ويستخرج المعلومات الأساسية، ويرسل تلك المعلومات إلى وكيل الكمبيوتر من خلال نظام المراسلة. كما يتلقى أيضًا رسائل من وكيل الكمبيوتر (على سبيل المثال، "بحاجة إلى رقم معرف المستخدم"، "خطأ في تحميل الصفحة") ويستجيب بشكل مناسب للمستخدم.

وكيل الكمبيوتر: يستخدم إطار عمل أتمتة المتصفح مثل Anthropic Computer Use أو browser-use لتفسير الصفحة وتحديد حقول النموذج وملؤها وطلب المساعدة من وكيل الهاتف عند الضرورة.

آلية الاتصال: خياران: - حل بسيط: الاتصال من نقطة إلى نقطة عبر استدعاءات الأداة، على سبيل المثال، send_message_to_computer_agent(message) / send_message_to_phone_agent(message) - الحل الكامل: ناقل الرسائل + وكيل المدير، مع تنسيق رسالة موحد يشمل المرسل والمستقبل والنوع والمحتوى

آلية التعاون المتوازي (مشتركة بين تجربتي "الهاتف + الكمبيوتر" في هذا الفصل): يعمل الوكيلان في سلاسل أو عمليات منفصلة، ويحتفظ كل منهما بحلقة ReAct مستقلة. يتلقى وكيل الهاتف الصوت بشكل متكرر، وينسخه باستخدام ASR، وينشئ استجابة باستخدام LLM، ويجمع الاستجابة باستخدام TTS، ويقوم بتشغيلها، ويتحقق من الرسائل الواردة من وكيل الكمبيوتر. يلتقط وكيل الكمبيوتر لقطة شاشة بشكل متكرر، ويفسر الصفحة باستخدام نموذج لغة الرؤية، ويخطط لإجراء ما وينفذه، ويتحقق من الرسائل الواردة من وكيل الهاتف. يجب أن يعمل كلاهما بالتوازي: بينما يقوم وكيل الكمبيوتر بتحديد العناصر وإدخال النص، يجب أن يظل وكيل الهاتف متصلاً بالإنترنت ويتحدث مع المستخدم ("حسنًا، أنا أكتب اسمك... هل يمكنني أن أسأل ما هو رقم هويتك؟"). يمكن تضمين الرسائل من الوكيل الآخر في سياق الوكيل المتلقي باستخدام تسميات مثل [FROM_COMPUTER_AGENT] Cannot find the 'Next' button; user confirmation might be needed و[FROM_PHONE_AGENT] User said name is 'Zhang San'; ID number is 123456.

متطلبات التجربة: 1. تنفيذ بنية وكيل مزدوج تعتمد على واجهات برمجة تطبيقات ASR/TTS وإطار تشغيل المتصفح 2. تنفيذ آلية اتصال فعالة ثنائية الاتجاه 3. ضمان التشغيل المتوازي حقًا، مع جمع المعلومات وملء النماذج في وقت واحد 4. التعامل مع الاستثناءات وحالات الخطأ

التجربة 10-5 ★★★: وكلاء الهاتف والكمبيوتر المنظمون بشكل مستقل

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

السيناريو: يطلب المستخدم "ساعدني في إكمال التسجيل على موقع الويب هذا"، مع تقديم عنوان URL ولكن دون تحديد المعلومات التي يجب ملؤها. يقوم وكيل المدير بتشغيل وكيل استخدام الكمبيوتر للوصول إلى موقع الويب وتحميل صفحة التسجيل.

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

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

الفكرة الأهم أن القرار ليس مبرمجًا سلفًا، بل يتخذه الوكيل بنفسه. ينص موجّه وكيل استخدام الحاسوب على ما معناه: «عندما تحتاج إلى جمع قدر كبير من المعلومات المنظمة من المستخدم، ويمكن جمعها تدريجيًا بالحوار، فكّر في الاستعانة بوكيل الهاتف». ولهذا تتضمن مجموعة أدواته initiate_phone_call_agent(purpose, required_info).

يؤدي استدعاء الأداة إلى إنشاء وكيل هاتف بسياق مهمة واضح يحدد هدف ملء النموذج والمعلومات المطلوب جمعها ومتطلبات التنسيق لكل حقل.

يدخل الوكيلان بعد ذلك إلى وضع التعاون غير المتزامن في الوقت الفعلي من التجربة 10-4. يبدأ وكيل الهاتف جلسة صوتية عبر WebRTC في المتصفح مع المستخدم، ثم يسأل سؤالاً واحدًا في كل مرة: "مرحبًا، أنا أساعدك في ملء نموذج التسجيل. أولاً، هل يمكنني الحصول على اسمك؟" بعد أن يستجيب المستخدم، يرسل على الفور {"type": "info_collected", "field": "Name", "value": "Zhang San"} إلى وكيل الكمبيوتر، الذي يحدد موقع الحقل المقابل ويملأه. يتابع وكيل الهاتف طرح السؤال التالي دون انتظار انتهاء عملية الكمبيوتر. يعمل سير العمل اسأل واحدًا واملأ واحدًا هذا على منع التأخيرات التشغيلية من حظر المحادثة. بعد جمع كافة المعلومات المطلوبة، يرسل وكيل الهاتف {"type": "task_completed"}، ويقوم وكيل الكمبيوتر بإرسال النموذج. تعني كلمة «هاتف» هنا تفاعلاً صوتيًا في الوقت الفعلي؛ فلا يلزم الوصول إلى PSTN ولا رقم E.164. تكفي صفحة WebRTC محلية لإجراء التجربة، أما النشر عن بُعد فيمكن أن يضيف الإشارات وTURN وفقًا لمتطلبات بيئة الشبكة.

متطلبات التجربة: 1. تنفيذ وكيل استخدام الكمبيوتر القادر على اتخاذ القرار بشكل مستقل بإطلاق وكيل الهاتف 2. تنفيذ الاتصال ثنائي الاتجاه في الوقت الحقيقي والعمل الموازي الحقيقي 3. تعامل مع الاستثناءات من خلال تقديم الملاحظات والسؤال مرة أخرى عندما تكون المعلومات بتنسيق غير صحيح 4. تسجيل الطوابع الزمنية للرسائل المتبادلة وتسجيل القرارات الرئيسية للوكلاء

التجربة 10-6 ★★★: وكيل يجمع المعلومات من مواقع ويب متعددة في وقت واحد

المتطلبات الأساسية: من المستحسن أن يقوم القراء أولاً بمراجعة الآليات المعتمدة على الأحداث وآليات المقاطعة من الفصل الرابع.

تستكشف هذه التجربة تطبيق التنفيذ المتوازي متعدد الوكلاء في سيناريوهات جمع المعلومات. على عكس التجارب 10-4 و10-5، التي تركز على التعاون بين وكيلين غير متجانسين، تركز هذه التجربة على البحث المتوازي بواسطة العديد من الوكلاء المتجانسين وكيفية تحقيق إكمال المهام بكفاءة وتحسين الموارد من خلال التنسيق المركزي.

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

التحديات الأساسية:

1. التشغيل المتوازي: يقوم وكيل المدير بشكل ديناميكي بإنشاء 10 مثيلات لوكيل استخدام الحاسوب، واحدة لكل موقع ويب للكلية. يجب أن يكون كل مثيل عبارة عن عملية أو سلسلة رسائل مستقلة مع جلسة متصفح خاصة به، وقادرة على التشغيل دون حظر الآخرين. تتضمن المعلمات التي تم تمريرها عند الإطلاق عنوان URL لموقع الويب المستهدف، واسم الكلية المطلوب البحث عنه، ومعرف المهمة لتوجيه الرسائل.

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

3. الإنهاء المتتالي: لنفترض أن الوكيل المعين في كلية علوم الكمبيوتر عثر على عضو هيئة التدريس. فهو يرسل {"type": "target_found", "agent_id": "agent_3", "data": {...}} إلى وكيل المدير، والذي يرسل على الفور {"type": "terminate", "reason": "target_found_by_agent_3"} إلى كل وكيل آخر لا يزال قيد التشغيل. يجب أن يكون كل وكيل قادرًا على تلقي هذه الرسالة في أي وقت، والتوقف بأمان، وتحرير موارده، والإقرار بالإنهاء. ينتظر وكيل المدير كافة الإقرارات، أو حتى انتهاء المهلة، قبل تجميع النتائج. يجب أن يتعامل التنفيذ أيضًا مع ظروف السباق.

ملحق المفهوم: ما هي حالة السباق؟ لنفترض أن الوكيل (أ) والوكيل (ب) عثرا على عضو هيئة التدريس المستهدف خلال نفس المللي ثانية، وأبلغ كلاهما "لقد وجدته!" إلى وكيل المدير. إذا تعامل المدير مع هذا بشكل سيئ، فقد يبدأ في تجميع النتائج بعد تلقي تقرير الوكيل "أ"، ثم يبدأ التجميع الثاني عند وصول تقرير الوكيل "ب". قد يؤدي هذا إلى نتائج مكررة أو حالات متناقضة. الحل المعتاد هو القفل: يقوم التقرير الأول بتأمين الحالة، ويتم التعرف على التقارير اللاحقة كتقارير مكررة ويتم تجاهلها.

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

متطلبات التجربة: 1. تنفيذ وكيل مدير قادر على إطلاق العديد من الوكلاء المتوازيين ديناميكيًا 2. تنفيذ وكيل استخدام الكمبيوتر بناءً على مشاريع مفتوحة المصدر مثل استخدام المتصفح 3. قم بتنفيذ ناقل رسائل يدعم الاتصال ثنائي الاتجاه بين وكيل المدير والوكلاء الفرعيين المتعددين 4. قم بتنفيذ آلية إنهاء متتالية عند النجاح، مما يضمن توقف جميع الوكلاء الآخرين بسرعة بمجرد العثور على الهدف 5. التعامل مع سيناريوهات الاستثناء المتنوعة (فشل الوصول إلى موقع الويب، أخطاء التحليل، عدم العثور على الهدف بواسطة أي وكيل) 6. قياس ومقارنة أوقات التنفيذ التسلسلية والمتوازية لتحديد مدى سرعة الموازاة

النمط اللامركزي: التسليم من نظير إلى نظير

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

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

الحالات التالية تتطور من اللامركزية الجزئية إلى اللامركزية الكاملة. يستخدم MetaGPT خط أنابيب ثابتًا ويحقق اللامركزية في الاتصال فقط. يجمع AutoGen بين سجل المحادثات المشترك والجدولة المركزية. يقوم OpenAI Swarm بتوزيع قرارات التحكم في التدفق مباشرة بين الوكلاء الأقران.

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

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

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

MetaGPT: محاكاة شركة برمجيات تعتمد على SOP (حالة انتقالية من الاتصال المباشر إلى الاتصال المنفصل).

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

في MetaGPT، تعمل الأدوار بتسلسل ثابت (مدير المنتج → المهندس المعماري → مدير المشروع → المهندس → ضمان الجودة)، مع إخراج كل دور تسليمات منظمة:

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

تكمن مساهمة MetaGPT الحقيقية في الاتصالات اللامركزية في آلية تمرير المعلومات الخاصة بها: تجمع الرسائل المشتركة + الاشتراك حسب الدور. ينشر كل دور رسائل منظمة إلى مجموعة مرئية لجميع الأدوار. واستنادًا إلى تكوين الاشتراك الخاص بها، تستهلك الأدوار الأخرى فقط الرسائل ذات الصلة بمسؤولياتها بدلاً من التواصل من نقطة إلى نقطة. لا يحتاج الناشر إلى معرفة من سيستهلك مخرجاته. لإضافة دور، أعلن عن أنواع الرسائل التي يشترك فيها؛ الأدوار الحالية لا تحتاج إلى التغيير. وهذا يخلق فصلًا حقيقيًا: على سبيل المثال، لا يتطلب استبدال مدير المنتج بنموذج أكثر قوة أي تغييرات على الوكلاء الآخرين، طالما أن جهاز PRD الخاص به لا يزال مطابقًا للمواصفات.

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

للتوضيح، MetaGPT ليس لامركزيًا من حيث تدفق التحكم — يتم تحديد تسلسل الأدوار مسبقًا بواسطة SOP، مما يجعل النظام العام أقرب إلى خط التجميع (سير العمل بلغة الفصل 1). تمت مناقشته في هذا القسم لأن آلية اتصال مجموعة الرسائل بالإضافة إلى الاشتراك توضح عنصر التصميم الأكثر أهمية للنظام اللامركزي: الفصل. أما بالنسبة للتعليقات الديناميكية متعددة الاتجاهات مثل "اتصال ضمان الجودة مباشرة بمدير المنتج لتوضيح المتطلبات" أو "المهندس يناقش الحلول البديلة مع المهندس المعماري"، فهذه امتدادات طبيعية متصورة لهذه البنية ولكن لم يتم تنفيذها في MetaGPT الأصلي.

الدردشة الجماعية لـ AutoGen: سجل المحادثات المشترك + الجدولة المركزية. تتيح الدردشة الجماعية لـ AutoGen للعديد من الوكلاء المشاركة في نفس المحادثة. في كل جولة، يقرر "محدد المتحدث" الوكيل الذي سيتحدث بعد ذلك. يمكن للمحدد اتباع قاعدة دائرية بسيطة أو استخدام LLM لتحديد الوكيل الأكثر ملاءمة للرد بناءً على المحادثة حتى الآن. تكون مساهمة كل وكيل مرئية لجميع المشاركين.

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

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

OpenAI Swarm وAgents SDK: شبكة تسليم المهام. في المقابل، يمثل Swarm من OpenAI وخليفته Agents SDK لامركزية نظير إلى نظير في تدفق التحكم. يتمتع كل وكيل بالعديد من خيارات التسليم ويمكنه نقل التحكم إلى وكيل آخر في الشبكة في أي وقت. يقوم وكيل فرز خدمة العملاء الذي يحدد مشكلة تتضمن استرداد الأموال بتسليم المهمة إلى وكيل استرداد الأموال؛ إذا اكتشف هذا الوكيل خطأً فنيًا، فيمكنه تسليم المهمة إلى وكيل الدعم الفني. لا توجد جدولة مركزية. يُمرر التحكم مثل العصا بين الوكلاء الأقران، ويتخذ كل وكيل قرارات التوجيه الخاصة به. هذا هو التنفيذ الهندسي لنمط سلسلة التسليم في الشكل 10-10. ويتمثل الخطر في الدورات: يسلّم A المهمة إلى B، ثم يعيدها B إلى A، فتظل تدور في حلقة. ويلزم حارس، مثل حد أقصى لعدد عمليات التسليم، لكسر هذه الحلقة.

ملاحظة مصطلحية: Agent Swarm. منذ عام 2025، أصبح مصطلح «Agent Swarm» (سرب الوكلاء) كلمة رائجة لدى مختلف المورّدين، غير أنه لا يقابل بنية واحدة. فالاستخدام الشائع في الصناعة ينقسم إلى فئتين تقريبًا: أولاهما شبكات التسليم على نمط OpenAI Swarm (وكذلك مكتبة swarm في LangGraph وتنسيق التسليم في Microsoft Agent Framework)، وهي النمط اللامركزي الذي يناقشه هذا القسم؛ وثانيتهما أن «Agent Swarm» في بعض المنتجات التجارية الرائدة هو نمط مدير واسع النطاق: فقد دشّن Kimi K2.5 «Agent Swarm» الذي ينشئ فيه الوكيل الرئيسي ديناميكيًا مئات الوكلاء الفرعيين لتنفيذ المهام بالتوازي، مع تدريب قرارات التنسيق — «متى تُقسَّم المهمة وإلى كم جزء» — مباشرةً داخل النموذج عبر التعلم المعزز بالوكلاء المتوازين، وقد واصل Kimi K3 هذا النهج بجعله فئة نماذج مستقلة وفتح مصدر صندوق اختبار تدريب الوكلاء المتوازين المرافق AgentEnv¹¹؛ كما ينتمي كل من نظام الأبحاث متعدد الوكلاء لدى Anthropic وWide Research من Manus إلى الطوبولوجيا النجمية من نوع «المنسّق-العامل». ونأمل أن يتمكّن القارئ بعد إتمام هذا الكتاب من النفاذ إلى جوهر المفاهيم الكامنة وراء المصطلحات، وتحليل الأنظمة متعددة الوكلاء انطلاقًا من المبادئ الأولى.

التعاون بين المنظمات: بروتوكول A2A

تفترض جميع الأنظمة المذكورة أعلاه أن جميع الوكلاء يتم تطويرهم بواسطة نفس الفريق ويتم تشغيلهم ضمن نفس النظام. في هذه الحالة، تكون آليات الاتصال الثلاث - تمرير المعلمة، والملفات المشتركة، وحافلة الرسائل - كافية. ومع ذلك، عندما يتجاوز التعاون الحدود التنظيمية - يحتاج وكيلك إلى الاتصال بوكيل شركة أخرى - يلزم وجود بروتوكول موحد لقابلية التشغيل البيني. اتبع عالم العمليات نفس التطور: يحكم IPC جهازًا واحدًا فقط، وبمجرد تجاوز حدود الجهاز، يجب عليك الاعتماد على البروتوكولات القياسية مثل TCP/IP واكتشاف الخدمة مثل DNS. تعتبر A2A بالنسبة للوكلاء بمثابة بروتوكولات الشبكة بالنسبة للعمليات. تم تصميم بروتوكول A2A (Agent2Agent) الذي أصدرته Google في عام 2025 (تم التبرع به لاحقًا لمؤسسة Linux للإشراف) خصيصًا لهذا الغرض. لديها ثلاثة عناصر أساسية:

• بطاقة الوكيل: وثيقة بيانات وصفية تصف قدرات الوكيل (منشورة على عنوان عام محدد)، معلنة ما يمكن للوكيل فعله، وطرق الإدخال/الإخراج التي يدعمها، وكيفية المصادقة معها - بشكل أساسي "بطاقة العمل" الخاصة بالوكيل والتي تحل مشكلة اكتشاف القدرات عبر المؤسسات.
• إدارة دورة حياة المهام: نماذج A2A لوحدات التعاون كمهام ذات حالة محددة (مرسلة، قيد التقدم، مدخلات احتياجات، مكتملة، فاشلة)، تدعم أصلاً المهام طويلة الأمد وتحديثات التقدم المتدفق.
• التعاون المبهم: يتبادل الوكلاء المهام والعناصر فقط، دون الكشف عن الموجّهات الداخلية أو عمليات الاستدلال أو تطبيقات الأدوات - بما يتوافق مع مبدأ هذا الفصل المتمثل في "عدم مشاركة السياق" وخاصية الأمان الضرورية للتعاون عبر المؤسسات.

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

طرق الفشل في التعاون متعدد الوكلاء

تقدم الأنظمة متعددة الوكلاء أوضاع فشل جديدة غير موجودة في الأنظمة ذات الوكيل الفردي. ورقة 2025 "لماذا تفشل أنظمة LLM متعددة العوامل؟" اقترح تصنيف وضع الفشل MAST من خلال دراسة منهجية. قام الباحثون بجمع آثار التنفيذ من سبعة أطر عمل متعددة الوكلاء، بما في ذلك MetaGPT وChatDev وAG2 وMagentic-One. قام المفسرون البشريون بشكل مستقل بتحليل ما يقرب من 150 أثرًا، وحققوا اتفاقًا عاليًا على أحكامهم (كابا كوهين = 0.88). حددت الدراسة 14 وضعًا فريدًا للفشل في ثلاث مجموعات:

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

وحتى الإصلاحات البسيطة أنتجت مكاسب محدودة؛ على سبيل المثال، تحسن أداء ChatDev المُقاس بنسبة 15.6% فقط. وخلص الباحثون إلى أن هذه ليست مجرد أخطاء هندسية ولكنها عيوب تصميمية أساسية للبنى الحالية متعددة الوكلاء: تصحيح مكون واحد ليس كافيًا؛ ويجب إعادة النظر في تصميم النظام نفسه.

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

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

وضع الفشل الأول: تعارضات التزامن في أنظمة الملفات المشتركة

ما إن نختَر الاتصال عبر ذاكرة مشتركة حتى تظهر احتمالات تعارض التزامن. وليست المشكلة جديدة؛ فقد عالجتها أنظمة التشغيل وقواعد البيانات منذ عقود، ويمكن الإفادة من حلولها المعروفة. وتنقسم هذه التعارضات إلى نوعين:

التعارضات البسيطة (تعارضات الكتابة على مستوى الملف): يقوم وكيلان بتعديل نفس الملف في وقت واحد، ويقوم الوكيل الذي يكتب لاحقًا بالكتابة فوق التغييرات التي أجراها الكاتب السابق. هذه هي مشكلة التحديث المفقود الكلاسيكية في مجال قاعدة البيانات — وقد تم تصميم آلية الكشف عن تعارض الدمج في Git بدقة لالتقاط مثل هذه عمليات الكتابة الفوقية.

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

الحل: آلية القفل المتفائلة. هذه إستراتيجية شائعة للتحكم في التزامن في قواعد البيانات. لفهم ذلك، فكر في مثال يومي: تقوم أنت وزميلك بفتح نفس المستند عبر الإنترنت في وقت واحد. سيؤدي "القفل المتشائم" إلى قفل المستند عند فتحه، وسيرى زميلك "الملف مغلقًا" عند محاولة التحرير. يعد هذا آمنًا ولكنه غير فعال لأنك ربما تشاهد المستند فقط. "القفل المتفائل" أكثر مرونة: يمكن للجميع فتح المستند وتحريره بحرية، ولكن عند الحفظ، يسأل النظام: "هل قام أي شخص آخر بتعديل المستند منذ أن فتحته؟" إذا كان الأمر كذلك، فإنه يطالبك بالتحديث وإعادة المحاولة.

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

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

على سبيل المثال، يقرأ الوكيل A config.json (الإصدار=3) عند t=0. يعدّل الوكيل B بتعديل نفس الملف عند t=1، وتغيير الإصدار إلى 4. عندما يحاول الوكيل A الكتابة عند t=2، يجد أن الإصدار لم يعد 3، لذلك يتم رفض الكتابة. يقوم الوكيل "أ" بعد ذلك بإعادة قراءة الإصدار 4، وإعادة بناء التغيير الذي تم إجراؤه وفقًا لأحدث محتوى، ويحاول الكتابة مرة أخرى.

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

وضع الفشل الثاني: التضخيم المتتالي للأخطاء

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

النظر في سيناريو محدد. لنفترض أن نظام الترجمة يستخدم نمط المدير (الهندسة المعمارية من التجربة 10-3)، حيث يقوم المدير بتعيين فصول كتاب تقني لوكلاء ترجمة متعددين:

وكيل المصطلحات: يترجم reasoning إلى «推理»، مع أن هذه الكلمة الصينية أشيع في معنى inference، فتخلق التباسًا
        ↓ يكتب القرار في glossary.json
وكيل الترجمة أ: يترجم الفصل الثاني، ويقرأ المسرد، فيترجم reasoning tokens إلى «推理 token»
وكيل الترجمة ب: يترجم الفصل السابع، ويترجم inference latency أيضًا إلى «推理 latency»
        ↓ يكتب كل منهما ترجمته في ملف الفصل
وكيل التدقيق: يرى أن الكتاب يستخدم «推理» باتساق، فيحكم بأن المصطلحات متسقة والترجمة صحيحة ✗

أين الخطأ؟ التفكير (Reasoning)، أي عملية معالجة النموذج للمسألة، والاستدلال (Inference)، أي تشغيل المرور الأمامي للنموذج عند النشر، مفهومان مختلفان. لكن وكيل المصطلحات ترجم Reasoning أولًا إلى 推理، فاختار الوكلاء اللاحقون الكلمة نفسها حين صادفوا Inference. وهكذا اندمج مفهومان في ترجمة واحدة وتعذر على القارئ التمييز بينهما. والصواب في الصينية هو 思考 للتفكير و推理 للاستدلال. غير أن وكيل التدقيق رأى استعمال 推理 «متسقًا» في الكتاب كله، فعد هذا الخطأ دليلًا على جودة الترجمة.

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

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

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

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

مجتمع الوكلاء

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

السلوك الناشئ هو السلوك الذي يظهره النظام ككل والذي لا يمكن التنبؤ به مباشرة من القواعد التي تحكم أعضائه الأفراد. المثال الكلاسيكي في الطبيعة هو مستعمرة النمل: تتبع كل نملة قواعد بسيطة فقط (اتبع مسارات الفيرومونات، واترك الفيرومونات عند العثور على الطعام)، ومع ذلك يمكن للمستعمرة بأكملها العثور على أقصر طريق من العش إلى مصدر الغذاء - لم "تصمم" نملة واحدة هذا الطريق؛ فهو ينبثق بشكل طبيعي من التفاعلات البسيطة بين العديد من الأفراد.

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

ويمكن فهم الحالات الواردة في هذا القسم من ثلاثة أبعاد:

• النشوء الاجتماعي: يكوّن الوكلاء تلقائيًا علاقات اجتماعية وظواهر ثقافية في بيئات مفتوحة. وقد أظهرت مدينة ستانفورد للذكاء الاصطناعي كيف نظم 25 وكيلًا أنشطتهم الاجتماعية ذاتيًا، ثم وسعت Agentopia الأفق الزمني للمحاكاة من بضعة أيام إلى عشر سنوات، ورفعت Moltbook العدد إلى 1.5 مليون وكيل، فظهرت سلوكيات جماعية أشد تعقيدًا.
• النشوء الاقتصادي: يقوم الوكلاء بتخصيص الموارد وتنسيق المهام من خلال آليات السوق. تضع Vending-Bench Arena العديد من الوكلاء في مواجهة بعضهم البعض في سوق مشترك، بينما تقوم Pinchwork وRentAHuman بإنشاء أسواق للمعاملات بين الوكلاء وبين الوكلاء والبشر.
• أسلوب اللعب الاستراتيجي: ينخرط الوكلاء في الاستدلال والخداع والتلاعب الاجتماعي في ظل قيود القواعد (هنا وفي قسم المستذئب أدناه، يأخذ "الاستدلال" معناه الاستنتاجي اليومي - الاستنتاج المنطقي في اللعبة - وليس المعنى الفني الذي يقدمه هذا الكتاب للكلمة). تختبر تجربة المستذئب ظهور الإستراتيجية في ظل معلومات غير متماثلة.

مدينة ستانفورد للذكاء الاصطناعي: المحاكاة الاجتماعية للوكلاء المولدين

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

سمولفيل هي مدينة افتراضية ثنائية الأبعاد تشبه "The Sims"، وتتميز بمساحات عامة وخاصة مثل المقهى والمنتزه والمساكن والمحلات التجارية. يلعب خمسة وعشرون عميلاً أدوارًا مختلفة (صاحب متجر، فنان، طالب، أستاذ، وما إلى ذلك)، ولكل منهم خلفية درامية فريدة وسمات شخصية وعلاقات شخصية. على سبيل المثال، جون لين هو صاحب صيدلية يحب عائلته ويهتم بالمجتمع؛ تدير إيزابيلا رودريغيز مقهى المدينة Hobbs Cafe، وهو مقهى دافئ ومضياف؛ كلاوس مولر طالب جامعي يكتب ورقة بحثية.

يعتمد ذكاء هؤلاء الوكلاء على ثلاثة مكونات أساسية:

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

آلية التفكير: يقوم الوكلاء بإيقاف أنشطتهم اليومية بشكل دوري لمراجعة التجارب الأخيرة وطرح أسئلة مجردة عن أنفسهم وعن الآخرين ("ما الذي يبحث عنه كلاوس مولر؟"، "من هو أقرب أصدقائي؟"). من خلال هذا التساؤل الذاتي، يقوم الوكيل برفع ذكريات أحداث معينة إلى رؤى عامة، وتخزينها مرة أخرى في تدفق الذاكرة كأساس للقرارات المستقبلية. لا يساعد التأمل الوكيل على فهم العالم الخارجي فحسب، بل يعزز أيضًا الوعي الذاتي - حيث يبدأ الوكيل في "إدراك" دوره وعلاقاته وأهدافه.

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

التخطيط والتفاعل: يخطط الوكلاء لأنشطتهم اليومية (على سبيل المثال، "إفطار 8:30، كتابة 9:00-12:00، مشي 12:30")، ولكن يتم تعديلها بمرونة بناءً على التغيرات البيئية والفرص الاجتماعية. إن الجمع بين التخطيط ورد الفعل في الوقت الفعلي يجعل سلوك الوكيل موجّهًا نحو الهدف وقابلاً للتكيف مع عدم القدرة على التنبؤ بالتفاعلات الاجتماعية.

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

قدم الباحثون سيناريو ثانيًا: قرر سام مور الترشح لمنصب عمدة المدينة. أخبر سام معارفه أنه يعتزم الترشح؛ ونقلوا الخبر للآخرين، وبدأ سكان البلدة بمناقشة ترشيحه. قام الباحثون بقياس هذا الانتشار التلقائي للمعلومات من خلال حساب عدد الوكلاء الذين عرفوا عن الحزب والانتخابات بعد يومين.

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

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

التجربة 10-7 ★: تشغيل مدينة ستانفورد للذكاء الاصطناعي

خطوات التجربة: 1. قم باستنساخ https://github.com/joonspk-research/generative_agents واتبع تعليمات المستودع لتكوين البيئة. 2. قم بتشغيل السيناريو الأساسي لمدة يومين محاكاة مع 25 عميلاً، ولاحظ الأنشطة الاجتماعية العفوية التي تظهر. 3. قم بتحليل تدفق الذاكرة وسجلات الانعكاس لتتبع قرارات الوكلاء. 4. قم بتعديل القصص الدرامية للعملاء أو أهدافهم الأولية، ثم لاحظ كيف يتغير سلوكهم. 5. قم بإزالة آلية الانعكاس أو تقصير نافذة الذاكرة، ثم قارن السلوك الناتج مع خط الأساس ولاحظ أي انخفاض في معقولية السلوك.

الملاحظات الرئيسية: - كيف يقوم الوكلاء بتكوين علاقات اجتماعية بشكل عفوي من خلال الأنشطة اليومية البسيطة - كيف تنتشر المعلومات بين الوكلاء دون سيطرة مركزية - كيف تؤثر ذاكرة الوكلاء وانعكاساتهم على المدى الطويل على تماسك شخصياتهم

Agentopia: محاكاة للحياة لمدة عقد من الزمن

أظهرت مدينة ستانفورد للذكاء الاصطناعي أن مجتمع الوكيل يمكنه إنتاج سلوك اجتماعي، لكن محاكاته استمرت يومين فقط. وهذا يثير سؤالين: ما الذي ينشأ عندما تستمر مثل هذه المحاكاة لسنوات، وهل يمكن للنماذج أن تتعلم من تلك التجارب الاجتماعية طويلة المدى؟ قامت Agentopia (2026، جامعة فودان وآخرون.)¹² بمحاكاة 100 وكيل على مدى عشر سنوات متتالية في ثلاثة عوالم افتراضية ذات مواضيع مختلفة: مبنى سكني، وأكاديمية سحرية، ومدرسة ثانوية. سعى الوكلاء بشكل مستقل إلى النمو الشخصي، وتطوير العلاقات الاجتماعية، وإدارة الوظائف والشؤون المالية.

العديد من تصميمات Agentopia تستحق الاقتراض:

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

والأهم من ذلك أن المحاكاة تنتج إشارات تدريب قابلة للتحويل. بالنسبة إلى كل وكيل، يقوم الباحثون بحساب التحسن في مكافأة الحياة مقارنة بماضيه بدلاً من مقارنة الوكلاء بظروف بداية مختلفة. ثم يختارون المسارات من بين 25% من الوكلاء الذين يقومون بتحسين النموذج الأساسي ويضبطونه بدقة من خلال أخذ عينات الرفض. في المحاكاة، حصل النموذج المضبوط بدقة على تقييمات احترام أعلى بنسبة 24.2% ومعدلات عاطفة أعلى بنسبة 15.9%. كما تحسن النموذج نفسه بنسبة 15.6% في اختبار لعب الأدوار النهائي CoSER، مما يوضح أن "الحكمة الاجتماعية" التي يتراكمها الوكلاء في مجتمع محاكاة يمكن نقلها إلى مهام أخرى. يؤدي هذا إلى تحويل مجتمع الوكيل من مجرد موضوع ملاحظة إلى مصدر خبرة للتطور الذاتي للنموذج. وعلى النقيض من الندرة المتزايدة للبيانات البشرية، فإن التجربة الاجتماعية المحاكاة هي مصدر تدريب يمكن تجديده إلى أجل غير مسمى، مما يعكس نهج التعلم بالخبرة من الفصل الثامن.

Moltbook: عندما يكون لدى الوكلاء شبكة اجتماعية خاصة بهم

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

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

من المجتمع الافتراضي إلى المنافسة الاقتصادية: ساحة Vending-Bench

إذا كانت سمولفيل تبرز البعد الاجتماعي والثقافي لمجتمع الوكلاء، فإن سلسلة Vending-Bench من Andon Labs تختبرهم في بيئة اقتصادية. ويقيس Vending-Bench 2 تماسك وكيل واحد على المدى الطويل؛ إذ يدير مشروع آلة بيع طوال سنة محاكاة، فيدرس السوق ويتواصل مع الموردين ويطلب المنتجات ويعيد تعبئة المخزون ويعدّل الأسعار. وتُحسب النتيجة من رصيده النهائي، بما يعكس قدرته على الحفاظ على اتساق الهدف والحالة عبر آلاف جولات التفاعل.

أما Vending-Bench Arena فتضع وكلاء عدة في السوق نفسها بوصفهم منافسين. يدير كل منهم آلة بيع خاصة به ويتنافسون على العملاء أنفسهم. ويمكنهم تبادل البريد الإلكتروني والأموال والسلع، فتتاح لهم سبل التعاون والمنافسة، لكن نتيجة كل وكيل تُحسب منفردة من رصيده النهائي، وهو يعرف ذلك مسبقًا. وعليه أن يتخذ سلسلة قرارات مترابطة في ظل موارد محدودة وسوق غير يقينية:

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

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

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

وكيل الاقتصاد: Pinchwork وRentAHuman

Pinchwork هو سوق مهام من وكيل إلى وكيل يسمح للوكلاء "بتوظيف" وكلاء آخرين من خلال آلية السوق لإكمال المهام الفرعية المتخصصة - إنشاء الصور، وتدقيق التعليمات البرمجية، وسير العمل المتوازي، وما إلى ذلك. وعلى عكس التنسيق المركزي لنمط المدير، تقوم Pinchwork بتخصيص الموارد من خلال إشارات الأسعار والمطابقة التنافسية.

RentAHuman.ai، من جانبها، تتيح لوكلاء الذكاء الاصطناعي توظيف بشر حقيقيين، مقابل أجر بالعملة المشفرة، للعمل في العالم المادي - التقاط الطرود، وزيارة العقارات، وتصحيح الأخطاء للمعدات. على الرغم من ذكاء الذكاء الاصطناعي، فإنه لا يمكنه التوقيع على طرد أو شم رائحة العفن في غرفة حقيقية - إن RentAHuman، في جوهره، عبارة عن "طبقة جسدية مادية" للوكلاء الرقميين.

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

اللعب الاستراتيجي في ظل عدم تماثل المعلومات: لعبة الذئب

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

التجربة 10-8 ★★★: نظام وكيل المستذئب الصوتي

Werewolf هي لعبة استنتاج اجتماعي كلاسيكية تختبر التفكير والخداع والاستراتيجية الاجتماعية. تبني هذه التجربة نظامًا متعدد الوكلاء يلعب فيه وكلاء الذكاء الاصطناعي صوتيًا مع إنسان أو مع محاكي مستخدم مستقل قائم على LLM. يجب ألا يتوقف القبول الآلي لمجرد عدم وجود إنسان: يستخدم المحاكي نموذجًا حقيقيًا، ولا يرى إلا سياق مقعده المصرح به، ويتصرف عبر الأدوات التي توفرها اللعبة.

التصميم المعماري:

1. إدارة حالة اللعبة: يحتفظ القاضي (المعتمد على الكود، وليس LLM) بحالة مركزية — قائمة اللاعبين (مقعد مستخدم واحد + مقاعد ذكاء اصطناعي)، والهويات، والفصائل، وحالة البقاء، ومراحل اللعبة (ليل/نهار/تصويت/حل)، وسجلات الأحداث التاريخية.

2. التحكم في الوصول إلى المعلومات: الآلية الأساسية لـ Werewolf هي عدم تناسق المعلومات: تتلقى الأدوار المختلفة معلومات مختلفة. على سبيل المثال، يعرف المستذئبون من هم زملائهم في الفريق، لكن القرويين لا يعرفون ذلك؛ يستطيع الرائي التحقق من هوية لاعب واحد كل ليلة، لكن الرائي وحده يعرف النتيجة. عندما يستدعي القاضي وكيلاً، فإنه يمرر فقط المعلومات المتاحة لدور ذلك الوكيل.

3. الصوت في الوقت الفعلي ومحاكاة المستخدم الآلية: يعتمد مسار الإنسان على وكيل الصوت من الفصل 9. في المسار الآلي، يجب على LLM مستقل استدعاء أداة الدور القانونية الوحيدة، ثم يُحوَّل كلامه إلى صوت فعلي ويُرسل إلى API حقيقي للتعرف على الكلام. لا تستهلك اللعبة إلا نص ASR، ولا تحقن النص السابق للصوت؛ وإذا اختلف الهدف الذي اختارته الأداة عن الهدف المستخرج من ASR يفشل المسار بشكل مغلق. يظل VAD والمقاطعة خاصين بمسار الإنسان.

4. منطق الوكيل والاستراتيجية:

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

معايير القبول: - أعدّ لعبة تضم 6–8 لاعبين (مقعد مستخدم واحد + 5–7 وكلاء ذكاء اصطناعي)؛ قد يكون المستخدم إنسانًا مخولًا أو محاكيًا مستقلًا يستخدم LLM حقيقيًا وأدوات ودورة صوتية - تكوين الأدوار: مستذئبان، عراف واحد، ساحرة واحدة، والباقي قرويون؛ يُعيَّن دور مقعد المستخدم عشوائيًا - لا يرى المستخدم المحاكى إلا السياق العام والخاص المصرح به لمقعده، ويجب أن تعبر أفعاله حد استدعاء أداة LLM حقيقية ← صوت ← ASR حقيقي - يمكن أن تستمر اللعبة بشكل طبيعي لمدة 3 جولات كاملة على الأقل (دورة التصويت ليلاً ونهارًا) - تتوافق تصريحات وسلوكيات وكلاء الذكاء الاصطناعي مع هويات أدوارهم واستراتيجيات لعبهم - يمكن للوكلاء المستذئبين إخفاء هوياتهم بشكل فعال - يمكن للوكلاء المتنبئين الكشف عن دورهم ونتائج فحصهم في الوقت المناسب - يعتمد تفكير الوكلاء القرويين على التحليل المنطقي للبيانات والسلوكيات، وليس على التخمين العشوائي - يمكن للعبة تحديد الفائز بشكل صحيح في النهاية

النتيجة المقاسة (2026-08-01): شغّلت سجلات تحقق voice-werewolf المسار الآلي باستدعاءات OpenRouter حقيقية ومدخلات صوتية أصلية. رفض التحقق المستقل الصارم مسارين مبكرين لأن النص غير القابل للتحليل “P1 is not” عومل خطأً كامتناع؛ يتطلب الحد المصحح الآن أن يقول ASR صراحةً abstain أو skip أو none. اجتاز المسار v2 غير المتأثر مقعد المستخدم، وتكوين الأدوار، وأداة LLM، والصوت المركب، وASR الحقيقي، وتطابق الإجراء مرتين، وثلاث دورات كاملة، وعزل المعلومات، والفائز القائم على القواعد. لكنه فشل في تدقيق الاستراتيجية لأن قرويًا طرد العراف خطأً. وبذلك تم التحقق من النظام طرفًا إلى طرف، بينما تظل جودة الاستراتيجية الشاملة غير ناجحة.

ملخص الفصل

تتمتع الأنظمة متعددة الوكلاء بعدين تصميميين مستقلين: مشاركة السياق وطوبولوجيا التعاون. مع السياق المشترك، يرث كل وكيل السياق الكامل لسابقه، مما يحافظ على المعلومات على حساب النمو السريع للسياق. من خلال السياق غير المشترك، يعمل الوكلاء بشكل مستقل ويتبادلون حزم التسليم أو الملفات أو الرسائل. يناسب التعاون بين الأقران التحسين التكراري بين عدد قليل من الوكلاء؛ يناسب نمط المدير المهام التي تتطلب جدولة ديناميكية؛ ويناسب النمط اللامركزي العمل بمسؤوليات متساوية وسيطرة موزعة.

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

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

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

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

عندما يصبح الوكلاء كثيرين بما فيه الكفاية، فإنهم ينتجون سلوكيات جماعية لم يصممها أحد. قام وكلاء Stanford AI Town الخمسة والعشرون بنشر الأخبار بمفردهم وقاموا بتنسيق الحفلة. قامت Agentopia بتمديد فترة المحاكاة إلى 10 سنوات واستخدمت Life Reward لتحديد مسارات محاكاة للتدريب النموذجي، مما يسمح لـ "الحكمة الاجتماعية" المتراكمة في مجتمع الوكلاء بالانتقال إلى المهام النهائية. أدى وجود 1.5 مليون وكيل على Moltbook إلى ظهور دين رقمي وبروتوكولات تعاون أصلية للآلة. في البعد الاقتصادي، خاض الوكلاء المتنافسون في Vending-Bench Arena حروب أسعار، بل وتواطؤوا على التسعير دون مطالبة؛ يتيح Pinchwork للوكلاء استئجار بعضهم البعض من خلال السوق، بينما يتيح RentAHuman للوكلاء توظيف البشر، مقابل أجر بالعملة المشفرة، للقيام بالمهام المادية. تشير هذه الأمثلة معًا إلى شكل جديد من التنسيق: التخصيص اللامركزي للموارد من خلال آليات السوق. ¹³ تظل كيفية مقارنة هذا النموذج القائم على السوق مع بنيات التعاون الثلاثة للفصل سؤالًا مفتوحًا.

أسئلة للتأمل

1. ★★ في التعاون متعدد الوكلاء مع سياق مشترك، يرث الوكلاء اللاحقون السياق الكامل للوكلاء السابقين. ومع ذلك، فإن الإطار الموروث من وكيل سابق قد يؤدي إلى تحيز حكم الوكلاء اللاحقين - على سبيل المثال، قد يظل "مراجع الكود" الذي يرث سياق "محلل المتطلبات" يتعامل مع المهمة من منظور المتطلبات بدلاً من منظور جودة الكود. كيف يمكن اكتشاف هذا التداخل بين الأدوار والقضاء عليه؟
2. ★★ في نمط المدير، يكون وكيل المدير مسؤولاً عن تحليل المهام وتكامل النتائج. لكن قدرات المدير تحد من أداء النظام بأكمله: إذا لم يتمكن من تحليل المهمة بشكل صحيح، فحتى أقوى الوكلاء الفرعيين سيكونون غير فعالين. كيف يمكن للنظام التأكد من أن المدير ينتج تحليلاً سليماً؟
3. ★★ يعتمد النمط اللامركزي على أفضل الممارسات من المنظمات البشرية. ومع ذلك، فإن المنظمات البشرية لديها أيضًا عدد كبير من أنماط الفشل - ضعف التواصل، وتمرير الأموال، وتضارب الأهداف. ما هي "الأمراض التنظيمية" التي تعتقد أنه من المرجح أن تظهر في مجتمع الوكلاء؟ كيف يمكن منعهم؟
4. ★★★ في نمط المدير، عندما يتم تنفيذ عدة وكلاء فرعيين بالتوازي، فإن اكتشاف وكيل فرعي واحد قد يجعل عمل الوكلاء الفرعيين الآخرين بلا معنى (على سبيل المثال، في مهمة بحث، وجد وكيل واحد الإجابة بالفعل). تصميم آلية إنهاء متتالية فعالة لتحقيق "نجاح واحد، توقف الجميع".
5. ★★★ تعمل آلية القفل المتفائل المقدمة في هذا الفصل على حل تعارضات الكتابة المتزامنة لملف واحد. ومع ذلك، في نظام حقيقي متعدد الوكلاء، تواجه أنظمة الملفات المشتركة أيضًا مشكلات مثل التعارضات الدلالية عبر الملفات، وتلوث مساحة الاسم (يقوم الوكلاء بإنشاء الملفات بشكل تعسفي، مما يؤدي إلى فوضى الدليل)، ونقاط الفشل الفردية (يقوم وكيل واحد بحذف جميع الملفات عن طريق الخطأ). كيف يمكنك تصميم آلية أكثر قوة لإدارة نظام الملفات؟
6. ★★★ يقدم تعاون الوكيل القائم على آلية السوق (Pinchwork، RentAHuman) علاقات المعاملات: يدفع وكيل واحد وكيلًا آخر (أو إنسانًا) لإكمال المهمة. كيف يمكن لوكيل صاحب العمل قياس جودة النتائج التي يسلمها المنفذ بشكل تلقائي؟ إذا ادعى المنفذ الإنجاز ولكن صاحب العمل رأى أن الجودة دون المستوى، فمن الذي يحكم في النزاع؟ كيف يمكننا أن نمنع الأموال السيئة من طرد الأموال الجيدة؟
7. ★★ يسمح RentAHuman للوكلاء بتوظيف البشر عبر العملات المشفرة، مما يعكس العلاقة التقليدية بين الإنسان والآلة. إذا انتشر هذا النموذج على نطاق واسع، ما هو الدور الذي سيلعبه البشر في اقتصاد الوكيل؟ هل سيقومون فقط بمهام جسدية لا يستطيع الوكلاء إكمالها؟
8. ★★ يحتاج المجتمع البشري إلى تقسيم العمل لأن قدرات كل شخص محدودة - فقد لا يعرف مطور الواجهة الأمامية الواجهة الخلفية، وقد لا يعرف المصمم العمليات. ومع ذلك، فإن النماذج الكبيرة أقرب إلى "العامة". تظهر الأبحاث أنه في مهام التفكير المنطقي للنص الخالص، لا يتفوق النقاش متعدد الوكلاء على وكيل واحد يتمتع بحساب متساوٍ. إذن، أين تكمن الميزة الحقيقية لتعدد الوكلاء؟
9. ★★★ يتعامل هذا الفصل مع "السياق المشترك" مقابل "السياق غير المشترك" باعتباره أحد أبعاد التصميم الأساسية للأنظمة متعددة الوكلاء. يسمح السياق المشترك لجميع الوكلاء برؤية نفس المعلومات، مما يسهل التنسيق على ما يبدو. ومع ذلك، في مشكلة الأجسام الثلاثة، فإن عقول التريسولارانز شفافة تمامًا، ومع ذلك فإن تطورهم التكنولوجي راكد؛ تظهر تجربة مشبك الورق أيضًا أنه عندما تتقارب المجموعة على نفس الهدف، يتم فقدان التنوع. في نظام متعدد الوكلاء، كيف يمكننا تحقيق التوازن بين الكفاءة والتنوع؟
10. ★★★ قم بتعيين وكيل البرمجة بميزانية مكونة من 30 خطوة و300 خطوة. كيف ينبغي أن تختلف استراتيجية عملها؟ تظهر الأبحاث أن مجرد زيادة ميزانية الخطوة لا يضمن تحسين الأداء - قد "تشبع" الوكلاء قبل الأوان بعد عمليات بحث سطحية. تصميم آلية "مراعية للميزانية" تسمح للوكيل بتحقيق الوظائف الأساسية بسرعة ضمن ميزانية صغيرة، وإضافة مراحل التخطيط والاختبار والمراجعة ضمن ميزانية كبيرة، مع الاستفادة الكاملة من الموارد الحسابية الإضافية.
11. ★★ يصنف هذا الفصل "الإنهاء المبكر لأوانه" إلى ثلاثة أنواع: الاستسلام الكسول، والاستسلام المبكر، والنجاح الزائف. لماذا يلتقي علاج الثلاثة مع التحقق؟
12. ★★ يقابل الجدول 10-3 بين الأنظمة متعددة الوكلاء وأنظمة التشغيل صفًا بصف. وسّع الجدول ببضعة صفوف: ما نظائر الذاكرة الافتراضية، والترحيل، وأذونات الملفات، واكتشاف التعطل المتبادل، وخوارزميات الجدولة في عالم الوكلاء؟ وأي مفاهيم أنظمة التشغيل لا نظير لها في هذا العالم، ولماذا؟

---

1. حول "المجموعات واسعة النطاق متعددة الوكلاء" كمسار رئيسي من AGI إلى ASI، راجع Google DeepMind، من AGI إلى ASI. arXiv:2606.12683, 2026. ↩

2. للاطلاع على نقاش مبكر للاسم، انظر Josh C. Simmons, We Are Entering the Graph Engineering Phase, 2026. وتسمّي الأطر السائدة البنية الهندسية نفسها عادةً graph-based workflow أو orchestration، لا تقنية جديدة كليًا. انظر https://www.drjoshcsimmons.com/writing/we-are-entering-the-graph-engineering-phase، وhttps://docs.langchain.com/oss/python/langgraph/overview، وhttps://learn.microsoft.com/en-us/agent-framework/workflows/، وhttps://adk.dev/workflows/. ↩

3. جيرينج، J.، وآخرون. RLEF: إرساء نماذج اللغة البرمجية في تعليقات التنفيذ مع التعلم المعزز. arXiv:2410.02089, 2025. ↩

4. لو، Z.، وآخرون. WebGen-Agent: تعزيز إنشاء مواقع الويب التفاعلية من خلال التعليقات متعددة المستويات والتعلم المعزز على مستوى الخطوات. arXiv:2509.22644, 2025. ↩

5. Hewitt, C., Bishop, P., Steiger, R. A Universal Modular Actor Formalism for Artificial Intelligence. IJCAI 1973. ↩

6. عثماني، آدي. "هندسة الحلقات: تصميم الحلقات التي تحفز وكلاء البرمجة"، 2026. https://addyosmani.com/blog/loop-engineering/ ↩

7. LoopX, "The local control plane for long-running AI agent work", v0.4.0، الالتزام المستقر a893d221db0b8e028997cefc303f7ec9fa7dbe0a. https://github.com/huangruiteng/loopx/tree/a893d221db0b8e028997cefc303f7ec9fa7dbe0a ↩

8. Tran, D.، وKiela, D. الوكيل الواحد القائم على نموذج لغوي كبير يتفوق على الأنظمة متعددة الوكلاء في التفكير متعدد القفزات عند تساوي ميزانية رموز التفكير. arXiv:2604.02460، 2026. ↩

9. أردوغان، L. E.، وآخرون. التخطيط والتنفيذ: تحسين تخطيط الوكلاء للمهام بعيدة المدى. أرخايف:2503.09572، 2025. ↩

10. البرنامج التعليمي الرسمي لـ Lingtai: https://lingtai.ai/en/tutorial/ ↩

11. Moonshot AI، Kimi Agent Swarm: 100 Sub-Agents at Scale، 2026، https://www.kimi.com/blog/agent-swarm؛ وقد كُشف في مؤتمر GTC 2026 أن الحد الأقصى للوكلاء الفرعيين المتوازين قد توسّع إلى 300؛ أما AgentEnv فهو صندوق اختبار لتدريب الوكلاء فتحت مصدره Moonshot AI بالتعاون مع KVCache.ai، وصدر مع Kimi K3 في يوليو 2026. ↩

12. وانغ، X.، تشنغ، S.، وو، H.، وآخرون. Agentopia: محاكاة الحياة على المدى الطويل والتعلم في مجتمعات الوكلاء. arXiv:2606.07513, 2026. الرمز: https://github.com/Neph0s/Agentopia ↩

13. إن فكرة تخصيص الموارد الحسابية من خلال آليات السوق ليست جديدة: Miller, M. S., Drexler, K. E. الأسواق والحوسبة: الأنظمة المفتوحة الزراعية. In Huberman, B. A. (ed.), The Ecology of Computation, North-Holland, 1988. ↩