اختيار معماريات الأنظمة الوكيلة: دورة مكثفة تقودها القرارات

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

*22 مفهوماً • 5 قرارات • أربعة مسارات تعلم. مسار القارئ: 2 إلى 3 ساعات قراءة مفاهيمية خالصة، شجرة القرار، والأنماط الخمسة، وإشارات الفشل، بلا إعداد. مسارات المبتدئ والمتوسط والمتقدم: نحو يوم، ثم 2 إلى 3 أيام، ثم 4 إلى 5 أيام، مع قراءة مفاهيمية وعمق متزايد في تصنيف المهام الحقيقية، ورسم طوبولوجيات النشر، وربط إشارات التقييم الخاصة بكل نمط. التقدير الصادق: 2 إلى 3 ساعات لمسار القارئ؛ و4 إلى 5 أيام لفريق كي يجعل اختيار النمط عادة عمل. اختر مسارك قبل مختبر القرار في الجزء 5.*

المقالة المحورية: Bala Priya C, "Choosing the Right Agentic Design Pattern: A Decision-Tree Approach," Machine Learning Mastery, May 15, 2026: machinelearningmastery.com/choosing-the-right-agentic-design-pattern-a-decision-tree-approach. شجرة القرار في قلب هذه الدورة مأخوذة منها. أما طبقة التركيب، أي ما يعنيه كل نمط لطوبولوجيا النشر وحزمة التقييمات، فهي إضافة هذه الدورة فوقها.

---

النسخة المبسطة (اقرأها أولاً)

لقد بنيت وكلاء. ربما عامل دعم العملاء Maya من دورة Digital FTE، أو وكيل تقييم من دورة التطوير المدفوع بالتقييمات، أو وكيل Tier-1 Support أخذته حتى الإنتاج في دورة النشر السحابي. تستطيع الآن بناء واحد. ما لا تستطيع فعله بعد، بانضباط، هو أن تقرر أي نوع من الوكلاء ينبغي أن تبنيه في المرة التالية.

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

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

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

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

إذا لم تأخذ الدورات السابقة في مسار Agent Factory

تحيل هذه الدورة إلى الغلاف التشغيلي (Inngest)، وانضباط التقييمات، ونشر سحابي، وتستخدم "Maya's Tier-1 Support agent" مثالاً جارياً من تلك الدورات. تستطيع استخدام هذه الدورة تماماً من دون قراءتها. شجرة القرار ذات الأسئلة الخمسة، والأنماط الخمسة، وانضباط إشارات الفشل تقف وحدها كإطار قابل للنقل.

لأول مرور مركز بلا سياق الدورات السابقة، اقرأ بهذا الترتيب:

• الجزء 1، مشكلة اختيار النمط: يؤسس الانضباط
• الجزء 2، شجرة القرار ذات الأسئلة الخمسة: العمود المفاهيمي
• أنماط الجزء 3، مع مسح سريع لهوامش الغلاف التشغيلي في أول مرور
• الجزء 4، إشارات الفشل والمراجعة
• الجزء 5، مختبر القرار: الأمثلة الخمسة تعمل حتى بلا سياق Maya
• خاتمة الجزء 7

ما تتعامل معه كمعاينة أو اختياري في أول مرور:

• المفهوم 8.5، بدائيات SDK: مفيد إذا كنت تستخدم OpenAI Agents SDK؛ امسحه سريعاً إذا كنت تستخدم إطاراً آخر، لأن أشكال الأنماط تنتقل
• المفهوم 8.6، اعتبارات الغلاف التشغيلي مع Inngest: مفيد إذا كنت تشحن أنظمة وكيلة إنتاجية؛ امسحه إذا كنت في مرحلة التصميم فقط. الحجة أن "الأنماط الأعقد تحتاج آلية تشغيل أكبر" تعمم خارج Inngest
• هوامش تركيب النشر في الجزء 3: مفيدة إذا كنت على الحزمة السحابية نفسها؛ وينتقل المبدأ العام، أي أي الأنماط تحتاج صندوقاً رملياً وأيها لا تحتاج، إلى أي إعداد سحابي

تعامل مع الإحالات كأمثلة ملموسة لمبادئ عامة، لا كمتطلبات حراسة. يعمل الإطار من دونها.

جدول ترجمة المنصات، ما الذي يقابله كل اختيار في Agent Factory

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

مرجع Agent Factory، الحزمة المستخدمة هنا	بدائل شائعة في 2026	ما تفعله الطبقة
Inngest، الغلاف التشغيلي	Temporal, Restate, Dapr Workflows, AWS Step Functions, Azure Durable Functions, LangGraph جزئياً عبر checkpointers	المحفزات، التنفيذ المتين، التحكم في التدفق، بوابات HITL
OpenAI Agents SDK، محرك الوكيل	LangGraph, AutoGen, CrewAI, AWS Strands, Pydantic AI, LlamaIndex Workflows	حلقة الوكيل، توجيه الأدوات، تركيب متعدد الوكلاء، مخرجات منظمة
Phoenix / Arize، ملاحظة التتبع	Langfuse, Helicone, LangSmith, Logfire, Honeycomb, Datadog APM	قابلية ملاحظة لسلوك الوكيل لكل تتبع وخط trace-to-eval
Azure Container Apps، بيئة تشغيل الـharness	AWS Fargate, Google Cloud Run, Fly.io, Railway, Render, Kubernetes	مضيف خدمة HTTP طويلة العمر، autoscale، أسرار، ingress
Neon Postgres، حالة متينة	Supabase, AWS RDS Postgres, PlanetScale, CockroachDB, Google Cloud SQL	جلسات، تشغيلات، تتبعات، سجل تدقيق: حالة وكيل متينة
Cloudflare R2، تخزين ملفات	AWS S3, Google Cloud Storage, Azure Blob, Backblaze B2	مدخلات ومخرجات وآثار معرفة؛ وصول presigned URL للصندوق الرملي
Cloudflare Sandbox، تنفيذ الكود	E2B, Modal, Daytona, Vercel Sandbox, Fly.io Machines, Cloudflare Containers	مساحة عمل معزولة للكود الذي يولده الوكيل
@inngest_client.create_function	@workflow.defn في Temporal، تعريف state machine في Step Functions، StateGraph(...) في LangGraph	تسجيل وحدة دالة متينة
ctx.step.run(name, fn)	workflow.execute_activity()، حالة Task، node في StateGraph	نقطة تحقق متينة تحفظ الناتج عند retry
ctx.step.wait_for_event(...)	workflow.wait_condition()، waitForTaskToken، interrupt()	تعليق متين حتى حدث أو timeout، بدائية HITL
Fan-out trigger	child workflow متوازية، Map state، parallel edges	منسق واحد → N تشغيلات مختصين
Agent(...) + Runner.run()	Agent.execute()، Agent + initiate_chat()، Crew + kickoff()	تشغيل حلقة الوكيل
@function_tool	@tool، Tool(...)، نماذج Pydantic في CrewAI	كشف دالة Python كأداة للوكيل
handoff(target_agent)	Command(goto=...)، محادثات متداخلة، تفويض مهام	استلام المختص للمحادثة
Agent.as_tool()	subgraph-as-node، استدعاءات وكيل متداخلة، أنماط as_tool	المنسق يستخدم المختص كأداة
output_guardrail	node مخصص + conditional edge، validator pattern، AWS Strands guardrails	مرور نقد/تحقق على مخرجات الوكيل

كيف تستخدم الجدول. عندما تقول الدورة "غلّف Runner.run() داخل step.run"، وأنت على Temporal مع LangGraph، فاقرأها كـ"غلّف Agent.execute() داخل workflow.execute_activity()." الحجة المعمارية واحدة؛ والصياغة تختلف. نمط سيئ يجب تجنبه: لا تتعلم حزمة Agent Factory فقط لقراءة هذه الدورة. اربط البدائيات، واقرأ الإطار، وطبقه على حزمتك.

صف واحد لا يترجم بسلاسة: Agent.as_tool() مقابل handoff(). يميّز OpenAI Agents SDK بين "يبقى المنسق مسؤولاً" (as_tool) و"يستلم المختص" (handoff) كبدائيات من الدرجة الأولى. تجمع معظم الأطر الأخرى هذا الفرق أو تطبق نصفاً واحداً. الفرق نفسه هو المهم معمارياً؛ اسم البدائية عرضي. عندما تختار في إطارك بين تركيب بأسلوب as_tool وتركيب بأسلوب handoff، فأنت تتخذ الاختيار المعماري نفسه الذي تسميه هذه الدورة.

---

المسرد (اقرأه مرة وارجع إليه عند الحاجة)

اضغط لتوسيع المسرد الكامل.

• Agentic design pattern. شكل معماري متكرر لأنظمة وكلاء الذكاء الاصطناعي: سير عمل تسلسلي، ReAct مع أدوات، تخطيط وتنفيذ، انعكاس، متعدد الوكلاء المتخصصين. يفترض كل نمط أشياء محددة عن المهمة؛ عندما تصح افتراضاته يضيف قيمة، وعندما لا تصح يصبح عبئاً.
• Sequential workflow. خط أنابيب ثابت من الخطوات حيث يغذي ناتج كل خطوة التالية. مسار الحل معروف مسبقاً؛ وتُحجز استدعاءات LLM للتفسير أو التوليد، لا لتحديد الخطوة التالية. مثال: استقبال فاتورة → استخراج → تحقق → تخزين → إشعار.
• ReAct (Reason + Act). حلقة وكيلة يتناوب فيها الوكيل بين الاستدلال حول حالته الحالية واتخاذ إجراء، غالباً استدعاء أداة، ثم يلاحظ النتيجة ويكرر. الخاصية المحددة: القرار التالي يُتخذ وقت التشغيل، لا يُحدد مسبقاً.
• Planning agent. وكيل ينتج خطة صريحة، تسلسل مراحل مع اعتماديات، قبل بدء التنفيذ. تنظم الخطة العمل؛ وقد تستخدم الخطوات الفردية ReAct داخلياً. مثال: "ابحث سوقاً" → أنشئ خطة من 5 خطوات → نفّذ كل خطوة بالأدوات.
• Reflection (self-critique). نمط يولّد فيه الوكيل مخرجاً، ثم ينقده مقابل معايير صريحة، ثم يحسّنه بناء على النقد. يضيف كموناً وتكلفة؛ ولا يكون مفيداً إلا عندما تكون المعايير قابلة للفحص والأخطاء مكلفة.
• Multi-agent specialist system. نظام يتعاون فيه وكلاء متعددون بأدوار متميزة، مثل باحث وكاتب ومراجع، بتنسيق من وكيل توجيه أو مشرف. تبرره الحاجة إلى التخصص أو فائض السياق أو التنفيذ المتوازي؛ لا الشكل الجمالي.
• Solution path. تسلسل الخطوات الذي يحل المهمة. المسار المعروف يمكن تحديده قبل وقت التشغيل؛ والمسار المجهول يظهر من تحقيق الوكيل.
• Task structure. المراحل الكبرى واعتمادياتها. البنية القابلة للصياغة تستطيع وصفها قبل التنفيذ؛ والبنية الناشئة تتكشف من التغذية الراجعة.
• Architectural fit. التطابق بين افتراضات النمط وخصائص المهمة الفعلية. اختيار النمط مطابقة ملاءمة لا مطابقة قدرة: اختيار النمط "الأقوى" منطق خاطئ.
• Coordination overhead. تكلفة التوجيه بين وكلاء متعددين أو تنسيق تسليماتهم، في tokens والكمون وتعقيد التنقيح وأنماط الفشل. تدفع الأنظمة متعددة الوكلاء هذه التكلفة، ويجب أن يبررها ما تكسبه.
• Failure signal. عرض وقت التشغيل الذي يدل أن النمط لا يطابق المهمة. أمثلة: حلقات ReAct تعيد العمل المحلول، وخطط ينحرف عنها التنفيذ، وانعكاس لا يحسن المخرج.
• Pattern composition. استخدام أنماط مختلفة في طبقات مختلفة من نظام أكبر. مثال: وكيل تخطيط في الطبقة العليا، وReAct مع أدوات داخل كل خطوة، وانعكاس على التركيب النهائي.
• Agent (OpenAI Agents SDK). صنف SDK الأساسي: كيان تقوده LLM مع instructions=، وأدوات اختيارية، وoutput_type= اختياري للمخرجات المنظمة، وhandoffs= اختياري. الوحدة الذرية لكل نمط في هذه الدورة.
• Runner.run(agent, input) (OpenAI Agents SDK). استدعاء SDK الذي يشغّل Agent حتى ينتج مخرجاً نهائياً. يشغّل الـSDK حلقة reason-act-observe داخلياً: لا حاجة إلى حلقة يدوية. معامل max_turns= هو ميزانية الخطوات.
• @function_tool (OpenAI Agents SDK). decorator يحول دالة Python إلى أداة يستطيع الوكيل استدعاءها. تصبح type hints وdocstrings مخطط JSON للأداة تلقائياً.
• handoff() (OpenAI Agents SDK). بدائية SDK من الدرجة الأولى للانتقالات متعددة الوكلاء: وكيل يسلم المحادثة صراحة إلى آخر، ويحفظ الـSDK السياق. استخدمها عندما يحتاج المختص إلى استلام التفاعل مع المستخدم.
• Agent.as_tool() (OpenAI Agents SDK). طريقة تغلف Agent كأداة قابلة للاستدعاء يستطيع Agent آخر استخدامها. استخدمها عندما ينبغي أن يبقى المنسق مسؤولاً ويجمع مخرجات المختصين.
• output_guardrail (OpenAI Agents SDK). decorator يربط وكيل تحقق/نقد بمسار مخرجات وكيل آخر. بدائية SDK الأصلية لانعكاس block-bad-outputs؛ ترفع OutputGuardrailTripwireTriggered عند التفعيل.
• Operational envelope (Inngest). طبقة وقت التشغيل التي توقظ دالة الوكيل، وتصمد بعد الأعطال، وتحد الحمل، وتنسق HITL. تتركب مع النشر السحابي ومحرك الـSDK. تُدرّس في دورة الغلاف التشغيلي.
• @inngest_client.create_function (Inngest). decorator يسجل دالة Python غير متزامنة في Inngest كوحدة تنفيذ متينة. يعلن سطح التحفيز وسياسة التحكم في التدفق.
• ctx.step.run(name, fn, args) (Inngest). نقطة تحقق المتانة. الخطوات المكتملة تعيد الناتج المحفوظ عند retry؛ والخطوات الفاشلة تعيد المحاولة مستقلة بتراجع أسي.
• ctx.step.wait_for_event(...) (Inngest). تعليق متين حتى يصل حدث مطابق أو يحدث timeout. لا تُستهلك حوسبة أثناء التعليق. بدائية وقت التشغيل خلف بوابات HITL.
• Fan-out trigger pattern (Inngest). دالة منسقة واحدة تصدر N أحداث؛ وكل حدث يوقظ دالة مشتركة خاصة به. بدائية وقت التشغيل خلف التنفيذ المتوازي للمختصين في الأنظمة متعددة الوكلاء.
• Replay (Inngest). التشغيلات الفاشلة تبقى بتتبع كامل. اشحن إصلاحاً، اضغط replay؛ وتستأنف الدالة من الخطوة الفاشلة بالكود الجديد. الخطوات الناجحة تبقى memoized.

---

هل أنت جاهز؟ (المتطلبات)

1. بنيت أول وكيل لك، أو لديك خبرة مكافئة. تفترض الأنماط هنا أنك تعرف ما حلقة الوكيل، وكيف يبدو استدعاء أداة، وكيف يعيد النموذج مخرجاً منظماً. إذا لم تبنِ وكيلاً بعد، فابدأ بـدورة بناء الوكلاء.
2. بنيت وكيلاً عاملاً واحداً على الأقل. سواء كان عامل دعم العملاء Maya، أو وكيل بحث، أو chatbot، أو وكيل برمجة، تحتاج إلى خبرة اتخاذ اختيار معماري والعيش مع نتائجه.
3. تستطيع قراءة pseudocode. هذه دورة مفاهيمية، لذلك فيها قليل جداً من الكود التنفيذي. سترى pseudocode لتوضيح الأنماط؛ إذا كنت تستطيع قراءة Python أو TypeScript، تستطيع قراءته.
4. اختياري لكن موصى به بقوة: أن تكون أنهيت دورتي التقييمات والنشر السحابي. مساهمة هذه الدورة الأساسية هي تركيب اختيار النمط مع طوبولوجيا النشر وحزمة التقييمات. سيستفيد القراء الذين لم ينجزوا تلك الدورات من الإطار، لكنهم سيفقدون حجج التكامل.

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

حواف خشنة ينبغي معرفتها مقدماً (النطاق الصادق)

• هذه دورة مفاهيمية، لا دورة كود. تعلّمك كيف تختار معمارية، لا كيف تنفذها. يعيش انضباط التنفيذ في دورات Agent Factory السابقة. توقع نحو 30 صفحة من الاستدلال المعماري ونحو 5 صفحات من pseudocode إجمالاً.
• الأنماط الخمسة ليست شاملة. في الواقع توجد أنظمة وكيلة قائمة على الرسوم، وأنماط مناظرة، وأنماط blackboard، وشبكات مهام هرمية، وغيرها. تغطي هذه الدورة الأنماط الخمسة التي تحددها المقالة كنقاط البداية المعمارية المهيمنة؛ تغطي هذه الخمسة أغلب أنظمة الإنتاج الوكيلة في منتصف 2026، لا كلها.
• شجرة القرار نقطة بداية، لا جواب نهائي. تتطور معماريات الوكلاء الحقيقية. قد يبدأ نظام كوكيل واحد مع أدوات ثم ينمو إلى نظام متعدد الوكلاء مع تنوع العمل؛ وقد يبسط نظام تخطيط وتنفيذ إلى سير عمل تسلسلي عندما تتضح المسارات. تعلّم هذه الدورة قرار البداية، لا التطور.
• التكلفة والكمون جزء من الاختيار. يضيف الانعكاس كموناً. ويضيف تعدد الوكلاء tokens. ويضيف التخطيط استدعاء LLM إضافياً. تعامل الدورة مع هذه التكاليف كقيود حقيقية؛ ويغطي المفهوم 18 متى يستحق عبء كل نمط.
• المقالة هي العمود؛ وطبقة التركيب هي الامتداد. شجرة قرار Bala Priya C هي العمود البنيوي لهذه الدورة. تضيف هذه الدورة طبقتين لا تغطيهما المقالة: ما يعنيه كل نمط لطوبولوجيا النشر، وكيف تبدو أنماط فشله عبر حزمة التقييمات. إذا قرأت المقالة فقط، تضيف لك هذه الدورة طبقة انضباط الإنتاج.

---

أربعة مسارات تعلم

المسار	الالتزام الزمني	ما تكمله	لمن يناسب
القارئ، مفاهيمي فقط	نحو 2 إلى 3 ساعات، بلا مختبر	القوس المفاهيمي الكامل: الجزء 1، المشكلة؛ الجزء 2، شجرة القرار؛ الجزء 3، الأنماط الخمسة؛ الجزء 4، إشارات الفشل؛ وخاتمة الجزء 7. لا تمارين تصنيف، لا مختبر قرار.	القادة الهندسيون، ومعماريو المنصات، أو القراء الفضوليون غير المهندسين الذين يقررون هل يستحق اختيار النمط المنهجي وقت الفريق.
المبتدئ	نحو يوم	مسار القارئ مع القرارين 1 و2 في مختبر القرار. تصنف مهمتين، Maya's Tier-1 Support ووكيل incident response، باستخدام شجرة القرار؛ وترسم النمط المختار بمستوى عالٍ.	مهندسون جدد في المعمارية الوكيلة يريدون جولة تدريب موجهة واحدة.
المتوسط	نحو 2 إلى 3 أيام	مسار المبتدئ مع القرارين 3 و4. تضيف وكيل بحث ووكيل enterprise onboarding؛ وترسم طوبولوجيات النشر على حزمتك السحابية؛ وتحدد إشارات التقييم التي تلتقط فشل كل نمط.	مهندسون يشحنون أنظمة وكيلة ويريدون تركيب اختيار النمط مع النشر والتقييم.
المتقدم	نحو 4 إلى 5 أيام	مسار المتوسط مع القرار 5 والأجزاء 6 و7. تضيف وكيل برمجة، أصعب حالة؛ وتستكشف تركيب الأنماط؛ وتعمّر نظام وكلاء افتراضياً من البداية إلى النهاية.	مهندسون كبار وقادة تقنيون يريدون جعل اختيار النمط انضباطاً للفريق كله.

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

أقصر مسار قابل للعمل لاختيار النمط. اقرأ الجزء 1، المشكلة؛ والجزء 2، شجرة القرار؛ والقرار 1 من المختبر، Maya's Tier-1 Support. هذا نحو 90 دقيقة؛ وفي النهاية تستطيع تصنيف مهمة جديدة بالأسئلة الخمسة واختيار نمط بداية. كل ما سواه يعمّق الانضباط؛ هذا هو البذرة.

ما الذي سيكون لديك في النهاية (مخرجات ملموسة)

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

وتنتج مسارات المبتدئ والمتوسط والمتقدم انضباط تصنيف عاملاً:

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

---

TL;DR، الادعاءات الأربعة التي تدافع عنها هذه الدورة

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

   أربعة أنماط أساسية + طبقة إضافية واحدة. تختار Q1 إلى Q3 النمط الأساسي: سير عمل تسلسلي، أو وكيل واحد مع ReAct وأدوات، أو التخطيط مع تنفيذ ReAct، أو نظام متعدد الوكلاء المتخصصين. تحدد Q4 هل تضيف الانعكاس كطبقة فوق النمط الأساسي المختار. الانعكاس ليس نمطاً خامساً مساوياً؛ إنه طبقة ضبط جودة تلف أي نمط أساسي. هذا الفرق مهم: من يعامل الانعكاس كنمط مستقل يفوته أنه يتركب مع النمط الأساسي المختار.

2. خمسة أسئلة عن المهمة تحدد المعمارية. تختار Q1 إلى Q3 النمط الأساسي: هل مسار الحل معروف؟ هل سير العمل ثابت؟ هل بنية المهمة قابلة للصياغة؟ تحدد Q4 هل تُضاف طبقة الانعكاس: هل الجودة أهم من السرعة مع معايير قابلة للفحص؟ وتحدد Q5 هل ترقى إلى متعدد الوكلاء: هل توجد عنق زجاجة في التخصص أو السياق أو الحجم؟ تقود الإجابات بحتمية إلى معمارية بداية.

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

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

شكل ما تتعلمه (رسم واحد، ارجع إليه طوال الدورة)

تقدم هذه الدورة 22 مفهوماً، 19 أساسياً مع 3 مفاهيم جسر عند 8.5 و8.6 و16.5، وتمشي عبر 5 قرارات. قبل ذلك كله، هذه هي شجرة القرار التي يتركب حولها كل شيء.

*شكل الشجرة: ابدأ بسؤال هل تحتاج حتى إلى وكيل تقوده LLM، أي Q1 وQ2؛ وإذا نعم، اسأل عن مدى بنية المهمة، Q3؛ ثم أضف الجودة، Q4، والحجم، Q5، فقط عندما يخلقان قيمة حقيقية. ارجع إلى هذا الرسم كلما بدا مفهوم أو قرار مجرداً.*

---

الجزء 1: مشكلة اختيار النمط

المفهوم 1: اختيار النمط هو عمل التصميم الذي يسبق البناء

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

كاتالوغ الأنماط ناضج. جاء ReAct من ورقة عام 2022. وتعود أنماط التخطيط ثم التنفيذ إلى STRIPS في الذكاء الاصطناعي الكلاسيكي ثم أُعيد اكتشافها لـLLMs في 2023. وصيغ الانعكاس رسمياً منذ 2023. وتعلّم كل الأطر الكبرى معماريات متعددة الوكلاء. تستطيع إيجاد درس لأي نمط في أقل من خمس دقائق. ما يصعب إيجاده هو: إذا كانت هذه المهمة المحددة بهذه القيود، فأي نمط يلائمها؟

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

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

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

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

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

المفهوم 2: كل نمط يراهن على شيء مختلف في المهمة

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

هذا ما يراهن عليه كل نمط:

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

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

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

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

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

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

الخلاصة: كل نمط وكيل رهان على المهمة: سير العمل التسلسلي يراهن على مسارات معروفة ثابتة، وReAct على مسارات مجهولة تكيفية، والتخطيط على بنية قابلة للصياغة، والانعكاس على معايير جودة قابلة للفحص، ومتعدد الوكلاء على حاجة تخصص حقيقية. النمط الصحيح هو الذي يطابق رهانه الواقع؛ اختيار النمط مطابقة ملاءمة لا مطابقة قدرة.

المفهوم 3: نمطا فشل، المبالغة والنقص

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

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

• بناء نظام من ثلاثة وكلاء، باحث وكاتب ومراجع، لمهمة توليد منشور LinkedIn واحد. مخرج وكيل "الباحث" فقرتان يضطر "الكاتب" إلى تلخيصهما. يرفض المراجع 5% من المخرجات لأمور كان prompt self-checking سيلتقطها. ثلاثة وكلاء، ثلاثة أضعاف التكلفة، بلا تحسن جودة قابل للقياس.
• إضافة التخطيط لمهمة هي في الحقيقة سير عمل ثابت. ينتج المخطط الخطة نفسها كل مرة لأن المهمة نفسها. يدفع كل تشغيل استدعاء LLM إضافياً بلا فائدة. والأسوأ: عندما يكون الإدخال غير معتاد قليلاً، ينتج المخطط خطة مختلفة قليلاً، والآن يضطر الفريق إلى تنقيح "لماذا أخذ المخطط مساراً مختلفاً؟"
• إضافة الانعكاس إلى مهمة بلا معايير قابلة للفحص. يشترك الناقد والمولد في النموذج وبيانات التدريب وغالباً العمى. يصدق النقد المخرج أو ينتج نقداً مطولاً غير قابل للتنفيذ. يتضاعف الكمون وتبقى الجودة ثابتة.

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

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

• استخدام وكيل واحد بتعليمة نظام 4,000 token لمعالجة دعم العملاء عبر الفوترة، والتقنية، والحسابات، والاستردادات. يخلط الوكيل قواعد الفوترة بالقواعد التقنية. يساعد الانعكاس قليلاً لكنه لا يحل الجذر. كانت المهمة تحتاج فعلاً إلى توجيه متخصص؛ لم يستطع وكيل واحد حمل السياق.
• استخدام ReAct + أدوات لسير عمل كان ينبغي أن يكون pipeline ثابتاً. يتجاوز الوكيل أحياناً خطوات، ويعود أحياناً إلى عمل مكتمل، ويخترع أحياناً استدعاءات أدوات غير موجودة. يضيف الفريق "stop conditions" و"progress criteria" إلى prompt، فيعالج الأعراض لا عدم التطابق. تصبح تقلبات التكلفة مشكلة runbook.
• تجاوز الانعكاس على مخرجات تحتاج تحققاً فعلاً. تشحن استعلامات SQL ذات أخطاء خفية إلى الإنتاج. وتُرسل مسودات قانونية بعيوب في الاستشهاد إلى العملاء. يضيف الفريق اختبارات بعد الواقعة، لكن المكان الطبيعي لالتقاط هذه الأخطاء كان مرور انعكاس وقت التوليد.

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

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

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

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

---

الجزء 2: شجرة القرار ذات الأسئلة الخمسة

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

بنية الشجرة:

#	السؤال	ما الذي يختبره	يقود إلى
Q1	هل يمكن تحديد مسار الحل مسبقاً؟	هل يمكن تحديد العملية قبل وقت التشغيل	إذا نعم → Q2؛ إذا لا → حاجة إلى استدلال تكيفي، اذهب إلى Q3
Q2	هل سير العمل ثابت ومستقر عبر التشغيلات؟	هل تنطبق الخطوات نفسها كل مرة	إذا نعم → سير عمل تسلسلي؛ إذا لا → راجع الأنماط التكيفية
Q3	هل بنية المهمة قابلة للصياغة قبل التنفيذ؟	هل المراحل الكبرى والاعتماديات واضحة	إذا نعم → تخطيط + تنفيذ ReAct؛ إذا لا → وكيل واحد + ReAct + أدوات
Q4	هل الجودة أهم من السرعة، مع معايير قابلة للفحص؟	هل تستحق مرورات النقد/التحسين الإضافية الكمون والتكلفة	إذا نعم → أضف طبقة انعكاس فوق النمط المختار؛ إذا لا → تجاوز الانعكاس
Q5	هل توجد عنق زجاجة في التخصص أو السياق أو الحجم؟	هل يفتقر وكيل واحد إلى الخبرة أو السياق أو السعة المتوازية	إذا نعم → نظام متعدد الوكلاء المتخصصين؛ إذا لا → أبقِ وكيلاً واحداً

تحدد الأسئلة 1 إلى 3 النمط الأساسي. أما السؤالان 4 و5 فطبقات إضافية؛ يمكن أن ينطبقا فوق أي نمط أساسي، لكن فقط عندما تصح افتراضاتهما.

المفهوم 4: Q1: هل يمكن تحديد مسار الحل مسبقاً؟

هذا أهم سؤال، لأنه يحدد هل تحتاج إلى نظام وكيل أصلاً.

ما معنى "مسار الحل". عملياً: إذا قلت لك الإدخال، هل تستطيع أن تخبرني التسلسل الدقيق للخطوات الذي ينتج المخرج؟ ليس الجواب نفسه، بل المسار. في استقبال الفواتير: استقبل البريد → استخرج الحقول المنظمة → تحقق من قاعدة البيانات → خزّن → أشعر الطالب. خمس خطوات، الخطوات الخمس نفسها، كل مرة. هذا مسار حل معروف.

قارن ذلك بسؤال عميل: "لماذا حُسب علي مرتين في 12 نوفمبر؟" يعتمد المسار على ما تجده. ابحث في تاريخ المعاملات. وجدته. إذا كانت العمليتان من تاجرين مختلفين، انتقل إلى "هل هذا احتيال؟" وإذا كانتا من التاجر نفسه بأوقات مختلفة، انتقل إلى "هل الثانية retry؟" وإذا كان للحساب مستخدمون متعددون، انتقل إلى "هل اشترى شخص آخر؟" كل فرع يقود إلى خطوة مختلفة. لا يمكن تحديد المسار مسبقاً؛ يظهر من التحقيق. هذا مسار حل مجهول.

كيف تختبر ذلك بصدق. ثلاثة اختبارات بالترتيب:

1. هل تستطيع رسم flowchart للخطوات قبل رؤية الإدخال؟ إذا نعم، فالمسار معروف. إذا احتاج flowchart إلى مربعات "الآن يقرر الوكيل ما يفعل"، فالمسار مجهول.
2. هل تتكرر الخطوات بلا تغيير عبر تشغيلات كثيرة؟ استقبال الفواتير يتكرر. تحقيقات دعم العملاء لا. قد يكون تقرير بحث بالشكل نفسه كل مرة، مقدمة وثلاثة أقسام وخاتمة، لكن اكتشاف المحتوى ليس تسلسلاً ثابتاً؛ إنه بحث تكيفي.
3. عندما يتغير الإدخال، هل تتغير الخطوات؟ ينتج المسار المعروف تسلسل الخطوات نفسه لمدخلات مختلفة. وينتج المسار المجهول تسلسلات مختلفة حسب ما يكشفه كل إجراء.

أين تخطئ الفرق. أكثر خطأ شيوعاً هو الاعتقاد أن المسار معروف لأن وصف المهمة يبدو منظماً. "معالجة طلبات الاسترداد" تبدو معروفة: استقبل الطلب، ابحث عن الطلبية، أصدر الاسترداد، أخطر العميل. طلبات الاسترداد الحقيقية ليست كذلك. بعضها يحتاج تحقيق نزاع، هل هو chargeback؟ وبعضها يحتاج بحث سياسة، هل خطة هذا العميل تسمح بالاسترداد؟ وبعضها يحتاج تصعيداً، فالمبلغ يتجاوز سلطة الوكيل؛ وبعضها يتضمن عدة charges تحتاج توضيحاً. flowchart الأربع خطوات خاطئ؛ المسار الفعلي تكيفي.

والخطأ المعاكس: الاعتقاد أن المسار مجهول لأن الوصف يبدو مفتوحاً. "ساعدني في إيجاد مطعم جيد في المدينة الليلة" يبدو تكيفياً، لكن إذا كان التنفيذ الفعلي: حلل الطلب → استعلم قاعدة المطاعم بفلاتر → أعد أفضل 5 بالتقييم، فالمسار معروف وسير العمل التسلسلي هو النمط الصحيح. الإطار "الوكيل" كان مضللاً.

المسار. إذا كان المسار معروفاً ومستقراً، انظر Q2، فأنت تتجه إلى سير عمل تسلسلي. قد لا تحتاج حتى إلى وكيل تقوده LLM؛ قد تحتاج إلى workflow مع استدعاءات LLM مضمّنة في خطوات محددة للتفسير أو التوليد. إذا كان المسار مجهولاً، تحتاج استدلالاً وكيلاً؛ والسؤال هو هل البنية قابلة للصياغة، Q3 والتخطيط، أم لا، Q3 وReAct خالص.

قاعدة عملية مفيدة. اسأل نفسك: "لو اضطررت إلى كتابة هذا كدالة Python بلا استدعاءات LLM، هل أعرف كيف أبنيه؟" إذا نعم، فالمسار غالباً معروف؛ وتحتاج LLM فقط في لحظات استدلال أو توليد محددة. إذا لا، فالمسار غالباً مجهول؛ وLLM تتخذ قرارات بنيوية لا توليدية فقط.

الخلاصة: يسأل Q1 هل يمكن تحديد مسار الحل قبل وقت التشغيل. المسارات المعروفة تقود إلى workflows تسلسلية، Q2؛ والمسارات المجهولة تقود إلى استدلال وكيلي تكيفي، Q3. الخطأ الأكثر شيوعاً هو الاعتقاد أن المسار معروف عندما يبدو وصف المهمة منظماً لكن التنفيذ تكيفي، مثل الاستردادات والدعم والتنقيح. والخطأ المعاكس هو الاعتقاد أنه مجهول عندما يكون workflow بمدخلات ذات نكهة LLM. اختبر بقاعدة "دالة Python بلا LLM".

المفهوم 5: Q2: هل سير العمل ثابت ومستقر عبر التشغيلات؟

أجبت Q1 بـ"نعم، المسار معروف". Q2 هو الفحص الثاني: هل هو ثابت ومستقر عبر المدخلات التي تتوقعها فعلاً؟ لأن "معروف" و"مستقر" ليسا الشيء نفسه.

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

في المقابل: استقبال الفواتير. كل فاتورة تمر بالخطوات الخمس نفسها. المسار مستقر. يختلف محتوى كل خطوة، بائعون ومبالغ مختلفة، لكن بنية الخطوات لا تتغير.

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

الاختبار. انظر إلى عينة ممثلة من المدخلات الحقيقية أو تخيلها بعناية. هل يبقى تسلسل الخطوات نفسه؟

• نعم، كل إدخال يمر بالخطوات نفسها → سير العمل مستقر؛ ابنِ سير عمل تسلسلياً.
• لا، المدخلات المختلفة تحتاج تسلسلات خطوات مختلفة → سير العمل متغير؛ تحتاج إما (أ) workflow بفروع صريحة لكل متغير، أو (ب) نمط وكيل يتكيف مع المسار بناء على الإدخال.

أين تخطئ الفرق. معاملة "معروف في المتوسط" كأنه "معروف ومستقر". حالة 80% هي workflow ثابت؛ وحالة 20% تحتاج انحرافاً. يبني المهندسون workflow لحالة 80% ويضيفون patches عشوائية لـ20%. في النهاية تهيمن patches على workflow الأصلي، ويصبح لديك hybrid غير موثق لا يفهمه أحد. يظهر هذا غالباً عندما لا يريد الفريق الاعتراف بأن المهمة أكثر تكيفاً مما تمنوا: workflows التسلسلية تبدو أكثر أماناً من الأنماط الوكيلة، فيفرطون في ملاءمتها.

المسار. إذا كان سير العمل ثابتاً ومستقراً → سير عمل تسلسلي. توقف هنا لهذا الفرع من الشجرة. تجاوز Q3، وغالباً Q4. فكّر في Q5 فقط إذا أجبر الحجم التوازي عبر instances من workflow.

إذا كان workflow معروفاً لكنه متغير → أمامك خياران:

1. سير عمل تسلسلي بفروع صريحة: اكتب كل متغير كفرع؛ ووجّه إليه حتمياً، غالباً باستدعاء LLM صغير يصنف نوع الإدخال ثم يوجه. الأفضل عندما تكون المتغيرات قليلة ومستقرة.
2. عامل المسار كأنه مجهول عملياً: انتقل إلى Q3 ودع الاستدلال الوكيلي يتعامل مع التغير. الأفضل عندما تكون المتغيرات كثيرة أو تتطور.

قاعدة عملية. إذا استطعت عد المتغيرات على يد واحدة ولا تتغير كثيراً، استخدم workflow متفرعاً. إذا لم تستطع، استخدم نمطاً وكيلاً.

الخلاصة: يسأل Q2 هل المسار المعروف مستقر أيضاً عبر المدخلات المتوقعة. المسارات المستقرة تقود إلى سير عمل تسلسلي. والمسارات المعروفة-المتغيرة تقود إما إلى workflows بفروع صريحة، إذا كانت المتغيرات قليلة ومستقرة، أو إلى أنماط وكيلة، إذا كانت كثيرة أو تتطور. الفخ هو اعتبار "حالة 80% ثابتة" كأنها "ثابتة"؛ تكبر حالة 20% إلى patches تهيمن على التصميم الأصلي.

المفهوم 6: Q3: هل بنية المهمة قابلة للصياغة قبل التنفيذ؟

أجبت Q1 بأن المسار مجهول، لذلك تحتاج إلى استدلال وكيلي. يسأل Q3 السؤال التالي: هل البنية عالية المستوى للعمل قابلة للصياغة مسبقاً، حتى لو لم تكن الخطوات المحددة كذلك؟

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

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

الاختبار. حاول رسم العمل كمخطط مراحل قبل رؤية أي إدخال محدد. هل تستطيع تسمية المراحل الكبرى واعتمادياتها؟

• نعم، المراحل واضحة، جمع → تحليل → تركيب، أو تصميم → تنفيذ → اختبار، أو بحث → مسودة → مراجعة → البنية قابلة للصياغة؛ استخدم التخطيط.
• لا، العمل لا يلائم مراحل، بل تحقيق أو تكرار أو استكشاف مفتوح → البنية غير قابلة للصياغة؛ استخدم ReAct.

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

والخطأ المعاكس: فقدان بنية موجودة فعلاً. يستخدم المهندسون ReAct خالصاً لمهام لها مراحل حقيقية. يتيه الوكيل، أو يعيد العمل المحلول، أو يفقد مسار التقدم. إضافة "تذكر فعل هذه المراحل" إلى prompt حل مؤقت؛ والإصلاح المعماري هو إضافة التخطيط فوق حلقة ReAct.

المسار. إذا كانت البنية قابلة للصياغة → تخطيط + تنفيذ ReAct. ينتج وكيل التخطيط بنية المراحل؛ ويعمل ReAct داخل كل مرحلة للتعامل مع التكيف في الخطوات الذي حدده Q1.

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

قاعدة تستحق الترسخ. يساعد التخطيط عندما يكون شكل العمل متوقعاً لكن محتواه غير متوقع. ويكون ReAct وحده صحيحاً عندما يعتمد حتى الشكل على ما تكتشفه. تمييز الشكل مقابل المحتوى هو أنظف طريقة للفصل بينهما.

التباس Q2 وQ3، توضيح بالأمثلة

يربك Q2، "هل سير العمل ثابت ومستقر؟"، وQ3، "هل بنية المهمة قابلة للصياغة؟"، حتى الفرق الخبيرة. كلاهما يسأل عن التوقع؛ والفرق هو أي نوع من التوقع:

السؤال	ما الذي يسأله	ماذا تعني "نعم"	إلى أين تقود "نعم"
Q2	هل الخطوات نفسها ثابتة عبر التشغيلات؟	تسلسل دوال Python نفسه ينتج الجواب الصحيح كل مرة. لا قرارات LLM حول ماذا تفعل تالياً.	سير عمل تسلسلي
Q3	هل المراحل الكبرى قابلة للصياغة مسبقاً، حتى لو تغير العمل داخلها؟	تستطيع وصف بنية المراحل على whiteboard قبل أي إدخال. ما زالت LLM تقرر ما تفعل داخل كل مرحلة.	تخطيط + تنفيذ ReAct

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

ثلاثة أمثلة حدية تميز Q2 عن Q3:

مثال A، استقبال فواتير، Q2 = نعم → سير عمل تسلسلي: استخراج → تحقق → تخزين → إشعار. الخطوات نفسها كل مرة. تستخرج LLM الحقول وتكتب الإشعار، لكنها لا تقرر الخطوة التالية. تسلسل الخطوات ثابت.

مثال B، تقرير بحث سوق، Q2 = لا، Q3 = نعم → تخطيط + ReAct: جمع بيانات → تحليل → تركيب → مسودة → مراجعة. المراحل قابلة للصياغة، لكن داخل كل مرحلة يقرر الوكيل ما يفعل، أي المصادر والمنافسين والتحليلات. المراحل ثابتة؛ والخطوات داخلها تكيفية.

مثال C، تحقيق دعم عملاء، Q2 = لا، Q3 = لا → وكيل واحد + ReAct: يحقق الوكيل في مشكلة العميل. لا توجد بنية مراحل مسبقة: حسب ما يجد، قد يكون العمل lookup واحداً أو خمسة lookups مع فحص سياسة وتصعيد. لا المراحل ولا الخطوات ثابتة.

لاحظ أن المثال B هو الحالة التي لا تمارسها قرارات الجزء 5 إلا جزئياً. إذا وجدت نفسك تريد "هناك مراحل واضحة" و"الخطة انحرف عنها التنفيذ"، فأنت على حد Q2/Q3، وغالباً الجواب تخطيط + ReAct، لا سير عمل تسلسلي.

حالة known-but-variable الفرعية في Q2 تستحق التسمية. أحياناً Q1 = نعم، المسار معروف، لكن Q2 = لا، متغير عبر المدخلات، مثل workflow له 3 أو 4 متغيرات مستقرة حسب نوع الإدخال. هذه ليست حالة سير عمل تسلسلي ولا تخطيط + ReAct؛ إنها workflow متفرع بتوجيه صريح لنوع الإدخال. يغطيها المفهوم 5.

الخلاصة: يسأل Q3 هل بنية المهمة عالية المستوى، مراحلها واعتمادياتها، قابلة للصياغة قبل التنفيذ. البنية القابلة للصياغة تقود إلى تخطيط + تنفيذ ReAct؛ الخطة تعطي الشكل وReAct يتعامل مع المحتوى المجهول داخل كل مرحلة. أما البنية غير القابلة للصياغة فتقود إلى ReAct خالص مع أدوات. الفخان هما اختراع بنية غير موجودة، وخطط ينحرف عنها التنفيذ، وفقدان بنية موجودة فعلاً، أي ReAct خالص على عمل مرحلي يؤدي إلى الشرود.

المفهوم 7: Q4: هل الجودة أهم من السرعة، مع معايير قابلة للفحص؟

Q4 هو أول سؤال من سؤالين عن طبقات إضافية. اختير النمط الأساسي، سير عمل تسلسلي أو ReAct أو تخطيط + ReAct، عبر Q1 إلى Q3. يسأل Q4 هل تضيف الانعكاس فوقه.

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

شرطان يجب أن يصحا معاً ليكون الانعكاس ذا قيمة.

1. الجودة أهم من السرعة. يضيف الانعكاس استدعاء LLM واحداً على الأقل، النقد، وغالباً اثنين، النقد + التحسين. في الحالات التفاعلية التي يهم فيها الكمون، مثل دعم العملاء اللحظي أو وكلاء المحادثة، تكون هذه التكلفة غالباً مانعة. في حالات الدُفعات حيث تُراجع المخرجات بشرياً أو تُرسل إلى أنظمة لاحقة، مثل التقارير والكود والوثائق، يكون الكمون غالباً مقبولاً. الاختبار: هل يقبل المستخدمون استجابة أبطأ 2 إلى 5 مرات مقابل تحسن جودة حقيقي؟
2. معايير التقييم صريحة وقابلة للفحص. المعايير الغامضة تنتج نقداً غامضاً. "تأكد أن هذا جيد" ليس معياراً. "تحقق أن SQL يمر parsing، ولا يلمس إلا الجداول المذكورة، ولا يستخدم SELECT *" معيار. من دون معايير صريحة، يصبح النقد كلاماً مطولاً لا يحسن المخرج وغالباً يعطي ثقة زائفة أن "AI فحصه" بينما لم يُفحص شيء.

الشرطان مهمان بالقدر نفسه. إضافة الانعكاس لمهمة حساسة للكمون تهدر الوقت. وإضافته لمهمة ذات معايير غامضة ينتج مسرحاً. كلا الفشلين شائع؛ وكلاهما يأتي من تجاوز Q4 وإضافة الانعكاس لأنه يبدو صارماً.

الاختبار. اسأل سؤالين:

• لو استغرق هذا الرد 3 إلى 5 مرات أطول، هل سيقبل المستخدمون أو المستهلكون اللاحقون ذلك مقابل تحسن جودة حقيقي؟ إذا لا، فلا يبرر الانعكاس ميزانية الكمون.
• هل أستطيع كتابة 5 إلى 10 نقاط محددة لما يعنيه "مخرج جيد" لهذه المهمة، بحيث يستطيع LLM آخر قراءة تلك النقاط وفحص المخرج مقابلها؟ إذا لا، فلا تبرر المعايير الانعكاس.

إذا كانت الإجابتان نعم، يضيف الانعكاس قيمة. إذا كانت أي منهما لا، فتجاوزه.

أين تخطئ الفرق.

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

استخدام النموذج وصياغة prompt نفسها للمولد والناقد. لدى الناقد بيانات التدريب والتحيزات والعمى نفسها. يميل إلى التصديق. تستخدم أنماط الانعكاس الفعالة إما نموذجاً مختلفاً للناقد، أو تأطيراً مختلفاً جذرياً، أو أدوات فحص صريحة مثل تشغيل SQL أو parsing JSON أو التحقق من schema.

الانعكاس على مهام بلا مخرج قابل للفحص. يعمل الانعكاس عندما يُعرّف الخطأ: SQL، أو كود لا يترجم، أو ملخص يفوته مصدر مهم. ويعمل ضعيفاً عندما تكون "الجودة" ذاتية: نص تسويقي، كتابة إبداعية، ردود محادثة. تستفيد المجالات الذاتية من human-in-the-loop أكثر من انعكاس LLM.

المسار. إذا صح الشرطان، أضف الانعكاس كطبقة فوق النمط الأساسي من Q1 إلى Q3. لا يستبدل النمط الأساسي؛ بل يلفه. سير عمل تسلسلي مع انعكاس يشغّل workflow ثم ينقد المخرج النهائي. وكيل ReAct مع انعكاس يكمل حلقته ثم ينقد المخرج النهائي. الانعكاس ضبط جودة بعدي، لا بديل للنمط الأساسي.

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

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

المفهوم 8: Q5: هل توجد عنق زجاجة في التخصص أو السياق أو الحجم؟

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

ما الذي تراهن عليه الأنظمة متعددة الوكلاء. ثلاثة ادعاءات مختلفة كثيراً ما تختلط:

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

يجب اختبار كل ادعاء وحده، ضد المهمة الفعلية.

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

ادعاء السياق غالباً أصدق عند الحجم. وكيل واحد يجري عشرة retrievals عبر عشر قواعد معرفة يراكم سياقاً يضعف الاستدلال. غالباً يتفوق تقسيم ذلك إلى عشرة وكلاء retrieve-and-summary ينتج كل واحد brief مركزاً، ثم تركيب briefs، لأن سياق كل وكيل يبقى صغيراً ومركزاً. لكن هذا قرار معماري حقيقي، لا افتراض افتراضي.

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

الاختبار. ثلاثة أسئلة فرعية:

1. هل أستطيع تسمية الخبرة المحددة التي تبرر المختص؟ "سيكون أنظف" لا يكفي. "المراجع يحتاج تطبيق OWASP standards التي لا ينبغي للمبرمج أن يحملها" يكفي. إذا لم تسمِّ الخبرة، فادعاء التخصص غالباً جمالي.
2. هل يتجاوز سياق المهمة ما يستطيع وكيل واحد استخدامه بفعالية؟ غالباً نعم إذا احتاجت المهمة قواعد معرفة كثيرة متميزة، أو تحقيقات طويلة عبر مصادر كثيرة، أو مجموعات أدوات متخصصة لكل مرحلة. وغالباً لا إذا كان السياق يلائم prompt مُداراً جيداً.
3. هل يتوازى العمل فعلاً مع تحسن throughput قابل للقياس؟ إذا كان العمل تسلسلياً، لا يساعد التوازي. وإذا كان مستقلاً فعلاً، بحث 10 منافسين، تقييم 10 مرشحين، تلخيص 10 وثائق، فالتوازي يضيف قيمة حقيقية.

إذا حصل سؤال واحد على نعم قوية، فمتعدد الوكلاء مبرر. إذا كانت الثلاثة "ربما" أو "سيكون جميلاً أن نفصل الوكلاء لأسباب تنظيمية"، ابقَ مع النمط أحادي الوكيل. عبء التنسيق حقيقي وكبير.

أين تخطئ الفرق.

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

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

بناء متعدد الوكلاء لإظهار الرقي. هذا فشل العروض والديموهات. تبدو الأنظمة متعددة الوكلاء مبهرة في المخططات؛ تظهر "AI حقيقياً". إذا لم تبررها المهمة الفعلية، فقد بنيت عبئاً مبهراً.

المسار. إذا خلقت التخصص أو السياق أو الحجم عنق زجاجة حقيقياً → نظام متعدد الوكلاء المتخصصين. قد يملك النظام وكيل منسق/موجه مع مختصين، أو مختصين بعقود handoff صريحة، أو مختصين يتواصلون عبر حالة مشتركة. ما زال النمط الأساسي، سير عمل تسلسلي أو ReAct أو تخطيط + ReAct، ينطبق داخل مجال كل مختص؛ ومتعدد الوكلاء تركيب أنماط لا بديل عنها.

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

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

ادعاء عنق الزجاجة	محفز كمي يبرر الترقية	ما يقيسه
التخصص	تظهر تتبعات الوكيل الواحد أخطاء توجيه أدوات مركزة في مجالات معرفة محددة، كعتبة عملية تقريبية على مستوى ثلث التشغيلات في الفئة المتأثرة، معايرة على خطك الأساسي.	صحة استخدام الأدوات لكل تتبع، مقسمة حسب فئة السؤال: مقيم Phoenix من حزمة التقييمات
التخصص، fallback نوعي	لا يمكن القياس؟ اشترط مواصفة مكتوبة لأدوار المختصين قبل الترقية: مسؤوليات كل دور وأدواته ومعايير قبوله بإنجليزية مبسطة. إذا كانت المواصفة غامضة أو تتداخل الأدوار فوق 40%، فالادعاء جمالي لا معماري.	مراجعة مستند لا metric
فائض السياق	تتدهور الدقة على holdout set مع نمو السياق. كإشارة تقريبية، انخفاض نحو 10 نقاط عبر sweep من 15K إلى 45K token يستحق التحقيق.	منحنى السياق مقابل الدقة على golden dataset
الحجم، قابل للتوازي	لدى العمل أكثر من 5 مهام فرعية مستقلة في كل تشغيل وتتجاوز latency الوكيل الواحد ميزانية المستخدم بأكثر من 2×.	latency من البداية إلى النهاية + تحليل استقلال المهام الفرعية
الحجم، throughput	يتجاوز حجم التشغيل 10× سقف rate-limit لتصميم وكيل واحد، ولا تحفظ caps التزامن لكل tenant العدالة.	حمل الإنتاج × حدود API، ظاهر في لوحات التحكم في التدفق للغلاف التشغيلي

تراتبية الدليل. من أقوى إلى أضعف تبرير لمتعدد الوكلاء:

1. بيانات تتبعات إنتاج تظهر عنق الزجاجة، الأفضل أن لديك دليل أن نظام الوكيل الواحد يفشل بهذه الطريقة
2. قياسات holdout set تظهر عنق الزجاجة، تجربة مضبوطة قوية
3. تحليل مجال مع مواصفات أدوار مختصين مكتوبة، مقبول لأنك عرّفت ما تبنيه
4. "يشعر كأنه يحتاج مختصين"، غير كافٍ؛ هنا تعيش المبالغة

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

الخلاصة: يسأل Q5 هل يخلق التخصص أو السياق أو الحجم عنق زجاجة حقيقياً يبرر معمارية متعددة الوكلاء. يجب اختبار الادعاءات الثلاثة منفصلة، وحيث أمكن بمحفزات كمية، مثل أخطاء توجيه أدوات في نحو ثلث التشغيلات، أو انخفاض دقة نحو 10 نقاط مع سياق أكبر، أو latency تتجاوز الميزانية بأكثر من 2×. التخصص هو الأكثر تصديقاً بلا دليل؛ والسياق غالباً حقيقي عند الحجم؛ والحجم أسهل اختباراً. أكبر فشل هو بناء متعدد الوكلاء لأسباب تنظيمية أو جمالية؛ عبء التنسيق حقيقي وكبير. ابدأ أحادي الوكيل؛ ودع القياس يفرض الترقية.

المفهوم 8.5: بدائيات OpenAI Agents SDK، ما يستخدمه كل نمط

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

خمس بدائيات تهم اختيار النمط.

البدائية	ما هي	أي أنماط تستخدمها
Agent	الصنف الأساسي، كيان تقوده LLM مع تعليمات وأدوات ومخطط مخرج منظم اختياري. الوحدة الذرية لكل نمط.	كل الأنماط الخمسة
Runner.run(agent, input)	يشغّل حلقة وكيل حتى ينتج مخرجاً نهائياً. يشغّل الـSDK الحلقة نيابة عنك: لا دورة reason-act-observe يدوية.	وكيل واحد + ReAct، تخطيط + ReAct، متعدد الوكلاء لكل مختص
@function_tool	decorator يحول دالة Python إلى أداة يستدعيها الوكيل. تصير type signatures وdocstrings مخطط الأداة تلقائياً.	ReAct، التخطيط مع ReAct، متعدد الوكلاء لكل مختص، وسير العمل عند احتياج خطوة LLM إلى أدوات
handoff(target_agent)	بدائية SDK للانتقال متعدد الوكلاء: وكيل يسلم التحكم إلى آخر مع حفظ سياق المحادثة. أنظف من منسق يدوي.	متعدد الوكلاء أساساً؛ وتخطيط + ReAct أحياناً من المخطط إلى المنفذ
output_guardrail / input_guardrail	بدائيات SDK لتشغيل تحقق/نقد على مدخل أو مخرج وكيل. نمط SDK الأصلي للانعكاس.	الانعكاس أساساً؛ وأي نمط يحتاج تحقق مدخلات

بدائية أخرى تستحق التسمية: Agent.as_tool(). تحول Agent إلى أداة قابلة للاستدعاء يستطيع Agent آخر استخدامها. هذه آلية SDK للتركيب الهرمي متعدد الوكلاء: يستخدم وكيل منسق وكلاء مختصين كأدوات، فيستدعيهم كأي function tool. الأنظمة متعددة الوكلاء مع Agent.as_tool() أبسط من الأنظمة مع handoff() لأن المنسق يبقى مسؤولاً؛ أما handoff() فللحالات التي تريد فيها فعلاً أن يستلم المختص المحادثة.

خريطة النمط إلى البدائيات بلمحة.

Sequential workflow:
    Agent(output_type=...) at the LLM-steps; plain Python everywhere else
    Runner.run() called once per LLM-step: no agentic loop (the agent has no tools)

Single agent + ReAct + tools:
    Agent(instructions=..., tools=[@function_tool, @function_tool, ...])
    Runner.run(agent, input): the SDK runs the reason-act-observe loop

Planning + ReAct execution:
    planner = Agent(output_type=PlanSchema)
    plan = await Runner.run(planner, task)
    for stage in plan.stages:
        result = await Runner.run(stage.agent, stage.input)

Single agent + reflection:
    Agent(..., output_guardrails=[critic_guardrail])
    OR: Agent(..., tools=[Agent.as_tool(critic_agent)])

Multi-agent specialist system:
    coordinator = Agent(handoffs=[researcher, writer, reviewer])
    OR: coordinator = Agent(tools=[researcher.as_tool(), writer.as_tool(), ...])

تعرض كتل الكود في الجزء 3 هذه الأشكال بتفصيل SDK كامل.

لماذا تهم هذه الخريطة لاختيار النمط. بدائيات SDK ليست مجرد وسائل تنفيذ؛ إنها تشفر قرارات معمارية. اختيار handoff() مقابل as_tool() قرار تركيب نمط بحد ذاته. يعني handoff() "يستلم المختص المحادثة"؛ ويعني as_tool() "يبقى المنسق مسؤولاً ويستخدم المختص كدالة." الأول مناسب عندما يحتاج المختص إلى التفاعل مع المستخدم مباشرة؛ والثاني عندما يركب المنسق مخرجات المختصين. معرفة أيهما تستخدم نتيجة للانضباط نفسه الذي تعلّمه هذه الدورة.

الصلة بالمثال العملي. يستخدم عامل دعم العملاء Maya Agent + @function_tool للبحث والاسترداد والتصعيد + Runner.run() في معالج FastAPI. إنه نمط وكيل واحد + ReAct + أدوات، وهو ما يمشي عليه المفهوم 10 بتفصيل SDK. تنفيذ Maya واحد من الأنماط الخمسة في هذه الدورة؛ والأنماط الأربعة الأخرى تختارها عندما تتغير خصائص المهمة.

خلاصة المفهوم 8.5: بدائيات SDK هي لبنات الأنماط الخمسة. Agent الوحدة الذرية؛ Runner.run() يشغّل الحلقة؛ @function_tool يكشف دوال Python كأدوات؛ handoff() وas_tool() يركبان الوكلاء في أنظمة متعددة؛ وoutput_guardrail يطبق الانعكاس. تجعل خريطة النمط إلى البدائيات اختيارات هذه الدورة ملموسة: اختيار النمط ليس مجرداً؛ إنه اختيار أي بدائيات SDK تركّب وكيف.

المفهوم 8.6: اعتبارات الغلاف التشغيلي لكل نمط (مع Inngest كمثال ملموس)

ملاحظة للقارئ المستقل. هذا المفهوم عن النتائج التشغيلية لاختيار النمط، لا عن تعليم Inngest. تعمم الحجة المعمارية إلى أي منصة تنفيذ متين، مثل Temporal أو Restate أو Dapr Agents أو AWS Step Functions؛ وInngest هو المثال الملموس لأنه ما تعلّمه دورة الغلاف التشغيلي. إذا كانت لديك منصة أخرى، أو لم تختر المنصة بعد، فاقرأ للحجة المعمارية: كلما كان النمط أعقد، زاد اعتماده على غلاف تشغيلي. استبدل بدائيات منصتك ببدائيات Inngest.

ربط المفهوم 8.5 الأنماط ببدائيات المحرك، OpenAI Agents SDK. ويربط المفهوم 8.6 الأنماط ببدائيات الغلاف التشغيلي: آلة وقت التشغيل التي تجعل حلقة الوكيل تصمد بعد الفشل، وتتوسع لمستخدمين متزامنين، وتتكامل مع العالم الذي يطلق الأحداث. يشغّل الـSDK حلقة الوكيل؛ ويجعل الغلاف الحلقة إنتاجية. يستخدم كل نمط بدائيات غلاف مختلفة، وكلما ازداد النمط تعقيداً ازداد اعتماده على الغلاف.

في مسار Agent Factory، الغلاف التشغيلي هو Inngest. البدائيات أدناه تخص Inngest؛ أما الحجة المعمارية فعمومية.

بدائيات الغلاف التشغيلي المهمة لاختيار النمط.

البدائية	ما هي	أي أنماط تستخدمها أكثر
@inngest_client.create_function	decorator يسجل دالة في runtime التنفيذ المتين. وحدة العمل المدار تشغيلياً.	كل الأنماط الخمسة
TriggerEvent, TriggerCron	أسطح التحفيز: أحداث يطلقها العالم وجداول توقظ الدالة. الوكيل لا يعمل عندما تستدعيه؛ بل عندما يطلق العالم المحفز.	كل الأنماط؛ cron أهم للاستجابة للحوادث والدفعات
ctx.step.run(name, fn, ...)	كل استدعاء نقطة تحقق متينة؛ الخطوات المكتملة تعيد output محفوظاً عند retry؛ والفاشلة تعيد المحاولة مستقلة. الميكانيكية تحت موثوقية الإنتاج.	سير العمل التسلسلي مباشرة؛ التخطيط + ReAct لكل مرحلة؛ الانعكاس لخطوات generator/critic
ctx.step.wait_for_event(...)	تعليق متين بلا حوسبة حتى حدث مطابق أو timeout. بدائية HITL.	أي نمط يحتاج موافقة بشرية؛ متعدد الوكلاء بين المختصين؛ الانعكاس عندما يكون الحكم بشرياً
concurrency, throttle, priority	سياسات التحكم في التدفق لكل دالة.	متعدد الوكلاء بشدة؛ وأي نمط عالي الحجم
Fan-out triggers	حدث واحد يوقظ N دوال أو parent يطلق N أحداث child. بدائية التنفيذ المتوازي للمختصين.	متعدد الوكلاء؛ وتخطيط + ReAct عند توازي المراحل
Replay + dead-letter	تبقى التشغيلات الفاشلة؛ اشحن إصلاحاً واضغط replay، وتستأنف الدالة من الخطوة الفاشلة بالكود الجديد.	كل الأنماط؛ وتزداد قيمته مع تعقيد النمط

خريطة النمط إلى بدائيات الغلاف بلمحة.

Sequential workflow:
    @inngest_client.create_function(trigger=TriggerEvent(...))
    async def workflow(ctx):
        a = await ctx.step.run("extract", extractor_agent.run, ...)
        b = await ctx.step.run("validate", validate, a)
        c = await ctx.step.run("store", db.insert, b)
        await ctx.step.run("notify", notifier_agent.run, ...)
    # Each step independently checkpointed; failure -> memoized resume

Single agent + ReAct + tools:
    @inngest_client.create_function(
        trigger=TriggerEvent(event="customer/email.received"),
        concurrency=[Concurrency(limit=10, key="event.data.customer_id")],
    )
    async def support(ctx):
        result = await ctx.step.run("agent-loop", Runner.run, support_agent, ctx.event.data["query"])
        return result.final_output

Planning + ReAct execution:
    @inngest_client.create_function(trigger=TriggerEvent(event="research/started"))
    async def planning(ctx):
        plan = await ctx.step.run("plan", Runner.run, planner, ctx.event.data["task"])
        results = {}
        for stage in plan.stages:
            results[stage.id] = await ctx.step.run(f"stage-{stage.id}", Runner.run, stage.agent, ...)
        return await ctx.step.run("synthesize", Runner.run, synthesizer, results)

Single agent + reflection:
    @inngest_client.create_function(trigger=TriggerEvent(...))
    async def reflective(ctx):
        output = await ctx.step.run("generate", Runner.run, generator, ctx.event.data["task"])
        critique = await ctx.step.run("critique", Runner.run, critic, output)
        if not critique.final_output.is_safe:
            output = await ctx.step.run("refine", Runner.run, generator, refine_prompt(output, critique))
        return output

Multi-agent specialist system:
    # Coordinator triggers fan-out of specialist events
    @inngest_client.create_function(trigger=TriggerEvent(event="research/landscape.requested"))
    async def coordinator(ctx):
        plan = await ctx.step.run("plan", Runner.run, planner, ctx.event.data["topic"])
        await ctx.step.run("fan-out", fan_out_specialist_events, plan.competitors)

    @inngest_client.create_function(
        trigger=TriggerEvent(event="research/competitor.research"),
        concurrency=[Concurrency(limit=5, key="event.data.tenant_id")],
    )
    async def competitor_research(ctx):
        return await ctx.step.run("research", Runner.run, researcher, ctx.event.data["target"])

تعرض هوامش الجزء 3 كل خريطة منها مع قسم غلاف تشغيلي لكل نمط.

لماذا تهم هذه الخريطة لاختيار النمط. نمطا فشل إنتاجيان لا يظهران على مستوى مخطط المعمارية لكنهما يؤذيان بقوة:

1. Crash mid-flight. تشغيل تخطيط + ReAct من ست خطوات ينهار عند الخطوة 4، بلا تنفيذ متين، يدفع مجدداً ثمن أول ثلاث خطوات. تقدر دورة الغلاف التشغيلي ذلك: بأسعار GPT-5-class، يمكن لتدفق وكيل متعدد المراحل أن يعيد دفع نحو 0.10 إلى 2.00 دولار لكل crash. عند 1000 تشغيل يومياً، هذا نحو 30 إلى 600 دولار شهرياً في عمل ضائع بسبب الأعطال وحدها. تصمد workflows التسلسلية رخيصة لأن retry قصير؛ وتصمد أنظمة متعدد الوكلاء + انعكاس غالية لأن retry طويل.
2. التنسيق عند الحجم. نظام متعدد الوكلاء بخمسة مختصين وعشرة tenants ودفعات 100 حدث/دقيقة سيستنزف rate limits بلا caps تزامن لكل مختص. يجعل الغلاف التشغيلي هذا سطراً واحداً: concurrency=[Concurrency(limit=5, key="event.data.tenant_id")]. تختار شجرة القرار النمط؛ وتحافظ بدائيات التحكم في التدفق على صحة النمط عند الحجم.

تركيب النشر. الغلاف التشغيلي، Inngest، والنشر السحابي يتركبان؛ ولا يتنافسان. تعلّم دورة النشر السحابي الطوبولوجيا: ACA + Neon + R2 + Cloudflare Sandbox + Phoenix. وتعلّم دورة الغلاف التشغيلي الطبقة التي تلف runner الـSDK داخل تلك الطوبولوجيا. يستخدم النظام الإنتاجي الحقيقي الاثنين: دوال Inngest منشورة على ACA، تستدعي Runner.run() داخل كتل step.run()، مع Neon لتتبعات الوكيل والصندوق الرملي لتنفيذ كود الأدوات. تسمي هوامش تركيب النشر في الجزء 3 الطبقتين صراحة.

تركيب التقييمات. يتدفق تتبع Inngest المنظم، مدخل ومخرج كل خطوة وعدد retry والكمون، إلى Phoenix مثل تتبع وكيل SDK عبر OpenTelemetry. أنماط كشف الفشل في حزمة التقييمات، مثل شذوذ طول التتبع، وانحراف plan-execution، والتصديق المطاطي، كلها تعمل على تشغيلات instrumented بـInngest؛ لا تتغير حزمة التقييمات لأن الغلاف التشغيلي أضيف.

خلاصة المفهوم 8.6: الغلاف التشغيلي، Inngest، هو substrate الإنتاج للأنماط الخمسة. المحفزات توقظ الدالة؛ وstep.run يجعلها متينة؛ وstep.wait_for_event يطبق بوابات HITL؛ وconcurrency/throttle/priority تشكل الحمل؛ وfan-out ينسق المختصين؛ وreplay يتعامل مع recovery بعد إصلاح علة. كلما كان النمط أعقد، زادت قيمة الغلاف: تستطيع workflows التسلسلية الصمود بدونه؛ وتحتاج أنظمة متعدد الوكلاء + انعكاس إليه. يتركب الغلاف مع النشر السحابي وحزمة التقييمات كطبقات متوازية في معمارية الإنتاج.

الطبقات الثلاث جنباً إلى جنب. يثبت المفهومان 8.5 و8.6 معاً أن أي نمط وكيل إنتاجي تركيب من ثلاث طبقات: الغلاف التشغيلي، Inngest، والمحرك، OpenAI Agents SDK، والنشر السحابي. يطلق العالم المحفزات في الأعلى، مثل رسائل العملاء، وwebhooks من billing أو Slack أو CRM، وجدول cron، وأحداث fan-out من Workers أخرى، وموافقات بشرية؛ وتتدفق هذه عبر الطبقات الثلاث. يربط الرسم أدناه بدائيات كل طبقة وما تفعله. ارجع إليه كلما بدت هوامش الغلاف التشغيلي في الجزء 3 مجردة.

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

جرّب مع AI بعد الجزء 2. لديك الأسئلة الخمسة. طبقها على شيء حقيقي قبل قراءة الأنماط بعمق. افتح جلسة Claude Code أو OpenCode والصق:

"I'm learning to choose agentic architectures. Pick one real task from my actual work that I might build an agent for. Ask me to describe it, then walk me through the five questions: Q1 (is the solution path known?), Q2 (is the workflow fixed and stable?), Q3 (is the task structure articulable?), Q4 (does quality outweigh speed, with checkable criteria?), Q5 (is there a specialization, context, or scale bottleneck?). Push back when my answer is vague or when I'm reaching for a more elaborate pattern than the task needs. At the end, tell me which starting pattern the answers point to."

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

---

الجزء 3: الأنماط الخمسة بعمق

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

تركيب النشر والتقييم هو ما تضيفه هذه الدورة. قلة من الدورات عن الأنماط الوكيلة تعلّم هذه الطبقة، لأنها تحتاج إلى دورتي النشر والتقييم كقاعدة. إذا لم تنجز تلك الدورات، فاقرأ الهوامش كمعاينة؛ وإذا أنجزتها، يجعل التركيب اختيار النمط تشغيلياً.

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

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

انضباط التكلفة المشفر في اختيار النمط: نظام متعدد الوكلاء مع انعكاس فوقه قد يكلف أضعافاً كثيرة من سير عمل تسلسلي لحجم المهمة نفسه، نسبة توضيحية على رتبة عشرات المرات لا benchmark مقاس. يتجاوز سير العمل التسلسلي طبقتي الصندوق الرملي وbridge Worker بالكامل، لذلك يتجنب جزءاً كبيراً من البنية؛ واختيار ReAct أو متعدد الوكلاء بلا مبرر يدفع ثمن قدرة لا تحتاجها المهمة.

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

المفهوم 9: سير العمل التسلسلي، الشكل المميز، النشر، إشارات التقييم

ما هو. pipeline ثابت من الخطوات حيث يغذي مخرج كل خطوة التالية. المسار معروف ومستقر، Q1 = نعم وQ2 = نعم. تُحجز استدعاءات LLM للخطوات التي تحتاج تفسيراً أو توليداً حقاً، مثل الاستخراج أو التلخيص أو التصنيف، لا لتقرير الخطوة التالية.

التنفيذ النموذجي في OpenAI Agents SDK:

from agents import Agent, Runner
from pydantic import BaseModel

class Invoice(BaseModel):
    vendor: str
    amount_cents: int
    due_date: str
    line_items: list[dict]

class NotificationMessage(BaseModel):
    subject: str
    body: str

# Two narrow agents: each does ONE LLM-step in the workflow.
# Notice: no tools, no agentic loop. Just structured-output extraction.
extractor = Agent(
    name="invoice_extractor",
    instructions="Extract structured invoice fields from the email body. Be strict about field types.",
    output_type=Invoice,
)

notifier = Agent(
    name="notification_writer",
    instructions="Write a brief notification message to the requester, referencing the invoice details.",
    output_type=NotificationMessage,
)

async def invoice_intake_workflow(email_content: str) -> ProcessingResult:
    # Step 1: extraction (SDK Agent with structured output)
    extraction = await Runner.run(extractor, email_content)
    invoice: Invoice = extraction.final_output

    # Step 2: validation (plain Python, no LLM)
    validation = validate_against_db(invoice)
    if not validation.ok:
        return ProcessingResult(status="rejected", reason=validation.reason)

    # Step 3: store (plain Python, no LLM)
    record_id = db.insert(invoice)

    # Step 4: notify (SDK Agent with structured output)
    notif = await Runner.run(notifier, f"Invoice {record_id} from {invoice.vendor} stored. Notify {invoice.requester}.")
    email.send(invoice.requester, notif.final_output.subject, notif.final_output.body)

    return ProcessingResult(status="completed", record_id=record_id)

لاحظ شكل الـSDK: وكيلان ضيقان، كل واحد يفعل مهمة LLM واحدة فقط: استخراج وكتابة إشعار. لكل وكيل مخرج منظم عبر output_type=، بلا parsing نص حر. يُستدعى Runner.run() مرتين، مرة لكل خطوة LLM. لا أدوات ولا decorators @function_tool ولا handoffs، لأن workflow لا يحتاج استدلالاً وكيلاً، بل استدعاءات LLM مضمّنة في Python عادي.

Insight SDK المهم: ليس كل استخدام لـAgent "وكيلاً". وكيل مع output_type= وبلا أدوات هو طريقة SDK الاصطلاحية لـ"استدعِ LLM برد typed"، وهذا بالضبط ما تحتاجه خطوات التفسير في سير العمل التسلسلي. أنت تستخدم SDK من دون استخدام حلقة الوكيل.

تركيب النشر. يستخدم سير العمل التسلسلي أصغر مجموعة من الحزمة السحابية:

• بدائيات SDK المستخدمة: Agent مع output_type= للاستخراج/التوليد المنظم، وRunner.run() لكل خطوة LLM. لا @function_tool، لا handoff()، لا as_tool()، لا output_guardrail. حلقة الوكيل غير مستخدمة.
• FastAPI harness على Azure Container Apps: نعم، ما زلت تحتاج خدمة HTTP لاستقبال الطلبات.
• Neon Postgres للحالة المتينة: نعم، لسجلات workflow وidempotency.
• OpenAI API لاستدعاءات LLM: نعم، لكن فقط للخطوات التي تحتاجه.
• Cloudflare R2 للملفات: ربما، فقط إذا كان workflow يتعامل مع آثار ملفات.
• Cloudflare Sandbox للتنفيذ: لا. لا تشغّل workflows التسلسلية كوداً يولده الوكيل؛ تشغّل كوداً حتمياً مع استدعاءات LLM مضمّنة. لا تحتاج طبقة الصندوق الرملي ولا bridge Worker.

هذه أكثر نتيجة لا تُقدّر عن workflows التسلسلية: لا تحتاج معظم تعقيد النشر الذي تعلّمه دورة النشر السحابي. إذا كانت مهمتك تلائم سير عمل تسلسلي، تستطيع الشحن على FastAPI + Postgres + OpenAI وتجاوز الصندوق الرملي بالكامل. توفير التكلفة: بنية أقل بوضوح لأنك تتجاوز sandbox وbridge-worker tiers. لا تدفع ثمن قدرة لا يحتاجها النمط.

إشارات التقييم. ما تراقبه حزمة التقييمات لسير العمل التسلسلي:

نمط الفشل	كيف يلتقطه التقييم
خطوة الاستخراج تسيء قراءة الإدخال	يفشل تحقق schema؛ يلتقط DeepEval عدم تطابق المخرج المنظم
منطق التحقق فيه فجوة	حالة إنتاج تمر؛ يظهر التتبع سجلاً صحيح الشكل لكنه خاطئ يصل إلى التخزين
رسالة الإشعار غير مناسبة أو خاطئة واقعياً	يقيم Phoenix الرسالة المولّدة؛ ثم تُرقى إلى golden dataset
workflow يعالج حالة لم يصمم لها	تتضمن DeepEval edge cases تكشف حدود افتراض workflow

الفكرة الأساسية: تقييمات workflow التسلسلي عن صحة الخطوات لا عن جودة استدلال الوكيل. تختبر كل خطوة تستخدم LLM وحدها، وتختبر نقاط branching. لا تحتاج لاختبار "هل اختار الوكيل المسار الصحيح" لأن المسار ثابت.

أين تخطئ الفرق في الإنتاج. معاملة workflows المضمنة بـLLM كأنها agentic. تضيف الفرق observability مصمماً لحلقات الوكلاء، مثل tool-call tracing وreasoning-step inspection، إلى workflows بلا tool calls ولا reasoning steps. تحتاج فقط تتبع request/response عادي مع structured-output validation لكل خطوة. لوحات Phoenix لاستدلال الوكلاء overkill؛ وتتبع Application Insights العادي كافٍ.

الغلاف التشغيلي. سير العمل التسلسلي هو أوضح تطابق مع نموذج Inngest للتنفيذ المتين. بنية النمط، خطوات ثابتة قد تفشل، واعتماديات حتمية، هي ما بُنيت له دوال Inngest.

• بدائيات Inngest: @inngest_client.create_function، وTriggerEvent أو TriggerCron، وctx.step.run("step-name", fn, args) لكل خطوة. لا step.wait_for_event غالباً، ولا fan-out، ولا flow control معقد.
• تطابق 1:1: كل خطوة في workflow تصبح ctx.step.run. Crash عند الخطوة 3 → تعيد الخطوتان 1 و2 output محفوظاً، وتحاول الخطوة 3 فقط.
• منفعة التكلفة: بلا memoization، crash عند الخطوة 5 يعيد دفع تكلفة 1 إلى 4. ومعها، تعاد الخطوة 5 فقط. تتراكم الوفورات مع طول workflows.

سير عمل تسلسلي + Inngest هو أبسط نشر وكيل جاهز للإنتاج في المنهج. كثير من workflows الحقيقية التي تُظن "أنظمة وكيلة" ينبغي أن تكون دوال Inngest مع نقاط step.run. سؤال Q1 في شجرة القرار يسأل عملياً هل ينبغي أن تستخدم Inngest بلا حلقة وكيل فوقه.

*خلاصة المفهوم 9: سير العمل التسلسلي هو النمط الصحيح عندما يكون المسار معروفاً ومستقراً. يستخدم أصغر subset من الحزمة السحابية، بلا حاجة إلى sandbox، ويحجز LLM لخطوات التفسير، ويُقيّم على مستوى الخطوة لا مستوى استدلال الوكيل. أكثر خطأ إنتاجي شيوعاً هو over-instrumenting workflows بقابلية ملاحظة وكيلة لا تحتاجها.*

المفهوم 10: وكيل واحد + ReAct + أدوات، الشكل المميز، النشر، إشارات التقييم

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

التنفيذ النموذجي في OpenAI Agents SDK:

from agents import Agent, Runner, function_tool

# Tools: plain async Python functions, exposed to the agent via the decorator.
# Type hints and docstrings become the tool's schema automatically.
@function_tool
async def lookup_account(account_id: str) -> dict:
    """Look up an account's current state including balance, plan, and billing status."""
    return await db.accounts.find_by_id(account_id)

@function_tool
async def lookup_transactions(account_id: str, since_days: int = 90) -> list[dict]:
    """Return recent transactions for an account; defaults to last 90 days."""
    return await db.transactions.find(account_id=account_id, since=since_days)

@function_tool
async def issue_refund(transaction_id: str, amount_cents: int, reason: str) -> dict:
    """Issue a refund. Fails if amount exceeds agent's authority ($500). Returns refund_id."""
    return await refund_service.create(transaction_id, amount_cents, reason)

@function_tool
async def escalate_to_human(reason: str, context: dict) -> str:
    """Hand the case to a human reviewer. Returns the escalation ticket id."""
    return await escalation_service.create_ticket(reason, context)

# One Agent with all the tools. The SDK runs the reason-act-observe loop.
support_agent = Agent(
    name="tier1_support",
    instructions=(
        "You are a Tier-1 customer support agent. Investigate the customer's issue "
        "using your tools. Issue refunds only when policy clearly allows and the "
        "amount is under $500. Escalate any ambiguous case. If you cannot determine "
        "the right action within 3 lookups, escalate. State when you are done."
    ),
    tools=[lookup_account, lookup_transactions, issue_refund, escalate_to_human],
)

# The FastAPI handler: exactly the customer-support Worker's shape.
async def handle_support_request(customer_id: str, query: str) -> str:
    result = await Runner.run(
        support_agent,
        input=f"Customer {customer_id} asks: {query}",
        max_turns=25,  # explicit step budget: non-optional in production
    )
    return result.final_output

لاحظ شكل الـSDK: وكيل واحد لديه أدوات متعددة، يُستدعى عبر Runner.run(). يشغّل الـSDK حلقة reason-act-observe داخلياً: لا تكتب حلقة يدوية. max_turns ميزانية الخطوات؛ ويرفع الـSDK MaxTurnsExceeded عند بلوغها.

Insight SDK المهم: حلقة ReAct الاصطلاحية هي استدعاء Runner.run() واحد. التعقيد في تعريفات الأدوات وتعليمات الوكيل؛ أما آلة الحلقة فمسؤولية SDK. هذا هو النمط خلف Maya's Tier-1 Support agent.

تركيب النشر. يستخدم ReAct أحادي الوكيل معظم الحزمة السحابية:

• بدائيات SDK: Agent مع tools= وinstructions=، وdecorator @function_tool، وRunner.run(agent, input, max_turns=N). لا handoff() ولا as_tool()؛ ولا output_guardrail إلا إذا أضفت انعكاساً.
• FastAPI harness على Azure Container Apps: نعم.
• Neon Postgres: نعم، للجلسات، والتشغيلات، والتتبعات. حرج لأن تتبع الاستدلال هو أثر التنقيح الأساسي.
• Cloudflare R2: نعم إذا تعامل الوكيل مع ملفات.
• Cloudflare Sandbox: نعم إذا كانت للوكيل أدوات تنفذ كوداً. أي apply_patch أو shell أو Python عشوائي يذهب إلى الصندوق الرملي. bridge Worker مطلوب.
• Background worker pattern: نعم، لأن حلقات ReAct قد تستغرق 30+ ثانية ولا ينبغي أن تحبس طلب HTTP.

إشارات التقييم. أنماط فشل ReAct على مستوى الاستدلال، لذلك إشارات التقييم كذلك:

نمط الفشل	كيف يلتقطه التقييم
الوكيل يدور أو يعيد العمل المحلول	شذوذ طول التتبع؛ استدعاءات أداة مكررة بوسائط متشابهة؛ Phoenix يعلّمها
الوكيل يستدعي أدوات غير موجودة	تحقق tool-call في SDK؛ يظهر الاستدعاء في التتبع؛ وتلتقطه CI عبر DeepEval
الوكيل يستسلم مبكراً	مقارنة المخرج بالسلوك المتوقع؛ يظهر التتبع خطوات قليلة؛ يلتقط DeepEval
الاستدلال لا يطابق الأفعال	مقيم Phoenix لصحة الأدوات: هل السبب المعلن يطابق الأداة المستدعاة؟
كمون الأدوات يتراكم	يوضح OTel أن runtime الكلي يتجاوز ميزانية الكمون

الفكرة الأساسية: يجب أن تلتقط تقييمات ReAct تتبع الاستدلال لا المدخل/المخرج فقط. التتبع هو البيانات. إذا فحصت الجواب النهائي فقط، ستفوت حالات حصل فيها على الجواب الصحيح بالحظ، وحالات كان ينبغي أن يصيب فيها لكنه أخطأ بقرار واحد. مقيمو Phoenix inline للتتبع طبقة observability حمّالة لـReAct.

أين تخطئ الفرق في الإنتاج. ترك step budgets بلا حد. حلقة ReAct بلا حد خطوات ستصادف في النهاية إدخالاً يجعلها تدور بلا نهاية، فتحرق tokens، وتحجز workers، وتستنزف rate limits. ضع سقف خطوات صريحاً دائماً، 25 افتراضي معقول؛ وبعض المهام تحتاج 50؛ وقليل جداً يحتاج 100. عندما يبلغ السقف، هذه إشارة تحقيق لا ذريعة لإزالته.

الغلاف التشغيلي. يلتف ReAct أحادي الوكيل بسهولة في Inngest، مع قرار بنيوي واحد: هل تجعل حلقة الوكيل كلها step.run واحداً، أم تفككها؟

• بدائيات Inngest: @inngest_client.create_function مع TriggerEvent، وctx.step.run("agent-loop", Runner.run, agent, input)، وconcurrency وthrottle لحماية الأنظمة اللاحقة، واختيارياً ctx.step.wait_for_event داخل أداة تصعيد لتنفيذ HITL.
• الاختيار البنيوي: step.run واحد للحلقة كلها هو النمط القياسي. يشغّل SDK حلقة reason-act-observe داخلياً؛ وبالنسبة إلى Inngest هي خطوة متينة واحدة. Crash وسط الحلقة → تعاد الحلقة كلها. التفكيك لكل tool call يعطي متانة أدق لكنه يتطلب رفع حلقة SDK من Runner.run()، وهو هش. افترض خطوة واحدة لكل agent loop إلا إذا كان لديك سبب محدد.
• HITL عبر wait_for_event: أداة escalate_to_human من الكود تطلق حدثاً، مثل refund/approval.requested، وتعلق الدالة عبر step.wait_for_event حتى يرد الإنسان. يبقى كود الوكيل نظيفاً، فقط يستدعي أداة، ويتولى الغلاف المتانة.
• حدود التزامن: concurrency=[Concurrency(limit=10, key="event.data.customer_id")] يمنع زحمة عميل واحد من حرمان الآخرين.

Maya's Tier-1 Support هو ضمناً هذا التركيب: Agent + Runner.run() للمحرك، وACA + Neon + R2 + sandbox للنشر، وInngest عند وجوده للمحفزات والمتانة والتحكم في التدفق. يجعل قرار 1 في الجزء 5 هذا التركيب صريحاً.

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

المفهوم 11: التخطيط + تنفيذ ReAct، الشكل المميز، النشر، إشارات التقييم

ما هو. نمط بطبقتين: ينتج وكيل تخطيط خطة صريحة، مراحل واعتماديات، قبل بدء التنفيذ؛ ويتعامل ReAct + أدوات مع العمل داخل كل مرحلة. المسار مجهول على مستوى الخطوات، Q1 = لا، لكن البنية قابلة للصياغة على مستوى المراحل، Q3 = نعم.

التنفيذ النموذجي في OpenAI Agents SDK:

from agents import Agent, Runner, function_tool
from pydantic import BaseModel
from typing import Literal

class Stage(BaseModel):
    id: str
    description: str
    agent_role: Literal["researcher", "analyzer", "synthesizer"]
    depends_on: list[str]  # other stage ids
    step_budget: int

class Plan(BaseModel):
    task_summary: str
    stages: list[Stage]
    success_criteria: str

# Planner: an Agent that produces a structured plan, no tools.
planner = Agent(
    name="market_research_planner",
    instructions=(
        "Given a research task, produce a plan with 3-7 stages. Each stage has clear "
        "dependencies and a step budget. Prefer fewer broader stages over many narrow ones."
    ),
    output_type=Plan,
)

# Three execution specialists: each with its own tools and instructions.
researcher = Agent(
    name="researcher",
    instructions="Investigate the assigned topic using your tools. Return a structured brief.",
    tools=[web_search, fetch_url, read_document],
)
analyzer = Agent(
    name="analyzer",
    instructions="Analyze the briefs from researchers. Identify patterns, contradictions, gaps.",
    tools=[compute_metrics, compare_briefs],
)
synthesizer = Agent(
    name="synthesizer",
    instructions="Synthesize the analyzed findings into a coherent report.",
    tools=[draft_report, format_citations],
)

ROLE_TO_AGENT = {"researcher": researcher, "analyzer": analyzer, "synthesizer": synthesizer}

async def planning_then_react(task: str, session_id: str) -> str:
    # Stage 1: Generate the plan via the planner Agent
    plan_result = await Runner.run(planner, task)
    plan: Plan = plan_result.final_output
    await db.runs.persist_plan(session_id, plan)  # cloud deployment: plan persistence

    # Stage 2: Execute each stage via the matching specialist Agent
    stage_results: dict[str, str] = {}
    for stage in topological_order(plan.stages):
        agent = ROLE_TO_AGENT[stage.agent_role]
        stage_input = compose_stage_input(stage, stage_results, task)
        stage_run = await Runner.run(agent, stage_input, max_turns=stage.step_budget)
        stage_results[stage.id] = stage_run.final_output
        await db.runs.persist_stage(session_id, stage.id, stage_run.final_output)

    # Stage 3: Final synthesis via the synthesizer one more time
    final = await Runner.run(
        synthesizer,
        f"Compose the final report. Plan: {plan.model_dump_json()}. Results: {stage_results}",
    )
    return final.final_output

لاحظ شكل الـSDK: المخطط Agent مع output_type=Plan وبلا أدوات. تستخدم كل مرحلة تنفيذ Agent المختص بدورها عبر Runner.run(). الخطة منظمة بـPydantic، فيتحقق SDK منها على مستوى النوع: لا JSON parsing مع الأمل. يحصل plan persistence عبر جدول runs في Neon داخل النشر السحابي.

Insight SDK المهم: وكيل المخرجات المنظمة + وكيل الأدوات هما نصفا التخطيط + تنفيذ ReAct. output_type= هو ما يجعل الخطط آثاراً من الدرجة الأولى؛ والباقي كود orchestration عادي فوق Runner.run().

تركيب النشر. يستخدم التخطيط + ReAct مكونات ReAct نفسها مع انضباط إضافي:

• بدائيات SDK: planner Agent مع output_type=PlanSchema؛ وexecution Agent لكل دور مع tools=[...]؛ واستدعاء Runner.run() مرة للمخطط ومرة لكل مرحلة. Plan persistence يعيش في جدول runs في النشر السحابي، لا في SDK نفسه؛ فالـSDK stateless بين استدعاءات Runner.run().
• كل متطلبات ReAct من المفهوم 10: harness، sandbox، R2، وbackground worker.
• حفظ الخطة في Neon. الخطة نفسها أثر يستحق الحفظ للتدقيق والاستئناف. جدول جديد أو امتداد لـruns يتتبع plan_id ومحتوى الخطة وتقدم كل مرحلة.
• التشغيلات الطويلة أكثر شيوعاً. غالباً تحتوي الخطط على 5 إلى 10 مراحل، وكل مرحلة قد تشغّل 20 إلى 30 خطوة ReAct. تشغيلات 5 إلى 10 دقائق عادية. background worker إلزامي.

إشارات التقييم. يضيف التخطيط + ReAct أنماط فشل جديدة فوق ReAct:

نمط الفشل	كيف يلتقطه التقييم
المخطط ينتج خطة ينحرف عنها التنفيذ	قارن الخطة بالتنفيذ؛ علّم المراحل المتجاوزة أو المعاد ترتيبها أو المعاد تعريفها
الخطة تفوّت مراحل واضحة	قارن بخطط golden dataset لمهام مشابهة؛ يلتقط DeepEval الانحراف البنيوي
handoff بين المراحل يفقد سياقاً	افحص مدخل كل مرحلة؛ إذا لم تستطع مرحلة N الإشارة إلى مخرج حرج من M فقد ضاع السياق
الخطة مفرطة التفصيل	تحليل حجم المرحلة؛ إذا نفذت كل مرحلة في 1 إلى 2 خطوة، فطبقة التخطيط لا تعمل
الخطة غير مفصلة كفاية	إذا شغلت مرحلة واحدة أكثر من 50 خطوة ReAct، فلم تفكك الخطة العمل فعلاً

الفكرة الأساسية: يجب أن تقيس تقييمات التخطيط + ReAct جودة الخطة منفصلة عن جودة التنفيذ. خطة جيدة مع تنفيذ سيئ تختلف عن خطة سيئة مع تنفيذ جيد؛ وخلطهما يعطي تشخيصات زائفة. إشارة plan-execution divergence هي الأهم: تدل أن المخطط ينتج بنية لا تملكها المهمة فعلاً.

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

الغلاف التشغيلي. التخطيط + تنفيذ ReAct هو أوضح ملاءمة لنموذج step.run في Inngest: كل مرحلة تتحول إلى step.run، وتتضاعف منافع المتانة عبر تشغيل متعدد المراحل.

• بدائيات Inngest: دالة parent عبر @inngest_client.create_function؛ وctx.step.run للتخطيط ثم لكل مرحلة؛ وretries= لكل مرحلة عند الحاجة؛ وconcurrency.
• خريطة plan-then-execute: ينتج step.run("plan", ...) الخطة؛ ثم تعبر الدالة plan.stages وتستدعي step.run(f"stage-{stage.id}", ...). إذا انهارت الدالة عند المرحلة 4 من 6، يستعيد Inngest الخطة والمراحل 1 إلى 3 من memoization؛ وتُعاد المرحلة 4 فقط.
• أثر التكلفة: الوفورات هنا من أكبر ما في الأنماط. قد يستغرق تشغيل التخطيط + ReAct 5 إلى 10 دقائق ويتضمن 20 إلى 30 tool calls؛ crash في الدقيقة 8 بلا متانة يعيد كل شيء. يمكن لـmemoization أن يوفر 0.50 إلى 2.00 دولار لكل crash بأسعار GPT-5-class.
• تنفيذ مراحل متوازية: المراحل المستقلة يمكن إطلاقها عبر fan-out، حدث لكل مرحلة، مع الحفاظ على متانة كل مرحلة.

متطلب "plan persistence in Neon" من تركيب النشر في المفهوم 11 يصبح جزئياً غير ضروري إذا كان Inngest موجوداً، لأنه يحفظ الخطة كمخرج خطوة "plan". ما زال Neon يتتبع التشغيل للتدقيق وقابلية الملاحظة عبر OTel، لكن قصة استرداد الخطة يتولاها Inngest لا كود التطبيق.

خلاصة المفهوم 11: التخطيط + تنفيذ ReAct هو النمط الصحيح عندما تكون البنية قابلة للصياغة بينما يحتاج العمل على مستوى الخطوة إلى تكيف. يستخدم حزمة ReAct كاملة مع plan persistence وbackground worker. يفصل انضباط التقييم جودة الخطة عن جودة التنفيذ؛ وplan-execution divergence أهم إشارة، لأنها تدل أن المخطط ينتج بنية لا تملكها المهمة.

المفهوم 12: وكيل واحد + انعكاس، الشكل المميز، النشر، إشارات التقييم

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

التنفيذ النموذجي في OpenAI Agents SDK. يعطيك SDK بدائيتين للانعكاس؛ اختر بحسب هل تريد تحققاً يمنع المخرجات السيئة أم تحسيناً للمخرجات الحدية.

النكهة 1، output_guardrail للانعكاس التحققي:

from agents import Agent, Runner, output_guardrail, GuardrailFunctionOutput, RunContextWrapper
from pydantic import BaseModel

class SQLReview(BaseModel):
    is_safe: bool
    issues: list[str]
    reasoning: str

# A critic Agent: uses a different model from the generator to avoid blind-spot overlap.
sql_critic = Agent(
    name="sql_critic",
    model="claude-opus-4-5",  # different model family from the generator
    instructions=(
        "Review the SQL query. Check that it parses, hits only allowed tables, "
        "does not use SELECT *, and has appropriate WHERE clauses. Flag any issues."
    ),
    output_type=SQLReview,
)

@output_guardrail
async def critic_guardrail(ctx: RunContextWrapper, agent: Agent, output: str) -> GuardrailFunctionOutput:
    review_result = await Runner.run(sql_critic, output)
    review: SQLReview = review_result.final_output
    return GuardrailFunctionOutput(
        output_info={"issues": review.issues, "reasoning": review.reasoning},
        tripwire_triggered=not review.is_safe,
    )

# The generator Agent: uses output_guardrails to invoke the critic.
sql_generator = Agent(
    name="sql_generator",
    model="gpt-5",  # different model family from the critic
    instructions="Generate a SQL query that answers the user's question.",
    tools=[fetch_schema, list_tables],
    output_guardrails=[critic_guardrail],
)

# When tripwire fires, Runner.run raises OutputGuardrailTripwireTriggered.
# Catch it and decide: retry with critique context, escalate, or fail loudly.

النكهة 2، حلقة ناقد ومُحسّن منفصلة للتحسين:

async def with_reflection(task: str, max_refinements: int = 2) -> str:
    output = (await Runner.run(sql_generator, task)).final_output
    for refinement in range(max_refinements):
        critique = (await Runner.run(sql_critic, output)).final_output
        if critique.is_safe and not critique.issues:
            return output
        # Refinement: feed the critique back to the generator
        refine_prompt = f"Original query:\n{output}\n\nCritic flagged: {critique.issues}\n\nRevise the query."
        output = (await Runner.run(sql_generator, refine_prompt)).final_output
    return output  # max refinements reached; output is best-effort

لاحظ شكلي SDK: output_guardrail نمط SDK الأصلي لـ"امنع المخرجات السيئة": تعريفي، مربوط بتعريف الوكيل، ويعمل تلقائياً على كل Runner.run(). حلقة الناقد والمُحسّن المنفصلة هي نمط SDK الاصطلاحي لـ"حسّن المخرجات الحدية": أكثر مرونة لكنك تكتب orchestration. كلا النمطين يستخدمان نماذج مختلفة للناقد والمولد.

Insight SDK المهم: الانعكاس ليس primitive إطار مستقل في SDK، بل تركيب Agent + Agent. decorator output_guardrail مجرد عرف SDK لربط الوكيل الثاني بمسار مخرجات الأول.

تركيب النشر. يتركب الانعكاس فوق النمط الأساسي، لذلك يعتمد النشر على ما تحته:

• بدائيات SDK: output_guardrail لانعكاس block-bad-outputs؛ أو وكيلان، generator + critic، مع Runner.run() لكل واحد لتحسين. مهم: يستخدم الناقد model= مختلفاً عن المولد.
• إذا كان الأساسي سير عمل تسلسلياً، يضيف الانعكاس 1 إلى 2 استدعاءات LLM؛ ولا يتغير النشر بنيوياً.
• إذا كان الأساسي ReAct + أدوات، يضيف الانعكاس 1 إلى 2 استدعاءات بعد اكتمال الحلقة؛ ولا يتغير النشر بنيوياً.
• إذا كان الأساسي تخطيط + ReAct، يدخل الانعكاس غالباً بين المراحل وعلى التركيب النهائي؛ ويضيف latency.

اعتبار نشر جديد: تنوع النماذج. إذا استخدم الناقد نموذجاً مختلفاً عن المولد، يحتاج الـharness إلى دعم مزودي نماذج متعددين. تعلّم دورة النشر السحابي نشر مزود واحد؛ والانعكاس غالباً يكشف أن multi-provider حاجة حقيقية. خطط لإدارة الأسرار والتوجيه.

إشارات التقييم. للانعكاس أنماط فشل مميزة:

نمط الفشل	كيف يلتقطه التقييم
الانعكاس لا يغير المخرج، تصديق مطاطي	قارن مخرجات قبل/بعد؛ إذا كانت شبه متطابقة في أكثر من 80% فالانعكاس لا يعمل
الانعكاس يجعل المخرج أسوأ	قيّم قبل/بعد مقابل golden dataset؛ الأثر السلبي يعني أن الناقد يخطئ
الناقد والمولد يشتركان في العمى	A/B test: المولد نفسه مع ناقدين مختلفين؛ الترابط العالي يعني استقلالاً ضعيفاً
انجراف المعايير مع الزمن	ضع قائمة المعايير في version control؛ علّم التغييرات بلا قرار موثق
حلقات التحسين تتجاوز الميزانية	عداد refinements يتجاوز العتبة؛ حقق لماذا يجد الناقد عيوباً لا يصلحها المولد

الفكرة الأساسية: يجب أن تقيس تقييمات الانعكاس هل هو إيجابي صافٍ، لا مجرد أنه يعمل. مرور انعكاس يعمل ولا يغير شيئاً عبء؛ ومرور يجعل المخرجات أسوأ ضرر. فشل rubber-stamp هو الأصعب اكتشافاً لأن المقاييس السطحية تبدو سليمة: زاد الكمون وبقيت الأخطاء ثابتة، لكنه لا يكسب تكلفته.

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

الغلاف التشغيلي. يتركب الانعكاس جيداً مع نموذج خطوات Inngest: كل مرور، generate وcritique وrefine، يصبح step.run خاصاً به.

• بدائيات Inngest: ثلاث أو أربع ctx.step.run لكل تشغيل: generate، وcritique، و0 إلى 2 refine-N. اختيارياً: ctx.step.wait_for_event عندما يكون الناقد إنساناً.
• مكسب المتانة: إذا اكتملت خطوة generator، وهي الأغلى، وفشل الناقد بسبب rate limit أو network، يُعاد الناقد وحده. يُحفظ مخرج generator ولا يولد من جديد.
• انعكاس HITL. عندما لا تكون المعايير قابلة للفحص بواسطة LLM، فالجواب غالباً انعكاس بشري. يجعل step.wait_for_event ذلك نظيفاً: generate → إرسال للمراجع → انتظار قرار بشري → التصرف على القرار. تعلق الدالة بلا استهلاك حوسبة.
• انضباط cost-per-output: تتبع تكلفة Inngest لكل step.run يجعل قياس مساهمة الانعكاس سهلاً.

خلاصة المفهوم 12: الانعكاس طبقة إضافية صحيحة عندما تكون الجودة أهم من السرعة والمعايير قابلة للفحص. يتركب فوق أي نمط أساسي. يقيس انضباط التقييم هل يضيف الانعكاس قيمة صافية؛ والrubber-stamping أخفى فشل. إذا لم يحسن المخرجات قابلاً للقياس خلال شهر، أزله.

المفهوم 13: نظام متعدد الوكلاء المتخصصين، الشكل المميز، النشر، إشارات التقييم

ما هو. يتعاون وكلاء متعددون بأدوار متميزة على مهمة. يبرره Q5: التخصص أو السياق أو الحجم يخلق عنق زجاجة حقيقياً. يهم تركيب النمط: قد تكون معمارية كل مختص الداخلية سير عمل تسلسلياً أو ReAct أو تخطيط + ReAct. متعدد الوكلاء ليس بديلاً للأنماط الأخرى؛ إنه تركيب لها.

ثلاث طوبولوجيات أصلية في SDK، كل واحدة تستخدم بدائية مختلفة.

الطوبولوجيا 1، منسق مع مختصين كأدوات، نمط Agent.as_tool(). يبقى المنسق مسؤولاً؛ ويُستدعى المختصون كدوال.

from agents import Agent, Runner, function_tool

# Three specialists, each with its own tools and instructions.
researcher = Agent(name="researcher", instructions="...", tools=[web_search, fetch_url])
writer = Agent(name="writer", instructions="...", tools=[draft_document])
reviewer = Agent(name="reviewer", instructions="...", tools=[lint_check, fact_check])

# The coordinator uses specialists as_tool(): calling them like functions.
coordinator = Agent(
    name="coordinator",
    instructions=(
        "Decompose the task into research, writing, and review phases. "
        "Use the specialist tools in order. Compose their outputs into a final report."
    ),
    tools=[
        researcher.as_tool(tool_name="research_topic", tool_description="Investigate a topic and return a brief"),
        writer.as_tool(tool_name="draft_document", tool_description="Draft a document from research notes"),
        reviewer.as_tool(tool_name="review_document", tool_description="Review a draft and return critique"),
    ],
)

async def coordinator_topology(task: str) -> str:
    result = await Runner.run(coordinator, task, max_turns=30)
    return result.final_output

الطوبولوجيا 2، handoff تسلسلي، نمط handoff(). يستلم المختصون المحادثة؛ ويمرر الـSDK السياق.

from agents import Agent, Runner, handoff

# Define specialists; each one declares which agents it can hand off TO.
final_reviewer = Agent(name="reviewer", instructions="Review the draft and produce the final output.")
writer = Agent(
    name="writer",
    instructions="Draft from the research. When the draft is ready, hand off to the reviewer.",
    handoffs=[handoff(final_reviewer)],
)
researcher = Agent(
    name="researcher",
    instructions="Investigate the topic. When research is complete, hand off to the writer.",
    tools=[web_search, fetch_url],
    handoffs=[handoff(writer)],
)

async def handoff_topology(task: str) -> str:
    # Start with the researcher; the SDK threads control through handoffs.
    result = await Runner.run(researcher, task, max_turns=50)
    return result.final_output  # whoever ended up holding the conversation

الطوبولوجيا 3، مختصون متوازيون يركبهم synthesizer. يشغّل SDK كل مختص مستقلاً عبر Runner.run()؛ ويركب synthesizer مخرجاتهم.

import asyncio
from agents import Agent, Runner

# Five domain specialists running in parallel: one per competitor to research.
competitor_specialist = Agent(
    name="competitor_research",
    instructions="Research one competitor in depth: pricing, product, positioning, recent news.",
    tools=[web_search, fetch_url, read_document],
)
synthesizer = Agent(
    name="synthesizer",
    instructions="Compose competitor briefs into a single comparative landscape report.",
)

async def parallel_topology(competitors: list[str]) -> str:
    # Each specialist runs independently: different Runner.run() calls.
    parallel_briefs = await asyncio.gather(*[
        Runner.run(competitor_specialist, f"Research: {c}", max_turns=15)
        for c in competitors
    ])
    briefs_text = "\n\n".join(r.final_output for r in parallel_briefs)
    final = await Runner.run(synthesizer, briefs_text)
    return final.final_output

لاحظ البدائيات الثلاث: Agent.as_tool() يلف وكيلاً كأداة ويبقي المنسق مسؤولاً؛ وhandoff() يسلم المحادثة؛ وasyncio.gather() مع Runner.run() يشغل fan-out مستقلاً. اختيار بينها قرار اختيار نمط بحد ذاته، ناتج عن خصائص المهمة التي كشفها Q5.

تركيب النشر. تستخدم الأنظمة متعددة الوكلاء الحزمة الكاملة مع انضباط إضافي حرج:

• بدائيات SDK: Agent.as_tool() للتركيب الهرمي، وhandoff() للاستلام التسلسلي، وRunner.run() المتوازي مع asyncio.gather() للfan-out. كل مختص Agent مستقل بأدواته وتعليماته.
• كل متطلبات ReAct لكل مختص: harness، والصندوق الرملي عند الحاجة، وR2، وbackground worker.
• تشغيلات/تتبعات لكل مختص في Neon. كل تنفيذ مختص run خاص؛ والنظام متعدد الوكلاء parent run يشير إلى child runs. يحتاج المخطط إلى parent_run_id وagent_role.
• سجلات تدقيق للتوجيه. كل قرار توجيه، أي مختص؟ وبأي handoff format؟، يُسجل. غالباً تظهر أعطال متعدد الوكلاء كقرار توجيه خاطئ أو سياق مفقود في handoff؛ ومن دون سجلات توجيه صريحة يصبح التنقيح شبه مستحيل.
• تتبع تكلفة لكل مختص. يسهل في متعدد الوكلاء فقدان أي مختص يحرق tokens. attribution لكل مختص يمنع runaway costs من الاختباء في الإجماليات.

Bridge Worker والمختصون. إذا شغّل عدة مختصين كوداً، قد تحتاج إلى إعدادات bridge-Worker متعددة، Manifests مختلفة لحاجات أدوات كل مختص، أو bridge واحد يوجه بحسب هوية المختص. يتصاعد التعقيد أسرع مما يتوقع الناس.

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

نمط الفشل	كيف يلتقطه التقييم
مختص ينتج مخرجاً خاطئاً	eval لكل وكيل على دوره، كأنه وكيل مستقل
المنسق يوجه إلى المختص الخطأ	routing-accuracy eval على أمثلة موسومة في golden dataset
handoff يفقد معلومات	handoff-completeness eval: هل يملك المختص B ما يحتاجه من A؟
الدمج يركب المخرجات خطأ	end-to-end eval؛ إذا نجح المختصون وفشل الناتج النهائي فالمشكلة دمج
المختصون يختلفون بلا حل	inconsistency detector: يجب أن يحل aggregator التعارض أو يرفعه
عبء التنسيق يفوق قيمة العمل	cost-per-correct-output: إذا زادت التكلفة أكثر من 3× وتحسن الجودة أقل من 20% فلا يكسب النمط تكلفته

الفكرة الأساسية: تحتاج تقييمات متعدد الوكلاء ثلاث لوحات درجات منفصلة: جودة المختص، ودقة التوجيه، وجودة الدمج. خلطها يعطي score إجمالي بلا معنى. قد تكون جودة كل مختص 95%، ودقة التوجيه 90%، وجودة الدمج 80%، والنظام كله نحو 68%. من دون الفصل لا تعرف أين تصلح.

أين تخطئ الفرق في الإنتاج. معاملة النظام متعدد الوكلاء كوحدة واحدة. عندما يفشل شيء، ينقح الفريق النظام كله بدلاً من حصر الفشل في طبقة. الحل: enforce tracing لكل مختص وlogging لكل handoff من اليوم الأول. من دونه يكون تنقيح متعدد الوكلاء أصعب وأبطأ بكثير من أحادي الوكيل.

الغلاف التشغيلي. متعدد الوكلاء هو النمط الأكثر اعتماداً على Inngest. تكاد كل بدائية تلعب دوراً: fan-out، وconcurrency لكل tenant، وpriority، وHITL بين مختصين، وreplay لتعافي الفشل الجزئي.

• بدائيات Inngest: fan-out trigger pattern؛ وstep.run لكل تشغيل مختص؛ وper-key concurrency مثل concurrency=[Concurrency(limit=5, key="event.data.tenant_id")]; وpriority للتدرج؛ وstep.wait_for_event بين المختصين عند الحاجة؛ وreplay عندما يفشل 3 من 5 مختصين وينجح 2.
• Insight تكلفة التنسيق: absorbs Inngest معظم العبء: routing becomes events + triggers، handoff contracts become event schemas، integration failures become replay candidates، وتتبع التكلفة لكل مختص يصبح metrics لكل دالة.
• توفير كمي: من دون Inngest قد تبني 2,000 إلى 7,000 سطر من كود operational-envelope: routing، retry/dead-letter، HITL queue، rate limiting، replay. مع Inngest يصبح ذلك نحو 50 إلى 200 سطر من trigger declarations وstep.run.
• تبقى لوحات الدرجات الثلاث. تتدفق تتبعات Inngest المنظمة إلى Phoenix عبر OTel، فلا يتغير انضباط التقييم.

يمتص Inngest جزئياً متطلبات النشر مثل per-specialist tracing وrouting audit logs وcost tracking. ما زلت تحتاج تتبعات التطبيق في Phoenix، لكن تصبح سجلات التدقيق والتكلفة دوالاً من تشغيلات الدوال في لوحة Inngest. التركيب: Inngest للبيانات التشغيلية، Phoenix لبيانات التقييم، Neon لتدقيق التطبيق.

خلاصة المفهوم 13: تستخدم الأنظمة متعددة الوكلاء المتخصصين الحزمة السحابية الكاملة مع tracing لكل مختص، وسجلات توجيه، وتكلفة لكل مختص. يحتاج انضباط التقييم ثلاث لوحات درجات منفصلة لأن الإجماليات تخفي الطبقة التي فشلت. عبء التنسيق أكثر تكلفة يُستهان بها؛ ومن دون instrumentation صارم لكل مختص يصبح التنقيح أصعب بكثير من أحادي الوكيل.

جرّب مع AI بعد الجزء 3. رأيت تكلفة نشر كل نمط وكيف يفشل. اجعل ذلك ملموساً لنمط قد تستخدمه فعلاً. افتح Claude Code أو OpenCode والصق:

"Pick the agentic pattern I'm most likely to build next (sequential workflow, single agent with ReAct and tools, planning with ReAct, or a multi-agent specialist system). For that pattern, walk me through two things. First, the deployment topology: which components does it need (HTTP service, durable state, file storage, sandboxed code execution, background workers, trace observability) and which can it skip? Second, the single failure signal I should watch for first in production, and the specific cheap fix to try before changing the architecture. Be concrete about my pattern, not generic."

ما تتعلمه. لا يكون اختيار النمط حقيقياً حتى تستطيع تسمية تكلفة تشغيله وكيف تعرف أنه انكسر. هذا يحول تركيب النشر والتقييم من شيء قرأته إلى شيء تستطيع رسمه على whiteboard.

---

الجزء 4: إشارات الفشل ومراجعة النمط

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

المفهوم 14: إشارات الفشل الخمس (وماذا تعني)

تحدد المقالة خمسة أعراض وقت تشغيل تدل على عدم تطابق النمط والمهمة. لكل واحد شكل مميز؛ بعد أن تراه مرتين تتعرف إليه فوراً.

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

أين تظهر في observability: شذوذ طول التتبع، تشغيل أخذ 40 خطوة بدل 15؛ أنماط duplicate-tool-call؛ ونصوص استدلال فيها "دعني أجرب مرة أخرى".

المعاني المحتملة: prompt لا يعرّف done؛ عقود الأدوات فضفاضة؛ أو كانت المهمة تحتاج تخطيطاً، Q3 كان ينبغي أن يكون نعم.

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

أين تظهر: metric plan-execution divergence، وstages خارج ترتيب الاعتماديات، وstages مدخلة لم تكن في الخطة.

المعاني المحتملة: البنية جزئية لا كاملة، فاستخدم تخطيطاً أخف؛ prompt المخطط لا يطابق المجال؛ أو المهمة لا تملك بنية قابلة للصياغة أصلاً، Q3 كان لا.

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

أين تظهر: مقارنة قبل/بعد reflection؛ معدلات firing للمعايير؛ معدل اتفاق الناقد والمولد.

المعاني المحتملة: المعايير غامضة؛ الناقد والمولد النموذج نفسه؛ أو المهمة لم تكن تحتاج انعكاساً، Q4 كان لا.

الإشارة 4: فشل توجيه متعدد الوكلاء. يرسل المنسق المهمة إلى المختص الخطأ. أو ينتج مختصان مخرجات متعارضة لا يحلها aggregator. أو يفقد handoff معلومات حرجة. غلب عبء التنسيق على العمل.

أين تظهر: routing accuracy، وhandoff-completeness، ومعدل integration failure حيث ينجح المختصون ويفشل الناتج النهائي.

المعاني المحتملة: الأدوار متداخلة؛ عقود handoff ضمنية؛ أو المهمة لم تكن تحتاج متعدد الوكلاء، Q5 كان لا.

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

أين تظهر: تحتاج baseline comparison. ابنِ نسخة أبسط من المهمة، مثل وكيل واحد + ReAct بلا انعكاس ولا متعدد وكلاء، وقس جودتها على golden dataset. إذا كان الأبسط ضمن نحو 10% من المعقد، فلا تكسب المعمارية المعقدة تكلفتها.

المعنى غالباً: تراكمت المبالغة لأن الفريق ركب طبقات بلا اختبار هل كل طبقة مبررة.

خلاصة المفهوم 14: خمس إشارات فشل تدل على عدم تطابق النمط: دوران ReAct، وانحراف plan-execution، وانعكاس لا يحسن، وفشل توجيه متعدد الوكلاء، ونظام معقد بلا تحسن. لكل إشارة شكل observability مميز. التعرف إلى الإشارة أول خطوة؛ والإصلاح ليس دائماً معمارياً، فقد يكون tightening للprompt أو توضيحاً للعقود.

المفهوم 15: إصلاحات مستهدفة لا تتطلب ترك المعمارية

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

الإشارة	أرخص إصلاح أولاً	إذا لم ينجح	تغيير معماري مطلوب
ReAct يدور/يعيد	أضف شروط توقف وحدود أدوات صريحة	حسّن عقود الأدوات	أضف طبقة تخطيط
انحراف plan-execution	استخدم تخطيطاً خفيفاً بمراحل أقل وأعرض	حسّن prompt المخطط بأمثلة مجال	اخفض إلى ReAct خالص
الانعكاس لا يحسن	اجعل المعايير أكثر تحديداً وقابلية للفحص	استخدم نموذجاً مختلفاً للناقد أو أدوات فحص	أزل الانعكاس إذا لم يظهر تحسن
فشل توجيه متعدد الوكلاء	حوّل التوجيه للحالات المعروفة من LLM إلى deterministic	اجعل handoff contracts منظمة وصريحة	ادمج المختصين المتداخلين أو اخفض لأحادي الوكيل
معقد بلا تحسن	أزل أعلى طبقة، أحدث نمط أضيف، وقس	أزل الطبقة التالية وكرر	ارجع إلى baseline أحادي قوي وابنِ فقط بالأدلة

المبدأ: أصلح بأصغر نطاق يعمل. tightening للprompt أرخص من تغيير عقود الأدوات. وتغيير العقود أرخص من المعمارية. والتغييرات المعمارية أرخص من إعادة الكتابة. لا تمسك مقبض المعمارية أولاً.

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

خلاصة المفهوم 15: لا تتطلب إشارات الفشل دائماً تغييرات معمارية. كثير منها يصلح في prompt، مثل شروط التوقف والمعايير وحدود الأدوار، أو في العقد، مثل وصف الأدوات وبنى handoff. التغيير المعماري آخر حل. الاستثناء: الفشل المتكرر بعد تلك الإصلاحات يعني أن النمط نفسه خاطئ؛ امشِ الشجرة مرة أخرى.

المفهوم 16: متى تكون شجرة القرار خاطئة

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

الحالة 1: خصائص المهمة تتغير بعد النشر. ما كان workflow مستقراً يصبح تكيفياً عندما تضيف الشركة 20 edge cases. وما كان تخصصاً يصبح commodity عندما يتحسن LLM ويستطيع generalist حمله. مثال: workflow دعم بدأ extract → classify → route → respond يصبح تكيفياً بعد إضافة personalization وhistory-awareness وtone-matching. النمط الأصلي أصبح خاطئاً والنظام في الإنتاج.

الإصلاح: تلتقط observability إشارات الفشل من المفهوم 14 هذا. عندما تفشل مسارات workflow لأن المدخلات الحقيقية لم تعد تطابق شكله، هذه هي الإشارة. امشِ شجرة القرار من جديد بخصائص المهمة الجديدة.

الحالة 2: مهام فرعية مختلفة تحتاج أنماطاً مختلفة. يتعامل Maya's Tier-1 Support مع التوجيه، والlookups، والاستردادات، والتصعيد. بعضها workflow-shaped، مثل lookup؛ وبعضها ReAct-shaped، مثل تحقيق الاسترداد. يتعامل نمط ReAct أحادي الوكيل معها كلها بشكل كافٍ لا ممتاز. الإصلاح: اعتبرها فرصة تركيب متعددة الأنماط. منسق علوي يوجه إلى subsystems بنمط محدد: workflow للlookups، وReAct للتحقيقات، وتخطيط للنزاعات المعقدة. التركيب متعدد الوكلاء، لكن المختصين ليسوا أدواراً بشرية؛ بل أنماط.

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

الإصلاح: سجل اختيارات النمط المدفوعة بالقيود كقرار منفصل. اكتب: "أشارت الشجرة إلى متعدد الوكلاء، لكن اخترنا أحادي الوكيل لأن سقف التكلفة فرض ذلك. الحد المعروف: ستكثر failures driven by specialization." يجعل ذلك القرار مرئياً وقابلاً للمراجعة عند تغير القيود.

خلاصة المفهوم 16: شجرة القرار نقطة بداية لا جواب دائم. ثلاث حالات تتطلب مراجعتها: تغير خصائص المهمة بعد النشر، أو احتياج sub-tasks مختلفة إلى أنماط مختلفة، أو استبعاد القيود لإجابة الشجرة. اختيار النمط تكراري لا one-shot.

المفهوم 16.5: معرض الأنماط السيئة، اختيارات خاطئة شائعة وما الأفضل

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

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

اختيار سيئ	لماذا يفشل	نمط بداية أفضل
متعدد الوكلاء لتوليد محتوى بسيط، مثل ثلاثة وكلاء لمنشور LinkedIn واحد	عبء التنسيق أكبر بكثير من مكسب التخصص؛ tokens أكثر بلا تحسن جودة قابل للقياس	وكيل واحد + ReAct + أدوات، أو سير عمل تسلسلي إذا كان الشكل ثابتاً
ReAct لمعالجة فاتورة ثابتة	يتجاوز خطوات أو يعيدها أو يخترع أدوات؛ يعالج الفريق الأعراض بشروط توقف	سير عمل تسلسلي
مخطط للتنقيح المفتوح	بنية المهمة غير قابلة للصياغة؛ تنحرف الخطة بحلول المرحلة الثانية	وكيل واحد + ReAct + أدوات
انعكاس على معايير جودة غامضة	النقد rubber-stamp، والكمون يتضاعف والجودة ثابتة	إزالة الانعكاس أو مراجعة بشرية
وكيل واحد ضخم لمجالات كثيرة	context overflow، وrole confusion، وأخطاء tool-routing	نظام متعدد الوكلاء المتخصصين
إضافة التخطيط إلى workflow مستقر	الخطة نفسها كل مرة؛ استدعاء LLM إضافي لا يفيد	سير عمل تسلسلي
وكيل واحد لمهام تحتاج سياقاً ضخماً	يضعف الاستدلال مع نمو السياق	متعدد الوكلاء بسياقات مركزة
تجاوز الانعكاس على مخرجات تحتاج تحققاً	تشحن أخطاء خفية، والاختبارات اللاحقة أقل فعالية	طبقة انعكاس فوق النمط الأساسي

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

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

خلاصة المفهوم 16.5: يفشل اختيار النمط غالباً بالمبالغة، وأقل قليلاً لكن بشكل مؤذٍ بالنقص. يسمي معرض الأنماط السيئة أشكال الفشل الشائعة. استيعابها يسرع انضباط الشجرة؛ والتعرف إلى anti-pattern في معمارية مسودة هو المهارة العملية. انظر قالب مراجعة التصميم في نهاية الدورة؛ يحتوي فحص anti-pattern صريحاً يعمل في مراجعات الفريق.

---

الجزء 5: مختبر القرار

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

يتبع كل قرار الشكل نفسه:

• المهمة
• المشي في الشجرة
• اختيار النمط والتبرير
• رسم طوبولوجيا النشر
• إشارات التقييم
• نداء مسار المحاكاة

القرار 1: وكيل Maya لدعم Tier-1

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

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

امشِها بنفسك أولاً، ثم افتح الجواب العملي.

المشي في الشجرة.

Q1: هل يمكن تحديد مسار الحل مسبقاً؟ لا. تتنوع أسئلة العملاء كثيراً: "أين استردادي؟" يحتاج lookup؛ و"حُسبت علي مرتين" يحتاج تحقيقاً؛ و"أريد الإلغاء" قد يحتاج تغييرات حساب؛ و"اشرح فاتورتي" يحتاج سياسة وشرحاً. المسار مجهول.

Q2: غير منطبق لأن Q1 لا.

Q3: هل البنية قابلة للصياغة قبل التنفيذ؟ لا. لا توجد مراحل قابلة للصياغة؛ هناك تحقيق ينتهي عندما ينتهي. قد يفعل الوكيل lookup واحداً ويرد، أو خمسة lookups وثلاث فحوص سياسة. لا بنية مراحل واضحة.

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

Q5: هل توجد عنق زجاجة تخصص أو سياق أو حجم؟ حدية. يتعامل الوكيل مع billing وtechnical وaccount وrefund، ما يبدو حالة تخصص. لكن تداخل الأسئلة كبير، والتوجيه المتخصص سيخلق handoff friction أكثر من مكسب التخصص. الوكيل الواحد هو القرار الصحيح.

اختيار النمط: وكيل واحد + ReAct + أدوات. نمط المفهوم 10.

رسم طوبولوجيا النشر. هذا بالضبط ما بنته سحابة عامل دعم العملاء. الحزمة الكاملة: FastAPI على ACA، وNeon للجلسات والتشغيلات والتتبعات، وR2 للوثائق المرفقة، وCloudflare Sandbox عبر bridge Worker لأداة apply_patch أحياناً لتوليد وثائق الاسترداد، وbackground worker للتشغيلات التي تتجاوز 30 ثانية.

إشارات التقييم. فشل ReAct المميز:

• شذوذ طول التتبع في Phoenix
• تكرار استدعاءات الأدوات
• تباعد reasoning-action عبر مقيم Phoenix
• إنهاء مبكر
• استنزاف step budget

أرجح فشل في الإنتاج: سيدور الوكيل على حالات استرداد غامضة. الإصلاح: أضف شروط توقف صريحة: "إذا لم تستطع تحديد مبلغ الاسترداد الصحيح خلال 3 lookups، صعّد"، ووضح الحد بين التحقيق والتصعيد.

الغلاف التشغيلي. إعداد Maya هو تركيب Inngest الاصطلاحي لوكيل دعم:

• Trigger: TriggerEvent(event="customer/email.received").
• Durability: غلّف Runner.run(support_agent, ...) في step.run("agent-loop", ...).
• HITL عند التصعيد: تطلق أداة escalate_to_human حدث refund/approval.requested وتعلق الدالة عبر step.wait_for_event حتى 4 ساعات.
• Concurrency: caps لكل customer وللنظام ككل لحماية rate limits وNeon.

نداء مسار المحاكاة. حتى بلا دورات النشر والتقييم، تستطيع فعل هذا على الورق: امشِ الأسئلة الخمسة، وبرر النمط، وارسم الأدوات. انضباط التصنيف هو ما يعلّمه القرار 1؛ وتفاصيل النشر تعمّقه فقط.

القرار 2: وكيل الاستجابة للحوادث

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

دورك. امشِ الأسئلة الخمسة قبل قراءة الجواب.

امشِها بنفسك أولاً، ثم افتح الجواب العملي.

المشي في الشجرة.

Q1: جزئياً. توجد بنية قياسية: فحص الصحة، ربط النشرات، تحديد السبب، محاولة remediation، تصعيد إذا لزم. لكن المسار المحدد يعتمد على ما يحدث. spike في service A قد يقود إلى rollback؛ و500 في service B إلى restart pod؛ وتقرير عميل إلى data-flow خاص. المسار مجهول على مستوى الخطوات لكنه منظم على مستوى المراحل.

Q3: نعم. المراحل واضحة: triage → diagnose → remediate → report. بنية قابلة للصياغة.

Q4: السرعة حاسمة، لكن الجودة مهمة لأن remediation خاطئ يزيد الضرر. الانعكاس على قرارات remediation مبرر. مرور نقد سريع يسأل هل هذا الإجراء آمن وهل يطابق الأعراض.

Q5: لا. وكيل واحد لديه monitoring وdeploy history وrunbooks وأدوات remediation يكفي. لا تضف متعدد الوكلاء.

اختيار النمط: تخطيط + تنفيذ ReAct، مع انعكاس على خطوات remediation.

رسم طوبولوجيا النشر. ReAct + plan persistence:

• جدول Neon جديد: incidents، فيه incident_id وseverity وplan وcurrent_stage وremediation_history
• تُحفظ الخطة وتُحدّث مع اكتمال المراحل
• انعكاس remediation كوكيل منفصل، ويفضل نموذج مختلف
• background worker إلزامي لأن تشغيلات الحوادث قد تستغرق 5 إلى 15 دقيقة

إشارات التقييم.

• plan-execution divergence
• فعالية الانعكاس على remediation
• time-to-resolution
• دقة التصعيد

أرجح فشل: ينتج المخطط خططاً مفرطة التفصيل لحوادث بسيطة. الإصلاح: دربه بأمثلة granularities مناسبة؛ قيمة الخطة أن تكون بالحجم الصحيح لا شاملة.

الغلاف التشغيلي. يستخدم incident response معظم بدائيات Inngest: cron، events، fan-out، durability، HITL، replay.

نداء المحاكاة. هذا أول قرار يركب أنماطاً: التخطيط + الانعكاس. لاحظ أن الانعكاس لا يأتي من Q4 عامة، بل من Q4 على خطوة remediation تحديداً. الانعكاس غالباً ليس كل شيء أو لا شيء؛ بل يطبق على المخرجات عالية المخاطر.

القرار 3: وكيل بحث سوق

المهمة. مع موضوع مثل "المشهد التنافسي في agentic AI middleware" وbrief بحث، ينتج الوكيل تقريراً بحثياً. يتضمن العمل: تحديد المصادر، والبحث في قواعد متعددة، وقراءة الوثائق، ومقارنة claims، وصياغة النتائج، وإنتاج التقرير النهائي.

امشِها بنفسك أولاً، ثم افتح الجواب العملي.

المشي في الشجرة.

Q1: لا. تعتمد المصادر والمنافسون والتحليلات على ما يُكتشف. مسار مجهول.

Q3: نعم. شكل تقرير البحث واضح: جمع بيانات → تحليل → تركيب → مسودة → مراجعة. بنية قابلة للصياغة.

Q4: نعم بقوة. تقرأ التقارير جهة قرار؛ والأخطاء الواقعية والتحليل الضعيف لها أثر. المعايير قابلة للفحص جزئياً: كل claim موثق، وتحليل المنافسين يغطي اللاعبين، والتركيب يجيب عن brief. انعكاس على التركيب والمسودة النهائية.

Q5: غالباً نعم للسياق. البحث العميق يحمّل مصادر كثيرة؛ وفعل ذلك في نافذة وكيل واحد يضعف الاستدلال. تقسيمه إلى وكلاء research-and-summarize لكل مصدر ثم تركيب briefs هو القرار الصحيح.

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

رسم النشر.

• parent run + child runs لكل مختص في Neon
• routing audit logs
• cost tracking لكل مختص
• bridge Worker لأدوات قراءة الوثائق
• aggregator يقرأ briefs من جدول Neon مشترك

إشارات التقييم.

• لوحات الدرجات الثلاث: جودة research specialist، ودقة التوجيه، وجودة الدمج
• plan-execution divergence
• فعالية reflection على synthesis
• cost-per-correct-output

أرجح فشل: briefs ممتازة منفردة لكن aggregator لا يركبها لأن الصيغ مختلفة. الإصلاح: فرض handoff formats منظمة، Pydantic schemas.

الغلاف التشغيلي. هذا مثال fan-out الأساسي: coordinator يطلق حدث research لكل competitor؛ وتشغل دوال المختصين بالتوازي مع concurrency caps؛ ويعمل aggregation كدالة منفصلة.

نداء المحاكاة. يوضح هذا القرار أن متعدد الوكلاء ليس بديلاً للأنماط الأخرى؛ بل تركيب لها. المخطط يستخدم planning، والمختصون يستخدمون ReAct، وsynthesizer يستخدم reflection.

القرار 4: وكيل onboarding للمؤسسات

المهمة. عند تسجيل عميل enterprise جديد، يشغّل وكيل onboarding: provision tenant، وإنشاء الحسابات وقواعد البيانات والإعدادات، وتعبئة seed data، ودعوة المسؤولين، وجدولة kickoff meetings، وإرسال welcome materials. العمل فيه خطوات حتمية كثيرة وقليل من التواصل الشخصي.

امشِها بنفسك أولاً، ثم افتح الجواب العملي.

المشي في الشجرة.

Q1: نعم. onboarding له تسلسل ثابت: provision → configure → seed → invite → schedule → send-welcome. كل عميل يمر بها بالترتيب. مسار معروف.

Q2: نعم. كل عميل enterprise يتبع workflow نفسه. مستقر.

Q3/Q4/Q5: غير منطبقة أو لا. تنتهي الشجرة عند Q2.

اختيار النمط: سير عمل تسلسلي.

رسم النشر. حزمة دنيا:

• FastAPI على ACA
• Neon لحالة onboarding
• R2 لأي وثائق
• استدعاءات LLM مضمنة للرسائل الشخصية
• لا sandbox. لا bridge Worker. لا background worker لوكيل طويل.

إشارات التقييم: صحة كل خطوة، معدل اكتمال workflow، جودة الرسائل الشخصية، وفشل تطبيق الخطوات على مدخلات خاطئة.

أرجح فشل: عميل edge-case لا يلائم workflow القياسي. الإصلاح: أضف branching صريحاً إذا كانت الحالات قليلة؛ أو اعترف بأن workflow أصبح متغيراً وانظر إلى ReAct إذا تكاثرت.

الغلاف التشغيلي. هذا أنظف مثال workflow تسلسلي في Inngest: كل خطوة step.run، وstep.sleep للمتابعات المتأخرة، وcron لتنظيف الحالات العالقة.

نداء المحاكاة. هذا هو المثال السلبي للأنماط الوكيلة. المهمة لا تحتاج استدلالاً وكيلاً. workflow مع استدعاءات LLM مضمنة أرخص، أكثر موثوقية، وأسهل تنقيحاً. لا تستخدم ReAct عندما يكفي workflow.

القرار 5: وكيل برمجة (المسار المتقدم)

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

امشِها بنفسك أولاً، ثم افتح الجواب العملي.

المشي في الشجرة.

Q1: لا. البرمجة اكتشاف مستمر: ماذا في الكود، كيف بني، وماذا تكشف الاختبارات. مسار مجهول.

Q3: جزئياً. الشكل العام واضح: افهم المتطلب → افهم الكود → صمم → نفّذ → اختبر → أصلح → PR. لكن التغييرات المعقدة قد تعيد التصميم عند اكتشاف قيود. بنية قابلة للصياغة مع تكيف داخلي.

Q4: نعم جداً. الكود الإنتاجي عالي الأثر. المعايير قابلة للفحص: الاختبارات، type checks، linters، وملاحظات code review. الانعكاس مبرر جداً.

Q5: نعم فعلاً للتخصص والسياق. تتضمن البرمجة توليد كود، ومراجعة أمنية، وتوثيقاً. كل واحد يستفيد من وكيل مركز. متعدد الوكلاء مبرر.

اختيار النمط: نظام متعدد الوكلاء المتخصصين، مع تخطيط في الأعلى، وReAct + أدوات داخل المختصين، وانعكاس صريح على مخرجات الكود.

رسم النشر.

• منسق ينتج خطة stages: design → code → review → document
• coder specialist يستخدم ReAct وأدوات read/write/run tests، ويستخدم sandbox بكثافة
• reviewer specialist يشغل checks أمنية وlinters
• documentation specialist قد يكون أبسط أو sequential
• reflection على PR النهائي
• runs لكل مختص في Neon، وسجلات توجيه، وتتبع تكلفة لكل مختص

إشارات التقييم: صحة الكود، فعالية review الأمني، plan-execution divergence، وcost-per-PR.

أرجح فشل: يصبح reviewer bottleneck، إما صارماً جداً أو متساهلاً. الإصلاح: معايير صريحة لأحكام reviewer، وتقييم منفصل يقارن أحكامه بأحكام مراجع بشري.

الغلاف التشغيلي. يستخدم وكيل البرمجة كل بدائيات Inngest: triggers من GitHub/Slack، fan-out للمختصين، step.run لكل تعديل ملف، step.wait_for_event على merge approval، concurrency لكل tenant، priority، replay، وstep.sleep لفترة أمان بعد الدمج.

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

---

الجزء 6: الحدود الصادقة

المفهوم 17: التكلفة والكمون قيود معمارية لا خواطر لاحقة

عاملت الدورة اختيار النمط حتى الآن كأن التكلفة والكمون ثانويان. في الإنتاج، غالباً هما أوليان. يسمي المفهوم 17 ملف التكلفة والكمون لكل نمط صراحة حتى تُمشَى الشجرة مع الميزانية في الحسبان.

ملف التكلفة لكل نمط، رتب تقريبية مع أسعار GPT-5-class:

النمط	تكلفة كل مهمة	محرك التكلفة
سير عمل تسلسلي	1× baseline	عدد استدعاءات LLM، غالباً 1 إلى 3
وكيل واحد + ReAct	3 إلى 10×	عدد iterations في ReAct
تخطيط + تنفيذ ReAct	5 إلى 15×	استدعاء التخطيط + حلقات ReAct لكل مرحلة
وكيل واحد + انعكاس	2 إلى 3× النمط الأساسي	نقد + تحسين
متعدد الوكلاء	5 إلى 20×	تشغيلات المختصين + المنسق + الدمج

الأرقام توضيحية لا دقيقة. المهم النسب: نظام متعدد الوكلاء مع انعكاس قد يكلف 30 إلى 60× أكثر من سير عمل تسلسلي لحجم المهمة نفسه. عندما تبرر الجودة ذلك، جيد. وعندما تبرره الجماليات، فهي كارثة ميزانية تنتظر الحدوث.

ملف الكمون لكل نمط:

النمط	الكمون	المحرك
سير عمل تسلسلي	الأقل، نحو 1 إلى 5 ثوان	خطوات حتمية + استدعاءات LLM متسلسلة
وكيل واحد + ReAct	متوسط، نحو 10 إلى 30 ثانية	استدعاء نموذج لكل حلقة
تخطيط + ReAct	متوسط-عال، نحو 30 إلى 90 ثانية	استدعاء تخطيط + تنفيذ المراحل
وكيل واحد + انعكاس	2 إلى 3× النمط الأساسي	نقد وتحسين
متعدد الوكلاء	متغير	التوازي يساعد؛ والتنسيق يضيف عبئاً

التكامل مع الشجرة. يعالج Q4 الكمون ضمنياً؛ ويعالج Q5 التكلفة ضمنياً. لكن الشجرة لا تقول صراحة: "الجواب نمط أقل تعقيداً لأن لديك ميزانية كمون صارمة." هذا قرار طبقة قيود فوق الشجرة.

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

1. غيّر القيود. زد الميزانية أو تقبل كموناً أعلى.
2. غيّر النطاق. قلل ما يجب أن يفعله النظام حتى يستطيع نمط أبسط تحمله.
3. اقبل ملاءمة أسوأ. استخدم نمطاً أبسط وتقبل أن بعض أنماط الفشل ستحدث.

وثّق ما اخترته ولماذا. عندما تظهر أنماط الفشل التي كان النمط الأعقد سيمنعها، ستحتاج تذكر trade-off.

خلاصة المفهوم 17: التكلفة والكمون قيود معمارية، لا خواطر لاحقة. لكل نمط ملف تكلفة وكمون، وتتكاثر المضاعفات عند تركيب الأنماط. قد يكلف متعدد الوكلاء مع انعكاس 30 إلى 60× سير عمل تسلسلي. قد تتغلب قيود الميزانية على جواب الشجرة؛ وثّق التجاوز واقبل أنماط الفشل الناتجة بوعي.

المفهوم 18: تركيب الأنماط، أنماط متعددة في طبقات مختلفة

عاملت الدورة الأنماط غالباً كأنك تختار واحداً. تركّب الأنظمة الحقيقية أنماطاً في طبقات مختلفة: وكيل تخطيط في الأعلى، وReAct + أدوات داخل كل مرحلة، وانعكاس على المخرج النهائي. أظهرت القرارات 3 و5 ذلك؛ ويسميه المفهوم 18 كحركة معمارية من الدرجة الأولى.

ثلاثة أشكال تركيب تستحق التعرف:

تركيب هرمي. نمط أعلى يلف أنماطاً أدنى. أمثلة: مخطط أعلى + ReAct داخل المراحل؛ منسق متعدد الوكلاء + workflows داخل المختصين؛ ReAct أعلى + workflow تسلسلي كأداة.

تركيب تسلسلي. أنماط تعمل واحداً بعد آخر، يغذي مخرج الأول الثاني. أمثلة: workflow يستخرج بيانات منظمة → وكيل ReAct يحقق؛ أو وكيل ReAct يولد مخرجاً → طبقة انعكاس تنقده وتحسنه.

تركيب شرطي. أنماط مختلفة للحالات المختلفة مع router. أمثلة: طلبات ذات شكل معروف إلى workflow؛ وطلبات ذات شكل مجهول إلى ReAct؛ ومخرجات عالية المخاطر مع انعكاس، ومنخفضة المخاطر بلا انعكاس.

قاعدة التركيب العملية: يجب تبرير اختيار النمط في كل طبقة بالأسئلة الخمسة نفسها، مطبقة على نطاق تلك الطبقة. اختَر النمط الأعلى بمشي الشجرة على المهمة كلها؛ واختر نمط كل مكوّن بمشيها على ما يفعله. لا تركّب لأن التركيب يبدو متقدماً؛ ركّب لأن خصائص مهمة كل طبقة تطلب ذلك.

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

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

---

الجزء 7: الخاتمة

المفهوم 19: اختيار النمط كنسيج رابط في منهج Agent Factory

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

تبدو الأسئلة الخمسة بسيطة: هل المسار معروف؟ هل workflow مستقر؟ هل البنية قابلة للصياغة؟ هل الجودة أهم من السرعة؟ هل توجد عنق زجاجة تخصص؟ لكنها تشفر الفروق المعمارية التي عمل عليها المجال خمس سنوات. كاتالوغات الأنماط موجودة؛ وما كان ناقصاً هو منطق القرار بينها. تسد مقالة Bala Priya C تلك الفجوة؛ وتوسعها هذه الدورة بتركيب النشر والتقييم الذي يحتاجه طلاب Agent Factory.

تركيب النشر هو المساهمة التي تميز هذه الدورة. قلة من الدورات تعلّم معنى كل نمط للحزمة السحابية:

• workflows التسلسلية تتجاوز طبقة sandbox
• ReAct أحادي الوكيل يستخدم الحزمة الكاملة
• التخطيط + ReAct يضيف plan persistence وbackground workers أطول
• الانعكاس غالباً يقدم multi-provider model routing
• متعدد الوكلاء يتطلب tracing لكل مختص، وسجلات توجيه، وcost attribution لكل دور

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

وتركيب التقييم هو المساهمة الثانية. لكل نمط فشل مميز تلتقطه حزمة التقييمات بطرق مختلفة:

• workflows التسلسلية: صحة الخطوات عبر DeepEval
• ReAct: تتبعات الاستدلال عبر Phoenix
• التخطيط + ReAct: plan-execution divergence كmetric مخصصة
• الانعكاس: مقارنة قبل/بعد وكشف rubber-stamp
• متعدد الوكلاء: ثلاث لوحات درجات لجودة المختص والتوجيه والدمج

بلا تقييم واعٍ بالنمط، تصبح حزمة التقييمات عامة وتفوت فشل كل نمط المحدد. تسمي هذه الدورة ما تراقبه، نمطاً بنمط، حتى تصبح حزمة التقييمات واعية بالنمط.

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

ما بعد هذه الدورة. سمت خاتمة دورة النشر السحابي ثلاث حدود مستقبلية: تجارة وكيل إلى وكيل، وتفاصيل نشر Identic AI، وactive-active متعدد المناطق. ما زالت قائمة. وتضيف هذه الدورة واحدة: harnesses اختبار خاصة بكل نمط. حزمة التقييمات عامة؛ وقد تبني دورة لاحقة generators لاختبارات خاصة، مثل "مختبر workflow تسلسلي" يولد مدخلات تغطي فروعه، أو "مختبر توجيه متعدد الوكلاء" يولد مدخلات تختبر منطق المنسق. هذه حدود حقيقية، وتعتمد على taxonomy الأنماط في هذه الدورة.

جرّب مع AI، التمرين النهائي. افتح Claude Code أو OpenCode والصق:

"I've just completed a course on agentic pattern selection. Pick a real task I might want to build an agent for in the next quarter, something at my actual job, not a toy example. Walk the five-question decision tree on it with me, asking me to answer each question and pushing back if my reasoning is weak. Then tell me what pattern you'd recommend, what cloud deployment topology I'd need, and what eval signals I should watch for. Be specific about the task properties, not generic."

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

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

---

بطاقة مختصرة: كل المفاهيم الـ22 والقرارات الـ5، مجمعة حسب الجزء

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

الجزء 1: مشكلة اختيار النمط

#	المفهوم	الخلاصة
1	اختيار النمط تصميم قبل البناء	الأنماط موثقة؛ منطق الاختيار بينها ليس كذلك. الاختيار الخاطئ يتضاعف مكلفاً في الإنتاج.
2	كل نمط رهان على المهمة	workflow يراهن على مسارات معروفة؛ ReAct على المجهولة؛ التخطيط على بنية قابلة للصياغة؛ الانعكاس على معايير قابلة للفحص؛ متعدد الوكلاء على تخصص حقيقي.
3	المبالغة والنقص	المبالغة أشهر؛ والنقص شائع بالقدر نفسه وأخفى.

الجزء 2: شجرة القرار

#	المفهوم	الخلاصة
4	Q1: هل مسار الحل معروف؟	المعروف يقود إلى workflows؛ والمجهول إلى استدلال وكيلي. اختبر بقاعدة دالة Python بلا LLM.
5	Q2: هل workflow ثابت؟	المسار الثابت → workflow تسلسلي؛ المعروف المتغير → workflow متفرع أو نمط وكيلي.
6	Q3: هل البنية قابلة للصياغة؟	قابلة → تخطيط + ReAct؛ غير قابلة → ReAct خالص.
7	Q4: جودة > سرعة ومعايير قابلة للفحص؟	يجب أن يصح الشرطان ليضيف الانعكاس قيمة.
8	Q5: عنق زجاجة تخصص/سياق/حجم؟	اختبر الادعاءات منفصلة وبمحفزات كمية حيث أمكن.

مفاهيم الجسر

#	المفهوم	الخلاصة
8.5	بدائيات SDK	Agent الوحدة الذرية؛ Runner.run() يشغّل الحلقة؛ @function_tool يكشف الأدوات؛ handoff() وas_tool() للتركيب؛ output_guardrail للانعكاس.
8.6	الغلاف التشغيلي	triggers توقظ، وstep.run يجعل متيناً، وstep.wait_for_event يطبق HITL، وfan-out ينسق المختصين. كلما كان النمط أعقد زادت أهمية الغلاف.

الجزء 3: الأنماط الخمسة

#	المفهوم	الخلاصة
9	سير عمل تسلسلي	أصغر subset من الحزمة؛ لا sandbox؛ تقييم على مستوى الخطوة.
10	وكيل واحد + ReAct	الحزمة الكاملة عند وجود تنفيذ كود؛ تقييمات Phoenix على التتبع حمّالة.
11	تخطيط + ReAct	plan persistence وbackground workers؛ أهم إشارة plan-execution divergence.
12	انعكاس	طبقة فوق أي نمط؛ قِس net-positive؛ rubber-stamping أخفى فشل.
13	متعدد الوكلاء	الحزمة الكاملة مع tracing لكل مختص؛ ثلاث لوحات درجات؛ coordination overhead حقيقي.

الجزء 4: إشارات الفشل والمراجعة

#	المفهوم	الخلاصة
14	إشارات الفشل الخمس	دوران ReAct، وانحراف الخطة، وانعكاس بلا تحسن، وفشل توجيه، وتعقيد بلا فائدة.
15	أصلح بأصغر نطاق	prompt ثم عقود ثم معمارية.
16	متى تخطئ الشجرة	تغير المهمة، أو اختلاف الأنماط داخل sub-tasks، أو قيود تستبعد الجواب.
16.5	معرض الأنماط السيئة	خمسة overshoot وثلاثة undershoot؛ استخدمها في design review.

الجزء 5: مختبر القرار

الجزء 6: الحدود الصادقة

#	المفهوم	الخلاصة
17	التكلفة والكمون	متعدد الوكلاء + انعكاس قد يكلف 30 إلى 60× workflow تسلسلي؛ وثّق اختيارات القيود.
18	تركيب الأنماط	هرمي وتسلسلي وشرطي؛ يبرر كل layer بالأسئلة نفسها.

الجزء 7: الخاتمة

#	المفهوم	الخلاصة
19	اختيار النمط كنسيج رابط	الجسر بين تصميم الوكيل ونشره؛ حلقة الوكيل الصحيحة للمهمة هي ما تعمل عليه الشركة المعتمدة أصلاً على AI.

القرارات الخمسة

#	القرار	النمط الأساسي والطبقات
1	Maya's Tier-1 Support	أساسي: وكيل واحد + ReAct + أدوات. بلا طبقات إضافية.
2	Incident response	أساسي: تخطيط + ReAct. + انعكاس على remediation.
3	Market research	أساسي: متعدد الوكلاء، مع تخطيط وReAct داخل المختصين. + انعكاس على synthesis.
4	Enterprise onboarding	أساسي: سير عمل تسلسلي. بلا طبقات. المثال السلبي للأنماط الوكيلة.
5	Coding agent	أساسي: متعدد الوكلاء، مع تخطيط وReAct داخل المختصين. + انعكاس على كود المبرمج. الحالة المتقدمة.

مرجع سريع: الأسئلة الخمسة والأنماط الخمسة

Q1: Can the solution path be defined in advance?
    Yes  -> Q2
    No   -> Q3 (need agentic reasoning)

Q2: Is the workflow fixed and stable across runs?
    Yes  -> SEQUENTIAL WORKFLOW
    No   -> Q3 (or branched workflow if few stable variants)

Q3: Is the task structure articulable before execution?
    Yes  -> PLANNING + REACT EXECUTION
    No   -> SINGLE AGENT + REACT + TOOLS

Q4: Quality > speed AND criteria are checkable?
    Yes  -> Add REFLECTION on top of the chosen pattern
    No   -> Skip reflection

Q5: Specialization, context, or scale bottleneck?
    Yes  -> MULTI-AGENT SPECIALIST SYSTEM
    No   -> Keep single-agent pattern

قالب مراجعة التصميم (صفحة واحدة، قابل للطباعة)

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

═══════════════════════════════════════════════════════════════════════
  COURSE ELEVEN: Agentic Architecture Design Review
═══════════════════════════════════════════════════════════════════════

Task name: _______________________________________________________

Task description (1-3 sentences):
  ________________________________________________________________
  ________________________________________________________________
  ________________________________________________________________

Reviewer(s): __________________________  Date: ____________________

───────────────────────────────────────────────────────────────────────
  CORE PATTERN (Q1-Q3)
───────────────────────────────────────────────────────────────────────

Q1. Can the solution path be defined in advance?
    [ ] YES, known        → go to Q2
    [ ] NO, adaptive      → skip to Q3
  Evidence:
    ______________________________________________________________

Q2. Is the workflow fixed and stable across runs?
    [ ] YES, stable        → CORE = Sequential Workflow → skip to Q4
    [ ] NO, variable        → continue to Q3
  Evidence:
    ______________________________________________________________

Q3. Is the task's high-level structure articulable before execution?
    [ ] YES, articulable   → CORE = Planning + ReAct execution
    [ ] NO, emergent       → CORE = Single Agent + ReAct + tools
  Evidence:
    ______________________________________________________________

  → CORE PATTERN CHOSEN: ________________________________________

───────────────────────────────────────────────────────────────────────
  ADDITIVE LAYERS (Q4-Q5)
───────────────────────────────────────────────────────────────────────

Q4. Quality > speed AND criteria are checkable?
    [ ] YES: both          → ADD Reflection layer
    [ ] NO: vague criteria → DO NOT add reflection
    [ ] NO: latency budget → DO NOT add reflection (consider human review)
  Checkable criteria (if YES):
    ______________________________________________________________
    ______________________________________________________________

Q5. Specialization, context, or scale bottleneck?
    [ ] YES: specialization (name it): _______________________________
    [ ] YES: context overflow (describe): ____________________________
    [ ] YES: parallelizable scale (quantify): ________________________
    [ ] NO: keep single agent

  → If Q5 is YES → upgrade CORE to: Multi-Agent Specialist System
    Specialist roles: ____________________________________________

───────────────────────────────────────────────────────────────────────
  FINAL ARCHITECTURE
───────────────────────────────────────────────────────────────────────

Core pattern:         ________________________________________________
+ Reflection (Y/N):   ________________________________________________
+ Multi-agent (Y/N):  ________________________________________________

───────────────────────────────────────────────────────────────────────
  IMPLEMENTATION & DEPLOYMENT
───────────────────────────────────────────────────────────────────────

SDK primitives used (Concept 8.5):
  [ ] Agent (with output_type if structured)
  [ ] Runner.run(agent, input, max_turns=__)
  [ ] @function_tool decorators on N tools (N = __)
  [ ] handoff() between agents
  [ ] Agent.as_tool() for coordinator composition
  [ ] output_guardrail (if reflection layer)

Operational envelope primitives (Concept 8.6, if applicable):
  [ ] Trigger: ___________________________________________________
  [ ] step.run per: _____________________________________________
  [ ] step.wait_for_event for: __________________________________
  [ ] Concurrency cap: ______ per ______________________________
  [ ] Fan-out for: ______________________________________________
  [ ] Priority/fairness rule: ___________________________________

Cloud deployment subset needed (Concept 9-13 sidebars):
  [ ] FastAPI on ACA (always)
  [ ] Neon Postgres
  [ ] R2 (if files in/out)
  [ ] Sandbox + Bridge Worker (if agent runs code)
  [ ] Phoenix (if agentic: any pattern except pure sequential workflow)

───────────────────────────────────────────────────────────────────────
  RISK ANALYSIS
───────────────────────────────────────────────────────────────────────

Cost class (Concept 17):
  [ ] 1× baseline (Sequential workflow)
  [ ] 3-10× (Single agent + ReAct)
  [ ] 5-15× (Planning + ReAct)
  [ ] +2-3× core (with Reflection)
  [ ] 5-20× (Multi-agent)

Latency budget check:
  Expected latency: ___________________________________________
  User-facing budget: _________________________________________
  [ ] Fits           [ ] Tight           [ ] Will not fit

Most likely failure signal to watch (Concept 14):
  [ ] ReAct loops / revisits solved work
  [ ] Plan-execution divergence
  [ ] Reflection not improving output
  [ ] Multi-agent routing failures
  [ ] System feels complex but not better
  Mitigation if it appears:
    ______________________________________________________________

Eval signals to wire (Concept 9-13 sidebars):
  ______________________________________________________________
  ______________________________________________________________

───────────────────────────────────────────────────────────────────────
  ANTI-PATTERN CHECK (Concept 16.5)
───────────────────────────────────────────────────────────────────────

If a senior engineer reviewed this choice, what would they object to?
  ______________________________________________________________
  ______________________________________________________________

Counter-argument (why our choice is right despite the objection):
  ______________________________________________________________
  ______________________________________________________________

───────────────────────────────────────────────────────────────────────
  SIGN-OFF
───────────────────────────────────────────────────────────────────────

Architecture approved for: [ ] Prototype  [ ] Pilot  [ ] Production
Approved by:    ______________________________________________________
Re-review date: ______________________________________________________

═══════════════════════════════════════════════════════════════════════

صُمم القالب ليُمشَى في 15 إلى 20 دقيقة لكل اقتراح معمارية. ملؤه هو الانضباط؛ والقيمة أن تكون الأسئلة مرئية أثناء محادثة الفريق. اطبع واحدة لكل قرار معماري كبير؛ واحفظ النسخ المملوءة في أرشيف قرارات التصميم.

المراجع

• Bala Priya C, "Choosing the Right Agentic Design Pattern: A Decision-Tree Approach," Machine Learning Mastery, May 15, 2026, machinelearningmastery.com/choosing-the-right-agentic-design-pattern-a-decision-tree-approach. شجرة القرار في قلب هذه الدورة مأخوذة منها.
• Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models" (2022)، ورقة ReAct الأصلية.
• Wang et al., "Voyager: An Open-Ended Embodied Agent with Large Language Models" (2023)، مثال مبكر لتركيب التخطيط والتنفيذ.
• Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning" (2023)، صياغة نمط الانعكاس.
• OpenAI, "The next evolution of the Agents SDK" (April 2026)، تحديث SDK الذي جعل الأنماط قابلة للشحن.
• دورة بناء الوكلاء في Panaversity Agent Factory: حلقات الوكلاء ومحرك الشركة المعتمدة أصلاً على الذكاء الاصطناعي.
• دورة التقييمات: التطوير المدفوع بالتقييمات وانضباط trace-to-eval.
• دورة النشر السحابي في Panaversity Agent Factory: نشر OpenAI Agents SDK harness في السحابة.

---

دورة اختيار الأنماط في مسار Agent Factory: خمسة أسئلة، وخمسة أنماط، وإشارات فشل، وتركيب مع النشر، وحزمة التقييمات، والغلاف التشغيلي (Inngest). المقالة المحورية: Bala Priya C, Machine Learning Mastery, May 15, 2026. تغلق فجوة اختيار النمط بين تصميم الوكيل، أي الحلقات والأدوات، وانضباط الإنتاج في النشر والتقييم، مع تركيب الغلاف التشغيلي طوال الدورة، وقابلة للنقل إلى أي حزمة وكيلة عبر جدول الترجمة.

وسيلة دراسة بالبطاقات