هذه المقالة السادسة من تسعٍ في سلسلتنا: هندسة الأوامر المتقدمة. السابقة: البرومبت متعدد الوسائط. التالية: سلاسل الأوامر الذكية وميتا-برومبتينج.

من الإجابة إلى التصرّف

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

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

هذه ليست قدرةً مستقبليةً بعيدة. في ٢٠٢٦، يدعم كلٌّ من كلود وGPT-4o وجيميني واجهاتٍ برمجيةٍ لاستخدام الأدوات تمنح النماذج إمكانية الوصول إلى البحث على الويب وتنفيذ الكود وأنظمة الملفات وقواعد البيانات والخدمات الخارجية. وأطر عمل مثل LangChain وLlamaIndex وأدوات كلود من أنثروبيك تجعل بناء سير عمل وكيلية متعددة الخطوات أمراً عملياً دون الحاجة إلى خبرةٍ هندسيةٍ عميقة. وبصورةٍ متزايدة، تُدمج أدواتٌ غير برمجية — كـ Zapier AI وMake وNotion AI — سير العمل الوكيلي في منتجاتٍ يستخدمها الفريلانسرون والمحترفون يومياً.

فهم كيفية برمجة الأنظمة الوكيلية مهارةٌ عمليةٌ اليوم، لا أكاديمية.

ما الذي يجعل نظاماً وكيلياً

ثلاث خصائصٍ تُميّز النظام الوكيلي عن استدعاء النموذج المعتاد:

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

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

إطار ReAct: فكّر، تصرّف، لاحظ

أكثر الأُطر المفاهيمية اعتماداً في برمجة الأوامر الوكيلية هو ReAct (اختصار Reason + Act أي “استدلال + فعل”)، الذي قدّمه ياو وزملاؤه في برينستون وجوجل في ورقة ٢٠٢٢. يُهيكل ReAct كل خطوةٍ في مهمةٍ وكيلية كدورةٍ ثلاثية المراحل:

الفكر (Thought): يستدل النموذج حول الوضع الراهن — ما الذي أُنجز، ما الذي لا يزال مطلوباً، أي أداةٍ أو إجراءٍ مناسب.
الفعل (Action): يختار النموذج أداةً ويستدعيها (بحث، آلة حاسبة، واجهة برمجية، مشغّل كود) أو يتخذ إجراءً في البيئة.
الملاحظة (Observation): يتلقّى النموذج نتيجة الفعل ويدمجها في استدلاله قبل الدورة التالية.

أظهرت الورقة أن ReAct تفوّق على النماذج التي تستدل دون تصرّف (سلسلة التفكير الصرفة) أو تتصرف دون استدلال (التعلم المعزَّز الصرف) في المهام التي تستلزم استرجاع المعلومات واتخاذ القرار. مزج الاستدلال الشفاف مع الفعل المُرسَّخ كان مفتاح التفوق.

ملاحظة حول لغة البرومبتات

تُكتب قوالب هذه المقالة بالإنكليزية لأن الأنظمة الوكيلية تشتغل في الغالب ضمن أكوادٍ وأُطر عمل تستخدم الإنكليزية. ترجمة كل قالبٍ موضوعةٌ مباشرةً تحته للفهم الكامل. يمكنك استبدال ما بين الأقواس [ .. ] باللغة التي تجيدها.

القالب الأول: برومبت الوكيل وفق إطار ReAct

هذا القالب التأسيسي لبناء وكيلٍ بأسلوب ReAct. يعمل مع أي نموذجٍ يدعم تعريفات الأدوات (كلود، GPT-4o، جيميني) ويمكن تكييفه لبيئاتٍ بلا أدوات حيث يُحاكي النموذج مخرجاتها من معرفته.

You are an autonomous agent working to achieve the following goal.

GOAL: [describe the end state you want achieved, not the steps]

AVAILABLE TOOLS:
- search(query): Returns top web search results for a query.
- run_code(code): Executes Python code and returns output.
- read_file(path): Reads the contents of a file.
- write_file(path, content): Writes content to a file.
[add or remove tools as available in your environment]

WORKING METHOD:
At each step, follow this structure exactly:

THOUGHT: [reason about the current state — what do you know,
          what do you still need, what should you do next?]
ACTION: [name the tool and the exact input you will pass to it]
OBSERVATION: [the result returned by the tool — do not fabricate;
              wait for the actual result before continuing]

Repeat THOUGHT → ACTION → OBSERVATION until the goal is achieved.

When the goal is complete, output:
FINAL ANSWER: [the result or deliverable]
STEPS TAKEN: [brief numbered list of what you did]
CONFIDENCE: [High / Medium / Low, with a one-sentence reason]

ترجمة القالب: أنت وكيلٌ مستقل تعمل على تحقيق الهدف التالي. الهدف: [صف الحالة النهائية المطلوبة لا الخطوات]. الأدوات المتاحة: بحث (استعلام) — يُعيد أفضل نتائج بحث الويب. تشغيل الكود (كود) — ينفّذ كود بايثون ويُعيد المخرج. قراءة ملف (مسار) — يقرأ محتوى ملف. كتابة ملف (مسار، محتوى) — يكتب محتوىً في ملف. طريقة العمل — في كل خطوة اتّبع هذا الهيكل بالضبط: فكر [استدل حول الوضع الراهن — ما تعرفه، ما لا تزال بحاجة إليه، ما الخطوة التالية المناسبة]. فعل [سمّ الأداة والمدخل الذي ستُمرّره إليها بالضبط]. ملاحظة [النتيجة التي تُعيدها الأداة — لا تخترع؛ انتظر النتيجة الفعلية قبل المتابعة]. كرّر فكر ← فعل ← ملاحظة حتى تحقق الهدف. حين يكتمل الهدف أخرج: الجواب النهائي [النتيجة أو المنتج]، الخطوات المتّخذة [قائمة مرقّمة مختصرة]، الثقة [عالية / متوسطة / منخفضة مع جملة تعليلية].

القالب الثاني: وكيل الخطة-ثم-التنفيذ

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

PHASE 1 — PLANNING:

You have been given the following goal:
GOAL: [describe what needs to be achieved]

CONSTRAINTS:
- [list any non-negotiable limits: time, tools available, scope]

Before taking any action, produce a complete plan:
1. Break the goal into sequential subtasks.
2. For each subtask, identify:
   - What tool or information source is needed.
   - What a successful output looks like.
   - What could go wrong and how you will handle it.
3. Identify any step where human review is required
   before continuing.

Output the plan as a numbered list. Do not begin execution.

---

[After human reviews and approves the plan:]

PHASE 2 — EXECUTION:

Execute the plan above step by step.
For each step, use the THOUGHT → ACTION → OBSERVATION format.
If a step produces an unexpected result, pause and explain
the discrepancy before deciding whether to continue or adapt.

ترجمة القالب: المرحلة الأولى — التخطيط: مُنحت الهدف التالي. الهدف: [صف ما يجب تحقيقه]. القيود: [أدرج الحدود غير القابلة للتفاوض: الوقت، الأدوات المتاحة، النطاق]. قبل اتخاذ أي إجراء، أنتج خطةً كاملة: ١) جزّئ الهدف إلى مهام فرعية متسلسلة. ٢) لكل مهمةٍ فرعية حدّد: الأداة أو مصدر المعلومات اللازمَين، وما يبدو عليه المخرج الناجح، وما قد يسوء وكيف ستتعامل معه. ٣) حدّد أي خطوةٍ تستلزم مراجعةً بشرية قبل المتابعة. أخرج الخطة كقائمة مرقّمة. لا تبدأ التنفيذ. بعد مراجعة الإنسان وموافقته: المرحلة الثانية — التنفيذ: نفّذ الخطة خطوةً بخطوة. لكل خطوة استخدم صيغة فكر ← فعل ← ملاحظة. إن أسفرت خطوةٌ عن نتيجةٍ غير متوقعة، أوقف وأوضح التناقض قبل قرار المتابعة أو التكيّف.

التوقف بين المرحلتين ليس اختيارياً. من أكثر إخفاقات الأنظمة الوكيلية شيوعاً وكيلٌ يسيء فهم الهدف في الخطوة الأولى ثم ينفّذ عشرين خطوةً لاحقةً بإتقانٍ — نحو نتيجةٍ خاطئة. مراجعة الخطة بشرياً تكلف دقائق. التراجع عن عشرين خطوةٍ خاطئة يكلف أكثر بكثير.

تعريف الأدوات بفعالية

جودة استخدام الوكيل للأدوات تعتمد بشكلٍ شبه كاملٍ على جودة تعريف تلك الأدوات، فالتعريفات المبهمة تُنتج استدعاءاتٍ مبهمة. الأداة المُعرَّفة جيداً تُخبر النموذج بالضبط ما تفعله الأداة، وما المدخلات التي تقبلها، وما تُعيده، ومتى يناسب أو لا يناسب استخدامها.

TOOL DEFINITIONS:

search(query: str) → list[str]
  Purpose: Find current information not in your training data.
  Use when: The task requires recent facts, prices, names,
            or events that may have changed since your cutoff.
  Do NOT use when: The answer is stable general knowledge
                   you are confident about.
  Returns: A list of text snippets from web results.
  Limit: Maximum 3 searches per task unless explicitly permitted.

run_code(code: str, language: str = "python") → str
  Purpose: Execute code and return the output or error message.
  Use when: The task requires computation, data processing,
            or file manipulation that text reasoning cannot do.
  Do NOT use when: A simpler text-based answer suffices.
  Returns: stdout output or error traceback as a string.
  Limit: Do not execute code that modifies files outside
         the designated working directory.

ask_user(question: str) → str
  Purpose: Request clarification or approval from the human.
  Use when: You reach a decision point where two valid paths
            exist and the correct one depends on human preference.
  Use when: A planned action is irreversible (deleting files,
            sending messages, making purchases).
  Returns: The human's text response.

ترجمة القالب (تعريفات الأدوات):
بحث (استعلام نصي) ← قائمة نصوص: الغرض — إيجاد معلوماتٍ راهنة غير موجودة في بيانات التدريب. استخدمها حين تستلزم المهمة حقائق أو أسعاراً أو أسماءً أو أحداثاً قد تغيّرت. لا تستخدمها حين يكون الجواب معرفةً عامةً ثابتة. تُعيد: قائمة مقتطفاتٍ نصية من نتائج الويب. الحد: ٣ عمليات بحث كحدٍّ أقصى للمهمة ما لم يُسمح بأكثر.
تشغيل الكود (كود نصي) ← نص: الغرض — تنفيذ الكود وإعادة المخرج أو رسالة الخطأ. استخدمه حين تستلزم المهمة حساباً أو معالجة بياناتٍ أو تعاملاً مع الملفات. تُعيد: مخرج stdout أو تتبّع الخطأ. الحد: لا تنفّذ كوداً يُعدّل ملفاتٍ خارج مجلد العمل المحدد.
سؤال المستخدم (سؤال نصي) ← نص: الغرض — طلب توضيحٍ أو موافقة من الإنسان. استخدمها حين تبلغ نقطة قرارٍ فيها مساران صالحان والصحيح منهما يعتمد على تفضيل الإنسان، أو حين يكون الإجراء المزمَع لا رجعة فيه (حذف ملفات، إرسال رسائل، إجراء مشتريات).

لاحظ أداة ask_user (سؤال المستخدم). بناء أداةٍ صريحة تُدخل الإنسان في الحلقة هو أحد أهم آليات السلامة في التصميم الوكيلي. بدونها قد تُكمل الأنظمة الوكيلية إجراءاتٍ لا رجعة فيها — إرسال رسائل بريد إلكتروني، وحذف ملفات، ونشر محتوى — دون أن تتاح للإنسان أي فرصةٍ للمراجعة.

أنماط إخفاق الأنظمة الوكيلية وكيف تُصمّم لتفاديها

تُخفق الأنظمة الوكيلية بطرقٍ لا تُخفق بها برومبتات المرور الواحد. فهم أنماط الإخفاق يُتيح تصميم برومبتاتٍ تقيها.

نمط الإخفاق	ما يحدث	الحل التصميمي
انجراف الهدف	يغوص الوكيل في مهمةٍ فرعية حتى يفقد الهدف الأصلي من أُفقه	أدرج الهدف في سياق كل دورة؛ أضف خطوة “تحقق من الهدف” كل ثلاثة أفعال
استدعاءات أدواتٍ مخترَعة	يختلق الوكيل مخرجات الأدوات بدلاً من انتظار الفعلية	نصّ صراحةً: “لا تُنشئ محتوى الملاحظة — انتظر إعادة الأداة الفعلية”
الحلقات اللانهائية	يكرر الوكيل الفعل ذاته حين لا يُعطي النتيجة المتوقعة	ضع حداً أقصى للخطوات؛ وجّه الوكيل للتصعيد عبر ask_user بعد محاولتَين فاشلتين على أي مهمةٍ فرعية
توسّع النطاق	يتخذ الوكيل إجراءاتٍ خارج حدود المهمة المحددة	عرّف الإجراءات الخارجة عن النطاق في تعليمات النظام؛ اشترط ask_user لأي إجراءٍ غير مدرجٍ صراحةً
إجراءٌ لا رجعة فيه	يحذف الوكيل أو يُرسل أو ينشر قبل المراجعة البشرية	صنّف الأدوات: قابلة للعكس أو لا؛ اشترط تأكيد ask_user قبل أي إجراءٍ لا رجعة فيه

حالات استخدامٍ وكيليةٍ عمليةٍ للمحترفين

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

للباحثين وكتّاب المحتوى المستقلين: يستطيع وكيلٌ بحثيٌ أن يُوجَّه للبحث عن مصادر حول موضوعٍ ما، واستخراج الادعاءات ذات الصلة من كل مصدر، والتحقق منها باستخدام تقنيات مكافحة الهلوسة من المقالة الرابعة، ثم إنتاج ملفٍّ بحثي مُهيكَل. ما يستغرق ساعتين من تبديل التبويبات وتدوين الملاحظات يمكن تشغيله كسير عمل وكيليٍ مُشرَفٌ عليه في جزءٍ بسيطٍ من ذلك الوقت. (راجع مقالتنا: الذكاء الاصطناعي في خدمة العمل الحر — ١٠ مهام بنصف الوقت.)
للمترجمين ومتخصصي التوطين: يستطيع سير عملٍ ترجميٍ وكيليٍ معالجة الوثيقة قسماً بقسمٍ، مع تطبيق البحث المصطلحي في كل خطوةٍ، وتشغيل فحص التوافق الذاتي على المصطلحات الغامضة، وتجميع قائمة المصطلحات من القرارات التي اتُّخذت خلال الترجمة. كل خطوةٍ في السلسلة هي استدعاء أداة؛ يراجع الإنسان المَخرج عند نقاط تفتيشٍ محددةٍ، لا باستمرار.
لمديري المحتوى: يمكن توجيه وكيلٍ للمحتوى لمراجعة مجموعة روابطٍ منشورةٍ في ضوء دليل الأسلوب، والإشارة إلى المقاطع غير الممتثِلة، واقتراح تصحيحاتٍ، وإنتاج قائمةٍ مراجعةٍ ذات أولوياتٍ، وكل ذلك دون أن يضطر الإنسان لفتح كلّ صفحةٍ يدوياً.

القالب الثالث: سير عمل وكيلي مبسَّط لغير المطوّرين

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

You are working through a multi-step task. Follow these rules strictly:

GOAL: [state the end result you need]

RULES:
1. Complete one step at a time. After each step, stop and output:
   STEP COMPLETE: [what you did and what you found]
   NEXT STEP: [what you plan to do next]
   WAITING FOR: [anything you need from me before continuing]

2. If you need information you do not have (a file, a URL,
   a number, a decision), ask for it explicitly before proceeding.
   Do not guess or fabricate.

3. Before any action that cannot be undone, state what you are
   about to do and wait for my confirmation.

4. After every 3 steps, output a PROGRESS CHECK:
   - Goal: [restate it]
   - Completed: [list what is done]
   - Remaining: [list what is left]
   - On track: Yes / No / Uncertain — explain if not Yes.

Begin with Step 1.

ترجمة القالب: أنت تعمل على مهمةٍ متعددة الخطوات. اتّبع هذه القواعد بدقة. الهدف: [حدّد النتيجة النهائية المطلوبة]. القواعد: ١) أنجز خطوةً واحدةً في كل مرة. بعد كل خطوةٍ أوقف وأخرج: الخطوة مكتملة [ما فعلته وما وجدته]، الخطوة التالية [ما تخطط فعله]، أنتظر [أي شيءٍ تحتاجه مني قبل المتابعة]. ٢) إن احتجت معلومةً ليست لديك (ملف، رابط، رقم، قرار)، اطلبها صراحةً قبل المتابعة. لا تخمّن ولا تخترع. ٣) قبل أي إجراءٍ لا يمكن التراجع عنه، صرّح بما ستفعله وانتظر تأكيدي. ٤) كل ثلاث خطواتٍ أخرج فحص تقدّم: الهدف [أعد صياغته]، المنجَز [أدرج ما أُنجز]، المتبقي [أدرج ما بقي]، على المسار: نعم / لا / غير متأكد — أوضح إن لم تكن الإجابة نعم. ابدأ بالخطوة الأولى.

الأخطاء الشائعة

وصف الخطوات بدلاً من الأهداف: “ابحث عن ثلاثة مقالات، لخّص كلاً منها، ثم ادمج الملخصات” هو إجراءٌ وليس هدف. يتقيّد الوكيل بطريقتك حتى لو كان هنالك طريقةٌ أفضل. استبدلها بـ: “أنتج نظرةً عامة موثّقة حول [الموضوع] يستطيع متخصصٌ/ أو غير متخصص التصرف بناءً عليها.” دع الوكيل يختار نهجه.
غياب شروط التوقف: وكيلٌ بلا معاييرٍ واضحة للاكتمال سيواصل إلى ما لا نهاية، يُصقل مخرجاتٍ تجاوزت نقطة تضاؤل العوائد أو يتشعّب نحو مناطقٍ غير مقصودة، لذا عَرّف دائماً ما يبدو عليه “الإنجاز”.
الوثوق بمخرج الوكيل دون مراجعة: الأنظمة الوكيلية تضخّم القرارات الجيدة والسيئة على حدٍّ سواء عبر خطواتٍ متعددة. تعليمةٌ مساءٌ فهمها في الخطوة الأولى تؤثر على كل خطوةٍ لاحقة. لذا فإن نقاط التفتيش الهيكلية — كل ثلاث خطوات، أو قبل أي إجراءٍ لا رجعة فيه — ليست تكاليف إضافية، بل هي الآلية التي تُبقي مخرجات الوكيل جديرةً بالثقة.
بناء وكلاء لمهامٍ لا تحتاجهم: إن كانت المهمة ذات خطوةٍ أو خطوتين، يُعالجها برومبت معتادٌ بشكلٍ أفضلٍ من وكيل. التعقيد الوكيلي مبرَّرٌ حين توجد نقاط قرارٍ حقيقيةٌ تعتمد على نتائجٍ وسيطةٍ، أي حين يعتمد ما تفعله في الخطوة الثالثة على ما وجدتَه في الخطوة الثانية.

تمارين تطبيقية

محاكاة ReAct: اختر مهمةً بحثيةً كنت تُنجزها يدوياً عادةً. شغّل القالب الأول في واجهة محادثة، وزوّد “مخرجات الأدوات” يدوياً لخطوات البحث والقراءة (الصق نتائج بحثٍ حقيقيةٍ أو مقتطفات وثائق). قارن المخرج المُهيكَل بما كنت ستُنتجه ببرومبت مرورٍ واحد.
مراجعة الخطة: استخدم القالب الثاني، المرحلة الأولى فقط، على مهمةٍ معقدة تعمل عليها حالياً. راجع الخطة التي ينتجها الوكيل قبل إقرارها. لاحظ ما إذا كانت الخطة تتطابق مع كيفية تعاملك أنت مع المهمة — وأين تختلف.
تدقيق أنماط الإخفاق: راجع سير عملٍ وكيلياً أو متعدد الخطوات استخدمته مؤخراً في أي أداة. حدد كل خطوةٍ في مقابل جدول أنماط الإخفاق. حدّد أنماط الإخفاق التي لا تزال دون حمايةٍ في سير عملك.

التالية في السلسلة: المقالة السابعة — سلاسل الأوامر الذكية وميتا-برومبتينج: أنظمة تكتب برومبتاتٍ أفضل منك.

المراجع

Yao, S. وآخرون (٢٠٢٢). ReAct: تآزر الاستدلال والتصرف في النماذج اللغوية. برينستون / جوجل. arxiv.org/abs/2210.03629
أنثروبيك (٢٠٢٤). وثائق استخدام الأدوات. docs.anthropic.com
منصة ذي يزن — الذكاء الاصطناعي في خدمة العمل الحر: ١٠ مهام بنصف الوقت. zyyazan.sy
منصة ذي يزن — هندسة السياق المتقدمة (مقدمة السلسلة). zyyazan.sy

🌐 اقرأ هذا المقال بالإنكليزية

هندسة الأوامر المتقدمة ٢٠٢٦