إطار عمل ReAct (Reasoning and Acting): كيف يفكر وينفذ الـ Agent المهام خطوة بخطوة؟
ما هو إطار عمل ReAct ولماذا يُعد نقطة تحول في تصميم الـ Agents؟
إطار ReAct هو اختصار لعبارة Reasoning + Acting، أي الجمع بين “التفكير” و“التنفيذ” داخل دورة تشغيل واحدة للعميل الذكي. الفكرة الأساسية ليست أن يجيب النموذج مباشرة، بل أن يحلل المهمة أولاً، يقرر هل يحتاج إلى أداة، ثم ينفذ خطوة عملية، يراقب الناتج، ويعود للتفكير مرة أخرى قبل اتخاذ الخطوة التالية. لهذا السبب يُعد ReAct من أهم الأنماط المعمارية بعد مقدمة في العملاء الأذكياء (AI Agents): الذكاء الاصطناعي الذي يتخذ القرارات.
في الأنظمة التقليدية، كان LLM يعمل كمولد نصي فقط: تدخل سؤالاً، فتخرج إجابة واحدة. أما في ReAct فهو يتحول إلى محرك قرار تتابعي Iterative Decision Engine قادر على تقسيم المهمة إلى حلقات صغيرة: يفكر، يختار أداة، ينفذ، ثم يبني الخطوة التالية اعتماداً على الملاحظة الناتجة. هذه البنية تقلل التخمين، وتزيد الدقة، خصوصاً في المسائل التي تتطلب بحثاً خارجياً أو حساباً أو استرجاع معرفة من قواعد بيانات.
الهيكلية الداخلية: كيف تتحرك البيانات داخل دورة ReAct Loop؟
من الناحية الهندسية، يتكون التدفق عادة من أربعة عناصر رئيسية:
- مدخل المستخدم
User Query. - النموذج اللغوي الذي ينتج التفكير والقرار.
- مجموعة أدوات
Toolsمثل البحث، الحاسبة، مفسرPython، أو مسترجعRetriever. - طبقة مراقبة تعيد ناتج الأداة إلى النموذج بصيغة
Observation.
السلسلة المنطقية تسير غالباً بهذا الشكل:
- يستقبل النظام السؤال.
- يكتب النموذج تفكيراً داخلياً حول ما يجب فعله.
- يحدد اسم الأداة المناسبة.
- يرسل مدخلات الأداة.
- تنفذ الأداة المهمة وتُرجع النتيجة.
- يقرأ النموذج النتيجة كملاحظة جديدة.
- إما أن يكرر الجولة أو يخرج الإجابة النهائية.
هذه البنية تصبح أكثر قوة عند ربطها مع مقدمة في إطار عمل LangChain: ثورة ربط وتطوير تطبيقات الذكاء الاصطناعي، لأن LangChain يوفر طبقات جاهزة لتعريف الأدوات، إدارة الذاكرة، وربط النماذج بسلاسل تنفيذ شبه مؤسسية.
النمط النصي الكلاسيكي لتفكير ReAct
Thought: أحتاج إلى جمع معلومات إضافية قبل الإجابة.
Action: search_tool
Action Input: “latest CPU benchmarks for AI inference”Observation: تم العثور على نتائج تتضمن المقارنات الحديثة.
Thought: الآن أمتلك معلومات كافية للمقارنة وكتابة خلاصة دقيقة.
Final Answer: …
هذا النمط ليس مجرد تنسيق شكلي، بل يمثل بروتوكول تشغيل بين النموذج وطبقة التنفيذ. أي خلل في صياغة Action أو في قراءة Observation قد يفسد الحلقة بالكامل.
لماذا يتفوق ReAct على الإجابة المباشرة؟
عندما تجبر النموذج على الإجابة مباشرة، فهو يعتمد على المعرفة المختزنة داخله فقط، وقد يقع في الهلوسة أو الحساب الخاطئ. أما مع ReAct، فإن القرار يصبح قائماً على التحقق المرحلي. مثلاً:
- إذا كان السؤال يحتاج بيانات حديثة، يستخدم أداة بحث.
- إذا كان السؤال حسابياً، يستخدم آلة حاسبة أو مفسر
Python. - إذا كان السؤال متعلقاً بملفات الشركة، يستخدم نظام RAG أو
Retriever.
هنا يظهر الفرق الجوهري بين “نموذج يجيب” و“نظام يفكر وينفذ”. ولهذا يرتبط ReAct عملياً مع مقالات مثل تزويد الذكاء الاصطناعي بالأدوات (Tools): كيف نعلمه البحث في جوجل للتحقق من الأخبار؟ ودمج آلة حاسبة ومفسر Python كأدوات يستخدمها الـ Agent لحل المسائل المعقدة.
بناء وكيل بسيط بنمط ReAct باستخدام Python وLangChain
قبل التنفيذ، من المفيد مراجعة إعداد بيئة العمل الذكية: تثبيت مكتبات Python الأساسية للتعامل مع الذكاء الاصطناعي والاتصال الأول: جلب مفاتيح API (Gemini / OpenAI) وكتابة أول سكربت اتصال.
1) تعريف الأدوات
الخطوة الأولى هي تحويل الوظائف البرمجية إلى أدوات يمكن للوكيل استدعاؤها. كل أداة يجب أن تملك اسماً واضحاً، وصفاً جيداً، ومدخلات متوقعة محددة. جودة وصف الأداة تؤثر مباشرة في اختيار النموذج لها.
from langchain.tools import Tool
def calculator_tool(expression: str) -> str:
try:
return str(eval(expression))
except Exception as e:
return f"error: {e}"
def search_tool(query: str) -> str:
mock_results = {
"best gpu for inference": "NVIDIA L4 and A10 are common inference-focused options.",
}
return mock_results.get(query.lower(), "No result found.")
tools = [
Tool(
name="calculator",
func=calculator_tool,
description="Useful for math calculations. Input should be a valid arithmetic expression."
),
Tool(
name="search_tool",
func=search_tool,
description="Useful for searching predefined technical facts. Input should be a concise query."
)
]
2) إعداد النموذج والوكيل
يمكنك بعد ذلك تهيئة النموذج وربطه بنمط ReAct. في المشاريع الحقيقية قد تضبط معاملات مثل temperature بعناية كما شرحنا في التحكم في إبداع الذكاء الاصطناعي: فهم وإعداد معاملات Temperature و Top-K برمجياً.
from langchain.agents import initialize_agent, AgentType
from langchain_openai import ChatOpenAI
llm = ChatOpenAI(
model="gpt-4o-mini",
temperature=0
)
agent = initialize_agent(
tools=tools,
llm=llm,
agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION,
verbose=True
)
result = agent.invoke({"input": "What is 25 * 18, then tell me the best gpu for inference?"})
print(result)
عند تفعيل verbose=True ستشاهد آثار التفكير والتنفيذ: اختيار أداة الحاسبة أولاً، ثم أداة البحث، ثم دمج النتيجتين في إجابة نهائية.
3) ربط ReAct مع RAG
في التطبيقات الإنتاجية، أفضل أداة قد لا تكون بحث ويب، بل مسترجع داخلي من قاعدة معرفية. هنا يتكامل ReAct مع قواعد البيانات المتجهة (Vector Databases) والخطوة الثالثة في RAG: استرجاع المعلومات المطابقة لسؤال المستخدم (Retriever). النموذج لا يستدعي المستندات عشوائياً، بل يقرر وقت الاسترجاع بناءً على غموض السؤال أو حاجته لمعلومة خاصة.
from langchain.tools import Tool
def retrieve_docs(query: str) -> str:
# Placeholder for vector search result
return "Retrieved internal documentation about model deployment and latency optimization."
retriever_tool = Tool(
name="retriever",
func=retrieve_docs,
description="Use this tool to fetch relevant internal documents before answering specialized questions."
)
أفضل ممارسات هندسية عند تصميم ReAct Agents
- اكتب وصف الأدوات بدقة شديدة، لأن النموذج يختارها اعتماداً على اللغة الوصفية.
- قلّل عدد الأدوات غير الضرورية حتى لا يزداد الالتباس في الاختيار.
- راقب التكلفة وعدد الجولات، لأن كل دورة
Thought/Actionتستهلك رموزاً إضافية. ويمكن الاستفادة من حساب التكلفة وإدارة الرموز (Tokens): سكربت لمعرفة حجم استهلاك الـ API قبل الإرسال. - أضف ذاكرة عند الحاجة إذا كانت المهمة متعددة الأدوار، بالاستفادة من الذاكرة في الذكاء الاصطناعي: لماذا ينسى الـ API المحادثات السابقة وكيف نعالج ذلك؟.
- استخدم مخرجات مهيكلة عندما تحتاج إلى قرارات قابلة للمعالجة آلياً، ويمكن دعم ذلك عبر استخراج بيانات مهيكلة (Output Parsers): إجبار الذكاء الاصطناعي على الرد بصيغة JSON فقط.
أين يفشل ReAct أحياناً؟
رغم قوته، ليس ReAct مثالياً دائماً. من أبرز المشكلات:
- اختيار أداة غير مناسبة بسبب وصف غامض.
- الدوران في حلقات زائدة إذا لم يُضبط حد أقصى للخطوات.
- تمرير مدخلات سيئة إلى الأدوات، خصوصاً مع أدوات حساسة مثل
SQLأو تنفيذ الشيفرة. - الاعتماد على مخرجات أداة غير موثوقة ثم البناء عليها في الجولات اللاحقة.
ولهذا يجب اعتبار ReAct نمط orchestration ذكي، لا مجرد حيلة prompting. نجاحه الحقيقي يعتمد على جودة الأدوات، وضبط الحراسة guardrails، ومراقبة السجلات التشغيلية.
الخلاصة الهندسية
إطار ReAct غيّر طريقة بناء العملاء الأذكياء لأنه نقل LLM من دور “المجيب” إلى دور “المخطط التنفيذي”. في هذا النمط، لا تنتج الإجابة دفعة واحدة، بل تُبنى عبر حلقات متعاقبة من التفكير، اختيار الأداة، التنفيذ، وقراءة الملاحظة. وعند دمجه مع LangChain، الذاكرة، وRAG، يتحول إلى أساس عملي لبناء أنظمة موثوقة تتعامل مع مهام مركبة خطوة بخطوة، بدقة أعلى وهلوسة أقل.