أنماط التصميم الوكيلية: كتاب جعلني أعيد التفكير في "ما هو الوكيل (Agent) بالضبط؟"

المؤلف: Yanhua

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

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

لقد منحني هذا الكتاب الإجابة، وكانت أعمق مما توقعت.

قد لا تكون بصدد كتابة وكيل (Agent) على الإطلاق

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

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

الصعود إلى الأعلى هو حيث توجد الوكلاء الحقيقيون:

• المستوى 1: مستخدم الأدوات

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

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

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

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

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

• المستوى 3: تعاون الوكلاء المتعددين

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

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

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

كتبت مقالاً عن هندسة الربط (Harness Engineering)، ناقشت فيه كيف أن تصميم المسار أهم من قوة المحرك. بعد قراءة هذا الكتاب، أدركت أن هندسة السياق هي التناظر لهندسة الربط على مستوى الأوامر (Prompts).

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

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

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

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

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

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

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

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

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

يقدم الكتاب مثالاً برمجياً كاملاً.

• أمر المنتج هو "أنت مطور Python، اكتب دالة لحساب المضروب، مع التعامل مع الحالات الاستثنائية والأخطاء".

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

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

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

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

تعدد الوكلاء ليس أفضل عندما يكون أكثر تعقيداً

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

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

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

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

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

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

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

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

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

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

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

3. الذاكرة (الطبقة الدائمة): ذاكرة طويلة المدى تمتد عبر الجلسات والمهام. تفضيلات المستخدم، والخبرات المكتسبة، والقرارات التاريخية المهمة المخزنة في قواعد البيانات أو مخازن المتجهات، مع استرجاع دلالي. يؤكد الكتاب على نقطة مهمة: الذاكرة لا تتعلق فقط بالتخزين؛ بل تتطلب أيضاً تصميم استراتيجية كاملة لـ "ماذا تخزن، ومتى تخزن، وكيف تسترجع". التخزين المفرط يخلق ضجيجاً، بينما التخزين القليل جداً غير كافٍ.

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

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

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

الفرضية الخامسة صدمتني: الوكلاء المتعددون المتحولون ذاتياً.

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

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

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

ثلاث إجراءات يمكنك اتخاذها فوراً

بعد الانتهاء من هذا الكتاب، لدي ثلاثة إجراءات فورية يمكنني تنفيذها:

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

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

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

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

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

لقد رسم شخص ما الخريطة لك؛ كل ما تبقى هو السير فيها.

هل تستخدم وكلاء الذكاء الاصطناعي للتطوير؟ ما هو المستوى الذي وصل إليه وكيلك الحالي؟