كتاب جديد عن أنماط التصميم الوكيلية يعيد تشكيل فهم وكلاء الذكاء الاصطناعي

الكاتب: يانهوا

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

لكن هذا ليس مراجعة كتاب. دافعي لقراءة هذا الكتاب كان محددًا جدًا: لقد كتبت عن Harness Engineering، وتجاربي مع Clawdbot، ومقالة "الوكلاء الذكيون ليسوا سحرًا" التي تناولت七个 التحولات من حرق الرموز إلى تحقيق فعالية حقيقية، وبعد كل كتابة، كان هناك سؤال لم أستطع الإجابة عنه تمامًا: هل هناك منطق أساسي قابل للتكرار وراء كل هذه الأشياء؟

This book gave me the answers, and deeper than I thought.

ربما ما كتبته ليس عاملًا على الإطلاق

أقسى حكم في الكتاب مخفي في المقدمة.

يستخدم معظم الناس ما يُسمى بـ "الذكاء الاصطناعي" كمستوى 0: نموذج لغوي خام، بدون أدوات، بدون ذاكرة، ولا يتخذ إجراءات. عندما تسأله عن فيلم العام الأفضل في حفلات الأوسكار لعام 2025، فهو يخمن. الكتاب يوضح ذلك بوضوح: الأشياء على مستوى 0 ليست وكيلًا.

الصعود هو الحقيقي Agent:

• المستخدم الأدوات

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

• المستوى 2: مفكر استراتيجي

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

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

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

• المستوى 3: التعاون بين عوامل متعددة

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

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

هندسة السياق: المفهوم الأكثر إهمالًا في الكتاب

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

يتعامل هندسة السياق في الكتاب مع "ما الذي يواجهه الوكيل قبل السؤال"، بينما تهتم هندسة الأوامر التقليدية فقط بـ"كيف تسأل". وهي تشمل أربع طبقات من المعلومات:

1. الطبقة الأولى، مُحفّز النظام. حدد من هو العامل، وما هي نبرته، وما هي حدوده. معظم الناس كتبوا فقط هذه الطبقة.

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

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

4. الطبقة الرابعة، حلقة التغذية الراجعة. بعد كل إخراج من الوكيل، يتم تقييم الجودة تلقائيًا وتعديل استراتيجية السياق للمرة القادمة. تسميه الكتاب "تحسين السياق التلقائي"، وهو ما يمثل التنفيذ الهندسي لـ Google Vertex AI Prompt Optimizer.

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

الانعكاس: وكيلان فعليًا أفضل من وكيل واحد

هذا النمط الأكثر فائدة عمليًا في الكتاب كله.

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

The book provides a complete code example.

• مُحفِّز Producer هو: "أنت مطور Python، اكتب دالة لحساب العامل، مع التعامل مع الشروط الحدية والاستثناءات."

• مُحفِّز Critic هو: "أنت مهندس متقدم ناقد، تُراجع الشيفرة سطرًا بسطر، وتتحقق من الأخطاء، والأسلوب، وشروط الحدود المفقودة، وأماكن التحسين. إذا كانت مثالية، فاكتب CODE_IS_PERFECT، وإلا فاذكر جميع المشكلات."

• ثم يأتي حلقة for: الكاتب يكتب الكود → الناقد يراجع → الكاتب يعدل بناءً على الملاحظات → الناقد يراجع مرة أخرى → حتى يقول الناقد CODE_IS_PERFECT أو يتم الوصول إلى الحد الأقصى لعدد التكرارات.

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

الاستخدامات تتجاوز كتابة الكود بكثير. كتابة المقالات، وضع الخطط، تلخيص الوثائق، حل المسائل المنطقية — جميعها يمكن تطبيق نموذج Producer-Critic عليها. يسرد الكتاب سبع سيناريوهات تطبيقية، والمنطق الأساسي واحد: الإنتاج أولاً، ثم المراجعة، ثم التصحيح.

Multi-Agent ليس كلما كان أكثر تعقيدًا كان أفضل

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

1. وكل منفرد (تنفيذ مستقل): يمكن تقسيم المهمة إلى مشكلات فرعية غير معتمدة على بعضها، وكل وكيل يتعامل مع مهمته الخاصة. بسيط وسهل الصيانة.

2. شبكة ند لند (Peer-to-Peer): التواصل المباشر بين الوكلاء دون عقد تحكم مركزي. لامركزية، وتحمل أعطال جيد، وتعطل وكيل واحد لا يؤثر على النظام ككل. لكن تكلفة التنسيق عالية، وقد تصبح فوضوية بسهولة.

3. المشرف (الجدولة المركزية): مشرف واحد يدير مجموعة من وكلاء العمال. يوزع المهام، ويجمع النتائج، وحل النزاعات. هيكل هرمي واضح وسهل الإدارة. لكن المشرف يمثل نقطة فشل واحدة وعائقًا في الأداء.

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

تجربتي تشير إلى أن كثيرين يقضون 80% من وقتهم في بناء بروتوكولات الاتصال عند إنشاء Multi-Agent، وينسون طرح سؤال أساسي أكثر: هل هذه المهمة تحتاج حقًا إلى عدة وكلاء؟ الكتاب يوضح بوضوح أن الوكيل الفردي من المستوى 2 مع Reflection غالبًا ما يكون كافيًا. المستوى 3 مخصص للسيناريوهات التي لا يستطيع الوكيل الفردي التعامل معها فعليًا.

نموذج الذاكرة الثلاثي، شعرت به من قبل بشكل غامض لكنني لم أسمه

أنا الأكثر تواصلًا مع هذا الفصل، لأنني كنت أفكر طوال الوقت في سؤال: كيف يجب تقسيم ذاكرة الوكلاء؟ أثناء كتابتي للمقالين عن Obsidian + Claude.

الإجابة موجودة في الكتاب:

1. طبقة الجلسة (Session): نافذة السياق للمحادثة الحالية، وهي أقصر نوع من الذاكرة وتختفي عند انتهاء المحادثة. إن النماذج ذات السياق الطويل تُوسّع فقط هذه النافذة، لكنها في جوهرها لا تزال مؤقتة، كما أن كل استنتاج يتطلب معالجة كاملة للنافذة، مما يجعلها مكلفة وبطيئة.

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

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

في المقال الذي كتبته سابقًا عن Clawdbot، ذكرت "ملف الحالة" و"مستندات بيئة العمل"، وهو في جوهره ما يعادل بناء طبقة الحالة وطبقة الذاكرة يدويًا، وقد قام الكتاب بتوحيد هذه العملية في إطار منظم.

خمسة افتراضات، الخامس هو الأكثر غرابة

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

الخامس الذي أدهشني: التحول Multi-Agent.

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

يُطلق عليه في الكتاب "نظام متعدد الوكلاء مستهدف ومُتَشَكِّل ذاتيًا". إنه لا ينفذ الخطة التي كتبتها، بل يُولِّد الخطة بنفسه، ويعدّلها، ويُعيد تشكيل فريق التنفيذ.

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

ثلاثة أشياء يمكنك فعلها فورًا

بعد قراءة هذا الكتاب، لدي ثلاث خطوات يمكنني تنفيذها فورًا:

• أولاً، أضف مُنقِّحًا إلى وكيلك الحالي. سواء كنت تستخدم Claude Code أو CrewAI أو إطارًا مخصصًا، أضف خطوة واحدة في نهاية سير العمل الحالي: اجعل وكيلًا آخر (باستخدام نظام تحفيز مختلف) يراجع مخرجات الخطوة السابقة. توليد الكود مع مراجعة الكود، كتابة المقالات مع التحقق من الحقائق، وضع الخطط مع تقييم الجدوى. إنها خطوة إضافية واحدة من استدعاء LLM، لكن تحسين الجودة غالبًا ما يتضاعف. نمط المنتج-المُنقِّح في الكتاب جاهز للتركيب والتشغيل.

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

• ثالثًا، لا تسرع في الانتقال إلى Multi-Agent. اجعل عاملك الفردي يصل إلى المستوى 2: مع أدوات، وReflection، وMemory. يُؤكد الكتاب مرارًا وتكرارًا أن عاملًا فرديًا من المستوى 2 مع Producer-Critic وContext Engineering يمكنه تغطية معظم السيناريوهات العملية. المستوى 3 مخصص للمهام الحقيقية التي تشمل مجالات متعددة ومراحل متعددة وتحتاج إلى توزيع متوازٍ. مشكلة معظم الناس ليست في قلة العوامل، بل في أن عاملًا واحدًا لم يتم ضبطه جيدًا بعد.

هذا الكتاب يحتوي على 453 صفحة، نُشر من قبل Springer في عام 2025. أمثلة الكود تغطي LangChain/LangGraph و Google ADK و CrewAI و OpenAI API. المقدمة مكتوبة من قبل نائب رئيس الذكاء الاصطناعي في Google Cloud، كما يوجد مقدمة توصية من رئيس المعلوماتية في Goldman Sachs، وهي مفاجئة بجمالها.

لكن السبب الذي أوصي به ليس "شاملًا". بعد قراءتك، ستدرك شيئًا واحدًا: كل الأخطاء التي وقعت فيها خلال النصف العام الماضي على Agent، تم تجميعها بالفعل كأنماط. لم تعد بحاجة إلى ابتكار Reflection، ولا إلى تخمين كيفية تقسيم Memory، ولا إلى تجربة أي توبولوجيا اتصال لـ Multi-Agent.

Someone has drawn the map for you; all that's left is to walk.

هل أنت تطور باستخدام وكيل ذكي؟ ما مستوى وكيلك الحالي؟