دليل تعلم الذكاء الاصطناعي لعام 2026: ماذا تتعلم، ماذا تستخدم، وما الذي يجب أن تتجنبه

العنوان الأصلي: ماذا تتعلم، تبني، وتتجاوز في وكلاء الذكاء الاصطناعي (2026)
المؤلف الأصلي: Rohit
الترجمة: Peggy، BlockBeats

المؤلف الأصلي:律动BlockBeats

المصدر الأصلي:

إعادة النشر: مارس فاينانس

مقدمة المحرر: مجال وكلاء الذكاء الاصطناعي يدخل مرحلة انفجار الأدوات، وقلة التوافق.

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

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

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

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

وفيما يلي النص الأصلي:

كل يوم يظهر إطار جديد، ومعيار جديد، ومنتج «عشرة أضعاف الكفاءة» جديد. لم يعد السؤال «كيف أتابع»، بل: ما هو الإشارة الحقيقية هنا، وما هو مجرد ضوضاء تتخفى وراء الشعور بالإلحاح.

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

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

على مدى العامين الماضيين، كنت أطور منتجات في هذا المجال، وحصلت على عروض عمل بأكثر من 250 ألف دولار سنويًا، وأعمل الآن في شركة سرية مسؤولة عن التقنية. إذا سألني أحد: «ماذا يجب أن أركز عليه الآن؟»، فهذه هي النصيحة التي أرسلها له.

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

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

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

المرشح الفعّال الحقيقي

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

خلال الـ 18 شهرًا الماضية، هناك خمسة أسئلة كانت دائمًا فعالة. قبل أن تضيف شيئًا جديدًا إلى تكديسك التقني، مرّ على هذه الأسئلة الخمسة.

هل لا زال مهمًا بعد عامين؟ إذا كان مجرد غلاف لنموذج متقدم، أو معلمة CLI، أو إصدار Devin معين، فالإجابة غالبًا لا. إذا كان أصلًا أساسيًا، مثل بروتوكول، أو نمط ذاكرة، أو طريقة صندوق الرمل، فالإجابة أكثر احتمالًا نعم. الأغلفة تتدهور بسرعة، بينما القدرات الأساسية يمكن أن تدوم لسنوات.

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

هل اعتمادك عليه يعني أنك ستتخلى عن أدوات التتبع، وإعادة المحاولة، والتكوين، وأنظمة المصادقة الحالية؟ إذا كان الأمر كذلك، فهو إطار يحاول أن يصبح منصة. الإطارات التي تحاول أن تكون منصة، لديها معدل فشل يقارب 90%. القدرات الأساسية الجيدة يجب أن تندمج مع نظامك الحالي، لا أن تجبرك على الترحيل.

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

هل يمكنك قياس مدى تحسين وكيلك الحقيقي؟ إذا لم تستطع، فأنت تتخمن. الفرق بين فريق بدون تقييم وفريق يستخدم التقييم هو أن الفريق الأول يعتمد على الشعور، بينما الثاني يمكنه أن يترك البيانات تقول له: هل GPT-5.5 أفضل، أم Opus 4.7، في عبء العمل المحدد هذا الأسبوع.

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

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

ماذا تتعلم

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

الهندسة السياقية (Context Engineering)

خلال العامين الماضيين، التسمية الأهم كانت «هندسة الطلبات» (Prompt Engineering) التي تحولت إلى «الهندسة السياقية» (Context Engineering). هذا التغيير حقيقي، وليس مجرد تغيير في المصطلح.

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

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

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

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

تصميم الأدوات

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

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

مقال «كتابة أدوات للوكلاء» من Anthropic هو نقطة انطلاق جيدة. بعد قراءته، أضف ملاحظاتك على أدواتك، وراقب أنماط الاستخدام الحقيقي. أكبر تحسين في موثوقية الوكيل يحدث غالبًا على جانب الأدوات. كثير من الناس يضبطون الطلبات، لكنهم يتجاهلون العامل الأهم.

نمط المنسق-الوكيل الفرعي (Orchestrator-Subagent)

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

نظام أبحاث Anthropic يعمل بهذه الطريقة. وكلاء Claude Code الفرعيون أيضًا. Spring AI وأغلب الأطر الإنتاجية الآن تتبنى هذا النمط. الوكيل الفرعي يمتلك سياقًا صغيرًا ومركزًا، ولا يغير الحالة المشتركة. التحديثات تكون من مسؤولية المنسق.

مراجعة «لا تبني وكلاء متعددين» من Cognition و«كيف بنينا نظام أبحاث الوكلاء المتعددين» من Anthropic، تبدو كآراء متعارضة، لكنها تتحدث عن نفس المفهوم بكلمات مختلفة. كلاهما يستحق القراءة.

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

التقييمات وبيانات الذهب

كل فريق ينجح في تقديم وكيل موثوق لديه تقييم. بدون تقييم، لا يمكن أن تقدم وكيلًا موثوقًا. هذه عادة أعلى مستوى من الاستفادة، وأقل ما يُقدّر في هذا المجال.

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

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

إطارات التقييم، مثل Braintrust، Langfuse evals، وLangSmith، جيدة، لكنها ليست العقبة. العقبة الحقيقية هي وجود مجموعة بيانات موسومة. ابدأ في اليوم الأول، قبل أن توسع، ب50 عينة موسومة يدويًا. لا عذر لعدم ذلك.

استخدام نظام الملفات كحالة، ودورة فكر-تصرف-ملاحظة

بالنسبة لأي وكيل ينفذ مهامًا متعددة الخطوات، فإن البنية المستدامة هي: التفكير، العمل، الملاحظة، التكرار. نظام الملفات أو التخزين الهيكلي هو مصدر الحقيقة. كل إجراء يُسجل ويمكن إعادة تشغيله. Claude Code، Cursor، Devin، Aider، OpenHands، goose، كلها تتفق على ذلك، وليس بدون سبب.

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

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

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

فهم MCP من ناحية المفهوم

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

مؤسسة Linux تتولى الآن إدارة MCP. جميع مزودي النماذج الرئيسيين يدعمونه. يمكن أن يُشبه «USB-C للذكاء الاصطناعي»، وهو الآن أقرب إلى الحقيقة من السخرية.

الصندوق الرمل هو أصل أساسي

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

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

ماذا تستخدم للبناء

إليك الاختيارات حتى أبريل 2026. ستتغير، لكن ليس بسرعة كبيرة. في هذا المستوى، اختر دائمًا «الأشياء المملة ولكن المستقرة».

طبقة التنسيق (Orchestration Layer)

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

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

إذا كنت تفضل Pydantic، وترى أن الأمان النوعي هو أولوية، فإن Pydantic AI خيار جيد. أطلق الإصدار 1.0 في نهاية 2025، ويحقق زخمًا.

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

طبقة البروتوكول

MCP، لا شيء غيره.

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

طبقة الذاكرة

عند اختيار نظام الذاكرة، لا تعتمد على الشعبية، بل على مدى استقلالية الوكيل.

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

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

المرئية والتقييمات

Langfuse هو الخيار المفتوح المصدر الافتراضي. يمكن استضافته ذاتيًا، ويغطي التتبع، وإدارة إصدارات الطلب، والتقييمات الأساسية باستخدام نظام الحكم عبر نماذج اللغة. إذا كنت تستخدم LangChain، فإن تكامل LangSmith سيكون أكثر تكاملًا. Braintrust مناسب لعمليات التقييم البحثية، خاصة في الحالات التي تتطلب مقارنة دقيقة. OpenLLMetry / Traceloop مناسبة لمشاريع التتبع متعددة اللغات، مع دعم أدوات OpenTelemetry.

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

الوقت والتشغيل في صندوق الرمل

E2B مناسب لتنفيذ الشيفرة في صندوق الرمل بشكل عام. Browserbase مع Stagehand، مناسب لأتمتة المتصفحات. Anthropic Computer Use مناسب للمهام التي تتطلب تحكمًا كاملًا في نظام التشغيل. Modal مناسب للمهام المفاجئة قصيرة المدى.

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

النموذج

ملاحقة المعايير (Benchmark) مرهقة، وغالبًا غير مجدية. بشكل عملي، حتى أبريل 2026:

• Claude Opus 4.7 و Sonnet 4.6 مناسبان للموارد الموثوقة، والتكرار متعدد الخطوات، واستعادة الفشل بشكل أنيق. بالنسبة لمعظم الأحمال، Sonnet هو الخيار الأمثل من حيث التكلفة والأداء.

• GPT-5.4 و GPT-5.5 مناسبان لأقصى قدرات الاستنتاج عبر سطر الأوامر، أو في بيئة تعتمد على بنية OpenAI.

• Gemini 2.5 و 3 مناسبان للمهام التي تتطلب سياقًا مكثفًا، أو متعددة الوسائط.

• عندما يكون التكلفة أهم من الأداء، خاصة في المهام ذات الحدود الواضحة، يمكن النظر في DeepSeek-V3.2 أو Qwen 3.6.

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

ما الذي يمكن تجاوزه

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

AutoGen و AG2، لا تستخدمها في الإنتاج. إطار Microsoft هذا أصبح موجهًا للمجتمع، وتوقف عن التحديث، والطريقة التي يكتب بها ليست مناسبة لفرق الإنتاج. يمكن استخدامها للبحث الأكاديمي، لكن لا تربط منتجك بها.

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

Microsoft Semantic Kernel، إلا إذا كنت ملتزمًا تمامًا بتقنية Microsoft، وعميلك يهتم بذلك. هو ليس الاتجاه الذي يسير فيه النظام البيئي.

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

اعتبر وكيل كتابة الشيفرة المستقل كخيار هندسي. «Code-as-action» هو مجال بحث مثير، لكنه ليس الوضع الافتراضي في الإنتاج بعد. ستواجه العديد من أدوات الأمان، وقد لا يستخدم منافسوك ذلك.

الدعاية لـ «وكيل مستقل» (Autonomous agent). مسار AutoGPT و BabyAGI انتهى. الصناعة تتجه نحو «الهندسة الوكيلة الموجهة»، مع إشراف، وحدود، وتقييم. من يبيع «نشر ثم لا تحتاج إلى شيء»، هو في الواقع يبيع شيئًا من عام 2023.

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

لا تتبع تصنيفات SWE-bench و OSWorld. سجل باحثو Berkeley في 2025 أن معظم المعايير المفتوحة يمكن التلاعب بها، ولا تتطلب حل المهام الأساسية. الآن، يستخدم الفرق نتائج اختبار Terminal-Bench 2.0 وتقييماتها الداخلية كمؤشرات أكثر واقعية. الشك في المعايير الرقمية فقط هو السائد.

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

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

الانتظار للأطر الجديدة التي تظهر على Hacker News. انتظر ستة أشهر. إذا بقيت مهمة، ستعرف ذلك بوضوح. وإذا لم تكن مهمة، فقد وفرت على نفسك عملية ترحيل غير ضرورية.

كيفية التقدم

إذا لم تكن تريد فقط «متابعة الوكيل»، بل تريد تبنيه، فهذه هي الخطوات الفعالة. قد تبدو مملة، لكنها مجدية.

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

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

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

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

ابدأ بدورة واحدة لوكيل واحد. اختر LangGraph أو Pydantic AI. النموذج: Claude، Sonnet 4.6، أو GPT-5. أعطِ الوكيل ثلاثة إلى سبعة أدوات مصممة جيدًا. دعها تستخدم نظام ملفات أو قاعدة بيانات للحالة. أطلقها على مجموعة صغيرة من المستخدمين، وراقب التتبع.

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

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

اختر البنية التحتية المملة. أدوات MCP. صندوق الرمل E2B أو Browserbase. الحالة عبر Postgres أو أي نظام تخزين تستخدمه. المصادقة والمرئية، حاول أن تعتمد على أنظمتك الحالية. البنى التحتية الغريبة نادرًا ما تكون حاسمة، والانضباط هو المفتاح الحقيقي.

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

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

كيف تعرف التيار الحقيقي

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

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

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

ما الذي يجب مراقبته بعد ذلك

الربعان القادمان، لا تتوقع أن تفوز، بل أن تكتشف «هل هو إشارة حقيقية أم لا».

نموذج التكرار المتوازي لوكيل Replit Agent 4. هذا أحد أول الحلول التي جربت «عمل عدة وكلاء بشكل متوازي دون أن تتعثر في الحالة المشتركة». إذا نجح بعد التوسع، قد يتغير النمط الافتراضي للمنسق-الوكيل الفرعي.

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

القدرة على تغليف المهارات كطبقة قدرات. زيادة ملفات AGENTS.md و skills في GitHub، تشير إلى ظهور طريقة جديدة لتغليف قدرات الوكيل. هل ستصبح معيارًا مثل MCP، أم ستظل فكرة غير موحدة؟

مراجعة جودة Claude Code في أبريل 2026، وما بعدها. إصدار أدى إلى تراجع في الأداء بنسبة 47%، وُجد من قبل المستخدمين، واكتُشف عبر المراقبة الداخلية. هذا يوضح أن ممارسات تقييم الوكيل في الإنتاج لا تزال غير ناضجة. إذا أدى ذلك إلى استثمار الصناعة في تقييمات مباشرة أفضل، فهذه خطوة صحية.

التحول الصوتي إلى الواجهة الافتراضية للدعم. قناة Sierra الصوتية تجاوزت النصية في نهاية 2025. إذا استمر هذا الاتجاه، فإن التأخير، والمقاطعة، وتصميم أدوات التفاعل في الوقت الحقيقي، ستصبح مسائل أساسية، وسيتطلب الأمر إعادة تصميم العديد من الأنظمة.

تحسين نماذج open-source لوكلاء القدرات. دعم DeepSeek-V3.2 للـ thinking-into-tool-use، وQwen 3.6، وبيئة النماذج المفتوحة بشكل أوسع، كلها تستحق المتابعة. تكاليف المهام الضيقة تتغير، والنماذج المغلقة لم تعد دائمًا الأفضل.

كل واحدة من هذه الأمور يمكن أن ترتبط بسؤال واضح: «بعد ستة أشهر، ماذا أحتاج أن أراه لأؤكد أنه مهم حقًا؟» هذه هي الاختبار. تتبع الإجابة، وليس الإعلانات.

المراهنات غير التقليدية

كل إطار لم تعتمد عليه، هو فرصة لتجنب الترحيل المستقبلي. كل معيار لم تتتبعه، هو تركيز لربع سنة. الشركات التي تتقدم الآن — Sierra، Harvey، Cursor — اختارت أهدافًا ضيقة، وأقامت انضباطًا مملًا، ومرّت الضوضاء من حولها.

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

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

لكن الآن، لا يوجد «وجه مقابل» ثابت لهذا المجال. الشركات التي تريد الانضمام إليها قد تكون عمرها ستة أشهر فقط. الأطر التي تستخدمها قد تكون عمرها 18 شهرًا. البروتوكولات الأساسية قد تكون عمرها سنتين. نصف المقالات الأكثر استشهاد