# Alejandro Rioja — AR > Alejandro Rioja — AI agent systems for founders. Plus posts on growth, marketing, sales, ops, and business from inside live P&Ls. Site: https://alejandrorioja.com/ar/ Author: Alejandro Rioja Language: ar --- ## الانطباعات الأولى عن Claude Fable 5: وجهة نظر مشغّل Source: https://alejandrorioja.com/ar/claude-fable-5-first-impressions/ Published: 2026-06-12 Updated: 2026-06-12 Tags: AI Agents TL;DR: يُعد Fable 5 أقدر نموذج لدى Anthropic، ويظهر ذلك في أعمال الوكلاء الصعبة طويلة المدى — لكنه ليس الترقية الافتراضية. فهو أغلى لكل token، ويستخدم tokenizer جديداً يضخّم أعداد الـ tokens لديك بنحو 30%، ويشغّل thinking دائم التشغيل لا يمكنك تعطيله، وقد يرفض الطلبات على مستوى المصنّف. بالنسبة لمعظم أحمال العمل، يظل Opus 4.8 هو الخيار الصحيح. لجأ إلى Fable 5 حين تكون المهمة صعبة حقاً. ## جدول المحتويات _محدَّث في يونيو 2026._ **TL;DR:** يُعد Fable 5 أقدر نموذج لدى Anthropic، ويظهر ذلك في أعمال الوكلاء الصعبة طويلة المدى — لكنه ليس الترقية الافتراضية. فهو أغلى لكل token، ويستخدم tokenizer جديداً يضخّم أعداد الـ tokens لديك بنحو 30%، ويشغّل thinking دائم التشغيل لا يمكنك تعطيله، وقد يرفض الطلبات على مستوى المصنّف. بالنسبة لمعظم أحمال العمل، يظل Opus 4.8 هو الخيار الصحيح. لجأ إلى Fable 5 حين تكون المهمة صعبة حقاً. **[قراءة المشغّل]** أشغّل أكثر من 30 وكيلاً في الإنتاج عبر علامة استشارية ومنشأة بيكلبول، لذا فإن نموذجاً رائداً جديداً ليس بالنسبة لي مقياساً مرجعياً — بل هو بند تكلفة وعملية ترحيل. إليك ما تغيّر حين ربطت Fable 5 فعلياً ببعضها، وأين أبقيت Opus 4.8 في مكانه. ## ما هو Fable 5 فعلاً [Claude](/recommends/claude) Fable 5 هو أقدر نموذج أطلقته Anthropic على نطاق واسع. وهو موجَّه إلى الطرف الأكثر صعوبة من الطيف: الاستدلال العميق وأعمال الوكلاء طويلة المدى — التشغيلات التي يتعيّن فيها على الوكيل أن يحتفظ بخطة عبر عشرات استدعاءات الأدوات دون أن يفقد خيط الموضوع. سطح الـ API مطابق تقريباً لـ Opus 4.7/4.8، ما سهّل اختباره. نافذة سياق بسعة 1M-token افتراضياً، وحتى 128K من tokens الإخراج لكل طلب. إن كنت قد بنيت أي شيء على سلسلة Opus الحديثة، فإن شكل الطلب مألوف. تكمن الاختلافات في التفاصيل، وفي التفاصيل تعيش الأموال والمفاجآت. ملاحظة بشأن التسمية كي لا تختلط عليك الأمور: **Mythos 5** هو النموذج نفسه — القدرات ذاتها، والتسعير ذاته، والسلوك ذاته — متاح فقط عبر برنامج Project Glasswing من Anthropic. إن لم تكن مشاركاً في ذلك البرنامج، فالنموذج الذي تريده هو `claude-fable-5`. كل ما يلي ينطبق على كليهما. ## أين هو أفضل فعلاً ألقيت إليه أصعب مهمة وكيل لديّ أولاً: تشغيلة بحث وتركيب متعددة الخطوات تقرأ كومة من المصادر، وتدقّق الادعاءات تقاطعياً، وتكتب موجزاً موثّقاً. هذا هو نوع العمل الذي تنحرف فيه النماذج الأضعف — تفقد تتبّع أي ادعاء جاء من أي مصدر بعد نحو عشر استدعاءات للأدوات. تمسّك Fable 5 بخيط الموضوع. كان التركيب أكثر إحكاماً، وبقيت الاستشهادات مرتبطة بالادعاءات الصحيحة، والتقط تناقضين بين المصادر كانت نسخة Opus 4.8 لديّ تتجاوزهما بهدوء بالتوسيط. في الاستدلال الطويل المنظَّم، إنه قفزة حقيقية إلى الأمام — لا مجرد تحسّن هامشي في المقاييس المرجعية. تلك هي الحجة الصادقة له. إن كان نمط فشل وكيلك هو «الانهيار في الـ 10% الصعبة»، فإن Fable 5 يضيّق تلك الفجوة. أما إن كان وكيلك يلخّص النشرات الإخبارية أو يصوغ منشورات اجتماعية، فلن تشعر بالفرق — وستدفع ثمن قدرة لا تستخدمها. ## مأزق التكلفة الذي لا يحذّرك منه أحد هذا هو المأزق الذي سيعضّك إن تصفّحت ملاحظات الإصدار بسرعة. يأتي Fable 5 مع **tokenizer جديد**، والمحتوى نفسه يُحوَّل إلى **عدد tokens أكبر بنحو 30%** مما هو عليه في سلسلة Opus. اقرأ ذلك مجدداً، لأنه يتراكب مع السعر. فـ Fable 5 مسعَّر أصلاً فوق فئة Opus (‏10 دولارات لكل مليون input token، و50 دولاراً لكل مليون output). والآن أضِف تضخّماً في الـ tokens بنحو 30% فوق كل prompt وإكمال. حمل عمل بلا تغيير — الـ prompts نفسها، والمخرجات نفسها — قد يكلّف أكثر بكثير بعد الترحيل، قبل أن تغيّر شيئاً واحداً مما يفعله الوكيل. لذا لا تُعِد استخدام أرقامك القديمة. إعدادات `max_tokens` لديك، وميزانيات نافذة السياق، وتقديرات التكلفة لكل تشغيلة — كلها قيست على tokenizer مختلف. الخبر السار: تُرجِع نقطة نهاية عدّ الـ tokens الأعداد تحت **كلا** الـ tokenizer حين تمرّر `model: "claude-fable-5"`، فيمكنك قياس الفرق على prompts الفعلية لديك قبل أن تبدّل أي شيء. ```bash # Measure the tokenizer delta on YOUR prompt before migrating. # The response includes input_tokens (new) AND input_tokens_prior_tokenizer (old). curl https://api.anthropic.com/v1/messages/count_tokens \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-fable-5", "messages": [{"role":"user","content":""}] }' ``` أجريت هذا على أثقل prompts لديّ أولاً. لم يكن الفرق منتظماً — فهو يتفاوت حسب المحتوى — لكن قاعدة «خصّص ميزانية لزيادة نحو 30%، ثم أضِف علاوة السعر» كانت النموذج الذهني الصحيح. ## thinking دائم التشغيل — ولا يمكنك إيقافه في Fable 5، يعمل thinking التكيّفي دائماً. التغيير الكاسر الوحيد الجديد مقارنة بسلسلة Opus: إن أرسلت `thinking: {type: "disabled"}` بشكل صريح، فستحصل على 400. الحل بسيط — فقط احذف معامل `thinking` كلياً — لكن إن كان لديك كود يعطّل thinking صراحةً لمكالمات رخيصة وسريعة، فهذا الكود يُخطئ الآن. كما لا تستعيد سلسلة التفكير الخام. يحمي Fable 5 ذلك: تتلقّى كتل `thinking` عادية، ويمكنك طلب ملخص قابل للقراءة عبر `display: "summarized"`، لكن الاستدلال غير المُرشَّح لا يُكشف أبداً. بالنسبة لمعظم التطبيقات هذا غير ذي بال — اقرأ الملخص إن احتجت إلى الرؤية. المكان الذي يهمّ فيه هو **الوكلاء متعددو الأدوار**: حين تواصل محادثة على النموذج نفسه، عليك تمرير كتل thinking مجدداً **دون تغيير**. أسقِطها أو عدّلها وينكسر الدور. إن كنت تبني حلقات وكلاء، فعامِل كتل thinking كـ tokens غامضة تحملها للأمام حرفياً. ## الرفض صار الآن مشكلة في تدفق التحكّم هذا هو التغيير الذي يؤثّر أكثر من غيره في كيفية كتابتك للكود حول النموذج. يشغّل Fable 5 مصنّفات أمان على الطلبات الواردة، تستهدف بشكل أساسي بيولوجيا الأبحاث ومعظم محتوى الأمن السيبراني. حين يُرفض طلب، تحصل على **HTTP 200 ناجح** مع `stop_reason: "refusal"` — لا خطأ، ولا استثناء. وقد تكون مصفوفة `content` فارغة. إن كان كودك يفعل `response.content[0].text` دون التحقق من `stop_reason` أولاً، فسوف يتعطّل في اليوم الذي يُرفض فيه طلب. والأعمال الحميدة المجاورة — أدوات الأمن المشروعة، ومهام علوم الحياة — قد تُطلِق أحياناً نتيجة إيجابية كاذبة، فهذه ليست مشكلة لمن يقومون بأمور مريبة فحسب. القاعدة هي: **تفرّع بناءً على `stop_reason`، لا بناءً على `stop_details` أبداً.** ```typescript const res = await client.messages.create({ model: "claude-fable-5", max_tokens: 1024, messages, }); if (res.stop_reason === "refusal") { // classifiers declined — content is empty or partial. Don't read content[0]. await handleRefusal(res); } else { console.log(res.content[0].text); } ``` بالنسبة للإنتاج، ثمة مسار أنظف: معامل `fallbacks` من جانب الخادم (في الإصدار التجريبي) يعيد محاولة الطلب المرفوض تلقائياً على `claude-opus-4-8` ضمن الرحلة الواحدة نفسها، مع تطبيق إعادة تسعير على نمط الرصيد. إن كنت تشغّل وكلاء دون إشراف، فاربط ذلك حتى لا تؤدي نتيجة إيجابية كاذبة واحدة إلى إيصال تشغيلة بأكملها إلى طريق مسدود. هذا هو الدرس نفسه الذي أعيد تعلّمه باستمرار بشأن الوكلاء التي [تستمر في الفشل في الإنتاج](/blog/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it): ازدياد ذكاء النموذج لا يلغي الحاجة إلى التعامل مع حالاته الحدّية — بل ينقل الحالات الحدّية إلى مكان آخر. ## تفصيلان إضافيان للترحيل أمران أصغر كلّفاني وقتاً كي لا يكلّفاك وقتك: - **لا توجد تعبئة مسبقة للمساعد.** إن كنت توجّه المخرجات عبر التعبئة المسبقة لدور المساعد الأخير، فقد اختفى هذا النمط. استخدم المخرجات المنظَّمة (`output_config.format`) أو تعليمات الـ system-prompt بدلاً منه. - **الاحتفاظ بالبيانات لمدة 30 يوماً مطلوب.** Fable 5 غير متاح تحت سياسة عدم الاحتفاظ بالبيانات. إن كنت على ZDR لأسباب امتثال، فإن Fable 5 خارج الطاولة ويبقى Opus 4.8 سقفك. تحقّق من هذا *قبل* أن تخطّط للترحيل، لا بعده. ## هل عليك التحوّل فعلاً؟ إليك قرار المشغّل لديّ بعد التعايش معه. **Fable 5 ليس هدف «الترقية إلى أحدث نموذج» الافتراضي — بل Opus 4.8 هو ذلك.** يفاجئ هذا الناس، لكنه التأطير الصحيح. فـ Opus 4.8 مجرد تبديل لمعرّف النموذج عن 4.7 دون تغييرات كاسرة جديدة، وهو أرخص، وبالنسبة للغالبية الساحقة من أعمال الوكلاء يتعذّر تمييزه في جودة المخرجات. يكتسب Fable 5 مكانته في المهام الصعبة فعلاً: الوكلاء طويلو المدى الذين يجب أن يظلوا متماسكين عبر خطوات كثيرة، والاستدلال العميق متعدد المصادر، والتشغيلات التي يكون فيها الفشل الذي تحاول القضاء عليه خفيّاً. لهذه المهام، القدرة حقيقية وتستحق العلاوة. أما لكل ما عداها — صياغة المحتوى، والتصنيف، والتوجيه، والتلخيص — فأنت تدفع المزيد من tokens بسعر أعلى مقابل جودة لا يمكنك إدراكها. انتهى بي الأمر إلى تشغيل كليهما. انتقل وكيل البحث والتركيب لديّ إلى Fable 5. وبقي كل شيء آخر على Opus 4.8. ذلك التقسيم هو جوهر الأمر بأكمله: اختر النموذج حسب المهمة، لا حسب الموضة. إن كنت تشغّل أسطولاً من الوكلاء، فإن الانضباط نفسه الذي كتبت عنه في [حزمة المشغّل لعام 2026 لديّ](/blog/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack) ينطبق — وجّه العمل الصعب إلى النموذج باهظ الثمن وتوقّف عن الدفع الزائد مقابل العمل السهل. ## خلاصة المشغّل اختبر Fable 5 على أصعب مهمة واحدة لديك قبل أن تمسّ أي شيء آخر — فهناك يؤتي ثماره، وإن لم يُحدِث فرقاً هناك، فلن يُحدثه في أي مكان. شغّل عدّاد الـ tokens على prompts الفعلية لديك حتى لا يفاجئك تضخّم الـ tokenizer بنحو 30% وعلاوة السعر في الفاتورة. أضِف فحص `stop_reason: "refusal"` (أو الرجوع الاحتياطي من جانب الخادم إلى Opus 4.8) أينما لمس Fable 5 الإنتاج. ثم وجّه عمداً: Fable 5 للـ 10% الصعبة، وOpus 4.8 لما تبقّى. أفضل نموذج ليس الأقدر — بل الذي يناسب المهمة. --- ## الدليل الشامل للمبتدئين في وكلاء الذكاء الاصطناعي: Cowork وCodex والأدوات التي تنجز العمل فعلاً Source: https://alejandrorioja.com/ar/ai-agents-for-beginners-cowork-codex-guide/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: وكلاء الذكاء الاصطناعي خطوة تتجاوز روبوتات المحادثة: تعطيهم هدفاً بلغة عادية فيُنجزون العمل — قراءة ملفاتك، والصياغة، والتنظيم، وكتابة الكود وتشغيله. Cowork هو المدخل بلا كود؛ وCodex وClaude Code لمن يتعامل مع قاعدة بيانات برمجية. المهارة التي تهم هي كتابة تعليمة واضحة ومحددة، لا تعلّم البرمجة. ## Table of contents _محدّث يونيو 2026._ **TL;DR:** وكلاء الذكاء الاصطناعي خطوة تتجاوز روبوتات المحادثة: تعطيهم هدفاً بلغة عادية فيُنجزون العمل — يقرؤون ملفاتك، ويصوغون المحتوى، وينظّمون، ويكتبون الكود ويشغّلونه، ويتحقّقون من نتائجهم. **Cowork** هو المدخل بلا كود للأشخاص غير التقنيين؛ **Codex** و**Claude Code** لمن يتعامل مع قاعدة بيانات برمجية. المهارة الوحيدة التي تهم هي كتابة تعليمة واضحة ومحددة النطاق، لا تعلّم البرمجة. **[ملاحظة الكاتب]** أُشغّل يومياً أكثر من 30 وكيلاً مبرمجاً، غير أن معظم الناس لا يحتاجون إلى كود للحصول على 80% من القيمة. كل ما يحتاجونه هو تعليمة واضحة ومكان لتنفيذها. هذا الدليل هو المقدمة التي سأضعها بين يدي صديق ذكي لم يكتب سطراً واحداً من الكود في حياته. ## ما هو «وكيل الذكاء الاصطناعي» فعلاً روبوت المحادثة يُجيب على سؤال. أما **الوكيل** فيُكمل مهمة. الفارق أن الوكيل يستطيع تنفيذ إجراءات في حلقة متكررة — يقرأ مستنداً، يقرر ما يفعله بعد ذلك، يكتب ملفاً، ينفّذ أمراً، يتحقق من النتيجة، يصلح ما أخطأ — دون أن تُوجّهه في كل خطوة. على وجه التحديد: لا تسأل «كيف أنظّف هذا الجدول؟» بل تقول: «هذا الجدول — أزل المكررات، وصحّح صيغ التاريخ، وضع علامة على الصفوف التي لا تحتوي على بريد إلكتروني»، فيفعل الوكيل ذلك ويسلّمك الملف نظيفاً. هذا التحوّل — من *النصيحة* إلى *العمل المُنجَز* — هو جوهر الأمر كله. ## عائلتا الأدوات ثمة بابان للدخول إلى هذا العالم، ولا تحتاج إلا الباب الذي يتناسب مع عملك. ### الباب الأول: الوكلاء بلا كود (ابدأ هنا إن كنت لا تكتب كوداً) **Claude Cowork** مساحة عمل تعطي فيها Claude هدفاً مع المواد — ملفات، روابط، ملاحظات — فيُنتج النتيجة التي تراجعها وتستخدمها: مسوّدة، ملخصاً، خطة، جدولاً منقّحاً. أنت تكتب تعليمات لا كوداً. تصوّره «مساعداً بالغ الكفاءة يقرأ بسرعة ولا يُصيبه التعب»، لا «أداة برمجة». هذه هي نقطة البداية الصحيحة للمسوّقين، والمؤسسين، والمشغّلين، والكتّاب، والمحللين — كل من يكون عمله في معظمه مستنداتٍ وبحثاً وقرارات. ### الباب الثاني: وكلاء البرمجة (استخدمها فور أن تنطوي المهمة على قاعدة بيانات برمجية) **OpenAI Codex** و**Claude Code** وكلاء يعيشون حيث يُبنى البرنامج — طرفية، بيئة تطوير، أو سحابة. تصف تغييراً («أضف مفتاح الوضع الداكن»، «أصلح هذا الاختبار الفاشل»، «انقل هذا الملف إلى الـ API الجديدة») فيحرّر الوكيل الكود ويُشغّله ويكرر حتى ينجح. أنت لا تزال تراجع كل شيء؛ الوكيل يتولى الكتابة. لا تحتاج أن تكون مهندساً متمرساً لاستخدامها. كثيرون من غير المطورين يستعملون وكلاء البرمجة لإطلاق مواقع صغيرة، وأتمتة الجداول كسكريبتات، وإصلاح أخطاء في أدوات لم يكتبوها. غير أن منحنى التعلم حقيقي، لذا يستفيد معظم المبتدئين من البدء بالباب الأول والولوج من الباب الثاني حين يواجهون مهمة تستلزم فعلاً كوداً. ## انتصارك الأول (افعله اليوم) اختر مهمة صغيرة مُزعجة تفعلها كثيراً. مرشحات جيدة للبداية: - تحويل محضر اجتماع فوضوي إلى ملاحظات نظيفة مع قائمة بنود العمل. - تلخيص ملف PDF طويل في 5 نقاط رئيسية و3 أسئلة تستحق الطرح. - إعادة كتابة مسوّدة بريد إلكتروني لتكون واضحة ودافئة وأقل من 120 كلمة. ثم استخدم البنية التي تجعل الوكلاء موثوقين بدلاً من متذبذبين — **الدور ← المدخلات ← التعليمة الدقيقة ← القيد ← مراجعة**: > أنت مساعدي. إليك [محضر اجتماع / ملف PDF / مسوّدة بريد إلكتروني] ملصقاً أدناه. افعل هذا: [حوّله إلى ملاحظات نظيفة مع قائمة \"بنود العمل\" بخط عريض / لخّصه في 5 نقاط + 3 أسئلة متابعة / أعد كتابته ليكون واضحاً ودافئاً وأقل من 120 كلمة]. حافظ على أسلوبي. اطرح عليّ سؤالاً واحداً إن كان أي شيء غامضاً قبل أن تبدأ. > > [الصق محتواك هنا] هذا كل شيء. لقد فوّضت مهمة للتو. البنية هي اللعبة بأكملها — وتعمل بالطريقة ذاتها في Cowork أو ChatGPT أو أي وكيل برمجة. ## التعليمة الرباعية التي تجعل الوكلاء موثوقين يظن المبتدئون أن السر عبارة سحرية. ليس كذلك. السر هو التحديد. كل تعليمة موثوقة لوكيل تحتوي أربعة أجزاء: 1. **الدور** — من هو الوكيل في هذه المهمة («أنت مساعدي في البحث»). 2. **السياق** — المواد و*لماذا* («أستعد لمكالمة مبيعات مع مؤسس شركة تقنية مالية»). 3. **المهمة** — الإجراء الدقيق المحدد النطاق («اسحب ثلاثة حقائق عن جولات التمويل الأخيرة وصُغ سؤالين افتتاحيين»). 4. **القيود + مراجعة** — التنسيق، الطول، النبرة، وتعليمة بالسؤال قبل التخمين («نقاط فقط، مع ذكر المصادر، واطرح سؤال توضيح واحداً إن كان اسم الشركة غامضاً»). غامض ما يدخل، غامض ما يخرج. كلما ازدادت قدرة الوكيل على *الفعل*، كلما كانت وضوحك أشد أهمية — روبوت محادثة يُسيء الفهم يُضيّع جملة؛ وكيل يُسيء الفهم يُضيّع بعد ظهر من العمل تضطر إلى التراجع عنه. ## أخطاء المبتدئين التي تستحق التجنّب - **التعامل معه كمحرك بحث.** لا تطرح أسئلة من سطر واحد. أعطه عملاً حقيقياً بملفات حقيقية. - **تجاوز القيد.** «اكتب لي خطة» يعطيك جداراً من النص. «اكتب لي خطة من صفحة واحدة بثلاث مراحل ومسؤول عن كل مهمة» يعطيك شيئاً قابلاً للاستخدام. - **عدم طلب المراجعة.** أضف «اطرح عليّ سؤالاً إن كان أي شيء غامضاً» وستلتقط سوء الفهم *قبل* أن يبدأ الوكيل لا بعده. - **ترك وكلاء البرمجة يعملون دون رقابة على كود مهم.** راجع الـ diff. الوكلاء سريعون وصحيحون في معظمهم، لكن «في معظمهم» تؤدي وظيفة في تلك الجملة — احتفظ بإنسان في الحلقة على كل ما يُشحن إلى الإنتاج. - **الانتقال المبكر إلى الباب الثاني.** إن كانت مهمتك مستنداتٍ وقرارات، فلن تحتاج أبداً إلى فتح طرفية. ## كيف تختار أول أداة لك - **عملك مستنداتٌ وبحثٌ وكتابة** → ابدأ بـ**Cowork** (أو منتج الدردشة الذي تدفع له بالفعل، مستخدماً في وضع الوكيل). - **تريد بناء برمجيات أو إصلاحها** → **Claude Code** أو **OpenAI Codex**. - **تريد عملاً متكرراً دون تدخّل** (ملخص يومي، تقرير أسبوعي) → انتقل إلى **[المهام المجدولة](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/)** بمجرد أن تُتقن التعليمة يدوياً. ## وكلاء الذكاء الاصطناعي للمبتدئين — الأسئلة الشائعة 2026 ### هل أحتاج إلى معرفة البرمجة لاستخدام وكلاء الذكاء الاصطناعي؟ لا. الوكلاء بلا كود كـClaude Cowork مُصمَّمون للمستخدمين غير التقنيين — تكتب التعليمات بلغة عادية. وكلاء البرمجة كـCodex وClaude Code تنطوي على منحنى تعلّم، لكن حتى هؤلاء يستخدمهم بشكل متزايد أناس لا يعتبرون أنفسهم مبرمجين. ابدأ بلا كود، وانتقل إلى الكود فقط حين تستلزم المهمة ذلك. ### ما الفرق بين روبوت المحادثة ووكيل الذكاء الاصطناعي؟ روبوت المحادثة يُجيب على أسئلة؛ الوكيل يُكمل مهاماً. الوكيل قادر على تنفيذ سلسلة من الإجراءات — قراءة، قرار، فعل، تحقق، تصحيح — في حلقة متكررة، فيُنتج عملاً مُنجَزاً لا نصائح. عملياً، المنتج نفسه كثيراً ما يفعل الاثنين؛ «وضع الوكيل» هو سلوك الوكيل. ### هل Cowork أفضل من Codex؟ كلاهما لوظائف مختلفة، لا أفضل ولا أسوأ. Cowork مساحة عمل بلا كود للمستندات والبحث والعمليات. Codex (وClaude Code) وكلاء برمجة لبناء البرمجيات وإصلاحها. اختر ما يتناسب مع مهمتك. ### كيف أحصل على نتائج جيدة من وكيل الذكاء الاصطناعي؟ التحديد. استخدم البنية الرباعية: الدور، والسياق، والمهمة الدقيقة، والقيود مع مراجعة. أعطه مواد حقيقية، أخبره بالتنسيق الذي تريده، واطلب منه الإشارة إلى الغموض قبل أن يبدأ. التعليمات الواضحة أهم من أي «تعليمة سحرية». ### هل من الآمن ترك وكلاء الذكاء الاصطناعي يعملون وحدهم؟ للمهام منخفضة الخطورة والقابلة للتراجع (الصياغة، التلخيص، التنظيم)، نعم — راجع المخرجات وتابع. لأي شيء يُغيّر أنظمة حقيقية (شحن كود، إرسال رسائل، حذف بيانات)، احتفظ بإنسان في الحلقة وراجع قبل أن يتصرف. القابلية للتراجع هي المقياس الصحيح: كلما كان التراجع عن شيء ما أيسر، كلما كان بإمكانه امتلاك استقلالية أكبر بأمان. **قراءات ذات صلة:** [كيف تُستشهد بك في إجابات ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) · [دليل llms.txt](https://alejandrorioja.com/llms-txt-playbook/) · [كيف تستخدم المهام المجدولة في Claude](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/) --- **تريد مساعدة في توظيف الوكلاء في عملك؟** أبني أنظمة وكلاء ذكاء اصطناعي لفرق التشغيل — [تواصل معي](https://alejandrorioja.com/contact/) أو اقرأ المزيد عن [طريقتي في التفكير](https://alejandrorioja.com/seo-tips/). --- ## كيف تكسب Anthropic المال؟ نموذج أعمال Claude موضّحًا Source: https://alejandrorioja.com/ar/how-does-anthropic-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: تبيع Anthropic حق الوصول إلى نماذج Claude للذكاء الاصطناعي عبر خمس قنوات رئيسية: API مبني على الاستخدام (تدفع لكل رمز)، واشتراكات للمستهلكين (Claude Pro وMax)، وخطط مؤسسية (مقاعد Team وEnterprise)، وClaude Code للمطوّرين، والتوزيع عبر أسواق السحابة كـ Amazon Bedrock وGoogle Vertex. قناة API والأعمال المؤسسية — لا تطبيق المستهلك — هي المحرّكات الأكبر للإيرادات. ## Table of contents _محدَّث يونيو 2026._ **TL;DR:** تبيع Anthropic حق الوصول إلى نماذج Claude للذكاء الاصطناعي عبر خمس قنوات رئيسية: **API مبني على الاستخدام** (تدفع لكل رمز)، **اشتراكات للمستهلكين** (Claude Pro وMax)، **خطط مؤسسية** (مقاعد Team وEnterprise)، **Claude Code** للمطوّرين، و**التوزيع عبر أسواق السحابة** كـ Amazon Bedrock وGoogle Vertex AI. قناة API والأعمال المؤسسية — لا تطبيق الدردشة للمستهلكين — هي المحرّكات الأكبر للإيرادات. **[ملاحظة المشغّل]** أبني على API الخاص بـ Anthropic يوميًا، لذا أرى الأعمال من داخل العدّاد. ما يجب فهمه: Anthropic شركة B2B لها باب أمامي للمستهلكين. تطبيق الدردشة الذي تستخدمه هو تسويق وخط إيرادات في آنٍ واحد؛ لكن المال الحقيقي يأتي من المطوّرين والمؤسسات التي تقيس الرموز عبر API وتدفع مقابل المقاعد على نطاق واسع. ## ما هي Anthropic Anthropic شركة متخصصة في أبحاث سلامة الذكاء الاصطناعي، تأسّست عام 2021، وتطوّر عائلة النماذج اللغوية الكبيرة **Claude**. تبيع هذه النماذج — وأدواتها المحيطة — للمستهلكين والمطوّرين والمؤسسات. وهي شركة خاصة تحظى بدعم استراتيجي قوي من مستثمرين بينهم Amazon وGoogle، اللذان يعملان أيضًا كشريكَي سحابة وتوزيع. المنتج ذكاء كخدمة: لا تشتري برنامجًا في صندوق، بل تستأجر حق الوصول إلى نموذج يقرأ ويكتب ويستدل ويتصرّف نيابةً عنك. كل قناة في ما يلي هي غلاف مختلف حول الأصل الجوهري ذاته. ## كيف تكسب Anthropic المال؟ ### 1. الـ API (مبني على الاستخدام، المحرّك الأساسي) أساس الأعمال. يستدعي المطوّرون والشركات Claude عبر API ويدفعون **لكل رمز** — تقريبًا، لكل قطعة نص في المدخلات والمخرجات. يتدرّج السعر مع قدرة النموذج: - **Claude Opus** (المستوى الأعلى قدرةً) الأغلى سعرًا — بترتيب بضعة دولارات لكل مليون رمز في المدخلات وأضعاف ذلك للمخرجات. - **Claude Sonnet** (النموذج المتوازن الشامل) في المنتصف. - **Claude Haiku** (المستوى السريع والاقتصادي) الأقل سعرًا، للمهام البسيطة ذات الحجم الكبير. رموز المخرجات أغلى من رموز المدخلات، وميزات كالسياق الطويل والتخزين المؤقت للمطالبات والمعالجة الدُّفعية لها تسعيرها الخاص. الديناميكية الأساسية: **الإيرادات تتناسب مباشرةً مع الاستخدام**. شركة ناشئة تدمج Claude في منتجها وتنمو لتصل إلى ملايين المستخدمين تولّد إيرادات API أكثر كل شهر دون أن توقّع Anthropic صفقةً جديدة. هذا النموذج القائم على الاستخدام هو سبب حديث مختبرات الذكاء الاصطناعي عن إيرادات "معدّل التشغيل" التي تنمو بهذه السرعة — فهي تتراكم مع نموّ العملاء أنفسهم. ### 2. اشتراكات المستهلكين (Claude Pro وMax) تطبيقات Claude (الويب وسطح المكتب والجوال) مجانية للتجربة، مع مستويات مدفوعة لمن يستخدمها بكثافة: - **Claude Pro** — رسوم شهرية ثابتة للحصول على حدود استخدام أعلى، والوصول إلى أفضل النماذج، وميزات كسياق أوسع وأولوية في الوصول. - **Claude Max** — مستوى أعلى سعرًا للمستخدمين المتقدّمين الذين يبلغون حدود Pro، مع مساحة استخدام أكبر بكثير. هذا الجزء الأكثر ظهورًا من Anthropic لكنه، لشركة عملاؤها في معظمهم شركات أخرى، شريحة أصغر مقارنةً بخطوط API والمؤسسات. قيمته الاستراتيجية كقمع وسطح علامة تجارية لا تقل عن كونه مصدر إيرادات. ### 3. المؤسسات (مقاعد Team وEnterprise) هنا يوجد كثير من المال الدائم. تشتري الشركات Claude لموظفيها على أساس **مقعد لكل مستخدم**، بخطط مصمّمة للمؤسسات: - **Team** — للشركات الأصغر: استخدام مجمّع وفوترة مركزية وميزات تعاون. - **Enterprise** — للمؤسسات الكبيرة: أمان وامتثال أعلى، وتسجيل دخول موحّد، ونوافذ سياق أوسع، وضوابط إدارية، وضمانات استخدام. صفقات المؤسسات متكرّرة وتتوسّع بمرور الوقت (مزيد من المقاعد والاستخدام)، وتحمل معها تكاليف التحوّل التي تجعل الإيرادات راسخة. هذه هي حركة SaaS الكلاسيكية المبنيّة فوق النموذج. ### 4. Claude Code (أدوات المطوّرين) **Claude Code** هو أداة البرمجة الوكيلة من Anthropic — وكيل يكتب الكود ويحرّره ويشغّله في طرفيّتك أو بيئة التطوير المتكاملة أو السحابة. يُجنى منه عبر نفس قضبان الاشتراك والاستخدام (مدرج في مستويات Pro/Max/Team/Enterprise ويُقاس على خطتك). استراتيجيًا يؤدّي مهمتَين: خط إيرادات بحد ذاته، وهو يدفع استخدامًا كثيرًا من الرموز عالية القيمة إذ تستهلك وكلاء البرمجة قدرًا كبيرًا من طاقة النموذج. ### 5. التوزيع عبر أسواق السحابة (AWS وGoogle وغيرها) لا تبيع Anthropic Claude مباشرةً فحسب — بل توزّعه عبر منصات السحابة الكبرى: - **Amazon Bedrock** و**Claude Platform on AWS** — عملاء AWS الحاليون يصلون إلى Claude عبر بنية Amazon التحتية وفوترتها. - **Google Vertex AI** و**Microsoft Foundry** — نفس الفكرة على Google Cloud ومنصة Microsoft. هذه القنوات تلتقي بالمؤسسات حيث توجد نفقاتها السحابية ومشترياتها بالفعل، مما يخفّض الاحتكاك أمام تبنّي Claude. تُشارك الإيرادات مع المنصة، لكن النطاق هائل — والاستثمارات العميقة من Amazon وGoogle تجعل هذه الشراكات استراتيجية لا تجارية فحسب. ### 6. منصة الوكلاء الناشئة تبيع Anthropic بشكل متزايد ليس مجرّد استدعاءات نماذج خام، بل **بنية تحتية للوكلاء** — خدمات مُدارة تشغّل فيها Anthropic حلقة الوكيل وتستضيف البيئة التي ينفّذ فيها الوكلاء المهام. كلما انتقل مزيد من العملاء من "طرح سؤال على النموذج" إلى "جعل وكيل يقوم بالعمل"، أصبحت هذه الطبقة الأعلى مكانًا جديدًا لالتقاط القيمة فوق جوهر الدفع لكل رمز. ## هل Anthropic مربحة؟ Anthropic شركة خاصة لا تنشر بياناتها المالية المدقَّقة، لكن الصورة العامة هي نفسها لدى نظيراتها: **الإيرادات تنمو بسرعة هائلة**، فيما تنفق الشركة مبالغ ضخمة على الحوسبة (تدريب النماذج وتشغيلها) والمواهب البحثية. كغيرها من مختبرات الذكاء الاصطناعي الرائدة، هي في مرحلة استثمار مكثّف حيث النموّ في صافي الإيرادات، لا الربح الحالي، هو العنوان. الرهان الذي يضعه المستثمرون هو أن الإيرادات القائمة على الاستخدام ستستمر في التراكم المضاعف كلما نسجت الذكاء الاصطناعي في مزيد من البرمجيات، لتتجاوز في نهاية المطاف تكلفة الحوسبة. ## كيف تُقارن مع OpenAI الأشكال متشابهة — كلتاهما تجني الإيرادات عبر اشتراكات المستهلكين وAPI مبني على الاستخدام ومقاعد المؤسسات وأدوات المطوّرين. الفوارق في التركيز والشراكات: Anthropic تراهن بقوة على API المطوّرين والمؤسسات وتحظى بدعم Amazon وGoogle؛ OpenAI لديها حضور أوسع في أسواق المستهلكين وشراكة عميقة مع Microsoft. إن أردت الجانب الآخر من المقارنة، اقرأ [كيف تكسب OpenAI المال](https://alejandrorioja.com/how-does-openai-make-money/). ## نموذج إيرادات Anthropic — الأسئلة الشائعة 2026 ### ما المصدر الرئيسي لإيرادات Anthropic؟ **API المبني على الاستخدام** و**عقود المؤسسات** هما المحرّكان الأثقل. المطوّرون والشركات يدفعون لكل رمز لاستدعاء Claude، والمؤسسات تشتري خططًا بالمقعد لفرقها. اشتراك Claude للمستهلكين هو أكثر المنتجات ظهورًا لكنه شريحة أصغر من الإيرادات مقارنةً بخطوط الأعمال. ### كيف يعمل تسعير API الخاص بـ Claude؟ تدفع لكل رمز — تُقاس المدخلات والمخرجات في مجموعات نصية. النماذج الأكثر قدرة (Opus) تكلّف أكثر لكل رمز من النماذج المتوازنة (Sonnet) أو السريعة (Haiku)، ورموز المخرجات أغلى من المدخلات. ميزات كالسياق الطويل والتخزين المؤقت للمطالبات والمعالجة الدُّفعية لها تسعيرها الخاص. تتناسب الإيرادات مباشرةً مع مقدار استخدام العملاء للنماذج. ### هل Anthropic شركة مدرجة في البورصة؟ لا. Anthropic شركة خاصة تدعمها مستثمرون استراتيجيون ومغامرون بينهم Amazon وGoogle. أسهمها غير متاحة في الأسواق المالية العامة ولا يوجد طرح عام أوّلي مؤكَّد. ### هل تكسب Anthropic من تطبيق Claude المجاني؟ ليس مباشرةً من المستخدمين المجانيين — المستوى المجاني قمع تسويقي. يأتي المال حين يرقّي المستخدمون المجانيون إلى **Pro** أو **Max**، وحين تشتري الفرق **مقاعد مؤسسية**، وخاصةً حين يبني المطوّرون على **API**. مهمة التطبيق المجاني هي الانتشار والعلامة التجارية؛ المستويات المدفوعة وAPI هي حيث يحدث التحوّل. ### من هم أكبر عملاء Anthropic؟ في المقام الأول شركات أخرى: شركات برمجيات تدمج Claude في منتجاتها عبر API، ومؤسسات تنشر Claude لموظفيها. التوزيع عبر أسواق السحابة من خلال AWS وGoogle وMicrosoft يجلب أيضًا عملاء مؤسسيين كبارًا يشترون عبر مزوّدي السحابة الحاليين لديهم. **قراءات ذات صلة:** [كيف تكسب OpenAI المال](https://alejandrorioja.com/how-does-openai-make-money/) · [الدليل المبتدئ لوكلاء الذكاء الاصطناعي](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [كيف تُستشهد بك في إجابات ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- ## النسخة المختصرة Anthropic تؤجّر حق الوصول إلى نماذج Claude. المطوّرون يدفعون لكل رمز عبر API، والمستهلكون يدفعون شهريًا لـ Pro وMax، والشركات تدفع لكل مقعد لـ Team وEnterprise، والمهندسون يستخدمون Claude Code بنفس الخطط، وعمالقة السحابة (AWS وGoogle وMicrosoft) يعيدون بيع Claude للمؤسسات عبر أسواقهم. إنه عمل B2B له باب أمامي للمستهلكين — والعدّاد، لا تطبيق الدردشة، هو المكان الذي يوجد فيه المال. --- ## كيف تجني OpenAI الأموال؟ نموذج أعمال ChatGPT وواجهة برمجة التطبيقات Source: https://alejandrorioja.com/ar/how-does-openai-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: تجني OpenAI الأموال بأربع طرق رئيسية: اشتراكات ChatGPT (Plus وPro وTeam وEnterprise وEdu)، وواجهة برمجة تطبيقات قائمة على الاستخدام يدفع فيها المطورون لكل رمز، وعقود مؤسسية كبيرة، وشراكتها مع Microsoft (التوزيع بالإضافة إلى اتفاقية تقاسم الإيرادات). على خلاف معظم مختبرات الذكاء الاصطناعي، يُعدّ نشاط اشتراكات المستهلكين لدى OpenAI أكبر مصادر إيراداتها المنفردة — وحجم ChatGPT الهائل هو المحرّك. ## Table of contents _محدّث في يونيو 2026._ **TL;DR:** تجني OpenAI الأموال بأربع طرق رئيسية: **اشتراكات ChatGPT** (Plus وPro وTeam وEnterprise وEdu)، و**واجهة برمجة تطبيقات قائمة على الاستخدام** يدفع فيها المطورون لكل رمز، و**عقود مؤسسية كبيرة**، و**شراكتها مع Microsoft** (التوزيع بالإضافة إلى اتفاقية تقاسم الإيرادات). على خلاف معظم مختبرات الذكاء الاصطناعي، يُعدّ نشاط اشتراكات المستهلكين لدى OpenAI أكبر مصادر إيراداتها المنفردة — وحجم ChatGPT الهائل هو المحرّك. **[رؤية المشغّل]** تعمل OpenAI عكس نموذج شركة الذكاء الاصطناعي المؤسسية النموذجية: بنت أولاً ظاهرة استهلاكية، ثم أتبعتها بنشاط تجاري للمطورين والمؤسسات. المئات من الملايين من مستخدمي ChatGPT هم في آنٍ واحد العلامة التجارية وآلة توليد النقد. كل المنافسين في هذا الفضاء يتمنون أن يمتلكوا هذا المستوى من القمع الاستحواذي العلوي. ## ما هي OpenAI؟ OpenAI هي شركة أبحاث الذكاء الاصطناعي التي طورت **ChatGPT** وعائلة نماذج **GPT**، إضافةً إلى منتجات كنموذج الفيديو Sora وتوليد الصور ووكيل البرمجة Codex. تأسست عام 2015، ونالت شهرة واسعة حين أُطلق ChatGPT في أواخر 2022 ليصبح أحد أسرع المنتجات الاستهلاكية نموًا في التاريخ. هيكلها غير مألوف: بدأت كمنظمة غير ربحية وأنشأت ذراعًا ربحية محدودة الأرباح لجمع رأس المال الضخم الذي يستلزمه تدريب النماذج المتطورة. لم تُدرج في البورصة، وتربطها شراكة عميقة متعددة السنوات مع **Microsoft** توفّر فيها القدرة الحاسوبية والتوزيع ورأس المال. المنتج، كما هو الحال في كل مختبر للذكاء الاصطناعي، هو الذكاء كخدمة — يُباع عبر قنوات المستهلكين والمطورين والمؤسسات. ## كيف تجني OpenAI الأموال؟ ### 1. اشتراكات ChatGPT (أكبر مصادر الإيرادات) هذا ما يميّز OpenAI عن أقرانها. ChatGPT مجاني الاستخدام، مع مستويات مدفوعة تحوّل شريحةً من قاعدة مستخدميه الضخمة إلى إيرادات متكررة: - **ChatGPT Plus** — رسوم شهرية ثابتة للوصول إلى أفضل النماذج وحدود أعلى وميزات متميزة. المستوى الموجَّه لعموم السوق. - **ChatGPT Pro** — مستوى بسعر أعلى للمستخدمين المتقدمين الراغبين في أقصى استخدام وأكثر إعدادات النموذج قدرةً. - **ChatGPT Team** — خطط بحسب المقعد للشركات الصغيرة، مع مساحات عمل مشتركة وأدوات إدارية. - **ChatGPT Enterprise** — للمؤسسات الكبيرة: أمان متقدم وامتثال ودخول موحّد (SSO) وسياق أوسع وضمانات استخدام. - **ChatGPT Edu** — نسخة مخصصة للجامعات والمدارس. نظرًا لأن ChatGPT يصل إلى مئات الملايين من المستخدمين أسبوعيًا، فحتى معدل تحويل منخفض بخانة واحدة إلى الخطط المدفوعة يُنتج نشاطًا اشتراكيًا ضخمًا. هذا الحجم الاستهلاكي هو الميزة التنافسية المحورية لـ OpenAI، وتُعدّ الاشتراكات وفق التقارير أكبر مصادر إيراداتها. ### 2. واجهة برمجة التطبيقات (قائمة على الاستخدام، للمطورين) يدمج المطورون والشركات نماذج OpenAI في منتجاتهم الخاصة ويدفعون **لكل رمز** — أي لكل مقطع نصي (أو صورة أو صوت) تتم معالجته. تتناسب الأسعار مع قدرة النموذج: نماذج الاستدلال الرائدة أغلى لكل رمز من النماذج الأصغر والأسرع والأرخص، والإخراج أعلى سعرًا من الإدخال. تحوّل واجهة برمجة التطبيقات كل شركة تبني على GPT إلى عميل مقيس تتزايد فاتورته مع تزايد استخدامه. هذه هي نفس ديناميكية التراكم التي تعتمد عليها كل مختبرات الذكاء الاصطناعي: شركة ناشئة تدمج OpenAI وتتوسع لتصل إلى ملايين المستخدمين تُولّد إيرادات واجهة برمجة تطبيقات أعلى كل شهر دون أي عقد جديد. ### 3. عقود المؤسسات بعيدًا عن واجهة برمجة التطبيقات ذاتية الخدمة وخطط Team، تُبرم OpenAI صفقات كبيرة ومخصصة مع الشركات الكبرى — استخدام بالجملة وطاقة مخصصة ودعم مصمم على المقاس والتزامات بالأمان والامتثال. هذه العقود متكررة وتتوسع بمرور الوقت وتصبح راسخة حين تبني الشركة سير عمل حيوية فوق النماذج. تقف هذه الحركة المؤسسية جنبًا إلى جنب مع النشاط الاستهلاكي وتُعدّ من أبرز مجالات النمو. ### 4. الشراكة مع Microsoft Microsoft هي أكبر شريك استراتيجي لـ OpenAI. تعمل العلاقة على عدة محاور: - **الحوسبة** — توفّر السحابة Azure من Microsoft الجزء الأكبر من البنية التحتية التي تُدرّب عليها OpenAI النماذج وتقدّمها. - **التوزيع** — تُعرض نماذج OpenAI عبر منصات Microsoft (خدمات Azure للذكاء الاصطناعي ومنتجات Copilot)، ما يضع GPT أمام قاعدة العملاء المؤسسيين الضخمة لـ Microsoft. - **تقاسم الإيرادات** — تتشارك الشركتان الإيرادات بموجب اتفاقيتهما التجارية، وقد ضخّت Microsoft استثمارات ضخمة في OpenAI. هذه الشراكة جزء منها رأس مال وجزء منها استراتيجية دخول السوق: تمنح OpenAI وصولاً إلى مؤسسات كان ليستغرق التواصل معها مباشرةً سنواتٍ طويلة. ### 5. المنتجات الجديدة والمجاورة تواصل OpenAI توسيع المساحة التي يمكنها تحقيق الدخل منها: - **Codex** — أداة البرمجة الوكيلة، تُجني أرباحها عبر الاشتراكات واستخدام واجهة برمجة التطبيقات (وهي محرّك لاستهلاك الرموز بكثافة). - **Sora** — توليد الفيديو، مُتاح ضمن المستويات المدفوعة وكمنتج قائم بذاته. - **توليد الصور وأساليب أخرى** — مُدرَج في الاشتراكات ومُقاس عبر واجهة برمجة التطبيقات. - **منظومة المطورين والوكلاء** — GPTs مخصصة ومنصة وكلاء وأدوات تتيح للشركات البناء فوق نماذج OpenAI. كل واحدة من هذه المنتجات هي غلاف إضافي حول الأصل الجوهري ذاته، يستهدف الاستحواذ على المزيد مما يرغب المستخدمون والمطورون في الدفع مقابله. ## هل OpenAI مربحة؟ تعمل OpenAI كشركة خاصة ولا تنشر بيانات مالية مُدقَّقة. الصورة الأوسع انتشارًا: **الإيرادات ضخمة جدًا وتنمو بسرعة**، لكن التكاليف كذلك — يستهلك تدريب النماذج المتطورة وخدمة مئات الملايين من المستخدمين كميات حوسبة مذهلة. كأقرانها، تمرّ OpenAI بمرحلة استثمار مكثّف تكون فيها الأولوية للنمو والقدرة لا للربح قصير الأمد. الرهان هو أن الحجم المتزايد وتبنّي المؤسسات المتنامي سيتجاوزان في نهاية المطاف تكاليف الحوسبة. ## المقارنة مع Anthropic مكوّنات البناء متشابهة — اشتراكات المستهلكين وواجهة برمجة تطبيقات قائمة على الاستخدام وصفقات مؤسسية وأدوات برمجة — لكن التركيز يختلف. الميزة المحورية لـ OpenAI هي **الحجم الاستهلاكي** (ChatGPT) وشراكتها مع **Microsoft**؛ بينما تميل Anthropic أكثر نحو **واجهة برمجة التطبيقات للمطورين والمؤسسات** وتحظى بدعم Amazon وGoogle. للاطلاع على الجانب المقابل من المقارنة، انظر [كيف تجني Anthropic الأموال](https://alejandrorioja.com/how-does-anthropic-make-money/). ## نموذج إيرادات OpenAI — الأسئلة الشائعة 2026 ### ما أكبر مصادر إيرادات OpenAI؟ **اشتراكات ChatGPT.** نظرًا لأن ChatGPT يصل إلى مئات الملايين من المستخدمين، تُشكّل مستوياته المدفوعة (Plus وPro وTeam وEnterprise وEdu) أكبر مصادر إيرادات OpenAI المنفردة — وهو ملف غير مألوف لمختبر ذكاء اصطناعي، إذ تكسب معظم المختبرات أكثر من واجهات برمجة التطبيقات والمؤسسات مما تكسبه من المستهلكين. ### كيف تجني واجهة برمجة تطبيقات OpenAI الأموال؟ يدفع المطورون **لكل رمز** لاستخدام نماذج OpenAI في تطبيقاتهم — لكل مقطع من النص أو الصورة أو الصوت المُعالَج. النماذج الأكثر قدرةً أعلى تكلفةً لكل رمز، والإخراج أعلى سعرًا من الإدخال. تنمو الإيرادات تلقائيًا مع نمو استخدام العملاء الخاص. ### هل OpenAI مدرجة في البورصة؟ هل يمكنني شراء أسهم OpenAI؟ لا. OpenAI شركة خاصة وأسهمها غير متاحة في الأسواق العامة. لا يستطيع معظم الناس الاستثمار فيها مباشرةً. تمتلك Microsoft حصةً كبيرة من خلال شراكتها، لكن ذلك لا يعني أن OpenAI مطروحة للاكتتاب العام. ### كيف تُدرّ الشراكة مع Microsoft أموالاً على OpenAI؟ توفّر Microsoft الحوسبة عبر Azure، وتوزع نماذج OpenAI عبر منتجاتها وسحابتها على قاعدة ضخمة من العملاء المؤسسيين، وتتشارك الشركتان الإيرادات بموجب اتفاقيتهما التجارية. كما استثمرت Microsoft بشكل ضخم في OpenAI. إنها مصدر تمويل وقناة توزيع في آنٍ واحد. ### هل تجني OpenAI أموالاً من مستخدمي ChatGPT المجانيين؟ ليس مباشرةً — المستوى المجاني هو قمع استحواذي. تأتي الإيرادات حين يرقّي المستخدمون المجانيون إلى **Plus** أو **Pro**، أو حين تشتري الشركات مقاعد **Team** أو **Enterprise**، وحين يبني المطورون على **واجهة برمجة التطبيقات**. دور المنتج المجاني هو الوصول؛ والمستويات المدفوعة وواجهة برمجة التطبيقات هي التي تحوّل ذلك إلى إيرادات. **قراءات ذات صلة:** [كيف تجني Anthropic الأموال](https://alejandrorioja.com/how-does-anthropic-make-money/) · [كيف تجني SpaceX الأموال](https://alejandrorioja.com/how-does-spacex-make-money/) · [دليل المبتدئين لوكلاء الذكاء الاصطناعي](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) --- ## النسخة المختصرة تحوّل OpenAI قاعدة المستخدمين الضخمة لـ ChatGPT إلى إيرادات اشتراك (Plus وPro وTeam وEnterprise)، وتُحصّل من المطورين رسومًا لكل رمز عبر واجهة برمجة التطبيقات، وتُبرم عقودًا مؤسسية كبيرة، وتعتمد على Microsoft للحوسبة والتوزيع وتقاسم الإيرادات. سمتها المحورية هي الحجم الاستهلاكي — تُعالج معظم مختبرات الذكاء الاصطناعي أولاً تحقيق الدخل من المطورين؛ أما OpenAI فقد أسست أولاً ظاهرةً استهلاكية ثم أقامت وراءها نشاطًا تجاريًا. --- ## كيف تجني SpaceX أموالها؟ الإطلاق، Starlink، وسؤال الطرح العام Source: https://alejandrorioja.com/ar/how-does-spacex-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business TL;DR: تجني SpaceX أموالها بثلاث طرق: خدمات الإطلاق (بيع مقاعد إلى المدار على صواريخ Falcon القابلة لإعادة الاستخدام)، وStarlink (الإنترنت الفضائي للأفراد والمؤسسات والقطاعين البحري والجوي والحكومات)، والعقود الحكومية (طاقم NASA والشحن، والمركبات القمرية، وإطلاقات الأمن القومي). أصبح Starlink الآن أكبر مصدر للإيرادات. تبقى SpaceX شركةً خاصة؛ لا يلوح اكتتاب SpaceX في الأفق القريب، وإن كان طرح Starlink مستقلاً يُطرح للنقاش منذ أمد بعيد. ## Table of contents _محدَّث في يونيو 2026._ **TL;DR:** تجني SpaceX أموالها بثلاث طرق: **خدمات الإطلاق** (بيع مقاعد إلى المدار على صواريخ Falcon القابلة لإعادة الاستخدام)، و**Starlink** (الإنترنت الفضائي للأفراد والمؤسسات والقطاعين البحري والجوي والحكومات)، و**العقود الحكومية** (طاقم NASA والشحن، والمركبات القمرية، وإطلاقات الأمن القومي). أصبح Starlink الآن أكبر مصدر للإيرادات. تبقى SpaceX شركةً خاصة؛ لا يلوح اكتتاب SpaceX في الأفق القريب، وإن كان طرح Starlink مستقلاً يُطرح للنقاش منذ أمد بعيد وتتقلص التوقعات حوله مراراً. **[رأي المشغّل]** تُعدّ SpaceX النموذج المعاصر الأجلى لشركة استثمرت ميزتها التنافسية في التكنولوجيا الصلبة (الصواريخ القابلة لإعادة الاستخدام) لتبني فوقها نموذج أعمال باقتصاديات البرمجيات (الإنترنت عبر الأقمار الاصطناعية). أعمال الإطلاق تكسب حق الوجود؛ Starlink هو مصدر الإيرادات المتكررة والقابلة للتوسع. هذه هي القصة بأسرها في جملة واحدة. ## ما هي SpaceX؟ SpaceX (شركة سبيس إكسبلوريشن تكنولوجيز) تُصمّم وتبني وتُطلق الصواريخ والمركبات الفضائية، وتدير شبكة Starlink للإنترنت عبر الأقمار الاصطناعية. تأسست عام 2002 بهدف بعيد المدى يرمي إلى جعل البشرية متعددة الكواكب، وصارت المزوّد الرائد للإطلاق في العالم حين أنجزت ما لم يُنجزه أحد على هذا النطاق: إهباط المرحلة الأولى من صاروخ مداري وإعادة استخدامها، مما أسقط تكلفة الوصول إلى الفضاء. هذه الميزة في التكلفة هي المحرك الجوهري لكل شيء آخر. فالإطلاق الرخيص والمتكرر والموثوق هو ما يجعل تشييد كوكبة تضم أكثر من 7000 قمر اصطناعي ممكنًا اقتصاديًا — وهذه الكوكبة بدورها هي ما يحوّل أعمال الإطلاق المتقطعة القائمة على المشاريع إلى أعمال ذات إيرادات متكررة. ## كيف تجني SpaceX أموالها؟ ### 1. خدمات الإطلاق العمل الأصلي للشركة. تبيع SpaceX عمليات الإطلاق لثلاثة أنواع من العملاء: - **مشغّلو الأقمار الاصطناعية التجارية** — تدفع الشركات التي تحتاج حمولة في المدار مقابل إطلاق مخصص، أو مقعدًا في مهمة **ركوب مشترك** (أقمار اصطناعية صغيرة متعددة على صاروخ واحد، بتسعير بالكيلوغرام). - **الحكومات والجيوش** — حمولات الأمن القومي والبعثات العلمية، وغالبًا بعلاوة لقاء الموثوقية والضمانات. - **شركات الفضاء الأخرى** — بما فيها المنافسون المتزايدون الذين لا يزالون يعتمدون على SpaceX لكونها أرخص خيار وأكثره توافرًا. تعمل الاقتصاديات وحدة الإنتاج بفضل **إعادة الاستخدام**: إذ يُحلّق المعزز ذاته (المرحلة الأولى) مرات عديدة، ما يجعل التكلفة الهامشية لعملية الإطلاق أدنى بكثير من سعرها. Falcon 9 هو الصاروخ العامل الأساسي، بينما يتولى Falcon Heavy الحمولات الأثقل. ### 2. Starlink (آلة الإيرادات المتكررة) Starlink كوكبة من آلاف الأقمار الاصطناعية في المدار الأرضي المنخفض، توصّل الإنترنت عالي السرعة إلى الأماكن التي لا يطالها النطاق العريض الأرضي أو لا يخدمها. إنه الآن الجزء من SpaceX الذي يشبه نموذج الاشتراك الحقيقي، بطبقات متعددة: - **المستهلكون** — تدفع الأسر مقابل طبق استقبال (عتاد) واشتراك شهري. - **الشركات والتنقل** — خطط مرتفعة السعر للأعمال، والقطاع البحري (السفن، اليخوت)، و**الطيران** (صفقات شبكة Wi-Fi على متن الطائرات مع شركات الطيران). - **الحكومات** — بما يشمل **Starshield**، المتغير الموجّه للدفاع والمباع للعملاء العسكريين والحكوميين. - **الاتصال المباشر بالهواتف** — شراكات مع شركات الاتصالات المحمولة لتوفير اتصال فضائي مباشر للهواتف العادية في مناطق انعدام التغطية. يجمع Starlink بين مبيعات الأجهزة (الطرفية) والإيرادات الشهرية المتكررة (الاشتراكات) عبر ملايين المشتركين — النموذج الكلاسيكي للشفرة والنصال على النطاق الكوني. لهذا تضع معظم التقديرات الآن Starlink في المرتبة الأولى تجاوزًا لخدمات الإطلاق بوصفه أكبر مصادر إيرادات SpaceX. ### 3. العقود الحكومية قطاع مستقل وكبير جدًا يتداخل مع الإطلاق، غير أنه جدير بالتناول منفردًا: - **NASA** — تنقل SpaceX رواد الفضاء إلى محطة الفضاء الدولية في إطار برنامج **Commercial Crew** (Crew Dragon)، وتزودها بالإمدادات عبر **Cargo Dragon**. كما فازت بعقد لبناء نظام هبوط بشري على سطح القمر يعتمد على **Starship** لدعم طموحات NASA القمرية. - **الأمن القومي** — عقود إطلاق دورية لحمولات الدفاع والاستخبارات. هذه العقود ذات قيمة عالية ومتعددة السنوات، وتمول قدرًا كبيرًا من التطوير الذي ينتفع به القطاع التجاري. ### 4. Starship (محرك المستقبل، وليس مركز ربح بعد) Starship هو صاروخ SpaceX القابل للاستخدام الكامل والرافعة الفائقة الثقيلة — البديل طويل الأمد لـ Falcon، والمفتاح لمهمات القمر/المريخ والجيل القادم الأكبر من أقمار Starlink الاصطناعية. اليوم هو مركز تكاليف تموله الأعمال الثلاثة الأخرى. إذا بلغ مرحلة الرحلات المنتظمة، فسيخفض تكاليف الإطلاق مرة أخرى بصورة جذرية ويتيح نشرًا أوسع بكثير لـ Starlink — وهذا هو الرهان الذي يضعه المستثمرون فعلاً. ## هل SpaceX مربحة؟ SpaceX شركة خاصة لا تنشر بيانات مالية مدققة، لذا فأي رقم دقيق لا يعدو كونه تقديرًا. الصورة المتداولة على نطاق واسع: الإطلاق مربح بحساب كل مهمة بفضل إعادة الاستخدام، وعبر Starlink حد التدفق النقدي الإيجابي مع توسع قاعدة مشتركيه. تعيد الشركة ضخ مبالغ طائلة في تطوير Starship، لذا يتوقف مفهوم «الربح» إلى حد بعيد على كيفية معالجة نفقات البحث والتطوير تلك. اتجاه السير — إيرادات Starlink المتكررة المتنامية فوق أعمال إطلاق مهيمنة — هو ما يسند التقييم الضخم للشركة في السوق الخاصة. ## سؤال الاكتتاب العام هذا الجزء الذي يسأل عنه الجميع، فإليك النسخة الصريحة. **لا يُتوقع أن تطرح SpaceX نفسها للاكتتاب العام قريبًا.** صرّح Elon Musk مرارًا بأنه يُفضّل إبقاء SpaceX خاصة في حين تكون مرحلة Starship وبرنامج المريخ كثيفة رأس المال وطويلة الأمد — فضغط الأسواق العامة الفصلي لا يلائم مهمة تمتد عقودًا. عوضًا عن ذلك، توفر SpaceX سيولة للموظفين والمستثمرين الأوائل عبر **عروض شراء دورية** (تيسّر الشركة بيع الأسهم بسعر محدد)، مما يتيح لهم الخروج بأموالهم دون إدراج عام. هذه المبيعات الثانوية هي ما يُنتج أرقام التقييم التي تتصدر العناوين — إذ قُدّرت قيمة SpaceX بمئات المليارات من الدولارات في جولات التمويل الأخيرة. **طرح Starlink مستقلاً مطروح للنقاش منذ زمن بعيد** — أشار Musk نفسه قبل سنوات إلى أن Starlink قد يطرح للاكتتاب العام في نهاية المطاف متى أصبحت إيراداته مستقرة ويمكن التنبؤ بها. بيد أنه أطفأ التوقعات المتعلقة بتواريخ قريبة مرات عديدة. حتى عام 2026، لم يطرح Starlink للاكتتاب، ولا تاريخ مؤكد. تعامل مع أي عنوان يتحدث عن «موعد اكتتاب Starlink» بتشكيك ما لم يصدر عن الشركة مباشرة. ## خلاصة القول نموذج SpaceX بناء متراكم: الإطلاق القابل لإعادة الاستخدام يُشيّد خندق التكلفة، وهذا الخندق يجعل Starlink ممكنًا اقتصاديًا، وStarlink يحوّل المنظومة كلها إلى أعمال ذات إيرادات متكررة، والعقود الحكومية تموّل العمل الرائد (Starship) الذي يُعيد ضبط منحنى التكاليف من جديد. تُبقي الشركة طابعها الخاص عن سابق إصرار وتصميم، وتستعيض عن الاكتتاب بعروض الشراء — والطريق الأرجح إلى الأسواق العامة هو إدراج Starlink مستقبلًا لا SpaceX بمجموعها، متى رأت الشركة أن الوقت قد حان. ## نموذج إيرادات SpaceX — الأسئلة الشائعة لعام 2026 ### ما أكبر مصدر لإيرادات SpaceX؟ تضع معظم التقديرات **Starlink** في الصدارة متجاوزًا خدمات الإطلاق بوصفه أكبر مصادر الإيرادات، مدفوعًا بملايين الاشتراكات للأفراد والمؤسسات والتنقل والحكومات، إضافة إلى مبيعات الأجهزة الطرفية. تبقى خدمات الإطلاق ضخمة ومربحة جدًا بحساب كل مهمة، غير أن نموذج Starlink المتكرر يتوسع بوتيرة أسرع. ### هل تُدرَج أسهم SpaceX في البورصة؟ هل بإمكاني شراء أسهمها؟ لا. SpaceX شركة خاصة وأسهمها غير متاحة في أسواق الأوراق المالية العامة. لا يستطيع معظم الناس الاستثمار مباشرةً؛ إذ يقتصر الوصول عمومًا على الموظفين والمستثمرين المعتمدين المشاركين في جولات خاصة أو عروض شراء. كن متيقظًا من عروض «أسهم SpaceX» التي توحي بخلاف ذلك. ### هل ستطرح SpaceX أو Starlink اكتتابًا عامًا؟ لا يُتوقع أن تدخل SpaceX البورصة في المدى القريب — فقد أعلن Musk أنه يريدها خاصة طوال المرحلة كثيفة رأس المال المتعلقة بـ Starship والمريخ. اكتتاب **Starlink** يُناقَش منذ سنوات بوصفه احتمالًا حين تصبح إيراداته قابلة للتنبؤ، لكن حتى عام 2026 لا يوجد تاريخ مؤكد. ينبغي التعامل بتشكيك مع أي ادعاء بـ «موعد اكتتاب» محدد ما لم يصدر عن الشركة. ### كيف يجني Starlink أمواله؟ يُحصّل Starlink من عملائه ثمن طبق استقبال الأقمار الاصطناعية (عتاد) واشتراكًا شهريًا، عبر مستويات للأفراد والأعمال والبحرية والطيران والحكومات — بما يشمل Starshield الموجّه للدفاع وشراكات الاتصال المباشر بالهواتف. إنه نموذج الشفرة والنصال: عتاد مقدمًا، إيرادات متكررة لاحقًا. ### كيف تُعين إعادة الاستخدام أرباح SpaceX؟ إهباط المعزز ذاته وإعادة تحليقه مرات عديدة يُخفّض التكلفة الهامشية لكل إطلاق إلى ما هو أدنى بكثير من السعر المُحصَّل. هذه الميزة في التكلفة هي ما يجعل SpaceX المزوّد الأرخص للإطلاق، وما يجعل نشر كوكبة Starlink المؤلفة من آلاف الأقمار الاصطناعية جدوى اقتصادية. **مقالات ذات صلة:** [كيف تجني Uber أموالها](https://alejandrorioja.com/how-does-uber-make-money/) · [كيف تجني Shopify أموالها](https://alejandrorioja.com/how-shopify-makes-money/) · [كيف تجني PayPal أموالها](https://alejandrorioja.com/how-does-paypal-make-money/) --- ## النسخة المختصرة تبيع SpaceX مقاعد مدارية بأسعار منخفضة لأنها تُعيد استخدام صواريخها، ثم توظّف هذه الميزة في التكلفة لتشغيل Starlink — أعمال الاشتراك في الإنترنت عبر الأقمار الاصطناعية التي باتت أكبر مصادر إيراداتها — فيما تموّل العقود الحكومية Starship من الجيل القادم. تظل الشركة خاصة عن عمد، وطرح Starlink للاكتتاب — لا SpaceX بكاملها — هو المسار الأرجح في نهاية المطاف إلى الأسواق العامة. --- ## كيفية استخدام المهام المجدولة في Claude: أتمتة الأعمال المتكررة باستخدام cron Source: https://alejandrorioja.com/ar/how-to-use-claude-scheduled-tasks/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: تحوّل المهام المجدولة موجّهاً منفرداً في Claude إلى عمل متكرر: يُطلَق وفق جدول زمني بأسلوب cron، ويُنجز المهمة ويُسلّم النتيجة. استخدم تطبيق Claude للموجّهات الشخصية المتكررة (ملخص صباحي، تلخيص أسبوعي)، وروتينات Claude Code أو نشرات Managed Agents للأتمتة البرمجية التي تعمل في السحابة. تكمن الفائدة في أتمتة العمل الذي كنت ستُنجزه يدوياً كل يوم أو كل أسبوع. ## Table of contents _محدّث يونيو 2026._ **TL;DR:** تحوّل المهام المجدولة موجّهاً منفرداً في Claude إلى عمل متكرر: يُطلَق وفق جدول زمني بأسلوب cron، ويُنجز المهمة ويُسلّم النتيجة. استخدم **تطبيق Claude** للموجّهات الشخصية المتكررة (ملخص صباحي، تلخيص أسبوعي)، و**روتينات Claude Code** أو **نشرات Managed Agents** للأتمتة البرمجية التي تعمل في السحابة. تكمن الفائدة في أتمتة العمل الذي كنت ستُعيد إنجازه يدوياً كل يوم أو كل أسبوع. **[للمشغّلين]** الأتمتة الأعلى تأثيراً ليست بالضرورة مبهرة — بل هي المهام الصغيرة المتكررة التي تسرق منك عشرين دقيقة يومياً في صمت. المهمة المجدولة هي الطريقة لتسليم تلك المهام إلى Claude مرة واحدة وعدم التفكير فيها أبداً. أُشغّل عدة مهام كهذه: فحص صباحي للمنافسين، ومراجعة ليلية لحالة طلبات السحب، ومسودة أسبوعية لخط أنابيب المحتوى. لم تستغرق أيٌّ منها أكثر من عشر دقائق للإعداد. ## ما هي المهمة المجدولة جلسة Claude العادية متزامنة: تكتب فتستجيب، وأنت حاضر. أما **المهمة المجدولة** فهي غير متزامنة ومتكررة: تُعرّف موجّهاً (أو سير عمل وكيل كامل) مع جدول زمني، ويُشغّل Claude المهمة باستقلالية — في السابعة صباحاً كل يوم عمل، كل اثنين، كل ساعة — ثم يُسلّمك النتيجة عند الانتهاء. تحت الغطاء، يتعلق الأمر بمهمة cron يتمركز فيها نموذج لغوي كبير. لا تكتب كوداً لربط واجهات برمجية ببعضها؛ بل تصف النتيجة بلغة طبيعية وتترك الوكيل يستنتج الخطوات في كل مرة يُطلَق فيها. ## الأماكن الثلاثة التي ستُعدّها فيها لا يوجد زر واحد — ثمة ثلاث واجهات، تتلاءم مع طبيعة المستخدم. ### 1. تطبيق Claude (للجميع) تدعم تطبيقات Claude للمستهلكين المهام المتكررة: تحفظ موجّهاً وإيقاعاً زمنياً، ويُشغّل Claude المهمة وفق الجدول ويُخطرك بالنتيجة. هذا هو مسار بدون كود — مثالي لإحاطة يومية، أو بحث دوري، أو مهمة "لخّص رسائلي الإخبارية غير المقروءة كل صباح". إن لم تكن مطوّراً، ابدأ من هنا. ### 2. روتينات Claude Code (لمحبّي الطرفية) إن كنت تستخدم **Claude Code**، يمكنك جدولة موجّه أو أمر شرطة كي يعمل وفق إيقاع cron بوصفه وكيلاً سحابياً — "روتيناً". يعمل على الخادم ضمن مستودعك أو مساحة عملك، فيشتغل حتى حين يكون حاسوبك المحمول مغلقاً. استخدامات نموذجية: مراقبة طلبات السحب المفتوحة، تشغيل جولة lint وإصلاح ليلية، إنشاء مسودة منشور كل صباح للمراجعة. تُعرّف الجدول والمهمة، ويتولى Claude Code الإطلاق وسجلات التشغيل. ### 3. نشرات Managed Agents (للمطوّرين الذين يبنون منتجات) للفرق التي تبني على Claude API، تُشغّل **النشرات المجدولة** وكيلاً وفق جدول cron متكرر — كل إطلاق يُنشئ جلسة تُنجز العمل باستقلالية (فحص امتثال ليلي، تقرير أسبوعي، مراقبة ساعية). تحصل على سجل تشغيل لكل إطلاق لمراجعة النجاحات والإخفاقات. هذا هو الإصدار البرمجي على مستوى الإنتاج من الفكرة ذاتها. ## كيف تفكر في الجدول الزمني تشترك الأنواع الثلاثة في النموذج الذهني نفسه — **ما المهمة، وما تكرارها، وماذا تفعل بالمخرجات**: 1. **المهمة** — اكتبها كما تكتب أي موجّه وكيل جيد: الدور، والسياق، والإجراء الدقيق، والقيود، والتحقق. لا تستطيع المهمة المجدولة طرح سؤال توضيحي في منتصف التشغيل، لذا يجب أن تكون *محددة بالكامل مسبقاً*. هذا هو الفارق الجوهري الوحيد عن الاستخدام التفاعلي. 2. **الإيقاع** — يومي، أسبوعي، ساعي، أيام عمل فقط، توقيت محدد في منطقتك الزمنية. اجعله يتوافق مع مدى سرعة تغير الشيء المعني فعلياً؛ ملخص "يومي" لمصدر يُحدَّث أسبوعياً يعني تشغيلات مهدرة. 3. **التسليم** — أين تصل النتيجة (إشعار، ملف، رسالة، مسودة). قرّر ذلك مسبقاً كي تكون المخرجات مفيدة لحظة وصولها. ## الأنماط التي تستحق الاستخدام فعلاً - **الملخص الصباحي.** "كل يوم عمل في السابعة صباحاً، اجلب آخر المستجدات حول [الموضوعات]، لخّص الأمور الثلاث المهمة، وأرسل لي إحاطة من 5 نقاط." يُغني عن عشرين دقيقة من المسح اليدوي. - **التقرير الأسبوعي.** "كل اثنين، اجمع [المقاييس] في ملخص من صفحة واحدة مع ما تغيّر ولماذا." يُحوّل مهمة متكررة مملة إلى مراجعة. - **العامل الليلي.** روتين برمجي يُشغّل مهمة طويلة ومحددة جيداً أثناء نومك — إعادة بناء كود، جولة اختبارات، تنظيف بيانات — فتستيقظ على نتيجة جاهزة للمراجعة. - **المراقب.** "كل ساعة، تحقق من [الشيء]؛ راسلني فقط إن كان [الشرط] صحيحاً." أفضل الأتمتة تبقى صامتة في معظمها ولا تتكلم إلا حين يهم الأمر. ## نصائح الإعداد من التشغيل الفعلي في الإنتاج - **أفرط في تحديد الموجّه.** لا يمكن طرح أسئلة توضيحية في منتصف التشغيل. حدد الشكل والمصادر والقيود وما يجب فعله في الحالات الاستثنائية. - **ابدأ باختبار يدوي.** شغّل الموجّه تماماً يدوياً مرة واحدة. إن أنتج ما تريده تفاعلياً، فجدوله. وإن لم يفعل، أصلح الموجّه أولاً — جدولة موجّه سيئ تُنتج مخرجات سيئة بشكل موثوق فحسب. - **وافق الإيقاع مع معدل التغيير.** لا تُشغّل شيئاً ساعياً مقابل شيء يُحدَّث أسبوعياً. - **احتفظ بالمخرجات كمسودات حين تكون المخاطر عالية.** لأي شيء يخرج للعالم — منشور مُنشر، بريد إلكتروني مُرسل — اجعل المهمة تُنتج *مسودة* لمراجعتك بدلاً من إجراء مباشر. احتفظ بـ"افعل فحسب" المستقل تماماً للأعمال منخفضة المخاطر القابلة للتراجع. - **راقب أول تشغيلات.** المهام المجدولة تنحرف — مصدر يغيّر تنسيقه، خلاصة تصمت. راجع سجلات التشغيل المبكرة، ثم ثق بها. ## المهام المجدولة في Claude — الأسئلة الشائعة لعام 2026 ### ما هي المهام المجدولة في Claude؟ هي أعمال متكررة: تُعرّف موجّهاً أو سير عمل وكيل مع جدول بأسلوب cron، ويُشغّل Claude المهمة تلقائياً — يومياً، أسبوعياً، ساعياً — مُسلّماً النتيجة دون حاجتك للجلوس أمام لوحة المفاتيح. توجد في تطبيقات Claude للمستهلكين (للموجّهات الشخصية المتكررة)، وفي Claude Code (كروتينات سحابية)، وفي Claude API (كنشرات Managed Agents). ### هل أحتاج إلى أن أكون مطوّراً لاستخدامها؟ لا. يدعم تطبيق Claude المهام المتكررة دون كود — فقط موجّه محفوظ وإيقاع زمني. روتينات Claude Code ونشرات Managed Agents هي الإصدارات الموجّهة للمطوّرين لأتمتة سير عمل البرمجة والمنتجات. ### كيف تختلف المهمة المجدولة عن محادثة Claude العادية؟ المحادثة العادية تفاعلية — أنت هناك للرد على الأسئلة المتابِعة. المهمة المجدولة مستقلة ومتكررة، لذا يجب أن يكون الموجّه محدداً بالكامل مسبقاً؛ لا يستطيع Claude التوقف ليسألك سؤالاً في منتصف التشغيل. تُطلَق وفق الجدول، وتُكمل العمل، وتُسلّمك النتيجة. ### ما هي أول مهمة مجدولة جيدة لتبدأ بها؟ ملخص صباحي. "كل يوم عمل في السابعة صباحاً، لخّص آخر المستجدات حول [موضوعاتك] في خمس نقاط." منخفض المخاطر، سهل التحقق منه، ويستبدل على الفور مهمة يدوية متكررة — النموذج المثالي لتعلم سير العمل قبل أتمتة شيء أكبر. ### هل يمكن للمهمة المجدولة اتخاذ إجراءات فعلية كإرسال رسائل بريد إلكتروني؟ نعم، لكن كن متعمداً. للأعمال القابلة للتراجع ومنخفضة المخاطر، دعها تتصرف. لأي شيء موجّه للخارج أو يصعب التراجع عنه، اجعل المهمة تُنتج مسودة لموافقتك بدلاً من الإطلاق التلقائي — لا سيما في التشغيلات غير المراقَبة. القدرة على التراجع هي الاختبار الصحيح لتحديد مقدار الاستقلالية الممنوحة. **قراءة ذات صلة:** [الدليل المبتدئ للوكلاء الذكيين](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [كيف تجني Anthropic أموالها](https://alejandrorioja.com/how-does-anthropic-make-money/) · [كيف تُقتبس في إجابات ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- **تريد نظاماً من الوكلاء المجدولين يُدير أعمالك المتكررة؟** هذا تحديداً ما أبنيه — [تواصل معي](https://alejandrorioja.com/contact/). --- ## حسابات تكلفة وكلاء الذكاء الاصطناعي: متى يتفوق Haiku على Sonnet (ومتى لا) Source: https://alejandrorioja.com/ar/ai-agent-cost-math-when-haiku-beats-sonnet/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: اختيار Claude Haiku بدلاً من Sonnet قد يخفض تكلفة الاستدعاء الواحد بشكل كبير، لكن فقط عندما تتحمّل المهمة معدل نجاح أقل. المقياس الحقيقي ليس التكلفة لكل استدعاء — بل التكلفة لكل نتيجة ناجحة، شاملةً المحاولات المتكررة والتصحيح البشري. أنا أوجّه حسب المهمة، لا حسب الإعداد الافتراضي. ## جدول المحتويات _محدّث يونيو 2026._ **باختصار:** اختيار Claude Haiku بدلاً من Sonnet قد يخفض تكلفة الاستدعاء الواحد بمقدار رتبة كاملة، لكن فقط عندما تتحمّل المهمة معدل نجاح Haiku الأقل. المقياس المهم هو **التكلفة لكل نتيجة ناجحة** — تكلفة الاستدعاء زائد المحاولات المتكررة زائد التصحيح البشري — وليس السعر المعلن لكل token. أنا أوجّه حسب المهمة، وحصة معتبرة من خطواتي عالية الحجم تعمل على Haiku بينما تبقى قرارات التقدير على Sonnet. **قراءة المُشغّل:** أُدير أكثر من 100 وكيل، والاستدلال بند تكلفة حقيقي. لكنني رأيت فرقاً «توفّر المال» بإجبار كل شيء على أرخص نموذج ثم تدفع الثمن في المحاولات المتكررة والتصعيدات والعملاء الغاضبين. حسابات التكلفة لا تنجح إلا حين تقيس القمع بأكمله. النموذج الأرخص ليس صاحب أدنى سعر لكل token. بل صاحب أدنى تكلفة إجمالية لإنجاز العمل بشكل صحيح. هذان رقمان مختلفان، والفجوة بينهما هي بالضبط حيث تخطئ معظم قرارات تكلفة الوكلاء. ## اقتصاد الـtokens، بوضوح تسعّر Anthropic نموذج Claude لكل مليون token، مع احتساب المدخلات والمخرجات بشكل منفصل، وتكلفة المخرجات أعلى بعدة أضعاف من المدخلات. تتغيّر الأرقام الدقيقة بمرور الوقت، لذا راجع أسعار Anthropic الحالية — لكن **البنية** هي ما يحرّك القرار: - **Haiku** هو المستوى الرخيص والسريع — أدنى تكلفة لكل token في العائلة بفارق كبير. - **Sonnet** يقع في المنتصف — أغلى بوضوح من Haiku، وأرخص بوضوح من Opus. - **Opus** هو المستوى الفاخر لأصعب أنواع الاستدلال. يترتب على ذلك أمران. أولاً، تهيمن tokens المخرجات على التكلفة في المهام التوليدية، لذا فإن النموذج المُطنب يكلّف أكثر حتى عند نفس السعر لكل token. ثانياً، الفجوة في السعر لكل token بين Haiku وSonnet كبيرة بما يكفي لتظهر بالتأكيد على الفاتورة في خطوة عالية الحجم. هذه هي الحجة *لصالح* Haiku. والآن الحجة ضده. ## المقياس الذي يهم فعلاً: التكلفة لكل نتيجة ناجحة التكلفة لكل استدعاء رقم استعراضي. إليك الصيغة التي أستخدمها فعلاً: ``` التكلفة_لكل_نجاح = (تكلفة_الاستدعاء × المحاولات) + تكلفة_التصحيح ÷ معدل_النجاح ``` حيث تحتسب `المحاولات` المحاولات المتكررة، و`تكلفة_التصحيح` هي التكلفة المتوقعة لإصلاح بشري للإخفاقات التي تتسرب. انظر ماذا يفعل هذا بالمقارنة. لنفترض أن Haiku يكلّف نحو عُشر تكلفة Sonnet لكل استدعاء. إذا نجح Haiku في 80% من الحالات في مهمة ونجح Sonnet في 98%، تبدو الوفورات لكل استدعاء هائلة. لكن إذا أطلق كل إخفاق من Haiku محاولة متكررة وظل 1 من كل 10 يحتاج إلى إنسان يكلّف مالاً حقيقياً، فقد يبتلع حدّ التصحيح وفورات الـtokens. في مهمة منخفضة المخاطر عالية الحجم، تميل الحسابات لصالح Haiku بشكل ساحق. وفي مهمة يُرسل فيها الإخفاق بريداً إلكترونياً إلى العميل الخطأ، قد ينقلب الأمر تماماً. لا يمكنك اتخاذ هذا القرار دون قياس معدل النجاح لكل نموذج — وهو بالضبط ما يمنحه لك [إطار التقييم](/the-eval-harness-i-use-to-ship-ai-agents/). شغّل مجموعة التقييم نفسها على كلا النموذجين واقرأ معدلات النجاح بالمقياس ذاته. ## أين يفوز Haiku بشكل حاسم Haiku هو الخيار الصحيح عندما تكون المهمة **ضيّقة ومنظّمة وقابلة للتحقق**: - **التصنيف والتوجيه** — «هل هذه الرسالة الواردة حجز أم شكوى أم بريد مزعج؟» ثلاث فئات، سهلة التحقق، تعمل باستمرار. Haiku طوال اليوم. - **الاستخراج وفق مخطط** — انتزاع تاريخ أو اسم أو مبلغ من نص، مع التحقق باستخدام Zod. إذا تمّ تحليل المخرجات، فهي صحيحة بشكل شبه مؤكد. - **إعادات الصياغة القصيرة والتنسيق** — تعديلات النبرة، وتلخيص مُدخل معروف الجودة، وتطبيع البيانات. - **التصفية في المرور الأول** — يقوم Haiku بالفرز، وتُصعَّد الحالات الغامضة وحدها إلى Sonnet. هذا هو النمط الأعلى رافعة. الخيط المشترك: تكلفة خطأ Haiku منخفضة والخطأ رخيص الالتقاط. حين يكون التحقق رخيصاً والمخاطر منخفضة، يفوز النموذج الرخيص. ## أين يستحق Sonnet سعره يستحق Sonnet (وأحياناً Opus) قيمته عندما تكون المهمة **مفتوحة أو متعددة الخطوات أو مكلفة عند الخطأ**: - **حلقات الوكيل متعددة الأدوات** حيث يتسبب استدعاء أداة خاطئ في سلسلة متتالية. تتراكم موثوقية الاستدلال الأعلى عبر الخطوات — أنماط التنسيق التي أتناولها في [تنسيق الوكلاء المتعددين](/multi-agent-orchestration-patterns-queues-state-handoffs/) تعتمد على ألّا يفقد النموذج خيط المهمة. - **التوليد المواجِه للعميل** حيث يكلّف المُخرج السيئ ثقةً، لا مجرد محاولة متكررة. - **أي شيء يكون فيه التحقق نفسه صعباً.** إذا لم تستطع أن تعرف بثمن زهيد ما إذا كان المُخرج صحيحاً، فلا يمكنك تحمّل نموذج يخطئ كثيراً. الإخفاق هنا لا يكلّف محاولة متكررة — بل يكلّف استرداداً للأموال، أو عميلاً مفقوداً، أو وقتي. وفي مقابل ذلك، فإن العلاوة لكل token خطأ تقريبي لا يُذكر. ## قاعدة التوجيه التي أطبّقها فعلاً لا أختار نموذجاً واحداً لكل وكيل. أوجّه حسب **المهمة** داخل الوكيل، عادةً بمصنّف رخيص يقرّر أي نموذج لاحق يتولّى العمل: ```typescript function pickModel(task: Task): string { // رخيص وقابل للتحقق وعالي الحجم ← Haiku if (task.type === "classify" || task.type === "extract") { return "claude-haiku"; } // مفتوح أو مواجِه للعميل ← Sonnet if (task.customerFacing || task.steps > 2) { return "claude-sonnet"; } return "claude-sonnet"; // الإعداد الافتراضي هو الخيار الآمن } ``` مبدآن مُرمَّزان هنا. **اجعل الافتراضي هو النموذج الآمن**، لا الرخيص — أنت تحسّن التكلفة *نزولاً* من خط أساس يعمل، لا الموثوقية *صعوداً* من خط معطوب. و**صعّد، لا تقامر**: دع Haiku يتولّى الـ80% السهلة وسلّم الـ20% الصعبة إلى Sonnet. هذا المزيج يتفوق دائماً تقريباً على تشغيل كل شيء على أي من النموذجين منفرداً. هناك أيضاً تخزين الـprompt مؤقتاً لإضافته فوق ذلك: إذا كان prompt النظام لديك كبيراً ويُعاد استخدامه، فإن التخزين المؤقت يخفض تكلفة المدخلات بشكل كبير بصرف النظر عن المستوى، مما يجعل Sonnet أحياناً رخيصاً بما يكفي ليصبح سؤال Haiku بلا معنى. ## مثال محلول من بنيتي الخاصة خذ خطوة فرز الرسائل الواردة عالية الحجم. تعمل آلاف المرات، والمهمة تصنيف ثلاثي الاتجاهات، والإخفاق يعني فقط أن العنصر يهبط في طابور مراجعة — رخيص الالتقاط، منخفض المخاطر. هذه مهمة Haiku نموذجية، ونقلها من Sonnet خفّض تكلفة تلك الخطوة بشكل ملموس دون أثر قابل للقياس على النتيجة التي تهم. والآن خذ الخطوة التي تصوغ الرد الفعلي للعميل. حجم أقل، ومفتوحة، ومسودة سيئة تخرج تكلّف ثقةً. تلك تبقى على Sonnet. الوكيل نفسه، نموذجان، موجَّهان حسب المخاطر. أراقب التكلفة لكل تشغيل ومقاييس النجاح لكليهما، بالطريقة التي أصفها في [كيف أقيس ما إذا كان وكيل الذكاء الاصطناعي يعمل فعلاً](/how-i-measure-whether-an-ai-agent-is-actually-working/) — ولا أنزل بخطوة إلى مستوى أدنى إلا بعد أن يقول التقييم إن النموذج الأرخص يحافظ على معدل النجاح. ## الأسئلة الشائعة ### هل Claude Haiku أرخص دائماً من Sonnet عملياً؟ لكل token، نعم — بفارق كبير. لكل نتيجة ناجحة، ليس دائماً. إذا أطلق معدل نجاح Haiku الأقل محاولات متكررة وتصحيحاً بشرياً، فقد تتجاوز التكلفة الإجمالية تكلفة Sonnet في المهام التي يكون فيها التقاط الأخطاء أو إصلاحها مكلفاً. ### كيف أقرّر بين Haiku وSonnet لمهمة معيّنة؟ قيّم المهمة على محورين: مدى قابلية التحقق من المُخرج، ومدى تكلفة الخطأ. العمل الرخيص التحقق، منخفض المخاطر، عالي الحجم يذهب إلى Haiku؛ والعمل المفتوح، المواجِه للعميل، أو الصعب التحقق يذهب إلى Sonnet. وجّه حسب المهمة، لا حسب الوكيل. ### ما المقياس الوحيد للتكلفة الذي ينبغي أن أتتبعه؟ التكلفة لكل نتيجة ناجحة — تكلفة الاستدعاء مضروبة في المحاولات زائد تكلفة التصحيح المتوقعة، مقسومة على معدل النجاح. السعر لكل استدعاء وحده يخفي المحاولات المتكررة والوقت البشري، وهناك تصبح النماذج الرخيصة مكلفة دون أن تلاحظ. ### هل يمكنني استخدام كلا النموذجين في وكيل واحد؟ نعم، وغالباً يجب عليك ذلك. أقوى نمط هو مرور أول رخيص (يصنّف Haiku أو يصفّي) يصعّد الحالات الغامضة وحدها إلى Sonnet. هذا المزيج يتفوق عادةً على تشغيل كل شيء على مستوى واحد. --- ## كيفية تصحيح أخطاء وكيل ذكاء اصطناعي في الإنتاج (دليل ميداني) Source: https://alejandrorioja.com/ar/how-to-debug-an-ai-agent-in-production/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: تصحيح أخطاء وكيل ذكاء اصطناعي في الإنتاج يتعلق في معظمه بعزل الطبقة التي فشلت — الموجِّه أو الأداة أو النموذج أو التنسيق. أسجّل كل خطوة بمعرّف تتبّع، وأعيد تشغيل المدخلات نفسها بالضبط، ثم أقسّم. في وكلائي، نحو 70% من 'أخطاء الذكاء الاصطناعي' تتبيّن أنها أخطاء سباكة، لا أخطاء نموذج. ## جدول المحتويات _محدّث يونيو 2026._ **الخلاصة:** تصحيح أخطاء وكيل ذكاء اصطناعي في الإنتاج يتعلق في معظمه بعزل الطبقة التي فشلت — الموجِّه، أو استدعاء الأداة، أو مُخرَج النموذج، أو التنسيق. أسجّل كل خطوة بمعرّف تتبّع، وأعيد تشغيل المدخلات نفسها بالضبط، ثم أقسّم انطلاقًا من هناك. في وكلائي، نحو 70% مما يبدو "خطأ ذكاء اصطناعي" يتبيّن أنه سباكة: نتيجة أداة مشوّهة، أو مدخل مقتطع، أو استثناء ابتُلِع بصمت. **قراءة المُشغّل:** أُشغّل أكثر من 100 وكيل في الإنتاج — تدفقات حجز لـ Pickleland، وخطوط أنابيب محتوى، ومُصنّفات صندوق وارد. تتعطّل كما يتعطّل أي برنامج، إضافة إلى بضع طرق جديدة. هذا هو الدليل الميداني الذي كنت أتمنى لو امتلكته: كيف تجد الطبقة المعطلة دون التحديق في جدار من الرموز (tokens). عندما يسيء وكيل التصرّف في الإنتاج، تكون الغريزة هي إلقاء اللوم على النموذج. "Claude هلوس." أحيانًا يكون ذلك صحيحًا. عادةً لا. النموذج طبقة واحدة في كومة من خمس أو ست طبقات، والخطأ يكون أكثر بكثير في الطبقة التي كتبتها أنت من الطبقة التي شحنتها Anthropic. هذه المقالة هي الطريقة المنهجية التي أجده بها. ## اجعل كل تشغيلة قابلة للتتبّع قبل أن تصحّح أي شيء لا يمكنك تصحيح ما لا تستطيع رؤيته. أعلى شيء ذي قيمة يمكنك فعله — قبل ظهور أي خطأ محدد — هو إرفاق معرّف تتبّع بكل تشغيلة للوكيل وتسجيل كل خطوة يخطوها. "الخطوة" هي أي شيء يعبر حدًّا: المُحفِّز الوارد، وكل استدعاء للنموذج (مع مصفوفة الرسائل الكاملة)، وكل استدعاء أداة (مع الوسائط)، وكل نتيجة أداة، والمُخرَج النهائي. سجّلها كـ JSON منظَّم مُفهرَس بمعرّف التتبّع. ```typescript function logStep(traceId: string, step: string, payload: unknown) { console.log(JSON.stringify({ traceId, step, // "trigger" | "model_call" | "tool_call" | "tool_result" | "output" ts: Date.now(), payload, })); } ``` على Cloudflare Workers أرسلها إلى طابور وإلى جدول؛ ومحليًّا تذهب إلى stdout. القاعدة مطلقة: إذا لم تُسجَّل خطوة، فهي لم تحدث بقدر ما يتعلق الأمر بالتصحيح. هذا يعكس الأدوات التي أصفها في [حزمة الوكلاء التي أستخدمها](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) — معرّف التتبّع هو العمود الفقري الذي يتعلّق به كل شيء آخر. ## اعزل الطبقة: الموجِّه أو الأداة أو النموذج أو التنسيق بمجرد أن يكون لديك تتبّع، يصبح التصحيح تقسيمًا ثنائيًّا. هناك أربع طبقات، والخطأ يعيش في واحدة منها بالضبط في معظم الأحيان. ### 1. طبقة المدخلات (المتهم الأكثر شيوعًا) اسحب مصفوفة `messages` نفسها بالضبط التي دخلت في استدعاء النموذج الفاشل. ليست إعادة بناء — بل الحمولة الحرفية من السجل. ثم اقرأها كما يقرأها غريب. نصف أخطائي من نوع "تجاهل النموذج التعليمات" هي في الواقع: - نتيجة أداة عادت كـ `"[object Object]"` لأن شيئًا ما حُوّل إلى نص بشكل خاطئ. - مدخل مقتطع في منتصف الجملة لأنه فجّر نافذة السياق وقطعه تقطيع ساذج. - متغيّر أُدرِج كـ `undefined` وسمّم الموجِّه بصمت. إذا كان المدخل خاطئًا، فقد أدى النموذج عمله بإتقان على قمامة. أصلح السباكة. ### 2. طبقة الأدوات إذا بدا المدخل نظيفًا، تحقق مما إذا كانت أداة قد أعادت خطأً عامله الوكيل على أنه نجاح. كلاسيكية: واجهة برمجية تُعيد `200` مع متن `{ "error": "rate limited" }`، وغلاف أداتك لا يفحص المتن، فيتصرّف الوكيل بثقة بناءً على رسالة خطأ. سجّل نتائج الأدوات خامًا وتحقّق من بنيتها. ### 3. طبقة النموذج فقط بعد استبعاد 1 و2 أشكّ في النموذج. وحتى عندها، "خطأ النموذج" يعني عادةً "موجّهي غامض." خذ المدخل الفاشل نفسه بالضبط، وضعه في سكربت لمرة واحدة مقابل النموذج ودرجة الحرارة نفسيهما، وانظر هل يتكرر. إن تكرّر، فالإصلاح هو عمل على الموجِّه أو [تقييم أكثر إحكامًا](/the-eval-harness-i-use-to-ship-ai-agents/)، وليس استبدالًا محمومًا للنموذج. ### 4. طبقة التنسيق إذا كانت خطوة واحدة سليمة بمعزل لكن التشغيلة متعددة الخطوات تفشل، فالخطأ في التسليم — حالة مفقودة بين الخطوات، أو حالة سباق، أو إعادة محاولة أعادت تنفيذ إجراء غير عديم الأثر التراكمي (non-idempotent). هذه هي الأشدّ خبثًا، وأغطّي أنماطها في [أنماط تنسيق الوكلاء المتعددين](/multi-agent-orchestration-patterns-queues-state-handoffs/). ## أعد إنتاج اللاحتمية بدلًا من مصارعتها الشيء الذي يجعل الوكلاء يبدون مستعصين على التصحيح هو اللاحتمية: المدخل نفسه يُنتج مُخرَجات مختلفة عبر التشغيلات. يمكنك ترويضها. أولًا، **ثبّت ما تستطيع.** اضبط `temperature: 0` أثناء التصحيح. لن يجعل Claude حتميًّا تمامًا، لكنه يُضيّق التباين بشكل حاد كي تميّز خطأً حقيقيًّا من ضوضاء العيّنات. ثانيًا، **شغّلها N مرة.** إذا تكرّر فشل مرة من كل 20 تشغيلة، فكرّر المدخل نفسه بالضبط 50 مرة والتقط كل مُخرَج. الآن لديك عيّنة، لا حكاية. خطأ يحدث 5% من الوقت هو خطأ حقيقي — تحتاج فقط إلى حجم لرؤيته. ```bash for i in $(seq 1 50); do node replay.mjs --trace=abc123 >> runs.jsonl done # ثم عُدّ حالات الفشل grep -c '"status":"fail"' runs.jsonl ``` ثالثًا، **قارِن بين التشغيلات الناجحة والفاشلة.** مع تثبيت درجة الحرارة والمدخل نفسه، فإن اختلافًا في المُخرَج يعني اختلافًا في المدخل لم تكتشفه بعد — طابع زمني في الموجِّه، أو نتيجة أداة تتغيّر، أو مستند مُسترجَع تغيّر. ## ابنِ حزمة إعادة تشغيل كي تتوقف عن التصحيح في الإنتاج التصحيح عبر إعادة تشغيل الوكيل المباشر بطيء وخطير — فهو يرسل رسائل بريد حقيقية، ويحجز ملاعب حقيقية. بدلًا من ذلك، التقط التتبّع وأعد تشغيله دون اتصال. تُحمّل حزمة إعادة التشغيل تتبّعًا مُسجَّلًا، وتعيد بناء المدخلات نفسها بالضبط لأي خطوة، وتعيد تشغيل تلك الخطوة فقط مقابل النموذج. لأنك سجّلت مصفوفة `messages` الكاملة، فأنت لا تحتاج إلى النظام الأعلى (upstream) إطلاقًا. هذا يحوّل رحلة ذهاب وإياب مدتها 10 دقائق في الإنتاج إلى حلقة محلية مدتها ثانيتان، وهي أكبر تسريع في سير عمل التصحيح لديّ. حزمة إعادة تشغيل جيدة تتيح لك أيضًا **التحوير وإعادة التشغيل**: غيّر سطرًا واحدًا من موجِّه النظام، وأعد تشغيل الـ 50 تتبّعًا الفاشلة نفسها، وانظر كم منها ينجح الآن. هذا هو الجسر من التصحيح إلى التقييم — بمجرد أن يصبح لديك مجموعة من التتبّعات الفاشلة، يصبح لديك بداية مجموعة اختبار انحدار (regression suite). ## راقب المقاييس التي تتنبأ فعلًا بالأعطال بعض حالات الفشل لا تُطلق استثناءً أبدًا. يعمل الوكيل، ويُعيد شيئًا معقولًا، ويفعل الشيء الخطأ بصمت. لاصطياد تلك، تراقب مقاييس سلوكية، لا مجرد معدلات أخطاء: - **معدل نجاح استدعاءات الأداة** لكل أداة. الانخفاض هنا كثيرًا ما يسبق فشلًا مرئيًّا. - **صلاحية مخطط المُخرَج** — ما النسبة المئوية للمُخرَجات التي تُحلَّل مقابل البنية المتوقّعة. أتحقق من كل مُخرَج باستخدام Zod وأُطلق تنبيهًا عندما تنخفض الصلاحية. - **طول الحلقة** — متوسط عدد الخطوات لكل تشغيلة. الارتفاع المفاجئ يعني عادةً أن الوكيل عالق في إعادة المحاولة. - **التكلفة لكل تشغيلة** — حلقة جامحة تظهر كقفزة في التكلفة قبل أن تظهر كشكوى. (عندما تهمّ التكلفة، يستحق [حساب Haiku مقابل Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet) المعرفة.) أتتبّع هذه كما أتتبّع كل شيء آخر — انظر [كيف أقيس ما إذا كان وكيل الذكاء الاصطناعي يعمل فعلًا](/how-i-measure-whether-an-ai-agent-is-actually-working/). المقياس الذي يصطاد فشلًا صامتًا يساوي عشرة تصطاد الفشل الصاخب. ## قائمة الفرز في 5 دقائق عندما يتعطّل وكيل وأنا تحت ضغط الوقت، أُنفّذ هذا بالترتيب: 1. **احصل على معرّف التتبّع** للتشغيلة الفاشلة. 2. **اقرأ المدخل نفسه بالضبط** للخطوة الفاشلة. هل هو جيّد التكوين؟ (يحلّ نحو 50% من الحالات هنا.) 3. **افحص نتائج الأدوات** في ذلك التتبّع بحثًا عن أخطاء متنكّرة في صورة نجاح. 4. **أعد تشغيل الخطوة دون اتصال** عند `temperature: 0`. هل تتكرر؟ 5. **إن تكرّرت،** فهي مشكلة موجِّه/نموذج — أصلِح وأعد تشغيل مجموعة التتبّعات. **وإن لم تتكرر،** فهي لاحتمية أو خطأ حالة/تنسيق — كرّرها 50× لتوصيفها. العزل المنضبط يتفوّق على الموجِّه البارع في كل مرة. النموذج نادرًا ما يكون المشكلة؛ النظام من حوله عادةً ما يكون كذلك. ## الأسئلة الشائعة ### كيف أُصحّح وكيل ذكاء اصطناعي يفشل أحيانًا فقط؟ التقط المدخل نفسه بالضبط من تتبّع مُسجَّل وأعد تشغيله أكثر من 50 مرة عند درجة حرارة 0. حالات الفشل المتقطّعة هي أخطاء حقيقية بمعدلات إطلاق منخفضة — الحجم يحوّل الحكاية إلى عيّنة قابلة لإعادة الإنتاج يمكنك مقارنتها وإصلاحها. ### هل الخطأ عادةً في النموذج أم في شفرتي؟ في وكلائي في الإنتاج، نحو 70% من "أخطاء الذكاء الاصطناعي" الظاهرة هي سباكة: نتائج أدوات مشوّهة، أو مدخلات مقتطعة، أو استثناءات مبتلَعة، أو حالة مفقودة بين الخطوات. استبعد طبقتَي المدخل والأداة قبل أن تشكّ في النموذج. ### ما الحد الأدنى من التسجيل الذي أحتاجه لتصحيح الوكلاء؟ معرّف تتبّع على كل تشغيلة، إضافة إلى سجلات منظَّمة للمُحفِّز، وكل استدعاء للنموذج (مصفوفة الرسائل الكاملة)، وكل استدعاء أداة ونتيجته الخام، والمُخرَج النهائي. إذا لم تُسجَّل خطوة، فلا يمكنك تصحيحها. ### كيف أتوقف عن التصحيح مقابل الإنتاج المباشر؟ ابنِ حزمة إعادة تشغيل تُحمّل تتبّعًا مُسجَّلًا وتعيد تشغيل أي خطوة مفردة دون اتصال باستخدام المدخلات الملتقَطة. تحوّل رحلة ذهاب وإياب بطيئة وخطيرة في الإنتاج إلى حلقة محلية سريعة وتصبح بذرة مجموعة اختبار الانحدار لديك. --- ## كيف تقيس ما إذا كان البحث بالذكاء الاصطناعي يرسل لك زيارات فعلًا Source: https://alejandrorioja.com/ar/how-to-measure-ai-search-traffic/ Published: 2026-06-08 Tags: GEO, Analytics TL;DR: معظم زيارات البحث بالذكاء الاصطناعي تظهر كتدفّق ضئيل من الإحالات من chatgpt.com وperplexity.ai وclaude.ai — لكن الأثر الأكبر مظلم: يقرأ الناس إجابة الذكاء الاصطناعي ولا ينقرون أبدًا. أقيس الاثنين معًا، مستخدمًا المُحيلين للنقرات وارتفاع البحث عن العلامة التجارية للتأثير. ## جدول المحتويات _محدّث في يونيو 2026._ **الخلاصة:** معظم زيارات البحث بالذكاء الاصطناعي تصل كتيار رفيع من الإحالات من `chatgpt.com` و`perplexity.ai` و`claude.ai` — سهلة العدّ بمجرد أن تعرف أين تبحث. لكن الأثر الأكبر **مظلم**: يقرأ الناس إجابة الذكاء الاصطناعي، ويستوعبون علامتك التجارية، ولا ينقرون أبدًا. أتتبّع النقرات عبر شرائح المُحيلين، والتأثير عبر ارتفاع البحث عن العلامة التجارية، وتحوّلات الزيارات المباشرة، ومراقبة الاستشهادات. عدّ النقرات وحدها يقلّل من شأن البحث بالذكاء الاصطناعي بشدة. **قراءة المُشغّل:** أدير محرّك محتوى وأراقب تحليلاته يوميًا. سؤال "هل يرسل البحث بالذكاء الاصطناعي زيارات؟" له إجابة محبطة: نعم، لكن معظم القيمة لا تظهر في تقرير الجلسات لديك. وإليك كيف أقيس الجزء الذي يظهر وأستنتج الجزء الذي لا يظهر. الجميع يريد رقمًا واحدًا: "كم من الزيارات يرسلها لي ChatGPT؟". الإجابة الصادقة هي أن البحث بالذكاء الاصطناعي ينتج أثرين مختلفين جدًا، وتحتاج إلى قياسين مختلفين. اخلط بينهما وستُصاب إما بالذعر (تبدو النقرات ضئيلة) أو ستخدع نفسك (ستفوّت الأثر الحقيقي). ## الأثر 1: الإحالات المباشرة — قابلة للعدّ، وأصغر مما تأمل عندما ينقر شخص على استشهاد داخل ChatGPT أو Perplexity أو إجابة من Claude، تسجّل تحليلاتك مُحيلًا. هذه جلسات حقيقية قابلة للإسناد. في GA4 أو أي أداة تحليلات، ابنِ شريحة تلتقط محرّكات الذكاء الاصطناعي: ``` session source matches any of: chatgpt.com chat.openai.com perplexity.ai claude.ai gemini.google.com copilot.microsoft.com ``` احفظ ذلك كقناة "بحث بالذكاء الاصطناعي" وراقبها عبر الزمن. بعض المحاذير التي تُربك الناس: - **المُحيلون يتسرّبون.** بعض واجهات الذكاء الاصطناعي تجرّد المُحيل أو تشوّهه، فتهبط نسبة من نقرات الذكاء الاصطناعي الحقيقية في خانة "مباشر" بدلًا من ذلك. عدد إحالاتك أرضية، لا الحقيقة. - **الحجم منخفض نسبةً إلى مرّات ظهور الإجابة.** محرّكات الذكاء الاصطناعي تجيب على السؤال على الصفحة؛ والأقلية الفضولية فقط هي التي تنقر للمتابعة. حفنة من الإحالات اليومية قد تقابل عددًا أكبر بكثير من الأشخاص الذين رأوك مُستشهَدًا بك. إذن شريحة الإحالات ضرورية لكنها غير كافية. تخبرك أن البحث بالذكاء الاصطناعي يرسل *بعض* الزيارات. وتقلّل من شأن التأثير بشدة. ## الأثر 2: التأثير المظلم — النصف الأكبر والأصعب رؤيةً الحركة الحقيقية بلا نقر. يسأل أحدهم ChatGPT سؤالًا، فتظهر علامتك التجارية في الإجابة كمصدر موصى به، ولا ينقر أبدًا — بل يتذكّرك فحسب. يظهر ذلك لاحقًا كـ**بحث عن العلامة التجارية** أو **زيارة مباشرة**، غير مُسندة إلى شيء. إنها الديناميكية نفسها التي جعلت قياس المقتطفات المميّزة محبطًا، لكن مُضخّمة. لا يمكنك قياس التأثير المظلم مباشرة، لكن يمكنك تثليثه: 1. **حجم البحث عن العلامة التجارية.** تتبّع عمليات البحث عن اسمك/علامتك في Google Search Console عبر الزمن. إذا بدأت تُستشهَد بك محرّكات الذكاء الاصطناعي وارتفعت مرّات ظهور علامتك دون حملة مقابلة، فهذا الارتفاع بصمة لتأثير الذكاء الاصطناعي. 2. **اتجاه الزيارات المباشرة.** ارتفاع مستمر في جلسات "مباشر" لا يتتبّع أي حملة كثيرًا ما يعكس إحالات ذكاء اصطناعي جُرّدت من مُحيلها، إضافةً إلى أشخاص يكتبون اسمك بعد إشارة من الذكاء الاصطناعي. 3. **التحويلات المساعِدة.** انظر ما إذا كانت جلسات البحث بالذكاء الاصطناعي، حتى وإن كانت نادرة، تظهر كـ*أول* نقطة تلامس في رحلات التحويل. قناة ضئيلة بمقياس النقرة الأخيرة قد تكون ذات شأن بمقياس اللمسة الأولى. لا شيء من هذه أرقام نظيفة. لكنها مجتمعةً تخبرك ما إذا كان النصف المظلم يتحرك. ## تتبّع الاستشهادات، لا النقرات فقط إليك المقياس الذي يهمّني أكثر من غيره للبحث بالذكاء الاصطناعي، وهو ليس في تحليلاتك على الإطلاق: **هل يُستشهَد بي، ولأي استعلامات؟** احتفظ بقائمة من 20-40 استعلامًا تهمّ عملك ومرّرها عبر ChatGPT وPerplexity وClaude وفق جدول — أسبوعيًا أكثر من كافٍ. سجّل، لكل استعلام ومحرّك: هل أنت مُستشهَد بك، وفي أي ترتيب؟ هذا هو مكافئ GEO لتتبّع الترتيب، وهو المؤشّر المتقدّم. تتحرك الاستشهادات *قبل* الزيارات اللاحقة وارتفاع العلامة التجارية، ولذا هنا ترى ما إذا كان [عملك في GEO للأعمال المحلية](/geo-for-local-business-getting-a-brick-and-mortar-cited-by-ai-search/) يؤتي ثماره. بنيتُ وكيلًا صغيرًا يُجري هذه الفحوص ويسجّل النتائج — من النوع الذي يصبح تافهًا بمجرد أن تمتلك حزمة وكلاء. وإن فضّلت القيام بذلك يدويًا، فجدول بيانات ومراجعة أسبوعية مدّتها 30 دقيقة يفي بالغرض للبداية. المنهجية تعكس [اختبار الاستشهادات ChatGPT مقابل Google](/chatgpt-search-vs-google-50-term-test/) الخاص بي، لكن يُجرى باستمرار بدلًا من مرة واحدة. ## ابنِ لوحة المعلومات: أربعة أرقام، أسبوعيًا لا أغرق في المقاييس. للبحث بالذكاء الاصطناعي أراقب أربعة أشياء وأراجعها أسبوعيًا: 1. **جلسات الإحالة من الذكاء الاصطناعي** — النقرات القابلة للعدّ من شريحة المُحيل. الاتجاه، لا القيمة المطلقة. 2. **تغطية الاستشهادات** — نسبة استعلاماتي المتتبَّعة التي أُستشهَد بي فيها عبر المحرّكات الثلاثة. المؤشّر المتقدّم. 3. **مرّات ظهور البحث عن العلامة التجارية** — من Search Console، كبديل للتأثير المظلم. 4. **التحويلات النابعة من الذكاء الاصطناعي** — حتى وإن كانت صغيرة، ما إذا كانت جلسات الذكاء الاصطناعي تبدأ يومًا رحلة تحويل. إذا كانت تغطية الاستشهادات ترتفع بينما تظل جلسات الإحالة ثابتة، فهذا *ليس* فشلًا — عادةً ما يعني أن النصف المظلم ينمو، ومن المفترض أن يتبع رقم البحث عن العلامة التجارية. وإذا كانت تغطية الاستشهادات تنخفض، فهذا تحذير مبكّر للتحرك قبل أن يتحرك أي رقم زيارات. إنها انضباط "قياس المؤشّر المتقدّم" نفسه الذي أطبّقه على الوكلاء في [كيف أقيس ما إذا كان وكيل الذكاء الاصطناعي يعمل فعلًا](/how-i-measure-whether-an-ai-agent-is-actually-working/). ## ماذا تفعل بالأرقام القياس مفيد فقط إن غيّر ما تفعله. خطة اللعب: - **تغطية استشهادات منخفضة لاستعلام يهمّك؟** هذه مشكلة محتوى + [schema](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/). الصفحة إما غير موجودة، أو غير مُهيكلة للاستخلاص، أو ليست موثوقة بما يكفي لتُسحَب إلى الإجابة. - **مُستشهَد بك لكن بلا زيارات إحالة؟** متوقّع وجيّد — البحث بالذكاء الاصطناعي يؤدّي عمل علامة تجارية، لا عمل نقرات. لا "تُصلحه" بمطاردة النقرات؛ بل اتّجه نحو كونك المصدر المُستشهَد به. - **إحالات من محرّك دون غيره؟** تتباين المحرّكات بشدة في المصادر (قِستُ ~40% تداخلًا بين ChatGPT وGoogle). كونك مُستشهَدًا بك من أحدها لا يجلب لك الآخرين — اعمل على تغطية كل محرّك على حدة. ## ملاحظة حول النزاهة في الإسناد قاوم رغبة الادّعاء بدقة لا تملكها. قياس البحث بالذكاء الاصطناعي في 2026 تثليث، لا إسناد. أي شخص يبيعك رقمًا نظيفًا من نوع "ChatGPT جلب لك X دولارًا" يبالغ في ما يمكن معرفته، لأن المُحيلين يتسرّبون والأثر الأكبر بلا نقر بحكم التصميم. الموقف الصحيح: عُدّ ما يمكنك عدّه، وراقب البدائل لما لا يمكنك، واتّخذ القرارات بناءً على الاتجاه. الاتجاه جدير بالثقة حتى عندما لا يكون الرقم المطلق كذلك. ## الأسئلة الشائعة ### كيف أرى الزيارات من ChatGPT أو Perplexity في GA4؟ ابنِ قناة/شريحة تطابق نطاقات محرّكات الذكاء الاصطناعي — chatgpt.com وchat.openai.com وperplexity.ai وclaude.ai وgemini.google.com وcopilot.microsoft.com — كمصدر للجلسة. هذا يلتقط إحالات النقر، رغم أن بعضها يُجرّد إلى "مباشر"، فعامِل العدد كأرضية. ### لماذا زيارات الإحالة من البحث بالذكاء الاصطناعي لديّ منخفضة جدًا؟ لأن البحث بالذكاء الاصطناعي بلا نقر في معظمه — يجيب المحرّك على الصفحة وأقلية فقط تنقر للمتابعة. كثيرًا ما تتزامن أعداد الإحالة المنخفضة مع مرّات ظهور استشهادات أكبر بكثير. قِس الاستشهادات وارتفاع البحث عن العلامة التجارية لترى الجزء الذي تفوّته الإحالات. ### ما أفضل مؤشّر متقدّم للبحث بالذكاء الاصطناعي؟ تغطية الاستشهادات: نسبة استعلاماتك الحرجة لعملك، المتتبَّعة، التي تُستشهَد بك فيها عبر ChatGPT وPerplexity وClaude. تتحرك قبل الزيارات وارتفاع العلامة التجارية، فتخبرك مبكّرًا ما إذا كان عملك في GEO يؤتي ثماره. ### هل يمكنني الحصول على إسناد دقيق للإيرادات من البحث بالذكاء الاصطناعي؟ لا، ليس بموثوقية في 2026. يتسرّب المُحيلون إلى "مباشر" ومعظم الأثر بلا نقر بحكم التصميم. عامِل قياس البحث بالذكاء الاصطناعي كتثليث — عُدّ النقرات، وراقب بدائل البحث عن العلامة التجارية والزيارات المباشرة، وقرّر بناءً على الاتجاه، لا على رقم دولاري زائف الدقّة. --- ## أنماط تنسيق الوكلاء المتعددين: الطوابير والحالة وعمليات التسليم Source: https://alejandrorioja.com/ar/multi-agent-orchestration-patterns-queues-state-handoffs/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: أنظمة الوكلاء المتعددين الموثوقة لا تعتمد على مطالبات ذكية — بل تعتمد على انضباط الأنظمة الموزعة المُمِلّ: طوابير دائمة بين الوكلاء، وحالة محفوظة خارج النموذج، وعمليات تسليم متكافئة (idempotent) تصمد أمام إعادات المحاولة. النموذج هو العامل؛ والطابور هو العمود الفقري. ## جدول المحتويات _محدَّث يونيو 2026._ **خلاصة:** أنظمة الوكلاء المتعددين الموثوقة لا تُكسَب بمطالبات ذكية — بل تُكسَب بانضباط الأنظمة الموزعة المُمِلّ. ضع **طابورًا** دائمًا بين الوكلاء، واحفظ **الحالة خارج النموذج**، واجعل كل **عملية تسليم متكافئة** بحيث لا يمكن لإعادة المحاولة أن تتصرف مرتين. النموذج هو العامل؛ والطابور هو العمود الفقري. أتقِن هذه الثلاثة ويتوقف التنسيق عن كونه مخيفًا. **قراءة المُشغِّل:** معظم وكلائي الذين يزيد عددهم عن 100 وكيل هم بخطوة واحدة. أما الذين ليسوا كذلك — خطوط المعالجة التي تُصنِّف ثم تُثري ثم تتصرف — فلم تصبح موثوقة إلا عندما توقّفت عن التفكير في "سلسلة مطالبات" وبدأت أفكر في "طابور مهام بعمال LLM". هذه هندسة معمارية، وليست هندسة مطالبات. كلمة "متعدد الوكلاء" توحي بأن الوكلاء يتحدثون فيما بينهم. عمليًا، النسخة الموثوقة هي العكس: الوكلاء لا يتواصلون مباشرة على الإطلاق. إنهم يضعون رسائل في طابور ويلتقطون العمل من طابور، ويعيش التنسيق في السباكة بينهم. إليك الأنماط التي تصمد في الإنتاج. ## النمط 1: ضع طابورًا دائمًا بين كل وكيل الغريزة الأولى هي استدعاء الوكيل B مباشرة من داخل الوكيل A. لا تفعل. الاستدعاءات المباشرة تقرن الاثنين: إذا كان B بطيئًا، يتوقف A؛ وإذا فشل B، يُفقَد عمل A؛ وإذا احتجت إلى توسيع نطاق B، فلا يمكنك ذلك دون المساس بـ A. بدلًا من ذلك، يُنهي A عمله و**يضع رسالة في الطابور** لـ B. الوكيل B عامل منفصل يُفرِّغ الطابور بوتيرته الخاصة. ```typescript // الوكيل A ينتهي ويُسلِّم عبر الطابور — دون استدعاء مباشر لـ B await env.ENRICH_QUEUE.send({ traceId, type: "enrich", payload: classifierResult, }); // مهمة A أُنجِزت. سيلتقطها B بشكل مستقل. ``` على Cloudflare أستخدم Workers Queues لهذا الغرض بالضبط — نفس البِنى الأساسية وراء [حزمة الوكلاء التي أستخدمها](/the-agent-stack-i-use-to-run-30-production-agents-no-python/). يمنحك الطابور أربعة أشياء مجانًا: **التخزين المؤقت** (يمكن أن يتعطل B دون فقدان العمل)، و**إعادات المحاولة** (تُعاد الرسائل الفاشلة)، و**الضغط العكسي** (تتراكم القفزة في الطابور بدلًا من الانهيار)، و**فك الاقتران** (وسِّع أو أعِد نشر B دون المساس بـ A). كل واحد من هذه أمر كنت ستضطر لولا ذلك إلى بنائه يدويًا وارتكاب أخطاء فيه. ## النمط 2: احفظ الحالة خارج النموذج دائمًا أكثر أخطاء الوكلاء المتعددين شيوعًا هو افتراض أن النموذج يتذكر أي شيء بين الخطوات. إنه لا يتذكر. كل استدعاء للنموذج عديم الحالة؛ والذاكرة الوحيدة هي ما تضعه في المطالبة. لذا يجب أن يعيش مصدر الحقيقة لـ "أين تقف هذه المهمة في خط المعالجة" في قاعدة بيانات، لا في محادثة. أحتفظ بسجل مهمة واحد يقرأه كل وكيل ويُحدِّثه: ```typescript interface JobState { traceId: string; stage: "classified" | "enriched" | "acted" | "done" | "failed"; data: Record; attempts: number; updatedAt: number; } ``` يُنفِّذ كل وكيل نفس الحلقة: **قراءة** حالة المهمة، وأداء عمله، و**كتابة** الحالة الجديدة، ووضع المرحلة التالية في الطابور. لا يحتفظ النموذج بالحالة أبدًا — بل يتلقى الجزء ذا الصلة كمُدخَل ويُعيد نتيجة. هذا ما يجعل النظام قابلًا لإعادة التشغيل: إذا مات عامل في منتصف المهمة، فإن سجل الحالة لا يزال يقول بالضبط أين كانت الأمور، وتلتقط رسالة الطابور المُعاد تسليمها من هناك. كما يجعل تصحيح الأخطاء قابلًا للإدارة، لأن جدول الحالة سجل قابل للاستعلام لرحلة كل مهمة — نفس عقلية القياس الواردة في [كيف أقيس ما إذا كان الوكيل يعمل فعلًا](/how-i-measure-whether-an-ai-agent-is-actually-working/). ## النمط 3: اجعل كل عملية تسليم متكافئة تضمن الطوابير التسليم *مرة واحدة على الأقل*، لا مرة واحدة بالضبط. هذا يعني أنه يمكن تسليم الرسالة مرتين — انقطاعات الشبكة، وإعادات المحاولة، وإعادات النشر. إذا لم يكن إجراء وكيلك متكافئًا، فإن التسليم المزدوج يتصرف مرتين: رسالتا تأكيد، وحجزان، ودفعتان. هذه أبشع فئة من أخطاء التنسيق، وهي التي تكتشفها الفرق في الإنتاج. الحل هو جعل الإجراءات متكافئة بمفتاح: ```typescript async function handleEnrich(msg: QueueMessage, env: Env) { const job = await getJob(env, msg.traceId); if (job.stage !== "classified") { // تمت معالجته بالفعل بعد هذه المرحلة — هذا تسليم مكرر. تخطَّ. return; } const result = await enrich(job.data); await advanceJob(env, msg.traceId, "enriched", result); await env.ACT_QUEUE.send({ traceId: msg.traceId, type: "act" }); } ``` يجعل فحص المرحلة العملية آمنة للتشغيل مرتين: يرى التسليم الثاني أن المهمة قد تقدمت بالفعل ولا يفعل شيئًا. للآثار الجانبية الخارجية (إرسال بريد إلكتروني، خصم بطاقة)، مرِّر مفتاح تكافؤ إلى واجهة برمجة التطبيقات النهائية حتى *تُزيل هي أيضًا* التكرار. افترض أن كل رسالة ستُسلَّم مرتين وصمِّم بحيث يكون ذلك غير ضار — لأنها ستفعل في نهاية المطاف. ## النمط 4: المنسِّق مقابل الكوريغرافيا — اختر بتأنٍّ هناك طريقتان لتوصيل التدفق، والخيار الصحيح يعتمد على التعقيد. **الكوريغرافيا** (ما ألجأ إليه افتراضيًا): يعرف كل وكيل الخطوة التالية فقط ويضعها في الطابور. ينبثق التدفق من السلسلة. بسيطة، لامركزية، سهلة التوسيع — أضِف مرحلة بإدراج طابور. العيب هو أنه لا يوجد مكان واحد يصف التدفق بأكمله، لذا قد يصبح خط المعالجة المعقّد صعب الفهم. **التنسيق** (منسِّق مركزي): يمتلك منسِّق واحد التدفق، ويستدعي كل وكيل بدوره، ويقرر ما يلي بناءً على النتائج. يعيش التدفق بأكمله في مكان واحد قابل للقراءة، ومنطق التفرّع صريح. والثمن هو مكوّن مركزي يجب أن يكون هو نفسه دائمًا — إذا لم تكن حالة المنسِّق نفسها مُخرَجة خارجيًا (النمط 2)، يصبح نقطة الفشل الوحيدة. قاعدتي: **الكوريغرافيا حتى يصبح التفرّع معقّدًا، ثم منسِّق دائم.** خط معالجة خطي من ثلاث مراحل هو كوريغرافيا. أما التدفق ذو التوجيه الشرطي، والتوزيع المتوازي، وعمليات الدمج فيتطلب منسِّقًا تعيش حالته في قاعدة البيانات حتى يتمكن من الاستئناف بعد انهيار. ## النمط 5: التوزيع والتجميع دون فقدان أجزاء عندما تُولِّد مهمة واحدة N مهامًا فرعية متوازية (إثراء 50 سجلًا، تلخيص 20 مستندًا) وتحتاج إلى انتظارها جميعًا قبل المتابعة، فأنت بحاجة إلى **دمج** (join). الحيلة هي عدّاد في حالة المهمة: 1. يضع الأب N رسالة ابنة في الطابور ويكتب `expected: N, completed: 0` في سجل المهمة. 2. يؤدي كل ابن عمله و**يزيد ذرّيًا** `completed`. 3. الابن الذي يرفع `completed` ليساوي `expected` يضع المرحلة التالية في الطابور. الزيادة الذرّية حاملة للوزن — بدونها، يمكن لابنين ينتهيان في وقت واحد أن يظنّا كلاهما أنهما ليسا الأخير، ولا يُطلَق الدمج أبدًا. استخدم عدّادًا يستطيع مخزن البيانات زيادته ذرّيًا، أو معاملة. يتيح لك هذا النمط موازاة الوسط المكلِّف من خط المعالجة (غالبًا عمل رخيص لـ Haiku — انظر [حسابات تكلفة Haiku مقابل Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet)) مع الحفاظ على دمج نظيف في النهاية. ## ما سأتجاوزه لست بحاجة إلى إطار عمل ثقيل للوكلاء لفعل أي من هذا. الطوابير، وجدول الحالة، ومفاتيح التكافؤ هي بِنى أساسية موجودة بالفعل في كل منصة. شاهدت فرقًا تلجأ إلى أطر عمل متعددة الوكلاء معقّدة للحصول على ميزات يمنحها الطابور مجانًا، فترث صندوقًا أسود أصعب في تصحيح أخطائه من السباكة التي حلّ محلها. ابدأ بالبِنى الأساسية المُمِلّة. لا تلجأ إلى إطار عمل إلا عندما تشعر بألم محدد يحلّه. الخلاصة: الوكلاء عمّال عديمو الحالة، والطوابير هي العمود الفقري الدائم، والحالة تعيش في قاعدة بيانات، وكل عملية تسليم آمنة للتشغيل مرتين. هذه هي اللعبة كلها. ## الأسئلة الشائعة ### هل ينبغي للوكلاء استدعاء بعضهم مباشرة أم المرور عبر طابور؟ عبر طابور. الاستدعاءات المباشرة تقرن الوكلاء — فشل أحدهم أو بطؤه ينتشر إلى الآخر، ولا يمكنك التوسيع أو إعادة النشر بشكل مستقل. يمنحك الطابور الدائم التخزين المؤقت وإعادات المحاولة والضغط العكسي وفك الاقتران مجانًا. ### أين يجب أن تعيش حالة الوكلاء المتعددين؟ خارج النموذج، في قاعدة بيانات، كسجل مهمة يقرأه كل وكيل ويُحدِّثه. استدعاءات النموذج عديمة الحالة، لذا يجب أن يكون مصدر الحقيقة لتقدّم خط المعالجة خارجيًا — وهذا ما يجعل النظام قابلًا لإعادة التشغيل بعد انهيار. ### كيف أمنع وكيلًا من التصرف مرتين على نفس المهمة؟ اجعل عمليات التسليم متكافئة. تحقق من مرحلة المهمة قبل التصرف ولا تفعل شيئًا إن كانت قد تقدمت بالفعل، ومرِّر مفاتيح تكافؤ إلى واجهات برمجة التطبيقات الخارجية. تُسلِّم الطوابير مرة واحدة على الأقل، لذا افترض أن كل رسالة قد تصل مرتين وصمِّم بحيث تكون التكرارات غير ضارة. ### هل أحتاج إلى إطار عمل متعدد الوكلاء؟ عادةً لا. تغطي الطوابير الدائمة، وجدول الحالة، ومفاتيح التكافؤ معظم احتياجات الإنتاج ببِنى أساسية توفرها منصتك بالفعل. تبنَّ إطار عمل فقط عندما تصطدم بمشكلة ملموسة يحلّها بشكل فريد، لا افتراضيًا. --- ## منظومة التقييم التي أستخدمها لإطلاق وكلاء الذكاء الاصطناعي دون خوف Source: https://alejandrorioja.com/ar/the-eval-harness-i-use-to-ship-ai-agents/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: إطلاق الوكلاء دون خوف ينبع من شيء واحد: منظومة تقييم. مجموعة ثابتة من حالات الاختبار المُقيَّمة، تُسجَّل آليًا (تأكيدات إضافةً إلى حكَم من نموذج لغوي كبير)، تُشغَّل قبل كل تغيير في التوجيه أو النموذج. إذا صمدت الدرجة، تُطلق. تُبنى مجموعة الاختبارات من إخفاقات إنتاج حقيقية. ## جدول المحتويات _محدّث في يونيو 2026._ **خلاصة:** السبب الذي يجعلني قادرًا على تغيير توجيه أو استبدال نموذج في وكيل حيّ دون أن أحبس أنفاسي هو شيء واحد: **منظومة تقييم**. مجموعة ثابتة من حالات الاختبار المُقيَّمة، تُسجَّل آليًا — تأكيدات صارمة حيث يمكنني كتابتها، وحكَم من نموذج لغوي كبير حيث لا أستطيع — تُشغَّل قبل كل تغيير. إذا صمدت الدرجة، أُطلق. إذا انخفضت، لا أُطلق. مجموعة الاختبارات ليست اصطناعية؛ إنها مبنية من إخفاقات إنتاج حقيقية، فيصير كل خطأ اختبار انحدار دائمًا. **قراءة المُشغّل:** عبر أكثر من 100 وكيل، الفرق بين تلك التي ألمسها بثقة وتلك التي أخشاها هو ما إذا كانت لديها تقييمات. غياب منظومة التقييم يعني أن كل تعديل في التوجيه مقامرة. منظومة التقييم تحوّل "أظن أن هذا أفضل" إلى "هذا أفضل بأربع نقاط قابلة للقياس ولم يعطّل شيئًا". هذا هو الانفتاح كله. لن تُطلق شيفرة دون اختبارات. يُطلق الناس وكلاء دون تقييمات باستمرار، ثم يتساءلون لماذا عطّل "تعديل توجيه ضئيل" الإنتاج. منظومة التقييم هي مجموعة الاختبارات للبرمجيات غير الحتمية. إليك تلك التي أُشغّلها فعلًا. ## ابدأ بمجموعة اختبارات مبنية من إخفاقات حقيقية المنظومة لا تكون أفضل من حالات اختبارها، وأفضل حالات الاختبار تأتي من الإنتاج، لا من خيالك. في كل مرة يفشل فيها وكيل في الواقع، ألتقط المُدخل بدقّة (أُسجّل كل تشغيل بمعرّف تتبّع — انظر [كيفية تنقيح وكيل في الإنتاج](/how-to-debug-an-ai-agent-in-production)) وأحوّله إلى حالة تقييم: ```typescript interface EvalCase { id: string; input: AgentInput; // المُدخل الإنتاجي الدقيق expected?: string; // الحقيقة المرجعية، حين توجد assertions: Assertion[]; // فحوص صارمة يجب أن تنجح rubric?: string; // لحكَم النموذج اللغوي، حين يكون المُخرَج مفتوحًا } ``` ممارستان تهمّان هنا. **اسحب من الإنتاج**، كي تختبر تقييماتك ما يتعطّل فعلًا، لا ما خمّنتَ أنه قد يتعطّل. و**غطِّ النطاق** — المسار السعيد، والحالات الحدّية، والمُدخلات الخصامية، والمُدخلات الفارغة/المشوّهة التي تسبّب إخفاقات صامتة. مجموعة اختبارات من 30 إلى 50 حالة مختارة بعناية تلتقط أكثر بكثير من 500 حالة كسولة. أُفضّل امتلاك 40 حالة تمثّل كل منها نمط إخفاق حقيقيًا على ألف حالة تختبر جميعها المسار السهل ذاته. ## قيّم بالتأكيدات أولًا، ثم بحكَم نموذج لغوي كبير ليس كل مُخرَج يحتاج إلى نموذج لتقييمه. ألجأ إلى أرخص مُقيِّم ينجح. **تأكيدات صارمة** لكل ما هو مُهيكَل. هل يُحلَّل المُخرَج بوصفه JSON صالحًا؟ هل يحتوي الحقل المطلوب؟ هل التاريخ المُستخرَج ضمن المدى؟ هل استدعى الأداة الصحيحة بالوسائط الصحيحة؟ هذه حتمية، ومجانية، وقاطعة — اكتب منها قدر ما تستطيع. ```typescript const assertions: Assertion[] = [ (out) => isValidJSON(out), (out) => parse(out).category in ALLOWED_CATEGORIES, (out) => parse(out).confidence >= 0 && parse(out).confidence <= 1, ]; ``` **حكَم نموذج لغوي كبير** للبقية المفتوحة — النبرة، والإفادة، و"هل أجاب هذا عن السؤال فعلًا". هنا تُعطي نموذجًا المُدخل والمُخرَج ومعيار تقييم، وتطلب منه أن يُسجّل درجة. قاعدتان تُبقيان الحكَم أمينًا: اجعل معيار التقييم **محدّدًا** (سلّم من 1 إلى 5 بمراسٍ موصوفة يتفوّق على "قيّم الجودة")، واستخدم **نموذجًا قويًا حكَمًا** — فالحكم مهمة استدلال، لذا هذا موضع أدفع فيه بسرور مقابل Sonnet حتى حين يعمل الوكيل نفسه على Haiku وفق [حساب التكلفة](/ai-agent-cost-math-when-haiku-beats-sonnet). معيار تقييم مبهم أو حكَم ضعيف يمنحك ضوضاء تبدو كإشارة. ## شغّل المنظومة قبل كل تغيير توجد المنظومة للإجابة عن سؤال واحد: *هل جعل هذا التغيير الوكيل أفضل أم أسوأ؟* لذا أُشغّلها قبل كل تعديل توجيه، أو استبدال نموذج، أو تغيير أداة. ```bash # خط الأساس على main npm run eval -- --suite=booking-agent > baseline.json # أجرِ التغيير، ثم أعد التشغيل npm run eval -- --suite=booking-agent > candidate.json # قارن npm run eval:diff baseline.json candidate.json ``` يُظهر الفرق الدرجة الإجمالية، والنجاح/الفشل لكل حالة، و — بالأهم — **أي حالات بعينها انحدرت.** إجمالي يرتفع بينما تنكسر ثلاث حالات بصمت ليس تحسينًا؛ إنه مقايضة أريد أن أراها وأوافق عليها، لا أن تتسلّل. مراقبة الفرق لكل حالة هي كيف تتجنّب "أصلحتُ شيئًا، كسرتُ شيئين آخرين"، نمط الإخفاق الذي يجعل الناس يخشون توجيهاتهم نفسها. ## ضع بوابة انحدار ودعها تحجب ما إن تثق بالمنظومة، اربطها بمسار الوصول إلى الإنتاج بوصفها بوابة. قاعدتي صريحة: **أي تغيير يُهبط الدرجة دون عتبة خط الأساس لا يُطلق.** ليس "سأنظر في الأمر لاحقًا" — بل محجوب، تمامًا كاختبار تكامل مستمر فاشل. ```typescript const PASS_THRESHOLD = 0.90; // يجب أن تنجح 90% من الحالات if (candidate.passRate < PASS_THRESHOLD || candidate.passRate < baseline.passRate) { throw new Error(`Eval regression: ${candidate.passRate} < ${baseline.passRate}`); } ``` هذا ما يحوّل التقييمات من رفاهية إلى الشيء الذي يتيح لك التحرّك بسرعة. البوابة هي ما يجعل "الإطلاق دون خوف" حقيقيًا بحرفيّته: أسوأ ما يحدث لتغيير سيّئ هو تشغيل تقييم أحمر، لا حادثة إنتاج. ولأن مجموعة الاختبارات تنمو كلما انكسر شيء، تصبح البوابة أصرم وأكثر حماية مع الوقت من تلقاء نفسها. ## احسب حساب اللاحتمية في التسجيل دقّة تُعثِر الناس: قد يحصل المُدخل نفسه على درجة مختلفة بين التشغيلات لأن النموذج يأخذ عيّنات بشكل مختلف. إذا شغّلت كل حالة مرة واحدة، فسترى انحدارات وهمية — حالة "انكسرت" وهي في الحقيقة مجرد ضوضاء أخذ عيّنات. تخفيفان. شغّل التقييمات عند **`temperature: 0`** لتقليص التباين (لن يُزيله كليًا). وللحالات التي رأيتها ترتعش، **شغّلها N مرة وخذ معدّل النجاح**، لا نجاحًا/فشلًا واحدًا. حالة تنجح 9 من 10 في حال أفضل من حالة تنجح 5 من 10 وإن أمكن لكلتيهما إظهار تشغيل أخضر واحد. هذا هو مبدأ الكمّ-فوق-الحكاية ذاته الذي أستخدمه عند [تنقيح الإخفاقات المتقطّعة](/how-to-debug-an-ai-agent-in-production) — تشغيل واحد رأي، وخمسون تشغيلًا بيانات. ## أغلق الحلقة بمراقبة الإنتاج تختبر منظومة التقييم مقابل حالات معروفة. أما الإنتاج فيُلقي حالات جديدة. فالحلقة هي: راقب السلوك الحيّ، التقط نمط إخفاق جديدًا، حوّله إلى حالة تقييم، أصلحه، وها هو الآن محميّ على الدوام. جانب المراقبة — تتبّع معدّل النجاح، وصلاحية المُخرَج، والتكلفة لكل تشغيل على حركة المرور الحيّة — هو ما أتناوله في [كيف أقيس ما إذا كان وكيل ذكاء اصطناعي يعمل فعلًا](/how-i-measure-whether-an-ai-agent-is-actually-working/). التقييمات والمراقبة نصفان للنظام نفسه: المراقبة تجد الأخطاء، والتقييمات تضمن بقاءها ميتة. تلك الحلقة الراجعة هي المنتج الحقيقي. أي مجموعة تقييم بمفردها تتقادم؛ أما *العملية* التي تحوّل كل إخفاق إنتاج إلى اختبار دائم فتزداد قوّة كل أسبوع. هكذا ينتقل وكيل من "مخيف اللمس" إلى شيء أعيد هيكلته عصر يوم جمعة دون أن يرفّ لي جفن. ## الأسئلة الشائعة ### ما الذي يدخل في مجموعة تقييم لوكيل ذكاء اصطناعي؟ مُدخلات إنتاج حقيقية مُحوَّلة إلى حالات مُقيَّمة — مسار سعيد، وحالات حدّية، ومُدخلات خصامية ومشوّهة — لكلٍّ تأكيدات صارمة، وللمُخرَجات المفتوحة معيار تقييم لحكَم نموذج لغوي. من 30 إلى 50 حالة مأخوذة من إخفاقات فعلية تتفوّق على مئات الحالات الاصطناعية التي تختبر جميعها المسار السهل. ### هل ينبغي أن أستخدم نموذجًا لغويًا لتقييم مُخرَجات الوكيل؟ استخدم تأكيدات صارمة حيثما كان المُخرَج مُهيكَلًا (JSON صالح، حقل صحيح، استدعاء أداة صحيح) — فهي مجانية وحتمية. احتفظ بحكَم النموذج اللغوي للصفات المفتوحة كالنبرة والإفادة، بمعيار تقييم محدّد ونموذج حكَم قوي كي تحصل على إشارة، لا ضوضاء. ### كيف أمنع تغيير توجيه من تعطيل الإنتاج بصمت؟ شغّل منظومة التقييم قبل كل تغيير وقارنها بخط أساس، مراقبًا الانحدارات لكل حالة، لا الدرجة الإجمالية وحدها. ثم اشترط النشر على النتيجة كي يُحجَب أي تغيير يهبط دون عتبة خط الأساس كاختبار فاشل. ### كيف أتعامل مع اللاحتمية في التقييمات؟ شغّل عند درجة حرارة 0 لتقليل التباين، وللحالات التي ترتعش، شغّلها مرات عدّة وسجّل معدّل النجاح بدل تشغيل واحد. حالة تنجح 9 من 10 مرّات أسلم من حالة تنجح 5 من 10، حتى لو أظهر تشغيل واحد كلتيهما خضراء. --- ## كيفية أتمتة نشرتك البريدية بوكيل ذكاء اصطناعي Source: https://alejandrorioja.com/ar/how-to-automate-your-newsletter-with-an-ai-agent/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents, Growth TL;DR: يقرأ وكيل Claude قائمة انتظار المحتوى الخاصة بي، ويختار أقوى زاوية للأسبوع، ويصيغ النشرة البريدية بصوتي، ويقسم القائمة حسب مستوى التفاعل، ويجدول الإرسال عبر واجهة برمجة تطبيقات Kit — كل ذلك دون أن أفتح محرراً. أراجع معاينة مُصيَّرة وأضغط موافقة. العمل الإبداعي الصعب لي؛ التنفيذ الميكانيكي للوكيل. ## جدول المحتويات _محدث يونيو 2026._ **خلاصة:** يقرأ وكيل Claude قائمة انتظار المحتوى الخاصة بي، ويختار أقوى زاوية للأسبوع، ويصيغ النشرة البريدية بصوتي، ويقسم القائمة حسب مستوى التفاعل، ويجدول الإرسال عبر واجهة برمجة تطبيقات Kit — كل ذلك دون أن أفتح محرراً. أراجع معاينة مُصيَّرة وأضغط موافقة. العمل الإبداعي الصعب لي؛ التنفيذ الميكانيكي للوكيل. **[ملاحظة المشغّل]** نشرة بريدية تُرسَل باستمرار تتفوق على نشرة "أفضل" لكنها تُرسَل حين يحلو لصاحبها. القيد كان العبء التنفيذي وليس الأفكار. كانت لديّ أفكار؛ لم يكن لديّ النطاق الترددي لتنسيقها وجدولتها وتقسيمها كل أسبوع. أزال الوكيل ذلك الفجوة. ## الاختناق الحقيقي في معظم سير عمل النشرات البريدية تركز معظم نصائح أتمتة النشرات البريدية على الشيء الخطأ: تسلسلات الترحيب، والأتمتة، ومنطق الوسم. هذا جيد، لكنه لا يحل مشكلة الإنشاء الأسبوعية. العائق الحقيقي هو: تعرف ما تريد قوله، لكن الجلوس لتنسيقه وكتابة متغيرات سطر الموضوع واختيار الشريحة الصحيحة وجدولته في الوقت المناسب يكلف 2-3 ساعات من تبديل السياق أسبوعياً. اضرب في 52 أسبوعاً وستجد أنك أمضيت أسبوع عمل كامل في *إرسال* النشرات البريدية فحسب. يتعامل الوكيل مع كل خطوة بعد "أعرف ما هي زاوية هذا الأسبوع." ## المجموعة التقنية التي أستخدمها - **[Kit](/recommends/convertkit)** (المعروف سابقاً بـ ConvertKit) — منصة البريد الإلكتروني. واجهة برمجة تطبيقات ممتازة، وسم موثوق للمشتركين، تحليلات نظيفة. واجهة برمجة التطبيقات الصديقة للوكلاء هي ما أقنعني. - **Claude (Anthropic SDK)** — طبقة التوليد - **Cloudflare Workers** — مشغّل مجدوَل (يعمل كل ثلاثاء الساعة 8 صباحاً CT) - **Airtable** — قائمة انتظار المحتوى وصندوق وارد الموافقة إذا لم تكن على Kit، فإن نفس النمط يعمل مع أي منصة تمتلك واجهة REST API لإنشاء وجدولة البث. ## الخطوة 1: قائمة انتظار المحتوى يحتاج الوكيل إلى مصدر حقيقي لـ"ما الذي نكتب عنه." لديّ جدول [Airtable](/recommends/airtable) بالأعمدة: - `Topic` — الزاوية أو السؤال - `Status` — Queue / Approved / Sent - `Tier` — هل هذا لجميع المشتركين أم للمشتركين النشطين فقط - `Notes` — أي قيود (تجنب هذا الأسلوب، أدرج هذا الرابط، إلخ.) كل أسبوع، أقضي 10 دقائق في إضافة 2-3 مواضيع إلى القائمة. هذا هو مساهمتي الإبداعية. الباقي عمل الوكيل. ## الخطوة 2: وكيل المسودة ```typescript // workers/newsletter-agent/index.ts import Anthropic from "@anthropic-ai/sdk"; import Airtable from "airtable"; const client = new Anthropic(); const VOICE_SYSTEM = `You are writing a weekly newsletter for Alejandro Rioja's subscribers. His audience: founders and operators interested in AI agents, SEO, and growing a one-person business. Voice: direct, first-person, practitioner. No hype, no "exciting times," no excessive bullet lists. Structure every newsletter as: 1. One-sentence hook (the problem or observation) 2. The core insight (3–5 paragraphs, no headers, conversational) 3. One concrete action the reader can take this week 4. A short sign-off (2 sentences max) Subject line: specific, outcome-oriented, under 50 chars. No clickbait. Return JSON: { "subject": "...", "preheader": "...", "body": "..." }`; async function getNextTopic(): Promise<{ id: string; topic: string; notes: string; tier: string }> { const base = new Airtable({ apiKey: process.env.AIRTABLE_API_KEY }).base(process.env.AIRTABLE_BASE_ID!); const records = await base("Newsletter Queue") .select({ filterByFormula: "{Status} = 'Queue'", sort: [{ field: "Created", direction: "asc" }], maxRecords: 1 }) .firstPage(); if (!records.length) throw new Error("Queue is empty. Add topics."); const r = records[0]; return { id: r.id, topic: r.get("Topic") as string, notes: (r.get("Notes") as string) ?? "", tier: (r.get("Tier") as string) ?? "all" }; } async function draftNewsletter(topic: string, notes: string): Promise<{ subject: string; preheader: string; body: string }> { const msg = await client.messages.create({ model: "claude-sonnet-4-6", max_tokens: 2048, system: VOICE_SYSTEM, messages: [{ role: "user", content: `Write this week's newsletter on: "${topic}". Additional notes: ${notes || "none"}` }], }); const text = (msg.content[0] as any).text.replace(/```json\n?/, "").replace(/```/, "").trim(); return JSON.parse(text); } async function scheduleWithKit(draft: { subject: string; preheader: string; body: string }, tier: string): Promise { const segmentId = tier === "engaged" ? process.env.KIT_ENGAGED_SEGMENT_ID : null; const sendAt = new Date(); sendAt.setDate(sendAt.getDate() + ((4 - sendAt.getDay() + 7) % 7)); // next Thursday sendAt.setHours(9, 0, 0, 0); // 9am CT const payload: any = { broadcast: { subject: draft.subject, content: draft.body, description: draft.preheader, send_at: sendAt.toISOString(), email_layout_template: "minimal", }, }; if (segmentId) payload.broadcast.segment_id = segmentId; const res = await fetch("https://api.kit.com/v4/broadcasts", { method: "POST", headers: { "Content-Type": "application/json", "X-Kit-Api-Key": process.env.KIT_API_KEY! }, body: JSON.stringify(payload), }); const data = await res.json(); return data.broadcast?.id ?? ""; } export default { async scheduled(_event: ScheduledEvent, env: Env) { // Inject env vars Object.assign(process.env, env); const { id, topic, notes, tier } = await getNextTopic(); const draft = await draftNewsletter(topic, notes); const broadcastId = await scheduleWithKit(draft, tier); // Mark as Approved in Airtable (not Sent — human reviews the Kit preview before confirm) const base = new Airtable({ apiKey: env.AIRTABLE_API_KEY }).base(env.AIRTABLE_BASE_ID); await base("Newsletter Queue").update(id, { Status: "Approved", KitBroadcastId: broadcastId }); console.log(`Scheduled broadcast ${broadcastId} for topic: ${topic}`); }, }; ``` ## الخطوة 3: خطوة الموافقة ينشئ الوكيل البث في حالة المسودة في Kit ويضع علامة على سجل Airtable بـ"Approved." يرسل لي Kit إشعاراً برابط المعاينة. أنقر عليه وأقرأه، وإذا بدا صحيحاً، أؤكد الإرسال. إذا أردت تغييرات، أعدّل مباشرة في Kit. هذا هو البوابة التي تمنع الوكيل من الاستقلالية الكاملة في البريد الصادر. أثق بالمسودات في حوالي 90% من الوقت. 10% التي ألتقطها في المراجعة — نبرة غير صحيحة قليلاً، إحصاء أريد التحقق منه، رابط أريد إضافته — تستحق مراجعة 3 دقائق. ## ما يتولاه الوكيل مما لا أريد فعله مطلقاً - كتابة متغيرات سطر الموضوع واختيار الأفضل - تنسيق نص ما قبل الرأس - حساب وقت الإرسال المناسب (جمهوري يفتح صباح الخميس؛ الوكيل يعرف ذلك) - التقسيم بشكل صحيح بناءً على مستوى الموضوع - تسجيل كل شيء في Airtable للاحتفاظ بسجل ## ما لا يزال ملكي *الفكرة*. الموضوع في قائمة الانتظار ملكي. الزاوية ملكي. الوكيل منفّذ ممتاز لموجز واضح؛ إنه ليس طبقة استراتيجية. إذا وضعت موضوعاً سيئاً في القائمة، أحصل على نشرة بريدية مكتوبة جيداً عن موضوع سيئ. أيضاً: بوابة المراجعة الأولى. كل إرسال يمر أمام عيني قبل خروجه. هذا لن يتغير. ## خلاصة المشغّل إذا كنت تقضي أكثر من ساعة أسبوعياً في ميكانيكيات النشرة البريدية — التنسيق والجدولة والتقسيم — فيجب أن تؤتمتها. واجهة برمجة تطبيقات Kit نظيفة، ومشغّل Worker cron صلب كالصخرة، وجودة مسودة Claude عالية بما يكفي لأوافق على نحو 90% من المسودات الأولى دون تغييرات. ابنِ القائمة في Airtable، وصِل Worker، وعُد إلى إنشاء الأفكار بدلاً من تنفيذ الإرسال. --- ## كيف تتصدر البحث الذكي دون كتابة منشور مدونة جديد واحد Source: https://alejandrorioja.com/ar/how-to-rank-in-ai-search-without-writing-a-single-new-blog-post/ Published: 2026-06-06 Updated: 2026-06-06 Tags: GEO, SEO TL;DR: تستشهد محركات الذكاء الاصطناعي بالمحتوى الذي يجيب على الأسئلة مباشرةً، ويدّعي توثيقاً واضحاً للمؤلف، ويهيكل المعرفة بطريقة تيسّر الاسترجاع. يمكن تهيئة معظم منشورات المدونة الحالية لتلبية الأهداف الثلاثة بالتحرير لا إعادة الكتابة. الخطة: إضافة TL;DR مباشر، وتعزيز إشارات الكيانات، وإضافة مخطط FAQ، والتقديم إلى llms.txt. المحتوى الجديد اختياري؛ إعادة الهيكلة ليست كذلك. ## جدول المحتويات _محدّث يونيو 2026._ **TL;DR:** تستشهد محركات الذكاء الاصطناعي بالمحتوى الذي يجيب على الأسئلة مباشرةً، ويدّعي توثيقاً واضحاً للمؤلف، ويهيكل المعرفة بطريقة تيسّر الاسترجاع. يمكن تهيئة معظم منشورات المدونة الحالية لتلبية الأهداف الثلاثة بالتحرير لا إعادة الكتابة. الخطة: إضافة TL;DR مباشر، وتعزيز إشارات الكيانات، وإضافة مخطط FAQ، والتقديم إلى llms.txt. المحتوى الجديد اختياري؛ إعادة الهيكلة ليست كذلك. **[قراءة المشغّل]** طبّقت هذه العملية على 341 منشوراً موجوداً قبل كتابة مقال واحد جديد يستهدف GEO. ارتفعت الاستشهادات في ChatGPT وPerplexity. أسرع المحتوى الجديد من المكاسب — لكن مراجعة المحتوى الموجود كانت نقطة انطلاقي، وأعطت نتائج أسرع مما توقعت. ## لماذا لا تستشهد محركات الذكاء الاصطناعي بمحتواك الموجود قبل كتابة أي شيء جديد، اسأل: لماذا ما أملكه بالفعل لا يُستشهد به؟ الجواب لا يكون تقريباً أبداً "المحتوى غير موجود." في الغالب يكون واحداً من هذه: 1. **لا إجابة مباشرة في الأعلى** — المنشور يدفن الإجابة في الفقرة السادسة 2. **إشارات توثيق المؤلف ضعيفة** — لا كيان مؤلف واضح، لا اعتمادات في المحتوى 3. **ضوضاء هيكلية** — مقدمات طويلة، أقسام غير ذات صلة، لا تسلسل هرمي واضح للعناوين 4. **لا أسئلة وأجوبة قابلة للقراءة آلياً** — محركات الذكاء الاصطناعي تُفضّل أزواج الأسئلة والأجوبة المهيكلة؛ معظم منشورات المدونة لا تمتلكها 5. **ليس في أي فهرس قابل للقراءة بالذكاء الاصطناعي** — لا llms.txt، ولا خرائط المواقع التي تجدها الزاحفات الخمسة قابلة للإصلاح على المحتوى الموجود. لا أحد منها يتطلب منشوراً جديداً. ## عملية التهيئة في أربع خطوات ### الخطوة الأولى: إضافة TL;DR مباشر في أول 100 كلمة تفعل محركات الذكاء الاصطناعي شيئاً مماثلاً لما تفعله عند التصفح السريع — تبحث عن الإجابة المباشرة قبل الغوص أعمق. إذا بدأ منشورك بقصة، أو سؤال، أو تمهيد سياقي، فقد لا يقرأ النموذج بعيداً بما يكفي ليجد إجابتك الفعلية. الإصلاح: أضف كتلة **TL;DR** في أول 100 كلمة. الصيغة: الاستنتاج ← السبب ← القيد أو التحفظ. جملتان إلى أربع جمل. لا حشو. مثال قبل: > *هل تساءلت يوماً لماذا تبدو بعض الشركات وكأنها تسيطر على نتائج بحث Google؟ في هذا المنشور، سنستكشف الاستراتيجيات التي تستخدمها المواقع الأعلى ترتيباً...* مثال بعد: > **TL;DR:** ثلاثة أشياء تحرك الإبرة لـSEO المحلي في 2026: اكتمال الملف التجاري على Google، واتساق الاستشهادات عبر الأدلة، والمخطط المنظم لبيانات NAP الخاصة بك. التكتيكات مثل "النشر كل يوم" و"الحصول على 100 تقييم بسرعة" ثانوية مقارنة بهذه الثلاثة. السقف هو دقة GBP الخاص بك — أصلح ذلك أولاً. إعادة الكتابة ليست أطول. إنها فقط محمّلة في المقدمة. ### الخطوة الثانية: تعزيز إشارات الكيانات تبني محركات الذكاء الاصطناعي رسماً بيانياً للمعرفة. تريد أن تعرف: من كتب هذا، وما موضوعه، وهل المؤلف موثوق به في هذا الموضوع؟ لكيان المؤلف: تأكد من أن صفحة "عن" مرتبطة من كل منشور، وأن مخطط المؤلف يتضمن روابط `sameAs` إلى LinkedIn وTwitter، وأن سيرة المؤلف في كل منشور تذكر اعتمادات محددة (ليس "متخصص تسويق" — "أدار SEO لثلاث شركات SaaS من 0 إلى 100K زيارة شهرية"). لكيان الموضوع: استخدم المصطلحات الدقيقة التي يبحث عنها جمهورك. إذا كنت تتناول "GEO" (تحسين محرك التوليد)، قل "تحسين محرك التوليد" في مكان ما، لا الاختصار فحسب. تستخدم النماذج التشابك في المصطلحات لتصنيف المحتوى. ### الخطوة الثالثة: إضافة مخطط FAQ لكل منشور يجيب على أسئلة مخطط FAQPage هو نوع المخطط الأعلى رافعةً للاستشهادات في GEO لأنه يربط السؤال بالإجابة صراحةً بصيغة يمكن للنماذج تحليلها مباشرةً. خذ 3–5 أسئلة يجيب عنها منشورك ضمنياً واجعلها صريحة: ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How long does it take to rank in AI search?", "acceptedAnswer": { "@type": "Answer", "text": "Most sites see initial citation improvements within 4–8 weeks of restructuring existing content for direct answers and adding FAQ schema. Brand-new domains take longer — expect 3–6 months before consistent citations appear." } } ] } ``` أضف هذا إلى `` منشورك أو عبر حقل المخطط في CMS الخاص بك. كل محرك ذكاء اصطناعي رئيسي يزحف ويحلل هذا. ### الخطوة الرابعة: التقديم إلى llms.txt وفهرس الذكاء الاصطناعي لمنصتك `llms.txt` معيار ناشئ — ملف نصي عادي على `موقعك.com/llms.txt` يخبر زاحفات الذكاء الاصطناعي بالمحتوى عالي الجودة وكيفية إعطاء الأولوية له. إنه مماثل لـ `robots.txt` لكن للنماذج اللغوية الكبيرة. llms.txt أساسي: ``` # llms.txt # alejandrorioja.com — AI agents and GEO for operators ## Priority content - /blog/geo-for-local-business (definitive guide, updated monthly) - /blog/schema-markup-for-ai-engines (technical reference) - /blog/how-to-get-cited-by-chatgpt (step-by-step) ## Author Alejandro Rioja — operator, AI agent builder, GEO practitioner. LinkedIn: https://linkedin.com/in/alejandrorioja ``` اقرنه بخريطة موقع نظيفة تتضمن طوابع زمنية `lastmod`. تُقلّل زاحفات الذكاء الاصطناعي من أولوية المحتوى الذي يبدو قديماً. ## كيف تحدد أولويات المنشورات التي يجب تهيئتها ليس كل منشور يستحق التهيئة. ركّز جولتك الأولى على: 1. **المنشورات التي تتصدر بالفعل الصفحة الأولى لكلمة مفتاحية بصيغة سؤال** — هذه الأقرب للاستشهاد؛ تحتاج فقط إلى إصلاح البنية 2. **المنشورات حول مواضيع أنت موثوق بشكل موثّق فيها** — تُعطي محركات الذكاء الاصطناعي وزناً كبيراً للتأليف؛ المنشور الذي اعتماداتك ذات صلة فيه يكتسب دفعة استشهاد من إشارات الكيانات 3. **المنشورات التي تجيب مباشرةً على سؤال مقابل المنشورات التي تُعلّم** — "كيف تفعل X" و"ما هو X" يُهيَّآن أفضل من قوائم المحتوى أو قطع الرأي استخدم بيانات Search Console: صفّح للاستعلامات التي هي أسئلة (كيف، ما هو، لماذا، أفضل طريقة). المنشورات المتراوحة بين 5 و15 لتلك الاستعلامات هي أفضل مرشحين للتهيئة — ذات صلة لكن ليست قريبة بما يكفي من القمة لتُستشهد بها. ## الخطأ الذي يرتكبه معظم الناس يكتبون منشوراً جديداً محسّناً للبحث الذكي قبل تهيئة أرشيفهم الموجود. المحتوى الجديد يساعد، لكن المنشورات الموجودة لها العمر والروابط الخارجية وتاريخ الزحف في صالحها. منشور عمره ثلاث سنوات بهيكل جيد سيتفوق على منشور جديد حول الموضوع ذاته لأشهر. افعل التهيئة أولاً. اكتب محتوى جديداً حيث توجد ثغرات حقيقية — أسئلة لا تجيب عنها منشوراتك الحالية إطلاقاً. ذلك هو الوقت الذي يتفوق فيه الجديد على القديم. ## خلاصة المشغّل إذا كان لديك أكثر من 20 منشوراً موجوداً في المدونة، فعملك في GEO يبدأ بالمراجعة والتهيئة، لا بتقويم المحتوى. أضف TL;DRs، وعزّز إشارات الكيانات، وأضف مخطط FAQ، وقدّم إلى llms.txt. افعل ذلك على أفضل 20 منشوراً لديك قبل كتابة أي شيء جديد. ستشهد تحسينات في الاستشهادات خلال أسابيع لا أشهر — وسيكون لديك خط أساس أنظف لقياس ما إذا كان المحتوى الجديد يحرك الإبرة فعلاً. --- ## بنيتُ مهارة Claude تُدير إعلاناتي على فيسبوك — وهذا هو الكود Source: https://alejandrorioja.com/ar/i-built-a-claude-skill-that-runs-my-facebook-ads-heres-the-code/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents TL;DR: بنيتُ مهارة Claude تقرأ حساب Meta Ads الخاص بي عبر Graph API، وتُحدد الإعلانات ضعيفة الأداء، وتُعيد كتابة نصوص الإعلانات بأسلوب علامتي التجارية، وتنشئ مجموعات إعلانية جديدة دون أن أفتح مدير الإعلانات. المشروع بأكمله أقل من 300 سطر من TypeScript. كان العائد فورياً: خفّضتُ وقت إدارة الإعلانات الأسبوعي من نحو 3 ساعات إلى نحو 20 دقيقة. ## جدول المحتويات _محدَّث يونيو 2026._ **TL;DR:** بنيتُ مهارة Claude تقرأ حساب Meta Ads الخاص بي عبر Graph API، وتُحدد الإعلانات ضعيفة الأداء، وتُعيد كتابة نصوص الإعلانات بأسلوب علامتي التجارية، وتنشئ مجموعات إعلانية جديدة دون أن أفتح مدير الإعلانات. المشروع بأكمله أقل من 300 سطر من TypeScript. كان العائد فورياً: خفّضتُ وقت إدارة الإعلانات الأسبوعي من نحو 3 ساعات إلى نحو 20 دقيقة. **[قراءة المشغّل]** أُدير إعلانات لـ Pickleland ولعلامتي التجارية في الاستشارات. حسابان، جماهير مختلفة، إرهاق إبداعي مستمر. كنتُ أُمضي بعد ظهر الأحد في مدير الإعلانات أفعل أشياء ينبغي للنموذج أن يفعلها. فأتمتّها. ## لماذا توقّفتُ عن إدارة إعلانات فيسبوك يدوياً ينقسم العمل الفعلي في إدارة إعلانات فيسبوك إلى ثلاثة أعمال: 1. **المراقبة** — التحقق من أيّ مجموعات الإعلانات تحرق المال وأيّها تجنيه 2. **التشخيص** — معرفة *لماذا* يُقصّر شيء ما (إرهاق إبداعي؟ استهداف سيئ؟ صفحة الهبوط؟) 3. **التكرار** — كتابة نصوص جديدة، وإنشاء مجموعات إعلانية جديدة، وتعديل الميزانيات العمل 1 آليّ. العمل 3 آليّ في معظمه (مع قيد صوتي). العمل 2 يتطلب حكماً — وهو الوحيد الذي يستفيد من وجود إنسان في الحلقة. تستطيع مهارة Claude أداء 1 و3. أُراجع مخرجات العمل 2 قبل نشر أي شيء. هذا هو التصميم الذي توصّلتُ إليه. ## إعداد Meta Graph API (هذا هو الجزء المزعج) قبل أي كود: تحتاج حساب Meta Business، ومستخدم نظام، ورمز وصول دائم. بوابة المطوّرين في فيسبوك معادية لكن المسار هو: 1. إنشاء **Meta App** على developers.facebook.com (النوع: Business) 2. إضافة منتج **Marketing API** 3. في محفظة الأعمال ← الإعدادات ← المستخدمون ← مستخدمو النظام، أنشئ مستخدم نظام وامنحه دور `ADVERTISER` على حساب إعلاناتك 4. أنشئ رمزاً بهذه الأذونات: `ads_read`، `ads_management`، `business_management` احفظ الرمز كـ `META_ACCESS_TOKEN` ومعرّف حساب إعلاناتك (الصيغة: `act_XXXXXXXX`) كـ `META_AD_ACCOUNT_ID` في ملف `.env`. ## هيكل ملفات المهارة ``` .claude/skills/fb-ads/ SKILL.md ← التعليمات التي يقرأها Claude index.ts ← التنفيذ الفعلي للأداة types.ts ← الأنواع المشتركة ``` ملف `SKILL.md` هو ما يُخبر Claude متى وكيف يستخدم المهارة. ملفي يقول: ```markdown # Facebook Ads Manager Skill Use this skill when the user says "check my ads", "run ads report", "pause underperformers", or "write new ad copy". Never run this without explicit user instruction — it touches live ad spend. ## What it can do - Pull performance data for all active ad sets (last 7 or 30 days) - Flag ad sets with ROAS < 1.5 or CTR < 0.8% as underperformers - Rewrite ad copy for flagged creatives in Ale's voice - Create new ad sets with revised copy (PAUSED by default — you approve before activating) ## What it will NOT do - Change budgets on live ad sets without explicit confirmation - Activate new ad sets automatically - Delete anything ``` قيد "لا تُفعِّل تلقائياً أبداً" غير قابل للتفاوض. تنشئ هذه المهارة الأشياء في حالة PAUSED. أُراجع وأُفعِّل يدوياً. أي شيء يمسّ الإنفاق الإعلاني المباشر يحتاج نقطة تفتيش بشرية. ## كود TypeScript الأساسي (تبقى كتل الكود بالإنجليزية — يُترجم النص المحيط بها فقط.) ## كيف أستخدمه يومياً تُستدعى المهارة من Claude Code (أداتي اليومية). جلسة نموذجية صباح الاثنين: ``` > check my ads from the last 7 days ``` يُشغّل Claude `runAdsReport(7)`، ويُنسّق النتائج في جدول، ويُضع علامة على ضعيفي الأداء، ويسأل إن كنتُ أريد إعادة كتابة. أقول نعم. يُولّد نصوصاً جديدة، ويُريني كلا الإصدارين جنباً إلى جنب، وينشئ مجموعات إعلانية PAUSED بالكريتيف الجديد. أُراجعها في مدير الإعلانات، وأُفعّل ما يُعجبني، وأُرشفة الخاسرين. الوقت الإجمالي: 20 دقيقة. صفر من بعد ظهر الأحد في مدير الإعلانات. ## ما لا تحلّ محلّه هذه المهارة لا تستطيع المهارة أن تُخبرني إن كانت مشكلة ملاءمة المنتج للسوق تتنكّر كمشكلة نصوص. إذا كان ROAS سيئاً في كل مكان، فذلك مشكلة قمع أو عرض وليس مشكلة عنوان. سيُعيد Claude كتابة النصوص بأمانة على قمع معطوب — وإعادة الكتابة لن تُنقذه. خطوة التشخيص لا تزال من مسؤوليتي. أقرأ التقرير، وأُطالع بيانات القمع، وأُقرر ما إذا كنا نكرّر الكريتيف أم نحلّ مشكلة في المنبع. العميل سريع في كل شيء *إلا* تلك الحكمة. ## خلاصة المشغّل إذا كنتَ تُدير الإعلانات يدوياً وتفتح مدير الإعلانات أكثر من مرتين في الأسبوع، فأنتَ تؤدي عمليات ينبغي للبرنامج النصي أن يفعلها. Graph API موثّقة بشكل جيد، وتدفق أذونات Meta، رغم إزعاجه، إعداد لمرة واحدة. ابنِ المهارة في فترة ما بعد الظهر. العائد في الوقت المُستعاد يظهر في الأسبوع الأول. --- ## أدوات الذكاء الاصطناعي الخمس التي أستخدمها فعلاً لإدارة أعمالي (2026) Source: https://alejandrorioja.com/ar/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents, Growth TL;DR: خمس أدوات: Claude (طبقة المشغّل + البرمجة)، وCursor (تطوير TypeScript)، وAirtable (العمود الفقري للبيانات لجميع الوكلاء)، وKit (النشرة الإخبارية + أتمتة البريد الإلكتروني)، وCloudflare Workers (استضافة الوكلاء). كل ما جربته قد استُبدل بإحدى هذه الأدوات أو حُذف كلياً. هذا هو المكدس الذي سأعيد بناءه لو كان عليّ أن أبدأ من الصفر اليوم. ## جدول المحتويات _محدّث يونيو 2026._ **TL;DR:** خمس أدوات: Claude (طبقة المشغّل + البرمجة)، وCursor (تطوير TypeScript)، و[Airtable](/recommends/airtable) (العمود الفقري للبيانات لجميع الوكلاء)، و[Kit](/recommends/convertkit) (النشرة الإخبارية + أتمتة البريد الإلكتروني)، وCloudflare Workers (استضافة الوكلاء). كل ما جربته قد استُبدل بإحدى هذه الأدوات أو حُذف كلياً. هذا هو المكدس الذي سأعيد بناءه لو كان عليّ أن أبدأ من الصفر اليوم. **[قراءة المشغّل]** أدير عملين: علامة استشارية شخصية في مجال الذكاء الاصطناعي (alejandrorioja.com)، ومنشأة Pickleland للبيكلبول في بفلوغرفيل، تكساس. سياقات مختلفة، جماهير مختلفة، عمليات مختلفة. هذه الأدوات الخمس تُشغّل كليهما. لا أذكرها لأنها رائجة؛ بل أذكرها لأنني حذفت بدائلها. ## 1. Claude — طبقة المشغّل Claude (عبر Claude Code وAnthropic SDK) هو عقل كل ما يتحرك. أستخدمه في ثلاثة أوضاع: **Claude Code** هو محرّكي اليومي للتطوير. أكتب TypeScript، وأبني الوكلاء، وأصحّح مشكلات البنية التحتية، وأدير المحتوى — كل ذلك من واجهة Claude Code. ليس مجرد إكمال تلقائي؛ إنه متعاون يستطيع قراءة ملف من 500 سطر، وفهم النية، واقتراح إعادة هيكلة لم أكن قد فكرت فيها. **Anthropic SDK** يُشغّل كل وكيل بنيته. وكيل نشرتي الإخبارية، ومهارة إعلاناتي على Facebook، وخط أنابيب المحتوى الخاص بي، ومولّد بطاقة OG الخاصة بي — كلها Claude في الخلفية. جودة النموذج عالية بما يكفي لأن أثق بالمسودات الأولى نحو 85% من الوقت. **حكم Claude على الصوت والعلامة التجارية** مُقلَّل التقدير. عندما أكتب شيئاً يحتاج أن يبدو مثلي، وجدت أن Claude + موجّه نظام مفصّل يتفوق على كل نموذج آخر اختبرته. الحيلة هي موجّه نظام محدد وذو رأي — ليس "اكتب بنبرة عفوية" بل "اكتب مثل أليخاندرو: مباشر، ممارس، بلا مبالغة، مرقّم، بضمير المتكلم، مع تحفظات صادقة." أدفع مقابل Claude Max. إنه الاشتراك الأكثر استخداماً لديّ، والعائد على الاستثمار لا يُقارَن. ## 2. Cursor — حيث يُكتب TypeScript Cursor هو بيئة التطوير المتكاملة. انتقلت من VS Code منذ نحو عام ولم أنظر إلى الوراء. إكمال التبويب سريع بما يكفي لتغيير طريقة كتابتي للكود فعلاً — أفكر على مستوى أعلى وأترك Cursor يتعامل مع الكود المتكرر. عرض الفروق لاقتراحات الذكاء الاصطناعي نظيف. نافذة السياق متعددة الملفات تعني أنني أستطيع أن أطلب منه تحديث دالة فيُحدِّث المستدعين أيضاً. لا أستخدم Cursor لقرارات الهندسة المعمارية. ما زلت أرسمها على ورق أو في Claude. لكن بمجرد أن يكون التصميم واضحاً، يكون Cursor أسرع مسار من التصميم إلى TypeScript تعمل. أكبر إلغاء قفل: Cursor + Claude Code بالتوازي. أستخدم Claude Code للتخطيط عالي المستوى وتنسيق الوكلاء؛ وأستخدم Cursor لعمل تفاصيل التنفيذ. لا يتعارضان — يغطيان مستويات مختلفة. ## 3. Airtable — العمود الفقري للبيانات كل وكيل ذكاء اصطناعي أشغّله يحتاج مكاناً للقراءة والكتابة. ذلك المكان هو [Airtable](/recommends/airtable). هذا ما أستخدمه لأجله عبر كلا العملين: - **قائمة انتظار المحتوى** — المنشورات وموضوعات النشرة الإخبارية قيد التقدم، مع تتبع الحالة - **سجلات الحجز** — حجوزات ملاعب Pickleland المتزامنة من نظام الحجز - **كتالوج روابط الشركاء التابعين** — أكثر من 105 slug مع بيانات وصفية يقرأها وكيل المحتوى وقت التوليد - **سجل تدقيق الوكيل** — ما الذي شُغِّل، ومتى، وما الذي أنتجه، وأي أخطاء الواجهة البرمجية نظيفة وسريعة. Airtable ليست قاعدة بيانات لأحمال العمل عالية الإنتاجية — لكن لجداول الوكلاء الجانبية، وقوائم انتظار المراجعة، وسير عمل الموافقة بمشاركة الإنسان، فهي الأداة الصحيحة تماماً. الواجهة المرئية تعني أنني أستطيع فحص أي جدول دون كتابة استعلام. البديل الذي جربته: قواعد بيانات Notion. واجهة Notion البرمجية أبطأ ونموذج البيانات أكثر ثقلاً لقراءات الوكلاء. Airtable يفوز للبيانات المجاورة للوكلاء. ## 4. Kit — النشرة الإخبارية وأتمتة البريد الإلكتروني انتقلت إلى [Kit](/recommends/convertkit) (المعروف سابقاً بـ ConvertKit) لسبب واحد: الواجهة البرمجية جيدة فعلاً. معظم منصات البريد الإلكتروني تعامل واجهتها البرمجية كفكرة لاحقة. Kit تعاملها كمنتج من الدرجة الأولى. أستطيع إنشاء بثوث، وجدولة إرسال، وتقسيم حسب العلامة، وقراءة التحليلات — كلها برمجياً. وكيل نشرتي الإخبارية يقوم بكل هذا دون أن أقترب من المحرر. الأشياء الخاصة بـ Kit التي أستخدمها: - **واجهة Broadcasts البرمجية** — وكيلي يُنشئ بثوثاً مجدولة برمجياً كل أسبوع - **وضع علامات على المشتركين** — أضع علامات على المشتركين حسب السلوك (فتح آخر 5 إرسالات = "منخرط"؛ لم يفتح في 60 يوماً = "معرّض للخطر") ويستهدف وكيلي الشرائح وفق ذلك - **النماذج + صفحات الهبوط** — نظيفة، سريعة التحميل، بدون كود. لا أتعامل معها برمجياً؛ تعمل فحسب. إذا كنت على Mailchimp أو منصة قديمة: الهجرة تستحق العناء. تتطلب واجهة Mailchimp البرمجية ثلاث استدعاءات إضافية لفعل ما يفعله Kit في استدعاء واحد. ## 5. Cloudflare Workers — حيث تعيش الوكلاء كل وكيل مجدول يعمل على Cloudflare Workers. الحجة: نشر حافة عالمي، وصفر بدايات باردة على المستوى المجاني، ونظام مشغّل cron يعمل فعلاً. وكلائي لا يحتاجون خادماً. يحتاجون دالة مجدولة تعمل بشكل موثوق، وتستطيع إجراء استدعاءات API خارجية، وتكلف ما يقارب الصفر عند حجمي. Workers هو الجواب. ما أشغّله على Workers: - **خط أنابيب المحتوى** — يُولّد منشوراً بالإنجليزية، ويوزّعه على 12 ترجمة، ويُولّد بطاقة OG - **وكيل النشرة الإخبارية** — يصيغ ويجدول الإرسال الأسبوعي - **مراقب إعلانات Facebook** — يقرأ الأداء، يضع علامة على المتخلفين، يُخطرني - **مراقب الإشغال في Pickleland** — يقرأ بيانات الحجز، يرسل لي ملخصاً يومياً إجمالي التكلفة الشهرية لكل هذا: ~5 دولار. هذه خطة Workers المدفوعة. تعمل الوكلاء بشكل موثوق وفق جدول cron؛ كان لديّ خلل واحد في ستة أشهر (مشكلة DNS من جانب Meta، ليس من جانبي). ## ما حذفته ولماذا **Zapier** — استُبدل بـ Workers + واجهات API للمنصات المعنية مباشرة. يضيف Zapier زمن استجابة، يكلف أكثر عند التوسع، وله سقف لا يملكه Workers. **ChatGPT** — نافذة السياق لدى Claude، واستخدام الأدوات، وجودة موجّه النظام أفضل لحالة استخدام المشغّل. أحتفظ بتبويب ChatGPT للبحث السريع على الويب لكنني لا أبني عليه. **Webflow** — نقلت موقعي إلى Astro + Cloudflare Pages. مزيد من التحكم، أداء أفضل، عملية بناء يمكن تشغيلها نصياً. **Grammarly** — يفعل Claude كل ما يفعله Grammarly ويحافظ على صوتي بشكل أفضل. ## خلاصة المشغّل الأدوات الخمس أعلاه ليست الأحدث ولا الأكثر نقاشاً. إنها الأدوات التي صمدت أمام الاستخدام اليومي في الإنتاج عبر عملين مختلفين. قبل إضافة أداة جديدة إلى مكدسك، اسأل: أيٌّ من هذه الخمس يستطيع القيام بهذا العمل؟ ستندهش من مدى تكرار الإجابة "إحداها تستطيع بالفعل." --- ## لماذا يستمر وكيل الذكاء الاصطناعي في الفشل في بيئة الإنتاج (وكيفية إصلاحه) Source: https://alejandrorioja.com/ar/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents TL;DR: تأتي معظم إخفاقات الوكلاء في الإنتاج من خمسة أسباب: موجّهات هشّة لا تعالج الحالات الحدية، ومنطق إعادة المحاولة المفقود لأخطاء API العابرة، وانعدام الرؤية التشغيلية لرؤية ما يتعطل، والحلقات الجامحة بلا شرط خروج، وتعريفات الأدوات الغامضة بما يكفي لجعل النموذج يختار الخاطئ. الخمسة قابلة للإصلاح دون تغيير النماذج أو الأطر. ## جدول المحتويات _محدّث يونيو 2026._ **TL;DR:** تأتي معظم إخفاقات الوكلاء في الإنتاج من خمسة أسباب: موجّهات هشّة لا تعالج الحالات الحدية، ومنطق إعادة المحاولة المفقود لأخطاء API العابرة، وانعدام الرؤية التشغيلية لرؤية ما يتعطل، والحلقات الجامحة بلا شرط خروج، وتعريفات الأدوات الغامضة بما يكفي لجعل النموذج يختار الخاطئ. الخمسة قابلة للإصلاح دون تغيير النماذج أو الأطر. **[قراءة المشغّل]** أدير أكثر من 30 وكيلاً في بيئة الإنتاج. لقد عانيت من جميع هذه الإخفاقات. تلك التي أهدرت أكثر وقت لم تكن الغريبة منها — بل كانت إخفاقات البنية التحتية المملة التي ظننت أنني تعاملت معها. ## الإخفاق الأول: موجّهات هشّة تنهار عند مدخلات الحالات الحدية الموجّه الذي يعمل في حالات الاختبار الخاصة بك سيفشل عند مدخلات لم تتوقعها. هذه ليست قيوداً في النموذج — إنها مشكلة كتابة التعليمات. **الأعراض:** ينتج الوكيل مخرجات عشوائية، أو يستدعي الأداة الخاطئة، أو يخرج JSON مشوهاً عندما تختلف المدخلات قليلاً عمّا اختبرته. **السبب الجذري:** يصف موجّه النظام مسار السعادة فحسب. لا يخبر النموذج بما يجب فعله عندما تكون البيانات مفقودة أو مشوهة أو غامضة. **الإصلاح:** أضف معالجة صريحة للحالات الحدية في موجّه نظامك: ``` If the input data is missing a required field, return: { "status": "error", "reason": "missing_field", "field": "" } Do NOT attempt to infer or hallucinate missing values. If you are uncertain which tool to call, call no tool and return: { "status": "clarification_needed", "question": "..." } ``` يتبع النموذج التعليمات الصريحة للحالات الحدية بشكل موثوق. الخطأ هو الافتراض بأنه سيعمّم تعليمات مسار السعادة لمعالجة الحالات الفوضوية. ## الإخفاق الثاني: لا منطق لإعادة المحاولة لأخطاء API العابرة كل API خارجي يستدعيه وكيلك سيفشل في مرحلة ما. واجهة Claude البرمجية، وMeta Graph API، وقاعدة بياناتك — جميعها ترجع أخطاء 5xx، أو تنتهي مهلتها، أو تحد من المعدل. إذا لم يكن لدى وكيلك منطق لإعادة المحاولة، فإن خطأً عابراً واحداً يقتل التشغيل كله. **الأعراض:** تفشل تشغيلات الوكيل بشكل عشوائي في خطوات مختلفة. تُظهر السجلات 503 أو 429 بدون محاولة متابعة. **الإصلاح:** قم بتغليف كل استدعاء خارجي في إعادة محاولة مع تراجع أسي: ```typescript async function withRetry(fn: () => Promise, retries = 3, baseDelayMs = 500): Promise { for (let attempt = 0; attempt <= retries; attempt++) { try { return await fn(); } catch (err: any) { const isTransient = err.status === 429 || err.status >= 500 || err.code === "ECONNRESET"; if (!isTransient || attempt === retries) throw err; const delay = baseDelayMs * Math.pow(2, attempt) + Math.random() * 100; await new Promise((r) => setTimeout(r, delay)); } } throw new Error("unreachable"); } // Usage const result = await withRetry(() => client.messages.create({ ... })); ``` تعالج ثلاث محاولات إعادة مع تراجع أسي ~99% من الإخفاقات العابرة. أضف هذا لكل استدعاء خارجي ونصف إخفاقاتك العشوائية ستختفي. ## الإخفاق الثالث: لا رؤية تشغيلية — لا يمكنك رؤية ما يتعطل هذا هو أكثر أوضاع الإخفاق شيوعاً في الإنتاج وأكثرها تكلفةً للتنقيح: يفشل الوكيل بصمت أو ينتج مخرجات خاطئة، وليس لديك أدنى فكرة أين في السلسلة سارت الأمور بشكل خاطئ. **الأعراض:** تعرف أن ثمة خللاً لكن لا تستطيع تحديد الخطوة. تضيف عبارات `console.log` وتعيد التشغيل يدوياً محاولاً إعادة الإنتاج. **الإصلاح:** تسجيل منظم في كل خطوة، مع معرّف تشغيل يتتبع التنفيذ بأكمله: ```typescript function createLogger(runId: string, agentName: string) { return { step: (step: string, data: object) => console.log(JSON.stringify({ runId, agent: agentName, step, ts: new Date().toISOString(), ...data })), error: (step: string, err: unknown) => console.error(JSON.stringify({ runId, agent: agentName, step, error: String(err), ts: new Date().toISOString() })), }; } const log = createLogger(crypto.randomUUID(), "newsletter-agent"); log.step("fetch_topic", { topicId: topic.id, topic: topic.name }); // ... do work ... log.step("draft_complete", { subject: draft.subject, wordCount: draft.body.split(" ").length }); ``` إذا كنت على Cloudflare Workers، تذهب هذه السجلات إلى Logpush أو Workers Tail. إذا كنت تعمل محلياً أو على VPS، أرسلها إلى مجمّع سجلات. JSON المنظم يعني أنك تستطيع التصفية بـ `runId` لرؤية ما حدث بالضبط في تشغيل واحد. ## الإخفاق الرابع: حلقات جامحة بلا شرط خروج الحلقات العاملة بشكل وكيل — حيث يستدعي النموذج الأدوات ويكرر حتى يتحقق شرط — يمكن أن تعمل للأبد إذا لم يتحقق ذلك الشرط أبداً أو أخطأ النموذج في تحديده. **الأعراض:** ينفق الوكيل مئات الدولارات في تكاليف API قبل انتهاء المهلة. أو يُشغّل نفس استدعاء الأداة مراراً وتكراراً دون إحراز تقدم. **الإصلاح:** احرص دائماً على وجود حد صارم للتكرارات وفحص للتقدم: ```typescript const MAX_ITERATIONS = 10; let iterations = 0; let lastToolCallName = ""; let sameToolCallCount = 0; while (true) { iterations++; if (iterations > MAX_ITERATIONS) { log.error("loop", { reason: "exceeded_max_iterations" }); break; } const response = await client.messages.create({ ... }); // Detect stuck loops: same tool called 3x in a row const toolCall = response.content.find(b => b.type === "tool_use"); if (toolCall?.name === lastToolCallName) { sameToolCallCount++; if (sameToolCallCount >= 3) { log.error("loop", { reason: "stuck_loop", tool: toolCall.name }); break; } } else { sameToolCallCount = 0; lastToolCallName = toolCall?.name ?? ""; } if (response.stop_reason === "end_turn") break; } ``` يلتقط هذا كلا وضعي الإخفاق: "عمل وقتاً طويلاً جداً" و"دار في المكان". يجب أن يكون الحد سخياً بما يكفي لمسار السعادة لكن ضيقاً بما يكفي للحدّ من نطاق الضرر. ## الإخفاق الخامس: تعريفات أدوات غامضة يحلها النموذج خطأ إذا أعطيت النموذج أداتين بأوصاف متداخلة، فسيستدعي أحياناً الخاطئة. هذا شائع بشكل خاص مع أدوات مثل `search_database` مقابل `get_record` أو `send_email` مقابل `create_draft`. **الأعراض:** يستدعي النموذج الفئة الصحيحة من الأدوات لكن يختار الأداة المحددة الخاطئة. أو يستدعي أداة في سياق خاطئ (استخدام أداة كتابة عندما كانت القراءة فقط مناسبة). **الإصلاح:** اجعل أوصاف الأدوات متنافية تبادلياً وأضف صراحةً "متى لا تستخدم هذا": ```typescript const tools = [ { name: "get_subscriber", description: "Fetch a single subscriber record by email. Use ONLY when you have a specific email address. Do NOT use for searching or listing subscribers.", input_schema: { ... } }, { name: "search_subscribers", description: "Search subscribers by tag, segment, or status. Use when you need to find subscribers matching a criteria — NOT when you have a specific email address.", input_schema: { ... } } ]; ``` بند "لا تستخدم عندما X" هو الجزء الذي يتخطاه معظم الناس. إنه أهم جزء. النماذج أفضل في اتباع القيود السلبية الصريحة من استنتاجها من الأوصاف الإيجابية. ## شيء أخير: اختبر وكلاءك على مدخلات سيئة تُختبر معظم الوكلاء فقط على مدخلات نظيفة ومسار سعادة. بيئة الإنتاج لديها مدخلات متسخة: سلاسل فارغة، وحقول null، وحالات حدية لـ Unicode، واستجابات API التي ترجع 200 لكن بمخطط غير متوقع. أضف مجموعة اختبار تمرّن بشكل صريح على: - المدخلات الفارغة أو null - المدخلات بأقصى طول تتوقعه - المدخلات ذات الأحرف الخاصة أو النص غير ASCII - واجهات API الخارجية التي ترجع أشكالاً غير متوقعة للاستجابة إذا انهار وكيلك عند أي من هذه، أصلحه قبل الإطلاق. بيئة الإنتاج ستجد كل افتراض قمت به. ## خلاصة المشغّل معظم إخفاقات الوكلاء في الإنتاج هي مشكلات بنية تحتية تتنكر في هيئة مشكلات نموذج. قبل تبديل النماذج، أضف عمليات إعادة المحاولة، والتسجيل المنظم، وحدود الحلقات، ومعالجة صريحة للحالات الحدية في موجّهاتك. أصلح تعريفات الأدوات الغامضة. ثم اختبر على مدخلات سيئة. افعل كل ذلك قبل إلقاء اللوم على النموذج — في تجربتي، النموذج عادةً آخر شيء يحتاج إلى تغيير. --- ## كيف تبني أول وكيل ذكاء اصطناعي خاص بك في 15 دقيقة Source: https://alejandrorioja.com/ar/how-to-build-your-first-ai-agent-in-15-minutes/ Published: 2026-06-02 Updated: 2026-06-02 Tags: AI Agents TL;DR: لا تحتاج إلى إطار عمل أو دورة تدريبية أو شهادة دكتوراه. تحتاج إلى Node.js و SDK الخاص بـ Anthropic و25 سطرًا من TypeScript. يبني هذا الدرس وكيلًا حقيقيًا وعاملًا — ملخّص محتوى منظَّم يمكنك نشره على Cloudflare في الجلسة نفسها. الشرط الوحيد المسبق هو مفتاح API مجاني. ## جدول المحتويات _محدّث في يونيو 2026._ **الخلاصة:** لا تحتاج إلى إطار عمل أو دورة تدريبية أو شهادة دكتوراه. تحتاج إلى Node.js و SDK الخاص بـ Anthropic و25 سطرًا من TypeScript. يبني هذا الدرس وكيلًا حقيقيًا وعاملًا — ملخّص محتوى منظَّم يمكنك نشره على Cloudflare في الجلسة نفسها. الشرط الوحيد المسبق هو مفتاح API مجاني. **[قراءة المُشغِّل]** أكثر ما أسمعه من المؤسسين الذين يريدون الأتمتة باستخدام الذكاء الاصطناعي هو "عليّ أن أتعلّم المزيد أولًا". لا، لا حاجة لذلك. نمط الوكيل بسيط، وأسرع طريقة لفهمه هي أن تبني واحدًا. إليك المسار الدقيق الذي كنت سأسلكه لو بدأت من الصفر اليوم. ## لماذا تخذلك معظم دروس "ابنِ وكيل ذكاء اصطناعي" فهي إما تستخدم Python (مناسبة لمهندسي تعلّم الآلة، لكنها عائق لكل من سواهم)، أو تخفي الكود الحقيقي خلف إطار عمل مثل LangChain، أو تبني شيئًا مجرّدًا أكثر من اللازم لربطه بعملك الفعلي. يفعل هذا الدرس ثلاثة أشياء بطريقة مختلفة: 1. **TypeScript فقط** — إن سبق لك كتابة JavaScript، يمكنك متابعة هذا 2. **بلا إطار عمل** — سترى كل سطر من الكود يتعامل مع النموذج 3. **مُخرَج مفيد** — ستبني ملخِّصًا منظَّمًا يمكنك استخدامه فعليًا على رسائل العملاء أو المراجعات أو ملاحظات الاجتماعات ## ما الذي ستبنيه **وكيل تلخيص محتوى**: الصق أي كتلة نصّية، واحصل في المقابل على ملخّص منظَّم بتنسيق متّسق. طلب HTTP واحد للدخول، وملخّص نظيف واحد للخروج. لماذا هذا كمشروع أول: النمط — موجِّه النظام + مُدخَل المستخدم ← مُخرَج منظَّم — هو أساس كل وكيل أُشغّله. بدِّل موجِّه النظام وستحصل على مُجيب أسئلة، أو مُعيد صياغة نبرة، أو مُصنِّف، أو مولِّد مسوّدات. تعلّم هذا مرة واحدة وستكون قد تعلّمت 80% مما تفعله الوكلاء في بيئة الإنتاج فعليًا. ## المتطلبات المسبقة (دقيقتان) - **Node.js 18+** — تحقّق باستخدام `node --version`. ثبّته من nodejs.org إن لزم الأمر. - **مفتاح API من Anthropic** — سجّل في [Claude](/recommends/claude)، واحصل على مفتاح من وحدة التحكّم. الخطة المجانية تفي بالغرض. - طرفية ومحرّر نصوص. بلا Docker. بلا بيئة افتراضية. بلا `pip install` لأي شيء. ## الخطوة 1: إنشاء المشروع (دقيقتان) ```bash mkdir my-first-agent && cd my-first-agent npm init -y npm install @anthropic-ai/sdk npm install -D tsx typescript ``` أضف سكربتًا إلى `package.json` لتتمكّن من تشغيل الوكيل بسهولة: ```json { "scripts": { "agent": "tsx agent.ts" } } ``` ## الخطوة 2: كتابة الوكيل (5 دقائق) أنشئ `agent.ts` والصق هذا: ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY, }); const SYSTEM_PROMPT = `You are a precise content summarizer. When given any block of text, return a structured summary in this exact format: **One-line summary:** **Key points:** - - - **Action item (if any):** Be specific. No filler. Under 150 words total.`; async function summarize(text: string): Promise { const message = await client.messages.create({ model: "claude-haiku-4-5", max_tokens: 512, system: SYSTEM_PROMPT, messages: [{ role: "user", content: text }], }); const block = message.content[0]; if (block.type !== "text") throw new Error("Unexpected response type"); return block.text; } const sample = ` Hey team — following up on the Q2 review meeting. We agreed to push the launch to July 15th instead of June 30th due to the payment integration delay. Marketing needs the new landing page copy by June 20th or we can't start the email campaign. Budget for the launch campaign is confirmed at $8,000. Please confirm receipt. `; const result = await summarize(sample); console.log(result); ``` ## الخطوة 3: تشغيله (دقيقة واحدة) ```bash ANTHROPIC_API_KEY=sk-ant-... npm run agent ``` المُخرَج المتوقَّع: ``` **One-line summary:** Launch pushed to July 15th due to payment delay; landing page copy needed by June 20th to unblock email campaign. **Key points:** - Launch date moved from June 30th to July 15th - Landing page copy deadline: June 20th (blocks email campaign) - Campaign budget confirmed at $8,000 **Action item (if any):** Confirm receipt and deliver landing page copy by June 20th. ``` هذا وكيل ذكاء اصطناعي عامل. مُدخَل حقيقي، موجِّه نظام مخصَّص، مُخرَج منظَّم. المسألة برمّتها 30 سطرًا من الكود. ## الخطوة 4: خصِّصه لحالة استخدامك موجِّه النظام هو الشيء الوحيد الذي يجعل هذا الوكيل خاصًّا بك. إليك ثلاثة بدائل جاهزة للاستبدال المباشر: **مُصنِّف مراجعات العملاء:** ```text Classify this customer review as POSITIVE, NEGATIVE, or MIXED. Then extract the main complaint or praise in one sentence. Format: SENTIMENT: