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

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

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

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

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

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

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

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

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

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

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

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

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

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

مرشح فعال حقًا

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

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

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

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

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

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

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

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

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

ما الذي يجب تعلمه

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

هندسة السياق

في العامين الماضيين، التغيير الأهم هو أن “هندسة الطلب” أصبحت “هندسة السياق”. هذا التغيير حقيقي، وليس مجرد تسمية جديدة.

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

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

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

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

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

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

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

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

نمط المنسق-الوكيل الفرعي

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ما الذي يجب أن تستخدمه للبناء

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

طبقة التنسيق

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

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

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

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

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

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

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

طبقة الذاكرة

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

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

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

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

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

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

البيئة التشغيلية والصندوق الرملي

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

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

النموذج

ملاحقة المعايير ليست مجدية، وغالبًا لا تساعد كثيرًا. بشكل عملي، حتى أبريل 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 انتهى. الصناعة تتجه نحو “الهندسة الوكيلة” المراقبة، ذات الحدود، والتقييم. من يبيع “نشر ثم ننسى” في 2026، هو في الواقع يبيع منتجات 2023.

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

اختر بعناية منصات بناء الوكلاء الأفقية.
مثل Google Agentspace، AWS Bedrock Agents، Microsoft Copilot Studio. قد تكون مفيدة لاحقًا، لكن الآن، السوق يفضل بناء وكيل ضيق، أو شراء واحد متخصص. استثناءً هما Salesforce Agentforce وServiceNow Now Assist، لأنها مدمجة في أنظمة سير العمل التي تستخدمها.

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

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

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

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

كيفية التقدم بشكل فعال

إذا لم تكن فقط تريد “متابعة الوكيل”، بل تريد تبنيه، فإن الترتيب التالي فعال. هو ممل، لكنه مفيد.

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

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

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

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

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

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

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

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

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

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

كيفية التعرف على الاتجاهات

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

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

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

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

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

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

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

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

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

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

التحسين المستمر لنماذج المصادر المفتوحة.
DeepSeek-V3.2 يدعم التفكير في استخدام الأدوات، وQwen 3.6، والنظام البيئي الأوسع للنماذج المفتوحة، كلها تستحق المتابعة. تكلفة المهام الضيقة تتغير، والنماذج المغلقة ليست دائمًا الأفضل.

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

مخاطر غير تقليدية

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

الطريق التقلي