بنية وكيل الذكاء الاصطناعي - كيف تعمل الذاكرة والأدوات؟

بنية وكيل الذكاء الاصطناعي | كيف تعمل الذاكرة والأدوات وحلقة التنفيذ؟​

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

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

​

ما المقصود ببنية وكيل الذكاء الاصطناعي؟​

بنية وكيل الذكاء الاصطناعي هي الطريقة التي تُنظم بها مكونات النظام لكي ينتقل من طلب المستخدم إلى قرار قابل للتنفيذ، ثم يراقب النتيجة ويحدد الخطوة التالية.
النموذج اللغوي الكبير (LLM - Large Language Model) عنصر مهم في هذه البنية، لكنه ليس الوكيل كاملًا. النموذج يفسر اللغة ويولد قرارًا أو مخرجًا، بينما يتولى النظام المحيط به إدارة السياق، واستدعاء الأدوات، وتخزين الحالة، وتطبيق الصلاحيات، وتسجيل ما حدث، وتحديد متى يتوقف التنفيذ.[1][2]

يمكن تلخيص البنية في سبع طبقات مترابطة:

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

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

الطبقة الأولى: الهدف والتعليمات​

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

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

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

الطبقة الثانية: النموذج أو محرك اتخاذ القرار​

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

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

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

الطبقة الثالثة: طبقة التنسيق Orchestration​

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

1. تحميل تعليمات الوكيل.
2. جلب بيانات الجلسة والذاكرة ذات الصلة.
3. تجهيز الرسالة التي ستصل إلى النموذج.
4. التحقق من أن استدعاء الأداة صالح ومسموح.
5. تشغيل الأداة في البيئة المناسبة.
6. إعادة نتيجة الأداة إلى السياق.
7. تحديد ما إذا كانت المهمة قد اكتملت.
8. تكرار الدورة أو تحويل التحكم إلى الإنسان.
9. تسجيل المسار لأغراض التدقيق والتقييم.

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

الطبقة الرابعة: السياق والحالة والجلسة​

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

السياق Context​

السياق هو حزمة المعلومات المتاحة للنموذج عند استدعائه في لحظة محددة. قد تشمل:

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

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

الجلسة Session​

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

الحالة State​

الحالة هي دفتر العمل الذي يحتفظ بالبيانات النشطة اللازمة لإكمال المهمة، مثل:

• المرحلة الحالية: بحث أو كتابة أو مراجعة.
• المصادر التي فُتحت.
• العناصر التي اكتملت.
• آخر أداة استُخدمت.
• عدد المحاولات.
• نتيجة التحقق.
• هل حصل الوكيل على الموافقة البشرية؟

تفرّق وثائق Google Agent Development Kit بين الجلسة التي تحفظ تسلسل الأحداث، والحالة التي تحفظ بيانات المحادثة الحالية، والذاكرة التي تتيح معلومات قابلة للبحث عبر جلسات متعددة.[3]
هذا الفصل مهم؛ لأن الاعتماد على سجل الرسائل وحده يجعل الوكيل يعيد قراءة معلومات كثيرة في كل جولة، وقد يصعب عليه معرفة ما الذي يمثل الحقيقة التشغيلية الحالية.

​

الطبقة الخامسة: ذاكرة وكيل الذكاء الاصطناعي​

الذاكرة ليست مجرد تخزين المحادثة كاملة. الذاكرة الجيدة تختار ما يستحق الحفظ، وتحدد أين يُخزن، وكيف يُسترجع، ومتى يُحذف أو يُحدّث.

يمكن تقسيم ذاكرة الوكيل إلى ثلاثة أنواع عملية:

الذاكرة قصيرة المدى​

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

الذاكرة طويلة المدى​

تحتفظ بالمعلومات عبر جلسات مختلفة، مثل:

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

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

الذاكرة الدلالية والحدثية والإجرائية​

من المفيد أيضًا تصنيف الذاكرة بحسب نوع ما تحفظه:

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

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

كيف تعمل الذاكرة عمليًا؟​

تمر الذاكرة بثلاث عمليات أساسية:

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

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

ما الفرق بين الذاكرة وقاعدة المعرفة؟​

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

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

قد تستخدم الذاكرة وقاعدة المعرفة التقنية نفسها في التخزين والاسترجاع، لكن الغرض ودورة الحياة وقواعد الصلاحية مختلفة.

الطبقة السادسة: الأدوات وبيئة التنفيذ​

الأداة هي الواجهة التي تسمح للوكيل بفعل شيء يتجاوز توليد النص. قد تكون وظيفة بسيطة داخل التطبيق، أو واجهة برمجة تطبيقات (API)، أو موصلًا لخدمة خارجية، أو خادمًا يعمل ببروتوكول سياق النموذج (MCP - Model Context Protocol).
من أمثلة الأدوات:

• البحث في الويب.
• قراءة ملف أو جدول.
• تشغيل كود.
• الاستعلام من قاعدة بيانات.
• إنشاء حدث في التقويم.
• إرسال بريد بعد الموافقة.
• تحديث نظام إدارة العملاء.
• تشغيل متصفح.
• استدعاء وكيل متخصص.

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

• read_file
• create_draft
• move_file
• delete_file_with_approval

تشير Anthropic إلى أن جودة تصميم الأدوات ووصفها واختبارها عامل أساسي في نجاح الوكيل، وأن الأدوات القليلة والواضحة والموجهة إلى مسارات ذات قيمة تكون أفضل من مجموعة كبيرة متداخلة الوظائف.[5]

مدخلات ومخرجات منظمة​

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

• التاريخ.
• وقت البداية.
• وقت النهاية.
• الحضور.
• المنطقة الزمنية.
• هل تم التأكيد؟

تتيح البنية المنظمة رفض القيم غير الصحيحة قبل التنفيذ، وتقلل احتمال أن تتحول بيانات غير موثوقة إلى أمر مباشر.

الأداة ليست صلاحية مفتوحة​

وجود أداة في النظام لا يعني السماح باستخدامها دائمًا. يمكن لطبقة الصلاحيات أن تحدد:

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

وهنا تظهر أهمية الفصل بين قدرة النموذج على اقتراح الإجراء وحق النظام في تنفيذه.

الطبقة السابعة: الأمان والحواجز والتقييم والمراقبة​

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

أهم ضوابط الحماية:​

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

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

لماذا نحتاج إلى تتبع التنفيذ؟
قد تبدو النتيجة النهائية صحيحة، بينما يكون الوكيل قد:

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

سجل التنفيذ أو Trace يساعد على رؤية تسلسل استدعاءات الأدوات وتغير الحالة والنتائج الوسيطة. وتصبح التقييمات أكثر فائدة عندما تقيس النتيجة الحقيقية في البيئة، لا مجرد ادعاء الوكيل بأنه أكمل المهمة.[7]

كيف تعمل حلقة وكيل الذكاء الاصطناعي؟​

حلقة الوكيل (Agent Loop) هي الدورة التي تربط النموذج بالأدوات والبيئة.
يمكن تمثيلها بالمسار التالي:

هدف المستخدم ← تجهيز السياق ← قرار النموذج ← استدعاء أداة أو إنتاج إجابة ← ملاحظة النتيجة ← تحديث الحالة ← التحقق من الاكتمال ← تكرار أو توقف

​

١. استقبال الهدف​

يستقبل النظام الطلب، ويتحقق من هوية المستخدم والصلاحيات والمدخلات الأساسية.

٢. تجهيز السياق​

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

٣. اختيار الخطوة التالية​

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

٤. التحقق من الإجراء​

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

٥. تنفيذ الأداة​

تعمل الأداة داخل البيئة المحددة، ثم تعيد نتيجة أو خطأً منظمًا.

٦. تسجيل الملاحظة وتحديث الحالة​

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

٧. تقييم التقدم​

يقرأ النموذج النتيجة الجديدة ويقرر: هل تحقق الهدف؟ هل يحتاج إلى أداة أخرى؟ هل ينبغي تعديل الخطة؟ هل وصل إلى حد التوقف؟

٨. إنهاء المهمة​

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

مثال عملي: وكيل يبحث ويكتب مقالًا تقنيًا​

لنفترض أن المستخدم أعطى الوكيل هذا الهدف:

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

ماذا يحدث داخل البنية؟

مرحلة الإدخال​

تُحفظ الكلمة المفتاحية، والجمهور، والطول، وقواعد النشر داخل حالة المهمة.

مرحلة فحص الموقع​

تختار طبقة التنسيق أداة البحث الداخلي. تعيد الأداة قائمة بالمقالات، فيسجل الوكيل النتائج ويتحقق من احتمال التنافس على الكلمة المفتاحية.

مرحلة البحث الخارجي​

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

مرحلة بناء الهيكل​

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

مرحلة الكتابة​

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

مرحلة المراجعة​

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

مرحلة التسليم​

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

أشهر أنماط بنية وكلاء الذكاء الاصطناعي​

لا توجد بنية واحدة تناسب جميع المهام. وفيما يلي أشهر الأنماط.

وكيل واحد مع أدوات​

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

التخطيط ثم التنفيذ​

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

سير عمل محدد​

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

منسق ووكلاء متخصصون​

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

كيف تختار البنية المناسبة؟​

ابدأ بالسؤال: هل المسار معروف أم مفتوح؟
استخدم سير عمل ثابتًا عندما:

• تكون الخطوات متوقعة.
• توجد قواعد صارمة.
• يمكن التحقق من كل مرحلة.
• تكون تكلفة الخطأ مرتفعة.
• لا يحتاج النظام إلى ابتكار مسار جديد.

استخدم وكيلًا ديناميكيًا عندما:

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

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

​

أخطاء شائعة في تصميم بنية وكيل الذكاء الاصطناعي​

وضع كل شيء داخل مطالبة واحدة​

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

استخدام سجل المحادثة بوصفه ذاكرة دائمة​

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

توفير أدوات كثيرة متشابهة​

الأدوات المتداخلة تزيد احتمال الاختيار الخاطئ. اجعل لكل أداة غرضًا واضحًا، ومدخلات محددة، وحدودًا لا تتعارض مع غيرها.

عدم تعريف شروط النجاح والتوقف​

عبارة «استمر حتى تحصل على أفضل نتيجة» غير قابلة للقياس. استبدلها بمعايير مثل عدد المصادر، وحد أدنى للثقة، واختبارات يجب اجتيازها، وحد أقصى للمحاولات.

منح صلاحيات واسعة منذ البداية​

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

حفظ كل معلومة في الذاكرة​

ليست كل رسالة معرفة طويلة المدى. افصل بين البيانات المؤقتة، والتفضيلات الثابتة، والحقائق المرجعية، والمعلومات الحساسة.

القفز إلى تعدد الوكلاء​

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

خطوات عملية لبناء وكيل قابل للصيانة​

1. حدد الهدف ومعيار النجاح - ما الحالة التي تعني ان المهمة اكتملت فعلا؟
2. ارسم الحدود: ما الذي يستطيع الوكيل قراءته أو تغييره؟
3. اختر النمط: سير عمل ثابت، أو وكيل ديناميكي، أو نظام هجين؟
4. صمم حالة منظمة: ما الحقول التي يجب أن تبقى دقيقة طوال التنفيذ؟
5. ضع سياسة ذاكرة: ماذا يُحفظ، وأين، ومدة بقائه، ومن يستطيع حذفه؟
6. ابدأ بأدوات قليلة: اختبر كل أداة بمدخلات صحيحة وخاطئة وحالات فشل.
7. أضف نقاط موافقة: خصوصًا عند الإرسال والدفع والحذف والنشر.
8. حدد ميزانية التشغيل: عدد الجولات والوقت والتكلفة وحجم النتائج.
9. سجل المسار: احتفظ باستدعاءات الأدوات وتغيرات الحالة دون تخزين الأسرار.
10. أنشئ اختبارات واقعية: قِس النتيجة داخل البيئة، لا جمال الرد وحده.
11. اختبر داخل بيئة معزولة: قبل ربط الوكيل بأنظمة الإنتاج.
12. راجع البنية دوريًا: لأن الأدوات والنماذج والسياسات تتغير.

​

أسئلة شائعة حول بنية وكيل الذكاء الاصطناعي​

- هل النموذج اللغوي هو وكيل الذكاء الاصطناعي؟​

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

- هل يحتاج كل وكيل إلى ذاكرة طويلة المدى؟​

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

- هل قاعدة البيانات تُعد ذاكرة للوكيل؟​

قد تكون جزءًا من الذاكرة، لكنها ليست ذاكرة تلقائيًا. تصبح كذلك عندما توجد سياسة تحدد ما يُكتب، وكيف يُسترجع، وكيف تُدار الصلاحية والتحديثات والتناقضات.

- ما أهم جزء في بنية الوكيل؟​

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

- هل حلقة التنفيذ تعني أن الوكيل مستقل تمامًا؟​

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

- متى أستخدم عدة وكلاء؟​

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

- كيف أعرف أن الوكيل أنهى المهمة بنجاح؟​

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

​

​

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

شاركنا رأيك هنا في منتديات شباب الرافدين: أي جزء من بنية الوكلاء ترغب في شرحه لاحقًا بصورة أعمق—الذاكرة، أم تصميم الأدوات، أم أنظمة تعدد الوكلاء؟
دمتم بود!

المصادر والمراجع​

[1] OpenAI. “Agents.” OpenAI Platform، بلا تاريخ.
https://platform.openai.com/docs/guides/agents
[2] Anthropic. “Building Effective AI Agents.” Anthropic Engineering، بلا تاريخ.
https://www.anthropic.com/engineering/building-effective-agents
[3] Google. “Conversational Context: Session, State, and Memory.” Agent Development Kit، بلا تاريخ.
https://adk.dev/sessions/
[4] Amazon Web Services. “How Amazon Bedrock Agents Works.” AWS Documentation، بلا تاريخ.
https://docs.aws.amazon.com/bedrock/latest/userguide/agents-how.html
[5] Ken Aizawa وآخرون. “Writing Effective Tools for AI Agents—Using AI Agents.” Anthropic Engineering، بلا تاريخ.
https://www.anthropic.com/engineering/writing-tools-for-agents
[6] OpenAI. “Safety in Building Agents.” OpenAI API Documentation، بلا تاريخ.
https://developers.openai.com/api/docs/guides/agent-builder-safety
[7] Anthropic. “Demystifying Evals for AI Agents.” Anthropic Engineering، بلا تاريخ.
https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

 

شرح Kimi K2.6: كيف تعمل ميزة Agent Swarm وما الذي تستطيع إنجازه؟