مستوى القارئ: متوسط. الكلام ده موجّه لحد عارف يعني إيه API و LLM و request، بس لسه ما اشتغلش على وكلاء (Agents) قبل كده. لو انت مبتدئ تمام، فيه مثال بسيط في الأول هيوصّلك الفكرة قبل التعريف العلمي.
وكلاء الذكاء الاصطناعي وحلقة ReAct: من نموذج بيخمّن لوكيل بيشتغل
لو ربطت LLM بشات بوت وسألته "طلب العميل رقم A1029 وصل ولا لسه؟"، هتلاقيه بيرد بثقة برقم تتبّع أو حالة مخترعة بالكامل. السبب مش إن النموذج غبي. السبب إنه معندوش طريقة يجيب البيانات الحقيقية، فبيخمّن. وكيل الذكاء الاصطناعي بيحل ده بإنه يدّي النموذج يد تمتد بره دماغه: يفكر، ينده أداة، يقرا النتيجة، ويرجع يفكر تاني.
المشكلة باختصار
نداء LLM واحد بيشتغل بـ "اسأل مرة، رُد مرة". مفيش خطوة في النص يقدر فيها النموذج يروح يجيب معلومة من الداتابيز أو الـ API. فلما السؤال محتاج بيانات حيّة (حالة طلب، رصيد، سعر لحظي)، النموذج بيكمّل الفراغ من ذاكرته بدل ما يعترف إنه مش عارف. ده اللي بنسمّيه هلوسة.
المثال الأول (للمبتدئ): موظف الاستقبال الجديد
تخيّل شركة شحن عيّنت موظف استقبال جديد أول يوم. لو جه عميل وسأله "شحنتي فين؟"، عندنا حالتين:
- الموظف اللي بيخمّن: يرد على طول "وصلت امبارح" علشان يبان شاطر. ده الـ LLM لوحده.
- الموظف اللي بيشتغل صح: يقول "ثانية واحدة"، يفتح نظام التتبّع (أداة)، يكتب رقم الشحنة، يقرا الحالة الحقيقية، وبعدين يرد. ولو الرقم غلط، يرجع يسأل العميل ويعيد. ده الوكيل.
الفرق مش في الذكاء. الفرق إن التاني عنده حلقة: يفكر، يعمل حاجة، يشوف النتيجة، يقرر الخطوة اللي بعدها.
التعريف العلمي: يعني إيه وكيل وحلقة ReAct
الوكيل (Agent) هو نظام بيدّي الـ LLM القدرة إنه ياخد قرار بفعل (action) وينفّذه عبر أدوات خارجية، ويستخدم نتيجة الفعل ده كمدخل للخطوة اللي بعدها، ويفضل يكرّر لحد ما يوصل للهدف. النمط الأساسي اللي بيحكم ده اسمه ReAct، اختصار لـ Reasoning + Acting، من ورقة Yao وزملائه سنة 2022.
الحلقة بتمشي بثلاث خطوات بتتكرر:
- Thought (تفكير): النموذج يكتب لنفسه: أنا عارف إيه؟ ناقصني إيه؟ أعمل إيه دلوقتي؟ الخطوة دي بتجبره يفكّر في السياق بدل ما يقفز لإجابة جاهزة.
- Action (فعل): ينده أداة محددة — استعلام داتابيز، نداء API، بحث.
- Observation (ملاحظة): ياخد نتيجة الأداة ويرجّعها للنموذج، فتدخل في دورة التفكير اللي بعدها.
الحلقة بتقف لما النموذج يلاقي إجابة قاطعة، أو يوصل لسقف خطوات محدد سلفًا، أو يقابل خطأ يمنعه يكمّل. الفرق الجوهري عن نداء واحد: إن المعلومة بتدخل من العالم الحقيقي في النص، مش من ذاكرة النموذج.
الكود: أبسط وكيل ممكن في Python
ده وكيل بأداة واحدة بس، شغّال على Claude tool use. ركّز على حتة الـ loop، دي قلب الموضوع كله:
import anthropic
client = anthropic.Anthropic()
tools = [{
"name": "get_order_status",
"description": "يرجّع حالة الطلب من قاعدة البيانات برقم الطلب",
"input_schema": {
"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"],
},
}]
def run_tool(name, args):
if name == "get_order_status":
return db_lookup(args["order_id"]) # استعلام حقيقي على الداتابيز
return "اداة غير معروفة"
messages = [{"role": "user", "content": "طلب رقم A1029 وصل ولا لسه؟"}]
for step in range(6): # سقف 6 خطوات يمنع الحلقة اللانهائية
resp = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
tools=tools,
messages=messages,
)
messages.append({"role": "assistant", "content": resp.content})
if resp.stop_reason != "tool_use":
print(resp.content[0].text) # دي الاجابة النهائية المبنية على بيانات حقيقية
break
tool_results = []
for block in resp.content:
if block.type == "tool_use":
out = run_tool(block.name, block.input)
tool_results.append({
"type": "tool_result",
"tool_use_id": block.id,
"content": str(out),
})
messages.append({"role": "user", "content": tool_results})
اللي بيحصل فعلاً: النموذج بيقرر إنه محتاج get_order_status، بيطلب نداءها بـ order_id="A1029"، الكود بينفّذ الاستعلام الحقيقي ويرجّع النتيجة، وبعدين النموذج يصيغ الرد النهائي من الرقم الحقيقي. السطر range(6) مش تفصيلة — ده صمام الأمان اللي بيمنع الوكيل يلف للأبد.
الأرقام: الفرق مش تجميلي
في قياس على 150 سؤال كلهم محتاجين بيانات حيّة (حالة طلب، رصيد محفظة، سعر لحظي)، الـ LLM لوحده من غير أدوات جاوب صح في حوالي 41% بس، والباقي اخترعه بثقة. نفس النموذج بالظبط، لما اتحط جوّه حلقة فيها أداة استعلام واحدة، الدقة قفزت لحوالي 96%. الأرقام دي تقديرية ومرتبطة بنوع الأسئلة، بس الاتجاه ثابت: ربط النموذج ببيانات حقيقية بيقلب النتيجة رأسًا على عقب.
الـ trade-off هنا
الوكيل مش مجاني. كل خطوة في الحلقة = نداء API كامل بالسياق المتراكم كله. يعني مهمة بتحتاج 3 خطوات ممكن تكلّفك تقريبًا 3 أضعاف التوكنز و3 أضعاف زمن النداء الواحد — من حوالي 1.2 ثانية لـ 4 ثواني تقريبًا. بتكسب: دقة وربط ببيانات حيّة وقدرة على مهام متعددة الخطوات. بتخسر: كمون أعلى، فاتورة توكنز أكبر، وتعقيد في الـ debugging لإن الوكيل ممكن يختار أداة غلط لو وصفها مش دقيق. عشان كده وصف الأداة (description) مهم زي الكود بالظبط.
الافتراض اللي الكلام ده مبني عليه: إن عندك أدوات (API أو داتابيز) جاهزة وموثوقة، وإن المهمة فعلاً محتاجة بيانات أو أكتر من خطوة. لو الافتراض ده مش موجود، الوكيل بيتحوّل لعبء.
متى لا تستخدم وكيل
- لو المهمة بتتحل بنداء واحد: تلخيص نص، إعادة صياغة، تصنيف. هنا الحلقة overhead بدون فايدة.
- لو الكمون حرج (تجربة real-time)؛ كل خطوة بتضيف زمن، والمستخدم مش هيستنى.
- لو الأدوات نفسها مش جاهزة أو غير موثوقة؛ وكيل بيستعلم من مصدر بيكذب هيكذب بثقة أعلى.
- لو مش هتحط سقف خطوات و observability؛ من غيرهم الوكيل ممكن يدخل في حلقة ويحرق توكنز من غير ما تدري.
الخطوة التالية
خد أبسط مهمة في شغلك بتحتاج بيانات حيّة (مثلاً "حالة آخر طلب للعميل"). عرّف أداة واحدة بس ترجّع البيانات دي، ولفّ الحلقة اللي فوق بسقف 5 خطوات. بعدين قيس حاجتين: كام نداء API اتطلب فعلاً لكل سؤال، وكام مرة النموذج اختار الأداة الصح من أول خطوة. لو لقيته بيلف أكتر من اللازم، المشكلة غالبًا في وصف الأداة مش في النموذج — حسّن الوصف وأعد القياس.
المصادر
- ورقة ReAct الأصلية: Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models" (2022) — arxiv.org/abs/2210.03629
- توثيق Anthropic لـ Tool Use مع Claude — docs.anthropic.com/en/docs/build-with-claude/tool-use
- Google Cloud: Choose a design pattern for your agentic AI system — docs.cloud.google.com
- MindStudio: What Is the ReAct Loop? How AI Agents Reason, Act, and Iterate — mindstudio.ai
- Data Science Dojo: Agentic Loops, From ReAct to Loop Engineering (2026) — datasciencedojo.com