كيف تبني وكيل ذكاء اصطناعي من الصفر؟ المكوّنات الأربعة بلا سحر

يتحدّث الجميع عن «وكلاء الذكاء الاصطناعي» (AI Agents) وكأنّهم سحرٌ غامض. الحقيقة أبسط وأعمق في آن: الوكيل في جوهره حلقة تكرار (while loop) تستدعي نموذجًا لغويًّا، تنفّذ الأداة التي يختارها، ثمّ تعيد له النتيجة ليقرّر الخطوة التالية — حتى يبلغ هدفه. ما يفصل «الروبوت المحادث» (Chatbot) عن «الوكيل» كلمةٌ واحدة: القرار. المحادث يولّد نصًّا، أمّا الوكيل فيولّد نصًّا ويتّخذ أفعالًا (يستدعي دوالّ، يستعلم قواعد بيانات، يقرأ ملفّات)، ثمّ يستخدم نتائجها ليقرّر ما يفعله تاليًا. لنبنِ فهمًا هندسيًّا حقيقيًّا لهذه المكوّنات، لا مجرّد كلام تسويقيّ.

المكوّن الأوّل: نواة النموذج (المحرّك)

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

المكوّن الثاني: الأدوات و«استدعاء الدوالّ»

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

tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "يجلب الطقس الحاليّ لمدينة محدّدة. استخدمها فقط حين يسأل المستخدم صراحةً عن الطقس.",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {"type": "string", "description": "اسم المدينة، مثل: الرياض"}
            },
            "required": ["city"]
        }
    }
}]

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

المكوّن الثالث: طبقة الذاكرة والسياق

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

أمّا الذاكرة طويلة المدى، فلتخزين ما يتجاوز الجلسة: تفضيلات المستخدم، وبيانات المشاريع السابقة. تُبنى عادةً عبر «قواعد البيانات المتّجهة» (Vector Databases)، التي تخزّن المعلومات كمتّجهات رقمية قابلة للبحث الدلاليّ (Semantic Search)، فيسترجع الوكيل ما يشبه سياقه الحاليّ حين يحتاجه. هذا ما يفرّق وكيلًا يبدأ كل مرّة من الصفر عن آخر «يتذكّر».

المكوّن الرابع: حلقة الوكيل (ReAct)

هنا يجتمع كل شيء. «حلقة الوكيل» هي الدورة المستمرّة التي تجعله «يفكّر قبل أن ينفّذ». النمط الأشهر والأكثر استخدامًا في 2026 اسمه ReAct (اختصار Reason + Act، أي الاستدلال ثمّ الفعل)، ويسير هكذا: فكرة (Thought) ← فعل (Action) ← ملاحظة (Observation) ← ثمّ فكرة جديدة، وهكذا حتى الجواب النهائيّ:

الهدف ← فكرة: ما الذي أحتاجه؟
      ← فعل: استدعاء أداة (بحث، حساب...)
      ← ملاحظة: نتيجة الأداة
      ← فكرة: هل يكفيني هذا؟ أم أحتاج خطوة أخرى؟
      ← ... تتكرّر ...
      ← الجواب النهائيّ

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

الشبكة الأمانية التي لا غنى عنها: حدّ الخطوات

هنا درسٌ إنتاجيّ حاسم يغفله كثيرون: الوكيل غير المحميّ سيدور إلى الأبد. نموذجٌ حائرٌ قد يظلّ يستدعي أدوات في حلقة لا تنتهي، فيستنزف ميزانية الـ API ويطيل الانتظار بلا طائل. القاعدة غير القابلة للتفاوض: ضع دائمًا حدًّا أقصى للخطوات (max_steps). هذا المتحكّم البسيط هو الفرق بين وكيلٍ إنتاجيّ آمن وكارثة فاتورة:

def run_agent(goal, max_steps=8):
    messages = [{"role": "user", "content": goal}]
    for step in range(max_steps):
        response = call_llm(messages, tools)
        if not response.tool_calls:
            return response.content  # لا أدوات = انتهى
        result = execute_tool(response.tool_calls[0])
        messages.append(response)
        messages.append(result)  # أعد النتيجة للتاريخ
    return "بلغ الوكيل حدّ الخطوات دون إكمال المهمّة"

ويكمّل هذا وسيطُ النظام (System Prompt) الذي يضبط «انضباط الأدوات»: بلا توجيه جيّد، سيفرط النموذج في استدعاء الأدوات لأمور لا تحتاجها. عبارة بسيطة مثل «استدعِ أداةً فقط حين تجيب مباشرةً عن سؤال طرحه المستخدم» تحسّن السلوك جذريًّا.

الخلاصة العملية التي تختصر كل ما سبق: بناء الوكلاء ليس سحرًا، بل هندسة برمجيات واضحة — حلقة تكرار تربط نموذجًا ببيئتك عبر أدوات موصوفة جيّدًا، وذاكرة تُعاد في كل خطوة، وحدود تمنع الانفلات. المرّة القادمة التي يتحدّث فيها أحدهم عن «الوكلاء» كأنّهم معجزة، ستبتسم، لأنك تعرف أنهم في جوهرهم حلقة while بتعليمات جيّدة. ابدأ ببناء وكيل بسيط من الصفر لتفهم الآلية، ثمّ انتقل للأطر الجاهزة (Frameworks) وأنت تعرف ما تخفيه تحتها — فمن يفهم النسخة الخام، يستخدم الأدوات الجاهزة بوعي أعمق.