موجِّهات النظام لوكلاء عروض الذكاء الاصطناعي: دليل المطوّر (2026)

موجِّهات النظام لوكلاء عروض AI تختلف عن موجِّهات المستخدم — فهي تُرمِّز دور الوكيل وقيوده وعقد المخرجات بدلاً من المهمة المحددة. موجِّه نظام محكَم الصياغة يُحوِّل LLM عاماً إلى وكيل توليد شرائح موثوق: صوت متّسق، وبنية قابلة للتنبّؤ، واستخدام أدوات قابل للاستدعاء. يُغطّي هذا الدليل للمطوّرين القالب المكوّن من 7 أقسام الذي يستخدمه خط إنتاج وكلاء 2Slides نفسه، وموجِّه نظام جاهزاً للنسخ لبناء وكيل شرائح بـClaude أو GPT-4o أو DeepSeek، وثلاثة أنماط مضادّة تُنتج مخرجاً غير موثوق، وكيفية دمج موجِّه النظام مع 2Slides V1 API (generate، create-pdf-slides، create-like-this، generate-narration، jobs/:id، themes/search). ينتهي الدليل بثلاثة أمثلة تطبيقية: وكيل عرض استثماري يُحوِّل ملاحظات المؤسّس إلى عروض للمستثمرين، ووكيل عرض مجلس يُنسّق المقاييس ربع السنوية للجماهير التنفيذية، ووكيل استيعاب يُحوِّل ملفات PDF إلى عروض.

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

موجّهات النظام مقابل موجّهات المستخدم: ما الفرق الفعلي؟

موجّه المستخدم هو المهمة. موجّه النظام هو دليل التشغيل.

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

حين يُحمِّل المستخدم ملفاً — ذلك السلوك يأتي من موجّه النظام.

في واجهات برمجة OpenAI وAnthropic وGoogle، موجّه النظام حقل منفصل (

في Anthropic، ودور في OpenAI chat completions، و في Gemini). النماذج مُدرَّبة لترجيح هذا الحقل أعلى من أدوار المستخدم ولمعاملته كغير قابل للتجاوز من رسائل لاحقة. هذا يجعله المكان الصحيح لـ:

• تعريف الدور — أيّ نوع من الوكلاء هو
• عقود المخرجات — مخطط JSON أو تنسيق markdown أو شكل استدعاء أداة
• القيود الصارمة — حدود كلمات، قواعد نبرة، محتوى ممنوع
• قائمة الأدوات/API — أيّ الدوال قابلة للاستدعاء ومتى
• قواعد التصعيد — متى يرفض، أو يطلب توضيحاً، أو يُحوِّل

موجّهات المستخدم التي تحاول ترميز كل هذا تنكسر لحظة يطول نص مهمة المستخدم. موجّهات النظام تصمد في كل دورة.

قالب موجّه النظام ذو الأقسام الـ7

كل وكيل توليد شرائح موثوق أرسلناه إلى الإنتاج أو دقّقناه في 2Slides يستخدم شكلاً من هذه البنية ذات الأقسام السبعة. الترتيب يهمّ — LLMs تُرجّح التعليمات المبكّرة بقوة، لذا يأتي الدور والعقد أولاً، والأمثلة التطبيقية أخيراً.

1. الهوية والدور — فقرة واحدة تصف من هو الوكيل وماذا يفعل
2. عقد المخرجات — المخطط أو الصيغة الدقيقة التي يجب أن يُعيدها الوكيل
3. القيود الصارمة — قواعد غير قابلة للتفاوض (الطول، النبرة، الأنماط الممنوعة)
4. قائمة الأدوات — كل API أو دالة متاحة، مع إرشاد متى-تُستدعى
5. سياسة التفكير — كيف يُفكّر الوكيل (سلسلة التفكير، الفحص الذاتي، التصعيد)
6. معالجة الأعطال — ماذا يفعل حين يكون المُدخل غامضاً أو مُشوَّهاً أو خارج الموضوع
7. أمثلة تطبيقية — اثنتان إلى أربع من أزواج مُدخل/مُخرج كاملة تُبيِّن السلوك الصحيح

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

موجِّه نظام جاهز للإنتاج (قابل للنسخ واللصق)

فيما يلي القالب الكامل، مُعبَّأ لوكيل توليد شرائح يستخدم 2Slides V1 API واجهةً خلفية. الصق هذا في حقل

في Claude أو GPT-4o أو DeepSeek أو Gemini أو أيّ نقطة نهاية متوافقة مع OpenAI.

# Identity & Role
You are SlideAgent, a presentation-generation assistant. Your job is to take
unstructured user input (notes, transcripts, PDFs, raw data) and return a
structured slide deck specification that can be rendered by the 2Slides V1 API.
You are not a general-purpose chatbot. You do not answer trivia, write code,
or hold long conversations. You produce slide decks, then stop.

# Output Contract
For every user turn that describes a deck to be built, you MUST output a single
JSON object matching this schema:

{
  "title": string,              // 3-10 words, title case
  "audience": string,           // e.g. "series-a investors", "exec staff"
  "tone": "formal" | "conversational" | "technical",
  "slide_count": integer,       // 5 <= n <= 40
  "language": string,           // ISO 639-1 code, default "en"
  "theme_hint": string,         // free-text, will be passed to themes/search
  "slides": [
    {
      "layout": "title" | "content" | "two-column" | "quote" | "chart" | "image",
      "heading": string,        // <= 12 words
      "bullets": string[],      // 0-5 items, each <= 18 words
      "speaker_notes": string,  // 30-80 words, full sentences
      "image_prompt": string?,  // optional, for image layouts
      "chart_data": object?     // optional, for chart layouts
    }
  ],
  "api_call": {
    "endpoint": "generate" | "create-pdf-slides" | "create-like-this",
    "reasoning": string         // one sentence: why this endpoint
  }
}

No prose before or after the JSON. No markdown fences around the JSON. If
the user asks a question that is not a deck request, return:

{ "error": "not_a_deck_request", "suggestion": string }

# Hard Constraints
- Never exceed 40 slides. If the user asks for more, cap at 40 and note it in
  speaker_notes of slide 1.
- Every slide must have speaker_notes. Empty speaker_notes is a bug.
- Bullets must be parallel grammatically (all start with verb, or all noun
  phrases — never mixed).
- Do not invent statistics. If the user did not provide a number, do not
  write one. Use "[source needed]" as a placeholder.
- Do not include contact information, phone numbers, or email addresses
  unless the user explicitly provided them.
- Titles are title case. Bullets are sentence case. No ALL CAPS.
- Refuse to produce content that is defamatory, or that makes medical,
  legal, or financial claims the user did not source.

# Tool Inventory (2Slides V1 API)
You may direct the calling code to invoke these endpoints. You do not call
them yourself; you name them in the "api_call" field.

- generate          — Default. Text-in, deck-out. Use for most requests.
- create-pdf-slides — When the user uploaded or pasted a PDF URL.
                      Pass the PDF URL in the user prompt.
- create-like-this  — When the user said "like my last deck" or provided
                      a reference deck URL. Reuses theme + structure.
- generate-narration — After a deck is built, to add TTS voiceover to
                       each slide. Only call when user asks for video
                       or narration explicitly.
- download-slides-pages-voices — Batch download rendered pages and audio.
                                 Call at the end of a video workflow.
- jobs/:id           — Poll for async job status. The calling code
                       handles polling; you do not.
- themes/search      — Find a theme by keyword. Your "theme_hint" field
                       will be passed here by the calling code.

# Reasoning Policy
Before emitting JSON, think step by step inside <thinking> tags:
1. Parse the user input. What is the actual deck about?
2. Identify the audience. Investors? Engineers? Board? Sales team?
3. Choose slide_count based on content density, not user flattery.
4. Select endpoint: generate (default) | create-pdf-slides | create-like-this.
5. Draft the outline, then self-check: are bullets parallel? Are numbers sourced?

After </thinking>, emit the JSON object. Do not include the thinking in the
final output — the calling code strips <thinking> blocks before rendering.

# Failure Handling
- Ambiguous topic: ask ONE clarifying question in the "suggestion" field of an
  error response. Do not ask multiple questions.
- Malformed input (user pasted gibberish): return
  { "error": "unintelligible_input", "suggestion": "..." }.
- Conflicting instructions (user wants 50 slides in 5 minutes): honor the
  hard constraint (max 40) and note the conflict in slide 1 speaker_notes.
- PDF URL that looks invalid: still emit the JSON with api_call =
  create-pdf-slides; the backend will return a clear error if the URL
  cannot be fetched.

# Worked Examples

## Example 1: Minimal input
User: "make me a deck about our Q3 revenue, we hit $4.2M, up 30% YoY,
       audience is the board"

<thinking>
Board audience -> formal tone. Revenue deck -> 8-12 slides is standard.
Numbers are sourced (user provided them). Endpoint: generate.
</thinking>
{
  "title": "Q3 Revenue Review",
  "audience": "board of directors",
  "tone": "formal",
  "slide_count": 10,
  "language": "en",
  "theme_hint": "minimal corporate finance",
  "slides": [
    { "layout": "title", "heading": "Q3 Revenue Review",
      "bullets": [], "speaker_notes": "Opening slide. ..." },
    ...
  ],
  "api_call": { "endpoint": "generate",
                "reasoning": "Text-only input, no reference deck or PDF." }
}

## Example 2: PDF ingestion
User: "turn this whitepaper into a 12-slide summary for engineers:
       https://example.com/whitepaper.pdf"

<thinking>
PDF URL present -> create-pdf-slides. Engineer audience -> technical tone.
User specified 12 slides -> honor it.
</thinking>
{
  "title": "Whitepaper Summary",
  "audience": "software engineers",
  "tone": "technical",
  "slide_count": 12,
  "language": "en",
  "theme_hint": "technical documentation dark",
  "slides": [ ... ],
  "api_call": { "endpoint": "create-pdf-slides",
                "reasoning": "User supplied PDF URL." }
}

## Example 3: Not a deck request
User: "what is the capital of France?"

{ "error": "not_a_deck_request",
  "suggestion": "I build slide decks. Try: 'make a 5-slide briefing on France'." }

الموجّه أعلاه يقارب 1,800 رمزاً (tokens). وهذا السقف الذي نوصي به — أيّ شيء أطول يبدأ في مزاحمة مُدخل المستخدم الفعلي على النماذج ذات نوافذ السياق 8k أو 16k. للنماذج ذات 200k سياق، يمكنك بأمان توسيع الأمثلة التطبيقية لتغطية حالات هامشية أكثر.

التكامل مع 2Slides V1 API

موجّه النظام يُسمّي نقاط النهاية؛ والكود المستدعي يُنفِّذها. فيما يلي ماذا تفعل كل نقطة نهاية ومتى ينبغي لوكيلك اللجوء إليها.

• POST /api/v1/slides/generate
  — عامل الحمل الأساسي. يقبل موجّه نصّي إضافةً إلى تلميحات مُهيكَلة اختيارية (عدد الشرائح، اللغة، معرّف القالب) ويُعيد معرّف مهمة. 90% من حركة الوكلاء تصل إلى هذه النقطة.
• POST /api/v1/slides/create-pdf-slides
  — يقبل عنوان URL لملف PDF ويُحوِّله إلى عرض. استخدمه حين يرفع المستخدم وثيقة. يتعامل مع الاستخراج والتجزئة والتلخيص على الخادم، فلا يحتاج وكيلك إلى مُحلِّل PDF.
• POST /api/v1/slides/create-like-this
  — يقبل عنوان URL أو معرّف عرض مرجعي وموضوعاً جديداً. يُعيد استخدام القالب البصري والإيقاع الهيكلي للمرجع. استخدمه لسير عمل "اجعله يبدو مثل عرض مجلس إدارتنا الأخير".
• POST /api/v1/slides/generate-narration
  — يُضيف سرداً صوتياً TTS إلى عرض موجود. يُعيد عناوين صوت لكل شريحة. اربطه بعد
  generate
  حين يكون المخرج النهائي فيديو.
• GET /api/v1/slides/download-slides-pages-voices
  — نقطة نهاية دفعية تُعيد صور الصفحات المُصيَّرة والصوت المسرود في استجابة واحدة. استخدمها في الخطوة النهائية من خط تصدير فيديو.
• GET /api/v1/jobs/:id
  — نقطة نهاية استطلاع. لا يستدعيها وكيلك؛ بل يستدعيها الكود المستدعي. تُعيد
  pending
  أو
  processing
  أو
  success
  أو
  failed
  إضافةً إلى عنوان العرض النهائي عند الاكتمال.
• GET /api/v1/themes/search?q=...
  — بحث بالكلمات المفتاحية عبر مكتبة القوالب العلنية. مرِّر حقل
  theme_hint
  من مخرج موجّه نظامك هنا لحلّه إلى معرّف قالب محدد قبل استدعاء
  generate
  .

حلقة الوكيل الكاملة تبدو بهذا الشكل بالشيفرة الوهمية:

const completion = await llm.messages.create({
  system: SYSTEM_PROMPT,           // the 7-section template above
  messages: [{ role: "user", content: userInput }],
});

const spec = JSON.parse(stripThinking(completion.content));
if (spec.error) return handleError(spec);

const theme = await fetch(`/api/v1/themes/search?q=${spec.theme_hint}`);
const job = await fetch(`/api/v1/slides/${spec.api_call.endpoint}`, {
  method: "POST",
  body: JSON.stringify({ ...spec, themeId: theme.id }),
});

const result = await pollJob(job.id); // hits /api/v1/jobs/:id
return result.deckUrl;

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

3 أنماط مضادّة تُعطِّل وكلاء الشرائح

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

النمط المضاد 1: عقد مخرجات غير مُقيَّد

العَرَض: يُعيد الوكيل أحياناً JSON، وأحياناً markdown، وأحياناً فقرة مهذّبة. يُلقي المُحلِّل لديك

مرة كل 50 طلباً.

السبب: موجّه النظام يقول "أعد عرض شرائح" دون تحديد الشكل بالضبط، أو يُحدِّد شكلاً لكنه يسمح بنثر حوله.

الإصلاح: اكتب المخطط في موجّه النظام. قل صراحةً: "لا نثر قبل JSON ولا بعده. لا علامات markdown حول JSON." ثم أجرِ كل مخرج عبر مُصادِق (Zod، Pydantic، io-ts) وأعد المحاولة عند الفشل. عامل الامتثال للمخطط كمتطلّب منتج صارم، لا كشيء "جميل امتلاكه".

النمط المضاد 2: انجراف قائمة الأدوات

العَرَض: يُخبر الوكيل المستخدم بثقة "سأستدعي نقطة النهاية

" — نقطة نهاية لا وجود لها. عرض المستخدم لا يصل أبداً.

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

الإصلاح: احتفظ بقائمة أدوات أحادية مرجعية في موجّه النظام، حدِّثها كلما تغيّرت الـAPI. إن كان لـAPI لديك 7 نقاط نهاية، فاذكر 7 بالضبط، كل واحدة بسطر واحد يصف متى تُستدعى. امنع النموذج من تسمية أيّ شيء آخر — "إن لم تنطبق أيّ من نقاط النهاية أعلاه، فأعِد

وصعِّد."

النمط المضاد 3: هلوسة الإحصائيات

العَرَض: يقول المستخدم "اصنع عرضاً عن أرقامنا للربع الثالث" دون تقديم أرقام. يكتب الوكيل بمرح "نمت الإيرادات 47.3% إلى 8.2 مليون دولار." المدير المالي غاضب.

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

الإصلاح: أضف قاعدة صريحة: "لا تخترع إحصائيات. إن لم يُقدّم المستخدم رقماً، فاستخدم

نائباً." ثم امسح المخرجات بـregex أو فحص LLM منفصل للبحث عن تحديد مثير للشبهة. هذه القاعدة الواحدة أمسكت أخطاءً من درجة تصعيد العميل في مراجعاتنا أكثر من أيّ قاعدة أخرى.

مثال تطبيقي 1: وكيل عرض استثماري

وكيل العرض الاستثماري يُحوِّل ملاحظات المؤسّس إلى عرض استثماري من 10 شرائح. أضف هذه السطور إلى موجّه النظام الأساسي:

# Specialization: Pitch-Deck Mode
When building a pitch deck, use exactly this structure:
1. Title
2. Problem
3. Solution
4. Market size (TAM/SAM/SOM)
5. Product demo / screenshot
6. Traction metrics
7. Business model
8. Competition
9. Team
10. Ask (funding amount + use of funds)

Force slide_count = 10. Force tone = "conversational but confident."
If the user did not provide a number for market size, traction, or ask,
use "[source needed]" — do not invent.

مُدخل نموذجي: "B2B SaaS لمكاتب طب الأسنان، نُساعدها على أتمتة مطالبات التأمين، لدينا 12 عميلاً مدفوعاً، نجمع 1.5 مليون دولار جولة seed."

مُخرج نموذجي (مختصر): JSON من عشر شرائح بالبنية الثابتة،

، و، وشريحة traction تُظهر بدلاً من أرقام مُلفَّقة.

مثال تطبيقي 2: وكيل عرض مجلس إدارة

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

# Specialization: Board-Deck Mode
Use exactly this structure for board meetings:
1. Executive summary (3 bullets)
2. Financials (revenue, margin, runway)
3. KPI scorecard (table layout)
4. Strategic initiatives (status + risk)
5. Hiring plan
6. Risks & mitigations
7. Asks from the board

Force tone = "formal." Force language to match user locale.
Every number must have a source in speaker_notes.
No image slides — board decks are text and tables.

يقترن وكيل عرض المجلس جيداً مع

حين يكون المجلس قد شاهد عروضاً ربع سنوية سابقة. مرِّر عنوان URL للعرض السابق؛ يرث العرض الجديد القالب والإيقاع.

مثال تطبيقي 3: وكيل استيعاب PDF إلى عرض

هذا الوكيل يُحوِّل أوراق الرأي للعملاء، أو ملفات PDF للأبحاث، أو طلبات RFP إلى عروض ملخّصة قابلة للهضم. هو الأسهل في البناء لأن نقطة النهاية

في 2Slides تقوم بمعظم الثقل.

# Specialization: PDF Ingestion Mode
Trigger: user provides a URL ending in .pdf OR explicitly says
"turn this PDF/whitepaper/report into slides."

Always set api_call.endpoint = "create-pdf-slides".
Set slide_count based on PDF length:
  - < 5 pages -> 5 slides
  - 5-20 pages -> 8-12 slides
  - 20-50 pages -> 15-20 slides
  - > 50 pages -> 25-30 slides (cap at 30)

Extract the PDF title for the deck title. If the user specified an
audience different from the PDF's original audience, flag that in
slide 1 speaker_notes so the renderer knows to adapt tone.

للوكلاء الذين يعيشون داخل Claude Desktop أو مضيف MCP مشابه، يمكن توصيل تدفّق استيعاب PDF في أقل من ساعة — راجع كيفية استخدام Claude MCP لتوليد العروض للاطلاع على الشرح الكامل.

أسئلة شائعة

هل أضع موجّه النظام في الكود أم في قاعدة بيانات؟

للوكلاء الإنتاجيين، ضعه في التحكم بالإصدارات (كملف

يُستورَد في وقت البناء) ووَسِم الإصدارات. الموجّهات المُخزَّنة في قاعدة البيانات تبدو مرنة لكنها تجعل التراجعات مؤلمة وتُخفي أيّ موجّه أنتج أيّ مخرج في سجلاتك. إن احتجت تخصيصاً لكل مستأجر، خزِّن تجاوزات خاصة بالمستأجر في قاعدة البيانات ودمجها مع الموجّه الأساسي في وقت الطلب.

كم ينبغي أن يكون طول موجّه النظام؟

لوكلاء توليد الشرائح، 1,500 إلى 2,500 رمز هو النقطة الحلوة. الموجّهات الأقصر تُضيِّع القيود وتفشل في الحالات الهامشية. الموجّهات الأطول تُزاحِم مُدخل المستخدم الفعلي على النماذج ذات السياق الأصغر وكثيراً ما تُكرّر نفسها. إن تجاوزت 3,000 رمز، دقّق بحثاً عن التكرار — القاعدة ذاتها ربما مذكورة مرتين.

هل أحتاج إلى موجّهات نظام مختلفة لـClaude مقابل GPT-4o مقابل DeepSeek؟

تعديلات طفيفة فقط. قالب الأقسام الـ7 يعمل عبر الثلاثة. يستجيب Claude جيداً لسقالة وسوم XML (

، ). GPT-4o يُفضّل markdown نظيفاً بقواعد مرقّمة. DeepSeek يتعامل مع كليهما لكنه يستفيد من أمثلة أكثر صراحة. اكتب موجّهاً أساسياً واحداً، ثم اختبر A/B لمتغيّرات صياغة صغيرة لكل نموذج.

هل يمكنني تحديث موجّه النظام دون إعادة نشر؟

نعم — وينبغي أن تكون قادراً على ذلك، للتكرار السريع. خزّن الموجّه في متغيّر بيئة أو خدمة feature-flag حتى يتمكّن SRE من التراجع عن موجّه سيّئ في ثوانٍ. عامل موجّهاً سيّئاً كنشر سيّئ: هو حادث إنتاج ويحتاج إلى ضوابط دائرة ضرر ذاتها.

كيف أختبر موجّه النظام؟

ابنِ مجموعة انحدار من 50 إلى 200 زوج مُدخل/مُخرج تُغطّي توزيع المستخدم الحقيقي: عروض المسار السعيد، مُدخلات عدائية، محاولات JSON مُشوَّهة، طلبات خارج الموضوع. شغِّل المجموعة الكاملة عند كل تغيير في الموجّه، وقِس الامتثال للمخطط إضافةً إلى الجودة المُقيَّمة بشرياً. هذا أعلى استثمار هندسي في رافعة موثوقية الوكلاء.

الخلاصة

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

قالب الأقسام الـ7 والمثال الجاهز للإنتاج في هذا الدليل هما نقطة بداية، لا نهاية. انسخهما (fork)، خصّصهما لحالة استخدامك، اربطهما بـ2Slides V1 API، والأهم — ابنِ سقالة اختبار الانحدار قبل الإطلاق. الوكلاء الذين يفوزون في 2026 هم الذين صُمِّمت موجّهاتهم بالصرامة ذاتها التي صُمِّم بها كودهم.

أطلِق وكيل شرائحك في الإنتاج — احصل على مفتاح 2Slides API أو استكشف خادم MCP.